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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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ファイル形式の詳細な仕様3節で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ファイルフォーマットは、この第10節11に記載の第9及び圧縮に記載の暗号化を提供するために活用し、他のフォーマットと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.
[RFC5101]及びそれに関連する文書の「IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様は、」IPトラフィックフロー情報へのアクセスとネットワークエンジニアや管理者に提供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データレコードとテンプレートを輸送するための方法の詳細を説明し
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情報モデルを拡張しますIPFIXファイルのメタデータのための新しい情報要素を提供しています。これは、企業固有の情報要素を含むIPFIXファイルの自己記述をサポートするために、[RFC5610]に記載された方法を使用しています。
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
IPFIXファイル：IPFIXファイルIPFIXメッセージのシリアル化されたストリームです。このストリームは、ファイルシステムに格納されるか、または慣用のファイルのために使用される任意の技術を使用して輸送することができます。 [RFC5101]で定義されるように指定されたIPFIXトランスポートの一つ以上を介して転送時に有効と考えられる任意IPFIXメッセージ・ストリーム（ストリーム制御伝送プロトコル（SCTP）、TCPまたはUDP）であります
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ファイルと見なさ。しかし、このドキュメントは、セクション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のファイルの書き込みプロセスです。この文書によって修正される場合を除き、[RFC5101]で指定されるようにIPFIXファイルライターは、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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ファイルは、単にいくつかのファイルシステムにシリアライズ一つ以上の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つです。シスコのNetFlowを介して収集されたデータを格納する一般的な方法は、ファイルに生のNetFlowデータグラムのストリームをシリアル化することです。これらのNetFlow PDUファイルは、固定長のバイナリフローレコードを含む（ワイヤ上で受信したデータグラムに相当）ヘッダ接頭辞ブロックの集合から成ります。各データグラムのヘッダ部は、次のレコードのNetFlowのバージョンを定義するようにNetFlowのV5、V7、及びV8データは、指定されたファイル内で混合されてもよいです。この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は、構造化データのための新しい「ユニバーサル」の表現形式として登場しました。人間読み込み可能であることを意図しています。確かに、それは、その急速な普及のための一つの理由です。しかし、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のスタート - タグと終了タグの使用、および実際の値の平文エンコーディングは、エンコーディングのサイズが大幅に非効率につながります。典型的なネットワーク・トラフィック・データセットは、代表トラフィックの時間あたりのフロー数百万や数十億を含めることができます。レコードごとにストレージサイズの増加は、フローデータストレージと転送サイズに劇的な影響を与える可能性があります。データ圧縮アルゴリズムは、部分的に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.
しかし、個人情報要素を含むテンプレートは、詳細な種類と意味情報が不足しています。それは理解していない企業固有の情報要素を含むテンプレートによって記述されたデータレコードを受信した収集プロセスは、オクテット配列としてそれらの情報要素内に含まれるデータを処理することができます。
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.
かかわらず、表現形式の、実際のネットワーク上のトラフィックを記述するフローデータは高度に圧縮する傾向があります。圧縮は、ディスク・ストレージおよび特定のワークロードのためのI / O帯域幅の要件を減らすことによって、フロー収集システムの拡張性を改善する傾向があります。理想的な流れの保存形式は、保存されたデータの圧縮をサポートすることにより、この事実を活用したいアプリケーションをサポートする必要があります。
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.
ファイルの順に順次スキャン：バイナリ、記録ストリーム指向のファイル形式は、ネイティブの探索の一形態のみをサポートしています。 （フロー終了時間によって、例えば）を注意深くファイル内のレコードの順序を選択することによって、ファイルは、単一のキーによってインデックス付けすることができます。
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.
この要件は、データ圧縮や暗号化アルゴリズムの選択と相互作用することに注意してください。例えば、ブロックの圧縮アルゴリズムを使用することは、全体のメッセージストリームを無効化、シングルビットエラーの後に再同期するのに失敗することがあり、ストリームの圧縮機とは異なり、単一の圧縮ブロックにエラーを隔離するために役立つことができます。
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.
SCTPまたは一時認証と機密性を提供し、どちらもUDP、以上の輸送のためのTCPまたはデータグラムトランスポート層セキュリティ（DTLS）上でのデータ転送を行うトランスポート層セキュリティ（TLS）を使用するためのサポートを越えて、IPFIXプロトコルは、直接この要件をサポートしていません。 IETFは、完全性及び認証のための取り外し署名を作成するための暗号メッセージ構文（CMS）[RFC3852]を指定しています。第9章は、IPFIXファイルに署名するためのCMSベースの方法を指定します。機密性の保護は、特定のアプリケーションとプロセスの要件を満たすために、ファイルを暗号化するための多くのそのような技術の一つ活かし、この仕様の外部の方法によって満たされるものとします。ただし、暗号化された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.
IPFIXプロトコルは、現在匿名表記をサポートしていません。匿名は[RFC3917]にIPFIXのために与えられた要件の一つであることに留意すべきです。 「MAY」とない要件文書で「MUST」、およびIPFIXプロトコルの現在のバージョンで仕様のその後の欠如と、この要件を修飾するという決定は、匿名化アルゴリズムは、まだ研究のオープンエリアであるという事実によるものです、現在は匿名化のための標準化された方法が存在しないこと。
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プロトコルは、監査能力とreplayabilityのための直接的なサポートが含まれていません。これらの詳細は、8.1.3項で定義されたエクスポートセッションの詳細オプションテンプレートを使用してIPFIXファイルに格納されていてもよい、とメッセージの詳細オプションテンプレートは、セクション8.1.4で定義されています。
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によって収集ストアフローデータを使用することができます。確かに、これは、この文書内に記述ファイル形式の後ろに主要初期動機の一つでした。など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サービス、バージョン9（NetFlowのV9）プロトコル[RFC3954]に基づいているが仕事がIPFIXに始まって以来、二人は発散しました。 NetFlowのV9情報モデルはIPFIX情報モデルの適合性のサブセットであるので、収集のNetFlow V9フローデータを格納するIPFIXファイルを使用することが可能です。このアプローチは、フローデータをエクスポートするための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.
[RFC5471]に記載されているようにまた、ファイルに格納されたIPFIXメッセージの高速再生は、ストレス/負荷テスト（例えば、高い情報要素の着信データレコード、大きなテンプレートの高い速度がカウント）のために使用することができます。試験のための参照ファイルのセットのプロビジョニングおよび使用は、テストの性能を簡素化し、テスト結果の比較可能性を増加させます。
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トランスポートとして扱われ、潜在的に高レイテンシの輸送にもかかわらず、ファイルのReaderとファイルライタと必ずしも同じ時刻に実行されません。
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.
この文書によって修正される場合を除き、[RFC5101]で指定されるようにIPFIXファイルリーダは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ファイルリーダーは、他の定義されたIPFIX輸送層のうちの1つまたは複数によって有効と考えられるように有効な任意のシリアル化された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 IPFIXメッセージ含むテンプレートセット、オプションテンプレートセットを受け入れ、データはTCPやUDP上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];
[RFC5101]のセクション10.3.6に記載されているように場合UDP上IPFIXを使用してテンプレートの再送信で起こり得るように、O、既にファイル内で定義されたテンプレートを定義するテンプレートセットを受け入れます。
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新しいテンプレートは、テンプレートの有効期限とIDの再利用と一貫として、古い置き換えると仮定して再送定義と以前の定義との間の競合を解決IPFIXトランスポートプロトコルにUDPを使用する場合、そして
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.
[RFC5101]のセクション8で説明したように、Oテンプレート引き出しを受け入れ、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項以下を参照してください。ファイルReaderは、単一のトランスポートセッションとファイルの収集を治療する構成可能です。ただし、ファイルのリーダーは、複数のトランスポートセッションを含むように、単一の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ファイルは、ファイルにcommonPropertiesId情報要素が含まれている[RFC5473]に記載された技術と非オプションのテンプレートのすべてを使用している場合は、ファイルリーダーは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.
[RFC5101]で指定されるようにIPFIXファイルライターは、この文書によって修正される場合を除き、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のサブセクションで特定のユースケースの要件によって修飾されない限り、ファイル自体の中にデータを復号するために必要なテンプレートとオプションを格納する必要があります。 [RFC5101]で定義されている。このように、単一IPFIXファイルは、一般的に、単一の想定元本交通のセッションが含まれています。
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 Readerは、その後のテンプレートやオプションのテンプレートを処理するために待つことなく、すべてのデータセットをデコードすることができます確保するために、そのセット内のテンプレートによって記載された任意のデータ・セットの前にファイルに表示されるように、各テンプレートセットまたはオプションのテンプレートセットを発するべきです。
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順に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で説明したメッセージの詳細オプションテンプレートを使用してファイルライターによって記録することができます。メッセージごとの情報は、各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）または（共通のイーサネット用の1500から9000）ほとんどのネットワーク・リンクのMTU 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.
収集プロセスと連結ファイルライターのデータがエクスポートされた上で交通セッションでない限り、セクション9.1で指定されたファイルを署名しないべきではTLSまたはDTLSを経由して保護され、収集プロセスは、正にその証明書によってエクスポートプロセスを特定しました。この問題の詳細については、セクション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で説明やメッセージの詳細オプションテンプレートは、8.1節で説明するには表示されないように注意してください場合には0.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:
ドキュメント、ファイルの作家として使用されるようにファイルを書き込むときファイルリーダーで文書の閲覧や利用を容易にするために、次の順序でファイル内の他のデータレコードの前にオプションのテンプレートによって記述特別なデータレコードを放出することができる：説明時間ウィンドウレコードO以下のセクション8.1.2で定義されたファイルのタイムウィンドウオプションテンプレートによって、に続く：
o Information Element Type Records as described in [RFC5610]; followed by
[RFC5610]に記載されているようにO情報エレメントタイプレコード。に続く
o commonPropertiesId definitions as described in [RFC5473]; followed by
[RFC5473]に記載されているように、O定義commonPropertiesId。に続く
o Export Session details records described by the Export Session Details Options Template as defined in Section 8.1.3 below.
以下のセクション8.1.3で定義されているOエクスポート・セッションは、書き出しセッションの詳細オプションテンプレートによって記述レコードを詳しく説明します。
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ファイルは、ファイルにcommonPropertiesId情報要素が含まれている[RFC5473]に記載された技術と非オプションのテンプレートのすべてを使用している場合は、ファイルリーダーは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ファイルは、フローテーブルの表現のための共通フォーマットとして、内部状態としてフローデータを使用するデバイスのデバッグに使用することができます。そのような状況では、opaqueOctets情報要素は、セクション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.
複数のファイル内のファイルを分割する任意の動作が得られた各ファイルに必要なすべてのテンプレートとオプションを記述し、その記述されたオプションは、得られた各ファイルに対して有効であることを保証すべきである（例えば、タイムウィンドウオプションテンプレートセクション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ファイルのメディアタイプは、アプリケーション/ IPFIXです。このメディアタイプの登録情報[RFC4288]はIANA Considerations部に与えられています。
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
以下のオプションテンプレートはIPFIXメッセージは、メッセージフォーマットまたはプロトコルを拡張することなく、上記で概説した要件を満たすようにストリームを可能にします。これらは、[RFC5102]で定義された既存の情報要素、情報要素で定義されています
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.
[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.
メッセージチェックサムオプションテンプレートは、IPFIXメッセージにMD5メッセージのチェックサムを取り付けるためのデータレコードの構造を指定します。データの整合性がアプリケーションにとって重要であるが、ファイルの署名が利用でき、または所望でないかのように説明したMD5メッセージのチェックサムを使用することができます。説明データレコードは、一度だけIPFIXメッセージごとに表示されなければなりませんが、どこにでもメッセージの中に表示されることがあります。
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時間。ファイルライターは、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ファイルに一度だけ現れるべきです。
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交通セッションを保存する際に、このオプションテンプレートは、SCTPを介して輸送メッセージにのみmessageScopeとcollectionTimeMilliseconds情報要素、および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.
以下の情報要素はIPFIXメッセージプロトコルの拡張子を除いた上で概説要件を満たすようにストリームできるように8.1節のオプションのテンプレートによって使用されます。以下に定義する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オプションとmessageScope情報要素を経由して、それを含む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.
説明：完全なX.509証明書、ASN.1のDER形式でエンコードされた、IPFIXメッセージをTLSまたはDTLSを使用して送信されたときにコレクタが使用します。この情報要素はオプションレコードとsessionScopeと情報要素を経由して、それを含むIPFIX交通セッションにバインドされた、またはオプションレコードとmessageScope情報要素を経由して、それを含む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.
説明：完全なX.509証明書、ASN.1のDER形式でエンコードされた、IPFIXメッセージをTLSまたはDTLSを使用して送信されたときにコレクタが使用します。この情報要素はオプションレコードとsessionScopeと情報要素を経由して、それを含むIPFIX交通セッションにバインドされた、またはオプションレコードとmessageScope情報要素を経由して、それを含む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 Messageの絶対エクスポート時間。この情報要素はその含むIPFIXオプションを経由してIPFIX交通セッションとsessionScopeと情報要素にバインドされるべきです。
Abstract Data Type: 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
説明：必要に応じて、この情報要素を含む範囲内の任意のフロー内の最後のパケットの最新の絶対的なタイムスタンプは、マイクロ秒に切り上げ。この情報要素はその含むIPFIX交通IPFIXオプションを介したセッションとsessionScopeとに結合されるべきです
Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with microsecond-precision (or better) timestamp Information Elements.
情報要素。この情報要素は唯一のマイクロ秒精度（またはそれ以上）でフローレコードを含む交通セッションのタイムスタンプ情報要素で使用されるべきです。
Abstract Data Type: dateTimeMicroseconds
抽象データ型：dateTimeのマイクロ秒
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オプションを経由してIPFIX交通セッションとsessionScopeと情報要素にバインドされるべきです。この情報要素は唯一のミリ秒の精度（またはそれ以上）でフローレコードを含む交通セッションのタイムスタンプ情報要素で使用されるべきです。
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オプションを経由してIPFIX交通セッションとsessionScopeと情報要素にバインドされるべきです。この情報要素は、ナノ秒精度のタイムスタンプ情報要素でフローレコードを含む唯一の交通セッションで使用されるべきです。
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.
説明：必要に応じて、この情報要素を含む範囲内の任意のフロー内の最後のパケットの最新の絶対的なタイムスタンプは、第二に切り上げ。この情報要素はその含むIPFIXオプションを経由してIPFIX交通セッションとsessionScopeと情報要素にバインドされるべきです。
Abstract Data Type: 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チェックサム。この情報要素は、以下に定義する、オプションレコードとmessageScope情報要素を経由して、それを含むIPFIXメッセージにバインドする必要があり、与えられたIPFIXメッセージに一度だけ現れるべきです。この情報要素の値を計算するには、最初にすべてゼロにこの情報要素の値を設定し、含む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オプションを経由してメッセージにチェックサムと収集情報の付着を可能にするために、具体的に提案されます。この情報要素の値は、File Writerまたはエクスポートプロセスによって0と書かなければなりません。この情報要素の値は、File Readerまたは収集プロセスによって無視されなければなりません。
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 Messageの絶対エクスポート時間。この情報要素はオプションレコードとsessionScopeと情報要素を経由して、それを含むIPFIX交通セッションにバインドされるべきです。
Abstract Data Type: 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
抽象データ型：dateTimeのマイクロ秒
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交通セッションにバインドされるべきです。この情報要素は唯一のミリ秒の精度（またはそれ以上）でフローレコードを含む交通セッションのタイムスタンプ情報要素で使用されるべきです。
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.
説明：必要に応じて、この情報要素を含む範囲内の任意のフロー内の最初のパケットの最も早い絶対タイムスタンプは、第二に切り捨て。この情報要素はオプションレコードとsessionScopeと情報要素を経由して、それを含むIPFIX交通セッションにバインドされるべきです。
Abstract Data Type: dateTimeSeconds
抽象データ型：日時秒
ElementId: 265
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データをカプセル化するために使用されます。収集プロセスやファイルライターは、このバイナリデータを解釈しようとしてはなりません。 paddingOctetsの内容は0x00でなければなりませんとだけ情報要素の位置合わせのために意図されている間、その内容は、いくつかの非IPFIXコンテキストで意味のあるように、この情報要素はpaddingOctetsは異なります。
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ファイルへの時間ウィンドウと収集情報の付着を可能にするために、具体的に提案されます。この情報要素の値は、File Writerまたはエクスポートプロセスによって0と書かなければなりません。この情報要素の値は、File Readerまたは収集プロセスによって無視されなければなりません。
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ファイルの作家、ファイルの作家およびファイルリーダーのアイデンティティが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ファイルのための分離署名ファイルは、ファイル拡張子「.p7s」ことを除いて、IPFIXファイルと同じファイル名で、署名されたIPFIXファイルと一緒に、保存された輸送、または他の方法（例えば、HTTP、FTPにより又は）利用できるようにすべきです[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:
分離署名の中では、CMS ContentInfo型は常に存在しなければならない、そしてそれは順番に署名したIPFIXファイルの内容をカプセル化してはならないCMSのSignedDataコンテンツタイプをカプセル化しなければなりません。次のようにCMS分離署名が要約されます。
ContentInfo { contentType id-signedData, -- (1.2.840.113549.1.7.2) content SignedData }
ContentInfo {contentTypeのID-たsignedData、 - （1.2.840.113549.1.7.2）コンテンツの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 }
SignedData {バージョンCMSVersion、 - ファイルライター証明書（複数可）のCRLのCertificateRevocationLists、 - - のSignerInfoの随意signerInfos SET - つのみ署名者は、必ず3 digestAlgorithmsのDigestAlgorithmIdentifiers、encapContentInfo EncapsulatedContentInfo、証明書が証明書群に設定}
SignerInfo { version CMSVersion, -- Always set to 3 sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs SignedAttributes, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs UnsignedAttributes }
SignerInfo {バージョンCMSVersion、 - 常に3のSID SignerIdentifier、digestAlgorithm DigestAlgorithmIdentifier、signedAttrs signedAttributesの、のsignatureAlgorithm SignatureAlgorithmIdentifier、署名SignatureValue、unsignedAttrs UnsignedAttributesに設定}
EncapsulatedContentInfo { eContentType id-data, -- (1.2.840.113549.1.7.1) eContent OCTET STRING -- Always absent }
EncapsulatedContentInfo {のeContentType番号データ、 - （1.2.840.113549.1.7.1）e-コンテンツオクテットSTRING - 常に存在しません}
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の：関連するコンテンツの種類。分離署名ファイルを、密閉型は常にのSignedDataので、ID-たsignedData（1.2.840.113549.1.7.2）オブジェクト識別子は、この分野で存在していなければなりません。
content: a SignedData content, detailed in Section 9.1.2.
コンテンツ：9.1.2項に詳述されたSignedData内容、。
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ファイルをカプセル化しません。 EncapsulatedContentInfoは、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].
CRLを：証明書失効リスト（CRL）のオプションのコレクション。これは、任意のCRLを含めるべきではありません。存在する任意の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証明書のsubjectKeyIdentifier証明書拡張に含ま値と一致する必要があります。
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:
EncapsulatedContentInfo構造は、コンテンツタイプ識別子が含まれています。分離署名が作成されているので、それはIPFIXファイルをカプセル化しません。次のようにEncapsulatedContentInfoのフィールドは、次のとおりです。
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データ（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.
e-コンテンツ：署名済みコンテンツを含むオプションのフィールド。これは分離署名であることから、e-コンテンツが存在してはなりません。
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（Cipher Block Chaining）モードでブロック暗号です。この場合、ファイルの作家も、復号化されたデータのエラーの認識をサポートするために、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ファイルのサポート2つの圧縮のカプセル化フォーマット：bzip2の[BZIP2]とgzip [RFC1952]。 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.
ファイルレベルでの圧縮は、暗号化のような、エラーに特に弾力的ではありません。最悪の場合には、ストリーム圧縮ファイル内の単一ビットエラーはファイル全体の損失につながる可能性があります。
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メッセージの先頭には、そのヘッダの署名（16ビットメッセージ長続くメッセージヘッダのバージョンフィールド、0×00は0x0A）によって識別される、単にバージョンフィールドの最初の出現を検索することは不十分であり、以降もよいですこれらの2つのバイトは、有効なIPFIXテンプレートまたはデータセットで発生する可能性があります。
Therefore, we specify the following algorithm for File Readers to resynchronize an IPFIX Message Stream after skipping a compressed block containing errors:
したがって、我々は、エラーを含む圧縮ブロックをスキップした後IPFIXメッセージストリームを再同期するファイルリーダーのための以下のアルゴリズムを指定します。
1. Search after the error for the first occurrence of the octet string 0x00, 0x0A (the IPFIX Message Header Version field).
オクテット文字列は0x00、0x0Aの（IPFIXメッセージヘッダーのバージョンフィールド）の最初の出現のためのエラーの後1.検索。
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つのオクテットは、0x0Aの（ストリーム内の次のメッセージのすなわち、IPFIXメッセージヘッダーのバージョンフィールド）、0x00である場合、またはエンド・オブ・ファイルはの終わりに正確に達した場合候補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.
追求に達するには、ファイルの終端または候補メッセージの終わりを見つける前に、エラーを含む別のブロック、候補IPFIXメッセージの開始から検索2つのバイトを始めて、ステップ1に戻る4.ない場合、または場合。
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ないメッセージを識別する。信頼性を高めるために、複数の候補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メッセージにカプセル化する必要があります。同時に、このデータは、伝送または保管中に変更してはいけません。 opaqueOctets情報要素は、セクション8.2.17で定義されるように、このカプセル化のために提供されます。
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メッセージをスキップする機能を除き、非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.
このメカニズムはデータのみの長さは65515オクテットまでのオブジェクトをカプセル化できることに注意してください。 1つのIPFIXメッセージ内の利用可能な空間がカプセル化されるべきデータの量のために十分でない場合、データは連続IPFIXメッセージにカプセル化されたより小さなセグメントに分割されなければなりません。生データの任意の追加の構造またはセマンティクスはIPFIXの範囲外であるとカプセル化されたバイナリデータ自体内に実装されなければなりません。さらに、生カプセル化されたデータは、任意の特定のフォーマットを有すること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ファイルは六角またはBase64エンコーディングを使用して、XML要素、または開始および終了区切り文字またはランレングス符号化のいくつかのフォームを使用して生のバイナリファイル内に埋め込むことができます。潜在的なファイル形式があるとして多くの潜在的なカプセル化がここにありますとおり、それぞれの特性は、この仕様の範囲外です。
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]のSecurity Considerations部は、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ファイルに署名する能力を提供しながら、収集プロセスがファイルライタと連結された場合に、データの整合性のエンドツーエンドの保護のための方法が存在しないことに留意されたいです。ファイルは、ファイルライターのキーによって署名され、CMSで保護されている間IPFIXを使用して収集処理へエクスポートプロセスの間のチャネルは、エクスポートプロセス鍵によって署名され、TLSとDTLSを介して保護されています。エクスポートプロセスのアイデンティティは、ファイルにアサートされていない、そしてレコードが収集プロセスとファイルライタ間で変更することができます。
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つの潜在的な方法があります。最初は平坦によるものであり、アプリケーションが収集・プロセス・ツー・ファイル・ライタチャネルが信頼されることを可能にする場合にのみ適切です。この場合、ファイルライターの署名は、エクスポートプロセスへのチャネルは、エクスポートプロセスの署名が検証されたことを、保護されたこと、およびデータが収集後に変更されていないことを暗黙の主張があります。これが機能するためには、セクション9.1で指定されたデータをエクスポートして、その上交通セッションがTLSまたはDTLSを経由して保護され、収集プロセスが積極によってエクスポートプロセスを特定した場合を除き、収集処理と併置ファイルライターがファイルに署名するべきではありませんその証明書。ファイルライターは、後で検証を可能にするために、セクション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
収集処理及び/又はファイルライターが信頼できない状況では、エンドツーエンドの完全性は、その後、計量プロセスとファイルライターを共存さ、及びチェーンから完全にIPFIXプロトコルを除去することによって近似することができます。この場合、ファイル
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.
作家の署名は、計量プロセスが識別され、ワイヤ上に観察されるように情報を改ざんされていない暗黙の主張です。
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.
アーカイブストレージ用のファイルを暗号化する際に、暗号強度はアーカイブデータが保持されることが予想される時間の長さに依存していることに注意してください。長期保存には、定期的に辞任し、より強力なキーでファイルを再暗号化、暗号保護の再申請が必要な場合があります。この場合、既存の署名されたおよび/またはencyptedデータがより新しい、より強力な保護内に封入することが推奨されます。この問題の議論のための[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情報要素collectionTimeMilliseconds情報要素のための数258。
o Information Element number 274 for the collectorCertificate Information Element.
O情報要素collectorCertificate情報要素のための数274。
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情報要素maxFlowEndNanoseconds情報要素のための数270。
o Information Element number 261 for the maxFlowEndSeconds Information Element.
O情報要素maxFlowEndSeconds情報要素のための数261。
o Information Element number 262 for the messageMD5Checksum Information Element.
メッセージMD5チェックサム情報要素のためのO情報要素数262。
o Information Element number 263 for the messageScope Information Element.
O情報要素messageScope情報要素のための数263。
o Information Element number 264 for the minExportSeconds Information Element.
O情報要素minExportSeconds情報要素のための数264。
o Information Element number 271 for the minFlowStartMicroseconds Information Element.
-minFlowStartMicroseconds情報要素の情報要素番号271を、O。
o Information Element number 272 for the minFlowStartMilliseconds Information Element.
-minFlowStartMilliseconds情報要素の情報要素番号272を、O。
o Information Element number 273 for the minFlowStartNanoseconds Information Element.
O情報要素minFlowStartNanoseconds情報要素のための数273。
o Information Element number 265 for the minFlowStartSeconds Information Element.
-minFlowStartSeconds情報要素の情報要素番号265を、O。
o Information Element number 266 for the opaqueOctets Information Element.
O情報要素opaqueOctets情報要素のための数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データのメディアタイプ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.
相互運用性の考慮：[RFC5101]で指定されたトランスポート上IPFIXメッセージの有効なストリームが有効IPFIXファイルとして認識されなければならないのでRFC 5655.の「詳細な説明」（第7章）を参照の形式は、広く相互運用できるように設計されています。
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実装はIPFIXファイルリーダおよびライターの構築をサポートします（[RFC5153]参照します）。
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.
マジックナンバー（S）：なし、任意IPFIXファイルの最初の2つのバイトは、メッセージヘッダの最初の2つのバイトはあるが、[RFC5101]のようなネットワークバイト順で常に10であり、バージョンフィールド、：0x00で、は0x0A。
File extension(s): .ipfix
ファイルの拡張子（S）：.ipfix
Macintosh file type code(s): none
Macintoshのファイルタイプコード（S）：なし
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@hitachi-eu.com> RFC 5655の作者のために。 IPFIXワーキンググループのためNevilブラウンリー<n.brownlee@auckland.ac.nz>。
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.
変更コントローラ：RFC 5655の作者のためのブライアン・トラメル<brian.trammell@hitachi-eu.com>。 IPFIXワーキンググループのためNevilブラウンリー<n.brownlee@auckland.ac.nz>。
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;
標準のフローストレージ形式の要件と技術支援のためのマウリツィオ・モリーナ、トムKosnar、およびアンドレアス種類に感謝します。彼らのレビューとフィードバックのためのブノワClaise、ポール・エイトケン、アンドリュー・ジョンソン、ゲルハルトMuenz、およびNevilブラウンリーに感謝します。それを書くために、[RFC5485]を指摘し、ラスHousleyのためのパシEronenに感謝します。
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.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "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]ボスキ、E.、トラメル、B.、マーク、L.、およびT. Zseby、RFC 5610、2009年7月 "IPフロー情報のエクスポート（IPFIX）情報要素の型情報のエクスポート"。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、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]ドイツ、P.、Gailly氏、J-L。、アドラー、M.、ドイツ、L.、及びG.ラナス-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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ウォレス、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[bzip2] Seward, J., "bzip2 (http://www.bzip.org/)", March 2008.
【BZIP2]スワード、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.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、 "シスコシステムズのNetFlowサービスエクスポートバージョン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]ボスキ、E.、マーク、L.、Quittek、J.、Stiemerling、M.、およびP.エイトケン、 "IPフロー情報のエクスポート（IPFIX）実装ガイドライン"、RFC 5153、2008年4月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009.
[RFC5471] Schmoll、C.、エイトケン、P.、およびB. Claise、RFC 5471、2009年3月 "IPフロー情報のエクスポート（IPFIX）テストのためのガイドライン"。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPフロー情報のエクスポート（IPFIX）の適用"、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]ボスキ、E.、マーク、L.、およびB. Claise、RFC 5473、2009年3月 "IPフロー情報のエクスポート（IPFIX）とパケットサンプリング（PSAMP）レポートで冗長性を削減します"。
[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]トラメル、B.、ボスキ、E.、マーク、L.、およびT. Zseby、インターネット計測技術、広島、日本、月にSAINT 2007ワークショップの議事録では、「標準化されたフローストレージソリューションの要件」、 2007。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（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]解放され、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月。
Appendix A. Example IPFIX File
付録A.例IPFIXファイル
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：例データ・テンプレートファイル
A.1. Example Options Templates
A.1。例オプションテンプレート
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：例オプションテンプレートファイル、継続（セッションの詳細）
A.2. Example Supplemental Options Data
A.2。例補足オプションデータ
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オプション情報です。最初のファイルのタイムウィンドウのレコードが来ます。これは、ファイルが0時01分13秒と夜11時56分27秒UTCとの間に2007年10月9日からのデータが含まれていることを指摘し、図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.40、ポート4739でCollectorに192.0.2.30、ポート32769で輸出業者からSCTPを経由して送信されたことを指摘し、0時01分57秒と23時57分12秒UTCとの間でエクスポートされたメッセージが含まれています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：ファイルのエクスポート・セッションの例詳細
A.3. Example Message Checksum
A.3。メッセージの例チェックサム
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：メッセージの例チェックサムファイル
A.4. File Example Data Set
A.4。例データセットファイル
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：例データセットファイル
A.5. Complete File Example
A.5。完全なファイルの例
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バイトのHEXダンプは、以下の注釈付きの図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
0：| 00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01 [^最初のメッセージ・ヘッダ（長さ160バイト） - > 16：| 00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04 [^データテンプレートセット - > 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
48：00 55 00 04 00 56 00 04 | 00 03 00 50 01 01 00 03 [^ opt以外のテンプレートセット - > 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
８０： ００ ０２ ００ ０１ ０１ ０７ ００ ０１ ０１ ０６ ００ １０ ０１ ０２ ００ ０９
96: 00 01 01 0B 00 01 00 82 00 04 00 D3 00 04 00 D9
猫：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 00 02 00 D8 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
128：04 00 00 00 04 01 04 00 | 01 03 00 18 00 73 12 F 1 [^ cekasum記録 - > 144：2つの44 6 SI 7 58 6 60 06 4 78 74 7 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
176：| 00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 [^第2のメッセージ・ヘッダ（長さ80バイト） - > 192：| 01 01 00 0E 00 47 0AのB6のB9 47 0C 07 1B 00 | 01 02 [^時間窓REC - > [セッションの詳細REC ^ - > 208：00 1C 00 C0 00 02 0C 00 1E 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
224：0A 47 0A B6 E5 47 0C 07 48 00 | 01 03 00 18 00 3E [メッセージチェックサムレコード^ - > 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
256：| 00 0A 05 10 47 0AのB6のE5 00 00 00 06 00 00 00 01 [^第3のメッセージ・ヘッダ（長さ1296バイト） - > 272：| 01 00 04 E6 | 47 0A B6 B9 C0 00 02 02 C0 00 02 03 [^設定HDR] [^最初のデータREC - > 288：80 02 00 50 06 00 00 46 50 00 00 00 41
Figure 10: File Example Hex Dump
図10：ファイルの例HEXダンプ
Appendix B. Applicability of IPFIX Files to NetFlow V9 Flow Storage
NetFlowのV9フローストレージへのIPFIXファイルの付録B.適用性
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に概説されています。 IPFIXファイル内のストレージとしてIPFIXメッセージにV9パケットを変換するための、シンプルで軽量な、メッセージのためのメッセージの変換方法は、付録B.2に記載されています。この変換方法の一例は、付録B.3に記載されています。
B.1. Comparing NetFlow V9 to IPFIX
B.1。 IPFIXへのNetFlow V9を比較
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プロトコルはIPFIX要件とIPFIXワーキンググループ内の利害関係者のニーズへの適合にそれを持って来るために、主に機能追加のプロセスを経て、そこから進化した、NetFlowのV9プロトコルのスーパーセットです。この付録では、2つのプロトコルの違いを概説します。それだけで有益である、とV9-収集したフローデータを保存するためにIPFIXファイルの使用状況をやる気にさせる2つのプロトコルの探求として提示しました。
B.1.1. Message Header Format
B.1.1。メッセージヘッダのフォーマット
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:
メッセージヘッダは、2つの間で大きく異なるがNetFlowのV9とIPFIX双方は、メッセージヘッダで始まるメッセージのストリームを使用します。 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.
バージョン番号：NetFlowのV9バージョン番号は9でなければならない一方、IPFIXバージョン番号は、10でなければなりません。
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.
長さ対数：IPFIXメッセージヘッダの長さフィールドは、メッセージ内のオクテットを数えながらのNetFlow V9パケットヘッダのカウントフィールドは、（データとテンプレートレコードを含む）メッセージ内のレコードをカウントします。これは、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.
システムアップタイムは：ミリ秒単位のシステムの稼働時間は、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.
エクスポート時間：別にUTC 0000で1970年1月1日以降の秒でエクスポート時、NetFlowのV9パケットヘッダ仕様のUNIX秒数呼び出されてからの両方の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.
シーケンス番号：IPFIXシーケンス番号は、データセット内のレコードをカウントしながらのNetFlow V9シーケンス番号は、パケットをカウントします。どちらも、観測ドメインにスコープされています。
Observation Domain ID: Similarly, the NetFlow V9 sourceID has become the IPFIX Observation Domain ID.
観測ドメインIDは：同様に、NetFlowのV9ソースIDはIPFIX観測ドメインIDとなっています。
B.1.2. Set Header Format
B.1.2。ヘッダー形式を設定します。
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の間で異なっていることに注意してください。 NetFlowのV9テンプレートフローセットは、セットID同様に、IPFIXオプションテンプレートセットはセットID 3によって識別される0によって識別されている間のNetFlow V9オプションテンプレートフローセットは、セットID 1によって識別されている間IPFIXテンプレートセットは、セットID 2によって識別されます。
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を使用します。
B.1.3. Template Format
B.1.3。テンプレートのフォーマット
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対象におけるオプションテンプレートセットに似ています。
B.1.4. Information Model
B.1.4。情報モデル
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情報要素識別子は、対応のNetFlow V9フィールドタイプと互換性があるようにIPFIX情報モデル[RFC5102]で定義されます。
B.1.5. Template Management
B.1.5。テンプレート管理
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はしたがって、エクスポートプロセスの寿命（再起動の間、すなわち、エクスポートプロセスインスタンス）にスコープされています。テンプレートの撤退またはテンプレートIDの再利用のためのIPFIXのように、NetFlowのV9での機能はありません。輸出業者のテンプレート再送はUDPベースのIPFIXのエクスポートプロセスのように動作します。
B.1.6. Transport
B.1.6。輸送
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のように何の施設は、ありません。 TLSまたはDTLSを介したトランスポート層セキュリティのためのNetFlow V9でのサポートはありません。
B.2. A Method for Transforming NetFlow V9 Messages to IPFIX
B.2。 IPFIXへのNetFlow V9メッセージを変換する方法
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.
この付録では、IPFIXファイル内のNetFlow V9データを格納するために使用することができるIPFIXメッセージへのNetFlow V9パケットを変換するための方法を記載しています。 IPFIXメッセージへのNetFlow V9パケットを変換するプロセスは、NetFlow V9パケットおよびIPFIXのメッセージは、その順序が違った作品に番号を、別々に囲まれているという事実を処理しなければならない、とのNetFlow V9フィールドタイプの定義は、情報要素識別子以下IPFIX情報モデルのみと互換性があること128。
For each incoming NetFlow V9 packet, the transformation process must:
各着信のNetFlow V9パケットに対して、変換処理しなければなりません。
2. Verify that the Sequence Number field of the packet header is valid.
2.パケットヘッダのシーケンス番号フィールドが有効であることを確認してください。
1. Verify that it contains no Templates with field types outside
the range 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.それはフローセットのレコード数が含まれていることを確認し、テンプレートフローセット、およびオプションテンプレートフローセットは、パケットヘッダのCountフィールドで宣言されました。そして
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.その内、この1次IPFIXメッセージのシーケンス番号として送信されるように、各観測ドメインに加えて、前のステップでのデータフローセット内のレコードのカウントのために送られた最後のシーケンス番号を格納することにより、各IPFIX観測ドメインのシーケンス番号を計算します観測ドメイン。
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.トランスポート層から返されたNetFlow V9パケットの長さから4を減算することによって、一般的に入手可能なIPFIXメッセージにおけるオクテットの数と長さフィールドは、（メッセージヘッダーの長さの違いを占めます）。
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.エクスポート時間と観測ドメインIDは、それぞれ、UNIXの秒とNetFlow V9パケットヘッダの送信元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.コピーヘッダの後IPFIXメッセージへのNetflow V9パケットから各フローセット。オプションテンプレートセットのセットID 3を持つテンプレートセットのセットID 2、およびSet ID 1とセットID 0を交換してください。
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オプションを使用して、その情報をエクスポートする必要があります。これは、より洗練された変換プロセス構造が必要な場合があります。
B.3. NetFlow V9 Transformation Example
B.3。 NetFlowのV9変換例
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つの図は、192.0.2.2から192.0.2.3に送信された60303個のオクテットを表す単一のフローレコードをエクスポートし、テンプレートと単一のNetFlow V9パケットと対応するIPFIXメッセージを表示します。これは、12レコード（パケット及びレコードシーケンス番号が0からカウント）で始まるレコードを含む、NetFlowのV9エクスポータから観測ドメイン33でエクスポート第3のパケットであろう。
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
ブライアン・トラメル日立ヨーロッパのC / O ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス電話：+41 44 632 70 13 Eメール：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
エリサボスキ日立ヨーロッパのC / O ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス電話：+41 44 632 70 57 Eメール：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
ルッツマーク・フラウンホーファーIFAMウィーンのStr。 12 28359ブレーメンドイツ電話：+49 421 2246206 Eメール：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
オープン通信システムのためのターニャZsebyフラウンホーファー研究所カイザリンオーガスタダレ31 10589ベルリンドイツ電話：+49 30 3463 7153 Eメール：tanja.zseby@fokus.fraunhofer.de
Arno Wagner ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 04 EMail: arno@wagner.name
アルノ・ワグナーETHチューリッヒGloriastrasse 35 8092チューリッヒスイス電話：+41 44 632 70 04 Eメール：arno@wagner.name