[要約] RFC 7011は、IP Flow Information Export（IPFIX）プロトコルの仕様を定めたもので、フロー情報の交換に使用されます。目的は、ネットワークトラフィックのモニタリングと分析を容易にすることです。
Internet Engineering Task Force (IETF) B. Claise, Ed.
Request for Comments: 7011 Cisco Systems, Inc.
STD: 77 B. Trammell, Ed.
Obsoletes: 5101 ETH Zurich
Category: Standards Track P. Aitken
ISSN: 2070-1721 Cisco Systems, Inc.
September 2013
Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様
Abstract
概要
This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101.
このドキュメントでは、ネットワーク経由でトラフィックフロー情報を送信する手段として機能するIPフロー情報エクスポート（IPFIX）プロトコルについて説明します。トラフィックフロー情報をエクスポートプロセスから収集プロセスに送信するには、フローデータの共通表現とそれらを通信する標準的な手段が必要です。このドキュメントでは、IPFIXデータとテンプレートレコードが、IPFIXエクスポートプロセスからIPFIX収集プロセスへの多数のトランスポートプロトコルでどのように転送されるかについて説明します。このドキュメントはRFC 5101を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7011.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7011で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Changes since RFC 5101 .....................................5
1.2. IPFIX Documents Overview ...................................6
2. Terminology .....................................................7
2.1. Terminology Summary Table .................................13
3. IPFIX Message Format ...........................................13
3.1. Message Header Format .....................................15
3.2. Field Specifier Format ....................................16
3.3. Set and Set Header Format .................................18
3.3.1. Set Format .........................................18
3.3.2. Set Header Format ..................................19
3.4. Record Format .............................................20
3.4.1. Template Record Format .............................20
3.4.2. Options Template Record Format .....................23
3.4.2.1. Scope .....................................23
3.4.2.2. Options Template Record Format ............24
3.4.3. Data Record Format .................................27
4. Specific Reporting Requirements ................................28
4.1. The Metering Process Statistics Options Template ..........29
4.2. The Metering Process Reliability Statistics
Options Template ..........................................29
4.3. The Exporting Process Reliability Statistics
Options Template ..........................................31
4.4. The Flow Keys Options Template ............................32
5. Timing Considerations ..........................................32
5.1. IPFIX Message Header Export Time and Flow Record Time .....32
5.2. Supporting Timestamp Wraparound ...........................33
6. Linkage with the Information Model .............................34
6.1. Encoding of IPFIX Data Types ..............................34
6.1.1. Integral Data Types ................................34
6.1.2. Address Types ......................................34
6.1.3. float32 ............................................34
6.1.4. float64 ............................................34
6.1.5. boolean ............................................35
6.1.6. string and octetArray ..............................35
6.1.7. dateTimeSeconds ....................................35
6.1.8. dateTimeMilliseconds ...............................35
6.1.9. dateTimeMicroseconds ...............................35
6.1.10. dateTimeNanoseconds ...............................36
6.2. Reduced-Size Encoding .....................................36
7. Variable-Length Information Element ............................37
8. Template Management ............................................38
8.1. Template Withdrawal and Redefinition ......................40
8.2. Sequencing Template Management Actions ....................42
8.3. Additional Considerations for Template Management
over SCTP .................................................43
8.4. Additional Considerations for Template Management
over UDP ..................................................44
9. The Collecting Process's Side ..................................45
9.1. Collecting Process Handling of Malformed IPFIX Messages ...46
9.2. Additional Considerations for SCTP Collecting Processes ...46
9.3. Additional Considerations for UDP Collecting Processes ....46
10. Transport Protocol ............................................47
10.1. Transport Compliance and Transport Usage .................47
10.2. SCTP .....................................................48
10.2.1. Congestion Avoidance ..............................48
10.2.2. Reliability .......................................49
10.2.3. MTU ...............................................49
10.2.4. Association Establishment and Shutdown ............49
10.2.5. Failover ..........................................50
10.2.6. Streams ...........................................50
10.3. UDP ......................................................50
10.3.1. Congestion Avoidance ..............................50
10.3.2. Reliability .......................................51
10.3.3. MTU ...............................................51
10.3.4. Session Establishment and Shutdown ................51
10.3.5. Failover and Session Duplication ..................51
10.4. TCP ......................................................52
10.4.1. Congestion Avoidance ..............................52
10.4.2. Reliability .......................................52
10.4.3. MTU ...............................................52
10.4.4. Connection Establishment and Shutdown .............53
10.4.5. Failover ..........................................53
11. Security Considerations .......................................54
11.1. Applicability of TLS and DTLS ............................55
11.2. Usage ....................................................56
11.3. Mutual Authentication ....................................56
11.4. Protection against DoS Attacks ...........................57
11.5. When DTLS or TLS Is Not an Option ........................58
11.6. Logging an IPFIX Attack ..................................58
11.7. Securing the Collector ...................................59
11.8. Privacy Considerations for Collected Data ................59
12. Management Considerations .....................................60
13. IANA Considerations ...........................................61
Appendix A. IPFIX Encoding Examples ...............................62
A.1. Message Header Example ....................................62
A.2. Template Set Examples .....................................63
A.2.1. Template Set Using IANA Information Elements ..........63
A.2.2. Template Set Using Enterprise-Specific Information
Elements ..............................................64
A.3. Data Set Example ..........................................65
A.4. Options Template Set Examples .............................66
A.4.1. Options Template Set Using IANA Information Elements ..66
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ..................................66
A.4.3. Options Template Set Using an Enterprise-Specific
Scope .................................................67
A.4.4. Data Set Using an Enterprise-Specific Scope ...........68
A.5. Variable-Length Information Element Examples ..............69
A.5.1. Example of Variable-Length Information Element with
Length Less Than 255 Octets ...........................69
A.5.2. Example of Variable-Length Information Element with
3-Octet Length Encoding ...............................70
Normative References ..............................................71
Informative References ............................................71
Acknowledgments ...................................................74
Contributors ......................................................75
Traffic on a data network can be seen as consisting of flows passing through network elements. For administrative or other purposes, it is often interesting, useful, or even necessary to have access to information about these flows that pass through the network elements. A Collecting Process should be able to receive the Flow information passing through multiple network elements within the data network. This requires uniformity in the method of representing the flow information and the means of communicating the flows from the network elements to the collection point. This document specifies a protocol to achieve these requirements. This document specifies in detail the representation of different flows, as well as the additional data required for flow interpretation, packet format, transport mechanisms used, security concerns, etc.
データネットワーク上のトラフィックは、ネットワーク要素を通過するフローで構成されていると見なすことができます。管理またはその他の目的で、ネットワーク要素を通過するこれらのフローに関する情報にアクセスすることは、多くの場合、興味深く、有用であり、必要でさえあります。収集プロセスは、データネットワーク内の複数のネットワーク要素を通過するフロー情報を受信できる必要があります。これには、フロー情報を表す方法の均一性と、ネットワーク要素から収集ポイントへのフローを通信する手段が必要です。このドキュメントでは、これらの要件を達成するためのプロトコルを指定しています。このドキュメントでは、さまざまなフローの表現と、フローの解釈、パケット形式、使用されるトランスポートメカニズム、セキュリティ上の懸念などに必要な追加データを詳細に指定しています。
This document obsoletes the Proposed Standard revision of the IPFIX Protocol Specification [RFC5101]. The protocol specified by this document is interoperable with the protocol as specified in [RFC5101]. The following changes have been made to this document with respect to the previous document:
このドキュメントは、IPFIXプロトコル仕様[RFC5101]の提案された標準改訂を廃止します。このドキュメントで指定されているプロトコルは、[RFC5101]で指定されているプロトコルと相互運用できます。前のドキュメントと比較して、このドキュメントには次の変更が加えられています。
- All outstanding technical and editorial errata on [RFC5101] have been addressed.
- [RFC5101]の未解決の技術および編集上のエラッタはすべて対処されています。
- As the [IANA-IPFIX] registry is now the normative reference for all Information Element definitions (see [RFC7012]), all definitions of Information Elements in Section 4 have been replaced with references to that registry.
- [IANA-IPFIX]レジストリがすべての情報要素定義（[RFC7012]を参照）の規範的な参照となったため、セクション4の情報要素のすべての定義がそのレジストリへの参照に置き換えられました。
- The encoding of the dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, and dateTimeNanoseconds data types, and the related encoding of the IPFIX Message Header Export Time field, have been clarified, especially with respect to the epoch upon which the timestamp data types are based.
- dateTimeSeconds、dateTimeMilliseconds、dateTimeMicroseconds、およびdateTimeNanosecondsデータ型のエンコード、およびIPFIXメッセージヘッダーエクスポート時間フィールドの関連するエンコードが、特にタイムスタンプデータ型の基になるエポックに関して明確になりました。
- A new Section 5.2 has been added to address wraparound of these timestamp data types after they overflow in the years 2032-2038.
- これらのタイムスタンプデータタイプが2032〜2038年にオーバーフローした後のラップアラウンドに対処するために、新しいセクション5.2が追加されました。
- Clarifications on encoding, especially in Section 6, have been made: all IPFIX values are encoded in network byte order.
- 特にセクション6で、エンコーディングに関する説明が追加されました。すべてのIPFIX値はネットワークバイトオーダーでエンコードされます。
- Template management, as described in Section 8, has been simplified and clarified: the specification has been relaxed with respect to [RFC5101], especially concerning potential failures in Template ID reuse. Additional corner cases in template management have been addressed. The new template management language is interoperable with that in [RFC5101] to the extent that the behavior was defined in the prior specification.
- セクション8で説明されているように、テンプレート管理は単純化され明確化されました。仕様は[RFC5101]に関して緩和されました。特にテンプレートIDの再利用における潜在的な障害に関するものです。テンプレート管理の追加のまれなケースが対処されました。新しいテンプレート管理言語は、以前の仕様で動作が定義されていた範囲で、[RFC5101]の言語と相互運用可能です。
- Section 11.3 (Mutual Authentication) has been improved to refer to current practices in Transport Layer Security (TLS) mutual authentication; references to Punycode were removed, as these are covered in [RFC6125].
- セクション11.3（相互認証）は、トランスポート層セキュリティ（TLS）相互認証の現在の慣行を参照するように改善されました。 Punycodeへの参照は削除されました。これらは[RFC6125]でカバーされているためです。
- Editorial improvements, including structural changes to Sections 8, 9, and 10 to improve readability, have been applied. Behavior common to all transport protocols has been separated out, with exceptions per transport specifically noted. All template management language (on both Exporting and Collecting Processes) has been unified in Section 8.
- 読みやすさを向上させるためのセクション8、9、および10の構造変更を含む編集上の改善が適用されました。すべてのトランスポートプロトコルに共通の動作は分離されていますが、トランスポートごとの例外は特に注記されています。すべてのテンプレート管理言語（エクスポートプロセスと収集プロセスの両方）は、セクション8で統合されました。
- A new Section 12 on management considerations has been added.
- 管理上の考慮事項に関する新しいセクション12が追加されました。
The IPFIX protocol provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. This document specifies how IPFIX Data Records and Templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIXプロトコルは、ネットワーク管理者にIPフロー情報へのアクセスを提供します。測定されたIPフロー情報をIPFIXエクスポートプロセスから収集プロセスにエクスポートするためのアーキテクチャは、[RFC3917]で定義されている要件に従って、[RFC5470]で定義されています。このドキュメントでは、IPFIXのデータレコードとテンプレートが、IPFIXエクスポートプロセスからIPFIX収集プロセスへの多数のトランスポートプロトコルを介してどのように転送されるかを指定します。
Four IPFIX optimizations/extensions are currently specified: a bandwidth-saving method for the IPFIX protocol [RFC5473], an efficient method for exporting bidirectional flows [RFC5103], a method for the definition and export of complex data structures [RFC6313], and the specification of the Protocol on IPFIX Mediators [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183].
現在、4つのIPFIX最適化/拡張が指定されています。IPFIXプロトコルの帯域幅を節約する方法[RFC5473]、双方向フローをエクスポートする効率的な方法[RFC5103]、複雑なデータ構造を定義およびエクスポートする方法[RFC6313]、およびIPFIXメディエーターフレームワーク[RFC6183]に基づくIPFIXメディエーターのプロトコル[IPFIX-MED-PROTO]の仕様。
A "file-based transport" for IPFIX, which defines how IPFIX Messages can be stored in files for document-based workflows and for archival purposes, is discussed in [RFC5655].
ドキュメントベースのワークフローとアーカイブ目的でIPFIXメッセージをファイルに保存する方法を定義するIPFIXの「ファイルベースのトランスポート」については、[RFC5655]で説明されています。
IPFIX has a formal description of IPFIX Information Elements -- their names, data types, and additional semantic information -- as specified in [RFC7012]. The registry is maintained by IANA [IANA-IPFIX]. The inline export of the Information Element type information is specified in [RFC5610].
IPFIXには、[RFC7012]で指定されているIPFIX情報要素（その名前、データ型、および追加のセマンティック情報）の正式な説明があります。レジストリはIANA [IANA-IPFIX]によって管理されています。情報要素タイプ情報のインラインエクスポートは、[RFC5610]で指定されています。
The framework for packet selection and reporting [RFC5474] enables network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector. The set of packet selection techniques (Sampling, Filtering, and hashing) standardized by the Packet Sampling (PSAMP) protocol is described in [RFC5475]. The PSAMP protocol [RFC5476], which uses IPFIX as its export protocol, specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collector. Instead of exporting PSAMP Packet Reports, the stream of selected packets may also serve as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP has a formal description of its Information Elements: their names, types, and additional semantic information. The PSAMP information model is defined in [RFC5477].
パケットの選択とレポートのフレームワーク[RFC5474]により、ネットワーク要素は統計的およびその他の方法でパケットのサブセットを選択し、選択したパケットに関するレポートのストリームをコレクターにエクスポートできます。パケットサンプリング（PSAMP）プロトコルによって標準化された一連のパケット選択技術（サンプリング、フィルタリング、ハッシュ）は、[RFC5475]で説明されています。エクスポートプロトコルとしてIPFIXを使用するPSAMPプロトコル[RFC5476]は、PSAMPエクスポートプロセスからPSAMPコレクターへのパケット情報のエクスポートを指定します。 PSAMPパケットレポートをエクスポートする代わりに、選択したパケットのストリームをIPFIXフローレコードの生成への入力として使用することもできます。 IPFIXと同様に、PSAMPにはその情報要素の正式な説明があります。名前、タイプ、および追加のセマンティック情報です。 PSAMP情報モデルは[RFC5477]で定義されています。
[RFC6615] specifies a MIB module for monitoring, and [RFC6728] specifies a data model for configuring and monitoring IPFIX and PSAMP-compliant devices using the Network Configuration Protocol (NETCONF). [RFC6727] specifies the PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module defined in [RFC6615].
[RFC6615]は監視用のMIBモジュールを指定し、[RFC6728]はネットワーク構成プロトコル（NETCONF）を使用してIPFIXおよびPSAMP準拠デバイスを構成および監視するためのデータモデルを指定します。 [RFC6727]は、PSAMP MIBモジュールを[RFC6615]で定義されているIPFIX SELECTOR MIBモジュールの拡張として指定します。
In terms of development, [RFC5153] provides guidelines for the implementation and use of the IPFIX protocol, while [RFC5471] provides guidelines for testing. Finally, [RFC5472] describes what types of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
開発に関しては、[RFC5153]はIPFIXプロトコルの実装と使用に関するガイドラインを提供し、[RFC5471]はテストのためのガイドラインを提供します。最後に、[RFC5472]は、IPFIXプロトコルを使用できるアプリケーションのタイプと、提供された情報をどのように使用できるかについて説明しています。さらに、IPFIXフレームワークが他のアーキテクチャーやフレームワークとどのように関連しているかを示しています。
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 RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
The definitions of the basic terms like Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. are semantically identical to those found in the IPFIX requirements document [RFC3917]. Some of the terms have been expanded for more clarity when defining the protocol. Additional terms required for the protocol have also been defined. Definitions in this document and in [RFC5470] are equivalent; definitions that are only relevant to the IPFIX protocol only appear here.
トラフィックフロー、エクスポートプロセス、収集プロセス、観測ポイントなどの基本的な用語の定義は、IPFIX要件ドキュメント[RFC3917]にあるものと意味的に同じです。一部の用語は、プロトコルを定義するときにわかりやすくするために拡張されています。プロトコルに必要な追加の用語も定義されています。このドキュメントと[RFC5470]の定義は同等です。 IPFIXプロトコルにのみ関連する定義はここにのみ表示されます。
The terminology summary table in Section 2.1 gives a quick overview of the relationships among some of the different terms defined.
セクション2.1の用語の要約表は、定義されたいくつかの異なる用語間の関係の概要を示しています。
Observation Point
観測点
An Observation Point is a location in the network where packets can be observed. Examples include a line to which a probe is attached; a shared medium, such as an Ethernet-based LAN; a single port of a router; or a set of interfaces (physical or logical) of a router.
監視ポイントは、パケットを監視できるネットワーク内の場所です。例には、プローブが接続されているラインが含まれます。イーサネットベースのLANなどの共有メディア。ルーターの単一ポート。またはルーターのインターフェイスのセット（物理または論理）。
Note that every Observation Point is associated with an Observation Domain (defined below) and that one Observation Point may be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces.
すべての観測ポイントは観測ドメイン（以下で定義）に関連付けられており、1つの観測ポイントは他のいくつかの観測ポイントのスーパーセットである可能性があることに注意してください。たとえば、1つの観測ポイントをラインカード全体にすることができます。これは、ラインカードのインターフェイスでの個々の観測ポイントのスーパーセットになります。
Observation Domain
観測ドメイン
An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device.
観測ドメインは、計測プロセスによってフロー情報を集約できる観測ポイントの最大のセットです。たとえば、ルータラインカードは、それぞれが観測ポイントである複数のインターフェイスで構成されている場合、観測ドメインになる可能性があります。それが生成するIPFIXメッセージでは、監視ドメインに、エクスポートプロセスごとに一意の監視ドメインIDが含まれています。このようにして、収集プロセスは、IPFIXメッセージを送信するエクスポーターから特定の監視ドメインを識別できます。すべての観測ポイントは、観測ドメインに関連付けられています。観測ドメインIDもIPFIXデバイスごとに一意であることが推奨されます。
Packet Treatment
パケット処理
"Packet Treatment" refers to action(s) performed on a packet by a forwarding device or other middlebox, including forwarding, dropping, delaying for traffic-shaping purposes, etc.
「パケット処理」とは、転送デバイスまたは他のミドルボックスによってパケットに対して実行されるアクションを指し、転送、ドロップ、トラフィックシェーピング目的の遅延などが含まれます。
Traffic Flow or Flow
トラフィックフローまたはフロー
There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX, we use the following definition:
インターネットコミュニティで使用されている「フロー」という用語にはいくつかの定義があります。 IPFIXのコンテキスト内では、次の定義を使用します。
A Flow is defined as a set of packets or frames passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
フローは、特定の時間間隔中にネットワーク内の観測ポイントを通過するパケットまたはフレームのセットとして定義されます。特定のフローに属するすべてのパケットには、共通のプロパティのセットがあります。各プロパティは、次の値に関数を適用した結果として定義されます。
1. one or more packet header fields (e.g., destination IP address), transport header fields (e.g., destination port number), or application header fields (e.g., RTP header fields [RFC3550]).
1. 1つ以上のパケットヘッダーフィールド（宛先IPアドレスなど）、トランスポートヘッダーフィールド（宛先ポート番号など）、またはアプリケーションヘッダーフィールド（RTPヘッダーフィールド[RFC3550]など）。
2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc.).
2. パケット自体の1つ以上の特性（MPLSラベルの数など）。
3. one or more of the fields derived from Packet Treatment (e.g., next-hop IP address, the output interface, etc.).
3. パケット処理から派生した1つ以上のフィールド（次ホップIPアドレス、出力インターフェースなど）。
A packet is defined as belonging to a Flow if it completely satisfies all the defined properties of the Flow.
パケットは、フローのすべての定義済みプロパティを完全に満たす場合、フローに属するものとして定義されます。
Note that the set of packets represented by a Flow may be empty; that is, a Flow may represent zero or more packets. As sampling is a Packet Treatment, this definition includes packets selected by a sampling mechanism.
フローによって表されるパケットのセットは空である可能性があることに注意してください。つまり、フローは0個以上のパケットを表す場合があります。サンプリングはパケット処理であるため、この定義にはサンプリングメカニズムによって選択されたパケットが含まれます。
Flow Key
フローキー
Each of the fields that:
以下の各フィールド：
1. belong to the packet header (e.g., destination IP address), or
1. パケットヘッダーに属している（例：宛先IPアドレス）、または
2. are a property of the packet itself (e.g., packet length), or
2. パケット自体のプロパティ（例：パケット長）、または
3. are derived from Packet Treatment (e.g., Autonomous System (AS) number),
3. パケット処理（自律システム（AS）番号など）から派生し、
and that are used to define a Flow (i.e., are the properties common to all packets in the Flow) are termed Flow Keys. As an example, the traditional '5-tuple' Flow Key of source and destination IP address, source and destination transport port, and transport protocol, groups together all packets belonging to a single direction of communication on a single socket.
フローの定義に使用される（つまり、フロー内のすべてのパケットに共通のプロパティである）は、フローキーと呼ばれます。例として、送信元と宛先のIPアドレス、送信元と宛先のトランスポートポート、およびトランスポートプロトコルの従来の「5タプル」フローキーは、単一のソケットで単一方向の通信に属するすべてのパケットをグループ化します。
Flow Record
フローレコード
A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually contains characteristic properties of the Flow (e.g., source IP address).
フローレコードには、観測ポイントで観測された特定のフローに関する情報が含まれています。フローレコードには、フローの測定されたプロパティ（すべてのフローのパケットの合計バイト数など）が含まれ、通常、フローの特性（送信元IPアドレスなど）が含まれます。
Metering Process
計量プロセス
The Metering Process generates Flow Records. Inputs to the process are packet headers, characteristics, and Packet Treatment observed at one or more Observation Points.
メータリングプロセスはフローレコードを生成します。プロセスへの入力は、1つ以上の観測ポイントで観測されたパケットヘッダー、特性、およびパケット処理です。
The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records.
メータリングプロセスは、パケットヘッダーのキャプチャ、タイムスタンプ、サンプリング、分類、およびフローレコードの維持を含む一連の機能で構成されています。
The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records.
フローレコードのメンテナンスには、新しいレコードの作成、既存のレコードの更新、フロー統計の計算、追加のフロープロパティの導出、フローの有効期限の検出、フローレコードのエクスポートプロセスへの受け渡し、フローレコードの削除が含まれます。
Exporting Process
輸出プロセス
The Exporting Process sends IPFIX Messages to one or more Collecting Processes. The Flow Records in the Messages are generated by one or more Metering Processes.
エクスポートプロセスは、IPFIXメッセージを1つ以上の収集プロセスに送信します。メッセージ内のフローレコードは、1つ以上のメータリングプロセスによって生成されます。
Exporter
輸出業者
A device that hosts one or more Exporting Processes is termed an Exporter.
1つ以上のエクスポートプロセスをホストするデバイスは、エクスポーターと呼ばれます。
IPFIX Device
IPFIXデバイス
An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes as well as arbitrary numbers of Observation Points and Metering Processes.
IPFIXデバイスは、少なくとも1つのエクスポートプロセスをホストします。さらに、エクスポートプロセス、および任意の数の観測ポイントと計測プロセスをホストできます。
Collecting Process
収集プロセス
A Collecting Process receives IPFIX Messages from one or more Exporting Processes. The Collecting Process might process or store Flow Records received within these Messages, but such actions are out of scope for this document.
収集プロセスは、1つ以上のエクスポートプロセスからIPFIXメッセージを受信します。収集プロセスは、これらのメッセージ内で受信されたフローレコードを処理または保存する場合がありますが、そのようなアクションはこのドキュメントの範囲外です。
Collector
コレクタ
A device that hosts one or more Collecting Processes is termed a Collector.
1つ以上の収集プロセスをホストするデバイスは、コレクタと呼ばれます。
Template
テンプレート
A Template is an ordered sequence of <type, length> pairs used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID.
テンプレートは、IPFIXデバイスからコレクターに通信する必要がある特定の情報セットの構造とセマンティクスを完全に指定するために使用される、<type、length>ペアの順序付けされたシーケンスです。各テンプレートは、テンプレートIDによって一意に識別できます。
IPFIX Message
IPFIXメッセージ
An IPFIX Message is a message that originates at the Exporting Process and carries the IPFIX records of this Exporting Process, and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer.
IPFIXメッセージは、エクスポートプロセスで発信され、このエクスポートプロセスのIPFIXレコードを伝達するメッセージであり、宛先は収集プロセスです。 IPFIXメッセージはトランスポート層でカプセル化されます。
Message Header
メッセージヘッダー
The Message Header is the first part of an IPFIX Message; the Message Header provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc.
メッセージヘッダーは、IPFIXメッセージの最初の部分です。メッセージヘッダーは、IPFIXバージョン、メッセージの長さ、メッセージシーケンス番号など、メッセージに関する基本情報を提供します。
Template Record
テンプレートレコード
A Template Record defines the structure and interpretation of fields in a Data Record.
テンプレートレコードは、データレコードのフィールドの構造と解釈を定義します。
Data Record
データ記録
A Data Record is a record that contains values of the parameters corresponding to a Template Record.
データレコードは、テンプレートレコードに対応するパラメータの値を含むレコードです。
Options Template Record
オプションテンプレートレコード
An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record.
オプションテンプレートレコードは、データレコード内のフィールドの構造と解釈を定義するテンプレートレコードです。これには、データレコードの適用範囲のスコープ方法の定義も含まれます。
Set
セットする
A Set is a collection of records that have a similar structure, prefixed by a header. In an IPFIX Message, zero or more Sets follow the Message Header. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets.
セットは、ヘッダーが前に付いた、同様の構造を持つレコードのコレクションです。 IPFIXメッセージでは、ゼロ以上のセットがメッセージヘッダーの後に続きます。セットには、テンプレートセット、オプションテンプレートセット、データセットの3種類があります。
Template Set
テンプレートセット
A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message.
テンプレートセットは、IPFIXメッセージにグループ化された1つ以上のテンプレートレコードのコレクションです。
Options Template Set
オプションテンプレートセット
An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message.
オプションテンプレートセットは、IPFIXメッセージにグループ化された1つ以上のオプションテンプレートレコードのコレクションです。
Data Set
データセット
A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record.
データセットは、IPFIXメッセージにグループ化された、同じタイプの1つ以上のデータレコードです。各データレコードは、テンプレートレコードまたはオプションテンプレートレコードによって事前に定義されています。
Information Element
情報要素
An Information Element is a protocol- and encoding-independent description of an attribute that may appear in an IPFIX Record. Information Elements are defined in the IANA "IPFIX Information Elements" registry [IANA-IPFIX]. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX.
情報要素は、プロトコルおよびエンコーディングに依存しない属性の説明であり、IPFIXレコードに表示される場合があります。情報要素は、IANAの「IPFIX情報要素」レジストリ[IANA-IPFIX]で定義されています。情報要素に関連付けられているタイプは、情報エレメントに含まれる可能性のある制約を示し、IPFIXで使用するための有効なエンコーディングメカニズムも決定します。
Transport Session
輸送セッション
In the Stream Control Transmission Protocol (SCTP), the Transport Session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC4960]; in TCP, the Transport Session is known as the TCP connection, which is uniquely identified by the combination of IP addresses and TCP ports used. In UDP, the Transport Session is known as the UDP session, which is uniquely identified by the combination of IP addresses and UDP ports used.
ストリーム制御伝送プロトコル（SCTP）では、トランスポートセッションはSCTPアソシエーションと呼ばれ、SCTPエンドポイント[RFC4960]によって一意に識別されます。 TCPでは、トランスポートセッションはTCP接続と呼ばれ、使用されるIPアドレスとTCPポートの組み合わせによって一意に識別されます。 UDPでは、トランスポートセッションはUDPセッションと呼ばれ、使用されるIPアドレスとUDPポートの組み合わせによって一意に識別されます。
Figure A shows a summary of IPFIX terminology.
図Aは、IPFIX用語の要約を示しています。
+------------------+---------------------------------------------+
| | Contents |
| +--------------------+------------------------+
| Set | Template | Record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Figure A: Terminology Summary Table
図A：用語の要約表
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record.
データセットはデータレコードで構成されています。テンプレートレコードは含まれていません。テンプレートレコードまたはオプションテンプレートレコードは、データレコードを定義します。
A Template Set contains only Template Record(s).
テンプレートセットには、テンプレートレコードのみが含まれます。
An Options Template Set contains only Options Template Record(s).
オプションテンプレートセットには、オプションテンプレートレコードのみが含まれます。
An IPFIX Message consists of a Message Header, followed by zero or more Sets. The Sets can be any of these three possible types: Data Set, Template Set, or Options Template Set.
IPFIXメッセージは、メッセージヘッダーとそれに続くゼロ以上のセットで構成されます。セットは、データセット、テンプレートセット、またはオプションテンプレートセットの3つのタイプのいずれかになります。
The format of the IPFIX Message is shown in Figure B.
IPFIXメッセージのフォーマットを図Bに示します。
+----------------------------------------------------+
| Message Header |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
Figure B: IPFIX Message Format
図B：IPFIXメッセージ形式
Following are some examples of IPFIX Messages:
次に、IPFIXメッセージの例をいくつか示します。
1. An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets, as shown in Figure C. Here, Template and Options Template Sets are transmitted "on demand", before the first Data Set whose structure they define.
1. 図Cに示すように、インターリーブされたテンプレート、データ、およびオプションテンプレートセットで構成されるIPFIXメッセージ。ここで、テンプレートとオプションテンプレートセットは、構造が定義されている最初のデータセットの前に「オンデマンド」で送信されます。
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | Set | | Set | ... | Template | | Set | |
| | | | | | | Set | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+
Figure C: IPFIX Message: Example 1
図C：IPFIXメッセージ：例1
2. An IPFIX Message consisting entirely of Data Sets, sent after the appropriate Template Records have been defined and transmitted to the Collecting Process, as shown in Figure D.
2. 図Dに示すように、適切なテンプレートレコードが定義されて収集プロセスに送信された後に送信される、完全にデータセットで構成されるIPFIXメッセージ。
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | | Data | | Data | |
| Header | | Set | ... | Set | ... | Set | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+
Figure D: IPFIX Message: Example 2
図D：IPFIXメッセージ：例2
3. An IPFIX Message consisting entirely of Template and Options Template Sets, as shown in Figure E. Such a message can be used to define or redefine Templates and Options Templates in bulk.
3. 図Eに示すように、テンプレートとオプションテンプレートセットのみで構成されるIPFIXメッセージ。このようなメッセージは、テンプレートとオプションテンプレートを一括で定義または再定義するために使用できます。
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | Set | ... | Set | ... | Template | |
| | | | | | | Set | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+
Figure E: IPFIX Message: Example 3
図E：IPFIXメッセージ：例3
The format of the IPFIX Message Header is shown in Figure F.
IPFIXメッセージヘッダーのフォーマットを図Fに示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure F: IPFIX Message Header Format
図F：IPFIXメッセージヘッダーの形式
Each Message Header field is exported in network byte order. The fields are defined as follows:
各メッセージヘッダーフィールドは、ネットワークバイトオーダーでエクスポートされます。フィールドは次のように定義されています。
Version
バージョン
Version of IPFIX to which this Message conforms. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].
このメッセージが準拠するIPFIXのバージョン。このフィールドの値は、現在のバージョンでは0x000aであり、NetFlowサービスエクスポートバージョン9 [RFC3954]で使用されているバージョンを1つ増やします。
Length
長さ
Total length of the IPFIX Message, measured in octets, including Message Header and Set(s).
IPFIXメッセージの全長（メッセージヘッダーとセットを含む、オクテットで測定）。
Export Time
エクスポート時間
Time at which the IPFIX Message Header leaves the Exporter, expressed in seconds since the UNIX epoch of 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer.
IPFIXメッセージヘッダーがエクスポーターを離れる時刻。UNIXの1970年1月1日00:00 UTCからの秒数で表され、符号なし32ビット整数としてエンコードされます。
Sequence Number
シーケンス番号
Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP session are considered to be part of the same stream. This value can be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number.
エクスポートプロセスによって現在の観測ドメインから現在のストリームで現在のストリームで送信されたすべてのIPFIXデータレコードの2 ^ 32を法とする増分シーケンスカウンター。各SCTPストリームはシーケンス番号を個別にカウントしますが、TCP接続またはUDPセッションのすべてのメッセージは同じストリームの一部と見なされます。収集プロセスはこの値を使用して、IPFIXデータレコードが失われたかどうかを識別できます。テンプレートとオプションテンプレートレコードはシーケンス番号を増やしません。
Observation Domain ID
観測ドメインID
A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporter. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in the case of a hierarchy of Collectors when aggregated Data Records are exported.
ローカルでエクスポートプロセスに固有の監視ドメインの32ビットの識別子。エクスポートプロセスは、観測ドメインIDを使用して、フローを計測した観測ドメインを収集プロセスに対して一意に識別します。この識別子もIPFIXデバイスごとに一意であることが推奨されます。収集プロセスは、トランスポートセッションと観測ドメインIDフィールドを使用して、同じエクスポーターから発信された異なるエクスポートストリームを分離する必要があります（SHOULD）。監視ドメインIDは、IPFIXメッセージ全体に関連する特定の監視ドメインIDがない場合、たとえば、エクスポートプロセス統計をエクスポートする場合、または集約されたデータレコードがエクスポートされるコレクターの階層の場合、0にする必要があります。
Vendors need the ability to define proprietary Information Elements, because, for example, they are delivering a pre-standards product, or the Information Element is in some way commercially sensitive. This section describes the Field Specifier format for both IANA-registered Information Elements [IANA-IPFIX] and enterprise-specific Information Elements.
ベンダーは、たとえば、先行標準製品を提供している、または情報要素が何らかの形で商業的に敏感であるため、独自の情報要素を定義する機能を必要としています。このセクションでは、IANAに登録された情報要素[IANA-IPFIX]と企業固有の情報要素の両方のフィールド指定子形式について説明します。
The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element appears in [IANA-IPFIX], and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier identified an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Appendix A.2.2.
情報要素は、情報要素識別子によって識別されます。エンタープライズビットが0に設定されている場合、対応する情報要素が[IANA-IPFIX]に表示され、エンタープライズ番号が存在してはならない（MUST NOT）。 Enterpriseビットが1に設定されている場合、対応する情報要素識別子は企業固有の情報要素を識別しました。企業番号が存在している必要があります。この例を付録A.2.2に示します。
The Field Specifier format is shown in Figure G.
フィールド指定子の形式を図Gに示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure G: Field Specifier Format
図G：フィールド指定子の形式
Where:
ただし：
E
絵
Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element identifier identifies an Information Element in [IANA-IPFIX], and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number field MUST be present.
エンタープライズビット。これはフィールド指定子の最初のビットです。このビットが0の場合、情報要素識別子は[IANA-IPFIX]の情報要素を識別し、4オクテットのエンタープライズ番号フィールドは存在してはならない（MUST NOT）。このビットが1の場合、情報要素識別子は企業固有の情報要素を識別し、企業番号フィールドが存在しなければなりません（MUST）。
Information Element identifier
情報要素識別子
A numeric value that represents the Information Element. Refer to [IANA-IPFIX].
情報要素を表す数値。 [IANA-IPFIX]を参照してください。
Field Length
フィールド長
The length of the corresponding encoded Information Element, in octets. Refer to [IANA-IPFIX]. The Field Length may be smaller than that listed in [IANA-IPFIX] if the reduced-size encoding is used (see Section 6.2). The value 65535 is reserved for variable-length Information Elements (see Section 7).
オクテットで表した、対応するエンコードされた情報要素の長さ。 [IANA-IPFIX]を参照してください。縮小サイズのエンコーディングが使用されている場合、フィールド長は[IANA-IPFIX]に記載されているものよりも小さくなる場合があります（セクション6.2を参照）。値65535は可変長の情報要素用に予約されています（セクション7を参照）。
Enterprise Number
企業番号
IANA enterprise number [IANA-PEN] of the authority defining the Information Element identifier in this Template Record.
このテンプレートレコードの情報要素識別子を定義する機関のIANAエンタープライズ番号[IANA-PEN]。
A Set is a generic term for a collection of records that have a similar structure. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets. Each of these Sets consists of a Set Header and one or more records. The Set Format and the Set Header Format are defined in the following sections.
セットは、同様の構造を持つレコードのコレクションの総称です。セットには、テンプレートセット、オプションテンプレートセット、データセットの3種類があります。これらの各セットは、セットヘッダーと1つ以上のレコードで構成されます。 Set FormatとSet Header Formatは、次のセクションで定義されています。
A Set has the format shown in Figure H. The record types can be either Template Records, Options Template Records, or Data Records. The record types MUST NOT be mixed within a Set.
セットの形式は、図Hに示されています。レコードタイプは、テンプレートレコード、オプションテンプレートレコード、またはデータレコードのいずれかです。セット内でレコードタイプを混在させることはできません。
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+
Figure H: Set Format
図H：フォーマットの設定
Set Header
ヘッダーを設定
The Set Header Format is defined in Section 3.3.2.
Set Header Formatはセクション3.3.2で定義されています。
Record
記録
One of the record formats: Template Record, Options Template Record, or Data Record format.
レコード形式の1つ：テンプレートレコード、オプションテンプレートレコード、またはデータレコード形式。
Padding
パディング
The Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of octets with value zero (0). The padding length MUST be shorter than any allowable record in this Set. If padding of the IPFIX Message is desired in combination with very short records, then the padding Information Element 'paddingOctets' can be used for padding records such that their length is increased to a multiple of 4 or 8 octets. Because Template Sets are always 4-octet aligned by definition, padding is only needed in the case of other alignments, e.g., on 8-octet boundaries.
エクスポートプロセスは、いくつかのパディングオクテットを挿入して、後続のセットが整列された境界で開始されるようにする場合があります。セキュリティ上の理由から、パディングオクテットは、値がゼロ（0）のオクテットで構成する必要があります。パディングの長さは、このセットの許容されるレコードよりも短くなければなりません。非常に短いレコードと組み合わせてIPFIXメッセージのパディングが必要な場合は、パディング情報要素「paddingOctets」を使用して、レコードの長さを4または8オクテットの倍数に増やすことができます。テンプレートセットは常に定義により常に4オクテットに配置されるため、パディングは他の配置の場合（たとえば、8オクテットの境界）にのみ必要です。
Every Set contains a common header. This header is defined in Figure I.
すべてのセットには共通のヘッダーが含まれています。このヘッダーは、図Iで定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure I: Set Header Format
図I：ヘッダー形式の設定
Each Set Header field is exported in network format. The fields are defined as follows:
各Set Headerフィールドはネットワーク形式でエクスポートされます。フィールドは次のように定義されています。
Set ID
セットID
Identifies the Set. A value of 2 is reserved for Template Sets. A value of 3 is reserved for Options Template Sets. Values from 4 to 255 are reserved for future use. Values 256 and above are used for Data Sets. The Set ID values of 0 and 1 are not used, for historical reasons [RFC3954].
セットを識別します。値2はテンプレートセット用に予約されています。値3は、オプションテンプレートセット用に予約されています。 4〜255の値は、将来の使用のために予約されています。データセットには256以上の値が使用されます。歴史的な理由から、0と1のセットID値は使用されません[RFC3954]。
Length
長さ
Total length of the Set, in octets, including the Set Header, all records, and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set.
セットヘッダー、すべてのレコード、オプションのパディングを含む、オクテット単位のセットの全長。個々のセットには複数のレコードが含まれる場合があるため、長さの値を使用して次のセットの位置を決定する必要があります。
IPFIX defines three record formats, as defined in the next sections: the Template Record format, the Options Template Record format, and the Data Record format.
IPFIXは、次のセクションで定義されているように、テンプレートレコード形式、オプションテンプレートレコード形式、およびデータレコード形式の3つのレコード形式を定義します。
One of the essential elements in the IPFIX record format is the Template Record. Templates greatly enhance the flexibility of the record format because they allow the Collecting Process to process IPFIX Messages without necessarily knowing the interpretation of all Data Records. A Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Element identifiers.
IPFIXレコード形式の重要な要素の1つは、テンプレートレコードです。テンプレートを使用すると、収集プロセスがすべてのデータレコードの解釈を必ずしも知らなくてもIPFIXメッセージを処理できるため、レコード形式の柔軟性が大幅に向上します。テンプレートレコードには、IANA割り当てまたは企業固有の情報要素識別子の任意の組み合わせが含まれています。
The format of the Template Record is shown in Figure J. It consists of a Template Record Header and one or more Field Specifiers. Field Specifiers are defined in Figure G above.
テンプレートレコードのフォーマットを図Jに示します。これは、テンプレートレコードヘッダーと1つ以上のフィールド指定子で構成されています。フィールド指定子は、上記の図Gで定義されています。
+--------------------------------------------------+
| Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure J: Template Record Format
図J：テンプレートレコードの形式
The format of the Template Record Header is shown in Figure K.
テンプレートレコードヘッダーのフォーマットを図Kに示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure K: Template Record Header Format
図K：テンプレートレコードヘッダーの形式
The Template Record Header Field definitions are as follows:
テンプレートレコードヘッダーフィールドの定義は次のとおりです。
Template ID
テンプレートID
Each Template Record is given a unique Template ID in the range 256 to 65535. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Since Template IDs are used as Set IDs in the Sets they describe (see Section 3.4.3), values 0-255 are reserved for special Set types (e.g., Template Sets themselves), and Templates and Options Templates (see Section 3.4.2) cannot share Template IDs within a Transport Session and Observation Domain. There are no constraints regarding the order of the Template ID allocation. As Exporting Processes are free to allocate Template IDs as they see fit, Collecting Processes MUST NOT assume incremental Template IDs, or anything about the contents of a Template based on its Template ID alone.
各テンプレートレコードには、256〜65535の範囲の一意のテンプレートIDが与えられます。この一意性は、テンプレートIDを生成したトランスポートセッションおよび観測ドメインに対してローカルです。テンプレートIDは、それらが説明するセット（セクション3.4.3を参照）でセットIDとして使用されるため、値0〜255は、特別なセットタイプ（テンプレートセット自体など）、およびテンプレートとオプションテンプレート（セクション3.4.2を参照）用に予約されています。 ）トランスポートセッションと観測ドメイン内でテンプレートIDを共有することはできません。テンプレートIDの割り当て順序に関する制約はありません。エクスポートプロセスは、必要に応じてテンプレートIDを自由に割り当てることができるため、収集プロセスは、増分テンプレートID、またはそのテンプレートIDのみに基づいてテンプレートの内容について何も想定してはなりません。
Field Count
フィールド数
Number of fields in this Template Record.
このテンプレートレコードのフィールド数。
The example in Figure L shows a Template Set with mixed IANA-assigned and enterprise-specific Information Elements. It consists of a Set Header, a Template Header, and several Field Specifiers.
図Lの例は、IANAが割り当てられ、企業固有の情報要素が混在するテンプレートセットを示しています。これは、セットヘッダー、テンプレートヘッダー、およびいくつかのフィールド指定子で構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 | Field Length 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 | Field Length 1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N | Field Length 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 | Field Length 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 | Field Length 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M | Field Length 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure L: Template Set Example
図L：テンプレートセットの例
Information Element id.s 1.2 and 2.1 appear in [IANA-IPFIX] (Enterprise bit = 0) and therefore do not need an Enterprise Number to identify them.
情報要素id.s 1.2および2.1は[IANA-IPFIX]（エンタープライズビット= 0）に表示されるため、それらを識別するためにエンタープライズ番号は必要ありません。
Thanks to the notion of scope, The Options Template Record gives the Exporter the ability to provide additional information to the Collector that would not be possible with Flow Records alone.
スコープの概念のおかげで、オプションテンプレートレコードを使用すると、エクスポーターはフローレコードだけでは不可能な追加情報をコレクターに提供できます。
See Section 4 for specific Options Templates used for reporting metadata about IPFIX Exporting and Metering Processes.
IPFIXエクスポートおよびメータリングプロセスに関するメタデータのレポートに使用される特定のオプションテンプレートについては、セクション4を参照してください。
The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records.
オプションテンプレートセットでのみ使用可能なスコープは、データレコードで報告された情報要素のコンテキストを提供します。
The scope is one or more Information Elements, specified in the Options Template Record. At a minimum, Collecting Processes SHOULD support as scope the observationDomainId, exportingProcessId, meteringProcessId, templateId, lineCardId, exporterIPv4Address, exporterIPv6Address, and ingressInterface Information Elements. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However, some Information Element types don't make sense if specified as scope (for example, the counter Information Elements).
スコープは、オプションテンプレートレコードで指定された1つ以上の情報要素です。少なくとも、プロセスの収集は、ObservationDomainId、exportingProcessId、meteringProcessId、templateId、lineCardId、exporterIPv4Address、exporterIPv6Address、およびingressInterface情報要素のスコープとしてサポートする必要があります（SHOULD）。 IPFIXプロトコルは、スコープの情報要素の使用を妨げません。ただし、一部の情報要素タイプは、スコープとして指定された場合は意味がありません（たとえば、カウンター情報要素）。
The IPFIX Message Header already contains the Observation Domain ID. If not zero, this Observation Domain ID can be considered as an implicit scope for the Data Records in the IPFIX Message.
IPFIXメッセージヘッダーにはすでに観測ドメインIDが含まれています。ゼロでない場合、この観測ドメインIDは、IPFIXメッセージのデータレコードの暗黙的なスコープと見なすことができます。
Multiple Scope Fields MAY be present in the Options Template Record, in which case the composite scope is the combination of the scopes. For example, if the two scopes are meteringProcessId and templateId, the combined scope is this Template for this Metering Process. If a different order of Scope Fields would result in a Record having a different semantic meaning, then the order of Scope Fields MUST be preserved by the Exporting Process. For example, in the context of PSAMP [RFC5476], if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function.
オプションテンプレートレコードに複数のスコープフィールドが存在する場合があります。その場合、複合スコープはスコープの組み合わせになります。たとえば、2つのスコープがmeteringProcessIdとtemplateIdである場合、結合されたスコープはこのメータリングプロセスのこのテンプレートです。スコープフィールドの順序が異なると、レコードのセマンティックな意味が異なる場合は、エクスポートプロセスでスコープフィールドの順序を維持する必要があります。たとえば、PSAMP [RFC5476]のコンテキストでは、最初のスコープがフィルタリング関数を定義し、2番目のスコープがサンプリング関数を定義する場合、スコープの順序が重要です。最初にサンプリング関数を適用し、その後にフィルタリング関数を適用すると、最初にフィルタリング関数を適用し、その後にサンプリング関数を適用する場合とは、データレコードが異なる可能性があります。
An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Element identifiers.
オプションテンプレートレコードには、IANAによって割り当てられた、または企業固有の情報要素識別子の組み合わせが含まれます。
The format of the Options Template Record is shown in Figure M. It consists of an Options Template Record Header and one or more Field Specifiers. Field Specifiers are defined in Figure G above.
オプションテンプレートレコードのフォーマットを図Mに示します。これは、オプションテンプレートレコードヘッダーと1つ以上のフィールド指定子で構成されています。フィールド指定子は、上記の図Gで定義されています。
+--------------------------------------------------+
| Options Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure M: Options Template Record Format
図M：オプションテンプレートのレコード形式
The format of the Options Template Record Header is shown in Figure N.
オプションテンプレートレコードヘッダーのフォーマットを図Nに示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure N: Options Template Record Header Format
図N：オプションテンプレートのレコードヘッダー形式
The Options Template Record Header Field definitions are as follows:
オプションテンプレートレコードヘッダーフィールドの定義は次のとおりです。
Template ID
テンプレートID
Each Options Template Record is given a unique Template ID in the range 256 to 65535. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Since Template IDs are used as Set IDs in the sets they describe (see Section 3.4.3), values 0-255 are reserved for special Set types (e.g., Template Sets themselves), and Templates and Options Templates cannot share Template IDs within a Transport Session and Observation Domain. There are no constraints regarding the order of the Template ID allocation. As Exporting Processes are free to allocate Template IDs as they see fit, Collecting Processes MUST NOT assume incremental Template IDs, or anything about the contents of an Options Template based on its Template ID alone.
各オプションテンプレートレコードには、256〜65535の範囲の一意のテンプレートIDが与えられます。この一意性は、テンプレートIDを生成したトランスポートセッションと観測ドメインに対してローカルです。テンプレートIDは、それらが説明するセットのセットIDとして使用されるため（セクション3.4.3を参照）、値0〜255は特別なセットタイプ（たとえば、テンプレートセット自体）用に予約されており、テンプレートとオプションテンプレートは、トランスポートセッションと観測ドメイン。テンプレートIDの割り当て順序に関する制約はありません。エクスポートプロセスは、必要に応じてテンプレートIDを自由に割り当てることができるため、収集プロセスは、増分テンプレートIDや、テンプレートIDのみに基づいてオプションテンプレートの内容について想定してはなりません。
Field Count
フィールド数
Number of all fields in this Options Template Record, including the Scope Fields.
スコープフィールドを含む、このオプションテンプレートレコードのすべてのフィールドの数。
Scope Field Count
スコープフィールド数
Number of scope fields in this Options Template Record. The Scope Fields are normal Fields, except that they are interpreted as scope at the Collector. A scope field count of N specifies that the first N Field Specifiers in the Template Record are Scope Fields. The Scope Field Count MUST NOT be zero.
このオプションテンプレートレコードのスコープフィールドの数。スコープフィールドは、コレクタでスコープとして解釈されることを除いて、通常のフィールドです。 Nのスコープフィールド数は、テンプレートレコードの最初のN個のフィールド指定子がスコープフィールドであることを指定します。スコープフィールドカウントはゼロであってはなりません。
The example in Figure O shows an Options Template Set with mixed IANA-assigned and enterprise-specific Information Elements. It consists of a Set Header, an Options Template Header, and several Field Specifiers.
図Oの例は、IANAが割り当てられ、企業固有の情報要素が混在するオプションテンプレートセットを示しています。セットヘッダー、オプションテンプレートヘッダー、およびいくつかのフィールド指定子で構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = N + M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = N |0| Scope 1 Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length |0| Scope 2 Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 2 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1| Scope N Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Scope N Enterprise Number |1| Option 1 Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |0| Option M Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure O: Options Template Set Example
図O：オプションテンプレートセットの例
The Data Records are sent in Data Sets. The format of the Data Record is shown in Figure P. It consists only of one or more Field Values. The Template ID to which the Field Values belong is encoded in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".
データレコードはデータセットで送信されます。データレコードのフォーマットを図Pに示します。これは、1つ以上のフィールド値のみで構成されています。フィールド値が属するテンプレートIDは、セットヘッダーフィールド「セットID」でエンコードされます。つまり、「セットID」=「テンプレートID」です。
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure P: Data Record Format
図P：データレコードの形式
Note that Field Values do not necessarily have a length of 16 bits. Field Values are encoded according to their data type as specified in [RFC7012].
フィールド値の長さは必ずしも16ビットではないことに注意してください。 [RFC7012]で指定されているように、フィールド値はデータタイプに従ってエンコードされます。
Interpretation of the Data Record format can be done only if the Template Record corresponding to the Template ID is available at the Collecting Process.
データレコード形式の解釈は、収集プロセスでテンプレートIDに対応するテンプレートレコードが利用可能な場合にのみ実行できます。
The example in Figure Q shows a Data Set. It consists of a Set Header and several Field Values.
図Qの例は、データセットを示しています。セットヘッダーといくつかのフィールド値で構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure Q: Data Set, Containing Data Records
図Q：データレコードを含むデータセット
Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process.
フローレコードと計測プロセスに関する追加情報を提供するには、いくつかの特定のオプションテンプレートとオプションテンプレートレコードが必要です。
The Options Template and Options Template Records defined in these subsections, which impose some constraints on the Metering Process and Exporting Process implementations, MAY be implemented. If implemented, the specific Options Templates SHOULD be implemented as specified in these subsections.
これらのサブセクションで定義されているオプションテンプレートとオプションテンプレートレコードは、メータリングプロセスとエクスポートプロセスの実装にいくつかの制約を課し、実装される場合があります。実装する場合は、これらのサブセクションで指定されているように、特定のオプションテンプレートを実装する必要があります（SHOULD）。
The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates.
情報要素の最小セットは、これらの特定のIPFIXオプションテンプレートで常に指定されます。それでも、これらの特定のオプションテンプレートで追加の情報要素が使用される場合があります。
The Collecting Process MUST check the possible combinations of Information Elements within the Options Template Records to correctly interpret the following Options Templates.
収集プロセスは、次のオプションテンプレートを正しく解釈するために、オプションテンプレートレコード内の情報要素の可能な組み合わせをチェックする必要があります。
The Metering Process Statistics Options Template specifies the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
メータリングプロセス統計オプションテンプレートは、メータリングプロセス統計をレポートするためのデータレコードの構造を指定します。 [IANA-IPFIX]で定義されている次の情報要素を含める必要があります。
(scope) observationDomainId
（スコープ）ObservationDomainId
This Information Element MUST be defined as a Scope Field and MUST be present, unless the Observation Domain ID of the enclosing Message is non-zero.
この情報要素は、スコープフィールドとして定義されなければならず、それを囲んでいるメッセージの観測ドメインIDがゼロ以外でない限り、存在していなければなりません。
(scope) meteringProcessId
（スコープ）meteringProcessId
If present, this Information Element MUST be defined as a Scope Field.
存在する場合、この情報要素はスコープフィールドとして定義する必要があります。
exportedMessageTotalCount
exportMessageTotalCount
exportedFlowRecordTotalCount
exportFlowRecordTotalCount
exportedOctetTotalCount
exportOctetTotalCount
The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的に、または一部のエクスポートポリシーに基づいて、メータリングプロセス統計オプションテンプレートで指定されたデータレコードをエクスポートする必要があります（SHOULD）。この周期性またはエクスポートポリシーは構成可能である必要があります。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
複数の計測プロセスがエクスポーター監視ドメインで使用できる場合、情報要素meteringProcessIdを追加のスコープフィールドとして指定する必要があることに注意してください。
The Metering Process Reliability Statistics Options Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
メータリングプロセスの信頼性統計オプションテンプレートは、メータリングプロセスの信頼性の欠如を報告するためのデータレコードの構造を指定します。 [IANA-IPFIX]で定義されている次の情報要素を含める必要があります。
(scope) observationDomainId
（スコープ）ObservationDomainId
This Information Element MUST be defined as a Scope Field and MUST be present, unless the Observation Domain ID of the enclosing Message is non-zero.
この情報要素は、スコープフィールドとして定義されなければならず、それを囲んでいるメッセージの観測ドメインIDがゼロ以外でない限り、存在していなければなりません。
(scope) meteringProcessId
（スコープ）meteringProcessId
If present, this Information Element MUST be defined as a Scope Field.
存在する場合、この情報要素はスコープフィールドとして定義する必要があります。
ignoredPacketTotalCount
ignorePacketTotalCount
ignoredOctetTotalCount
無視されたOctetTotalCount
time first packet ignored
最初のパケットが無視された時間
The timestamp of the first packet that was ignored by the Metering Process. For this timestamp, any of the following timestamp Information Elements can be used:
メータリングプロセスによって無視された最初のパケットのタイムスタンプ。このタイムスタンプには、次のタイムスタンプ情報要素のいずれかを使用できます。
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
ObservationTimeSeconds、observationTimeMilliseconds、observationTimeMicroseconds、またはObservationTimeNanoseconds。
time last packet ignored
最後のパケットが無視された時間
The timestamp of the last packet that was ignored by the Metering Process. For this timestamp, any of the following timestamp Information Elements can be used:
メータリングプロセスによって無視された最後のパケットのタイムスタンプ。このタイムスタンプには、次のタイムスタンプ情報要素のいずれかを使用できます。
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
ObservationTimeSeconds、observationTimeMilliseconds、observationTimeMicroseconds、またはObservationTimeNanoseconds。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的または何らかのエクスポートポリシーに基づいて、メータリングプロセス信頼性統計オプションテンプレートで指定されたデータレコードをエクスポートする必要があります（SHOULD）。この周期性またはエクスポートポリシーは構成可能である必要があります。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
複数の計測プロセスがエクスポーター監視ドメインで使用できる場合、情報要素meteringProcessIdを追加のスコープフィールドとして指定する必要があることに注意してください。
Since the Metering Process Reliability Statistics Options Template contains two identical timestamp Information Elements, and since the order of the Information Elements in the Template Records is not guaranteed, the Collecting Process interprets the time interval of ignored packets as the range between the two values; see Section 5.2 for wraparound considerations.
メータリングプロセス信頼性統計オプションテンプレートには2つの同じタイムスタンプ情報要素が含まれ、テンプレートレコード内の情報要素の順序は保証されないため、収集プロセスは無視されたパケットの時間間隔を2つの値の間の範囲として解釈します。ラップアラウンドの考慮事項については、セクション5.2を参照してください。
The Exporting Process Reliability Statistics Options Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting Process. It SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
エクスポートプロセスの信頼性統計オプションテンプレートは、エクスポートプロセスの信頼性の欠如を報告するためのデータレコードの構造を指定します。 [IANA-IPFIX]で定義されている次の情報要素を含める必要があります。
(scope) Exporting Process Identifier
（スコープ）プロセス識別子のエクスポート
The identifier of the Exporting Process for which reliability is reported. Any of the exporterIPv4Address, exporterIPv6Address, or exportingProcessId Information Elements can be used for this field. This Information Element MUST be defined as a Scope Field.
信頼性が報告されるエクスポートプロセスの識別子。このフィールドには、exporterIPv4Address、exporterIPv6Address、またはexportingProcessId情報要素のいずれかを使用できます。この情報要素は、スコープフィールドとして定義する必要があります。
notSentFlowTotalCount
notSentFlowTotalCount
notSentPacketTotalCount
notSentPacketTotalCount
notSentOctetTotalCount
notSentOctetTotalCount
time first flow dropped
最初のフローがドロップした時間
The time at which the first Flow Record was dropped by the Exporting Process. For this timestamp, any of the following timestamp Information Elements can be used:
最初のフローレコードがエクスポートプロセスによってドロップされた時刻。このタイムスタンプには、次のタイムスタンプ情報要素のいずれかを使用できます。
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
ObservationTimeSeconds、observationTimeMilliseconds、observationTimeMicroseconds、またはObservationTimeNanoseconds。
time last flow dropped
最後のフローがドロップした時間
The time at which the last Flow Record was dropped by the Exporting Process. For this timestamp, any of the following timestamp Information Elements can be used:
最後のフローレコードがエクスポートプロセスによってドロップされた時刻。このタイムスタンプには、次のタイムスタンプ情報要素のいずれかを使用できます。
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
ObservationTimeSeconds、observationTimeMilliseconds、observationTimeMicroseconds、またはObservationTimeNanoseconds。
The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的またはいくつかのエクスポートポリシーに基づいて、エクスポートプロセスの信頼性統計オプションテンプレートで指定されたデータレコードをエクスポートする必要があります（SHOULD）。この周期性またはエクスポートポリシーは構成可能である必要があります。
Since the Exporting Process Reliability Statistics Options Template contains two identical timestamp Information Elements, and since the order of the Information Elements in the Template Records is not guaranteed, the Collecting Process interprets the time interval of dropped packets as the range between the two values; see Section 5.2 for wraparound considerations.
エクスポートプロセスの信頼性統計オプションテンプレートには2つの同じタイムスタンプ情報要素が含まれ、テンプレートレコード内の情報要素の順序は保証されないため、収集プロセスはドロップされたパケットの時間間隔を2つの値の間の範囲として解釈します。ラップアラウンドの考慮事項については、セクション5.2を参照してください。
The Flow Keys Options Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow.
フローキーオプションテンプレートは、レポートされたフローのフローキーをレポートするためのデータレコードの構造を指定します。フローキーデータレコードは、templateIdによって参照される特定のテンプレートレコードを拡張します。テンプレートレコードは、対応するデータレコードに含まれる情報要素のうち、レポートされたフローのフローキーとして機能するフロープロパティを記述するものを指定することで拡張されます。
The Flow Keys Options Template SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
フローキーオプションテンプレートには、[IANA-IPFIX]で定義されている次の情報要素を含める必要があります（SHOULD）。
(scope) templateId
（スコープ）templateId
This Information Element MUST be defined as a Scope Field.
この情報要素は、スコープフィールドとして定義する必要があります。
flowKeyIndicator
flowKeyIndicator
The IPFIX Message Header Export Time field is the time at which the IPFIX Message Header leaves the Exporter, using the same encoding as the dateTimeSeconds abstract data type [RFC7012], i.e., expressed in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer.
IPFIXメッセージヘッダーエクスポート時間フィールドは、IPFIXメッセージヘッダーがエクスポーターを離れる時間で、dateTimeSeconds抽象データタイプ[RFC7012]と同じエンコーディングを使用します。つまり、1970年1月1日のUNIXエポックからの秒数で表されます。 00 UTC、符号なし32ビット整数としてエンコードされます。
Certain time-related Information Elements may be expressed as an offset from this Export Time. For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements, which encode the absolute time in microseconds in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements in the Data Record, which respectively report the flow start and end time as negative offsets from the Export Time, as an unsigned 32-bit integer. This latter solution lowers the export bandwidth requirement, saving four bytes per timestamp, while increasing the load on the Exporter, as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message.
特定の時間関連の情報要素は、このエクスポート時間からのオフセットとして表現される場合があります。たとえば、マイクロ秒の精度を必要とするデータレコードは、フローの開始時間と終了時間をflowStartMicrosecondsとflowEndMicroseconds情報要素でエクスポートできます。これらの情報要素は、1900年1月1日1900年1月1日00:00 UTCの絶対時間をマイクロ秒単位でエンコードします。 64ビットフィールド。別の解決策は、データレコード内のflowStartDeltaMicrosecondsおよびflowEndDeltaMicroseconds情報要素をエクスポートすることです。これらの情報要素はそれぞれ、フロー開始時間と終了時間をエクスポート時間からの負のオフセットとして、符号なし32ビット整数として報告します。この後者のソリューションでは、エクスポート帯域幅の要件を下げ、タイムスタンプごとに4バイトを節約すると同時に、エクスポーターの負荷を増やします。これは、エクスポートプロセスがIPFIXメッセージをエクスポートする前に、すべての単一のデータレコードのflowStartDeltaMicrosecondsとflowEndDeltaMicrosecondsを計算する必要があるためです。
It must be noted that timestamps based on the Export Time impose some time constraints on the Data Records contained within the IPFIX Message. In the example of flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements, the Data Record can only contain records with timestamps within 71 minutes of the Export Time. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset.
エクスポート時間に基づくタイムスタンプは、IPFIXメッセージ内に含まれるデータレコードに時間制限を課すことに注意する必要があります。 flowStartDeltaMicrosecondsおよびflowEndDeltaMicroseconds情報要素の例では、データレコードには、エクスポート時刻から71分以内のタイムスタンプを持つレコードのみを含めることができます。それ以外の場合、32ビットカウンターはフロー開始時間オフセットを含めるのに十分ではありません。
The dateTimeSeconds abstract data type [RFC7012] and the Export Time Message Header field (Section 3.1) are encoded as 32-bit unsigned integers, expressed as seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. These values will wrap around on 7 February 2106 at 06:28:16 UTC.
dateTimeSeconds抽象データ型[RFC7012]およびエクスポート時刻メッセージヘッダーフィールド（セクション3.1）は、[POSIXで定義されているように、UNIXエポック、1970年1月1日00:00 UTCからの秒数として表される32ビット符号なし整数としてエンコードされます。 .1]。これらの値は、2106年2月7日のUTC 06:28:16にラップアラウンドします。
In order to support continued use of the IPFIX protocol beyond this date, Exporting Processes SHOULD export dateTimeSeconds values and the Export Time Message Header field as the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting Processes SHOULD use the current date, or other contextual information, to properly interpret dateTimeSeconds values and the Export Time Message Header field.
この日付を超えてIPFIXプロトコルの継続的な使用をサポートするために、エクスポートプロセスは、dateTimeSeconds値とエクスポート時間メッセージヘッダーフィールドを、UNIXエポック、1970年1月1日00:00 UTC、モジュロ2 ^ 32からの秒数としてエクスポートする必要があります（SHOULD）。 。プロセスの収集では、現在の日付またはその他のコンテキスト情報を使用して、dateTimeSeconds値とExport Time Message Headerフィールドを適切に解釈する必要があります（SHOULD）。
There are similar considerations for the NTP-based dateTimeMicroseconds and dateTimeNanoseconds abstract data types [RFC7012]. Exporting Processes SHOULD export dateTimeMicroseconds and dateTimeNanoseconds values as if the NTP era [RFC5905] is implicit; Collecting Processes SHOULD use the current date, or other contextual information, to determine the NTP era in order to properly interpret dateTimeMicroseconds and dateTimeNanoseconds values in received Data Records.
NTPベースのdateTimeMicrosecondsおよびdateTimeNanoseconds抽象データ型[RFC7012]についても同様の考慮事項があります。プロセスのエクスポートは、NTP時代[RFC5905]が暗黙的であるかのように、dateTimeMicrosecondsとdateTimeNanosecondsの値をエクスポートする必要があります（SHOULD）。収集プロセスは、受信したデータレコードのdateTimeMicrosecondsとdateTimeNanosecondsの値を正しく解釈するために、現在の日付またはその他のコンテキスト情報を使用してNTPの時代を特定する必要があります（SHOULD）。
The dateTimeMilliseconds abstract data type will wrap around in approximately 500 billion years; the specification of the behavior of this abstract data type after that time is left as a subject of a future revision of this specification.
dateTimeMilliseconds抽象データ型は約5,000億年で循環します。それ以降のこの抽象データ型の動作の仕様は、この仕様の将来の改訂の対象として残されます。
The long-term storage of files [RFC5655] for archival purposes is affected by timestamp wraparound, as the use of the current date to interpret timestamp values in files stored on the order of multiple decades in the past may lead to incorrect values; therefore, it is RECOMMENDED that such files be stored with contextual information to assist in the interpretation of these timestamps.
過去数十年のオーダーで保存されたファイルのタイムスタンプ値を解釈するために現在の日付を使用すると誤った値になる可能性があるため、アーカイブ目的でのファイルの長期保存[RFC5655]はタイムスタンプラップアラウンドの影響を受けます。したがって、これらのタイムスタンプの解釈を支援するために、そのようなファイルをコンテキスト情報とともに保存することをお勧めします。
As with values in the IPFIX Message Header and Set Header, values of all Information Elements [RFC7012], except for those of the string and octetArray data types, are encoded in canonical format in network byte order (also known as big-endian byte ordering).
IPFIXメッセージヘッダーとセットヘッダーの値と同様に、文字列とoctetArrayデータ型の値を除くすべての情報要素[RFC7012]の値は、ネットワークバイトオーダー（ビッグエンディアンバイトオーダーとも呼ばれます）の正規形式でエンコードされます。 ）。
The following sections define the encoding of the data types specified in [RFC7012].
以下のセクションでは、[RFC7012]で指定されているデータ型のエンコーディングを定義します。
Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 -- MUST be encoded using the default canonical format in network byte order. Signed integral data types are represented in two's complement notation.
整数データ型-unsigned8、unsigned16、unsigned32、unsigned64、signed8、signed16、signed32、signed64-は、ネットワークバイトオーダーのデフォルトの標準形式を使用してエンコードする必要があります。符号付き整数データ型は、2の補数表記で表されます。
Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types, as six, four, and sixteen octets in network byte order, respectively.
アドレスタイプ-macAddress、ipv4Address、およびipv6Address-は、整数データタイプと同じ方法で、それぞれネットワークバイトオーダーで6、4、および16オクテットとしてエンコードする必要があります。
The float32 data type MUST be encoded as an IEEE binary32 floating point type as specified in [IEEE.754.2008], in network byte order as specified in Section 3.6 of [RFC1014]. Note that on little-endian machines, byte swapping of the native representation is necessary before export. Note that the method for doing this may be implementation platform dependent.
float32データ型は、[IEEE.754.2008]で指定されているIEEEバイナリ32浮動小数点型として、[RFC1014]のセクション3.6で指定されているネットワークバイト順でエンコードする必要があります。リトルエンディアンマシンでは、エクスポートする前にネイティブ表現のバイトスワッピングが必要です。これを行う方法は、実装プラットフォームに依存する場合があることに注意してください。
The float64 data type MUST be encoded as an IEEE binary64 floating point type as specified in [IEEE.754.2008], in network byte order as specified in Section 3.7 of [RFC1014]. Note that on little-endian machines, byte swapping of the native representation is necessary before export. Note that the method for doing this may be implementation platform dependent.
float64データ型は、[IEEE.754.2008]で指定されているIEEEバイナリ64浮動小数点型として、[RFC1014]のセクション3.7で指定されているネットワークバイト順でエンコードする必要があります。リトルエンディアンマシンでは、エクスポートする前にネイティブ表現のバイトスワッピングが必要です。これを行う方法は、実装プラットフォームに依存する場合があることに注意してください。
The boolean data type is specified according to the TruthValue in [RFC2579]. It is encoded as a single-octet integer per Section 6.1.1, with the value 1 for true and value 2 for false. Every other value is undefined.
ブールデータ型は、[RFC2579]のTruthValueに従って指定されます。これは、セクション6.1.1に従って1オクテットの整数としてエンコードされ、値がtrueの場合は値1、falseの場合は値2になります。他のすべての値は未定義です。
The "string" data type represents a finite-length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 [RFC3629] format. The string is sent as an array of zero or more octets using an Information Element of fixed or variable length. IPFIX Exporting Processes MUST NOT send IPFIX Messages containing ill-formed UTF-8 string values for Information Elements of the string data type; Collecting Processes SHOULD detect and ignore such values. See [UTF8-EXPLOIT] for background on this issue.
「string」データ型は、Unicode文字エンコーディングセットの有効な文字の有限長の文字列を表します。文字列データ型は、UTF-8 [RFC3629]形式でエンコードする必要があります。文字列は、固定長または可変長の情報要素を使用して、0個以上のオクテットの配列として送信されます。 IPFIXエクスポートプロセスは、文字列データ型の情報要素の不正な形式のUTF-8文字列値を含むIPFIXメッセージを送信してはなりません（MUST NOT）。収集プロセスは、そのような値を検出して無視する必要があります。この問題の背景については、[UTF8-EXPLOIT]を参照してください。
The octetArray data type has no encoding rules; it represents a raw array of zero or more octets, with the interpretation of the octets defined in the Information Element definition.
octetArrayデータ型にはエンコード規則がありません。情報要素の定義で定義されたオクテットの解釈とともに、0個以上のオクテットの生の配列を表します。
The dateTimeSeconds data type is an unsigned 32-bit integer in network byte order containing the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. dateTimeSeconds is encoded identically to the IPFIX Message Header Export Time field. It can represent dates between 1 January 1970 and 7 February 2106 without wraparound; see Section 5.2 for wraparound considerations.
dateTimeSecondsデータ型は、[POSIX.1]で定義されているように、UNIXエポック、1970年1月1日00:00 UTCからの秒数を含むネットワークバイトオーダーの符号なし32ビット整数です。 dateTimeSecondsは、IPFIXメッセージヘッダーエクスポート時間フィールドと同じようにエンコードされます。 1970年1月1日から2106年2月7日までの日付をラップアラウンドなしで表すことができます。ラップアラウンドの考慮事項については、セクション5.2を参照してください。
The dateTimeMilliseconds data type is an unsigned 64-bit integer in network byte order containing the number of milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It can represent dates beginning on 1 January 1970 and for approximately the next 500 billion years without wraparound.
[POSIX.1]で定義されているように、dateTimeMillisecondsデータ型は、UNIXバイトの1970年1月1日00:00 UTCからのミリ秒数を含むネットワークバイトオーダーの符号なし64ビット整数です。これは、1970年1月1日から始まり、約5,000億年にわたるラップアラウンドなしの日付を表すことができます。
The dateTimeMicroseconds data type is a 64-bit field encoded according to the NTP Timestamp format as defined in Section 6 of [RFC5905]. This field is made up of two unsigned 32-bit integers in network byte order: Seconds and Fraction. The Seconds field is the number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC.
dateTimeMicrosecondsデータ型は、[RFC5905]のセクション6で定義されているNTPタイムスタンプ形式に従ってエンコードされた64ビットのフィールドです。このフィールドは、ネットワークバイトオーダーの2つの符号なし32ビット整数（秒と分数）で構成されています。 Secondsフィールドは、NTPエポック、1900年1月1日、UTC 00:00からの秒数です。
The Fraction field is the fractional number of seconds in units of 1/(2^32) seconds (approximately 233 picoseconds). It can represent dates between 1 January 1900 and 8 February 2036 in the current NTP era; see Section 5.2 for wraparound considerations.
Fractionフィールドは、1 /（2 ^ 32）秒（約233ピコ秒）を単位とする秒の小数です。現在のNTP時代における1900年1月1日から2036年2月8日までの日付を表すことができます。ラップアラウンドの考慮事項については、セクション5.2を参照してください。
Note that dateTimeMicroseconds and dateTimeNanoseconds share an identical encoding. The dateTimeMicroseconds data type is intended only to represent timestamps of microsecond precision. Therefore, the bottom 11 bits of the Fraction field SHOULD be zero and MUST be ignored for all Information Elements of this data type (as 2^11 x 233 picoseconds = .477 microseconds).
dateTimeMicrosecondsとdateTimeNanosecondsは同じエンコーディングを共有することに注意してください。 dateTimeMicrosecondsデータ型は、マイクロ秒精度のタイムスタンプを表すことのみを目的としています。したがって、分数フィールドの下位11ビットはゼロである必要があり（SHOULD）、このデータ型のすべての情報要素（2 ^ 11 x 233ピコ秒= .477マイクロ秒）では無視する必要があります。
The dateTimeNanoseconds data type is a 64-bit field encoded according to the NTP Timestamp format as defined in Section 6 of [RFC5905]. This field is made up of two unsigned 32-bit integers in network byte order: Seconds and Fraction. The Seconds field is the number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The Fraction field is the fractional number of seconds in units of 1/(2^32) seconds (approximately 233 picoseconds). It can represent dates between 1 January 1900 and 8 February 2036 in the current NTP era; see Section 5.2 for wraparound considerations.
dateTimeNanosecondsデータ型は、[RFC5905]のセクション6で定義されているNTPタイムスタンプ形式に従ってエンコードされた64ビットのフィールドです。このフィールドは、ネットワークバイトオーダーの2つの符号なし32ビット整数（秒と分数）で構成されています。 Secondsフィールドは、NTPエポック、1900年1月1日、UTC 00:00からの秒数です。 Fractionフィールドは、1 /（2 ^ 32）秒（約233ピコ秒）を単位とする秒の小数です。現在のNTP時代における1900年1月1日から2036年2月8日までの日付を表すことができます。ラップアラウンドの考慮事項については、セクション5.2を参照してください。
Note that dateTimeMicroseconds and dateTimeNanoseconds share an identical encoding. There is no restriction on the interpretation of the Fraction field for the dateTimeNanoseconds data type.
dateTimeMicrosecondsとdateTimeNanosecondsは同じエンコーディングを共有することに注意してください。 dateTimeNanosecondsデータ型のFractionフィールドの解釈に制限はありません。
Information Elements encoded as signed, unsigned, or float data types MAY be encoded using fewer octets than those implied by their type in the information model definition, based on the assumption that the smaller size is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [IANA-IPFIX] always define the maximum encoding size.
符号付き、符号なし、または浮動小数点データ型としてエンコードされた情報要素は、より小さなサイズでエクスポーターが提供する必要のある値を運ぶのに十分であるという仮定に基づいて、情報モデル定義のタイプによって暗示されるよりも少ないオクテットを使用してエンコードされる場合があります。これにより、エクスポーターとコレクター間のネットワーク帯域幅要件が軽減されます。情報要素の定義[IANA-IPFIX]は常に最大エンコードサイズを定義することに注意してください。
For instance, the information model defines octetDeltaCount as an unsigned64 type, which would require 64 bits. However, if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may choose to send the value as unsigned32 instead.
たとえば、情報モデルはoctetDeltaCountをunsigned64タイプとして定義します。これには64ビットが必要です。ただし、エクスポーターが4294967295より大きい値を送信する必要がローカルで発生しない場合は、代わりにunsigned32として値を送信することを選択できます。
This behavior is indicated by the Exporter by specifying a size in the Template with a smaller length than that associated with the assigned type of the Information Element. In the example above, the Exporter would place a length of 4 versus 8 in the Template.
この動作は、割り当てられたタイプの情報要素に関連付けられているサイズよりも短い長さのテンプレートのサイズを指定することにより、エクスポーターによって示されます。上記の例では、エクスポーターはテンプレートに8対8の長さを配置します。
Reduced-size encoding MAY be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The signed versus unsigned property of the reported value MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e., so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
縮小サイズのエンコーディングは、次の整数型に適用される場合があります：unsigned64、signed64、unsigned32、signed32、unsigned16、signed16。レポートされた値の署名されたプロパティと署名されていないプロパティを保持する必要があります。データ値が依然として適合している場合、つまり、先行ゼロのみが削除される場合、サイズの削減は、元のタイプよりも小さい任意の数のオクテットにすることができます。たとえば、unsigned64は、サイズを7、6、5、4、3、2、または1オクテットに縮小できます。
Reduced-size encoding MAY be used to reduce float64 to float32. The float32 not only has a reduced number range but, due to the smaller mantissa, is also less precise. In this case, the float64 would be reduced in size to 4 octets.
float64をfloat32に減らすために、縮小サイズのエンコーディングを使用できます（MAY）。 float32は数値範囲が減少するだけでなく、仮数が小さいため、精度も低くなります。この場合、float64のサイズは4オクテットに縮小されます。
Reduced-size encoding MUST NOT be applied to any other data type defined in [RFC7012] that implies a fixed length, as these types either have internal structure (such as ipv4Address or dateTimeMicroseconds) or restricted ranges that are not suitable for reduced-size encoding (such as dateTimeMilliseconds).
固定長を意味する[RFC7012]で定義されている他のデータ型には、縮小サイズエンコーディングを適用しないでください。これらのタイプは、内部構造（ipv4AddressやdateTimeMicrosecondsなど）または縮小サイズエンコーディングに適さない制限付き範囲を持っているためです（dateTimeMillisecondsなど）。
Information Elements of type octetArray and string may be exported using any length, subject to restrictions on length specific to each Information Element, as noted in that Information Element's description.
タイプ情報octetArrayおよび文字列の情報要素は、その情報要素の説明に記載されているように、各情報要素に固有の長さに関する制限に従い、任意の長さを使用してエクスポートできます。
The IPFIX Template mechanism is optimized for fixed-length Information Elements [RFC7012]. Where an Information Element has a variable length, the following mechanism MUST be used to carry the length information for both the IANA-assigned and enterprise-specific Information Elements.
IPFIXテンプレートメカニズムは、固定長の情報要素[RFC7012]向けに最適化されています。情報要素が可変長である場合、次のメカニズムを使用して、IANAが割り当てた情報要素と企業固有の情報要素の両方の長さ情報を運ぶ必要があります。
In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself.
テンプレートセットでは、情報要素フィールドの長さが65535として記録されます。この予約された長さの値は、情報要素の長さの値が情報要素のコンテンツ自体に含まれることを収集プロセスに通知します。
In most cases, the length of the Information Element will be less than 255 octets. The following length-encoding mechanism optimizes the overhead of carrying the Information Element length in this more common case. The length is carried in the octet before the Information Element, as shown in Figure R.
ほとんどの場合、情報要素の長さは255オクテット未満です。次の長さエンコーディングメカニズムは、このより一般的なケースで情報要素の長さを運ぶオーバーヘッドを最適化します。図Rに示すように、長さは情報要素の前のオクテットで運ばれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure R: Variable-Length Information Element (IE) (Length < 255 Octets)
図R：可変長情報要素（IE）（長さ<255オクテット）
The length may also be encoded into 3 octets before the Information Element, allowing the length of the Information Element to be greater than or equal to 255 octets. In this case, the first octet of the Length field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S.
長さは、情報要素の前に3オクテットにエンコードすることもでき、情報要素の長さを255オクテット以上にすることができます。この場合、図Sに示すように、長さフィールドの最初のオクテットは255でなければならず、長さは2番目と3番目のオクテットで運ばれます。
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 | Length (0 to 65535) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure S: Variable-Length Information Element (IE) (Length 0 to 65535 Octets)
図S：可変長情報要素（IE）（長さ0〜65535オクテット）
The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Element.
長さを運ぶオクテット（最初または最初の3つのオクテットのいずれか）は、情報要素の長さに含めてはならない（MUST NOT）。
This section describes the management of Templates and Options Templates at the Exporting and Collecting Processes. The goal of Template management is to ensure, to the extent possible, that the Exporting Process and Collecting Process have a consistent view of the Templates and Options Templates used to encode and decode the Records sent from the Exporting Process to the Collecting Process.
このセクションでは、エクスポートおよび収集プロセスでのテンプレートおよびオプションテンプレートの管理について説明します。テンプレート管理の目的は、エクスポートプロセスと収集プロセスが、エクスポートプロセスから収集プロセスに送信されるレコードをエンコードおよびデコードするために使用されるテンプレートとオプションテンプレートの一貫したビューを確実に持つようにすることです。
Achieving this goal is complicated somewhat by two factors: 1) the need to support the reuse of Template IDs within a Transport Session and 2) the need to support unreliable transmission for Templates when UDP is used as the transport protocol for IPFIX Messages.
この目標の達成は、2つの要因によってやや複雑になります。1）トランスポートセッション内でのテンプレートIDの再利用をサポートする必要性、および2）IPFIXメッセージのトランスポートプロトコルとしてUDPを使用する場合に、テンプレートの信頼できない送信をサポートする必要性。
The Template Management mechanisms defined in this section apply to the export of IPFIX Messages on SCTP, TCP, or UDP. Additional considerations specific to SCTP and UDP transport are given in Sections 8.3 and 8.4, respectively.
このセクションで定義されているテンプレート管理メカニズムは、SCTP、TCP、またはUDPでのIPFIXメッセージのエクスポートに適用されます。 SCTPおよびUDPトランスポートに固有の追加の考慮事項は、それぞれセクション8.3および8.4に記載されています。
The Exporting Process assigns and maintains Template IDs per Transport Session and Observation Domain. A newly created Template Record is assigned an unused Template ID by the Exporting Process. The Collecting Process MUST store all received Template Record information for the duration of each Transport Session until reuse or withdrawal as described in Section 8.1, or expiry over UDP as described in Section 8.4, so that it can interpret the corresponding Data Records.
エクスポートプロセスは、トランスポートセッションおよび観測ドメインごとにテンプレートIDを割り当て、維持します。新しく作成されたテンプレートレコードには、エクスポートプロセスによって未使用のテンプレートIDが割り当てられます。収集プロセスは、8.1で説明されているように再利用または撤回されるまで、または8.4で説明されているようにUDPで期限切れになるまで、各トランスポートセッションの間、受信したすべてのテンプレートレコード情報を保存する必要があります。これにより、対応するデータレコードを解釈できます。
The Collecting Process MUST NOT assume that the Template IDs from a given Exporting Process refer to the same Templates as they did in previous Transport Sessions from the same Exporting Process; a Collecting Process MUST NOT use Templates from one Transport Session to decode Data Sets in a subsequent Transport Session.
収集プロセスは、特定のエクスポートプロセスからのテンプレートIDが、同じエクスポートプロセスからの以前のトランスポートセッションと同じテンプレートを参照していると想定してはなりません（MUST NOT）。収集プロセスは、1つのトランスポートセッションのテンプレートを使用して、後続のトランスポートセッションのデータセットをデコードしてはなりません（MUST NOT）。
If a specific Information Element is required by a Template but is not present in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record described by a new Template.
特定の情報要素がテンプレートに必要であるが、監視対象のパケットに存在しない場合、エクスポートプロセスは、新しいテンプレートで記述されたデータレコードにこの情報要素がないフローレコードをエクスポートすることを選択できます。
If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value should belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the address of the inner header. Collecting Processes MUST properly handle Templates with multiple identical Information Elements.
テンプレートで情報要素が2回以上必要な場合、この情報要素の異なる出現は、メータリングプロセスによる処理の論理的な順序に従う必要があります。たとえば、選択したパケットが2つのハッシュ関数を通過し、2つのハッシュ値が単一のテンプレート内で送信される場合、最初のハッシュ値は、メータリングプロセスの最初のハッシュ関数に属している必要があります。たとえば、IPv4-in-IPv4パケットの2つのソースIPアドレスをエクスポートする場合、最初のsourceIPv4Address Information Elementオカレンスは外部ヘッダーのIPv4アドレスでなければならず、2番目のオカレンスは内部ヘッダーのアドレスでなければなりません。収集プロセスは、複数の同一の情報要素を持つテンプレートを適切に処理する必要があります。
The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record. Data Records that correspond to a Template Record MAY appear in the same and/or subsequent IPFIX Message(s). However, a Collecting Process MUST NOT assume that the Data Set and the associated Template Set (or Options Template Set) are exported in the same IPFIX Message.
エクスポートプロセスは、その（オプション）テンプレートIDを使用するデータセットの前にテンプレートセットとオプションテンプレートセットを送信して、最初のデータレコードを受信する前にコレクタがテンプレートレコードを確実に持つようにする必要があります（SHOULD）。テンプレートレコードに対応するデータレコードは、同じまたは後続のIPFIXメッセージに表示される場合があります。ただし、収集プロセスでは、データセットと関連するテンプレートセット（またはオプションテンプレートセット）が同じIPFIXメッセージでエクスポートされると想定してはなりません（MUST NOT）。
Though a Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records, this is not always the case, e.g., in the case of reordering or Collecting Process restart over UDP. In these cases, the Collecting Process MAY buffer Data Records for which it has no Templates, to wait for Template Records describing them; however, note that in the presence of Template withdrawal and redefinition (Section 8.1) this may lead to incorrect interpretation of Data Records.
収集プロセスは通常、データレコードを受信する前にエクスポートプロセスからテンプレートレコードを受信しますが、これは、UDPを介して並べ替えや収集プロセスを再起動する場合など、常にそうとは限りません。これらの場合、収集プロセスは、テンプレートがないデータレコードをバッファリングして、テンプレートレコードがそれらを記述するのを待つことができます。ただし、テンプレートの撤回および再定義（セクション8.1）があると、データレコードが正しく解釈されない可能性があることに注意してください。
Different Observation Domains within a Transport Session MAY use the same Template ID value to refer to different Templates; Collecting Processes MUST properly handle this case.
トランスポートセッション内の異なる観測ドメインは、同じテンプレートID値を使用して異なるテンプレートを参照する場合があります。収集プロセスは、このケースを適切に処理する必要があります。
Options Templates and Templates that are related or interdependent (e.g., by sharing common properties as described in [RFC5473]) SHOULD be sent together in the same IPFIX Message.
オプションテンプレートおよび関連または相互依存するテンプレート（[RFC5473]で説明されている共通のプロパティを共有するなど）は、同じIPFIXメッセージで一緒に送信する必要があります（SHOULD）。
Templates that will not be used further by an Exporting Process MAY be withdrawn by sending a Template Withdrawal. After receiving a Template Withdrawal, a Collecting Process MUST stop using the Template to interpret subsequently exported Data Sets. Note that this mechanism does not apply when UDP is used to transport IPFIX Messages; for that case, see Section 8.4.
エクスポートプロセスでこれ以上使用されないテンプレートは、テンプレート撤回を送信することで撤回される場合があります。テンプレートの撤回を受け取った後、収集プロセスは、その後にエクスポートされたデータセットを解釈するためにテンプレートの使用を停止する必要があります。 UDPを使用してIPFIXメッセージを転送する場合、このメカニズムは適用されないことに注意してください。その場合は、8.4項を参照してください。
A Template Withdrawal consists of a Template Record for the Template ID to be withdrawn, with a Field Count of 0. The format of a Template Withdrawal is shown in Figure T.
テンプレートの撤回は、撤回されるテンプレートIDのテンプレートレコードで構成され、フィールド数は0です。テンプレートの撤回の形式を図Tに示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = (2 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure T: Template Withdrawal Format
図T：テンプレートの引き出し形式
The Set ID field MUST contain the value 2 for Template Set Withdrawal or the value 3 for Options Template Set Withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal; in that case, padding MAY be used.
セットIDフィールドには、テンプレートセットの取り消しの値2またはオプションテンプレートセットの取り消しの値3を含める必要があります。複数のテンプレートIDは、1回のテンプレートの取り消しで取り消すことができます。その場合、パディングが使用される場合があります。
Template Withdrawals MAY appear interleaved with Template Sets, Options Template Sets, and Data Sets within an IPFIX Message. In this case, the Templates and Template Withdrawals shall be interpreted as taking effect in the order in which they appear in the IPFIX Message. An Exporting Process SHOULD NOT send a Template Withdrawal until sufficient time has elapsed to allow receipt and processing of any Data Records described by the withdrawn Templates; see Section 8.2 for details regarding the sequencing of Template management actions.
テンプレートの引き出しは、IPFIXメッセージ内のテンプレートセット、オプションテンプレートセット、およびデータセットと交互に表示される場合があります。この場合、テンプレートとテンプレートの引き出しは、IPFIXメッセージに表示される順序で有効になると解釈されます。エクスポートプロセスは、撤回されたテンプレートによって記述されたデータレコードの受信と処理を可能にするのに十分な時間が経過するまで、テンプレートの撤回を送信しないでください。テンプレート管理アクションのシーケンスに関する詳細については、セクション8.2を参照してください。
The end of a Transport Session implicitly withdraws all the Templates used within the Transport Session, and Templates must be resent during subsequent Transport Sessions between an Exporting Process and Collecting Process. This applies to SCTP and TCP only; see Sections 8.4 and 10.3.4 for discussions of Transport Session and Template lifetime over UDP.
トランスポートセッションの終了により、トランスポートセッション内で使用されているすべてのテンプレートが暗黙的に取り消されます。テンプレートは、エクスポートプロセスと収集プロセスの間の後続のトランスポートセッション中に再送信する必要があります。これはSCTPとTCPにのみ適用されます。 UDPでのトランスポートセッションとテンプレートの有効期間については、セクション8.4および10.3.4を参照してください。
All Templates for a given Observation Domain MAY also be withdrawn using an All Templates Withdrawal, as shown in Figure U. All Options Templates for a given Observation Domain MAY likewise be withdrawn using an All Options Templates Withdrawal, as shown in Figure V.
与えられた観測ドメインのすべてのテンプレートは、図Uに示すように、すべてのテンプレート撤回を使用して撤回することもできます。特定の観測ドメインのすべてのオプションテンプレートは、図Vに示すように、全オプションテンプレート撤回を使用して撤回することもできます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure U: All Templates Withdrawal Set Format
図U：すべてのテンプレートの引き出しセット形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 3 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure V: All Options Templates Withdrawal Set Format
図V：すべてのオプションテンプレートの引き出しセット形式
Template IDs MAY be reused for new Templates by sending a new Template Record or Options Template Record for a given Template ID after withdrawing the Template.
テンプレートを撤回した後、特定のテンプレートIDの新しいテンプレートレコードまたはオプションテンプレートレコードを送信することにより、テンプレートIDを新しいテンプレートに再利用できます。
If a Collecting Process receives a Template Withdrawal for a Template or Options Template it does not presently have stored, this indicates a malfunctioning or improperly implemented Exporting Process. The continued receipt and interpretation of Data Records are still possible, but the Collecting Process MUST ignore the Template Withdrawal and SHOULD log the error.
収集プロセスが、現在保存していないテンプレートまたはオプションテンプレートのテンプレート撤回を受け取った場合、これは、誤動作しているか、不適切に実装されたエクスポートプロセスを示しています。データレコードの継続的な受信と解釈は引き続き可能ですが、収集プロセスはテンプレートの引き出しを無視し、エラーを記録する必要があります（SHOULD）。
If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, and that Template or Options Template is identical to the already-received Template or Options Template, it SHOULD log the retransmission; however, this is not an error condition, as it does not affect the interpretation of Data Records.
収集プロセスが、既に割り当てられているテンプレートIDの新しいテンプレートレコードまたはオプションテンプレートレコードを受信し、そのテンプレートまたはオプションテンプレートが、既に受信したテンプレートまたはオプションテンプレートと同一である場合、再送信をログに記録する必要があります。ただし、データレコードの解釈には影響しないため、これはエラー状態ではありません。
If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, and that Template or Options Template is different from the already-received Template or Options Template, this indicates a malfunctioning or improperly implemented Exporting Process. The continued receipt and unambiguous interpretation of Data Records for this Template ID are no longer possible, and the Collecting Process SHOULD log the error. Further Collecting Process actions are out of scope for this specification.
収集プロセスが、既に割り当てられているテンプレートIDの新しいテンプレートレコードまたはオプションテンプレートレコードを受け取り、そのテンプレートまたはオプションテンプレートが、すでに受け取ったテンプレートまたはオプションテンプレートと異なる場合、これは、誤動作しているか、不適切に実装されたエクスポートプロセスを示しています。このテンプレートIDのデータレコードの継続的な受信と明確な解釈はもはや不可能であり、収集プロセスはエラーをログに記録する必要があります（SHOULD）。これ以上の収集プロセスアクションは、この仕様の範囲外です。
Since there is no guarantee of the ordering of exported IPFIX Messages across SCTP Streams or over UDP, an Exporting Process MUST sequence all Template management actions (i.e., Template Records defining new Templates and Template Withdrawals withdrawing them) using the Export Time field in the IPFIX Message Header.
SCTPストリームまたはUDPを介してエクスポートされたIPFIXメッセージの順序の保証がないため、エクスポートプロセスは、IPFIXのエクスポート時間フィールドを使用して、すべてのテンプレート管理アクション（つまり、新しいテンプレートを定義するテンプレートレコードとそれらを撤回するテンプレート撤回）をシーケンスする必要があります。メッセージヘッダー。
An Exporting Process MUST NOT export a Data Set described by a new Template in an IPFIX Message with an Export Time before the Export Time of the IPFIX Message containing that Template. If a new Template and a Data Set described by it appear in the same IPFIX Message, the Template Set containing the Template MUST appear before the Data Set in the Message.
エクスポートプロセスは、そのテンプレートを含むIPFIXメッセージのエクスポート時刻より前のエクスポート時刻を持つIPFIXメッセージの新しいテンプレートによって記述されたデータセットをエクスポートしてはなりません（MUST NOT）。新しいテンプレートとそれによって記述されたデータセットが同じIPFIXメッセージに表示される場合、テンプレートを含むテンプレートセットは、メッセージのデータセットの前に表示される必要があります。
An Exporting Process MUST NOT export any Data Sets described by a withdrawn Template in IPFIX Messages with an Export Time after the Export Time of the IPFIX Message containing the Template Withdrawal withdrawing that Template.
エクスポートプロセスは、IPFIXメッセージ内の撤回されたテンプレートによって記述されたデータセットを、そのテンプレートを撤回するテンプレート撤回を含むIPFIXメッセージのエクスポート時刻より後のエクスポート時刻でエクスポートしてはなりません（MUST NOT）。
Put another way, a Template describes Data Records contained in IPFIX Messages when the Export Time of such messages is between a specific start and end time, inclusive. The start time is the Export Time of the IPFIX Message containing the Template Record. The end time is one of two times: if the template is withdrawn during the session, then it is the Export Time of the IPFIX Message containing the Template Withdrawal for the template; otherwise, it is the end of the Transport Session.
言い換えると、テンプレートは、そのようなメッセージのエクスポート時間が特定の開始時間と終了時間の間にある場合に、IPFIXメッセージに含まれるデータレコードを記述します。開始時間は、テンプレートレコードを含むIPFIXメッセージのエクスポート時間です。終了時間は2回のうちの1つです。セッション中にテンプレートが撤回された場合、それはテンプレートのテンプレート撤回を含むIPFIXメッセージのエクスポート時間です。それ以外の場合は、トランスポートセッションの終了です。
Even if sent in order, IPFIX Messages containing Template management actions could arrive at the Collecting Process out of order, i.e., if sent via UDP or via different SCTP Streams. Given this, Template Withdrawals and subsequent reuse of Template IDs can significantly complicate the problem of determining Template lifetimes at the Collecting Process. A Collecting Process MAY implement a buffer and use Export Time information to disambiguate the order of Template management actions. This buffer, if implemented, SHOULD be configurable to impart a delay on the order of the maximum reordering delay experienced at the Collecting Process. Note, in this case, that the Collecting Process's clock is irrelevant: it is only comparing the Export Times of Messages to each other.
順序どおりに送信された場合でも、テンプレート管理アクションを含むIPFIXメッセージは、UDPまたは異なるSCTPストリームを介して送信された場合、収集プロセスに順不同で到着する可能性があります。このため、テンプレートの引き出しとそれに続くテンプレートIDの再利用は、収集プロセスでのテンプレートの有効期間を決定する問題を非常に複雑にする可能性があります。収集プロセスは、バッファを実装し、エクスポート時間情報を使用して、テンプレート管理アクションの順序を明確にする場合があります。このバッファーは、実装されている場合、収集プロセスで発生する最大の並べ替え遅延のオーダーに遅延を与えるように構成可能である必要があります（SHOULD）。この場合、収集プロセスのクロックは無関係であることに注意してください。これは、メッセージのエクスポート時間を互いに比較するだけです。
The specifications in this section apply only to SCTP; in cases of contradiction with specifications in Section 8 or Section 8.1, this section takes precedence.
このセクションの仕様はSCTPにのみ適用されます。セクション8またはセクション8.1の仕様と矛盾する場合は、このセクションが優先されます。
Template Sets and Options Template Sets MAY be sent on any SCTP Stream. Data Sets sent on a given SCTP Stream MAY be represented by Template Records exported on any SCTP Stream.
テンプレートセットとオプションテンプレートセットは、任意のSCTPストリームで送信できます。特定のSCTPストリームで送信されたデータセットは、任意のSCTPストリームでエクスポートされたテンプレートレコードによって表される場合があります。
Template Sets and Options Template Sets MUST be sent reliably, using SCTP ordered delivery.
テンプレートセットとオプションテンプレートセットは、SCTPの順序付き配信を使用して確実に送信する必要があります。
Template Withdrawals MAY be sent on any SCTP Stream. Template Withdrawals MUST be sent reliably, using SCTP ordered delivery. Template IDs MAY be reused by sending a Template Withdrawal and/or a new Template Record on a different SCTP Stream than the stream on which the original Template was sent.
テンプレートの引き出しは、任意のSCTPストリームで送信できます（MAY）。テンプレートの引き出しは、SCTPの順序付き配信を使用して、確実に送信する必要があります。テンプレートIDは、元のテンプレートが送信されたストリームとは異なるSCTPストリームでテンプレート撤回または新しいテンプレートレコード、あるいはその両方を送信することによって再利用できます。
Additional Template Management considerations are provided in [RFC6526], which specifies an extension to explicitly link Templates with SCTP Streams. In exchange for more restrictive rules on the assignment of Template Records to SCTP Streams, this extension allows fast, reliable reuse of Template IDs and estimation of Data Record loss per Template.
[RFC6526]では、テンプレート管理に関する追加の考慮事項が提供されており、テンプレートとSCTPストリームを明示的にリンクするための拡張が指定されています。 SCTPストリームへのテンプレートレコードの割り当てに関するより制限的なルールと引き換えに、この拡張により、テンプレートIDの高速で信頼性の高い再利用と、テンプレートごとのデータレコード損失の推定が可能になります。
The specifications in this section apply only to UDP; in cases of contradiction with specifications in Section 8 or Section 8.1, this section takes precedence.
このセクションの仕様はUDPにのみ適用されます。セクション8またはセクション8.1の仕様と矛盾する場合は、このセクションが優先されます。
Since UDP provides no method for reliable transmission of Templates, Exporting Processes using UDP as the transport protocol MUST periodically retransmit each active Template at regular intervals. The Template retransmission interval MUST be configurable via, for example, the templateRefreshTimeout and optionsTemplateRefreshTimeout parameters as defined in [RFC6728]. Default settings for these values are deployment- and application-specific.
UDPはテンプレートを確実に送信する方法を提供しないため、トランスポートプロトコルとしてUDPを使用するエクスポートプロセスは、定期的に各アクティブなテンプレートを定期的に再送信する必要があります。テンプレートの再送信間隔は、たとえば、[RFC6728]で定義されているように、templateRefreshTimeoutおよびoptionsTemplateRefreshTimeoutパラメータを介して構成可能である必要があります。これらの値のデフォルト設定は、デプロイメントおよびアプリケーション固有です。
Before exporting any Data Records described by a given Template Record or Options Template Record, especially in the case of Template ID reuse as described in Section 8.1, the Exporting Process SHOULD send multiple copies of the Template Record in a separate IPFIX Message, in order to help ensure that the Collecting Process has received it.
特定のテンプレートレコードまたはオプションテンプレートレコードによって記述されたデータレコードをエクスポートする前に、特にセクション8.1で説明されているテンプレートIDの再利用の場合、エクスポートプロセスは、テンプレートレコードの複数のコピーを個別のIPFIXメッセージで送信する必要があります。収集プロセスがそれを受け取ったことを確認するのに役立ちます。
In order to minimize resource requirements for Templates that are no longer being used by the Exporting Process, the Collecting Process MAY associate a lifetime with each Template received in a Transport Session. Templates not refreshed by the Exporting Process within the lifetime can then be discarded by the Collecting Process. The Template lifetime at the Collecting Process MAY be exposed by a configuration parameter or MAY be derived from observation of the interval of periodic Template retransmissions from the Exporting Process. In this latter case, the Template lifetime SHOULD default to at least 3 times the observed retransmission rate.
エクスポートプロセスで使用されなくなったテンプレートのリソース要件を最小限に抑えるために、収集プロセスは、トランスポートセッションで受信した各テンプレートに有効期間を関連付けることができます（MAY）。存続期間内にエクスポートプロセスによって更新されなかったテンプレートは、収集プロセスによって破棄できます。収集プロセスでのテンプレートの有効期間は、構成パラメータによって公開される場合と、エクスポートプロセスからの定期的なテンプレート再送信の間隔の観察から導出される場合があります。後者の場合、テンプレートの有効期間はデフォルトで、観測された再送信率の少なくとも3倍にすべきです（SHOULD）。
Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting Processes exporting via UDP and MUST be ignored by Collecting Processes collecting via UDP. Template IDs MAY be reused by Exporting Processes by exporting a new Template for the Template ID after waiting at least 3 times the retransmission delay. Note that Template ID reuse may lead to incorrect interpretation of Data Records if the retransmission and lifetime are not properly configured.
テンプレートの引き出し（セクション8.1）は、UDPを介してエクスポートするエクスポートプロセスによって送信されてはならず、UDPを介して収集している収集プロセスによって無視されなければなりません。再送信遅延の3倍以上待機した後、テンプレートIDの新しいテンプレートをエクスポートすることにより、エクスポートプロセスでテンプレートIDを再利用できます。再送信とライフタイムが適切に設定されていないと、テンプレートIDの再利用によりデータレコードが正しく解釈されない可能性があることに注意してください。
When a Collecting Process receives a new Template Record or Options Template Record via UDP for an already-allocated Template ID, and that Template or Options Template is identical to the already-received Template or Options Template, it SHOULD NOT log the retransmission, as this is the normal operation of Template refresh over UDP.
収集プロセスが、すでに割り当てられているテンプレートIDのUDPを介して新しいテンプレートレコードまたはオプションテンプレートレコードを受信し、そのテンプレートまたはオプションテンプレートが、すでに受信したテンプレートまたはオプションテンプレートと同一である場合、再送信をログに記録しないでください。 UDPを介したテンプレート更新の通常の操作です。
When a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, and that Template or Options Template is different from the already-received Template or Options Template, the Collecting Process MUST replace the Template or Options Template for that Template ID with the newly received Template or Options Template. This is the normal operation of Template ID reuse over UDP.
収集プロセスが、すでに割り当てられているテンプレートIDの新しいテンプレートレコードまたはオプションテンプレートレコードを受け取り、そのテンプレートまたはオプションテンプレートが、すでに受け取ったテンプレートまたはオプションテンプレートと異なる場合、収集プロセスは、テンプレートまたはオプションテンプレートを置き換える必要があります。新しく受信したテンプレートまたはオプションテンプレートを含むそのテンプレートID。これは、UDPを介したテンプレートIDの再利用の通常の操作です。
As Template IDs are unique per UDP session and per Observation Domain, at any given time, the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template Records: <IPFIX Device, Exporter source UDP port, Collector IP address, Collector destination UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>.
テンプレートIDは、UDPセッションおよび観測ドメインごとに一意であるため、収集プロセスは、現在のすべてのテンプレートレコードおよびオプションテンプレートレコードについて、以下を維持する必要があります。<IPFIXデバイス、エクスポーターソースUDPポート、コレクターIPアドレス、コレクター宛先UDPポート、監視ドメインID、テンプレートID、テンプレート定義、最終受信>。
This section describes the handling of the IPFIX protocol at the Collecting Process common to all transport protocols. Additional considerations for SCTP and UDP are provided in Sections 9.2 and 9.3, respectively. Template management at Collecting Processes is covered in Section 8.
このセクションでは、すべてのトランスポートプロトコルに共通する収集プロセスでのIPFIXプロトコルの処理について説明します。 SCTPおよびUDPに関する追加の考慮事項は、それぞれセクション9.2および9.3に記載されています。収集プロセスでのテンプレート管理については、セクション8で説明します。
The Collecting Process MUST listen for association requests / connections to start new Transport Sessions from the Exporting Process.
収集プロセスは、関連付けリクエスト/接続をリッスンして、エクスポートプロセスから新しいトランスポートセッションを開始する必要があります。
The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from received Data Records.
収集プロセスは、理解できない情報要素の情報要素識別子に注意しなければならず、受信したデータレコードからその情報要素を破棄してもよい（MAY）。
The Collecting Process MUST accept padding in Data Records and Template Records. The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the minimum Record size deduced from the Template Record.
収集プロセスは、データレコードとテンプレートレコードのパディングを受け入れる必要があります。パディングサイズは、セット長からセットヘッダーのサイズ（セットIDとセット長の4オクテット）を引いたものであり、テンプレートレコードから推定される最小レコードサイズを法としています。
The IPFIX protocol has a Sequence Number field in the Export header that increases with the number of IPFIX Data Records in the IPFIX Message. A Collector can detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. A Collector SHOULD provide a logging mechanism for tracking out-of-sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be due to Exporter resource exhaustion where it cannot transmit messages at their creation rate, an Exporting Process reset, congestion on the network link between the Exporter and Collector, Collector resource exhaustion where it cannot process the IPFIX Messages at their arrival rate, out-of-order packet reception, duplicate packet reception, or an attacker injecting false messages.
IPFIXプロトコルには、エクスポートヘッダーにシーケンス番号フィールドがあり、IPFIXメッセージのIPFIXデータレコードの数とともに増加します。コレクターは、シーケンス番号を追跡することにより、シーケンス外、ドロップ、または重複のIPFIXメッセージを検出できます。コレクタは、シーケンス外のIPFIXメッセージを追跡するためのロギングメカニズムを提供する必要があります（SHOULD）。このようなシーケンス外のIPFIXメッセージは、作成レートでメッセージを送信できないエクスポーターリソースの枯渇、エクスポートプロセスのリセット、エクスポーターとコレクター間のネットワークリンクの輻輳、IPFIXを処理できないコレクターリソースの枯渇が原因である可能性があります。到着率のメッセージ、順序どおりでないパケット受信、重複パケット受信、または偽のメッセージを挿入する攻撃者。
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. A malformed IPFIX Message is one that cannot be interpreted due to nonsensical length values (e.g., a variable-length Information Element longer than its enclosing Set, a Set longer than its enclosing IPFIX Message, or an IPFIX Message shorter than an IPFIX Message Header) or a reserved Version value (which may indicate that a future version of IPFIX is being used for export but in practice occurs most often when non-IPFIX data is sent to an IPFIX Collecting Process). Note that non-zero Set padding does not constitute a malformed IPFIX Message.
収集プロセスが不正なIPFIXメッセージを受信した場合、IPFIXメッセージを破棄し、エラーを記録する必要があります（SHOULD）。不正な形式のIPFIXメッセージは、意味のない長さの値（たとえば、可変長の情報要素がその外側のセットより長い、外側のIPFIXメッセージより長い、またはIPFIXメッセージヘッダーより短いIPFIXメッセージ）のために解釈できないメッセージです。または予約済みのバージョン値（IPFIXの将来のバージョンがエクスポートに使用されていることを示す場合がありますが、実際には、非IPFIXデータがIPFIX収集プロセスに送信されるときに最も頻繁に発生します）。ゼロ以外のSetパディングは、不正なIPFIXメッセージを構成しないことに注意してください。
As the most likely cause of malformed IPFIX Messages is a poorly implemented Exporting Process, or the sending of non-IPFIX data to an IPFIX Collecting Process, human intervention is likely necessary to correct the issue. In the meantime, the Collecting Process MAY attempt to rectify the situation any way it sees fit, including:
不正なIPFIXメッセージの原因として最も可能性が高いのは、実装が不十分なエクスポートプロセス、または非IPFIXデータのIPFIX収集プロセスへの送信であるため、問題を修正するために人間の介入が必要になる可能性があります。それまでの間、収集プロセスは、次のような状況に応じて状況を修正しようとする場合があります。
- terminating the TCP connection or SCTP connection
- TCP接続またはSCTP接続の終了
- using the receiver window to reduce network load from the malfunctioning Exporting Process
- 受信ウィンドウを使用して、誤動作しているエクスポートプロセスによるネットワーク負荷を軽減する
- buffering and saving malformed IPFIX Message(s) to assist in diagnosis
- 診断に役立つ不正なIPFIXメッセージのバッファリングと保存
- attempting to resynchronize the stream, e.g., as described in Section 10.3 of [RFC5655]
- [RFC5655]のセクション10.3で説明されているように、ストリームの再同期を試みる
Resynchronization should only be attempted if the Collecting Process has reason to believe that the error is transient. On the other hand, the Collecting Process SHOULD stop processing IPFIX Messages from clearly malfunctioning Exporting Processes (e.g., those from which the last few IPFIX Messages have been malformed).
再同期は、収集プロセスにエラーが一時的なものであると信じる理由がある場合にのみ試行してください。一方、収集プロセスは、エクスポートプロセス（たとえば、最後のいくつかのIPFIXメッセージの形式が正しくないプロセス）が明らかに誤動作することから、IPFIXメッセージの処理を停止する必要があります（SHOULD）。
As an Exporting Process may request and support more than one stream per SCTP association, the Collecting Process MUST support the opening of multiple SCTP Streams.
エクスポートプロセスはSCTPアソシエーションごとに複数のストリームを要求およびサポートする可能性があるため、収集プロセスは複数のSCTPストリームのオープンをサポートする必要があります。
A Transport Session for IPFIX Messages transported over UDP is defined from the point of view of the Exporting Process and roughly corresponds to the time during which a given Exporting Process sends IPFIX Messages over UDP to a given Collecting Process. Since this is difficult to detect at the Collecting Process, the Collecting Process MAY discard all Transport Session state after no IPFIX Messages are received from a given Exporting Process within a given Transport Session during a configurable idle timeout.
UDPを介して転送されるIPFIXメッセージのトランスポートセッションは、エクスポートプロセスの観点から定義され、特定のエクスポートプロセスがIPFIXメッセージをUDPを介して特定の収集プロセスに送信する時間にほぼ対応します。これは収集プロセスで検出することが難しいため、構成可能なアイドルタイムアウト中に特定のトランスポートセッション内の特定のエクスポートプロセスからIPFIXメッセージを受信しなかった場合、収集プロセスはすべてのトランスポートセッションの状態を破棄できます（MAY）。
The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions such as Common Properties) required to decode the Data Record. If the Template Records or other definitions have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records or other definitions are received, comparing Export Times of IPFIX Messages containing the Template Records with those containing the Data Records as discussed in Section 8.2. Note that this mechanism may lead to incorrectly interpreted records in the presence of Template ID reuse or other identifiers with limited lifetimes.
収集プロセスは、データレコードのデコードに必要な関連するテンプレートレコード（または共通プロパティなどの他の定義）なしでデータレコードを受け入れる必要があります（SHOULD）。テンプレートレコードまたは他の定義がデータレコードの受信時に受信されなかった場合、収集プロセスはデータレコードを短期間保存し、テンプレートレコードまたは他の定義の受信後にそれらをデコードして、セクション8.2で説明するように、テンプレートレコードを含むIPFIXメッセージとデータレコードを含むメッセージ。このメカニズムにより、テンプレートIDの再利用や、有効期限が限定されたその他の識別子が存在する場合に、レコードが誤って解釈される可能性があることに注意してください。
The IPFIX Protocol Specification has been designed to be transport protocol independent. Note that the Exporter can export to multiple Collecting Processes using independent transport protocols.
IPFIXプロトコル仕様は、トランスポートプロトコルに依存しないように設計されています。エクスポーターは、独立したトランスポートプロトコルを使用して複数の収集プロセスにエクスポートできることに注意してください。
The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535 octets.
IPFIXメッセージヘッダーの16ビット長フィールドは、IPFIXメッセージの長さをヘッダーを含む65535オクテットに制限します。収集プロセスは、最大65535オクテットのIPFIXメッセージ長を処理できる必要があります。
While an Exporting Process or Collecting Process may support multiple transport protocols, Transport Sessions are bound to a transport protocol. Transport Session state MUST NOT be migrated by an Exporting Process or Collecting Process among Transport Sessions using different transport protocols between the same Exporting Process and Collecting Process pair. In other words, an Exporting Process supporting multiple transport protocols is conceptually multiple Exporting Processes, one per supported transport protocol. Likewise, a Collecting Process supporting multiple transport protocols is conceptually multiple Collecting Processes, one per supported transport protocol.
エクスポートプロセスまたは収集プロセスは複数のトランスポートプロトコルをサポートする場合がありますが、トランスポートセッションはトランスポートプロトコルにバインドされています。トランスポートセッションの状態は、同じエクスポートプロセスと収集プロセスのペア間で異なるトランスポートプロトコルを使用するトランスポートセッション間で、エクスポートプロセスまたは収集プロセスによって移行してはなりません。つまり、複数のトランスポートプロトコルをサポートするエクスポートプロセスは、概念的には、サポートされるトランスポートプロトコルごとに1つずつ、複数のエクスポートプロセスです。同様に、複数のトランスポートプロトコルをサポートする収集プロセスは、概念的には、サポートされるトランスポートプロトコルごとに1つずつ、複数の収集プロセスです。
SCTP [RFC4960] using the Partially Reliable SCTP (PR-SCTP) extension as specified in [RFC3758] MUST be implemented by all compliant implementations. UDP [UDP] MAY also be implemented by compliant implementations. TCP [TCP] MAY also be implemented by compliant implementations.
[RFC3758]で指定されている部分的に信頼できるSCTP（PR-SCTP）拡張を使用するSCTP [RFC4960]は、すべての準拠実装によって実装する必要があります。 UDP [UDP]も準拠した実装によって実装される場合があります。 TCP [TCP]も準拠した実装によって実装される場合があります。
SCTP should be used in deployments where Exporters and Collectors are communicating over links that are susceptible to congestion. SCTP is capable of providing any required degree of reliability when used with the PR-SCTP extension.
SCTPは、エクスポーターとコレクターが、輻輳の影響を受けやすいリンクを介して通信している配置で使用する必要があります。 SCTPは、PR-SCTP拡張機能と併用すると、必要な信頼性を提供できます。
TCP may be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but SCTP is preferred, due to its ability to limit back pressure on Exporters and its message-versus-stream orientation.
TCPは、エクスポーターとコレクターが輻輳の影響を受けやすいリンクを介して通信するデプロイメントで使用できますが、エクスポーターへのバックプレッシャーを制限する機能とメッセージ対ストリームの方向性のため、SCTPが推奨されます。
UDP may be used, although it is not a congestion-aware protocol. However, in this case the IPFIX traffic between the Exporter and Collector must be separately contained or provisioned to minimize the risk of congestion-related loss.
UDPは、輻輳認識プロトコルではありませんが使用できます。ただし、この場合、輻輳に関連する損失のリスクを最小限に抑えるために、エクスポーターとコレクター間のIPFIXトラフィックを個別に封じ込めまたはプロビジョニングする必要があります。
By default, the Collecting Process listens for connections on SCTP, TCP, and/or UDP port 4739. By default, the Collecting Process listens for secure connections on SCTP, TCP, and/or UDP port 4740 (refer to the Security Considerations section). By default, the Exporting Process attempts to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use different ports than the default.
デフォルトでは、収集プロセスはSCTP、TCP、UDPポート4739で接続をリッスンします。デフォルトでは、収集プロセスはSCTP、TCP、UDPポート4740でセキュア接続をリッスンします（「セキュリティに関する考慮事項」セクションを参照）。 。デフォルトでは、エクスポートプロセスはこれらのポートのいずれかに接続しようとします。デフォルトとは異なるポートを使用するように、エクスポートプロセスと収集プロセスの両方を構成できる必要があります。
This section describes how IPFIX is transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension.
このセクションでは、PR-SCTP [RFC3758]拡張機能を使用して、IPFIXがSCTP [RFC4960]を介して転送される方法について説明します。
SCTP provides the required level of congestion avoidance by design.
SCTPは、設計により、必要なレベルの輻輳回避を提供します。
SCTP detects congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limits the transfer rate accordingly. When an IPFIX Exporting Process has records to export but detects that transmission by SCTP is temporarily impossible, it can either wait until sending is possible again or decide to drop the record. In the latter case, the dropped export data SHOULD be accounted for, so that the amount of dropped export data can be reported using the mechanism described in Section 4.3.
SCTPは、IPFIXエクスポートプロセスとIPFIX収集プロセスの間のエンドツーエンドパスで輻輳を検出し、それに応じて転送速度を制限します。 IPFIXエクスポートプロセスがエクスポートするレコードを持っているが、SCTPによる送信が一時的に不可能であることを検出した場合、送信が再び可能になるまで待つか、レコードをドロップすることを決定できます。後者の場合、ドロップされたエクスポートデータを考慮する必要があるため、セクション4.3で説明されているメカニズムを使用して、ドロップされたエクスポートデータの量を報告できます。
The SCTP transport protocol is by default reliable but has the capability to deliver messages with partial reliability [RFC3758].
SCTPトランスポートプロトコルはデフォルトで信頼性がありますが、部分的な信頼性でメッセージを配信する機能があります[RFC3758]。
Using reliable SCTP messages for IPFIX export is not in itself a guarantee that all Data Records will be delivered. If there is congestion on the link from the Exporting Process to the Collecting Process, or if a significant number of retransmissions are required, the send queues on the Exporting Process may fill up; the Exporting Process MAY either suspend, export, or discard the IPFIX Messages. If Data Records are discarded, the IPFIX Sequence Numbers used for export MUST reflect the loss of data.
IPFIXエクスポートに信頼できるSCTPメッセージを使用すること自体は、すべてのデータレコードが配信されることを保証するものではありません。エクスポートプロセスから収集プロセスへのリンクに輻輳がある場合、またはかなりの数の再送信が必要な場合、エクスポートプロセスの送信キューがいっぱいになることがあります。エクスポートプロセスは、IPFIXメッセージを一時停止、エクスポート、または破棄できます。データレコードが破棄される場合、エクスポートに使用されるIPFIXシーケンス番号は、データの損失を反映している必要があります。
SCTP provides the required IPFIX Message fragmentation service based on Path MTU (PMTU) discovery.
SCTPは、パスMTU（PMTU）ディスカバリーに基づいて、必要なIPFIXメッセージフラグメンテーションサービスを提供します。
The IPFIX Exporting Process initiates an SCTP association with the IPFIX Collecting Process. The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
IPFIXエクスポートプロセスは、IPFIX収集プロセスとのSCTPアソシエーションを開始します。エクスポートプロセスは、収集プロセスへの複数の関連付け（SCTP用語では接続「バンドル」）を確立する場合があります。
An Exporting Process MAY support more than one active association to different Collecting Processes (including the case of different Collecting Processes on the same host).
エクスポートプロセスは、異なる収集プロセスへの複数のアクティブな関連付けをサポートする場合があります（同じホスト上の異なる収集プロセスの場合を含む）。
When an Exporting Process is shut down, it SHOULD shut down the SCTP association.
エクスポートプロセスがシャットダウンされると、SCTPアソシエーションをシャットダウンする必要があります（SHOULD）。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shut down its end of the association. The Collecting Process SHOULD continue to receive and process IPFIX Messages until the Exporting Process has closed its end of the association.
収集プロセスがIPFIXメッセージを受信する必要がなくなった場合は、関連付けの終わりをシャットダウンする必要があります（SHOULD）。収集プロセスは、エクスポートプロセスが関連付けの終わりを閉じるまで、IPFIXメッセージの受信と処理を継続する必要があります（SHOULD）。
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment.
収集プロセスは、SCTPアソシエーションが異常終了したことを検出した場合、新しいアソシエーションの確立をリッスンし続ける必要があります。
When an Exporting Process detects that the SCTP association to the Collecting Process is abnormally terminated, it SHOULD try to re-establish the association.
エクスポートプロセスは、収集プロセスへのSCTPアソシエーションが異常終了したことを検出すると、アソシエーションの再確立を試みる必要があります。
Association timeouts SHOULD be configurable.
アソシエーションのタイムアウトは構成可能であるべきです（SHOULD）。
If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish an association, SCTP will automatically retry association establishment using exponential backoff. The Exporter MAY log an alarm if the underlying SCTP association establishment times out; this timeout should be configurable on the Exporter.
収集プロセスがエクスポートプロセスによる関連付けの確立の試みを認めない場合、SCTPは指数バックオフを使用して関連付けの確立を自動的に再試行します。基礎となるSCTPアソシエーションの確立がタイムアウトした場合、エクスポーターはアラームをログに記録できます。このタイムアウトはエクスポーターで構成可能でなければなりません。
The Exporting Process MAY open a backup SCTP association to a Collecting Process in advance, if it supports Collecting Process failover.
エクスポートプロセスは、収集プロセスのフェイルオーバーをサポートしている場合、事前に収集プロセスへのバックアップSCTPアソシエーションを開くことができます。
An Exporting Process MAY request more than one SCTP Stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets.
エクスポートプロセスは、関連付けごとに複数のSCTPストリームを要求する場合があります。これらの各ストリームは、データセット、テンプレートセット、および/またはオプションテンプレートセットを含むIPFIXメッセージの送信に使用できます。
Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP Stream established during SCTP association setup.
アプリケーションの要件に応じて、エクスポートプロセスは、SCTPアソシエーションのセットアップ中に確立されたSCTPストリームを介して、順序付きまたは順序外の配信を使用して、完全または部分的な信頼性でデータセットを送信できます。
An IPFIX Exporting Process MAY use any PR-SCTP service definition as per Section 4 of the PR-SCTP specification [RFC3758] when using partial reliability to transmit IPFIX Messages containing only Data Sets.
IPFIXエクスポートプロセスは、PR-SCTP仕様[RFC3758]のセクション4に従い、データセットのみを含むIPFIXメッセージを送信するために部分信頼性を使用する場合、PR-SCTPサービス定義を使用してもよい（MAY）。
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow.
ただし、エクスポートプロセスは、リソースまたは他の制約が許す限り、そのようなIPFIXメッセージに再送信のマークを付ける必要があります（SHOULD）。
This section describes how IPFIX is transported over UDP [UDP].
このセクションでは、IPFIXがUDP [UDP]を介して転送される方法について説明します。
UDP has no integral congestion-avoidance mechanism. Its use over congestion-sensitive network paths is therefore not recommended. UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion, i.e., links that are over-provisioned compared to the maximum export rate from the Exporters.
UDPには、統合的な輻輳回避メカニズムはありません。したがって、輻輳の影響を受けやすいネットワークパスでの使用はお勧めしません。 UDPは、エクスポーターとコレクターが常に、輻輳の影響を受けにくい専用リンク、つまりエクスポーターからの最大エクスポートレートと比べて過剰にプロビジョニングされているリンクを介して通信するデプロイメントで使用できます。
UDP is not a reliable transport protocol and cannot guarantee delivery of messages. IPFIX Messages sent from the Exporting Process to the Collecting Process using UDP may therefore be lost. UDP MUST NOT be used unless the application can tolerate some loss of IPFIX Messages.
UDPは信頼できるトランスポートプロトコルではなく、メッセージの配信を保証できません。したがって、UDPを使用してエクスポートプロセスから収集プロセスに送信されたIPFIXメッセージは失われる可能性があります。アプリケーションがIPFIXメッセージのいくつかの損失を許容できる場合を除き、UDPを使用してはなりません（MUST NOT）。
The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number.
収集プロセスは、IPFIXシーケンス番号の不連続性を調べることにより、IPFIXデータレコードの損失と並べ替えを推定する必要があります（SHOULD）。 UDPの場合、IPFIXシーケンス番号には、このIPFIXメッセージ（2 ^ 32を法とする）の受信前にトランスポートセッション用に送信されたIPFIXデータレコードの総数が含まれます。コレクターは、シーケンス番号を追跡することにより、シーケンス外、ドロップ、または重複のIPFIXメッセージを検出する必要があります（SHOULD）。
Exporting Processes exporting IPFIX Messages via UDP MUST include a valid UDP checksum [UDP] in UDP datagrams including IPFIX Messages.
UDPを介してIPFIXメッセージをエクスポートするプロセスをエクスポートするには、IPFIXメッセージを含むUDPデータグラムに有効なUDPチェックサム[UDP]を含める必要があります。
The maximum size of exported messages MUST be configured such that the total packet size does not exceed the PMTU. If the PMTU is unknown, a maximum packet size of 512 octets SHOULD be used.
エクスポートされるメッセージの最大サイズは、合計パケットサイズがPMTUを超えないように構成する必要があります。 PMTUが不明な場合は、512オクテットの最大パケットサイズを使用する必要があります（SHOULD）。
As UDP is a connectionless protocol, there is no real session establishment or shutdown for IPFIX over UDP. An Exporting Process starts sending IPFIX Messages to a Collecting Process at one point in time and stops sending them at another point in time. This can lead to some complications in Template management, as outlined in Section 8.4 above.
UDPはコネクションレス型プロトコルであるため、UDPを介したIPFIXの実際のセッションの確立やシャットダウンはありません。エクスポートプロセスは、ある時点で収集プロセスへのIPFIXメッセージの送信を開始し、別の時点でそれらの送信を停止します。上記のセクション8.4で概説されているように、これはテンプレート管理にいくつかの複雑さをもたらす可能性があります。
Because UDP is not a connection-oriented protocol, the Exporting Process is unable to determine from the transport protocol that the Collecting Process is no longer able to receive the IPFIX Messages. Therefore, it cannot invoke a failover mechanism. However, the Exporting Process MAY duplicate the IPFIX Message to several Collecting Processes.
UDPは接続指向のプロトコルではないため、エクスポートプロセスは、収集プロセスがIPFIXメッセージを受信できなくなったことをトランスポートプロトコルから判別できません。したがって、フェイルオーバーメカニズムを呼び出すことはできません。ただし、エクスポートプロセスは、IPFIXメッセージをいくつかの収集プロセスに複製する場合があります。
This section describes how IPFIX is transported over TCP [TCP].
このセクションでは、IPFIXがTCP [TCP]を介して転送される方法について説明します。
TCP controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that takes into account both congestion in the network and the capabilities of the receiver.
TCPは、ネットワークの輻輳と受信機の機能の両方を考慮したメカニズムを使用して、エクスポートプロセスから収集プロセスにデータを送信できるレートを制御します。
Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate that the Metering Process generates them, either because of congestion in the network or because the Collecting Process cannot handle IPFIX Messages fast enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. But such buffering is necessarily limited, both because of resource limitations and because of timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked.
したがって、ネットワークの輻輳のため、または収集プロセスがIPFIXメッセージを十分に速く処理できないため、IPFIXエクスポートプロセスは、メータリングプロセスが生成するレートでIPFIXメッセージを送信できない場合があります。輻輳が一時的である限り、エクスポートプロセスはIPFIXメッセージを送信用にバッファできます。ただし、リソースの制限と適時性の要件の両方が原因で、このようなバッファリングは必然的に制限されるため、継続的または深刻な輻輳により、エクスポートプロセスがブロックされる場合があります。
When an Exporting Process has Data Records to export but the transmission buffer is full, and it wants to avoid blocking, it can decide to drop some Data Records. The dropped Data Records MUST be accounted for, so that the number of lost records can later be reported as described in Section 4.3.
エクスポートプロセスにエクスポートするデータレコードがあるが、送信バッファがいっぱいで、ブロックを回避したい場合、一部のデータレコードを削除することを決定できます。セクション4.3で説明するように、失われたレコードの数を後で報告できるように、ドロップされたデータレコードを考慮する必要があります。
TCP ensures reliable delivery of data from the Exporting Process to the Collecting Process.
TCPは、エクスポートプロセスから収集プロセスへのデータの信頼できる配信を保証します。
As TCP offers a stream service instead of a datagram or sequential packet service, IPFIX Messages transported over TCP are instead separated using the Length field in the IPFIX Message Header. The Exporting Process can choose any valid length for exported IPFIX Messages, as TCP handles segmentation.
TCPはデータグラムまたは順次パケットサービスの代わりにストリームサービスを提供するため、TCPを介して転送されるIPFIXメッセージは、IPFIXメッセージヘッダーのLengthフィールドを使用して分離されます。 TCPはセグメンテーションを処理するため、エクスポートプロセスは、エクスポートされたIPFIXメッセージの有効な長さを選択できます。
Exporting Processes may choose IPFIX Message lengths lower than the maximum in order to ensure timely export of Data Records.
エクスポートプロセスは、データレコードのタイムリーなエクスポートを保証するために、最大よりも短いIPFIXメッセージ長を選択する場合があります。
The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). An Exporting Process MAY support more than one active connection to the same Collecting Process to avoid head-of-line blocking across Observation Domains.
IPFIXエクスポートプロセスは、収集プロセスへのTCP接続を開始します。エクスポートプロセスは、異なる収集プロセスへの複数のアクティブな接続をサポートする場合があります（同じホスト上の異なる収集プロセスの場合を含む）。エクスポートプロセスは、同じ収集プロセスへの複数のアクティブな接続をサポートして、観測ドメイン間のヘッドオブラインブロッキングを回避する場合があります。
The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter.
基礎となるTCP接続の確立がタイムアウトした場合、エクスポーターはアラームをログに記録できます。このタイムアウトはエクスポーターで構成可能でなければなりません。
When an Exporting Process is shut down, it SHOULD shut down the TCP connection.
エクスポートプロセスがシャットダウンされるとき、それはTCP接続をシャットダウンする必要があります。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end.
収集プロセスがIPFIXメッセージを受信する必要がなくなった場合は、接続の終わりを閉じる必要があります。収集プロセスは、エクスポートプロセスが終了するまでIPFIXメッセージを読み続ける必要があります。
When a Collecting Process detects that the TCP connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection.
収集プロセスは、エクスポートプロセスへのTCP接続が異常終了したことを検出した場合、新しい接続をリッスンし続ける必要があります。
When an Exporting Process detects that the TCP connection to the Collecting Process has terminated abnormally, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute.
エクスポートプロセスは、収集プロセスへのTCP接続が異常終了したことを検出すると、接続を再確立する必要があります（SHOULD）。接続タイムアウトと再試行スケジュールは構成可能である必要があります。デフォルトの構成では、エクスポートプロセスは、1分に1回よりも頻繁に接続を確立しようとしてはなりません。
If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, TCP will automatically retry connection establishment using exponential backoff. The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter.
収集プロセスがエクスポートプロセスによる接続の確立の試みを認めない場合、TCPは指数バックオフを使用して接続の確立を自動的に再試行します。基礎となるTCP接続の確立がタイムアウトした場合、エクスポーターはアラームをログに記録できます。このタイムアウトはエクスポーターで構成可能でなければなりません。
The Exporting Process MAY open a backup TCP connection to a Collecting Process in advance, if it supports Collecting Process failover.
エクスポートプロセスは、収集プロセスのフェイルオーバーをサポートしている場合、事前に収集プロセスへのバックアップTCP接続を開くことができます。
The security considerations for the IPFIX protocol have been derived from an analysis of potential security threats, as discussed in the Security Considerations section of the IPFIX requirements document [RFC3917]. The requirements for IPFIX security are as follows:
IPFIX要件ドキュメント[RFC3917]のセキュリティに関する考慮事項のセクションで説明されているように、IPFIXプロトコルのセキュリティに関する考慮事項は、潜在的なセキュリティの脅威の分析に基づいています。 IPFIXセキュリティの要件は次のとおりです。
1. IPFIX must provide a mechanism to ensure the confidentiality of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent disclosure of Flow Records transported via IPFIX.
1. IPFIXは、IPFIXを介して転送されるフローレコードの開示を防ぐために、エクスポートプロセスから収集プロセスに転送されるIPFIXデータの機密性を確保するメカニズムを提供する必要があります。
2. IPFIX must provide a mechanism to ensure the integrity of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent the injection of incorrect data or control information (e.g., Templates), or the duplication of Messages, in an IPFIX Message stream.
2. IPFIXは、IPFIXメッセージ内の不正なデータや制御情報（テンプレートなど）の挿入、またはメッセージの重複を防ぐために、エクスポートプロセスから収集プロセスに転送されるIPFIXデータの整合性を保証するメカニズムを提供する必要がありますストリーム。
3. IPFIX must provide a mechanism to authenticate IPFIX Collecting and Exporting Processes, to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process.
3. IPFIXは、IPFIXの収集およびエクスポートプロセスを認証するメカニズムを提供して、無許可のエクスポートプロセスからのデータの収集、または無許可の収集プロセスへのデータのエクスポートを防止する必要があります。
Because IPFIX can be used to collect information for network forensics and billing purposes, attacks designed to confuse, disable, or take information from an IPFIX collection system may be seen as a prime objective during a sophisticated network attack.
IPFIXはネットワークフォレンジックや請求の目的で情報を収集するために使用できるため、IPFIX収集システムから情報を混乱、無効化、または取得するように設計された攻撃は、高度なネットワーク攻撃の主な目的と見なされる場合があります。
An attacker in a position to inject false messages into an IPFIX Message stream can affect either the application using IPFIX (by falsifying data) or the IPFIX Collecting Process itself (by modifying or revoking Templates, or changing options); for this reason, IPFIX Message integrity is important.
偽のメッセージをIPFIXメッセージストリームに挿入する立場にある攻撃者は、IPFIXを使用するアプリケーション（データの改ざんによる）またはIPFIX収集プロセス自体（テンプレートの変更または取り消し、またはオプションの変更による）に影響を与える可能性があります。このため、IPFIXメッセージの整合性は重要です。
The IPFIX Messages themselves may also contain information of value to an attacker, including information about the configuration of the network as well as end-user traffic and payload data, so care must be taken to confine their visibility to authorized users. When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping. Suitable mechanisms include the use of either a direct point-to-point connection assumed to be unavailable to attackers, or the use of an encryption mechanism. It is the responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, encryption and/or anonymization of any reported data; see Section 11.8.
IPFIXメッセージ自体にも攻撃者にとって価値のある情報が含まれている可能性があります。これには、ネットワークの構成、エンドユーザーのトラフィック、ペイロードデータなどの情報が含まれるため、承認されたユーザーだけが見えるように注意する必要があります。エンドユーザーのペイロード情報を含む情報要素がエクスポートされるとき、その内容を盗聴から保護する手段を使用して収集プロセスに送信する必要があります。適切なメカニズムには、攻撃者が利用できないと想定される直接のポイントツーポイント接続の使用、または暗号化メカニズムの使用が含まれます。収集されたデータに十分なセキュリティを提供することは収集プロセスの責任であり、必要に応じて、報告されたデータの暗号化や匿名化を含みます。セクション11.8を参照してください。
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] were designed to provide the confidentiality, integrity, and authentication assurances required by the IPFIX protocol, without the need for pre-shared keys.
トランスポート層セキュリティ（TLS）[RFC5246]およびデータグラムトランスポート層セキュリティ（DTLS）[RFC6347]は、事前共有キーを必要とせずに、IPFIXプロトコルで必要な機密性、整合性、および認証保証を提供するように設計されました。
IPFIX Exporting Processes and Collecting Processes using TCP MUST support TLS version 1.1 and SHOULD support TLS version 1.2 [RFC5246], including the mandatory ciphersuite(s) specified in each version. IPFIX Exporting Processes and Collecting Processes using UDP or SCTP MUST support DTLS version 1.0 and SHOULD support DTLS version 1.2 [RFC6347], including the mandatory ciphersuite(s) specified in each version.
IPFIXエクスポートプロセスとTCPを使用したプロセスの収集は、TLSバージョン1.1をサポートしなければならず（MUST）、各バージョンで指定された必須の暗号スイートを含むTLSバージョン1.2 [RFC5246]をサポートする必要があります。 UDPまたはSCTPを使用するIPFIXエクスポートプロセスと収集プロセスは、DTLSバージョン1.0をサポートする必要があり、各バージョンで指定された必須の暗号スイートを含むDTLSバージョン1.2 [RFC6347]をサポートする必要があります。
Note that DTLS is selected as the security mechanism for SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they require that all communication be over reliable, bidirectional streams, and they also require one TLS connection per stream. This arrangement is not compatible with the rationale behind the choice of SCTP as an IPFIX transport protocol.
SCTLSのセキュリティメカニズムとしてDTLSが選択されていることに注意してください。 SCTPへのTLSバインディングは[RFC3436]で定義されていますが、すべての通信が信頼性の高い双方向ストリーム上にある必要があり、ストリームごとに1つのTLS接続が必要です。この配置は、IPFIXトランスポートプロトコルとしてSCTPを選択する根拠と互換性がありません。
Note that using DTLS has a man-in-the-middle vulnerability not present in TLS, allowing a message to be removed from the stream without the knowledge of either the sender or receiver. Additionally, when using DTLS over SCTP, an attacker could inject SCTP control information and shut down the SCTP association, causing a loss of IPFIX Messages if those messages are buffered outside of the SCTP association. Techniques such as those described in [RFC6083] could be used to overcome these vulnerabilities.
DTLSを使用すると、TLSには存在しない中間者の脆弱性が存在することに注意してください。これにより、送信者または受信者のいずれかの知識がなくてもメッセージをストリームから削除できます。さらに、SCTP over DTLSを使用する場合、攻撃者はSCTP制御情報を挿入してSCTPアソシエーションをシャットダウンし、それらのメッセージがSCTPアソシエーションの外部でバッファリングされている場合、IPFIXメッセージを失う可能性があります。 [RFC6083]で説明されているような手法を使用して、これらの脆弱性を克服できます。
When using DTLS over SCTP, the Exporting Process MUST ensure that each IPFIX Message is sent over the same SCTP Stream that would be used when sending the same IPFIX Message directly over SCTP. Note that DTLS may send its own control messages on stream 0 with full reliability; however, this will not interfere with the processing of stream 0 IPFIX Messages at the Collecting Process, because DTLS consumes its own control messages before passing IPFIX Messages up to the application layer.
DTP over SCTPを使用する場合、エクスポートプロセスでは、各IPFIXメッセージが、SCTPを介して同じIPFIXメッセージを直接送信するときに使用される同じSCTPストリームを介して送信されるようにする必要があります。 DTLSは独自の制御メッセージを完全な信頼性を持ってストリーム0で送信する場合があることに注意してください。ただし、DTLSはIPFIXメッセージをアプリケーション層に渡す前に独自の制御メッセージを消費するため、収集プロセスでのストリーム0 IPFIXメッセージの処理を妨げることはありません。
When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] SHOULD be used, especially on long-lived Transport Sessions, to ensure that the association remains active.
DTP over SCTPまたはUDPを使用する場合、ハートビート拡張[RFC6520]を使用する必要があります（特に、長期間有効なトランスポートセッションでは）、関連付けがアクティブなままであることを確認してください。
Exporting and Collecting Processes MUST NOT request, offer, or use any version of the Secure Socket Layer (SSL), or any version of TLS prior to 1.1, due to known security vulnerabilities in prior versions of TLS; see Appendix E of [RFC5246] for more information.
以前のバージョンのTLSには既知のセキュリティ脆弱性があるため、プロセスのエクスポートと収集は、Secure Socket Layer（SSL）のバージョン、または1.1より前のバージョンのTLSを要求、提供、または使用してはなりません。詳細については、[RFC5246]の付録Eを参照してください。
The IPFIX Exporting Process initiates the communication to the IPFIX Collecting Process and acts as a TLS or DTLS client according to [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a TLS or DTLS server. The DTLS client opens a secure connection on SCTP port 4740 of the DTLS server if SCTP is selected as the transport protocol. The TLS client opens a secure connection on TCP port 4740 of the TLS server if TCP is selected as the transport protocol. The DTLS client opens a secure connection on UDP port 4740 of the DTLS server if UDP is selected as the transport protocol.
IPFIXエクスポートプロセスはIPFIX収集プロセスへの通信を開始し、[RFC5246]および[RFC6347]に従ってTLSまたはDTLSクライアントとして機能し、IPFIX収集プロセスはTLSまたはDTLSサーバーとして機能します。トランスポートプロトコルとしてSCTPが選択されている場合、DTLSクライアントはDTLSサーバーのSCTPポート4740で安全な接続を開きます。トランスポートプロトコルとしてTCPが選択されている場合、TLSクライアントは、TLSサーバーのTCPポート4740で安全な接続を開きます。トランスポートプロトコルとしてUDPが選択されている場合、DTLSクライアントはDTLSサーバーのUDPポート4740で安全な接続を開きます。
When using TLS or DTLS, IPFIX Exporting Processes and IPFIX Collecting Processes SHOULD be identified by a certificate containing the DNS-ID as discussed in Section 6.4 of [RFC6125]; the inclusion of Common Names (CN-IDs) in certificates identifying IPFIX Exporting Processes or Collecting Processes is NOT RECOMMENDED.
[RFC6125]のセクション6.4で説明されているように、TLSまたはDTLSを使用する場合、IPFIXエクスポートプロセスとIPFIX収集プロセスは、DNS-IDを含む証明書で識別される必要があります。 IPFIXエクスポートプロセスまたは収集プロセスを識別する証明書に共通名（CN-ID）を含めることは推奨されません。
To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, mutual authentication MUST be used for both TLS and DTLS. Exporting Processes MUST verify the reference identifiers of the Collecting Processes to which they are exporting IPFIX Messages against those stored in the certificates. Likewise, Collecting Processes MUST verify the reference identifiers of the Exporting Processes from which they are receiving IPFIX Messages against those stored in the certificates. Exporting Processes MUST NOT export to non-verified Collecting Processes, and Collecting Processes MUST NOT accept IPFIX Messages from non-verified Exporting Processes.
なりすましのエクスポートまたは収集プロセスによる中間者攻撃、無許可のエクスポートプロセスからのデータの受け入れ、または無許可の収集プロセスへのデータのエクスポートを防ぐには、TLSとDTLSの両方に相互認証を使用する必要があります。エクスポートプロセスは、証明書に格納されているものと比較して、IPFIXメッセージのエクスポート先の収集プロセスの参照識別子を検証する必要があります。同様に、収集プロセスは、証明書に格納されているものと比較して、IPFIXメッセージの受信元であるエクスポートプロセスの参照識別子を検証する必要があります。エクスポートプロセスは、検証されていない収集プロセスにエクスポートしてはならず、収集プロセスは、検証されていないエクスポートプロセスからのIPFIXメッセージを受け入れてはなりません。
Exporting Processes and Collecting Processes MUST support the verification of certificates against an explicitly authorized list of peer certificates identified by Common Name and SHOULD support the verification of reference identifiers by matching the DNS-ID or CN-ID with a DNS lookup of the peer.
エクスポートプロセスと収集プロセスは、共通名で識別されるピア証明書の明示的に承認されたリストに対する証明書の検証をサポートする必要があり、DNS-IDまたはCN-IDをピアのDNSルックアップと照合することにより、参照識別子の検証をサポートする必要があります。
IPFIX Exporting Processes and Collecting Processes MUST use non-NULL ciphersuites for authentication, integrity, and confidentiality.
IPFIXエクスポートプロセスと収集プロセスは、認証、整合性、および機密性のためにNULL以外の暗号群を使用する必要があります。
An attacker may mount a denial-of-service (DoS) attack against an IPFIX collection system either directly, by sending large amounts of traffic to a Collecting Process, or indirectly, by generating large amounts of traffic to be measured by a Metering Process.
攻撃者は、大量のトラフィックを収集プロセスに送信することによって直接、またはメータリングプロセスによって測定される大量のトラフィックを生成することによって間接的に、IPFIX収集システムに対してサービス拒否（DoS）攻撃を仕掛けることがあります。
Direct DoS attacks can also involve state exhaustion, whether at the transport layer (e.g., by creating a large number of pending connections) or within the IPFIX Collecting Process itself (e.g., by sending Flow Records pending Template or scope information, or a large amount of Options Template Records, etc.).
直接DoS攻撃には、トランスポート層（保留中の多数の接続を作成するなど）またはIPFIX収集プロセス自体（たとえば、保留中のフローレコード保留中のテンプレートまたはスコープ情報、または大量の送信）による状態の枯渇も含まれます。オプションテンプレートレコードなど）。
SCTP mandates a cookie-exchange mechanism designed to defend against SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be used by any Collecting Process accepting TCP connections. DTLS also provides cookie exchange to protect against DTLS server state exhaustion.
SCTPは、SCTP状態の枯渇DoS攻撃を防御するように設計されたCookie交換メカニズムを義務付けています。同様に、TCPは状態の枯渇を軽減するための「SYN cookie」メカニズムを提供します。 SYNクッキーは、TCP接続を受け入れるすべての収集プロセスで使用する必要があります（SHOULD）。 DTLSは、DTLSサーバー状態の枯渇から保護するためのCookie交換も提供します。
The reader should note that there is no way to prevent fake IPFIX Message processing (and state creation) for UDP and SCTP communication. The use of TLS and DTLS can obviously prevent the creation of fake states, but they are themselves prone to state exhaustion attacks. Therefore, Collector rate limiting SHOULD be used to protect TLS and DTLS (like limiting the number of new TLS or DTLS sessions per second to a sensible number).
読者は、UDPおよびSCTP通信の偽のIPFIXメッセージ処理（および状態の作成）を防ぐ方法はないことに注意してください。 TLSとDTLSの使用は明らかに偽の状態の作成を防ぐことができますが、それら自体が状態枯渇攻撃をしがちです。したがって、コレクターのレート制限は、TLSとDTLSを保護するために使用する必要があります（1秒あたりの新しいTLSまたはDTLSセッションの数を適切な数に制限するなど）。
IPFIX state exhaustion attacks can be mitigated by limiting the rate at which new connections or associations will be opened by the Collecting Process; limiting the rate at which IPFIX Messages will be accepted by the Collecting Process; and adaptively limiting the amount of state kept, particularly for records waiting for Templates. These rate and state limits MAY be provided by a Collecting Process, and if provided, the limits SHOULD be user configurable.
収集プロセスによって新しい接続または関連付けが開かれる速度を制限することで、IPFIX状態の枯渇攻撃を軽減できます。収集プロセスがIPFIXメッセージを受け入れる速度を制限する。特に、テンプレートを待機しているレコードに対して、保持される状態の量を適応的に制限します。これらのレートと状態の制限は収集プロセスによって提供される場合があり、提供される場合、制限はユーザーが構成可能であるべきです（SHOULD）。
Additionally, an IPFIX Collecting Process can eliminate the risk of state exhaustion attacks from untrusted nodes by requiring TLS or DTLS mutual authentication, causing the Collecting Process to accept IPFIX Messages only from trusted sources.
さらに、IPFIX収集プロセスは、TLSまたはDTLS相互認証を要求することにより、信頼できないノードからの状態枯渇攻撃のリスクを排除でき、収集プロセスが信頼できるソースからのみIPFIXメッセージを受け入れるようにします。
With respect to indirect denial of service, the behavior of IPFIX under overload conditions depends on the transport protocol in use. For IPFIX over TCP, TCP congestion control would cause the flow of IPFIX Messages to back off and eventually stall, blinding the IPFIX system. SCTP improves upon this situation somewhat, as some IPFIX Messages would continue to be received by the Collecting Process due to the avoidance of head-of-line blocking by SCTP's multiple streams and partial reliability features, possibly affording some visibility of the attack. The situation is similar with UDP, as some datagrams may continue to be received at the Collecting Process, effectively applying sampling to the IPFIX Message stream and implying that some information about the attack will be available.
間接的なサービス拒否に関しては、過負荷状態でのIPFIXの動作は、使用しているトランスポートプロトコルによって異なります。 IPFIX over TCPの場合、TCP輻輳制御により、IPFIXメッセージのフローがバックオフし、最終的に停止して、IPFIXシステムを盲目にします。 SCTPは、この状況を多少改善します。これは、SCTPの複数のストリームと部分的な信頼性機能による行頭ブロッキングの回避により、一部のIPFIXメッセージが引き続き収集プロセスによって受信されるため、攻撃をある程度可視化できるためです。一部のデータグラムは収集プロセスで引き続き受信され、IPFIXメッセージストリームに効果的にサンプリングが適用され、攻撃に関するいくつかの情報が利用可能であることを示唆するため、状況はUDPと同様です。
To minimize IPFIX Message loss under overload conditions, some mechanism for service differentiation could be used to prioritize IPFIX traffic over other traffic on the same link. Alternatively, IPFIX Messages can be transported over a dedicated network. In this case, care must be taken to ensure that the dedicated network can handle the expected peak IPFIX Message traffic.
過負荷状態でのIPFIXメッセージの損失を最小限に抑えるために、サービスを区別するためのいくつかのメカニズムを使用して、同じリンク上の他のトラフィックよりもIPFIXトラフィックを優先させることができます。または、IPFIXメッセージを専用ネットワーク経由で転送することもできます。この場合、専用ネットワークが予想されるピークIPFIXメッセージトラフィックを確実に処理できるように注意する必要があります。
The use of DTLS or TLS might not be possible in some cases, due to performance issues or other operational concerns.
パフォーマンスの問題やその他の運用上の問題により、DTLSまたはTLSを使用できない場合があります。
Without TLS or DTLS mutual authentication, IPFIX Exporting Processes and Collecting Processes can fall back on using IP source addresses to authenticate their peers. A policy of allocating Exporting Process and Collecting Process IP addresses from specified address ranges, and using ingress filtering to prevent spoofing, can improve the usefulness of this approach. Again, completely segregating IPFIX traffic on a dedicated network, where possible, can improve security even further. In any case, the use of open Collecting Processes (those that will accept IPFIX Messages from any Exporting Process regardless of IP address or identity) is discouraged.
TLSまたはDTLS相互認証がない場合、IPFIXエクスポートプロセスと収集プロセスは、IP送信元アドレスを使用してピアを認証することになります。エクスポートプロセスを割り当て、指定されたアドレス範囲からプロセスIPアドレスを収集し、入力フィルタリングを使用してスプーフィングを防止するポリシーは、このアプローチの有用性を向上させることができます。繰り返しますが、可能であれば、専用ネットワークでIPFIXトラフィックを完全に分離すると、セキュリティをさらに向上させることができます。いずれの場合も、開いている収集プロセス（IPアドレスやIDに関係なく、エクスポートプロセスからのIPFIXメッセージを受け入れるプロセス）の使用はお勧めしません。
Modern TCP and SCTP implementations are resistant to blind insertion attacks (see [RFC4960] and [RFC6528]); however, UDP offers no such protection. For this reason, IPFIX Message traffic transported via UDP and not secured via DTLS SHOULD be protected via segregation to a dedicated network.
最新のTCPおよびSCTP実装は、ブラインド挿入攻撃に耐性があります（[RFC4960]および[RFC6528]を参照）。ただし、UDPはそのような保護を提供しません。このため、UDPを介して転送され、DTLSを介して保護されていないIPFIXメッセージトラフィックは、分離によって専用ネットワークに保護する必要があります（SHOULD）。
IPFIX Collecting Processes MUST detect potential IPFIX Message insertion or loss conditions by tracking the IPFIX Sequence Number and SHOULD provide a logging mechanism for reporting out-of-sequence messages. Note that an attacker may be able to exploit the handling of out-of-sequence messages at the Collecting Process, so care should be taken in handling these conditions. For example, a Collecting Process that simply resets the expected Sequence Number upon receipt of a later Sequence Number could be temporarily blinded by deliberate injection of later Sequence Numbers.
IPFIX収集プロセスは、IPFIXシーケンス番号を追跡することにより、潜在的なIPFIXメッセージの挿入または損失の状態を検出する必要があり、シーケンス外のメッセージを報告するためのロギングメカニズムを提供する必要があります（SHOULD）。攻撃者は収集プロセスでシーケンス外のメッセージの処理を悪用できる可能性があるため、これらの条件の処理には注意が必要です。たとえば、後のシーケンス番号の受信時に予期されるシーケンス番号を単にリセットする収集プロセスは、後のシーケンス番号の意図的な挿入によって一時的にブラインドされる可能性があります。
IPFIX Exporting and Collecting Processes SHOULD log any connection attempt that fails due to authentication failure, whether due to being presented an unauthorized or mismatched certificate during TLS or DTLS mutual authentication, or due to a connection attempt from an unauthorized IP address when TLS or DTLS is not in use.
IPFIXエクスポートおよび収集プロセスは、TLSまたはDTLS相互認証中に無許可または不一致の証明書が提示されたため、またはTLSまたはDTLSが許可されている場合に無許可IPアドレスからの接続試行のために、認証の失敗が原因で失敗した接続試行をログに記録する必要があります（SHOULD）。使用されていません。
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset.
IPFIXプロセスのエクスポートと収集は、SCTPアソシエーションのリセットまたはTCP接続のリセットを検出してログに記録する必要があります（SHOULD）。
The security of the Collector and its implementation is important to achieve overall security; however, a complete set of security guidelines for Collector implementation is outside the scope of this document.
コレクタとその実装のセキュリティは、全体的なセキュリティを実現するために重要です。ただし、Collector実装のセキュリティガイドラインの完全なセットは、このドキュメントの範囲外です。
As IPFIX uses length-prefix encodings, Collector implementors should take care to ensure the detection of inconsistent values that could impact IPFIX Message decoding, and proper operation in the presence of such inconsistent values.
IPFIXは長さプレフィックスエンコーディングを使用するため、コレクターの実装者は、IPFIXメッセージのデコードに影響を与える可能性のある不整合値の検出、およびそのような不整合値が存在する場合の適切な操作を保証するよう注意する必要があります。
Specifically, IPFIX Message, Set, and variable-length Information Element lengths must be checked for consistency to avoid buffer-sizing vulnerabilities.
具体的には、IPFIXメッセージ、セット、および可変長の情報要素の長さをチェックして、バッファーサイズの脆弱性を回避する必要があります。
Collector implementors should also pay special attention to UTF-8 encoding of string data types, as vulnerabilities may exist in the interpretation of ill-formed UTF-8 values; see Section 6.1.6.
コレクターの実装者は、不正な形式のUTF-8値の解釈に脆弱性が存在する可能性があるため、文字列データ型のUTF-8エンコーディングにも特別な注意を払う必要があります。セクション6.1.6を参照してください。
Flow data exported by Exporting Processes and collected by Collecting Processes typically contains information about traffic on the observed network. This information may be personally identifiable and privacy-sensitive. The storage of this data must be protected via technical as well as policy means to ensure that the privacy of the users of the measured network is protected. A complete specification of such means is out of scope for this document and is specific to the application and storage technology used.
エクスポートプロセスによってエクスポートされ、収集プロセスによって収集されたフローデータには、通常、監視対象ネットワーク上のトラフィックに関する情報が含まれています。この情報は個人を特定できる可能性があり、プライバシーに配慮する必要があります。このデータのストレージは、測定されたネットワークのユーザーのプライバシーが確実に保護されるように、技術的およびポリシー手段によって保護する必要があります。このような手段の完全な仕様は、このドキュメントの範囲外であり、使用されるアプリケーションとストレージテクノロジーに固有のものです。
[RFC6615] specifies a MIB module that defines managed objects for monitoring IPFIX Devices, including basic configuration. This MIB can be used to measure the impact of IPFIX export on the monitoring network; it contains tables covering:
[RFC6615]は、基本構成を含む、IPFIXデバイスを監視するための管理対象オブジェクトを定義するMIBモジュールを指定します。このMIBは、監視ネットワークに対するIPFIXエクスポートの影響を測定するために使用できます。以下をカバーするテーブルが含まれています。
Transport Session, Cache definition, Observation Point definition, Template and Options Template definition, export features (failover, load-balancing, duplicate), and export statistics per Process, Session, and Template
トランスポートセッション、キャッシュ定義、観測ポイント定義、テンプレートとオプションテンプレート定義、エクスポート機能（フェイルオーバー、ロードバランシング、複製）、およびプロセス、セッション、テンプレートごとの統計のエクスポート
From an operational aspect, an important function of this MIB module is provided by the Transport Session Statistical table, which contains the rate (in bytes per second) at which the Collector receives or the Exporter sends out IPFIX Messages. Of particular interest to operations, the Transport Session Statistical table in Section 5.8.1 of this MIB module exposes the rate of collection or export of IPFIX Messages, which allows the measurement of the bandwidth used by IPFIX export.
運用面から見ると、このMIBモジュールの重要な機能は、コレクタが受信またはエクスポーターがIPFIXメッセージを送信する速度（1秒あたりのバイト数）を含むトランスポートセッション統計テーブルによって提供されます。操作に特に関心があるのは、このMIBモジュールのセクション5.8.1のTransport Session Statisticalテーブルが、IPFIXメッセージの収集またはエクスポートの速度を公開するため、IPFIXエクスポートで使用される帯域幅の測定を可能にします。
[RFC6727] describes extensions to the IPFIX-SELECTOR-MIB module specified in [RFC6615] and contains managed objects for providing information on applied packet selection functions and their parameters (filtering and sampling).
[RFC6727]は、[RFC6615]で指定されたIPFIX-SELECTOR-MIBモジュールの拡張機能を説明し、適用されたパケット選択関数とそのパラメーター（フィルタリングとサンプリング）に関する情報を提供するための管理オブジェクトを含みます。
Since the IPFIX-SELECTOR-MIB [RFC6615] and PSAMP-MIB [RFC6727] modules only contain read-only objects, they cannot be used for configuration of IPFIX Devices. [RFC6728] specifies a configuration data model for the IPFIX and PSAMP protocols, using the Network Configuration Protocol (NETCONF). This data model covers Selection Processes, Caches, Exporting Processes, and Collecting Processes on IPFIX and PSAMP Devices, and is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML).
IPFIX-SELECTOR-MIB [RFC6615]およびPSAMP-MIB [RFC6727]モジュールには読み取り専用オブジェクトしか含まれていないため、IPFIXデバイスの構成には使用できません。 [RFC6728]は、ネットワーク構成プロトコル（NETCONF）を使用して、IPFIXおよびPSAMPプロトコルの構成データモデルを指定します。このデータモデルは、IPFIXおよびPSAMPデバイスでの選択プロセス、キャッシュ、エクスポートプロセス、および収集プロセスを対象としており、UML（統一モデリング言語）クラス図を使用して定義され、YANGを使用して正式に指定されます。構成データはExtensible Markup Language（XML）でエンコードされています。
A few mechanisms specified alongside the IPFIX protocol can help monitor and reduce bandwidth used for IPFIX Export:
IPFIXプロトコルとともに指定されたいくつかのメカニズムは、IPFIXエクスポートに使用される帯域幅の監視と削減に役立ちます。
- a bandwidth-saving method for exporting redundant information in IPFIX [RFC5473]
- IPFIX [RFC5473]で冗長情報をエクスポートするための帯域幅節約方法
- an efficient method for exporting bidirectional flows [RFC5103]
- 双方向フローをエクスポートするための効率的な方法[RFC5103]
- a method for the definition and export of complex data structures [RFC6313]
- 複雑なデータ構造の定義とエクスポートの方法[RFC6313]
Alternatively, PSAMP [RFC5474] can be used to export packets sampled by statistical and other methods, which may be applicable to many monitoring areas for which IPFIX is also suited. PSAMP also provides control over the impact on the measured network through its sampling rate. The set of packet selection techniques (Sampling, Filtering, and hashing) standardized by PSAMP is described in [RFC5475]. PSAMP also defines an explicitly configurable export rate limit in Section 8.4 of [RFC5474].
あるいは、PSAMP [RFC5474]を使用して、統計的およびその他の方法でサンプリングされたパケットをエクスポートできます。これは、IPFIXも適した多くの監視領域に適用できる場合があります。 PSAMPは、サンプリングレートを通じて、測定されたネットワークへの影響を制御することもできます。 PSAMPによって標準化された一連のパケット選択技術（サンプリング、フィルタリング、およびハッシュ）は、[RFC5475]で説明されています。 PSAMPでは、[RFC5474]のセクション8.4で明示的に構成可能なエクスポートレート制限も定義されています。
IANA has updated the "IPFIX Information Elements" registry [IANA-IPFIX] so that all references that previously pointed to RFC 5101 now point to this document instead.
IANAは「IPFIX情報要素」レジストリ[IANA-IPFIX]を更新して、以前にRFC 5101を指していたすべての参照が、代わりにこのドキュメントを指すようになりました。
IPFIX Messages use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message.
IPFIXメッセージは、割り当てられた値を持つ2つのフィールドを使用します。これらは、IPFIXメッセージのエクスポートに使用されたIPFIXプロトコルのバージョンを示すIPFIXバージョン番号と、IPFIXメッセージ内の各情報セットのタイプを示すIPFIXセットIDです。
The Information Elements used by IPFIX, and sub-registries of Information Element values, are managed by IANA [IANA-IPFIX], as are the Private Enterprise Numbers used by enterprise-specific Information Elements [IANA-PEN]. This document makes no changes to these registries.
IPFIXによって使用される情報要素、および情報要素値のサブレジストリは、企業固有の情報要素[IANA-PEN]によって使用される私企業番号と同様に、IANA [IANA-IPFIX]によって管理されます。このドキュメントでは、これらのレジストリは変更されません。
The IPFIX Version Number value of 0x000a (10) is reserved for the IPFIX protocol specified in this document. Set ID values of 0 and 1 are not used, for historical reasons [RFC3954]. The Set ID value of 2 is reserved for the Template Set. The Set ID value of 3 is reserved for the Options Template Set. All other Set ID values from 4 to 255 are reserved for future use. Set ID values above 255 are used for Data Sets.
IPFIXバージョン番号の値0x000a（10）は、このドキュメントで指定されているIPFIXプロトコル用に予約されています。歴史的な理由により、0と1のセットID値は使用されません[RFC3954]。セットID値2は、テンプレートセット用に予約されています。セットID値3は、オプションテンプレートセット用に予約されています。他のすべての4〜255のセットID値は、将来の使用のために予約されています。データセットには、255を超えるセットID値が使用されます。
New assignments in either the "IPFIX Version Number" or "IPFIX Set IDs" sub-registries require a Standards Action [RFC5226], i.e., they are to be made via Standards Track RFCs approved by the IESG.
「IPFIXバージョン番号」または「IPFIXセットID」サブレジストリでの新しい割り当てには、標準アクション[RFC5226]が必要です。つまり、それらはIESGによって承認された標準トラックRFCを介して行われます。
This appendix, which is a not a normative reference, contains IPFIX encoding examples.
この付録は規範的なリファレンスではありませんが、IPFIXエンコーディングの例が含まれています。
Let's consider the example of an IPFIX Message composed of a Template Set, a Data Set (which contains three Data Records), an Options Template Set, and another Data Set (which contains two Data Records related to the previous Options Template Record).
テンプレートセット、データセット（3つのデータレコードを含む）、オプションテンプレートセット、および別のデータセット（前のオプションテンプレートレコードに関連する2つのデータレコードを含む）で構成されるIPFIXメッセージの例を考えてみましょう。
IPFIX Message:
IPFIXメッセージ：
+--------+------------------------------------------. . .
| | +--------------+ +------------------+
|Message | | Template | | Data |
| Header | | Set | | Set | . . .
| | | (1 Template) | | (3 Data Records) |
| | +--------------+ +------------------+
+--------+------------------------------------------. . .
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+
The Message Header is composed of:
メッセージヘッダーは以下で構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x000a | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
次の情報要素を報告します。
- IPv4 source IP address: sourceIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4送信元IPアドレス：sourceIPv4Address [IANA-IPFIX]、長さは4オクテット
- IPv4 destination IP address: destinationIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4宛先IPアドレス：destinationIPv4Address [IANA-IPFIX]、長さ4オクテット
- Next-hop IP address (IPv4): ipNextHopIPv4Address [IANA-IPFIX], with a length of 4 octets
- ネクストホップIPアドレス（IPv4）：ipNextHopIPv4Address [IANA-IPFIX]、長さ4オクテット
- Number of packets of the Flow: packetDeltaCount [IANA-IPFIX], with a length of 4 octets
- フローのパケット数：packetDeltaCount [IANA-IPFIX]、長さは4オクテット
- Number of octets of the Flow: octetDeltaCount [IANA-IPFIX], with a length of 4 octets
- フローのオクテット数：octetDeltaCount [IANA-IPFIX]、長さは4オクテット
Therefore, the Template Set will be composed of the following:
したがって、テンプレートセットは以下で構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
次の情報要素を報告します。
- IPv4 source IP address: sourceIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4送信元IPアドレス：sourceIPv4Address [IANA-IPFIX]、長さは4オクテット
- IPv4 destination IP address: destinationIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4宛先IPアドレス：destinationIPv4Address [IANA-IPFIX]、長さ4オクテット
- An enterprise-specific Information Element representing proprietary information, with a type of 15 and a length of 4 octets
- タイプが15で長さが4オクテットの企業固有の情報要素
- Number of packets of the Flow: packetDeltaCount [IANA-IPFIX], with a length of 4 octets
- フローのパケット数：packetDeltaCount [IANA-IPFIX]、長さは4オクテット
- Number of octets of the Flow: octetDeltaCount [IANA-IPFIX], with a length of 4 octets
- フローのオクテット数：octetDeltaCount [IANA-IPFIX]、長さは4オクテット
Therefore, the Template Set will be composed of the following:
したがって、テンプレートセットは以下で構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. = 15| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following three Flow Records:
この例では、次の3つのフローレコードを報告します。
Src IP Addr. | Dst IP Addr. | Next-Hop Addr. | Packet | Octets
| | | Number | Number
----------------------------------------------------------------
192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that padding is not necessary in this example.
この例ではパディングは必要ないことに注意してください。
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
ラインカード（ルータは2つのラインカードで構成されています）ごとに、次の情報要素を報告します。
- Total number of IPFIX Messages: exportedMessageTotalCount [IANA-IPFIX], with a length of 2 octets
- IPFIXメッセージの総数：2オクテットの長さの、exportedMessageTotalCount [IANA-IPFIX]
- Total number of exported Flows: exportedFlowRecordTotalCount [IANA-IPFIX], with a length of 2 octets
- エクスポートされたフローの総数：exportedFlowRecordTotalCount [IANA-IPFIX]、長さ2オクテット
The line card, which is represented by the lineCardId Information Element [IANA-IPFIX], is used as the Scope Field.
lineCardId情報要素[IANA-IPFIX]で表されるラインカードは、スコープフィールドとして使用されます。
Therefore, the Options Template Set will be:
したがって、オプションテンプレートセットは次のようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|exportedFlowRecordTotalCo.=42|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.2. Options Template Set Using Enterprise-Specific Information Elements
A.4.2. 企業固有の情報要素を使用したオプションテンプレートセット
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
ラインカード（ルータは2つのラインカードで構成されています）ごとに、次の情報要素を報告します。
- Total number of IPFIX Messages: exportedMessageTotalCount [IANA-IPFIX], with a length of 2 octets
- IPFIXメッセージの総数：2オクテットの長さの、exportedMessageTotalCount [IANA-IPFIX]
- An enterprise-specific number of exported Flows, with a type of 42 and a length of 4 octets
- タイプが42で長さが4オクテットの企業固有のエクスポートされたフローの数
The line card, which is represented by the lineCardId Information Element [IANA-IPFIX], is used as the Scope Field.
lineCardId情報要素[IANA-IPFIX]で表されるラインカードは、スコープフィールドとして使用されます。
The format of the Options Template Set is as follows:
オプションテンプレートセットの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |1|Information Element id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Enterprise number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise number | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we want to export the same information as in the example in Appendix A.4.1:
この例では、付録A.4.1の例と同じ情報をエクスポートします。
- Total number of IPFIX Messages: exportedMessageTotalCount [IANA-IPFIX], with a length of 2 octets
- IPFIXメッセージの総数：2オクテットの長さの、exportedMessageTotalCount [IANA-IPFIX]
- Total number of exported Flows: exportedFlowRecordTotalCount [IANA-IPFIX], with a length of 2 octets
- エクスポートされたフローの総数：exportedFlowRecordTotalCount [IANA-IPFIX]、長さ2オクテット
But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123.
しかし今回は、情報は企業固有の情報要素番号123で識別される独自のスコープに関連しています。
The format of the Options Template Set is now as follows:
オプションテンプレートセットの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 260 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |1|Scope 1 Infor. El. id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 | Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise Number |0|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|exportedFlowRecordTotalCo.=42|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following two Data Records:
この例では、次の2つのデータレコードを報告します。
Enterprise field 123 | IPFIX Message | Exported Flow Records
---------------------------------------------------------------
1 | 345 | 10201
2 | 690 | 20402
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 260 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 345 | 10201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5.1. Example of Variable-Length Information Element with Length Less Than 255 Octets
A.5.1. 長さが255オクテット未満の可変長情報要素の例
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5-octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5.2. Example of Variable-Length Information Element with 3-Octet Length Encoding
A.5.2. 3オクテットエンコーディングの可変長情報要素の例
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 | 1000 | IE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1000-octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normative References
引用文献
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix/>.
[IANA-IPFIX] IANA、「IP Flow Information Export（IPFIX）Entities」、<http://www.iana.org/assignments/ipfix/>。
[RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation Standard", RFC 1014, June 1987.
[RFC1014] Sun Microsystems、Inc。、「XDR：External Data Representation Standard」、RFC 1014、1987年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、Rescorla、E。、およびM. Tuexen、「ストリーム制御伝送プロトコルを介したトランスポート層セキュリティ」、RFC 3436、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R。、ラマーリョ、M。、シー、Q。、テューセン、M。、およびP.コンラッド、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「Transport Layer Security（TLS）and Datagram Transport Layer Security（DTLS）Heartbeat Extension」、RFC 6520、2012年2月。
[RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012] Claise、B。、編、およびB. Trammell、編、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、2013年9月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
Informative References
参考引用
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[IEEE.754.2008] Institute of Electrical and Electronics Engineers、「IEEE Standard for Floating-Point Arithmetic」、IEEE Standard 754、2008年8月。
[IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators", Work in Progress, July 2013.
[IPFIX-MED-PROTO] Claise、B.、Kobayashi、A。、およびB. Trammell、「IPFIX MediatorsでのIPフロー情報エクスポート（IPFIX）プロトコルの動作」、2013年7月、進行中。
[IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers/>.
[IANA-PEN] IANA、「Private Enterprise Numbers」、<http://www.iana.org/assignments/enterprise-numbers/>。
[POSIX.1] IEEE 1003.1-2008, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX(R))", 2008.
[POSIX.1] IEEE 1003.1-2008、「IEEE Standard for Information Technology-Portable Operating System Interface（POSIX（R））」、2008。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、April 1999。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IPフロー情報エクスポート（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B。、編、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、編、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103] Trammell、B。およびE. Boschi、「IP Flow Information Export（IPFIX）を使用した双方向フローエクスポート」、RFC 5103、2008年1月。
[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008.
[RFC5153] Boschi、E.、Mark、L.、Quittek、J.、Stiemerling、M。、およびP. Aitken、「IPフロー情報エクスポート（IPFIX）実装ガイドライン」、RFC 5153、2008年4月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、2009年3月。
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009.
[RFC5471] Schmoll、C.、Aitken、P。、およびB. Claise、「IPフロー情報エクスポート（IPFIX）テストのガイドライン」、RFC 5471、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、RFC 5472、2009年3月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473] Boschi、E.、Mark、L。、およびB. Claise、「Reduce Redundancy in IP Flow Information Export（IPFIX）and Packet Sampling（PSAMP）Reports」、RFC 5473、2009年3月。
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474] Duffield、N.、Ed。、Chiou、D.、Claise、B.、Greenberg、A.、Grossglauser、M。、およびJ. Rexford、「A Framework for Packet Selection and Reporting」、RFC 5474、March 2009。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングおよびフィルタリング技術」、RFC 5475、2009年3月。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、Ed。、Johnson、A。、およびJ. Quittek、「Packet Sampling（PSAMP）Protocol Specifications」、RFC 5476、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F。、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610] Boschi、E.、Trammell、B.、Mark、L。、およびT. Zseby、「Exporting Type Information for IP Flow Information Export（IPFIX）Information Elements」、RFC 5610、2009年7月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「Specification of the IP Flow Information Export（IPFIX）File Format」、RFC 5655、2009年10月。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083] Tuexen、M.、Seggelmann、R。、およびE. Rescorla、「Stream Control Transmission Protocol（SCTP）のデータグラムトランスポート層セキュリティ（DTLS）」、RFC 6083、2011年1月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]小林明朗、クレイズB.、ムエンツG.、石橋健二、「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」、RFC 6183、2011年4月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月。
[RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, March 2012.
[RFC6526] Claise、B.、Aitken、P.、Johnson、A。、およびG. Muenz、「IP Flow Information Export（IPFIX）Per Stream Control Transmission Protocol（SCTP）Stream」、RFC 6526、2012年3月。
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012.
[RFC6528] Gont、F。、およびS. Bellovin、「シーケンス番号攻撃に対する防御」、RFC 6528、2012年2月。
[RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 2012.
[RFC6615] Dietz、T.、Ed。、Kobayashi、A.、Claise、B.、およびG. Muenz、「Definions of Managed Objects for IP Flow Information Export」、RFC 6615、2012年6月。
[RFC6727] Dietz, T., Ed., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", RFC 6727, October 2012.
[RFC6727] Dietz、T.、Ed。、Claise、B。、およびJ. Quittek、「Definions of Managed Objects for Packet Sampling」、RFC 6727、2012年10月。
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, October 2012.
[RFC6728] Muenz、G.、Claise、B。、およびP. Aitken、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）プロトコルの構成データモデル」、RFC 6728、2012年10月。
[UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", The Unicode Consortium, July 2012.
[UTF8-EXPLOIT] Davis、M.およびM. Suignard、「Unicode Technical Report＃36：Unicode Security Considerations」、Unicode Consortium、2012年7月。
Acknowledgments
謝辞
We would like to thank Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification. Additional thanks go to Juergen Quittek for coordination between IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, and Andrew Johnson for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise and contributions; Martin Djernaes for the first essay on the SCTP section; Michael Behringer and Eric Vyncke for their advice and knowledge in security; Michael Tuexen for his help regarding the DTLS section; Elisa Boschi for her contribution regarding the improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, Sue Hares, and many more, for the technical reviews and feedback. Finally, a special mention to Adrian Farrel for his attention to management and operational aspects.
プロトコル仕様の初期段階におけるGanesh Sadasivanの多大な貢献に感謝します。さらに、IPFIXとPSAMP間の調整についてJuergen Quittekに感謝します。徹底的なレビューを行ったNevil Brownlee、Dave Plonka、Andrew Johnson。 SCTPの専門知識と貢献に対するRandall StewartとPeter Lei。 SCTPセクションの最初のエッセイのためのMartin Djernaes;セキュリティに関するアドバイスと知識を提供してくれたMichael BehringerとEric Vyncke。 DTLSセクションに関する彼の助力に対するMichael Tuexen; SCTPセクションの改善に関する彼女の貢献に対するElisa Boschi;テクニカルレビューとフィードバックについては、Mark Fullmer、Sebastian Zander、Jeff Meyer、Maurizio Molina、Carter Bullard、Tal Givoly、Lutz Mark、David Moore、Robert Lowe、Paul Calato、Andrew Feren、Gerhard Muenz、Sue Haresなど多数。最後に、管理と運用の側面に注意を向けたAdrian Farrelへの特別な言及。
Contributors
貢献者
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA United Kingdom
Stewart Bryant Cisco Systems 10 New Square、Bedfont Lakes Feltham、Middlesex TW18 8HAイギリス
EMail: stbryant@cisco.com
Simon Leinen SWITCH Werdstrasse 2 P.O. Box 8021 Zurich Switzerland
Simon Leinen SWITCH Werdstrasse 2 P.O. Box 8021チューリッヒスイス
Phone: +41 44 268 1536
EMail: simon.leinen@switch.ch
Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany
Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany
Phone: +49 6221 4342-128
EMail: Thomas.Dietz@nw.neclab.eu
Authors' Addresses
著者のアドレス
Benoit Claise (editor) Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise（編集者）Cisco Systems、Inc. De Kleetlaan 6a b1 1831 Diegemベルギー
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Brian Trammell (editor) Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメル（編集者）スイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street, Edinburgh EH6 6LX United Kingdom
Paul Aitken Cisco Systems、Inc. 96 Commercial Quay Commercial Street、Edinburgh EH6 6LX United Kingdom
Phone: +44 131 561 3616
EMail: paitken@cisco.com