[要約] RFC 5655は、IPFIXファイル形式の仕様を定めたものであり、IPフロー情報のエクスポートに使用されます。目的は、ネットワークトラフィックの分析や監視において、IPフロー情報を効果的に収集・転送・保存するためです。
Network Working Group B. Trammell
Request for Comments: 5655 E. Boschi
Category: Standards Track Hitachi Europe
L. Mark
Fraunhofer IFAM
T. Zseby
Fraunhofer FOKUS
A. Wagner
ETH Zurich
October 2009
Specification of the IP Flow Information Export (IPFIX) File Format
IPフロー情報エクスポート（IPFIX）ファイル形式の指定
Abstract
概要
This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools.
このドキュメントでは、IPフロー情報エクスポート（IPFIX）プロトコルに基づいて、フローデータのストレージのファイル形式について説明します。フラットファイルのバイナリフローデータファイル形式の一連の要件を提案し、IPFIXメッセージに基づいてこれらの要件を満たすIPFIXファイル形式を指定します。このIPFIXファイル形式は、さまざまなフローストレージ、処理、および分析ツールの間の相互運用性と再利用性を促進するように設計されています。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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 BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................5
3. Design Overview .................................................6
4. Motivation ......................................................7
5. Requirements ...................................................10
5.1. Record Format Flexibility .................................10
5.2. Self-Description ..........................................10
5.3. Data Compression ..........................................11
5.4. Indexing and Searching ....................................11
5.5. Error Recovery ............................................12
5.6. Authentication, Confidentiality, and Integrity ............12
5.7. Anonymization and Obfuscation .............................13
5.8. Session Auditability and Replayability ....................13
5.9. Performance Characteristics ...............................14
6. Applicability ..................................................14
6.1. Storage of IPFIX-Collected Flow Data ......................14
6.2. Storage of NetFlow-V9-Collected Flow Data .................15
6.3. Testing IPFIX Collecting Processes ........................15
6.4. IPFIX Device Diagnostics ..................................16
7. Detailed File Format Specification .............................16
7.1. File Reader Specification .................................16
7.2. File Writer Specification .................................17
7.3. Specific File Writer Use Cases ............................18
7.3.1. Collocating a File Writer with a Collecting
Process ............................................18
7.3.2. Collocating a File Writer with a Metering Process ..19
7.3.3. Using IPFIX Files for Archival Storage .............20
7.3.4. Using IPFIX Files as Documents .....................20
7.3.5. Using IPFIX Files for Testing ......................21
7.3.6. Writing IPFIX Files for Device Diagnostics .........22
7.3.7. IPFIX File Manipulation ............................22
7.4. Media Type of IPFIX Files .................................22
8. File Format Metadata Specification .............................22
8.1. Recommended Options Templates for IPFIX Files .............22
8.1.1. Message Checksum Options Template ..................23
8.1.2. File Time Window Options Template ..................23
8.1.3. Export Session Details Options Template ............24
8.1.4. Message Details Options Template ...................26
8.2. Recommended Information Elements for IPFIX Files ..........29
8.2.1. collectionTimeMilliseconds .........................29
8.2.2. collectorCertificate ...............................29
8.2.3. exporterCertificate ................................29
8.2.4. exportSctpStreamId .................................30
8.2.5. maxExportSeconds ...................................30
8.2.6. maxFlowEndMicroseconds .............................30
8.2.7. maxFlowEndMilliseconds .............................31
8.2.8. maxFlowEndNanoseconds ..............................31
8.2.9. maxFlowEndSeconds ..................................32
8.2.10. messageMD5Checksum ................................32
8.2.11. messageScope ......................................32
8.2.12. minExportSeconds ..................................33
8.2.13. minFlowStartMicroseconds ..........................33
8.2.14. minFlowStartMilliseconds ..........................34
8.2.15. minFlowStartNanoseconds ...........................34
8.2.16. minFlowStartSeconds ...............................34
8.2.17. opaqueOctets ......................................35
8.2.18. sessionScope ......................................35
9. Signing and Encryption of IPFIX Files ..........................36
9.1. CMS Detached Signatures ...................................36
9.1.1. ContentInfo ........................................37
9.1.2. SignedData .........................................38
9.1.3. SignerInfo .........................................38
9.1.4. EncapsulatedContentInfo ............................39
9.2. Encryption Error Resilience ...............................39
10. Compression of IPFIX Files ....................................39
10.1. Supported Compression Formats ............................40
10.2. Compression Recognition at the File Reader ...............40
10.3. Compression Error Resilience .............................40
11. Recommended File Integration Strategies .......................41
11.1. Encapsulation of Non-IPFIX Data in IPFIX Files ...........41
11.2. Encapsulation of IPFIX Files within Other File Formats ...42
12. Security Considerations .......................................42
12.1. Relationship between IPFIX File and Transport
Encryption ...............................................43
12.2. End-to-End Assertions for IPFIX Files ....................43
12.3. Recommendations for Strength of Cryptography for
IPFIX Files ..............................................44
13. IANA Considerations ...........................................44
14. Acknowledgements ..............................................46
15. References ....................................................47
15.1. Normative References .....................................47
15.2. Informative References ...................................48
Appendix A. Example IPFIX File ...................................49
A.1. Example Options Templates .................................50
A.2. Example Supplemental Options Data .........................52
A.3. Example Message Checksum ..................................54
A.4. File Example Data Set .....................................55
A.5. Complete File Example .....................................55
Appendix B. Applicability of IPFIX Files to NetFlow V9 Flow
Storage ..............................................57
B.1. Comparing NetFlow V9 to IPFIX .............................57
B.1.1. Message Header Format .................................57
B.1.2. Set Header Format .....................................58
B.1.3. Template Format .......................................59
B.1.4. Information Model .....................................59
B.1.5. Template Management ...................................59
B.1.6. Transport .............................................59
B.2. A Method for Transforming NetFlow V9 Messages to IPFIX ....60
B.3. NetFlow V9 Transformation Example .........................61
This document specifies a file format based upon IPFIX, designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. It begins with an overview of the IPFIX File format, and a quick summary of how IPFIX Files work in Section 3. The detailed specification of the IPFIX File format appears in Section 7; this section includes general specifications for IPFIX File Readers and IPFIX File Writers and specific recommendations for common situations in which they are used. The format makes use of the IPFIX Options mechanism for additional file metadata, in order to avoid requiring any protocol extensions, and to minimize the effort required to adapt IPFIX implementations to use the file format; a detailed definition of the Options Templates used for storage metadata appears in Section 8. Appendix A contains a detailed example IPFIX File.
このドキュメントは、IPFIXに基づいたファイル形式を指定します。これは、さまざまなフローストレージ、処理、分析ツール間の相互運用性と再利用性を促進するように設計されています。IPFIXファイル形式の概要と、IPFIXファイルの機能の仕組みの簡単な要約から始まります。IPFIXファイル形式の詳細な仕様はセクション7に表示されます。このセクションには、IPFIXファイルリーダーの一般的な仕様とIPFIXファイルライターと、それらが使用されている一般的な状況に関する具体的な推奨事項が含まれています。この形式は、プロトコル拡張機能を必要としないように、追加ファイルメタデータのIPFIXオプションメカニズムを使用し、ファイル形式を使用するためにIPFIXの実装を適応させるために必要な努力を最小限に抑えるためです。ストレージメタデータに使用されるオプションテンプレートの詳細な定義は、セクション8に表示されます。付録Aには、詳細な例IPFIXファイルが含まれています。
An advantage of file-based storage is that files can be readily encapsulated within each other and other data storage and transmission formats. The IPFIX File format leverages this to provide encryption, described in Section 9 and compression, described in Section 10. Section 11 provides specific recommendations for integration of IPFIX File data with other formats.
ファイルベースのストレージの利点は、ファイルを互いに容易にカプセル化し、他のデータストレージと送信形式をカプセル化できることです。IPFIXファイル形式は、これを活用して、セクション9および圧縮で説明されている暗号化を提供します。セクション11で説明されています。セクション11では、IPFIXファイルデータを他の形式と統合するための特定の推奨事項を提供します。
The IPFIX File format was designed to be applicable to a wide variety of flow storage situations; the motivation behind its creation is described in Section 4. The document outlines of the set of requirements the format is designed to meet in Section 5, and explores the applicability of such a format to various specific application areas in Section 6. These sections are intended to give background on the development of IPFIX Files.
IPFIXファイル形式は、さまざまなフローストレージの状況に適用できるように設計されています。その作成の背後にある動機については、セクション4で説明します。一連の要件のドキュメントの概要形式はセクション5で満たすように設計されており、セクション6のさまざまな特定のアプリケーション領域へのこのような形式の適用性を調査します。これらのセクションは意図しています。IPFIXファイルの開発の背景を示す。
"Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information" [RFC5101] and its associated documents define the IPFIX protocol, which provides network engineers and administrators with access to IP traffic flow information.
「IPトラフィックフロー情報の交換用のIPフロー情報エクスポート（IPFIX）プロトコルの仕様[RFC5101]とその関連ドキュメントは、IPFIXプロトコルを定義します。
"Architecture for IP Flow Information Export" [RFC5470] defines the architecture for the export of measured IP flow information out of an IPFIX Exporting Process to an IPFIX Collecting Process, and the basic terminology used to describe the elements of this architecture, per the requirements defined in "Requirements for IP Flow Information Export" [RFC3917]. [RFC5101] then covers the details of the method for transporting IPFIX Data Records and Templates via a congestion-aware transport protocol from an IPFIX Exporting Process to an IPFIX
「IPフロー情報エクスポートのアーキテクチャ」[RFC5470]は、IPFIXエクスポートプロセスからIPFIXの収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャを定義し、要件ごとにこのアーキテクチャの要素を記述するために使用される基本的な用語を定義します。「IPフロー情報エクスポートの要件」[RFC3917]で定義されています。[RFC5101]次に、IPFIXの輸送プロトコルを介してIPFIXデータレコードとテンプレートをIPFIXエクスポートプロセスからIPFIXに輸送する方法の詳細をカバーします
Collecting Process.
収集プロセス。
"Information Model for IP Flow Information Export" [RFC5102] describes the Information Elements used by IPFIX, including details on Information Element naming, numbering, and data type encoding.
「IPフロー情報エクスポートの情報モデル」[RFC5102]は、情報要素の命名、番号付け、データ型エンコードの詳細を含むIPFIXが使用する情報要素を説明しています。
"IP Flow Information Export (IPFIX) Applicability" [RFC5472] describes the various applications of the IPFIX protocol and their use of information exported via IPFIX, and it relates the IPFIX architecture to other measurement architectures and frameworks.
「IPフロー情報エクスポート（IPFIX）アプリケーション」[RFC5472]は、IPFIXプロトコルのさまざまなアプリケーションとIPFIXを介してエクスポートされる情報の使用について説明し、IPFIXアーキテクチャを他の測定アーキテクチャとフレームワークに関連付けます。
In addition, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements" [RFC5610] specifies a method for encoding Information Model properties within an IPFIX Message stream.
さらに、「IPフロー情報エクスポート（IPFIX）情報要素のタイプ情報のエクスポート」[RFC5610]は、IPFIXメッセージストリーム内の情報モデルプロパティをエンコードする方法を指定します。
This document references [RFC5101] and [RFC5470] for terminology, defines IPFIX File Writer and IPFIX File Reader in terms of the IPFIX Exporting Process and IPFIX Collecting Process definitions from [RFC5101], and extends the IPFIX Information Model defined in [RFC5102] to provide new Information Elements for IPFIX File metadata. It uses the method described in [RFC5610] to support the self-description of IPFIX Files containing enterprise-specific Information Elements.
このドキュメントは、用語について[RFC5101]および[RFC5470]を参照し、[RFC5101]からIPFIXファイルライターとIPFIXファイルリーダーをIPFIXエクスポートプロセスとIPFIXを収集するプロセス定義を収集し、[RFC5102]で定義されているIPFIX情報モデルを拡張し、[RFC5102]に定義します。IPFIXファイルメタデータに新しい情報要素を提供します。[RFC5610]で説明されている方法を使用して、エンタープライズ固有の情報要素を含むIPFIXファイルの自己説明をサポートします。
This section defines terminology related to the IPFIX File format. In addition, terms used in this document that are defined in the "Terminology" section of [RFC5101] are to be interpreted as defined there.
このセクションでは、IPFIXファイル形式に関連する用語を定義します。さらに、[RFC5101]の「用語」セクションで定義されているこのドキュメントで使用される用語は、そこで定義されていると解釈されます。
IPFIX File: An IPFIX File is a serialized stream of IPFIX Messages; this stream may be stored on a filesystem or transported using any technique customarily used for files. Any IPFIX Message stream that would be considered valid when transported over one or more of the specified IPFIX transports (Stream Control Transmission Protocol (SCTP), TCP, or UDP) as defined in [RFC5101] is considered an IPFIX File. However, this document extends that definition with recommendations on the construction of IPFIX Files that meet the requirements identified in Section 5.
IPFIXファイル：IPFIXファイルは、IPFIXメッセージのシリアル化されたストリームです。このストリームは、ファイルシステムに保存するか、ファイルに使用される任意の手法を使用して輸送される場合があります。[RFC5101]で定義されているように、指定されたIPFIXトランスポンド（ストリーム制御伝送プロトコル（SCTP）、TCP、またはUDP）の1つまたは複数の場合に輸送されたときに有効と見なされるIPFIXメッセージストリームは、IPFixファイルと見なされます。ただし、このドキュメントは、セクション5で特定された要件を満たすIPFIXファイルの構築に関する推奨事項で、その定義を拡張します。
IPFIX File Reader: An IPFIX File Reader is a process that reads IPFIX Files from a filesystem. An IPFIX File Reader operates as an IPFIX Collecting Process as specified in [RFC5101], except as modified by this document.
IPFIXファイルリーダー：IPFIXファイルリーダーは、ファイルシステムからIPFIXファイルを読み取るプロセスです。IPFIXファイルリーダーは、[RFC5101]で指定されているように、このドキュメントで変更された場合を除き、IPFIX収集プロセスとして動作します。
IPFIX File Writer: An IPFIX File Writer is a process that writes IPFIX Files to a filesystem. An IPFIX File Writer operates as an IPFIX Exporting Process as specified in [RFC5101], except as modified by this document.
IPFIXファイルライター：IPFIXファイルライターは、IPFIXファイルをファイルシステムに書き込むプロセスです。IPFIXファイルライターは、[RFC5101]で指定されているように、このドキュメントで変更された場合を除き、IPFIXエクスポートプロセスとして動作します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
An IPFIX File is simply a data stream containing one or more IPFIX Messages serialized to some filesystem. Though any set of valid IPFIX Messages can be serialized into an IPFIX File, the specification includes guidelines designed to ease storage and retrieval of flow data using the IPFIX File format.
IPFIXファイルは、一部のファイルシステムにシリアル化された1つ以上のIPFIXメッセージを含むデータストリームです。有効なIPFIXメッセージのセットはIPFIXファイルにシリアル化できますが、仕様には、IPFIXファイル形式を使用してストレージとフローデータの取得を容易にするために設計されたガイドラインが含まれています。
IPFIX Files contain only IPFIX Messages; any file metadata such as checksums or export session details are stored using Options within the IPFIX Message. This design is completely compatible with the IPFIX protocol on the wire. A schematic of a typical IPFIX File is shown below:
IPFIXファイルにはIPFIXメッセージのみが含まれています。チェックサムやエクスポートセッションの詳細などのファイルメタデータは、IPFIXメッセージ内のオプションを使用して保存されます。この設計は、ワイヤー上のIPFIXプロトコルと完全に互換性があります。典型的なIPFIXファイルの概略図を以下に示します。
+=======================================+
| IPFIX File |
| +===================================+ |
| | IPFIX Message | |
| | +-------------------------------+ | |
| | | IPFIX Message Header | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Options Template Set | | |
| | | Options Template Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Template Set | | |
| | | Template Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| +===================================+ |
| | IPFIX Message | |
| | +-------------------------------+ | |
| | | IPFIX Message Header | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Data Set | | |
| | | Data Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Data Set | | |
| | | Data Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | . . . | |
| +===================================+ |
| . . . |
+=======================================+
Figure 1: Typical File Structure
図1：典型的なファイル構造
There is a wide variety of applications for the file-based storage of IP flow data, across a continuum of time scales. Tools used in the analysis of flow data and creation of analysis products often use files as a convenient unit of work, with an ephemeral lifetime. A set of flows relevant to a security investigation may be stored in a file for the duration of that investigation, and further exchanged among incident handlers via email or within an external incident handling workflow application. Sets of flow data relevant to Internet measurement research may be published as files, much as libpcap [pcap] packet trace files are, to provide common datasets for the repeatability of research efforts; these files would have lifetimes measured in months or years. Operational flow measurement systems also have a need for long-term, archival storage of flow data, either as a primary flow data repository, or as a backing tier for online storage in a relational database management system (RDBMS).
タイムスケールの連続体にわたって、IPフローデータのファイルベースのストレージにはさまざまなアプリケーションがあります。フローデータの分析と分析製品の作成で使用されるツールは、しばしば一時的な寿命を備えた便利な作業単位としてファイルを使用します。セキュリティ調査に関連する一連のフローは、その調査の期間中ファイルに保存され、電子メールでインシデントハンドラー間でさらに交換されるか、外部インシデントワークフローアプリケーション内でさらに交換できます。インターネット測定に関連するフローデータのセットは、研究努力の再現性のための一般的なデータセットを提供するために、libpcap [pcap]パケットトレースファイルと同様に、ファイルとして公開される場合があります。これらのファイルには、寿命が数か月または数年で測定されます。運用フロー測定システムは、プライマリフローデータリポジトリとして、またはリレーショナルデータベース管理システム（RDBMS）のオンラインストレージのバッキング層として、フローデータの長期的なアーカイブストレージも必要です。
The variety of applications of flow data, and the variety of presently deployed storage approaches, indicates the need for a standard approach to flow storage with applicability across the continuum of time scales over which flow data is stored. A storage format based around flat files would best address the variety of storage requirements. While much work has been done on structured storage via RDBMS, relational database systems are not a good basis for format standardization owing to the fact that their internal data structures are generally private to a single implementation and subject to change for internal reasons. Also, there are a wide variety of operations available on flat files, and external tools and standards can be leveraged to meet file-based flow storage requirements. Further, flow data is often not very semantically complicated, and is managed in very high volume; therefore, an RDBMS-based flow storage system would not benefit much from the advantages of relational database technology.
フローデータのさまざまなアプリケーション、および現在展開されているストレージアプローチの多様性は、フローデータが保存されている時間スケールの連続体にわたって適用されるフローストレージを備えた標準的なアプローチの必要性を示しています。フラットファイルに基づいたストレージ形式は、さまざまなストレージ要件に最適に対処します。RDBMSを介した構造化されたストレージでは多くの作業が行われていますが、リレーショナルデータベースシステムは、内部のデータ構造が一般に単一の実装と非公開であり、内部的な理由で変更される可能性があるため、フォーマット標準化の適切な基礎ではありません。また、フラットファイルで利用可能な幅広い操作があり、ファイルベースのフローストレージ要件を満たすために外部ツールと標準を活用できます。さらに、フローデータは多くの場合、それほど意味的には複雑ではなく、非常に大量に管理されています。したがって、RDBMSベースのフローストレージシステムは、リレーショナルデータベーステクノロジーの利点からはあまり利益を得ません。
The simplest way to create a new file format is simply to serialize some internal data model to disk, with either textual or binary representation of data elements, and some framing strategy for delimiting fields and records. "Ad hoc" file formats such as this have several important disadvantages. They impose the semantics of the data model from which they are derived on the file format, and as such, they are difficult to extend, describe, and standardize.
新しいファイル形式を作成する最も簡単な方法は、データ要素のテキスト表現またはバイナリ表現、およびフィールドとレコードを区切るためのフレーミング戦略を使用して、一部の内部データモデルをディスクにシリアル化することです。このような「アドホック」ファイル形式には、いくつかの重要な欠点があります。彼らは、ファイル形式で導出されるデータモデルのセマンティクスを課しているため、拡張、説明、標準化が困難です。
Indeed, one de facto standard for the storage of flow data is one of these ad hoc formats. A common method of storing data collected via Cisco NetFlow is to serialize a stream of raw NetFlow datagrams into files. These NetFlow PDU files consist of a collection of header-prefixed blocks (corresponding to the datagrams as received on the wire) containing fixed-length binary flow records. NetFlow V5, V7, and V8 data may be mixed within a given file, as the header on each datagram defines the NetFlow version of the records following. While this NetFlow PDU file format has all the disadvantages of an ad hoc format, and is not extensible to data models other than that defined by Cisco NetFlow, it is at least reasonably well understood due to its ubiquity.
実際、フローデータの保存に関する事実上の標準の1つは、これらのアドホック形式の1つです。Cisco Netflowを介して収集されたデータを保存する一般的な方法は、生のNetflowデータグラムのストリームをファイルにシリアル化することです。これらのNetflow PDUファイルは、固定長のバイナリフローレコードを含むヘッダーが育てられたブロック（ワイヤーで受信したデータグラムに対応）のコレクションで構成されています。Netflow V5、V7、およびV8データは、各データグラムのヘッダーがレコードのNetflowバージョンを定義しているため、特定のファイル内で混合される場合があります。このNetflow PDUファイル形式には、アドホック形式のすべての欠点があり、Cisco Netflowで定義されているもの以外のデータモデルには拡張できませんが、その遍在のために少なくとも合理的によく理解されています。
Over the past decade, XML has emerged as a new "universal" representation format for structured data. It is intended to be human readable; indeed, that is one reason for its rapid adoption. However, XML has limited usefulness for representing network flow data. Network flow data has a simple, repetitive, non-hierarchical structure that does not benefit much from XML. An XML representation of flow data would be an essentially flat list of the attributes and their values for each flow record.
過去10年間で、XMLは構造化データの新しい「ユニバーサル」表現形式として浮上してきました。それは人間が読みやすいことを意図しています。実際、それが急速な採用の理由の1つです。ただし、XMLは、ネットワークフローデータを表すための有用性が限られています。ネットワークフローデータには、XMLからあまり利益を得ない、単純で反復的な非階層構造があります。フローデータのXML表現は、各フローレコードの属性とその値の本質的にフラットなリストになります。
The XML approach to data encoding is very heavyweight when compared to binary flow encoding. XML's use of start- and end-tags, and plaintext encoding of the actual values, leads to significant inefficiency in encoding size. Typical network traffic datasets can contain millions or billions of flows per hour of traffic represented. Any increase in storage size per record can have dramatic impact on flow data storage and transfer sizes. While data compression algorithms can partially remove the redundancy introduced by XML encoding, they introduce additional overhead of their own.
データエンコードへのXMLアプローチは、バイナリフローエンコードと比較すると非常にヘビー級です。XMLの開始および終了タグの使用、および実際の値のプレーンテキストエンコードにより、エンコードサイズの有意な非効率性が発生します。典型的なネットワークトラフィックデータセットには、1時間あたり数百万または数十億の流れが表される可能性があります。レコードごとのストレージサイズの増加は、フローデータのストレージと転送サイズに劇的な影響を与える可能性があります。データ圧縮アルゴリズムは、XMLエンコードによって導入された冗長性を部分的に削除できますが、独自の追加のオーバーヘッドを導入します。
A further problem is that XML processing tools require a full XML parser. XML parsers are fully general and therefore complex, resource-intensive, and relatively slow, introducing significant processing time overhead for large network-flow datasets. In contrast, parsers for typical binary flow data encodings are simply structured, since they only need to parse a very small header and then have complete knowledge of all following fields for the particular flow. These can then be read in a very efficient linear fashion.
さらなる問題は、XML処理ツールには完全なXMLパーサーが必要であることです。XMLパーサーは完全に一般的であり、したがって複雑でリソース集約型で、比較的遅いため、大きなネットワークフローデータセットに重要な処理時間オーバーヘッドが導入されます。対照的に、典型的なバイナリフローデータエンコーディングのパーサーは、非常に小さなヘッダーを解析するだけで、特定のフローのすべてのフォローフィールドに関する完全な知識を得る必要があるため、単純に構成されています。これらは、非常に効率的な線形ファッションで読み取ることができます。
This leads us to propose the IPFIX Message format as the basis for a new flow data file format. The IPFIX Working Group, in defining the IPFIX protocol, has already defined an information model and data formatting rules for representation of flow data. Especially at shorter time scales, when a file is a unit of data interchange, the filesystem may be viewed as simply another IPFIX Message transport between processes. This format is especially well suited to representing flow data, as it was designed specifically for flow data export; it is easily extensible, unlike ad hoc serialization, and compact, unlike XML. In addition, IPFIX is an IETF Standards-Track protocol for the export and collection of flow data; using a common format for storage and analysis at the collection side allows implementors to use substantially the same information model and data formatting implementation for transport as well as storage.
これにより、新しいフローデータファイル形式の基礎としてIPFIXメッセージ形式を提案することになります。IPFIXプロトコルを定義する際に、IPFIXワーキンググループは、フローデータを表現するための情報モデルとデータのフォーマットルールを既に定義しています。特に短い時間スケールでは、ファイルがデータ交換の単位である場合、ファイルシステムは、プロセス間の単なる別のIPFIXメッセージトランスポートと見なされる場合があります。この形式は、フローデータのエクスポート専用に設計されているため、フローデータを表すのに特に適しています。アドホックシリアル化とは異なり、XMLとは異なり、コンパクトに簡単に拡張できます。さらに、IPFIXは、フローデータのエクスポートと収集のIETF標準トラックプロトコルです。コレクション側でのストレージと分析のために共通の形式を使用すると、実装者は実質的に同じ情報モデルを使用し、トランスポートとストレージの実装をフォーマットすることができます。
In this section, we outline a proposed set of requirements [SAINT2007] for any persistent storage format for flow data. First and foremost, a flow data file format should support storage across the continuum of time scales important to flow storage applications. Each of the requirements enumerated in the sections below is broadly applicable to flow storage applications, though each may be more important at certain time scales. For each, we first identify the requirement, then explain how the IPFIX Message format addresses it, or briefly outline the changes that must be made in order for an IPFIX-based file format to meet the requirement.
このセクションでは、フローデータの永続的なストレージ形式について、提案された一連の要件[SAINT2007]の概要を説明します。何よりもまず、フローデータファイル形式は、フローストレージアプリケーションにとって重要な時間スケールの連続体全体のストレージをサポートする必要があります。以下のセクションで列挙されている各要件は、フローストレージアプリケーションに広く適用されますが、それぞれが特定の時間スケールでより重要になる可能性があります。それぞれについて、最初に要件を特定し、次にIPFIXメッセージ形式がどのようにアドレス指定するかを説明するか、IPFIXベースのファイル形式が要件を満たすために行う必要がある変更を簡単に概説します。
Due to the wide variety of flow attributes collected by different network flow attribute measurement systems, the ideal flow storage format will not impose a single data model or a specific record type on the flows it stores. The file format must be flexible and extensible; that is, it must support the definition of multiple record types within the file itself, and must be able to support new field types for data within the records in a graceful way.
さまざまなネットワークフロー属性測定システムによって収集された多種多様なフロー属性により、理想的なフローストレージ形式では、保存するフローに単一のデータモデルまたは特定のレコードタイプが課されません。ファイル形式は柔軟で拡張可能でなければなりません。つまり、ファイル自体内の複数のレコードタイプの定義をサポートする必要があり、レコード内のデータの新しいフィールドタイプを優雅な方法でサポートできる必要があります。
IPFIX provides record format flexibility through the use of Templates to describe each Data Record, through the use of an IANA Registry to define its Information Elements, and through the use of enterprise-specific Information Elements.
IPFIXは、各データレコードを記述するためのテンプレートを使用して、IANAレジストリを使用して情報要素を定義し、エンタープライズ固有の情報要素を使用することにより、レコード形式の柔軟性を提供します。
Archived data may be read at a time in the future when any external reference to the meaning of the data may be lost. The ideal flow storage format should be self-describing; that is, a process reading flow data from storage should be able to properly interpret the stored flows without reference to anything other than standard sources (e.g., the standards document describing the file format) and the stored flow data itself.
アーカイブデータは、データの意味を外部的に参照することが失われる可能性がある場合に、将来的に読み取ることができます。理想的なフローストレージ形式は、自己記述する必要があります。つまり、ストレージからフローデータを読み取るプロセスは、標準のソース（ファイル形式を説明する標準ドキュメント）および保存されたフローデータ自体を参照することなく、保存されたフローを適切に解釈できる必要があります。
The IPFIX Message format is partially self-describing; that is, IPFIX Templates containing only IANA-assigned Information Elements can be completely interpreted according to the IPFIX Information Model without additional external data.
IPFIXメッセージ形式は、部分的に自己記述的です。つまり、IANAが割り当てられた情報要素のみを含むIPFIXテンプレートは、追加の外部データなしでIPFIX情報モデルに従って完全に解釈できます。
However, Templates containing private information elements lack detailed type and semantic information; a Collecting Process receiving Data Records described by a Template containing enterprise-specific Information Elements it does not understand can only treat the data contained within those Information Elements as octet arrays.
ただし、個人情報要素を含むテンプレートには、詳細なタイプとセマンティック情報がありません。理解できないエンタープライズ固有の情報要素を含むテンプレートで説明されているデータレコードを受信する収集プロセスは、それらの情報要素に含まれるデータのみをOctetアレイとして扱うことができます。
To be fully self-describing, enterprise-specific Information Elements must be additionally described via IPFIX Options according to the Information Element Type Options Template defined in [RFC5610].
完全に説明するには、[RFC5610]で定義されている情報要素タイプオプションテンプレートに従って、IPFIXオプションを介してエンタープライズ固有の情報要素をさらに説明する必要があります。
Regardless of the representation format, flow data describing traffic on real networks tends to be highly compressible. Compression tends to improve the scalability of flow collection systems, by reducing the disk storage and I/O bandwidth requirement for a given workload. The ideal flow storage format should support applications that wish to leverage this fact by supporting compression of stored data.
The IPFIX Message format has no support for data compression, as the IPFIX protocol was designed for speed and simplicity of export. Of course, any flat file is readily compressible using a wide variety of external data compression tools, formats, and algorithms; therefore, this requirement can be met via encapsulation in one of these formats. Section 10 specifies an encapsulation based on bzip2 or gzip, to maximize interoperability.
IPFIXプロトコルは、エクスポートの速度とシンプルさのために設計されたため、IPFIXメッセージ形式はデータ圧縮をサポートしていません。もちろん、さまざまな外部データ圧縮ツール、形式、およびアルゴリズムを使用して、フラットファイルは容易に圧縮できます。したがって、この要件は、これらの形式のいずれかでカプセル化を介して満たすことができます。セクション10は、相互運用性を最大化するために、BZIP2またはGZIPに基づいたカプセル化を指定します。
A few simple optimizations can be made by File Writers to increase the integrity and usability of compressed IPFIX data; these are outlined in Section 10.3.
圧縮IPFIXデータの整合性と使いやすさを高めるために、ファイルライターによっていくつかの簡単な最適化を行うことができます。これらはセクション10.3で概説されています。
Binary, record-stream-oriented file formats natively support only one form of searching: sequential scan in file order. By choosing the order of records in a file carefully (e.g., by flow end time), a file can be indexed by a single key.
バイナリ、レコードストリーム指向のファイル形式は、1つの検索形式のみをネイティブにサポートします。ファイルの順序でのシーケンシャルスキャン。ファイル内のレコードの順序を慎重に（フローエンドタイムごとに）選択することにより、ファイルは単一のキーでインデックス作成できます。
Beyond this, properly addressing indexing is an application-specific problem, as it inherently involves trade-offs between storage complexity and retrieval speed, and requirements vary widely based on time scales and the types of queries used from site to site. However, a generic standard flow storage format may provide limited direct support for indexing and searching.
これを超えて、適切に対処することはアプリケーション固有の問題です。これは、ストレージの複雑さと検索速度の間のトレードオフが本質的に関与しており、要件は時間スケールとサイトからサイトへの使用の種類に基づいて大きく異なります。ただし、一般的な標準フローストレージ形式は、インデックス作成と検索を直接サポートしています。
The ideal flow storage format will support a limited table of contents facility noting that the records in a file contain data relating only to certain keys or values of keys, in order to keep multi-file search implementations from having to scan a file for data it does not contain.
理想的なフローストレージ形式は、ファイル内のレコードには、マルチファイルの検索実装がデータをファイルをスキャンする必要がないようにするために、ファイル内のレコードに特定のキーまたはキーの値のみに関連するデータが含まれていることに注目する限られたテーブル施設をサポートします。含まれていません。
The IPFIX Message format has no direct support for indexing. However, the technique described in "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports"
IPFIXメッセージ形式は、インデックス作成を直接サポートしていません。ただし、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」で説明されている手法
[RFC5473] can be used to describe the contents of a file in a limited way. Additionally, as flow data is often sorted and divided by time, the start and end time of the flows in a file may be declared using the File Time Window Options Template defined in Section 8.1.2.
[RFC5473]は、ファイルの内容を限られた方法で説明するために使用できます。さらに、フローデータは多くの場合、時間で分割されて分割されるため、ファイル内のフローの開始時間と終了時間は、セクション8.1.2で定義されたファイルタイムウィンドウオプションテンプレートを使用して宣言できます。
When storing flow data for archival purposes, it is important to ensure that hardware or software faults do not introduce errors into the data over time. The ideal flow storage format will support the detection and correction of encoding-level errors in the data.
アーカイブの目的でフローデータを保存する場合、ハードウェアまたはソフトウェアの障害が時間の経過とともにデータにエラーを導入しないようにすることが重要です。理想的なフローストレージ形式は、データのエンコーディングレベルのエラーの検出と修正をサポートします。
Note that more advanced error correction is best handled at a layer below that addressed by this document. Error correction is a topic well addressed by the storage industry in general (e.g., by Redundant Array of Independent Disks (RAID) and other technologies). By specifying a flow storage format based upon files, we can leverage these features to meet this requirement.
より高度なエラー補正は、このドキュメントで扱われているレイヤーの下のレイヤーで最適に処理されることに注意してください。エラー修正は、一般的にストレージ業界が適切に対処するトピックです（例えば、独立したディスクの冗長な配列（RAID）およびその他のテクノロジー）。ファイルに基づいてフローストレージ形式を指定することにより、これらの機能を活用してこの要件を満たすことができます。
However, the ideal flow storage format will be resilient against errors, providing an internal facility for the detection of errors and the ability to isolate errors to as few data records as possible.
ただし、理想的なフローストレージ形式はエラーに対して回復力があり、エラーの検出とエラーを可能な限り少ないデータレコードに分離する能力のための内部機能を提供します。
Note that this requirement interacts with the choice of data compression or encryption algorithm. For example, the use of block compression algorithms can serve to isolate errors to a single compression block, unlike stream compressors, which may fail to resynchronize after a single bit error, invalidating the entire message stream.
この要件は、データ圧縮または暗号化アルゴリズムの選択と相互作用することに注意してください。たとえば、ブロック圧縮アルゴリズムの使用は、ストリームコンプレッサーとは異なり、単一の圧縮ブロックにエラーを分離するのに役立ちます。これは、1つのビットエラーの後に再同期に失敗する可能性があり、メッセージストリーム全体を無効にします。
The IPFIX Message format does not support data integrity assurance. It is assumed that advanced error correction will be provided externally. Compression and encryption, if used, provide some allowance for detection, if not correction, of errors. For simple error detection support in the absence of compression or encryption, checksums may be attached to messages via IPFIX Options according to the Message Checksum Options Template defined in Section 8.1.1.
IPFIXメッセージ形式は、データの整合性保証をサポートしていません。高度なエラー修正が外部から提供されると想定されています。圧縮と暗号化は、使用する場合、エラーの修正ではないにしても検出の許容量を提供します。圧縮または暗号化がない場合の単純なエラー検出サポートの場合、セクション8.1.1で定義されたメッセージチェックサムオプションテンプレートに従って、IPFIXオプションを介してメッセージに添付される場合があります。
Archival storage of flow data may also require assurance that no unauthorized entity can read or modify the stored data. Cryptography can be applied to this problem to ensure integrity and confidentiality by signing and encryption.
フローデータのアーカイブストレージには、許可されていないエンティティが保存されたデータを読み取ったり変更できないという保証が必要になる場合があります。この問題に暗号化を適用して、署名と暗号化により整合性と機密性を確保することができます。
As with error correction, this problem has been addressed well at a layer below that addressed by this document. We can leverage the fact that existing cryptographic technologies work quite well on data stored in files to meet this requirement.
エラー修正と同様に、この問題は、このドキュメントで扱われているレイヤーの下のレイヤーでよく対処されています。この要件を満たすために、既存の暗号化技術がファイルに保存されているデータに非常にうまく機能するという事実を活用できます。
Beyond support for the use of Transport Layer Security (TLS) for transport over TCP or Datagram Transport Layer Security (DTLS) for transport over SCTP or UDP, both of which provide transient authentication and confidentiality, the IPFIX protocol does not support this requirement directly. The IETF has specified the Cryptographic Message Syntax (CMS) [RFC3852] for creating detached signatures for integrity and authentication; Section 9 specifies a CMS-based method for signing IPFIX Files. Confidentiality protection is assumed to be met by methods external to this specification, leveraging one of the many such technologies for encrypting files to meet specific application and process requirements; however, notes on improving archival integrity of encrypted IPFIX Files are given in Section 9.2.
TCPまたはDatagram Transport Layer Security（DTLS）を介したTCPまたはDatagram Transport Layer Security（DTLS）を使用するための輸送層セキュリティ（TLS）の使用をサポートしてください。IETFは、整合性と認証のための分離署名を作成するために、暗号化メッセージ構文（CMS）[RFC3852]を指定しました。セクション9では、IPFIXファイルに署名するCMSベースの方法を指定しています。機密保護は、この仕様の外部の方法で満たされていると想定されており、特定のアプリケーションとプロセスの要件を満たすためにファイルを暗号化するための多くのそのような技術の1つを活用します。ただし、暗号化されたIPFIXファイルのアーカイブの整合性の改善に関するメモは、セクション9.2に記載されています。
To ensure the privacy of individuals and organizations at the endpoints of communications represented by flow records, it is often necessary to obfuscate or anonymize stored and exported flow data. The ideal flow storage format will provide for a notation that a given information element on a given record type represents anonymized, rather than real, data.
フローレコードで表される通信のエンドポイントで個人と組織のプライバシーを確保するには、多くの場合、保存およびエクスポートされたフローデータを難読化または匿名化する必要があります。理想的なフローストレージ形式は、特定のレコードタイプの特定の情報要素が実際のデータではなく匿名化されたものを表すという表記を提供します。
The IPFIX protocol presently has no support for anonymization notation. It should be noted that anonymization is one of the requirements given for IPFIX in [RFC3917]. The decision to qualify this requirement with 'MAY' and not 'MUST' in the requirements document, and its subsequent lack of specification in the current version of the IPFIX protocol, is due to the fact that anonymization algorithms are still an open area of research, and that there currently exist no standardized methods for anonymization.
No support is presently defined in [RFC5101] or this IPFIX-based File format for anonymization, as anonymization notation is an area of open work for the IPFIX Working Group.
匿名化表記はIPFIXワーキンググループのオープンワークの領域であるため、現在[RFC5101]またはこのIPFIXベースのファイル形式で匿名化用のサポートは定義されていません。
Certain use cases for archival flow storage require the storage of collection infrastructure details alongside the data itself. These details include information about how and when data was received, and where it was received from. They are useful for auditing as well as for the replaying received data for testing purposes.
アーカイブフローストレージの特定のユースケースでは、データ自体とともにコレクションインフラストラクチャの詳細を保存する必要があります。これらの詳細には、データがどのように、いつ受信されたか、どこから受信したかに関する情報が含まれます。これらは、監査や、テスト目的で受信したデータのリプレイに役立ちます。
The IPFIX protocol contains no direct support for auditability and replayability, though the IPFIX Information Model does define various Information Elements required to represent collection infrastructure details. These details may be stored in IPFIX Files using the Export Session Details Options Template defined in Section 8.1.3, and the Message Details Options Template defined in Section 8.1.4.
IPFIX情報モデルは、コレクションインフラストラクチャの詳細を表すために必要なさまざまな情報要素を定義しますが、IPFIXプロトコルには監査可能性と再生可能性に関する直接的なサポートは含まれていません。これらの詳細は、セクション8.1.3で定義されているエクスポートセッションの詳細オプションテンプレートと、セクション8.1.4で定義されているメッセージの詳細オプションテンプレートを使用して、IPFIXファイルに保存できます。
The ideal standard flow storage format will not have a significant negative impact on the performance of the application generating or processing flow data stored in the format. This is a non-functional requirement, but it is important to note that a standard that implies a significant performance penalty is unlikely to be widely implemented and adopted.
理想的な標準フローストレージ形式は、形式で保存されているアプリケーションまたは処理フローデータのパフォーマンスに大きなマイナスの影響を与えません。これは非機能的要件ですが、重要なパフォーマンスペナルティを暗示する基準が広く実装および採用される可能性は低いことに注意することが重要です。
An examination of the IPFIX protocol would seem to suggest that implementations of it are not particularly prone to slowness; indeed, a template-based data representation is more easily subject to optimization for common cases than representations that embed structural information directly in the data stream (e.g., XML). However, a full analysis of the impact of using IPFIX Messages as a basis for flow data storage on read/write performance will require more implementation experience and performance measurement.
IPFIXプロトコルの調査は、その実装が特に遅くなる傾向がないことを示唆しているようです。実際、テンプレートベースのデータ表現は、データストリーム（XMLなど）に構造情報を直接埋め込む表現よりも、一般的なケースの最適化をより簡単に対象とします。ただし、読み取り/書き込みパフォーマンスに関するフローデータストレージの基礎としてIPFIXメッセージを使用することの影響を完全に分析するには、より多くの実装エクスペリエンスとパフォーマンス測定が必要です。
This section describes the specific applicability of IPFIX Files to various use cases. IPFIX Files are particularly useful in a flow collection and processing infrastructure using IPFIX for flow export. We explore the applicability and provide guidelines for using IPFIX Files for the storage of flow data collected by IPFIX Collecting Processes and NetFlow V9 collectors, the testing of IPFIX Collecting Processes, and diagnostics of IPFIX Devices.
このセクションでは、さまざまなユースケースへのIPFIXファイルの特定の適用性について説明します。IPFIXファイルは、フローエクスポートにIPFIXを使用したフロー収集および処理インフラストラクチャで特に役立ちます。適用性を調査し、IPFIXの収集プロセスとNetFlow V9コレクターによって収集されたフローデータのストレージにIPFIXファイルを使用するためのガイドライン、IPFIX収集プロセスのテスト、IPFIXデバイスの診断を提供します。
IPFIX Files can naturally be used to store flow data collected by an IPFIX Collecting Process; indeed, this was one of the primary initial motivations behind the file format described within this document. Using IPFIX Files as such provides a single, standard, well-understood encoding to be used for flow data on disk and on the wire, and allows IPFIX implementations to leverage substantially the same code for flow export and flow storage. In addition, the storage of single Transport Sessions in IPFIX Files is particularly important for network measurement research, allowing repeatability of experiments by providing a format for the storage and exchange of IPFIX flow trace data much as the libpcap [pcap] format is used for experiments on packet trace data.
IPFIXファイルは、IPFIXの収集プロセスによって収集されたフローデータを保存するために自然に使用できます。実際、これは、このドキュメント内で説明されているファイル形式の背後にある主要な初期動機の1つでした。IPFIXファイルを使用すると、ディスクおよびワイヤー上のフローデータに使用するために、単一の標準的でよく理解されたエンコードが提供され、IPFIXの実装がフローエクスポートとフローストレージのコードを大幅に活用できます。さらに、IPFIXファイルでの単一輸送セッションのストレージは、ネットワーク測定研究にとって特に重要であり、LIBPCAP [PCAP]形式と同じくらいIPFIXフロートレースデータのストレージと交換の形式を提供することにより、実験の再現性を可能にします。パケットトレースデータ。
Although the IPFIX protocol is based on the Cisco NetFlow Services, Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged since work began on IPFIX. However, since the NetFlow V9 information model is a compatible subset of the IPFIX Information Model, it is possible to use IPFIX Files to store collected NetFlow V9 flow data. This approach may be particularly useful in multi-vendor, multi-protocol collection infrastructures using both NetFlow V9 and IPFIX to export flow data.
IPFIXプロトコルはCisco Netflow Services、バージョン9（Netflow V9）プロトコル[RFC3954]に基づいていますが、IPFIXでの作業が開始されてから2つは分岐しています。ただし、Netflow V9情報モデルはIPFIX情報モデルの互換性のあるサブセットであるため、IPFIXファイルを使用して収集されたNetflow V9フローデータを保存することができます。このアプローチは、Netflow V9とIPFIXの両方を使用してフローデータをエクスポートするマルチベンダー、マルチプロトコルコレクションインフラストラクチャで特に役立つ場合があります。
The applicability of IPFIX Files to this use case is outlined in Appendix B.
このユースケースへのIPFIXファイルの適用性は、付録Bで概説されています。
IPFIX Files can be used to store IPFIX Messages for the testing of IPFIX Collecting Processes. A variety of test cases may be stored in IPFIX Files. First, IPFIX data collected in real network environments and stored in an IPFIX File can be used as input to check the behavior of new or extended implementations of IPFIX Collectors. Furthermore, IPFIX Files can be used to validate the operation of a given IPFIX Collecting Process in a new environment, i.e., to test with recorded IPFIX data from the target network before installing the Collecting Process in the network.
IPFIXファイルを使用して、IPFIXの収集プロセスをテストするためにIPFIXメッセージを保存できます。さまざまなテストケースがIPFIXファイルに保存される場合があります。まず、実際のネットワーク環境で収集され、IPFIXファイルに保存されているIPFIXデータを入力として使用して、IPFIXコレクターの新しいまたは拡張実装の動作を確認できます。さらに、IPFIXファイルを使用して、特定のIPFIX収集プロセスの操作を新しい環境で検証することができます。つまり、ネットワークに収集プロセスをインストールする前に、ターゲットネットワークから記録されたIPFIXデータでテストします。
The IPFIX File format can also be used to store artificial, non-compliant reference messages for specific Collecting Process test cases. Examples for such test cases are sets of IPFIX records with undefined Information Elements, Data Records described by missing Templates, or incorrectly framed Messages or Data Sets. Representative error handling test cases are defined in [RFC5471].
IPFIXファイル形式は、特定の収集プロセステストケースのための人工的な非準拠の参照メッセージを保存するためにも使用できます。このようなテストケースの例は、未定義の情報要素を備えたIPFIXレコードのセット、欠落しているテンプレートで説明されているデータレコード、または誤ってフレーム化されたメッセージまたはデータセットです。代表的なエラー処理テストケースは[RFC5471]で定義されています。
Furthermore, fast replay of IPFIX Messages stored in a file can be used for stress/load tests (e.g., high rate of incoming Data Records, large Templates with high Information Element counts), as described in [RFC5471]. The provisioning and use of a set of reference files for testing simplifies the performance of tests and increases the comparability of test results.
さらに、ファイルに保存されているIPFIXメッセージの高速リプレイは、[RFC5471]で説明されているように、ストレス/負荷テストに使用できます（たとえば、着信データレコードの高いレート、高い情報要素カウントを持つ大きなテンプレート）。テストのための一連の参照ファイルのプロビジョニングと使用は、テストのパフォーマンスを簡素化し、テスト結果の比較可能性を向上させます。
As an IPFIX File can be used to store any collection of flows, the format may also be used for dumping and storing various types of flow data for IPFIX Device diagnostics (e.g., the open flow cache of a Metering Process or the flow backlog of an Exporting or Collecting Process at the time of a process reset or crash). File-based storage is preferable to remote transmission in such error-recovery situations.
IPFIXファイルを使用してフローのコレクションを保存できるため、フォーマットは、IPFIXデバイス診断のさまざまな種類のフローデータのダンプと保存にも使用できます（たとえば、計量プロセスのオープンフローキャッシュまたはプロセスのリセットまたはクラッシュの時点でのプロセスのエクスポートまたは収集）。ファイルベースのストレージは、このようなエラー回復状況でのリモート送信よりも望ましいです。
Any valid serialized IPFIX Message stream MUST be accepted by a File Reader as a valid IPFIX File. In this way, the filesystem is simply treated as another IPFIX transport alongside SCTP, TCP, and UDP, albeit a potentially high-latency transport, as the File Reader and File Writer do not necessarily run at the same time.
有効なシリアル化されたIPFIXメッセージストリームは、有効なIPFIXファイルとしてファイルリーダーによって受け入れられる必要があります。このようにして、ファイルシステムは、ファイルリーダーとファイルライターが必ずしも同時に実行されないため、潜在的に高速輸送ではありますが、SCTP、TCP、およびUDPと並んで別のIPFIXトランスポートとして単純に扱われます。
This section specifies the detailed actions of File Readers and File Writers in handling IPFIX Files, and further specifies actions of File Writers in specific use cases. Unless otherwise specified herein, IPFIX File Writers MUST behave as IPFIX Exporting Processes, and IPFIX File Readers MUST behave as IPFIX Collecting Processes, where appropriate.
このセクションでは、IPFIXファイルの処理におけるファイルリーダーとファイルライターの詳細なアクションを指定し、特定のユースケースでファイルライターのアクションをさらに指定します。本明細書に特に指定されていない限り、IPFIXファイルライターはIPFIXエクスポートプロセスとして動作する必要があり、IPFIXファイルリーダーは、必要に応じてIPFIXの収集プロセスとして動作する必要があります。
An IPFIX File Reader MUST act as an IPFIX Collecting Process as specified in [RFC5101], except as modified by this document.
IPFIXファイルリーダーは、[RFC5101]で指定されているように、このドキュメントで変更された場合を除き、IPFIX収集プロセスとして機能する必要があります。
An IPFIX File Reader MUST accept as valid any serialized IPFIX Message stream that would be considered valid by one or more of the other defined IPFIX transport layers. Practically, this means that the union of IPFIX Template management features supported by SCTP, TCP, and UDP MUST be supported in IPFIX Files. File Readers MUST:
IPFIXファイルリーダーは、他の1つまたは複数の定義されたIPFIXトランスポートレイヤーによって有効と見なされるシリアル化されたIPFIXメッセージストリームを有効なものとして受け入れる必要があります。実際には、これは、SCTP、TCP、およびUDPがサポートするIPFIXテンプレート管理機能の組合がIPFIXファイルでサポートする必要があることを意味します。ファイルリーダーは：
o accept IPFIX Messages containing Template Sets, Options Template Sets, and Data Sets within the same message, as with IPFIX over TCP or UDP;
o TCPまたはUDPを介したIPFIXと同様に、同じメッセージ内のテンプレートセット、オプションテンプレートセット、およびデータセットを含むIPFIXメッセージを受け入れます。
o accept Template Sets that define Templates already defined within the File, as may occur with retransmission of Templates when using IPFIX over UDP as described in Section 10.3.6 of [RFC5101];
o [RFC5101]のセクション10.3.6で説明されているように、UDPを介してIPFIXを使用する場合、テンプレートの再送信で発生する可能性があるように、ファイル内で既に定義されているテンプレートを定義するテンプレートセットを受け入れます。
o resolve any conflict between a resent definition and a previous definition by assuming that the new Template replaces the old, as consistent with Template expiration and ID reuse when using UDP at the IPFIX transport protocol; and
o IPFIXトランスポートプロトコルでUDPを使用する場合、新しいテンプレートが古いものを置き換えると仮定して、新しいテンプレートが古いものを置き換えると仮定することにより、resした定義と以前の定義の間の競合を解決します。と
o accept Template Withdrawals as described in Section 8 of [RFC5101], provided that the Template to be withdrawn is defined, as is the case with IPFIX over TCP and SCTP.
o [RFC5101]のセクション8で説明されているように、TCPおよびSCTPを介したIPFIXの場合と同様に、撤回するテンプレートが定義されている場合、テンプレートの引き出しを受け入れます。
Considering the filesystem-as-transport view, in the general case, an IPFIX File SHOULD be treated as containing a single Transport Session as defined by [RFC5101]. However, some applications may benefit from the ability to treat a collection of IPFIX Files as a single Transport Session; see especially Section 7.3.3 below. A File Reader MAY be configurable to treat a collection of Files as a single Transport Session. However, a File Reader MUST NOT treat a single IPFIX File as containing multiple Transport Sessions.
トランスポートとしてのファイルシステムのビューを考慮すると、一般的な場合、IPFIXファイルは[RFC5101]で定義されている単一の輸送セッションを含むものとして扱う必要があります。ただし、一部のアプリケーションは、IPFIXファイルのコレクションを単一のトランスポートセッションとして扱う機能の恩恵を受ける場合があります。特に以下のセクション7.3.3を参照してください。ファイルリーダーは、ファイルのコレクションを単一のトランスポートセッションとして扱うように構成できる場合があります。ただし、ファイルリーダーは、単一のIPFIXファイルを複数のトランスポートセッションを含むものとして扱ってはなりません。
If an IPFIX File uses the technique described in [RFC5473] AND all of the non-Options Templates in the File contain the commonPropertiesId Information Element, a File Reader MAY assume the set of commonPropertiesId definitions provides a complete table of contents for the File for searching purposes.
IPFIXファイルが[RFC5473]で説明されている手法を使用し、ファイル内のすべての非オプションテンプレートにCommonPropertiesID情報要素が含まれている場合、ファイルリーダーはCommonPropertiesID定義のセットが、検索のためのファイルの完全な内容の表を提供する場合があります。目的。
An IPFIX File Writer MUST act as an IPFIX Exporting Process as specified in [RFC5101], except as modified by this document. This section contains specifications for IPFIX File Writers in all situations; specifications and recommendations for specific File Writer use cases are found in Section 7.3 below.
IPFIXファイルライターは、[RFC5101]で指定されているように、このドキュメントで変更された場合を除き、IPFIXエクスポートプロセスとして機能する必要があります。このセクションには、あらゆる状況でIPFIXファイルライターの仕様が含まれています。特定のファイルライターユースケースの仕様と推奨事項は、以下のセクション7.3にあります。
File Writers SHOULD store the Templates and Options required to decode the data within the File itself, unless modified by the requirements of a specific use case in a subsection of Section 7.3. In this way, a single IPFIX File generally contains a single notional Transport Session as defined by [RFC5101].
ファイルライターは、セクション7.3のサブセクションで特定のユースケースの要件によって変更されない限り、ファイル自体内のデータをデコードするために必要なテンプレートとオプションを保存する必要があります。このようにして、単一のIPFIXファイルには、一般に[RFC5101]で定義されている単一の概念的な輸送セッションが含まれます。
File Writers SHOULD emit each Template Set or Options Template Set to appear in the File before any Data Set described by the Templates within that Set, to ensure the File Reader can decode every Data Set without waiting to process subsequent Templates or Options Templates.
ファイルライターは、そのセット内のテンプレートで説明されているデータセットの前にファイルに表示される各テンプレートセットまたはオプションテンプレートセットを発し、ファイルリーダーが後続のテンプレートまたはオプションテンプレートを処理するのを待つことなくすべてのデータセットをデコードできるようにする必要があります。
File Writers SHOULD emit Data Records described by Options Templates to appear in the File before any Data Records that depend on the scopes defined by those options.
ファイルライターは、オプションテンプレートで説明されているデータレコードを、それらのオプションで定義されたスコープに依存するデータレコードの前にファイルに表示されるように表示する必要があります。
File Writers SHOULD use Template Withdrawals to withdraw Templates if Template IDs need to be reused. Template Withdrawals SHOULD NOT be used unless it is necessary to reuse Template IDs.
ファイルライターは、テンプレートIDを再利用する必要がある場合、テンプレート引き出しを使用してテンプレートを引き出します。テンプレートの引き出しは、テンプレートIDを再利用する必要がない限り使用しないでください。
File Writers SHOULD write IPFIX Messages within an IPFIX File in ascending Export Time order.
ファイルライターは、昇順のエクスポート時間の注文でIPFIXファイル内にIPFIXメッセージを記述する必要があります。
File Writers MAY write Data Records to an IPFIX File in any order. However, File Writers that write flow records to an IPFIX File in flowStartTime or flowEndTime order SHOULD be consistent in this ordering within each File.
ファイルライターは、データレコードを任意の順序でipfixファイルに書き込むことができます。ただし、FlowStartTimeまたはFlowEndtimeの注文でFlow RecordsをIPFIXファイルに書き込むファイルライターは、各ファイル内のこの注文で一貫している必要があります。
The specifications in this section apply to specific situations. Each section below extends or modifies the base File Writer specification in Section 7.2. Considerations for collocation of a File Writer with IPFIX Collecting Processes and Metering Processes are given, as are specific guidelines for using IPFIX Files for archival storage, or as documents. Also covered are the use of IPFIX Files in the testing and diagnostics of IPFIX Devices.
このセクションの仕様は、特定の状況に適用されます。以下の各セクションでは、セクション7.2のベースファイルライターの仕様を拡張または変更します。IPFIXの収集プロセスと計量プロセスを使用したファイルライターのコロケーションに関する考慮事項は、アーカイブストレージにIPFIXファイルを使用するための特定のガイドライン、またはドキュメントとして与えられています。また、IPFIXデバイスのテストと診断でIPFIXファイルを使用することもカバーされています。
When collocating a File Writer with an IPFIX Collecting Process for archival storage of collected data in IPFIX Files as described in Section 6.1, the following recommendations may improve the usefulness of the stored data.
セクション6.1で説明されているように、IPFIXファイルで収集されたデータのアーカイブストレージのためのIPFIX収集プロセスでファイルライターをコロケートする場合、以下の推奨事項により、保存されたデータの有用性が向上する可能性があります。
The simplest way for a File Writer to store the data collected in a single Transport Session is to simply write the incoming IPFIX Messages to an IPFIX File as they are collected. This approach has several drawbacks. First, if the original Exporting Process did not conform to the recommendations in Section 7.2 with respect to Template and Data Record ordering, the written file can be difficult to use later; in this case, File Writers MAY reorder records as received in order to ensure that Templates appear before the Data Records they describe.
ファイルライターが単一のトランスポートセッションで収集されたデータを保存する最も簡単な方法は、収集されたときにIPFIXファイルに着信IPFIXメッセージを単純に書き込むことです。このアプローチにはいくつかの欠点があります。まず、元のエクスポートプロセスが、テンプレートとデータの記録順序に関するセクション7.2の推奨事項に準拠していなかった場合、書かれたファイルを後で使用するのが難しい場合があります。この場合、ファイルライターは、説明されたデータレコードの前にテンプレートが表示されることを確認するために、受信したようにレコードを並べ替えることができます。
A File Writer collocated with a Collecting Process that starts writing data from a running Transport Session SHOULD write all the Templates currently active within that Transport Session before writing any Data Records described by them.
実行中のトランスポートセッションからデータの書き込みを開始する収集プロセスとコロックされたファイルライターは、それらが説明したデータレコードを作成する前に、そのトランスポートセッション内で現在アクティブなテンプレートを作成する必要があります。
Also, the resulting IPFIX Files will lack information about the IPFIX Transport Session used to export them, such as the network addresses of the Exporting and Collecting Processes and the protocols used to transport them. In this case, if information about the Transport Session is required, the File Writer SHOULD store a single IPFIX Transport Session in an IPFIX File and SHOULD record information about the Transport Session using the Export Session Details Options Template described in Section 8.1.3.
また、結果のIPFIXファイルには、エクスポートと収集プロセスのネットワークアドレスやそれらを輸送するために使用されるプロトコルなど、エクスポートに使用されるIPFIXトランスポートセッションに関する情報がありません。この場合、トランスポートセッションに関する情報が必要な場合、ファイルライターはIPFIXファイルに単一のIPFIXトランスポートセッションを保存し、セクション8.1.3で説明したエクスポートセッションの詳細オプションテンプレートを使用してトランスポートセッションに関する情報を記録する必要があります。
Additional per-Message information MAY be recorded by the File Writer using the Message Details Options Template described in Section 8.1.4. Per-Message information includes the time at which each IPFIX Message was received at the Collecting Process, and can be used to resend IPFIX Messages while keeping the original measurement plane traffic profile.
セクション8.1.4で説明されているメッセージの詳細オプションテンプレートを使用して、ファイルライターによって追加の1人あたりの情報が記録される場合があります。メッセージごとの情報には、各IPFIXメッセージが収集プロセスで受信された時間が含まれ、元の測定プレーントラフィックプロファイルを維持しながらIPFIXメッセージを再送信するために使用できます。
When collocating a File Writer with a Collecting Process, the Export Time of each Message SHOULD be the Export Time of the Message received by the Collecting Process containing the first Data Record in the Message. Note that File Writers storing IPFIX data collected from an IPFIX Collecting Process using SCTP as the transport protocol SHOULD interleave messages from multiple streams in order to preserve Export Time order, and SHOULD reorder the written messages as necessary to ensure that each Template Set or Options Template Set appears in the File before any Data Set described by the Templates within that Set. Template reordering MUST preserve the sequence of Template Sets with Template Withdrawals in order to ensure consistency of Templates.
ファイルライターを収集プロセスでコロケートする場合、各メッセージのエクスポート時間は、メッセージの最初のデータレコードを含む収集プロセスで受信したメッセージのエクスポート時間である必要があります。輸送プロトコルとしてSCTPを使用してIPFIXデータを収集したIPFIXデータを保存するファイルライターは、エクスポート時間の順序を維持するために複数のストリームからメッセージをインターリーブする必要があり、各テンプレートセットまたはオプションテンプレートを確保するために必要に応じて書かれたメッセージを並べ替える必要があることに注意してください。セットは、そのセット内のテンプレートで説明されているデータセットの前にファイルに表示されます。テンプレートの並べ替えは、テンプレートの一貫性を確保するために、テンプレートの引き出しでテンプレートセットのシーケンスを保持する必要があります。
Note that when adding additional information to IPFIX Messages received from Collecting Processes (e.g., Message Checksum Options, Message Detail Options), the File Writer SHOULD extend the length of the Message for the additional data if possible; otherwise, the Message SHOULD be split into two approximately equal-size Messages aligned on a Data Set or Template Set boundary from the original Message if possible; otherwise, the Message SHOULD be split into two approximately equal-size Messages aligned on a Data Record boundary. Note that, since the Maximum Segment Size (MSS) or MTU of most network links (1500-9000 for common Ethernets) is smaller than the maximum IPFIX Message size (65536) within an IPFIX File, it is expected that message length extension will suffice in most circumstances.
収集プロセス（メッセージチェックサムオプション、メッセージの詳細オプションなど）から受信したIPFIXメッセージに追加情報を追加する場合、ファイルライターは、可能であれば追加データのメッセージの長さを拡張する必要があることに注意してください。それ以外の場合、メッセージは、可能であれば、元のメッセージからのデータセットまたはテンプレートセットの境界に並べられた2つのほぼ等しいサイズのメッセージに分割する必要があります。それ以外の場合、メッセージは、データレコードの境界に合わせた2つのほぼ等しいサイズのメッセージに分割する必要があります。ほとんどのネットワークリンクの最大セグメントサイズ（MSS）またはMTU（一般的なイーサネットの場合は1500-9000）は、IPFIXファイル内の最大IPFIXメッセージサイズ（65536）よりも小さいため、メッセージの長さ拡張機能で十分であると予想されます。ほとんどの場合。
A File Writer collocated with a Collecting Process SHOULD NOT sign a File as specified in Section 9.1 unless the Transport Session over which the data was exported was protected via TLS or DTLS, and the Collecting Process positively identified the Exporting Process by its certificate. See Section 12.2 for more information on this issue.
収集プロセスとコロックされたファイルライターは、データがエクスポートされたトランスポートセッションがTLSまたはDTLSを介して保護されていない場合を除き、セクション9.1で指定されたファイルに署名しないでください。この問題の詳細については、セクション12.2を参照してください。
Note that File Writers may also be collocated directly with IPFIX Metering Processes, for writing measured information directly to disk without intermediate IPFIX Exporting or Collecting Processes. This arrangement may be particularly useful when providing data to an analysis environment with an IPFIX-File-based workflow, when testing Metering Processes during development, or when the authentication of a Metering Process is important.
また、ファイルライターは、中間IPFIXのエクスポートまたは収集プロセスなしでディスクに直接測定された情報を書き込むために、IPFIXメータープロセスと直接コロケートされる場合があることに注意してください。この配置は、IPFIXファイルベースのワークフローを使用して分析環境にデータを提供し、開発中に計量プロセスをテストする場合、または計量プロセスの認証が重要な場合に特に役立ちます。
When collocating a File Writer with a Metering Process, note that Information Elements associated with Exporting or Collecting Processes are meaningless, and SHOULD NOT appear in the Export Session Details Options Template described in Section 8.1.3 or the Message Details Options Template described in Section 8.1.4.
ファイルライターを計量プロセスでコロケートする場合、エクスポートまたは収集プロセスに関連する情報要素は無意味であり、セクション8.1.3で説明されているエクスポートセッションの詳細オプションテンプレートに表示されないことに注意してください。.4。
When collocating a File Writer with a Metering Process, the Export Time of each Message SHOULD be the time at which the first Data Record in the Message was received from the Metering Process.
ファイルライターを計量プロセスでコロケートする場合、各メッセージのエクスポート時間は、メッセージの最初のデータレコードがメータープロセスから受信された時間である必要があります。
Note that collocating a File Writer with a Metering Process is the only way to provide positive authentication of a Metering Process through signatures as in Section 9.1. See Section 12.2 for more information on this issue.
セクション9.1のように、署名を介して計量プロセスの肯定的な認証を提供する唯一の方法であることに注意してください。この問題の詳細については、セクション12.2を参照してください。
While in the general case File Writers should store one Transport Session per IPFIX File, some applications storing large collections of data over long periods of time may benefit from the ability to treat a collection of IPFIX Files as a single Transport Session. A File Writer MAY be configurable to write data from a single Transport Session into multiple IPFIX Files; however, File Writers supporting such a configuration option MUST provide a configuration option to support one-file-per-session behavior for interoperability purposes.
一般的なケースファイルでは、ライターはIPFIXファイルごとに1つのトランスポートセッションを保存する必要がありますが、長期間にわたって大規模なデータコレクションを保存するアプリケーションの一部は、IPFIXファイルのコレクションを単一のトランスポートセッションとして扱う機能の恩恵を受ける可能性があります。ファイルライターは、単一のトランスポートセッションから複数のIPFIXファイルにデータを記述するように設定できる場合があります。ただし、このような構成オプションをサポートするファイルライターは、相互運用性の目的でセッションごとの1ファイルの動作をサポートする構成オプションを提供する必要があります。
File Writers using IPFIX Files for archival storage SHOULD support compression as in Section 10.
アーカイブストレージにIPFIXファイルを使用するファイルライターは、セクション10のように圧縮をサポートする必要があります。
When IPFIX Files are used as documents, to store a set of flows relevant to query, investigation, or other common context, or for the publication of traffic datasets relevant to network research, each File MUST be readable as a single Transport Session, self-contained aside from any detached signature as in Section 9.1, and making no reference to metadata stored in separate Files, in order to ensure interoperability.
IPFIXファイルがドキュメントとして使用され、クエリ、調査、またはその他の共通コンテキストに関連する一連のフローを保存する場合、またはネットワーク調査に関連するトラフィックデータセットの公開のために、各ファイルは単一のトランスポートセッションとして読み取る必要があります。セクション9.1のような分離された署名は別として、相互運用性を確保するために、別々のファイルに保存されたメタデータを参照しません。
When writing Files to be used as documents, File Writers MAY emit the special Data Records described by Options Templates before any other Data Records in the File in the following order to ease the inspection and use of documents by File Readers: o Time Window records described by the File Time Window Options Template as defined in Section 8.1.2 below; followed by:
ドキュメントとして使用されるファイルを作成する場合、ファイルライターは、ファイル内の他のデータレコードの前にオプションテンプレートで説明されている特別なデータレコードを、ファイルリーダーによるドキュメントの検査と使用を容易にすることができます。以下のセクション8.1.2で定義されているファイルタイムウィンドウオプションテンプレートによって。に続く：
o Information Element Type Records as described in [RFC5610]; followed by
o [RFC5610]で説明されている情報要素タイプレコード。に続く
o commonPropertiesId definitions as described in [RFC5473]; followed by
o [RFC5473]で説明されているCommonPropertiesID定義。に続く
o Export Session details records described by the Export Session Details Options Template as defined in Section 8.1.3 below.
o エクスポートセッションの詳細記録は、以下のセクション8.1.3で定義されているエクスポートセッションの詳細オプションテンプレートで説明されています。
The Export Time of each Message within a File used as a document SHOULD be the time at which the Message was written by the File Writer.
ドキュメントとして使用されるファイル内の各メッセージのエクスポート時間は、メッセージがファイルライターによって書かれた時間である必要があります。
If an IPFIX File used as a document uses the technique described in [RFC5473] AND all of the non-Options Templates in the File contain the commonPropertiesId Information Element, a File Reader MAY assume the set of commonPropertiesId definitions provides a complete table of contents for the File for searching purposes.
ドキュメントとして使用されるIPFIXファイルが[RFC5473]で説明されている手法を使用し、ファイル内のすべての非オプションテンプレートにCommonPropertiesID情報要素が含まれている場合、ファイルリーダーはCommonPropertiesID定義のセットが完全な内容の表を提供すると想定する場合があります。検索目的のファイル。
IPFIX Files can be used for testing IPFIX Collecting Processes in two ways. First, IPFIX Files can be used to store specific flow data for regression and stress testing of Collectors; there are no special considerations for IPFIX Files used in this way.
IPFIXファイルは、IPFIXの収集プロセスを2つの方法でテストするために使用できます。まず、IPFIXファイルを使用して、コレクターの回帰とストレステストのために特定のフローデータを保存できます。この方法で使用されるIPFIXファイルについて特別な考慮事項はありません。
Second, IPFIX Files are useful for storing reference messages that do not comply to the IPFIX protocol in order to test the error handling and recovery behavior of Collectors. Of course, IPFIX Files intended to be used in this application necessarily MAY violate any of the specifications in this document or in [RFC5101], and such Files MUST NOT be transmitted to Collecting Processes or given as input to File Readers not under test.
第二に、IPFIXファイルは、コレクターのエラー処理と回復の動作をテストするために、IPFIXプロトコルに準拠していない参照メッセージを保存するのに役立ちます。もちろん、このアプリケーションで使用することを目的としたIPFIXファイルは、必然的にこのドキュメントまたは[RFC5101]の仕様に違反する可能性があり、そのようなファイルはプロセスの収集に送信したり、テスト中ではないファイルリーダーへの入力として指定されてはなりません。
Note that an extremely simple IPFIX Exporting Process may be crafted for testing purposes by simply reading an IPFIX File and transmitting it directly to a Collecting Process. Similarly, an extremely simple Collecting Process may be crafted for testing purposes by simply accepting connections and/or IPFIX Messages from Exporting Processes and writing the session's message stream to an IPFIX File.
非常にシンプルなIPFIXエクスポートプロセスは、IPFIXファイルを読み取り、収集プロセスに直接送信するだけで、テスト目的で作成される可能性があることに注意してください。同様に、プロセスのエクスポートからの接続および/またはIPFIXメッセージを受け入れ、セッションのメッセージストリームをIPFIXファイルに書き込むだけで、非常に単純な収集プロセスをテストするために作成できます。
IPFIX Files can be used in the debugging of devices that use flow data as internal state, as a common format for the representation of flow tables. In such situations, the opaqueOctets information element can be used to store additional non-IPFIX encoded, non-flow information (e.g., stack backtraces, process state, etc.) within the IPFIX File as in Section 11.1; the IPFIX flow table information could also be embedded in a larger proprietary diagnostic format using delimiters as in Section 11.2
IPFIXファイルは、フローテーブルの表現の共通形式として、フローデータを内部状態として使用するデバイスのデバッグで使用できます。このような状況では、Opakeoctets情報要素を使用して、セクション11.1のように、IPFIXファイル内の追加の非IPFIXエンコード、非フロー情報（スタックバックトレース、プロセス状態など）を保存できます。IPFIXフローテーブル情報は、セクション11.2のように、区切り文字を使用して、より大きな独自の診断形式に埋め込むこともできます。
For many applications, it may prove useful for implementations to provide functionality for the manipulation of IPFIX Files; for example, to select data from a File, to change the Templates used within a File, or to split or join data in Files. Any such utility should take special care to ensure that its output remains a valid IPFIX File, specifically with respect to Templates and Options, which are scoped to Transport Sessions.
多くのアプリケーションでは、実装がIPFIXファイルの操作に機能を提供するのに役立つことが証明される場合があります。たとえば、ファイルからデータを選択したり、ファイル内で使用されているテンプレートを変更したり、ファイルにデータを分割または結合したりすること。このようなユーティリティは、特にテンプレートとオプションに関して、その出力がセッションを範囲で監視されているテンプレートとオプションに関して、有効なIPFIXファイルのままであることを確認するために特別な注意を払う必要があります。
Any operation that splits one File into multiple Files SHOULD write all necessary Templates and Options to each resulting File, and ensure that written Options are valid for each resulting File (e.g., the Time Window Options Template in Section 8.1.2). Any operation that joins multiple Files into a single File should do the same, additionally ensuring that Template IDs do not collide, through the use of different Observation Domain IDs or Template ID rewriting. Combining operations may also want to ensure any desired ordering of flow records is maintained.
1つのファイルを複数のファイルに分割する操作は、必要なすべてのテンプレートとオプションを結果のファイルに記述し、結果のファイルごとに書かれたオプションが有効であることを確認する必要があります（たとえば、セクション8.1.2のタイムウィンドウオプションテンプレート）。複数のファイルを単一のファイルに結合する操作は同じことを行い、さらに、異なる観測ドメインIDまたはテンプレートIDの書き換えを介して、テンプレートIDが衝突しないようにする必要があります。操作を組み合わせることで、フローレコードの目的の順序が維持されるようにする場合があります。
The media type for IPFIX Files is application/ipfix. The registration information [RFC4288] for this media type is given in the IANA Considerations section.
IPFIXファイルのメディアタイプはApplication/IPFixです。このメディアタイプの登録情報[RFC4288]は、IANAの考慮事項セクションに記載されています。
This section defines the Options Templates used for IPFIX File metadata, and the Information Elements they require.
このセクションでは、IPFIXファイルメタデータに使用されるオプションテンプレートと、必要な情報要素を定義します。
The following Options Templates allow IPFIX Message streams to meet the requirements outlined above without extension to the message format or protocol. They are defined in terms of existing Information Elements defined in [RFC5102], the Information Elements defined in [RFC5610], as well as Information Elements defined in Section 8.2. IPFIX File Readers and Writers SHOULD support these Options Templates as defined below.
次のオプションテンプレートにより、IPFIXメッセージストリームは、メッセージ形式またはプロトコルを拡張せずに上記の要件を満たすことができます。これらは、[RFC5102]で定義されている既存の情報要素、[RFC5610]で定義されている情報要素、およびセクション8.2で定義されている情報要素に関して定義されます。IPFIXファイルリーダーとライターは、以下に定義するようにこれらのオプションテンプレートをサポートする必要があります。
In addition, IPFIX File Readers and Writers SHOULD support the Options Templates defined in [RFC5610] in order to support self-description of enterprise-specific Information Elements.
さらに、IPFIXファイルリーダーとライターは、エンタープライズ固有の情報要素の自己説明をサポートするために、[RFC5610]で定義されているオプションテンプレートをサポートする必要があります。
The Message Checksum Options Template specifies the structure of a Data Record for attaching an MD5 message checksum to an IPFIX Message. An MD5 message checksum as described MAY be used if data integrity is important to the application but file signing is not available or desired. The described Data Record MUST appear only once per IPFIX Message, but MAY appear anywhere within the Message.
メッセージチェックサムオプションテンプレートは、MD5メッセージチェックサムをIPFIXメッセージに添付するためのデータレコードの構造を指定します。データの整合性がアプリケーションにとって重要であるが、ファイルの署名が利用できないか、望まれていない場合、記載されているMD5メッセージチェックサムを使用できます。説明されたデータレコードは、IPFIXメッセージごとに1回のみ表示される必要がありますが、メッセージ内に表示される場合があります。
This Options Template SHOULD contain the following Information Elements:
このオプションテンプレートには、次の情報要素が含まれている必要があります。
+--------------------+----------------------------------------------+
| IE | Description |
+--------------------+----------------------------------------------+
| messageScope | A marker denoting this Option applies to the |
| [scope] | whole IPFIX Message; content is ignored. |
| | This Information Element MUST be defined as |
| | a Scope Field. |
| messageMD5Checksum | The MD5 checksum of the containing IPFIX |
| | Message. |
+--------------------+----------------------------------------------+
The File Time Window Options Template specifies the structure of a Data Record for attaching a time window to an IPFIX File; this Data Record is referred to as a time window record. A time window record defines the earliest flow start time and the latest flow end time of the flow records within a File. One and only one time window record MAY appear within an IPFIX File if the time window information is available; a File Writer MUST NOT write more than one time window record to an IPFIX File. A File Writer that writes a time window record to a File MUST NOT write any Flow with a start time before the beginning of the window or an end time after the end of the window to that File.
ファイルタイムウィンドウオプションテンプレートは、IPFIXファイルにタイムウィンドウを添付するためのデータレコードの構造を指定します。このデータレコードは、タイムウィンドウレコードと呼ばれます。タイムウィンドウのレコードは、ファイル内のフローレコードの最も早いフロー開始時間とフローエンドタイムを定義します。タイムウィンドウ情報が利用可能な場合、IPFIXファイル内に1つの1つのタイムウィンドウレコードが表示される場合があります。ファイルライターは、IPFIXファイルに複数の時間ウィンドウレコードを記述してはなりません。タイムウィンドウのレコードをファイルに書き込むファイルライターは、ウィンドウの開始前の開始時間、またはそのファイルへのウィンドウの終了後の終了時間にフローを書き込んではなりません。
This Options Template SHOULD contain the following Information Elements:
このオプションテンプレートには、次の情報要素が含まれている必要があります。
+---------------+---------------------------------------------------+
| IE | Description |
+---------------+---------------------------------------------------+
| sessionScope | A marker denoting this Option applies to the |
| [scope] | whole IPFIX Transport Session (i.e., the IPFIX |
| | File in the common case); content is ignored. |
| | This Information Element MUST be defined as a |
| | Scope Field. |
| minFlowStart* | Exactly one of minFlowStartSeconds, |
| | minFlowStartMilliseconds, |
| | minFlowStartMicroseconds, or |
| | minFlowStartNanoseconds SHOULD match the |
| | precision of the accompanying maxFlowEnd* |
| | Information Element. The start time of the |
| | earliest flow in the Transport Session (i.e., |
| | File). |
| maxFlowEnd* | Exactly one of maxFlowEndSeconds, |
| | maxFlowEndMilliseconds, maxFlowEndMicroseconds, |
| | or maxFlowEndNanoseconds SHOULD match the |
| | precision of the accompanying minFlowStart* |
| | Information Element. The end time of the latest |
| | flow in the Transport Session (i.e., File). |
+---------------+---------------------------------------------------+
The Export Session Details Options Template specifies the structure of a Data Record for recording the details of an IPFIX Transport Session in an IPFIX File. It is intended for use in storing a single complete IPFIX Transport Session in a single IPFIX File. The described Data Record SHOULD appear only once in a given IPFIX File.
エクスポートセッションの詳細オプションテンプレートは、IPFIXファイルのIPFIXトランスポートセッションの詳細を記録するためのデータレコードの構造を指定します。単一のIPFIXトランスポートセッションを単一のIPFIXファイルに保存する際に使用することを目的としています。説明されたデータレコードは、特定のIPFIXファイルに1回のみ表示される必要があります。
This Options Template SHOULD contain at least the following Information Elements, subject to applicability as noted on each Information Element:
このオプションテンプレートには、各情報要素に記載されているように、少なくとも次の情報要素を含める必要があります。
+----------------------------+--------------------------------------+
| IE | Description |
+----------------------------+--------------------------------------+
| sessionScope [scope] | A marker denoting this Option |
| | applies to the whole IPFIX Transport |
| | Session (i.e., the IPFIX File in the |
| | common case); content is ignored. |
| | This Information Element MUST be |
| | defined as a Scope Field. |
| exporterIPv4Address | IPv4 address of the IPFIX Exporting |
| | Process from which the Messages in |
| | this Transport Session were |
| | received. Present only for |
| | Exporting Processes with an IPv4 |
| | interface. For multi-homed SCTP |
| | associations, this SHOULD be the |
| | primary path endpoint address of the |
| | Exporting Process. |
| exporterIPv6Address | IPv6 address of the IPFIX Exporting |
| | Process from which the Messages in |
| | this Transport Session were |
| | received. Present only for |
| | Exporting Processes with an IPv6 |
| | interface. For multi-homed SCTP |
| | associations, this SHOULD be the |
| | primary path endpoint address of the |
| | Exporting Process. |
| exporterTransportPort | The source port from which the |
| | Messages in this Transport Session |
| | were received. |
| exporterCertificate | The certificate used by the IPFIX |
| | Exporting Process from which the |
| | Messages in this Transport Session |
| | were received. Present only for |
| | Transport Sessions protected by TLS |
| | or DTLS. |
| collectorIPv4Address | IPv4 address of the IPFIX Collecting |
| | Process that received the Messages |
| | in this Transport Session. Present |
| | only for Collecting Processes with |
| | an IPv4 interface. For multi-homed |
| | SCTP associations, this SHOULD be |
| | the primary path endpoint address of |
| | the Collecting Process. |
| collectorIPv6Address | IPv6 address of the IPFIX Collecting |
| | Process that received the Messages |
| | in this Transport Session. Present |
| | only for Collecting Processes with |
| | an IPv6 interface. For multi-homed |
| | SCTP associations, this SHOULD be |
| | the primary path endpoint address of |
| | the Collecting Process. |
| collectorTransportPort | The destination port on which the |
| | Messages in this Transport Session |
| | were received. |
| collectorTransportProtocol | The IP Protocol Identifier of the |
| | transport protocol used to transport |
| | Messages within this Transport |
| | Session. |
| collectorProtocolVersion | The version of the export protocol |
| | used to transport Messages within |
| | this Transport Session. Applicable |
| | only in mixed NetFlow V9-IPFIX |
| | collection environments when storing |
| | NetFlow V9 data in IPFIX Messages, |
| | as in Appendix B. |
| collectorCertificate | The certificate used by the IPFIX |
| | Collecting Process that received the |
| | Messages in this Transport Session. |
| | Present only for Transport Sessions |
| | protected by TLS or DTLS. |
| minExportSeconds | The Export Time of the first Message |
| | in the Transport Session. |
| maxExportSeconds | The Export Time of the last Message |
| | in the Transport Session. |
+----------------------------+--------------------------------------+
The Message Details Options Template specifies the structure of a Data Record for attaching additional export details to an IPFIX Message. These details include the time at which a message was received and information about the export and collection infrastructure used to transport the Message. This Options Template also allows the storage of the export session metadata provided the Export Session Details Options Template, for storing information from multiple Transport Sessions in the same IPFIX File.
メッセージの詳細オプションテンプレートは、IPFIXメッセージに追加のエクスポートの詳細を添付するためのデータレコードの構造を指定します。これらの詳細には、メッセージの受信時間と、メッセージの輸送に使用されるエクスポートおよびコレクションインフラストラクチャに関する情報が含まれます。また、このオプションテンプレートを使用すると、エクスポートセッションメタデータの保存が、同じIPFIXファイルに複数のトランスポートセッションから情報を保存するためのエクスポートセッションの詳細オプションテンプレートを提供することもできます。
This Options Template SHOULD contain at least the following Information Elements, subject to applicability as noted for each Information Element. Note that when used in conjunction with the Export Session Details Options Template, when storing a single complete IPFIX Transport Session in an IPFIX File, this Options Template SHOULD contain only the messageScope and collectionTimeMilliseconds Information Elements, and the exportSctpStreamId Information Element for Messages transported via SCTP.
このオプションテンプレートには、各情報要素に記載されているように、適用可能性を条件として、少なくとも次の情報要素を含める必要があります。エクスポートセッションの詳細オプションテンプレートと組み合わせて使用する場合、IPFIXファイルに単一の完全なIPFIXトランスポートセッションを保存する場合、このオプションテンプレートにはメッセージスコープとCollectionTimeMilliseconds情報要素のみ、およびSCTPを介して輸送されるメッセージのExportSCTPSTREAMID情報要素のみを含める必要があることに注意してください。。
+----------------------------+--------------------------------------+
| IE | Description |
+----------------------------+--------------------------------------+
| messageScope [scope] | A marker denoting this Option |
| | applies to the whole IPFIX message; |
| | content is ignored. This |
| | Information Element MUST be defined |
| | as a Scope Field. |
| collectionTimeMilliseconds | The absolute time at which this |
| | Message was received by the IPFIX |
| | Collecting Process. |
| exporterIPv4Address | IPv4 address of the IPFIX Exporting |
| | Process from which this Message was |
| | received. Present only for |
| | Exporting Processes with an IPv4 |
| | interface, and if this information |
| | is not available via the Export |
| | Session Details Options Template. |
| | For multi-homed SCTP associations, |
| | this SHOULD be the primary path |
| | endpoint address of the Exporting |
| | Process. |
| exporterIPv6Address | IPv6 address of the IPFIX Exporting |
| | Process from which this Message was |
| | received. Present only for |
| | Exporting Processes with an IPv6 |
| | interface and if this information is |
| | not available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Exporting Process. |
| exporterTransportPort | The source port from which this |
| | Message was received. Present only |
| | if this information is not available |
| | via the Export Session Details |
| | Options Template. |
| exporterCertificate | The certificate used by the IPFIX |
| | Exporting Process from which this |
| | Message was received. Present only |
| | for Transport Sessions protected by |
| | TLS or DTLS. |
| collectorIPv4Address | IPv4 address of the IPFIX Collecting |
| | Process that received this Message. |
| | Present only for Collecting |
| | Processes with an IPv4 interface, |
| | and if this information is not |
| | available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Collecting Process. |
| collectorIPv6Address | IPv6 address of the IPFIX Collecting |
| | Process that received this Message. |
| | Present only for Collecting |
| | Processes with an IPv6 interface, |
| | and if this information is not |
| | available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Collecting Process. |
| collectorTransportPort | The destination port on which this |
| | Message was received. Present only |
| | if this information is not available |
| | via the Export Session Details |
| | Options Template. |
| collectorTransportProtocol | The IP Protocol Identifier of the |
| | transport protocol used to transport |
| | this Message. Present only if this |
| | information is not available via the |
| | Export Session Details Options |
| | Template. |
| collectorProtocolVersion | The version of the export protocol |
| | used to transport this Message. |
| | Present only if necessary and if |
| | this information is not available |
| | via the Export Session Details |
| | Options Template. |
| collectorCertificate | The certificate used by the IPFIX |
| | Collecting Process that received |
| | this Message. Present only for |
| | Transport Sessions protected by TLS |
| | or DTLS. |
| exportSctpStreamId | The SCTP stream used to transport |
| | this Message. Present only if the |
| | Message was transported via SCTP. |
+----------------------------+--------------------------------------+
The following Information Elements are used by the Options Templates in Section 8.1 to allow IPFIX Message streams to meet the requirements outlined above without extension of the protocol. IPFIX File Readers and Writers SHOULD support these Information Elements as defined below.
次の情報要素は、セクション8.1のオプションテンプレートで使用され、IPFIXメッセージストリームがプロトコルの拡張なしに上記の要件を満たすことができます。IPFIXファイルリーダーとライターは、以下に定義するように、これらの情報要素をサポートする必要があります。
In addition, IPFIX File Readers and Writers SHOULD support the Information Elements defined in [RFC5610] in order to support full self-description of Information Elements.
さらに、IPFIXファイルリーダーとライターは、情報要素の完全な自己説明をサポートするために、[RFC5610]で定義されている情報要素をサポートする必要があります。
Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element SHOULD be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element, as defined below.
説明：この情報要素を含むスコープ内のデータが収集プロセスによって受信された絶対タイムスタンプ。この情報要素は、以下に定義するように、IPFIXオプションとメッセージスコープ情報要素を介してIPFIXメッセージを含むものにバインドする必要があります。
Abstract Data Type: dateTimeMilliseconds
抽象データ型：DateTimeMilliseConds
ElementId: 258
ElementID：258
Status: current
ステータス：現在
Description: The full X.509 certificate, encoded in ASN.1 DER format, used by the Collector when IPFIX Messages were transmitted using TLS or DTLS. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element, or to its containing IPFIX Message via an options record and the messageScope Information Element.
説明：IPFIXメッセージをTLSまたはDTLSを使用して送信したときにコレクターが使用するASN.1 DER形式でエンコードされた完全なX.509証明書。この情報要素は、Options RecordとSessionscope Information要素を介してIPFIXトランスポートセッションを含む、またはOptions RecordとMessagesScope情報要素を介してIPFIXメッセージを含むものにバインドする必要があります。
Abstract Data Type: octetArray
抽象データ型：OctetArray
ElementId: 274
ElementID：274
Status: current
ステータス：現在
Description: The full X.509 certificate, encoded in ASN.1 DER format, used by the Collector when IPFIX Messages were transmitted using TLS or DTLS. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element, or to its containing IPFIX Message via an options record and the messageScope Information Element.
説明：IPFIXメッセージをTLSまたはDTLSを使用して送信したときにコレクターが使用するASN.1 DER形式でエンコードされた完全なX.509証明書。この情報要素は、Options RecordとSessionscope Information要素を介してIPFIXトランスポートセッションを含む、またはOptions RecordとMessagesScope情報要素を介してIPFIXメッセージを含むものにバインドする必要があります。
Abstract Data Type: octetArray
抽象データ型：OctetArray
ElementId: 275
ElementID：275
Status: current
ステータス：現在
Description: The value of the SCTP Stream Identifier used by the Exporting Process for exporting IPFIX Message data. This is carried in the Stream Identifier field of the header of the SCTP DATA chunk containing the IPFIX Message(s).
説明：IPFIXメッセージデータをエクスポートするためにエクスポートプロセスで使用されるSCTPストリーム識別子の値。これは、IPFIXメッセージを含むSCTPデータチャンクのヘッダーのストリーム識別子フィールドに運ばれます。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 259
ElementID：259
Status: current
ステータス：現在
Description: The absolute Export Time of the latest IPFIX Message within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element.
説明：この情報要素を含むスコープ内の最新のIPFIXメッセージの絶対エクスポート時間。この情報要素は、IPFIXオプションとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。
Abstract Data Type: dateTimeSeconds
抽象データ型：DateTimeseConds
ElementId: 260
ElementID：260
Status: current
ステータス：現在
Units: seconds
ユニット：秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the microsecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with microsecond-precision (or better) timestamp Information Elements.
説明：この情報要素を含むスコープ内のフロー内の最後のパケットの最新の絶対タイムスタンプは、必要に応じてマイクロ秒まで上昇しました。この情報要素は、IPFIXオプションとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。この情報要素は、マイクロ秒前（またはより良い）タイムスタンプ情報要素を含むフローレコードを含むトランスポートセッションでのみ使用する必要があります。
Abstract Data Type: dateTimeMicroseconds
抽象データ型：DateTimemicRoseconds
ElementId: 268
ElementID：268
Status: current
ステータス：現在
Units: microseconds
ユニット：マイクロ秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the millisecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with millisecond-precision (or better) timestamp Information Elements.
説明：この情報要素を含むスコープ内のフロー内の最後のパケットの最新の絶対タイムスタンプは、必要に応じてミリ秒まで上昇しました。この情報要素は、IPFIXオプションとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。この情報要素は、Millisecond Precision（またはより良い）タイムスタンプ情報要素を含むフローレコードを含むトランスポートセッションでのみ使用する必要があります。
Abstract Data Type: dateTimeMilliseconds
抽象データ型：DateTimeMilliseConds
ElementId: 269
ElementID：269
Status: current
ステータス：現在
Units: milliseconds
ユニット：ミリ秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with nanosecond-precision timestamp Information Elements.
説明：この情報要素を含むスコープ内のフロー内の最後のパケットの最新の絶対タイムスタンプ。この情報要素は、IPFIXオプションとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。この情報要素は、ナノ秒前のタイムスタンプ情報要素を含むフローレコードを含むトランスポートセッションでのみ使用する必要があります。
Abstract Data Type: dateTimeNanoseconds
抽象データ型：DateTimeナノ秒
ElementId: 270
ElementID：270
Status: current
ステータス：現在
Units: nanoseconds
ユニット：ナノ秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element.
説明：この情報要素を含むスコープ内のフロー内の最後のパケットの最新の絶対タイムスタンプは、必要に応じて2番目に丸められました。この情報要素は、IPFIXオプションとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。
Abstract Data Type: dateTimeSeconds
抽象データ型：DateTimeseConds
ElementId: 261
ElementID：261
Status: current
ステータス：現在
Units: seconds
ユニット：秒
Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element SHOULD be bound to its containing IPFIX Message via an options record and the messageScope Information Element, as defined below, and SHOULD appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in [RFC1321], place the resulting value in this Information Element, and export the buffered message. This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest.
説明：このレコードを含むIPFIXメッセージのMD5チェックサム。この情報要素は、以下に定義されているように、オプションレコードとメッセージスコープ情報要素を介してその含有IPFIXメッセージにバインドする必要があり、特定のIPFIXメッセージに1回のみ表示される必要があります。この情報要素の値を計算するには、まず含まれたIPFIXメッセージをバッファし、この情報要素の値をすべてのゼロに設定します。次に、[RFC1321]で定義されている結果のバッファーのMD5チェックサムを計算し、結果の値をこの情報要素に配置し、バッファーメッセージをエクスポートします。この情報要素は、単純なチェックサムとしてのみ意図されています。したがって、衝突抵抗とアルゴリズムの俊敏性は必要ありません。MD5は適切なメッセージダイジェストです。
Abstract Data Type: octetArray (16 bytes)
抽象データ型：OctetArray（16バイト）
ElementId: 262
ElementID：262
Status: current
ステータス：現在
Reference: RFC 1321, The MD5 Message-Digest Algorithm [RFC1321]
リファレンス：RFC 1321、MD5メッセージダイジェストアルゴリズム[RFC1321]
Description: The presence of this Information Element as scope in an Options Template signifies that the options described by the Template apply to the IPFIX Message that contains them. It is defined for general purpose message scoping of options, and proposed specifically to allow the attachment of checksum and collection information to a message via IPFIX Options. The value of this Information Element MUST be written as 0 by the File Writer or Exporting Process. The value of this Information Element MUST be ignored by the File Reader or the Collecting Process.
説明：オプションテンプレート内の範囲としてのこの情報要素の存在は、テンプレートで説明されているオプションがそれらを含むIPFIXメッセージに適用されることを意味します。オプションの汎用メッセージスコープ用に定義され、IPFIXオプションを介してメッセージにチェックサムとコレクション情報を添付できるように特に提案されています。この情報要素の値は、ファイルライターまたはエクスポートプロセスによって0として記述する必要があります。この情報要素の値は、ファイルリーダーまたは収集プロセスによって無視する必要があります。
Abstract Data Type: unsigned8
抽象データ型：unsigned8
ElementId: 263
ElementID：263
Status: current
ステータス：現在
Description: The absolute Export Time of the earliest IPFIX Message within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element.
説明：この情報要素を含むスコープ内の初期のIPFIXメッセージの絶対エクスポート時間。この情報要素は、オプションレコードとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。
Abstract Data Type: dateTimeSeconds
抽象データ型：DateTimeseConds
ElementId: 264
ElementID：264
Status: current
ステータス：現在
Units: seconds
ユニット：秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the microsecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with microsecond-precision (or better) timestamp Information Elements.
説明：この情報要素を含むスコープ内のフロー内の最初のパケットの最初の絶対タイムスタンプは、必要に応じてマイクロ秒に丸められました。この情報要素は、オプションレコードとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。この情報要素は、マイクロ秒前（またはより良い）タイムスタンプ情報要素を含むフローレコードを含むトランスポートセッションでのみ使用する必要があります。
Abstract Data Type: dateTimeMicroseconds
抽象データ型：DateTimemicRoseconds
ElementId: 271
ElementID：271
Status: current
ステータス：現在
Units: microseconds
ユニット：マイクロ秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the millisecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with millisecond-precision (or better) timestamp Information Elements.
説明：この情報要素を含むスコープ内のフロー内の最初のパケットの最初の絶対的なタイムスタンプは、必要に応じてミリ秒まで丸められました。この情報要素は、オプションレコードとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。この情報要素は、Millisecond Precision（またはより良い）タイムスタンプ情報要素を含むフローレコードを含むトランスポートセッションでのみ使用する必要があります。
Abstract Data Type: dateTimeMilliseconds
抽象データ型：DateTimeMilliseConds
ElementId: 272
ElementID：272
Status: current
ステータス：現在
Units: milliseconds
ユニット：ミリ秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with nanosecond-precision timestamp Information Elements.
説明：この情報要素を含むスコープ内の任意のフロー内の最初のパケットの最初の絶対タイムスタンプ。この情報要素は、オプションレコードとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。この情報要素は、ナノ秒前のタイムスタンプ情報要素を含むフローレコードを含むトランスポートセッションでのみ使用する必要があります。
Abstract Data Type: dateTimeNanoseconds
抽象データ型：DateTimeナノ秒
ElementId: 273
ElementID：273
Status: current
ステータス：現在
Units: nanoseconds
ユニット：ナノ秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element.
説明：この情報要素を含むスコープ内のフロー内の最初のパケットの最初の絶対タイムスタンプは、必要に応じて2番目に丸められました。この情報要素は、オプションレコードとSessionscope情報要素を介して、IPFIXトランスポートセッションを含むものにバインドする必要があります。
Abstract Data Type: dateTimeSeconds ElementId: 265
抽象データ型：DateTimeseConds ElementID：265
Status: current
ステータス：現在
Units: seconds
ユニット：秒
Description: This Information Element is used to encapsulate non-IPFIX data into an IPFIX Message stream, for the purpose of allowing a non-IPFIX data processor to store a data stream inline within an IPFIX File. A Collecting Process or File Writer MUST NOT try to interpret this binary data. This Information Element differs from paddingOctets as its contents are meaningful in some non-IPFIX context, while the contents of paddingOctets MUST be 0x00 and are intended only for Information Element alignment.
説明：この情報要素は、非IPFIXデータプロセッサがIPFIXファイル内にインラインでデータストリームを保存できるようにするために、非IPFIXデータをIPFIXメッセージストリームにカプセル化するために使用されます。収集プロセスまたはファイルライターは、このバイナリデータを解釈しようとしてはなりません。この情報要素は、その内容がいくつかの非IPFIXコンテキストで意味があるため、パディングクテットとは異なりますが、パディングクテットの内容は0x00でなければならず、情報要素のアライメントのみを目的としています。
Abstract Data Type: octetArray
抽象データ型：OctetArray
ElementId: 266
ElementID：266
Status: current
ステータス：現在
Description: The presence of this Information Element as scope in an Options Template signifies that the options described by the Template apply to the IPFIX Transport Session that contains them. Note that as all options are implicitly scoped to Transport Session and Observation Domain, this Information Element is equivalent to a "null" scope. It is defined for general purpose session scoping of options, and proposed specifically to allow the attachment of time window and collection information to an IPFIX File via IPFIX Options. The value of this Information Element MUST be written as 0 by the File Writer or Exporting Process. The value of this Information Element MUST be ignored by the File Reader or the Collecting Process.
説明：オプションテンプレート内の範囲としてのこの情報要素の存在は、テンプレートで説明されているオプションがそれらを含むIPFixトランスポートセッションに適用されることを意味します。すべてのオプションは、セッションと観測ドメインの輸送に暗黙的にスコープされているため、この情報要素は「ヌル」スコープに相当することに注意してください。オプションの汎用セッションスコーピング用に定義され、IPFIXオプションを介してIPFIXファイルに時間ウィンドウと収集情報を添付できるように特に提案されています。この情報要素の値は、ファイルライターまたはエクスポートプロセスによって0として記述する必要があります。この情報要素の値は、ファイルリーダーまたは収集プロセスによって無視する必要があります。
Abstract Data Type: unsigned8
抽象データ型：unsigned8
ElementId: 267
ElementID：267
Status: current
ステータス：現在
In order to ensure the integrity of IPFIX Files and the identity of IPFIX File Writers, File Writers and File Readers SHOULD provide for an interoperable and easily implemented method for signing IPFIX Files, and verifying those signatures. This section specifies method via CMS detached signatures.
IPFIXファイルの整合性とIPFIXファイルライターのIDを確保するために、ファイルライターとファイルリーダーは、IPFIXファイルに署名し、それらの署名を検証するための相互運用可能で簡単に実装された方法を提供する必要があります。このセクションでは、CMSデタッチされた署名を介してメソッドを指定します。
Note that while CMS specifies an encapsulation format that can be used for encryption as well as signing, no method is specified for encapsulation for confidentiality protection. It is assumed that application-specific or process-specific requirements outweigh the need for interoperability for encrypted files.
CMSは、暗号化と署名に使用できるカプセル化形式を指定しているが、機密保護のためのカプセル化の方法は指定されていないことに注意してください。アプリケーション固有またはプロセス固有の要件は、暗号化されたファイルの相互運用性の必要性を上回ると想定されています。
The Cryptographic Message Syntax (CMS) [RFC3852] defines an encapsulation syntax for data protection, used to digitally sign, authenticate, or encrypt arbitrary message content. CMS can also be used to create detached signatures, in which the signature is stored in a separate file. This arrangement maximizes interoperability, as File Readers that are not aware of CMS detached signatures and have no requirement for them can simply ignore them; the content of the IPFIX File itself is unchanged by the signature.
暗号化メッセージ構文（CMS）[RFC3852]は、任意のメッセージコンテンツをデジタル的に署名、認証、または暗号化するために使用されるデータ保護のカプセル化構文を定義します。CMSを使用して、署名が別のファイルに保存される分離署名を作成することもできます。この配置は相互運用性を最大化します。これは、CMS分離された署名を認識しておらず、それらを必要としないファイルリーダーが単純にそれらを無視できるためです。IPFIXファイル自体のコンテンツは、署名によって変更されません。
The detached signature file for an IPFIX File SHOULD be stored, transported, or otherwise made available (e.g., by FTP or HTTP) alongside the signed IPFIX File, with the same filename as the IPFIX File, except that the file extension ".p7s" is added to the end, conforming to the naming convention in [RFC3851].
IPFIXファイルのデタッチされた署名ファイルは、署名されたIPFIXファイルと一緒に、IPFIXファイルと同じファイル名を持つ署名されたIPFIXファイルとともに（FTPまたはHTTPなど）、保存、輸送、またはその他の方法で利用可能にする必要があります。[RFC3851]の命名規則に準拠して、最後に追加されます。
Within the detached signature, the CMS ContentInfo type MUST always
be present, and it MUST encapsulate the CMS SignedData content type,
which in turn MUST NOT encapsulate the signed IPFIX File content.
The CMS detached signature is summarized as follows:
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- File Writer certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes
}
EncapsulatedContentInfo {
eContentType id-data, -- (1.2.840.113549.1.7.1)
eContent OCTET STRING -- Always absent
}
The details of the contents of each CMS encapsulation are detailed in the subsections below.
各CMSカプセル化の内容の詳細については、以下のサブセクションで詳しく説明しています。
[RFC3852] requires the outer-most encapsulation to be ContentInfo; the fields of ContentInfo are as follows:
[RFC3852]では、最も外側のカプセル化がcontentinfoである必要があります。contentinfoのフィールドは次のとおりです。
contentType: the type of the associated content. For the detached signature file, the encapsulated type is always SignedData, so the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field.
ContentType：関連するコンテンツのタイプ。分離された署名ファイルの場合、カプセル化されたタイプは常に署名されているため、ID-SignedData（1.2.840.113549.1.7.2）オブジェクト識別子がこのフィールドに存在する必要があります。
content: a SignedData content, detailed in Section 9.1.2.
コンテンツ：セクション9.1.2で詳述されている署名dataコンテンツ。
The SignedData content type contains the signature of the IPFIX File and information to aid in validation; the fields of SignedData are as follows:
SignedDataコンテンツタイプには、検証を支援するIPFIXファイルの署名と情報が含まれています。SignedDataのフィールドは次のとおりです。
version: MUST be 3.
バージョン：3でなければなりません。
digestAlgorithms: a collection of one-way hash function identifiers. It MUST contain the identifier used by the File Writer to generate the digital signature.
Digestalgorithms：一元配置ハッシュ関数識別子のコレクション。ファイルライターがデジタル署名を生成するために使用する識別子を含める必要があります。
encapContentInfo: the signed content, including a content type identifier. Since a detached signature is being created, it does not encapsulate the IPFIX File. The EncapsulatedContentInfo is detailed in Section 9.1.4.
EncapContentInfo：コンテンツタイプ識別子を含む署名されたコンテンツ。分離された署名が作成されているため、IPFIXファイルをカプセル化しません。cancopturatedContentInfoのセクション9.1.4で詳細に説明されています。
certificates: a collection of certificates. It SHOULD include the X.509 certificate needed to validate the digital signature file. Certification Authority (CA) and File Writer certificates MUST conform to the certificate profile specified in [RFC5280].
証明書：証明書のコレクション。デジタル署名ファイルを検証するために必要なX.509証明書を含める必要があります。認証機関（CA）およびファイルライター証明書は、[RFC5280]で指定された証明書プロファイルに準拠する必要があります。
crls: an optional collection of certificate revocation lists (CRLs). It SHOULD NOT contain any CRLs; any CRLs that are present MUST conform to the certificate profile specified in [RFC5280].
CRLS：証明書の取り消しリスト（CRLS）のオプションのコレクション。CRLSを含めるべきではありません。存在するCRLは、[RFC5280]で指定された証明書プロファイルに準拠する必要があります。
signerInfos: a collection of per-signer information; this identifies the File Writer. More than one SignerInfo MAY appear to facilitate transitions between keys or algorithms. The SignerInfo type is detailed in Section 9.1.3.
SignerInfos：署名者ごとの情報のコレクション。これにより、ファイルライターが識別されます。複数のSignerinfoがキーまたはアルゴリズム間の遷移を容易にするように見える場合があります。SignerINFOタイプのセクション9.1.3で詳細に説明されています。
The SignerInfo type identifies the File Writer; the fields of SignerInfo are as follows:
Signerinfoタイプは、ファイルライターを識別します。Signerinfoのフィールドは次のとおりです。
version: MUST be 3.
バージョン：3でなければなりません。
sid: identifies the File Writer's public key. This identifier MUST match the value included in the subjectKeyIdentifier certificate extension on the File Writer's X.509 certificate.
SID：ファイルライターの公開キーを識別します。この識別子は、ファイルライターのX.509証明書の件名に含まれる値に含まれる値と一致する必要があります。
digestAlgorithm: identifies the one-way hash function and associated parameters used to generate the signature.
Digestalgorithm：署名を生成するために使用される一元配置ハッシュ関数と関連するパラメーターを識別します。
signedAttrs: an optional set of attributes that are signed along with the content.
SigneDattrs：コンテンツとともに署名されたオプションの属性セット。
digestAlgorithm: identifies the digital signature algorithm and associated parameters used to generate the signature.
DIGESTALGORITHM：署名を生成するために使用されるデジタル署名アルゴリズムと関連するパラメーターを識別します。
signature: the digital signature of the associated file.
署名：関連するファイルのデジタル署名。
unsignedAttrs: an optional set of attributes that are not signed.
unsignedattrs：署名されていないオプションの属性セット。
The EncapsulatedContentInfo structure contains a content type identifier. Since a detached signature is being created, it does not encapsulate the IPFIX File. The fields of EncapsulatedContentInfo are as follows:
cancopturatedContentINFO構造には、コンテンツ型識別子が含まれています。分離された署名が作成されているため、IPFIXファイルをカプセル化しません。cankulatedContentInfoのフィールドは次のとおりです。
eContentType: an object identifier that uniquely specifies the content type. The content type associated with IPFIX File MUST be id-data (1.2.840.113549.1.7.1).
EcontentType：コンテンツタイプを一意に指定するオブジェクト識別子。IPFIXファイルに関連付けられたコンテンツタイプは、ID-DATA（1.2.840.113549.1.7.1）でなければなりません。
eContent: an optional field containing the signed content. Since this is a detached signature, eContent MUST be absent.
econtent：署名されたコンテンツを含むオプションのフィールド。これは独立した署名であるため、econtentは存在しない必要があります。
Note that single bit errors in the encrypted data stream can result in larger errors in the decrypted stream, depending on the encryption scheme used.
暗号化されたデータストリームの単一ビットエラーは、使用される暗号化スキームに応じて、復号化されたストリームでより大きなエラーをもたらす可能性があることに注意してください。
In applications (e.g., archival storage) in which error resilience is very important, File Writers SHOULD use an encryption scheme that can resynchronize after bit errors. A common example is a block cipher in CBC (Cipher Block Chaining) mode. In this case, File Writers MAY also use the Message Checksum Options Template to attach a checksum to each IPFIX Message in the IPFIX File, in order to support the recognition of errors in the decrypted data.
エラーの回復力が非常に重要であるアプリケーション（たとえば、アーカイブストレージ）では、ファイルライターはビットエラー後に再同期することができる暗号化スキームを使用する必要があります。一般的な例は、CBC（暗号ブロックチェーン）モードのブロック暗号です。この場合、ファイルライターはメッセージチェックサムオプションテンプレートを使用して、復号化されたデータのエラーの認識をサポートするために、IPFIXファイルの各IPFIXメッセージにチェックサムを添付することもできます。
Network traffic measurement data is generally highly compressible. IPFIX Templates tend to increase the information content per record by not requiring the export of irrelevant or non-present fields in records, and the technique described in [RFC5473] also reduces the export of redundant information. However, even with these techniques, generalized compression can decrease storage requirements significantly; therefore, IPFIX File Writers and File Readers SHOULD support compression as described in this section.
ネットワークトラフィック測定データは一般に非常に圧縮可能です。IPFIXテンプレートは、レコードの無関係または非提示フィールドのエクスポートを必要としないことにより、記録ごとの情報コンテンツを増やす傾向があり、[RFC5473]で説明されている手法は、冗長な情報のエクスポートを減らします。ただし、これらの手法であっても、一般化された圧縮により、ストレージ要件が大幅に減少する可能性があります。したがって、IPFIXファイルライターとファイルリーダーは、このセクションで説明されているように圧縮をサポートする必要があります。
IPFIX Files support two compression encapsulation formats: bzip2 [bzip2] and gzip [RFC1952]. bzip2 provides better compression than gzip and, as a block compression algorithm, better error recovery characteristics, at the expense of slower compression. gzip is potentially a better choice when compression time is an issue. These two algorithms and encapsulation formats were chosen for ubiquity and ease of implementation.
IPFIXファイルは、BZIP2 [BZIP2]とGZIP [RFC1952]の2つの圧縮カプセル化形式をサポートしています。BZIP2は、GZIPよりも優れた圧縮を提供し、ブロック圧縮アルゴリズムとして、圧縮が遅いため、より良いエラー回復特性を提供します。GZIPは、圧縮時間が問題である場合、潜在的により良い選択です。これらの2つのアルゴリズムとカプセル化形式は、遍在性と実装の容易さのために選択されました。
IPFIX File Readers and Writers supporting compression MUST support bzip2, and SHOULD support gzip.
圧縮をサポートするIPFIXファイルリーダーとライターは、BZIP2をサポートする必要があり、GZIPをサポートする必要があります。
bzip2, gzip, and uncompressed IPFIX Files have distinct magic numbers. IPFIX File Readers SHOULD use these magic numbers to determine what compression, if any, is in use for an IPFIX File, and invoke the proper decompression. bzip2 files are identified by the initial three-octet string 0x42, 0x5A, 0x68 ("BZh"). gzip files are identified by the initial two-octet string 0x1F, 0x8B. IPFIX Files are identified by the initial two-octet string 0x00, 0x0A; these are the version bytes of the first IPFIX Message header in the File.
BZIP2、GZIP、および非圧縮IPFIXファイルには、明確なマジック番号があります。IPFIXファイルリーダーは、これらのマジック番号を使用して、IPFIXファイルに使用されている圧縮を決定し、適切な減圧を呼び出す必要があります。BZIP2ファイルは、最初の3オクテット文字列0x42、0x5a、0x68（ "bzh"）によって識別されます。GZIPファイルは、最初の2オクテット文字列0x1f、0x8bで識別されます。IPFIXファイルは、最初の2オクテット文字列0x00、0x0aで識別されます。これらは、ファイル内の最初のIPFIXメッセージヘッダーのバージョンバイトです。
Compression at the file level, like encryption, is not particularly resilient to errors; in the worst case, a single bit error in a stream-compressed file could result in the loss of the entire file.
暗号化のようなファイルレベルでの圧縮は、エラーに特に回復力がありません。最悪の場合、ストリーム圧縮ファイルの1つのビットエラーにより、ファイル全体が失われる可能性があります。
Since block compression algorithms that support the identification and isolation of blocks containing errors limit the impact of errors on the recoverability of compressed data, the use of bzip2 in applications where error resilience is important is RECOMMENDED.
エラーを含むブロックの識別と分離をサポートするブロック圧縮アルゴリズムは、圧縮データの回復可能性に対するエラーの影響を制限するため、エラーの回復力が重要なアプリケーションでのBZIP2の使用が推奨されます。
Since the block boundary of a block-compressed IPFIX File may fall in the middle of an IPFIX Message, resynchronization of an IPFIX Message stream by a File Reader after a compression error requires some care. The beginning of an IPFIX Message may be identified by its header signature (the Version field of the Message Header, 0x00 0x0A, followed by a 16-bit Message Length), but simply searching for the first occurrence of the Version field is insufficient, since these two bytes may occur in valid IPFIX Template or Data Sets.
ブロック圧縮IPFIXファイルのブロック境界はIPFIXメッセージの途中に収まる可能性があるため、圧縮エラーにある程度の注意が必要な後、ファイルリーダーによるIPFIXメッセージストリームの再同時代化が必要です。IPFIXメッセージの開始は、ヘッダー署名（メッセージヘッダーのバージョンフィールド、0x00 0x0A、16ビットメッセージの長さ）によって識別される場合がありますが、バージョンフィールドの最初の発生を検索するだけでは不十分です。これらの2つのバイトは、有効なIPFIXテンプレートまたはデータセットで発生する場合があります。
Therefore, we specify the following algorithm for File Readers to resynchronize an IPFIX Message Stream after skipping a compressed block containing errors: 1. Search after the error for the first occurrence of the octet string 0x00, 0x0A (the IPFIX Message Header Version field).
したがって、エラーを含む圧縮ブロックをスキップした後、ファイルリーダーがIPFIXメッセージストリームを再同期するように次のアルゴリズムを指定します。1。Octet String 0x00、0x0a（IPFIXメッセージヘッダーバージョンフィールド）の最初の発生をエラー後に検索します。
2. Treat this field as the beginning of a candidate IPFIX Message. Read the two bytes following the Version field as a Message Length, and seek to that offset from the beginning of the candidate IPFIX Message.
2. このフィールドを候補IPFIXメッセージの始まりとして扱います。バージョンフィールドに続く2バイトをメッセージの長さとして読み取り、候補IPFIXメッセージの先頭からそのオフセットを求めます。
3. If the first two octets after the candidate IPFIX Message are 0x00, 0x0A (i.e., the IPFIX Message Header Version field of the next message in the stream), or if the end-of-file is reached precisely at the end of the candidate IPFIX Message, presume that the candidate IPFIX Message is valid, and begin reading the IPFIX File from the start of the candidate IPFIX Message.
3. 候補IPFIXメッセージの後の最初の2オクテットが0x00、0x0a（つまり、ストリームの次のメッセージのIPFIXメッセージヘッダーバージョンフィールド）の場合、または候補IPFIXの終わりに正確にファイルに到達した場合メッセージ、候補IPFIXメッセージが有効であると仮定し、候補IPFIXメッセージの開始からIPFIXファイルの読み取りを開始します。
4. If not, or if the seek reaches end-of-file or another block containing errors before finding the end of the candidate message, go back to step 1, starting the search two bytes from the start of the candidate IPFIX Message.
4. そうでない場合、またはシークが候補メッセージの終了を見つける前にエラーを含む別のブロックまたは別のブロックに到達した場合、ステップ1に戻り、候補IPFIXメッセージの開始から2バイトの検索を開始します。
The algorithm above will improperly identify a non-message as a message approximately 1 in 2^32 times, assuming random IPFIX data. It may be expanded to consider multiple candidate IPFIX Messages in order to increase reliability.
上記のアルゴリズムは、ランダムなIPFIXデータを想定して、2^32回の約1倍の1つのメッセージとして非メッセージを不適切に識別します。信頼性を高めるために、複数の候補IPFIXメッセージを検討するために拡張される場合があります。
In applications (e.g., archival storage) in which error resilience is very important, File Writers SHOULD use block compression algorithms, and MAY attempt to align IPFIX Messages within compression blocks to ease resynchronization after errors. File Readers SHOULD use the resynchronization algorithm above to minimize data loss due to compression errors.
エラーの回復力が非常に重要であるアプリケーション（たとえば、アーカイブストレージ）では、ファイルライターはブロック圧縮アルゴリズムを使用し、エラー後に再同期を容易にするために圧縮ブロック内のIPFIXメッセージを調整しようとする可能性があります。ファイルリーダーは、上記の再同期アルゴリズムを使用して、圧縮エラーによるデータ損失を最小限に抑える必要があります。
This section describes methods for integrating IPFIX File data with other file formats.
このセクションでは、IPFIXファイルデータを他のファイル形式と統合する方法について説明します。
At times, it may be useful to export or store non-IPFIX data inline in an IPFIX File or Message stream. To do this cleanly, this data must be encapsulated into IPFIX Messages so that an IPFIX File Reader or Collecting Process can handle it without any need to interpret it. At the same time, this data must not be changed during transmission or storage. The opaqueOctets Information Element, as defined in Section 8.2.17, is provided for this encapsulation.
時には、IPFIXファイルまたはメッセージストリームに非IPFIXデータをインラインでエクスポートまたは保存すると便利かもしれません。これをきれいに行うには、このデータをIPFIXメッセージにカプセル化して、IPFIXファイルリーダーまたは収集プロセスが解釈する必要なく処理できるようにする必要があります。同時に、このデータを送信またはストレージ中に変更してはなりません。セクション8.2.17で定義されているように、Opakeoctets情報要素は、このカプセル化のために提供されています。
Processing the encapsulated non-IPFIX data is left to a separate processing mechanisms that can identify encapsulated non-IPFIX data in an IPFIX Message Stream, but need not have any other IPFIX handling capability, except the ability to skip over all IPFIX Messages that do not encapsulate non-IPFIX data.
カプセル化された非IPFIXデータの処理は、IPFIXメッセージストリームでカプセル化された非IPFIXデータを識別できる別の処理メカニズムに任されていますが、他のIPFIX処理機能は必要ありません。非IPFIXデータをカプセル化します。
The Message Checksum Options Template, described in Section 8.1.1, may be used as a uniform mechanism to identify errors within encapsulated data.
セクション8.1.1で説明されているメッセージチェックサムオプションテンプレートは、カプセル化されたデータ内のエラーを識別するための均一なメカニズムとして使用できます。
Note that this mechanism can only encapsulate data objects up to 65,515 octets in length. If the space available in one IPFIX Message is not enough for the amount of data to be encapsulated, then the data must be broken into smaller segments that are encapsulated into consecutive IPFIX Messages. Any additional structuring or semantics of the raw data is outside the scope of IPFIX and must be implemented within the encapsulated binary data itself. Furthermore, the raw encapsulated data cannot be assumed by an IPFIX File Reader to have any specific format.
このメカニズムは、長さが最大65,515オクテットのデータオブジェクトのみをカプセル化できることに注意してください。1つのIPFIXメッセージで利用可能なスペースで、データの量をカプセル化するのに十分ではない場合、データは連続したIPFIXメッセージにカプセル化された小さなセグメントに分割する必要があります。生データの追加の構造化またはセマンティクスは、IPFIXの範囲外であり、カプセル化されたバイナリデータ自体に実装する必要があります。さらに、RAWカプセル化されたデータは、IPFIXファイルリーダーが特定の形式を持つように想定することはできません。
Consequently, it may also be useful to reverse the encapsulation, that is, to export or store IPFIX data inline within a non-IPFIX File or data stream. This makes sense when the other file format is not compatible with the encapsulation described above in Section 11.1. Generally speaking, the encapsulation here will be specific to the format of the containing file. For example, IPFIX Files may be embedded in XML elements using hex or Base64 encoding, or in raw binary files using start and end delimiters or some form of run-length encoding. As there are as many potential encapsulations here as there are potential file formats, the specifics of each are out of scope for this specification.
したがって、カプセル化、つまり、IPFIX以外のファイルまたはデータストリーム内にIPFIXデータをインラインでエクスポートまたは保存することも役立つ場合があります。これは、他のファイル形式が上記のセクション11.1で説明したカプセル化と互換性がない場合に理にかなっています。一般的に言えば、ここでのカプセル化は、含有ファイルの形式に固有のものになります。たとえば、IPFIXファイルは、HEXまたはBase64エンコードを使用してXML要素に埋め込まれ、Start and End Delimitersまたは何らかの形式の走行長エンコードを使用して生のバイナリファイルに埋め込まれます。潜在的なファイル形式があるのと同じくらい多くの潜在的なカプセルがあるため、それぞれの詳細はこの仕様の範囲外です。
The Security Considerations section of [RFC5101], on which the IPFIX File format is based, is largely concerned with the proper application of TLS and DTLS to ensure confidentiality and integrity when exporting IPFIX Messages. By analogy, this document specifies the use of CMS [RFC3852] detached signatures to provide equivalent integrity protection to TLS and DTLS in Section 9.1. However, aside from merely applying CMS for signatures, there are several security issues which much be considered in certain circumstances; these are covered in the subsections below.
IPFIXファイル形式の基礎となる[RFC5101]のセキュリティに関する考慮事項セクションは、IPFIXメッセージをエクスポートするときに機密性と整合性を確保するために、TLSとDTLSの適切なアプリケーションに大きく関係しています。類推により、このドキュメントは、セクション9.1でTLSとDTLSに同等の整合性保護を提供するために、CMS [RFC3852]分離署名の使用を指定します。ただし、署名にCMSを適用するだけでなく、特定の状況で考慮されるセキュリティの問題がいくつかあります。これらは、以下のサブセクションで説明されています。
The underlying protocol used to exchange the information that will be stored using the format proposed in this document must as well apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. Such issues are addressed in [RFC5101]. Specifically, IPFIX Files that store data taken from an IPFIX Collecting Process using TLS or DTLS for transport security SHOULD be signed as in Section 9.1 and SHOULD be encrypted out of band; storage of such flow data without encryption may present a potential breach of confidentiality. Conversely, flow data considered sensitive enough to require encryption in storage that is later transmitted using IPFIX SHOULD be transmitted using TLS or DTLS for transport security.
このドキュメントで提案されている形式を使用して保存される情報の交換に使用される基礎となるプロトコルは、エクスポートされた情報の整合性と機密性を保証するために適切な手順を適用する必要があります。このような問題は[RFC5101]で対処されています。具体的には、輸送セキュリティのためにTLSまたはDTLSを使用してプロセスを収集するIPFIXから取得したデータを保存するIPFIXファイルは、セクション9.1のように署名し、バンドから暗号化する必要があります。暗号化なしのこのようなフローデータの保存は、機密性の潜在的な違反をもたらす可能性があります。逆に、IPFIXを使用して後で送信されるストレージで暗号化を必要とするほど敏感であると考えられるフローデータは、輸送セキュリティのためにTLSまたはDTLSを使用して送信する必要があります。
Note that while both TLS and CMS provide the ability to sign an IPFIX Transport Session or an IPFIX File, there exists no method for protecting data integrity end-to-end in the case in which a Collecting Process is collocated with a File Writer. The channel between the Exporting Process to Collecting Process using IPFIX is signed by the Exporting Process key and protected via TLS and DTLS, while the File is signed by the File Writer key and protected via CMS. The identity of the Exporting Process is not asserted in the file, and the records may be modified between the Collecting Process and the File Writer.
TLSとCMSの両方がIPFIXトランスポートセッションまたはIPFIXファイルに署名する機能を提供しますが、収集プロセスがファイルライターとコロークされる場合、データの整合性を保護する方法は存在しないことに注意してください。IPFIXを使用したプロセスへのエクスポートプロセス間のチャネルは、エクスポートプロセスキーによって署名され、TLSおよびDTLSを介して保護され、ファイルはファイルライターキーによって署名され、CMSを介して保護されます。エクスポートプロセスのIDはファイルで主張されておらず、レコードは収集プロセスとファイルライターの間に変更される場合があります。
There are two potential ways to address this issue. The first is by fiat, and is appropriate only when the application allows the Collecting-Process-to-File-Writer channel to be trusted. In this case, the File Writer's signature is an implicit assertion that the channel to the Exporting Process was protected, that the Exporting Process's signature was verified, and that the data was not changed after collection. For this to work, a File Writer collocated with a Collecting Process SHOULD NOT sign a File as specified in Section 9.1 unless the Transport Session over which the data was exported was protected via TLS or DTLS, and the Collecting Process positively identified the Exporting Process by its certificate. The File Writer SHOULD include the Exporting Process and Collecting Process certificates within the File using the Export Session Detail Options Template in Section 8.1.3 or the Message Detail Options Template in Section 8.1.4 to allow for later verification.
この問題に対処するには、2つの潜在的な方法があります。1つ目はフィアットによるものであり、アプリケーションが収集プロセスからファイルへのライターチャネルを信頼できる場合にのみ適切です。この場合、ファイルライターの署名は、エクスポートプロセスへのチャネルが保護され、エクスポートプロセスの署名が検証され、収集後にデータが変更されなかったという暗黙の主張です。これが機能するためには、データがエクスポートされたトランスポートセッションがTLSまたはDTLSを介して保護されていない場合を除き、セクション9.1で指定されたファイルに署名しないでください。その証明書。ファイルライターには、セクション8.1.3のエクスポートセッションの詳細オプションテンプレートを使用して、ファイル内のプロセス証明書のエクスポートと収集プロセス証明書またはセクション8.1.4のメッセージ詳細オプションテンプレートを含める必要があります。
In situations in which the Collecting Process and/or File Writer cannot be trusted, end-to-end integrity can then be approximated by collocating the File Writer with the Metering Process, and removing the IPFIX protocol completely from the chain. In this case, the File Writer's signature is an implicit assertion that the Metering Process is identified and is not tampering with the information as observed on the wire.
収集プロセスおよび/またはファイルライターを信頼できない状況では、エンドツーエンドの整合性をメータープロセスとファイルライターにコロッコ化し、IPFIXプロトコルを完全にチェーンから削除することで近似できます。この場合、ファイルライターの署名は、計量プロセスが特定されており、ワイヤで観察された情報を改ざんしていないという暗黙の主張です。
Verification of these trust relationships is out of scope for this document, and should be considered on a per-implementation basis.
これらの信頼関係の検証は、この文書の範囲外であり、実装ごとに考慮されるべきです。
Note that when encrypting files for archival storage, the cryptographic strength is dependent on the length of time over which archival data is expected to be kept. Long-term storage may require re-application of cryptographic protection, periodically resigning and reencrypting files with stronger keys. In this case, it is recommended that the existing signed and/or encypted data be encapsulated within newer, stronger protection. See [RFC4810] for a discussion of this issue.
アーカイブストレージのファイルを暗号化する場合、暗号化強度は、アーカイブデータが保持されると予想される時間の長さに依存していることに注意してください。長期的なストレージには、暗号化保護の再申請が必要になる場合があり、キーを使用してファイルを定期的に辞任し、再クリップする必要があります。この場合、既存の署名されたデータおよび/またはエンクロートされたデータを、より新しい強力な保護内でカプセル化することをお勧めします。この問題の議論については、[RFC4810]を参照してください。
This document specifies the creation of several new IPFIX Information Elements in the IPFIX Information Element registry located at http://www.iana.org, as defined in Section 8.2 above. IANA has assigned the following Information Element numbers for their respective Information Elements as specified below:
このドキュメントは、上記のセクション8.2で定義されているように、http://www.iana.orgにあるIPFIX情報要素レジストリにいくつかの新しいIPFIX情報要素の作成を指定します。IANAは、以下に指定されているように、それぞれの情報要素に次の情報要素番号を割り当てました。
o Information Element number 258 for the collectionTimeMilliseconds Information Element.
o 情報要素番号258 CollectionTimeMilliseConds情報要素の場合。
o Information Element number 274 for the collectorCertificate Information Element.
o Information要素番号274 CollectorCertificate情報要素の。
o Information Element number 275 for the exporterCertificate Information Element.
o ExporterCertificate情報要素の情報要素番号275。
o Information Element number 259 for the exportSctpStreamId Information Element.
o ExportSCTPSTREAMID情報要素の情報要素番号259。
o Information Element number 260 for the maxExportSeconds Information Element.
o MaxExportSeconds情報要素の情報要素番号260。
o Information Element number 268 for the maxFlowEndMicroseconds Information Element.
o MAXFLOWENDMICROSECONDS情報要素の情報要素番号268。
o Information Element number 269 for the maxFlowEndMilliseconds Information Element.
o maxflowendmilliseconds情報要素の情報要素番号269。
o Information Element number 270 for the maxFlowEndNanoseconds Information Element.
o MAXFLOWENDNANANOSOCONDS情報要素の情報要素番号270。
o Information Element number 261 for the maxFlowEndSeconds Information Element.
o maxflowendseconds情報要素の情報要素番号261。
o Information Element number 262 for the messageMD5Checksum Information Element.
o messagemd5checksum情報要素の情報要素番号262。
o Information Element number 263 for the messageScope Information Element.
o メッセージスコープ情報要素の情報要素番号263。
o Information Element number 264 for the minExportSeconds Information Element.
o Information要素番号264 MINEXPORTSECONDS情報要素の場合。
o Information Element number 271 for the minFlowStartMicroseconds Information Element.
o 情報要素番号271 minflowstartmicroseconds情報要素の場合。
o Information Element number 272 for the minFlowStartMilliseconds Information Element.
o 情報要素番号272 minflowstartMilliseConds情報要素の場合。
o Information Element number 273 for the minFlowStartNanoseconds Information Element.
o 情報要素番号273 minflowstartnananosoconds情報要素の場合。
o Information Element number 265 for the minFlowStartSeconds Information Element.
o 情報要素番号265 minflowstartseconds情報要素の場合。
o Information Element number 266 for the opaqueOctets Information Element.
o Opakeoctets情報要素の情報要素番号266。
o Information Element number 267 for the sessionScope Information Element.
o Sessionscope情報要素の情報要素番号267。
IANA has created the media type application/ipfix for IPFIX data, as described by the following registration information:
IANAは、次の登録情報で説明されているように、IPFIXデータ用のMedia Type Application/IPFixを作成しました。
Type name: application
タイプ名：アプリケーション
Subtype name: ipfix
サブタイプ名：ipfix
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: IPFIX Files are binary, and therefore must be encoded in non-binary contexts.
考慮事項のエンコード：IPFIXファイルはバイナリであるため、非バイナリコンテキストでエンコードする必要があります。
Security considerations: See the Security Considerations (Section 12) of RFC 5655, and the Security Considerations of [RFC5101].
セキュリティ上の考慮事項：RFC 5655のセキュリティ上の考慮事項（セクション12）と[RFC5101]のセキュリティに関する考慮事項を参照してください。
Interoperability considerations: See the "Detailed Specification" (Section 7) of RFC 5655. The format is designed to be broadly interoperable, as any valid stream of IPFIX Messages over any transport specified in [RFC5101] MUST be recognizable as a valid IPFIX File.
相互運用性の考慮事項：RFC 5655の「詳細な仕様」（セクション7）を参照してください。[RFC5101]で指定されたトランスポートにわたってIPFIXメッセージの有効なストリームが有効なIPFIXファイルとして認識できるように、この形式は広く相互運用可能になるように設計されています。
Published specification: RFC 5655, especially Section 7, and [RFC5101].
公開された仕様：RFC 5655、特にセクション7、および[RFC5101]。
Applications that use this media type: Various IPFIX implementations (see [RFC5153]) support the construction of IPFIX File Readers and Writers.
このメディアタイプを使用するアプリケーション：さまざまなIPFIX実装（[RFC5153]を参照）は、IPFIXファイルリーダーとライターの構築をサポートしています。
Additional information:
追加情報：
Magic number(s): None, although the first two bytes of any IPFIX File are the first two bytes of a message header, the Version field, which as of [RFC5101] are always 10 in network byte order: 0x00, 0x0A.
マジック番号：なし：ipfixファイルの最初の2バイトは、メッセージヘッダーの最初の2バイトであるバージョンフィールドですが、[RFC5101]は常にネットワークバイトの順序で10です：0x00、0x0a。
File extension(s): .ipfix
ファイル拡張子：.ipfix
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Person & email address to contact for further information: Brian Trammell <brian.trammell@hitachi-eu.com> for the authors of RFC 5655; Nevil Brownlee <n.brownlee@auckland.ac.nz> for the IPFIX Working Group.
詳細については、個人とメールアドレスをお問い合わせください：Brian Trammell <Brian.trammell@hitachi-eu.com> RFC 5655の著者について。Nevil Brownlee <n.brownlee@auckland.ac.nz> ipfixワーキンググループ。
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: none
使用に関する制限：なし
Change controller: Brian Trammell <brian.trammell@hitachi-eu.com> for the authors of RFC 5655; Nevil Brownlee <n.brownlee@auckland.ac.nz> for the IPFIX Working Group.
Change Controller：Brian Trammell <Brian.trammell@hitachi-eu.com> RFC 5655の著者向け。Nevil Brownlee <n.brownlee@auckland.ac.nz> ipfixワーキンググループ。
Thanks to Maurizio Molina, Tom Kosnar, and Andreas Kind for technical assistance with the requirements for a standard flow storage format. Thanks to Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, and Nevil Brownlee for their reviews and feedback. Thanks to Pasi Eronen for pointing out [RFC5485], and Russ Housley for writing it;
Maurizio Molina、Tom Kosnar、およびAndreasのおかげで、標準のフローストレージ形式の要件について技術支援を受けています。Benoit Claise、Paul Aitken、Andrew Johnson、Gerhard Muenz、Nevil Brownleeのレビューとフィードバックに感謝します。[RFC5485]を指摘してくれたPasi Eronenと、それを書いてくれたRuss Housleyに感謝します。
it specifies a detached signature format, from which Section 9.1 is largely drawn. Thanks to the PRISM project for its support of this work.
セクション9.1が主に描画されているデタッチされた署名形式を指定します。この作業をサポートしてくれたPrismプロジェクトに感謝します。
[RFC5101] Claise, B., "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月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[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、「IPフロー情報エクスポート（IPFIX）情報要素のタイプ情報のエクスポート」、RFC 5610、2009年7月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952] Deutsch、P.、Gailly、J-L。、Adler、M.、Deutsch、L。、およびG. Randers-Pehrson、「GZIPファイル形式の仕様バージョン4.3」、RFC 1952、1996年5月。
[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月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
[RFC4810] Wallace、C.、Pordesch、U。、およびR. Brandner、「長期アーカイブサービス要件」、RFC 4810、2007年3月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[bzip2] Seward, J., "bzip2 (http://www.bzip.org/)", March 2008.
[BZIP2] Seward、J。、 "Bzip2（http://www.bzip.org/）"、2008年3月。
[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 Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., "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月。
[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 Flow Information Export（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、「IPフロー情報エクスポートのアーキテクチャ」、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 Flow Information Export（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、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」、RFC 5473、2009年3月。
[SAINT2007] Trammell, B., Boschi, E., Mark, L., and T. Zseby, "Requirements for a standardized flow storage solution", in Proceedings of the SAINT 2007 workshop on Internet Measurement Technology, Hiroshima, Japan, January 2007.
[Saint2007] Trammell、B.、Boschi、E.、Mark、L。、およびT. Zseby、「標準化されたフローストレージソリューションの要件」、インターネット測定技術に関するSaint 2007ワークショップの議事録、広島、日本、1月2007年。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, March 2009.
[RFC5485] Housley、R。、「インターネットドラフトドキュメントのデジタル署名」、RFC 5485、2009年3月。
[pcap] "libpcap (http://www.tcpdump.org/)", October 2008.
[PCAP] "libpcap（http://www.tcpdump.org/）"、2008年10月。
In this section we will explore an example IPFIX File that demonstrates the various features of the IPFIX File format. This File contains flow records described by a single Template. This File also contains a File Time Window record to note the start and end time of the data, and an Export Session Details record to record collection infrastructure information. Each Message within this File also contains a Message Checksum record, as this File may be externally encrypted and/or stored as an archive. The structure of this File is shown in Figure 2.
このセクションでは、IPFIXファイル形式のさまざまな機能を実証するIPFIXファイルの例を検討します。このファイルには、単一のテンプレートで記述されたフローレコードが含まれています。このファイルには、データの開始時間と終了時間を記録するファイルタイムウィンドウレコードと、記録的なインフラストラクチャ情報を記録するためのエクスポートセッションの詳細記録も含まれています。このファイル内の各メッセージには、メッセージチェックサムレコードも含まれています。このファイルは、アーカイブとして外部から暗号化および/または保存される場合があるためです。このファイルの構造を図2に示します。
+=================================================+
| IPFIX Message seq. 0 |
| +---------------------------------------------+ |
| | Template Set (ID 2) 1 rec | |
| | Data Tmpl. ID 256 | |
| +---------------------------------------------+ |
| | Options Template Set (ID 3) 3 recs | |
| | File Time Window Opt. Tmpl. ID 257 | |
| | Message Checksum Opt. Tmpl. ID 259 | |
| | Export Session Details Opt. Tmpl. ID 258 | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 1 |
| +---------------------------------------------+ |
| | Data Set (ID 257) [File Time Window] 1 rec | |
| +---------------------------------------------+ |
| | Data Set (ID 258) [Export Session] 1 rec | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 4 |
| +---------------------------------------------+ |
| | Data Set (ID 256) 50 recs | |
| | contains flow data | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 55 |
| . . . |
Figure 2: File Example Structure
図2：ファイルの例構造
The Template describing the data records contains a flow start timestamp, an IPv4 5-tuple, and packet and octet total counts. The Template Set defining this is as shown in Figure 3 below:
データレコードを記述するテンプレートには、フロースタートタイムスタンプ、IPv4 5タプル、パケットとオクテットの合計カウントが含まれています。これを定義するテンプレートセットは、以下の図3に示すとおりです。
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 = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds = 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| dest.IPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort = 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| dest.TransportPort = 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier = 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount = 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetTotalCount = 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: File Example Data Template
図3：ファイル例データテンプレート
This is followed by an Options Template Set containing the Options Templates required to read the File: the File Time Window Options Template (defined in Section 8.1.2 above), the Export Session Details Options Template (defined in Section 8.1.3 above), and the Message Checksum Options Template (defined in Section 8.1.1 above). This Options Template Set is shown in Figure 4 and Figure 5 below:
これに続いて、ファイルの読み取りに必要なオプションテンプレートを含むオプションテンプレートセットが続きます。ファイルタイムウィンドウオプションテンプレート（上記のセクション8.1.2で定義）、エクスポートセッションの詳細オプションテンプレート（上記のセクション8.1.3で定義）、メッセージチェックサムオプションテンプレート（上記のセクション8.1.1で定義）。このオプションテンプレートセットを図4と図5に示します。
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 = 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| sessionScope = 267 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| minFlowStartSeconds = 265 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| maxFlowEndSeconds = 261 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Template ID = 259 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 2 | Scope Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| messageScope = 263 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| messageMD5Checksum = 262 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: File Example Options Templates (Time Window and Checksum)
図4：ファイルの例のオプションテンプレート（タイムウィンドウとチェックサム）
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 = 258 | Field Count = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| sessionScope = 267 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| exporterIPv4Address = 130 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| collectorIPv4Address = 211 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| exporterTransportPort = 217 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| col.TransportPort = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| col.TransportProtocol = 215 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| col.ProtocolVersion = 214 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| minExportSeconds = 264 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| maxExportSeconds = 260 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | set padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: File Example Options Templates, Continued (Session Details)
図5：ファイルの例のオプションテンプレート、続き（セッションの詳細）
Following the Templates required to decode the File is the supplemental IPFIX Options information used to describe the File's contents and type information. First comes the File Time Window record; it notes that the File contains data from 9 October 2007 between 00:01:13 and 23:56:27 UTC, and appears as in Figure 6:
ファイルをデコードするために必要なテンプレートに従うことは、ファイルの内容とタイプ情報を説明するために使用される補足IPFIXオプション情報です。最初にファイルの時刻ウィンドウのレコードがあります。このファイルには、2007年10月9日から00：01：13から23:56:27の間のデータが含まれており、図6のように表示されます。
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 = 257 | Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sessionScope | minFlowStartSeconds
| 0 | 2007-10-09 00:01:13 UTC . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maxFlowEndSeconds
. . . | 2007-10-09 23:56:27 UTC . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
. . . |
+-+-+-+-+-+-+-+-+
Figure 6: File Example Time Window
図6：ファイルの例の時間ウィンドウ
This is followed by information about how the data in the File was collected, in the Export Session Details record. This record notes that the session stored in this File was sent via SCTP from an Exporter at 192.0.2.30 port 32769 to a Collector at 192.0.2.40 port 4739, and contains messages exported between 00:01:57 and 23:57:12 UTC on 9 October 2007; it is represented in its Data Set as in Figure 7:
これに続いて、エクスポートセッションの詳細レコードで、ファイル内のデータの収集方法に関する情報が続きます。この記録は、このファイルに保存されているセッションは、192.0.2.30ポート32769の輸出業者から192.0.2.40ポート4739のコレクターにSCTPを介して送信され、00:01:57から23:57:12の間にエクスポートされるメッセージが含まれていることに注目しています。2007年10月9日。図7のように、データセットで表されています。
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 = 258 | Length = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sessionScope | exporterIPv4Address
| 0 | 192.0.2.30 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| collectorIPv4Address
. . . | 192.0.2.31 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| exporterTransportPort | cTPort
. . . | 32769 | 4739 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cTProtocol | cPVersion |
. . . | 132 | 10 | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
minExportSeconds |
. . . 2007-10-09 00:01:57 UTC | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
maxExportSeconds |
. . . 2007-10-09 23:57:12 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: File Example Export Session Details
図7：ファイルの例エクスポートセッションの詳細
Each IPFIX Message within the File is completed with a Message Checksum record; the structure of this record within its Data Set is as in Figure 8:
ファイル内の各IPFIXメッセージは、メッセージチェックサムレコードで完了します。データセット内のこのレコードの構造は、図8のようです。
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 = 259 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| messageScope | |
| 0 | |
+-+-+-+-+-+-+-+-+ |
| messageMD5Checksum |
| (16-byte MD5 checksum of options message) |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | set padding (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: File Example Message Checksum
図8：ファイルの例メッセージチェックサム
After the Templates and supplemental Options information comes the data itself. The first record of an example Data Set is shown with its message and set headers in Figure 9:
テンプレートと補足オプション情報がデータ自体に登場します。例データセットの最初のレコードは、そのメッセージとセットヘッダーが図9に示されています。
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 = 10 | Length = 1296 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 2007-10-09 00:01:57 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 1254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flowStartSeconds |
| 2007-10-09 00:01:13 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort | destinationTransportPort |
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocolId | totalOctetCount
| 6 | 18000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| totalPacketCount
. . . | 65 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (49 more records)
. . . |
+-+-+-+-+-+-+-+-+
Figure 9: File Example Data Set
図9：ファイルの例データセット
Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below.
上記の例をまとめ、必要に応じてメッセージヘッダーを追加すると、上記の例の最初の317バイトのヘックスダンプが、以下の注釈付き図10のように表示されます。
0:|00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01
[^ first message header (length 160 bytes) -->
16:|00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04
[^ data template set -->
32: 00 0C 00 04 00 07 00 02 00 0B 00 02 00 04 00 01
48: 00 55 00 04 00 56 00 04|00 03 00 50 01 01 00 03
[^ opt template set -->
64: 00 01 01 0B 00 01 01 09 00 04 01 05 00 04 01 03
80: 00 02 00 01 01 07 00 01 01 06 00 10 01 02 00 09
80：00 02 00 01 01 07 00 01 06 00 10 01 02 00 09
96: 00 01 01 0B 00 01 00 82 00 04 00 D3 00 04 00 D9
96：00 01 01 0B 00 01 00 82 00 04 00 D3 00 04 00 D9
112: 00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 01 08
112：00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 01 08
128: 00 04 01 04 00 04 00 00|01 03 00 18 00 73 F1 12
[^ checksum record -->
144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00
176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
[^ second message header (length 80 bytes) -->
192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
[^ time window rec -> [ session detail rec ^ -->
208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84
224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
[ message checksum record ^ -->
240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
[^ third message header (length 1296 bytes) -->
272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
[^ set hdr ][^ first data rec -->
288: 80 02 00 50 06 00 00 46 50 00 00 00 41
Figure 10: File Example Hex Dump
図10：ファイルの例HEXダンプ
As the IPFIX Message format is nearly a superset of the NetFlow V9 packet format, IPFIX Files can be used for store NetFlow V9 data relatively easily. This section describes a method for doing so. The differences between the two protocols are outlined in Appendix B.1 below. A simple, lightweight, message-for-message translation method for transforming V9 Packets into IPFIX Messages for storage within IPFIX Files is described in Appendix B.2. An example of this translation method is given in Appendix B.3.
IPFIXメッセージ形式はNetFlow V9パケット形式のほぼスーパーセットであるため、IPFIXファイルはNetflow V9データを比較的簡単に保存できるように使用できます。このセクションでは、そうする方法について説明します。2つのプロトコルの違いは、以下の付録B.1に概説されています。V9パケットをIPFIXファイル内のストレージ用にIPFIXメッセージに変換するためのシンプルで軽量のメッセージ用翻訳方法については、付録B.2に説明します。この翻訳方法の例は、付録B.3に記載されています。
With a few caveats, the IPFIX protocol is a superset of the NetFlow V9 protocol, having evolved from it largely through a process of feature addition to bring it into compliance with the IPFIX Requirements and the needs of stakeholders within the IPFIX Working Group. This appendix outlines the differences between the two protocols. It is informative only, and presented as an exploration of the two protocols to motivate the usage of IPFIX Files to store V9-collected flow data.
いくつかの注意事項があるため、IPFIXプロトコルはNetflow V9プロトコルのスーパーセットであり、IPFIXの要件とIPFIXワーキンググループ内の利害関係者のニーズを順守するために、特徴の追加プロセスを通じて主に進化しました。この付録は、2つのプロトコル間の違いの概要を示しています。これは有益であり、2つのプロトコルの調査として提示され、V9が収集したフローデータを保存するIPFIXファイルの使用を動機付けます。
Both NetFlow V9 and IPFIX use streams of messages prefixed by a message header, though the message header differs significantly between the two. Note that in NetFlow V9 terminology, these messages are called packets, and messages must be delimited by datagram boundaries. IPFIX does not have this constraint. The header formats are detailed below:
Netflow V9とIPFIXはどちらも、メッセージヘッダーが付けられたメッセージのストリームを使用しますが、メッセージヘッダーは2つの間で大きく異なります。Netflow v9用語では、これらのメッセージはパケットと呼ばれ、メッセージはデータグラムの境界で区切る必要があることに注意してください。IPFIXにはこの制約はありません。ヘッダー形式の詳細については、以下に詳しく説明してください。
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 | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NetFlow V9 Packet Header Format
図11：Netflow V9パケットヘッダー形式
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 12: IPFIX Message Header Format
図12：IPFIXメッセージヘッダー形式
Version Number: The IPFIX Version Number MUST be 10, while the NetFlow V9 Version Number MUST be 9.
バージョン番号：IPFIXバージョン番号は10である必要がありますが、NetFlow V9バージョン番号は9でなければなりません。
Length vs. Count: The Count field in the NetFlow V9 packet header counts records in the message (including Data and Template Records), while the Length field in the IPFIX Message Header counts octets in the message. Note that this implies that NetFlow V9 collectors must rely on datagram boundaries or some other external delimiter; otherwise, they must completely consume a message before finding its end.
長さvs.カウント：Netflow V9パケットヘッダーのカウントフィールドは、メッセージ内のレコード（データおよびテンプレートレコードを含む）をカウントし、IPFIXメッセージヘッダーの長さフィールドはメッセージ内のオクテットをカウントします。これは、Netflow V9コレクターがデータグラムの境界または他の外部デリミッターに依存している必要があることを意味することに注意してください。そうでなければ、彼らはその終わりを見つける前にメッセージを完全に消費する必要があります。
System Uptime: System uptime in milliseconds is exported in the NetFlow V9 packet header. This field is not present in the IPFIX Message Header, and must be exported using an IPFIX Option if required.
システムアップタイム：Millisecondsでのシステムアップタイムは、Netflow V9パケットヘッダーでエクスポートされます。このフィールドは、IPFIXメッセージヘッダーに存在せず、必要に応じてIPFIXオプションを使用してエクスポートする必要があります。
Export Time: Aside from being called UNIX Secs in the NetFlow V9 packet header specification, the export time in seconds since 1 January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX message headers.
エクスポート時間：Netflow V9パケットヘッダー仕様でUNIX SECと呼ばれることは別として、0000 UTCの1970年1月1日以来の数秒での輸出時間は、Netflow V9とIPFIXメッセージヘッダーの両方に表示されます。
Sequence Number: The NetFlow V9 Sequence Number counts packets, while the IPFIX Sequence Number counts records in Data Sets. Both are scoped to Observation Domain.
シーケンス番号：Netflow V9シーケンス番号はパケットをカウントし、IPFIXシーケンス番号はデータセットのレコードをカウントします。どちらも観測ドメインにスコープされています。
Observation Domain ID: Similarly, the NetFlow V9 sourceID has become the IPFIX Observation Domain ID.
観察ドメインID：同様に、Netflow V9 SourceIDはIPFIX観測ドメインIDになりました。
Set headers are identical between NetFlow V9 and IPFIX; that is, each Set (FlowSet in NetFlow V9 terminology) is prefixed by a 4-byte set header containing the Set ID and the length of the set in octets.
セットヘッダーは、Netflow V9とIPFIXの間で同じです。つまり、各セット（Netflow V9用語のフローセット）には、セットIDとオクテットのセットの長さを含む4バイトセットヘッダーが付いています。
Note that the special Set IDs are different between IPFIX and NetFlow V9. IPFIX Template Sets are identified by Set ID 2, while NetFlow V9 Template FlowSets are identified by Set ID 0. Similarly, IPFIX Options Template Sets are identified by Set ID 3, while NetFlow V9 Options Template FlowSets are identified by Set ID 1.
特別なセットIDは、IPFIXとNetFlow V9の間で異なることに注意してください。IPFIXテンプレートセットはセットID 2で識別され、Netflow V9テンプレートフローはセットID 0で識別されます。同様に、IPFIXオプションテンプレートセットはセットID 3で識別され、NetFlow V9オプションテンプレートフローはセットID 1で識別されます。
Both protocols reserve Set IDs 0-255, and use Set IDs 256-65535 for Data Sets (or FlowSets, in NetFlow V9 terminology).
どちらのプロトコルも設定されたID 0-255を予約し、データセット（またはフローセット、Netflow V9用語）にセットID 256-65535を使用します。
Template FlowSets in NetFlow V9 support a subset of functionality of those in IPFIX. Specifically, NetFlow V9 does not have any support for vendor-specific Information Elements as IPFIX does, so there is no enterprise bit or facility for associating a private enterprise number with an information element. NetFlow V9 also does not support variable-length fields.
Netflow V9のテンプレートフローセットは、IPFIXの機能のサブセットをサポートしています。具体的には、Netflow V9はIPFIXのようにベンダー固有の情報要素をサポートしていないため、プライベートエンタープライズ番号を情報要素に関連付けるためのエンタープライズビットや施設はありません。Netflow V9は、可変長フィールドもサポートしていません。
Options Template FlowSets in NetFlow V9 are similar to Options Template Sets in IPFIX subject to the same caveats.
Netflow V9のオプションテンプレートフローは、同じ警告を受けます。IPFIXのオプションテンプレートセットに似ています。
The NetFlow V9 field type definitions are a compatible subset of, and have evolved in concert with, the IPFIX Information Model. IPFIX Information Element identifiers in the range 1-127 are defined by the IPFIX Information Model [RFC5102] to be compatible with the corresponding NetFlow V9 field types.
Netflow V9フィールドタイプの定義は、IPFIX情報モデルの互換性のあるサブセットであり、協調して進化しています。範囲1〜127のIPFIX情報要素識別子は、IPFIX情報モデル[RFC5102]によって定義され、対応するNetFlow V9フィールドタイプと互換性があります。
NetFlow V9 has no concept of a Transport Session as in IPFIX, as NetFlow V9 was designed with a connectionless transport in mind. Template IDs are therefore scoped to an Exporting Process lifetime (i.e., an Exporting Process instance between restarts). There is no facility in NetFlow V9 as in IPFIX for Template withdrawal or Template ID reuse. Template retransmission at the Exporter works as in UDP-based IPFIX Exporting Processes.
Netflow V9は、Netflow V9がコネクションレストランスポートを念頭に置いて設計されているため、IPFIXのように輸送セッションの概念はありません。したがって、テンプレートIDは、エクスポートプロセスの寿命（つまり、再起動間のエクスポートプロセスインスタンス）にスコープされます。Netflow V9には、テンプレートの引き出しまたはテンプレートIDの再利用用のIPFIXのように施設はありません。輸出業者でのテンプレートの再送信は、UDPベースのIPFIXエクスポートプロセスのように機能します。
In practice, though NetFlow V9 is designed to be transport-independent, it is transported only over UDP. There is no facility as in IPFIX for full connection-oriented transport without datagram boundaries, due to the use of a record count field as opposed to a message length field in the packet header. There is no support in NetFlow V9 for transport layer security via TLS or DTLS.
実際には、Netflow V9は輸送に依存しないように設計されていますが、UDPを介してのみ輸送されます。パケットヘッダーのメッセージ長フィールドとは対照的に、レコードカウントフィールドの使用により、データグラムの境界なしで完全な接続指向のトランスポート用のIPFIXのように機能はありません。Netflow V9には、TLSまたはDTLSを介した輸送層のセキュリティに関するサポートはありません。
This appendix describes a method for transforming NetFlow V9 Packets into IPFIX Messages, which can be used to store NetFlow V9 data in IPFIX Files. A process transforming NetFlow V9 Packets into IPFIX Messages must handle the fact that NetFlow V9 Packets and IPFIX Messages are framed differently, that sequence numbering works differently, and that the NetFlow V9 field type definitions are only compatible with the IPFIX Information Model below Information Element identifier 128.
この付録では、Netflow V9パケットをIPFIXメッセージに変換する方法について説明します。これは、Netflow V9データをIPFIXファイルに保存するために使用できます。Netflow V9パケットをIPFIXメッセージに変換するプロセスは、NetFlow V9パケットとIPFIXメッセージが異なる方法でフレーム化され、シーケンス番号が異なる機能を除き、NetFlow V9フィールドタイプの定義は情報要素の下のIPFIX情報モデルとのみ互換性があるという事実を処理する必要があります。128。
For each incoming NetFlow V9 packet, the transformation process must:
着信Netflow V9パケットごとに、変換プロセスは次のとおりです。
1. Verify that the Version field of the packet header is 9.
1. パケットヘッダーのバージョンフィールドが9であることを確認します。
2. Verify that the Sequence Number field of the packet header is valid.
2. パケットヘッダーのシーケンス番号フィールドが有効であることを確認します。
3. Scan the packet to:
3. パケットをスキャンします。
1. Verify that it contains no Templates with field types outside the range 1-127;
1. 範囲1〜127の外側のフィールドタイプのテンプレートが含まれていないことを確認します。
2. Verify that it contains no FlowSets with Set IDs between 2 and 255 inclusive;
2. 2〜255の包括的IDを持つフローセットが含まれていないことを確認します。
3. Verify that it contains the number of records in FlowSets, Template FlowSets, and Options Template FlowSets declared in the Count field of the packet header; and
3. パケットヘッダーのカウントフィールドで宣言されたフロー、テンプレートフロー、およびオプションテンプレートフローセットのレコードの数が含まれていることを確認します。と
4. Count the number of records in Data FlowSets for calculating the IPFIX Sequence Number.
4. IPFIXシーケンス番号を計算するために、データフローのレコード数をカウントします。
4. Calculate a Sequence Number for each IPFIX Observation Domain by storing the last Sequence Number sent for each Observation Domain plus the count of records in Data FlowSets in the previous step to be sent as the Sequence Number for the IPFIX Message following this one within that Observation Domain.
4. 各観測ドメインに送信された最後のシーケンス番号と前のステップのデータフローのカウントを保存することにより、各IPFIX観測ドメインのシーケンス番号を計算します。。
5. Generate a new IPFIX Message Header with:
5. 以下で新しいIPFIXメッセージヘッダーを生成します。
1. a Version field of 10;
1. 10のバージョンフィールド。
2. a Length field with the number of octets in the IPFIX Message, generally available by subtracting 4 from the length of the NetFlow V9 packet as returned from the transport layer (accounting for the difference in message header lengths);
2. IPFIXメッセージのオクテット数を持つ長さフィールド。通常、Netflow V9パケットの長さから4を輸送層から返したものから差し引くことで利用できます（メッセージヘッダーの長さの違いを説明します）。
3. the Sequence Number calculated for this message by the Sequence Number calculation step; and
3. シーケンス番号計算ステップでこのメッセージに対して計算されたシーケンス番号。と
4. Export Time and Observation Domain ID taken from the UNIX secs and Source ID fields of the NetFlow V9 packet header, respectively.
4. Netflow V9パケットヘッダーのUNIX SECとソースIDフィールドから取得したエクスポート時間および観測ドメインID。
6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message after the header. Replace Set ID 0 with Set ID 2 for Template Sets, and Set ID 1 with Set ID 3 for Options Template Sets.
6. 各フローセットをNetflow V9パケットからヘッダーの後にIPFIXメッセージにコピーします。セットID 0をテンプレートセットの設定ID2に置き、オプションテンプレートセットの設定ID3に設定ID 1を設定します。
Note that this process loses system uptime information; if such information is required, the transformation process will have to export that information using IPFIX Options. This may require a more sophisticated transformation process structure.
このプロセスはシステムの稼働時間情報を失うことに注意してください。そのような情報が必要な場合、変換プロセスはIPFIXオプションを使用してその情報をエクスポートする必要があります。これには、より洗練された変換プロセス構造が必要になる場合があります。
The following two figures show a single NetFlow V9 packet with templates and the corresponding IPFIX Message, exporting a single flow record representing 60,303 octets sent from 192.0.2.2 to 192.0.2.3. This would be the third packet exported in Observation Domain 33 from the NetFlow V9 exporter, containing records starting with the 12th record (packet and record sequence numbers count from 0).
次の2つの図は、テンプレートを備えた単一のNetflow V9パケットと対応するIPFIXメッセージを示しており、192.0.2.2から192.0.2.3に送信された60,303オクテットを表す単一のフローレコードをエクスポートしています。これは、Netflow V9 Exporterの観測ドメイン33でエクスポートされる3番目のパケットであり、12番目のレコードから始まるレコード（パケットとレコードシーケンス数は0からカウント）を含みます。
The ** symbol in the IPFIX example shows those fields that required modification from the NetFlow V9 packet by the transformation process.
IPFIX例の**記号は、変換プロセスによってNetFlow V9パケットからの変更を必要とするフィールドを示しています。
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 = 9 | Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime = 3750405 ms (1:02:30.405) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 0 | Set Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_SRC_ADDR = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_DST_ADDR = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Set Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_SRC_ADDR |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_DST_ADDR |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES |
| 60303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Example NetFlow V9 Packet
図13：Netflow V9パケットの例
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 = 10 | ** Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ** Sequence Number = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ** Set ID = 2 | Set Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Set Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| octetDeltaCount |
| 60303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Corresponding Example IPFIX Message
図14：対応する例IPFIXメッセージ
Authors' Addresses
著者のアドレス
Brian Trammell Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 13 EMail: brian.trammell@hitachi-eu.com
Brian Trammell Hitachi Europe c/o Eth Zurich Gloriastrasse 35 8092 Zurich Switzerland電話：41 44 632 70 13メール：Brian.trammell@hitachi-eu.com
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 57 EMail: elisa.boschi@hitachi-eu.com
Elisa Boschi Hitachi Europe C/o ETHチューリッヒグロリアストラス35 8092チューリッヒスイス電話：41 44 632 70 57メール：elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer IFAM Wiener Str. 12 28359 Bremen Germany Phone: +49 421 2246206 EMail: lutz.mark@ifam.fraunhofer.de
Lutz Mark Fraunhofer Ifam Wiener str。12 28359ブレーメンドイツ電話：49 421 2246206メール：lutz.mark@ifam.fraunhofer.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 3463 7153 EMail: tanja.zseby@fokus.fraunhofer.de
Tanja Zseby Fraunhofer Open Communication Systems for Open Communication Systems Kaiserin-Augusta-Allee 31 10589ベルリンドイツ電話：49 30 3463 7153メール：tanja.zseby@fokus.fraunhofer.de
Arno Wagner ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 04 EMail: arno@wagner.name