Network Working Group E. Boschi
Request for Comments: 5153 Hitachi Europe
Category: Informational L. Mark
Fraunhofer FOKUS
J. Quittek
M. Stiemerling
NEC
P. Aitken
Cisco Systems, Inc.
April 2008
IP Flow Information Export (IPFIX) Implementation Guidelines
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.).
IPフロー情報エクスポート（IPFIX）プロトコルは、IPフロー情報は、ルータ、計測プローブ、または他のデバイスからエクスポートすることができる方法を定義します。このドキュメントは、IPFIXプロトコルの実装と使用のためのガイドラインを提供します。 （等ファイアウォール、ネットワークアドレス変換、トンネルエンドポイント、パケット分類器、等）中間装置のガイドラインアドレステンプレート管理、トランスポート固有の問題、プロセスのエクスポートおよび収集の実装、およびIPFIX実装のいくつかのセット。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3
1.2. Overview of the IPFIX Protocol . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Template Management Guidelines . . . . . . . . . . . . . . . . 4
3.1. Template Management . . . . . . . . . . . . . . . . . . . 4
3.2. Template Records versus Options Template Records . . . . . 5
3.3. Using Scopes . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Multiple Information Elements of the Same Type . . . . . . 6
3.5. Selecting Message Size . . . . . . . . . . . . . . . . . . 6
4. Exporting Process Guidelines . . . . . . . . . . . . . . . . . 7
4.1. Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Information Element Coding . . . . . . . . . . . . . . . . 7
4.3. Using Counters . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. Alignment of Information Elements within a Data
Record . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Alignment of Information Element Specifiers within
a Template Record . . . . . . . . . . . . . . . . . . 9
4.4.3. Alignment of Records within a Set . . . . . . . . . . 9
4.4.4. Alignment of Sets within an IPFIX Message . . . . . . 9
4.5. Time Issues . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. IPFIX Message Header Export Time and Data Record Time . . 10
4.7. Devices without an Absolute Clock . . . . . . . . . . . . 11
5. Collecting Process Guidelines . . . . . . . . . . . . . . . . 11
5.1. Information Element (De)Coding . . . . . . . . . . . . . . 11
5.2. Reduced-Size Encoding of Information Elements . . . . . . 12
5.3. Template Management . . . . . . . . . . . . . . . . . . . 12
6. Transport-Specific Guidelines . . . . . . . . . . . . . . . . 12
6.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Guidelines for Implementation on Middleboxes . . . . . . . . . 18
7.1. Traffic Flow Scenarios at Middleboxes . . . . . . . . . . 20
7.2. Location of the Observation Point . . . . . . . . . . . . 21
7.3. Reporting Flow-Related Middlebox Internals . . . . . . . . 22
7.3.1. Packet Dropping Middleboxes . . . . . . . . . . . . . 23
7.3.2. Middleboxes Changing the DSCP . . . . . . . . . . . . 23
7.3.3. Middleboxes Changing IP Addresses and Port Numbers . . 24
8. Security Guidelines . . . . . . . . . . . . . . . . . . . . . 25
8.1. Introduction to TLS and DTLS for IPFIX Implementers . . . 25
8.2. X.509-Based Identity Verification for IPFIX over TLS
or DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Implementing IPFIX over TLS over TCP . . . . . . . . . . . 26
8.4. Implementing IPFIX over DTLS over UDP . . . . . . . . . . 26
8.5. Implementing IPFIX over DTLS over SCTP . . . . . . . . . . 27
9. Extending the Information Model . . . . . . . . . . . . . . . 27
9.1. Adding New IETF-Specified Information Elements . . . . . . 27
9.2. Adding Enterprise-Specific Information Elements . . . . . 28
10. Common Implementation Mistakes . . . . . . . . . . . . . . . . 28
10.1. IPFIX and NetFlow Version 9 . . . . . . . . . . . . . . . 28
10.2. Padding of the Data Set . . . . . . . . . . . . . . . . . 29
10.3. Field ID Numbers . . . . . . . . . . . . . . . . . . . . . 30
10.4. Template ID Numbers . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
The IPFIX protocol [RFC5101] defines how IP Flow information can be exported from routers, measurement probes, or other devices. In this document, we provide guidelines for its implementation.
IPFIXプロトコル[RFC5101]はIPフロー情報は、ルータ、計測プローブ、または他のデバイスからエクスポートすることができる方法を定義します。この文書では、我々は、その実施のためのガイドラインを提供します。
The guidelines are split into seven main sets. These sets address implementation aspects for Template management, Exporting Process, Collecting Process, transport, implementation on middleboxes, security, and extending the information model.
ガイドラインでは、7つの主要セットに分割されています。これらのセットは、ミドルボックスの実装、セキュリティ、輸送、回収処理、プロセスのエクスポート、テンプレート管理のための実装の側面に対処し、情報モデルを拡張します。
Finally, this document contains a list of common mistakes related to issues that had been misinterpreted in the first IPFIX implementations and that created (and still might create) interoperability problems.
最後に、相互運用性の問題を、この資料は、最初のIPFIX実装で誤解されていた問題に関連する一般的なミスのリストが含まれていることは、作成した（まだ作成することがあります）。
The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX architecture [IPFIX-ARCH], per the requirements defined in [RFC3917].
IPFIXプロトコル[RFC5101]はIPフロー情報へのアクセスをネットワーク管理者に提供します。収集プロセスにIPFIXエクスポートプロセスのうち測定IPフロー情報のエクスポートのためのアーキテクチャは、[RFC3917]で定義された要件に従って、IPFIXアーキテクチャ[IPFIX-ARCH]で定義されています。
The IPFIX architecture [IPFIX-ARCH] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIXアーキテクチャ[IPFIX-ARCH]どのIPFIXデータレコードとテンプレートがIPFIX収集プロセスにIPFIXエクスポートプロセスから渋滞認識トランスポートプロトコルを介して行われる指定します。
IPFIX has a formal description of IPFIX Information Elements, their name, type, and additional semantic information, as specified in the IPFIX information model [RFC5102].
IPFIXはIPFIX情報モデル[RFC5102]で指定されるように、正式なIPFIX情報要素の説明、自分の名前、タイプ、および追加の意味情報を持っています。
Finally, the IPFIX applicability statement [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
最後に、IPFIXの適用文[IPFIX-AS]はIPFIXプロトコルを使用できるアプリケーションの種類と、彼らが提供された情報を使用する方法について説明します。それはさらに、IPFIXフレームワークは、他のアーキテクチャおよびフレームワークの関係を示します。
In the IPFIX protocol, { type, length, value } tuples are expressed in Templates containing { type, length } pairs, specifying which { value } fields are present in Data Records conforming to the Template, giving great flexibility as to what data is transmitted.
どのようなデータ伝達されるようIPFIXプロトコルでは、{タイプ、長さ、値}の組は、大きな柔軟性を与える{値}のフィールドがテンプレートに適合データレコードに存在する{タイプ、長さ}ペア、指定を含むテンプレートで表され。
Since Templates are sent very infrequently compared with Data Records, this results in significant bandwidth savings.
テンプレートは、データレコードと比較して非常に低い頻度で送信されているので、これはかなりの帯域幅の節約になります。
Different Data Records may be transmitted simply by sending new Templates specifying the { type, length } pairs for the new data format. See [RFC5101] for more information.
異なるデータ・レコードは、単に新たなデータ形式の{タイプ、長さ}ペアを指定する新しいテンプレートを送信することによって送信されてもよいです。詳細については、[RFC5101]を参照してください。
The IPFIX information model [RFC5102] defines a large number of standard Information Elements that provide the necessary { type } information for Templates.
IPFIX情報モデル[RFC5102]はテンプレートの必要{タイプ}の情報を提供する標準の情報要素の多数を定義します。
The use of standard elements enables interoperability among different vendors' implementations. The list of standard elements may be extended in the future through the process defined in Section 9, below. Additionally, non-standard enterprise-specific elements may be defined for private use.
標準的な要素の使用は、異なるベンダーの実装間の相互運用を可能にします。標準的な要素のリストは、以下のセクション9で定義されたプロセスを介して、将来的に拡張することができます。また、非標準のエンタープライズ固有の要素は、私的使用のために定義することができます。
The terminology used in this document is fully aligned with the terminology defined in [RFC5101]. Therefore, the terms defined in the IPFIX terminology are capitalized in this document, as in other IPFIX documents ([RFC5101], [RFC5102], [IPFIX-ARCH]).
本書で使用される用語は、完全に[RFC5101]で定義された用語と位置合わせされます。したがって、IPFIXの用語で定義された用語は、他のIPFIX文書（[RFC5101]、[RFC5102]、[IPFIX-ARCH]）のように、本書で計上されます。
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]に記載されているように解釈されます。
This document is Informational. It does not specify a protocol and does not use RFC 2119 key words [RFC2119] such as "MUST" and "SHOULD", except in quotations and restatements from the IPFIX standards documents. The normative specification of the protocol is given in the IPFIX protocol [RFC5101] and information model [RFC5102] documents.
この文書は情報です。これは、プロトコルを指定しないとIPFIX標準文書からの引用及び修正再表示を除き、そのような「MUST」と「SHOULD」としてRFC 2119のキーワード[RFC2119]を使用していません。プロトコルの規範的仕様は、IPFIXプロトコル[RFC5101]と情報モデル[RFC5102]の文書に記載されています。
The Exporting Process should always endeavor to send Template Records before the related Data Records. However, since the Template Record may not arrive before the corresponding Data Records, the Collecting Process MAY store Data Records with an unknown Template ID pending the arrival of the corresponding Template (see Section 9 of [RFC5101]). If no Template becomes available, we recommend logging the event and discarding the corresponding Data Records, and for SCTP and TCP we recommend resetting the Transport Session. The amount of time the Collecting Process waits for a Template before resetting should be configurable. We recommend a default of 30 minutes. Note that when using UDP as the transport protocol, this delay should be bound, when possible, by the Template Retransmit and the Template Expiry times (see Section 6.2).
エクスポートプロセスは、常に関連するデータレコードの前にテンプレートレコードを送信するために努力する必要があります。テンプレートレコードは、対応するデータレコードの前に到着しなくてもよいので、収集プロセスは、対応するテンプレート（[RFC5101]のセクション9を参照）の到着ペンディング未知のテンプレートIDとデータレコードを格納することができます。何のテンプレートが利用可能になっていない場合は、私たちはイベントをログに記録し、対応するデータレコードを破棄し、SCTPとTCPのために、私たちは交通のセッションをリセットすることをお勧めしますお勧めします。収集プロセスをリセットする前にテンプレートを待機する時間は設定可能でなければなりません。私たちは、30分のデフォルトをお勧めします。トランスポートプロトコルとしてUDPを使用する場合、この遅延は、テンプレートの再送信とテンプレート有効期限時間（6.2節を参照）によって、可能な場合、結合されるべきであることに留意されたいです。
The Exporting Process must be able to resend active Templates. Templates must be resent in the case of a Stream Control Transport Protocol (SCTP) association restart, a User Datagram Protocol (UDP) template refresh, or a Transmission Control Protocol (TCP) connection restart.
エクスポートプロセスは、アクティブなテンプレートを再送信することができなければなりません。テンプレートは、ストリーム制御転送プロトコル（SCTP）関連の再起動、ユーザーデータグラムプロトコル（UDP）テンプレートのリフレッシュ、または伝送制御プロトコル（TCP）接続の再起動の場合に再送する必要があります。
The Exporting Process is responsible for the management of Template IDs. Should an insufficient number of Template IDs be available, the Exporting Process must send a Template Withdrawal Message in order to free up the allocation of unused Template IDs. Note that UDP doesn't use the Template Withdrawal Message, and the Template lifetime on the Collecting Process relies on timeout.
エクスポートプロセスは、テンプレートIDの管理を担当しています。テンプレートIDの数が不十分利用可能であるべき、エクスポートプロセスは、未使用のテンプレートIDの割り当てを解放するためにテンプレート無効化メッセージを送信する必要があります。 UDPは、テンプレート無効化メッセージを使用していないことに注意してください、と収集プロセスのテンプレートの寿命はタイムアウトに依存しています。
The IPFIX protocol [RFC5101] defines and specifies the use of Templates and Options Templates. Templates define the layout of Data Records, which represent Flow data. Options Templates additionally specify scope Information Elements, which can be used to define scoped Data Records. Scoped Data Records generally export control plane data (such as metadata about processes in the IPFIX collection architecture) or data otherwise applicable to multiple Flow Data Records (such as common properties as in [IPFIX-REDUCING]).
IPFIXプロトコル[RFC5101]は定義とテンプレートとオプションテンプレートの使用を指定します。テンプレートは、フローデータを表すデータレコードのレイアウトを定義します。オプションテンプレートは、さらにスコープのデータレコードを定義するために使用することができスコープ情報要素を、指定します。データレコードは、一般的に（例えば[IPFIX低減]のように共通のプロパティのような）複数のフローデータレコードになければ適用制御プレーン（例えばIPFIX収集アーキテクチャのプロセスに関するメタデータとして）データ又はデータをエクスポートスコープ。
Aside from Section 4 of [RFC5101], which defines specific Options Templates to use for reporting Metering Process and Exporting Process statistics and configuration information, the choice to use Options Templates is left up to the implementer. Indeed, there is a trade-off between bandwidth efficiency and complexity in the use of Options Templates and scoped Data Records.
別に計量プロセスとエクスポートプロセスの統計情報と設定情報を報告するために使用する特定のオプションテンプレートを定義し、[RFC5101]のセクション4から、オプションテンプレートを使用する選択は実装者に任されます。確かに、そこに帯域幅の効率性と複雑性とのトレードオフは、オプションのテンプレートを使用中で、データレコードのスコープ。
For example, control plane information about an Observation Point could be exported with every Flow Record measured at that Observation Point, or in a single Data Record described by an Options Template, scoped to the Observation Point identifier. In the former case, simplicity of decoding the data is gained in exchange for redundant export of the same data with every applicable Flow Record. The latter case is more bandwidth-efficient, but at the expense of requiring the Collecting Process to maintain the relationship between each applicable Flow Record and the Observation Point.
例えば、観測点の周りの制御プレーン情報は、その観測点で測定毎にフローレコードでエクスポートすることができ、またはオプションテンプレートによって記述される単一のデータレコードに、観測ポイント識別子にスコープ。前者の場合には、データを復号化するの単純さは、すべての適用可能なフローレコードと同じデータの冗長輸出と引き換えに得られます。後者の場合は、より多くの帯域幅効率が、それぞれ該当するフローレコードと観測点との間の関係を維持するために、収集プロセスを必要とする費用です。
A generalized method of using Options Templates to increase bandwidth efficiency is fully described in [IPFIX-REDUCING].
帯域幅の効率を高めるためのオプションテンプレートを使用する一般的な方法は、完全[IPFIX還元]に記載されています。
The root scope for all IPFIX Messages is the Observation Domain, which appears in the Message Header. In other words, all Data Records within a message implicitly belong to the Observation Domain. All Data Records described by Options Templates (and only those) must be restricted to an additional scope within the Observation Domain, as defined by the scope Information Elements in the Options Template Record.
すべてのIPFIXメッセージのルートスコープは、メッセージヘッダに表示されて観測ドメイン、です。言い換えれば、メッセージ内のすべてのデータレコードは、暗黙的に観測ドメインに属しています。スコープオプションテンプレートレコードの情報要素で定義されたオプションのテンプレート（とのみ）で説明されているすべてのデータレコードは、観測ドメイン内の追加の範囲に制限されなければなりません。
In IPFIX, any Information Element can be used for scope. However, Information Elements such as counters, timestamps, padding elements, Flow properties like timeout, Flow end reason, duration, or Min/Max Flow properties [RFC5102] may not be appropriate.
IPFIXでは、任意の情報要素は、スコープのために使用することができます。しかしながら、このようなカウンタ、タイムスタンプ、パディング要素、タイムアウト、フロー終了の理由、期間、または最小/最大流動性のような流動性のような情報エレメント[RFC5102]は適切ではないかもしれません。
Note that it is sometimes necessary to export information about entities that exist outside any Observation Domain, or within multiple Observation Domains (e.g., information about Metering Processes scoped to meteringProcessID). Such information SHOULD be exported in an IPFIX Message with Observation Domain ID 0 (see [RFC5101], Section 3.1).
任意の観測ドメイン外に存在する、または複数の観測ドメイン内のエンティティについての情報をエクスポートすることが必要な場合があることに留意されたい（例えば、計量プロセスに関する情報がmeteringProcessIDにスコープ）。そのような情報は、（[RFC5101]、セクション3.1を参照）観測ドメインID 0のIPFIXメッセージでエクスポートされるべきです。
The Exporting Process and Collecting Process MUST support the use of multiple Information Elements of the same type in a single Template [RFC5101]. This was first required by Packet Sampling (PSAMP) [PSAMP-PROTO] for the export of multiple Selector IDs. Note that the IPFIX protocol recommends that Metering Processes SHOULD use packet treatment order when exporting multiple Information Elements of the same type in the same record ([RFC5101] Section 8). This implies that ordering is important, and changes to the order of multiple identical Information Elements could cause information loss. Therefore, we strongly recommend preservation of the order of multiple Information Elements of the same type by Exporting and Collecting Processes for correct processing and storage.
エクスポートプロセスと収集処理は、単一のテンプレート[RFC5101]で同じタイプの複数の情報要素の使用をサポートしなければなりません。これは、第1の多重セレクタIDの輸出のためのパケットサンプリング（PSAMP）[PSAMP-プロト]で必要でした。 IPFIXプロトコルは、同じレコード（[RFC5101]セクション8）で同じタイプの複数の情報要素をエクスポートするときに計量プロセスは、パケット処理の順序を使用することをお勧めしますことに留意されたいです。これは、順序が重要であることを意味し、複数の同一の情報要素の順序を変更すると、情報の損失を引き起こす可能性があります。したがって、我々は強くエクスポートし、正しい処理及び記憶するためのプロセスを収集することにより、同じタイプの複数の情報要素の順序の保存をお勧めします。
Section 10.3.3 of the IPFIX protocol defines the maximum message size for IPFIX Messages transported over UDP to be constrained by the path MTU, or if the path MTU is not available, 512 bytes, which is the minimum datagram size all IP implementations must support (see also Section 8.4). However, no maximum message size is imposed on other transport protocols, beyond the 65535-byte limit imposed by the 16- bit Message Length field in the IPFIX Message Header specified in Section 3.1 of [RFC5101].
IPFIXプロトコルのセクション10.3.3は、パスMTUによって制約されるUDPを介して転送IPFIXメッセージの最大メッセージサイズを定義する、またはパスMTUは、すべてのIP実装がサポートしなければならない最小データグラムサイズである、512バイト利用可能でない場合（また、8.4節を参照してください）。しかし、最大メッセージサイズは、[RFC5101]のセクション3.1で指定されたIPFIXメッセージヘッダー内の16ビットメッセージ長フィールドによって課さ65535バイトの限界を超えて、他のトランスポートプロトコルに課されていません。
An IPFIX Exporting Process operating over SCTP or TCP may export IPFIX Messages up to this 64-kB limit, and an IPFIX Collecting Process must accept any IPFIX Message up to that size.
SCTPまたはTCP上で動作するIPFIXエクスポートプロセスは、この64 kbの限界にIPFIXメッセージをエクスポートすることができ、IPFIX収集プロセスは、そのサイズまでの任意のIPFIXメッセージを受け入れなければなりません。
A Set is identified by a Set ID [RFC5101]. A Set ID has an integral data type and its value is in the range of 0-65535. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. A value of 2 identifies a Template Set. A value of 3 identifies an Options Template Set. Values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. In this case, the Set ID corresponds to the Template ID of the used Template.
セットは、セットID [RFC5101]によって識別されます。セットIDは、一体データ・タイプを有し、その値は、0〜65535の範囲です。 0と1のセットのID値は、歴史的な理由[RFC3954]のために使用されていません。 2の値は、テンプレートセットを識別する。 3の値は、オプションのテンプレートセットを識別します。 4から255までの値は、将来の使用のために予約されています。 255以上の値はデータセットのために使用されています。この場合、セットIDが使用されるテンプレートのテンプレートIDに対応します。
A Data Set received with an unknown Set ID may be stored pending the arrival of the corresponding Template (see Section 9 of [RFC5101]). If no Template becomes available, we recommend logging the event and discarding the corresponding Data Records, and for SCTP and TCP we recommend resetting the Transport Session. The amount of time the Collecting Process waits for a Template before resetting should be configurable. We recommend a default of 30 minutes. Note that when using UDP as the transport protocol, this delay should be bound, when possible, by the Template Retransmit and the Template Expiry times (see Section 6.2).
データセットは、未知のセットIDと受信（[RFC5101]のセクション9を参照）は、対応するテンプレートの到着係属格納されてもよいです。何のテンプレートが利用可能になっていない場合は、私たちはイベントをログに記録し、対応するデータレコードを破棄し、SCTPとTCPのために、私たちは交通のセッションをリセットすることをお勧めしますお勧めします。収集プロセスをリセットする前にテンプレートを待機する時間は設定可能でなければなりません。私たちは、30分のデフォルトをお勧めします。トランスポートプロトコルとしてUDPを使用する場合、この遅延は、テンプレートの再送信とテンプレート有効期限時間（6.2節を参照）によって、可能な場合、結合されるべきであることに留意されたいです。
The arrival of a Set with a reserved Set ID should be logged, and the Collector must ignore the Set.
予約されたセットIDとセットの到着はログに記録されなければならない、とコレクターは設定を無視しなければなりません。
[IPFIX-ARCH] does not specify which entities are responsible for the encoding and decoding of Information Elements transferred via IPFIX. An IPFIX device can do the encoding either within the Metering Process or within the Exporting Process. The decoding of the Information Elements can be done by the Collecting Process or by the data processing application.
[IPFIX-ARCH]はIPFIXを介して転送される情報要素の符号化及び復号化のための原因であるエンティティを指定しません。 IPFIXデバイスは、計量プロセス内またはエクスポートプロセス内のいずれかの符号化を行うことができます。情報要素の復号化は、収集プロセスによって、またはデータ処理アプリケーションによって行うことができます。
If an IPFIX node simply relays IPFIX Records (like a proxy), then no decoding or encoding of Information Elements is needed. In this case, the Exporting Process may export unknown Information Elements, i.e., Information Elements with an unknown Information Element identifier.
IPFIXノードは単にIPFIXレコード（プロキシなど）を中継する場合には、情報要素のいかなる復号化または符号化が必要とされません。この場合、エクスポートプロセスは、未知の情報要素識別子と情報要素、すなわち、未知の情報要素をエクスポートすることができます。
IPFIX offers both Delta and Total counters (e.g., octetDeltaCount, octetTotalCount). If information about a Flow is only ever exported once, then it's not important whether Delta or Total counters are used. However, if further information about additional packets in a Flow is exported after the first export, then either:
IPFIXはデルタと合計カウンタ（例えば、octetDeltaCount、octetTotalCount）の両方を提供しています。フローに関する情報は今までに一度だけエクスポートされる場合、それはデルタまたはTotalカウンタが使用されているかどうかは重要ではありません。ただし、フロー内の追加のパケットについてのさらなる情報は最初のエクスポート後にエクスポートされている場合は、次のいずれか
o the metering system must reset its counters to zero after the first export and report the new counter values using Delta counters, or
計量システムは、最初のエクスポート後にゼロにそのカウンタをリセットし、デルタカウンタを使用して、新しいカウンタ値を報告しなければならない、O、または
o the metering system must carefully maintain its counters and report the running total using Total counters.
O計量システムは、慎重にそのカウンターを維持し、トータルカウンタを使用して、実行中の合計を報告しなければなりません。
At first, reporting the running total may seem to be the obvious choice. However, this requires that the system accurately maintains information about the Flow over a long time without any loss or error, because when reported to a Collecting Process, the previous total values will be replaced with the new information.
最初に、実行中の合計を報告することは当然の選択であるように見えることがあります。しかし、これは、収集プロセスに報告する際、以前の合計値は、新しい情報に置き換えられますので、システムが正確に、いかなる損失またはエラーなしで長い時間をかけてフローに関する情報を保持する必要があります。
Delta counters offer some advantages: information about Flows doesn't have to be permanently maintained, and any loss of information has only a small impact on the total stored at the Collecting Process. Finally, Deltas may be exported in fewer bytes than Total counters using the IPFIX "Reduced Size Encoding" scheme [RFC5101].
フローに関する情報を永続的に維持する必要はなく、情報の損失は、収集プロセスで保存され、合計でわずかな影響を与えている：デルタカウンタはいくつかの利点を提供します。最後に、デルタはIPFIX「縮小サイズのエンコーディング」方式[RFC5101]を用いて、全カウンタよりも少ないバイト数でエクスポートすることができます。
Note that Delta counters have an origin of zero and that a Collecting Process receiving Delta counters for a Flow that is new to the Collecting Process must assume the Deltas are from zero.
デルタカウンタがゼロの起源を持ち、収集プロセスに新しいものであるフローのデルタカウンタを受け収集プロセスを想定しなければならないことをデルタはゼロからのものであることに注意してください。
The IPFIX information model defines an Information Element for padding called paddingOctets [RFC5102]. It is of type octetArray, and the IPFIX protocol allows encoding it as a fixed-length array as well as a variable-length array.
IPFIX情報モデルは、パディングと呼ばpaddingOctets [RFC5102]のための情報要素を定義します。これはタイプoctetArrayのものであり、IPFIXプロトコルは、固定長の配列、ならびに可変長アレイとして符号化することができます。
The padding Information Element can be used to align Information Elements within Data Records, Records within Sets, and Sets within IPFIX Messages, as described below.
以下に説明するようにパディング情報要素は、セット内のレコード、データレコード内の情報要素を整列させるために使用され、IPFIXメッセージ内にセットすることができます。
The padding Information Element gives flexible means for aligning Information Elements within a Data Record. Aligning within a Data Record can be useful, because internal data structures can be easily converted into Flow Records at the Exporter and vice versa at the Collecting Process.
パディング情報要素は、データレコード内の情報要素を整列させるための柔軟な手段を提供します。内部データ構造を容易に収集プロセスで輸出及びその逆でフローレコードに変換することができるため、データレコード内の位置合わせは、有用であり得ます。
Alignment of Information Elements within a Data Record is achieved by inserting an instance of the paddingOctets Information Element with appropriate length before each unaligned Information Element. This insertion is explicitly specified within the Template Record or Options Template Record, respectively, that corresponds to the Data Record.
データレコード内の情報要素の位置合わせは、各アラインされていない情報要素の前に適切な長さでpaddingOctets情報要素のインスタンスを挿入することによって達成されます。この挿入は、明示的にデータレコードに対応し、それぞれ、テンプレートレコードまたはオプションテンプレートレコード内の指定されています。
4.4.2. Alignment of Information Element Specifiers within a Template Record
4.4.2. テンプレートレコード内の情報要素指定子のアライメント
There is no means for aligning Information Element specifiers within Template Records. However, there is limited need for such a method, as Information Element specifiers are always 32-bit aligned, and 32- bit alignment is generally sufficient.
テンプレートレコード内の情報要素の指定子を整列させるための方法はありません。情報要素指定子は常に32ビットに整列され、そして32ビットのアライメントは、一般的に十分であるようしかし、このような方法のための限定された必要性があります。
There is no means for aligning Template Records within a Set. However, there is limited need for such a method, as Information Element specifiers are always 32-bit aligned, and 32-bit alignment is generally sufficient.
セット内のテンプレートレコードを整列させるための方法はありません。情報要素指定子は常に32ビットに整列され、そして32ビットのアライメントは、一般的に十分であるようしかし、このような方法のための限定された必要性があります。
Data Records can be aligned within a Set by appending instances of the paddingOctets Information Element at the end of the Record. Since all Data Records within a Set have the same structure and size, aligning one Data Record implies aligning all the Data Records within a single Set.
データレコードは、レコードの終わりにpaddingOctets情報要素のインスタンスを追加することによって、セット内に整列させることができます。セット内のすべてのデータレコードが同じ構造と大きさを持っているので、合わせる1データレコードは、単一のセット内のすべてのデータレコードを揃える意味します。
If Records are already aligned within a Set by using paddingOctets Information Elements, then this alignment will already be achieved. But for aligning Sets within an IPFIX Message, padding Information Elements can be used at the end of the Set so that the subsequent Set starts at an aligned boundary. This padding mechanism is described in Section 3.3.1 of [RFC5101] and can be applied even if the Records within the Set are not aligned. However, it should be noted that this method is limited by the constraint that "the padding length MUST be shorter than any allowable Record in the Set", to prevent the padding from being misinterpreted as an additional Data Record.
レコードがすでにpaddingOctets情報要素を使用して設定内に整列されている場合は、このアライメントはすでに達成されます。その後の設定が整列境界で開始するようにしかし、IPFIXのメッセージ内のセットを揃えるために、パディング情報要素は、セットの最後に使用することができます。このパディングメカニズムは[RFC5101]のセクション3.3.1に記載されており、セット内のレコードが揃っていない場合であっても適用することができます。しかし、この方法は、追加のデータレコードと誤解されることから、パディングを防ぐために、「パディング長は、セット内の許容録音よりも短くしなければならない」という制約によって制限されることに留意すべきです。
IPFIX Messages contain the export time in the Message Header. In addition, there is a series of Information Elements defined to transfer time values. [RFC5102] defines four abstract data types to transfer time values in second, millisecond, microsecond, and nanosecond resolution.
IPFIXメッセージは、メッセージヘッダの輸出の時間を含んでいます。また、時間の値を転送するために定義された情報要素のシリーズがあります。 [RFC5102]は秒、ミリ秒、マイクロ秒、およびナノ秒の分解能で時間値を転送する4つの抽象データ型を定義します。
The accuracy and precision of these values depend on the accuracy and the precision of the Metering Process clock. The accuracy and precision of the Exporting Process clock, and the synchronization of the Metering Process and Exporting Process clocks, are also important when using the delta timestamp Information Elements. To ensure accuracy, the clocks should be synchronized to a UTC time source. Normally, it would be sufficient to derive the time from a remote time server using the Network Time Protocol (NTP) [RFC1305]. IPFIX Devices operating with time values of microsecond or nanosecond resolution need direct access to a time source, for example, to a GPS (Global Positioning System) unit.
これらの値の正確さと精度は、精度と計量プロセスクロックの精度に依存します。デルタタイムスタンプ情報要素を使用する場合の精度とエクスポートプロセスクロックの精度、および計量プロセスとエクスポートプロセスクロックの同期は、また重要です。精度を確保するために、クロックがUTC時刻ソースに同期する必要があります。通常は、ネットワークタイムプロトコル（NTP）[RFC1305]を使用してリモートタイムサーバから時間を導出するのに十分であろう。マイクロ秒またはナノ秒の分解能の時間値で動作IPFIXデバイスは、GPS（全地球測位システム）ユニットに、例えば時間ソースへの直接アクセスを必要とします。
The most important consideration in selecting timestamp Information Elements is to use a precision appropriate for the timestamps as generated from the Metering Process. Specifically, an IPFIX Device should not export timestamp Information Elements of higher precision than the timestamps used by the Metering Process (e.g., millisecond-precision Flows should not be exported with flowStartMicroseconds and flowEndMicroseconds).
タイムスタンプ情報要素を選択する際の最も重要な考慮事項は、計量プロセスから生成されるタイムスタンプのための精密な適切なを使用することです。具体的には、IPFIXデバイスは、（例えば、ミリ秒の精度のフローがflowStartMicrosecondsとflowEndMicrosecondsでエクスポートされるべきではない）計量プロセスによって使用されるタイムスタンプよりも高い精度のタイムスタンプ情報要素をエクスポートするべきではありません。
Section 5 of [RFC5101] defines a method for optimized export of time-related Information Elements based upon the Export Time field of the IPFIX Message Header. The architectural separation of the Metering Process and Exporting Process in [IPFIX-ARCH] raises some difficulties with this method, of which implementers should be aware.
[RFC5101]のセクション5はIPFIXメッセージヘッダーのエクスポートTimeフィールドに基づいて、時間に関連する情報要素の最適化された輸出のための方法を定義します。 [IPFIX-ARCH]の建築計量プロセスの分離およびエクスポートプロセスは、実装者が知っておくべきで、この方法でいくつかの問題を提起します。
Since the Metering Process has no information about the export time of the IPFIX Message (that is, when the message leaves the Exporting Process), it cannot properly use the delta time Information Elements; it must store absolute timestamps and transmit these to the Exporting Process. The Exporting Process must then convert these to delta timestamps once the export time is known. This increases the processing burden on the Exporting Process. Note also that the absolute timestamps require more storage than their delta timestamp counterparts. However, this method can result in reduced export bandwidth.
計量プロセスは、（そのメッセージがエクスポートプロセスを出るときに、）IPFIXメッセージのエクスポート時間に関する情報を有していないので、適切デルタ時間情報要素を使用することはできません。それは絶対的なタイムスタンプを保存し、エクスポートプロセスにこれらを送信しなければなりません。輸出時間がわかればエクスポートプロセスは、その後、デルタタイムスタンプにこれらを変換する必要があります。これは、エクスポートプロセスの処理負担を増大させます。絶対的なタイムスタンプがそのデルタタイムスタンプの対応よりも多くのストレージを必要とすることにも注意してください。しかし、この方法では減少し、輸出の帯域幅をもたらす可能性があります。
Alternatively, the Exporting Process may simply export absolute timestamp Information Elements. This simplifies the Exporting Process' job and reduces processing burden, but increases export bandwidth requirements.
また、エクスポートプロセスは、単純に絶対タイムスタンプ情報要素をエクスポートすることがあります。これは、エクスポートプロセスの仕事を簡素化し、処理負担を軽減しますが、輸出の帯域幅要件が増加します。
Exporting just relative times in a device without an absolute clock is often not sufficient. For instance, observed traffic could be retained in the device's cache for some time before being exported (e.g., if the Exporter runs once per minute), or stuck in an Inter Process Communication (IPC) queue, or stuck in the export stack, or delayed in the network between the Exporter and Collector.
絶対クロックなしで装置内に相対時間をエクスポートすると、多くの場合、十分ではありません。たとえば、トラフィックが（例えば、輸出業者は、1分に1回実行されている場合）、または、プロセス間通信（IPC）のキューに立ち往生、またはエクスポート・スタックで立ち往生またはエクスポートされる前に、いくつかの時間のために、デバイスのキャッシュに保持することができ観測輸出業者とコレクター間のネットワークが遅れます。
For these reasons, it can be difficult for the Collecting Process to convert the relative times exported using the flowStartSysUpTime and flowEndSysUpTime Information Elements to absolute times with any sort of accuracy without knowing the systemInitTimeMilliseconds. Therefore, the sending of the flowStartSysUpTime and flowEndSysUpTime Information Elements without also sending the systemInitTimeMilliseconds Information Element is not recommended.
収集プロセスはsystemInitTimeMillisecondsを知らなくても精度の何らかの絶対時間にflowStartSysUpTimeとflowEndSysUpTime情報要素を使用してエクスポートされた相対時間を変換するために、これらの理由のため、それは困難であることができます。したがって、またsystemInitTimeMilliseconds情報要素を送信することなくflowStartSysUpTimeとflowEndSysUpTime情報要素の送信はお勧めしません。
Section 9 of [RFC5101] specifies: "The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record". The Collecting Process may accept Templates with Information Elements of unknown types. In this case, the value received for these Information Elements should be decoded as an octet array.
[RFC5101]のセクション9を指定：「収集プロセスは、それが理解していないことをすべての情報要素の情報要素識別子を注意しなければならなくて、フローレコードからその情報要素を捨てるかもしれ」。収集プロセスは、不明な種類の情報要素を持つテンプレートを受け入れることができます。この場合には、これらの情報要素のために受信された値は、オクテット配列として復号化されるべきです。
Alternatively, the Collecting Process may ignore Templates and subsequent Data Sets that contain Information Elements of unknown types.
また、収集プロセスは、不明な種類の情報要素が含まれているテンプレートと、後続のデータセットを無視することができます。
It is recommended that Collecting Processes provide means to flexibly add types of new Information Elements to their knowledge base. An example is a configuration file that is read by the Collecting Process and that contains a list of Information Element identifiers and their corresponding types. Particularly for adding enterprise-specific Information Elements, such a feature can be very useful.
収集プロセスを柔軟知識ベースに新しい情報要素の種類を追加するための手段を提供することをお勧めします。例では、収集プロセスによって読み込まれる設定ファイルであり、それは情報要素識別子とそれに対応するタイプのリストが含まれています。特にエンタープライズ固有の情報要素を追加するため、このような特徴は、非常に便利です。
Since a Collector may receive data from the same device and Observation Domain in two Templates using different reduced-size encodings, it is recommended that the data be stored using full-size encoding, to ensure that the values can be stored or even aggregated together.
コレクタは異なる縮小エンコーディングを使用して2つのテンプレートで同じデバイスと観測ドメインからデータを受信することができるので、データの値が一緒に格納され、あるいは凝集させることができることを確実にするために、フルサイズのエンコーディングを使用して格納することが推奨されます。
Template IDs are generated dynamically by the Exporting Process. They are unique per Transport Session and Observation Domain.
テンプレートIDは、エクスポートプロセスによって動的に生成されます。彼らは、交通セッションと観測ドメインごとに一意です。
Therefore, for each Transport Session, the Collecting Process has to maintain a list of Observation Domains. For each Observation Domain, the Collecting Process has to maintain a list of current Template IDs in order to decode subsequent Data Records.
したがって、各トランスポートセッションのために、収集プロセスは、観測ドメインのリストを維持しなければなりません。各観測ドメインため、収集プロセスは、後続のデータレコードを復号化するために、現在のテンプレートIDのリストを維持しなければなりません。
Note that a restart of the Transport Session may lead to a Template ID renumbering.
交通セッションの再起動がテンプレートIDの再番号付けにつながる可能性があることに注意してください。
IPFIX can use SCTP, TCP, or UDP as a transport protocol. IPFIX implementations MUST support SCTP with partial reliability extensions (PR-SCTP), and MAY support TCP and/or UDP (see [RFC5101], Section 10.1). In the IPFIX documents, the terms SCTP and PR-SCTP are often used interchangeably to mean SCTP with partial reliability extensions.
IPFIXは、トランスポートプロトコルとしてSCTP、TCP、またはUDPを使用することができます。 IPFIX実装は（[RFC5101]、10.1節を参照してください）部分信頼の拡張（PR-SCTP）でSCTPをサポートしなければならないし、TCPおよび/またはUDPをサポートするかもしれません。 IPFIX文書では、用語のSCTPとPR-SCTPは、多くの場合、部分的に信頼性の拡張子を持つSCTPを意味するために互換的に使用されています。
PR-SCTP is the preferred transport protocol for IPFIX because it is congestion-aware, reducing total bandwidth usage in the case of congestion, but with a simpler state machine than TCP. This saves resources on lightweight probes and router line cards.
それは、輻輳の場合に、合計帯域幅使用量を減少させる、輻輳を認識しているが、TCPよりも単純な状態機械を用いているのでPR-SCTPは、IPFIXのための好ましいトランスポートプロトコルです。これは、軽量のプローブと、ルータのラインカード上のリソースを節約できます。
SCTP, as specified in [RFC4960] with the PR-SCTP extension defined in [RFC3758], provides several features not available in TCP or UDP. The two of these most universally applicable to IPFIX implementations, and which IPFIX implementers need to know about, are multiple streams and per-message partial reliability.
SCTPは、[RFC3758]で定義されたPR-SCTP拡張子を持つ[RFC4960]で指定されるように、TCPやUDPでは利用できないいくつかの機能を提供します。 IPFIX実装者が知っておく必要があるIPFIX実装への適用これらの最も普遍の2、とは、複数のストリームとメッセージごとの部分的な信頼性があります。
An SCTP association may contain multiple streams. Streams are useful for avoiding head-of-line blocking, thereby minimizing end-to-end delay from the Exporting Process to the Collecting Process. Example applications for this feature would be using one SCTP stream per Observation Domain, one stream per type of data (or Template ID), or one stream for Flow data and one for metadata.
SCTPアソシエーションは、複数のストリームを含むことができます。ストリームは、それによって収集プロセスにエクスポートプロセスからエンドツーエンド遅延を最小化する、ヘッドオブラインブロッキングを回避するために有用です。この機能の例のアプリケーションは、観測ドメインごとにSCTPストリーム、一つのデータの種類ごとに、ストリーム（またはテンプレートID）、またはフローデータ及びメタデータのための1つに対して1つのストリームを使用することになります。
An Exporting Process may request any number of streams, and may send IPFIX Messages containing any type of Set (Data Set, Template Set, etc.) on any stream. A Collecting Process MUST be able to process any Message received on any stream.
エクスポートプロセスは、ストリームの任意の数を求めることができる、任意のストリーム上の任意のセットの種類（データセット、テンプレートセット、等）を含むIPFIXメッセージを送信することができます。収集プロセスは、どのストリーム上で受信したメッセージを処理できなければなりません。
Stream negotiation is a feature of the SCTP protocol. Note, however, that the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about which streams are in use to the Collector. Therefore, stream configuration must be done out of band.
ストリーム交渉はSCTPプロトコルの機能です。 IPFIXプロトコルは、ストリームがコレクタに使用されているかについての任意の情報を伝えるために輸出するための任意のメカニズムを提供しないこと、しかし、注意してください。したがって、ストリーム構成は、帯域外で行う必要があります。
One extra advantage of the PR-SCTP association is its ability to send messages with different levels of reliability, selected according to the application. For example, billing or security applications might require reliable delivery of all their IPFIX Messages, while capacity planning applications might be more tolerant of message loss. SCTP allows IPFIX Messages for all these applications to be transported over the same association with the appropriate level of reliability.
PR-SCTPアソシエーションの1つの余分な利点は、用途に応じて選択、信頼性の異なるレベルでメッセージを送信する能力です。キャパシティプランニングのアプリケーションがメッセージの損失のより寛容であるかもしれない一方、例えば、課金やセキュリティのアプリケーションは、すべてのIPFIXメッセージの信頼性の高い配信が必要な場合があります。 SCTPは、信頼性の適切なレベルと同じアソシエーションを介して輸送されるすべてのこれらの用途にIPFIXメッセージを可能にします。
IPFIX Messages may be sent with full or partial reliability, on a per-message basis. Fully reliable delivery guarantees that the IPFIX Message will be received at the Collecting Process or that that SCTP association will be reset, as with TCP. Partially reliable delivery does not guarantee the receipt of the IPFIX Message at the Collecting Process. This feature may be used to allow Messages to be dropped during network congestion, i.e., while observing a Denial of Service attack.
IPFIXメッセージは、メッセージごとに、完全または部分的な信頼性で送信することができます。 IPFIXメッセージは、収集プロセスにおいて、またはそのSCTPアソシエーションはTCPと同様に、リセットされることを受信されることを完全に信頼できる配信を保証します。部分的に信頼性の高い配信は、収集プロセスでIPFIXメッセージの受信を保証するものではありません。サービス拒否攻撃を観察しながら、この機能は、すなわち、メッセージが、ネットワーク輻輳中にドロップすることを可能にするために使用されてもよいです。
[RFC3758] defines the concept of a Partial Reliability policy, which specifies the interface used to control partially reliable delivery. It also defines a single example Partial Reliability policy called "timed reliability", which uses a single parameter: lifetime. The lifetime is specified per message in milliseconds, and after it expires, no further attempt will be made to transmit the message. Longer lifetimes specify more retransmission attempts per message and therefore higher reliability; however, it should be noted that the absolute reliability provided by a given lifetime is highly dependent on network conditions, so an Exporting Process using the timed reliability service should provide a mechanism for configuring the lifetime of exported IPFIX Messages. Another possible Partial Reliability policy could be limited retransmission, which guarantees a specified number of retransmissions for each message. It is up to the implementer to decide which Partial Reliability policy is most appropriate for its application.
[RFC3758]は、部分的に信頼できる配信を制御するために使用されるインタフェースを指定部分信頼ポリシーの概念を定義します。寿命：それはまた、単一のパラメータを使用して「時限信頼性」と呼ばれる単一の例部分的な信頼ポリシーを定義します。寿命はミリ秒単位でメッセージごとに指定され、それが満了した後、それ以上の試みは、メッセージを送信するために行われません。長い寿命メッセージあたりの再送の試み、したがって、より高い信頼性を指定します。しかし、与えられた寿命によって提供される絶対的な信頼性は、ネットワーク条件に非常に依存することに留意すべきであるので、タイミング信頼性のサービスを使用してエクスポートプロセスは、エクスポートされたIPFIXメッセージの寿命を設定するためのメカニズムを提供しなければなりません。別の可能な部分的な信頼ポリシーは各メッセージの再送信の指定された数を保証有限再送信、可能性があります。これは、部分的な信頼性ポリシーがその用途のために最も適切であるかを決定するために実装次第です。
There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered to the receiver as soon as it is queued rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender, even messages sent partially reliably will still be delivered in order. Unordered delivery should not be used when the order of IPFIX Messages may matter: e.g., a Template or Options Template. Unordered delivery should not be used when Total counters are used, as reordering could result in the counter value decreasing at the Collecting Process and even being left with a stale value if the last message processed is stale.
順不同配信：PR-SCTPと一緒にSCTPと便利によって提供される付加サービスがあります。これはまた、指定されたメッセージは、すぐにそれを順にキューイングなく維持されるように受信機に配信されるべきであることを宣言することで、メッセージごとのベースで動作します。しかし、明示的に送信者から要求されない限り、部分的に確実に送信してもメッセージはまだ順番に配信されることに注意すべきです。例えば、テンプレートまたはオプションテンプレート：順不同の送達はIPFIXメッセージの順序は重要でよいときに使用すべきではありません。順不同の送達は、合計カウンタが使用される場合、並べ替えは、収集プロセスで減少カウンタの値をもたらし得るように、使用すべきではないと処理された最後のメッセージが古い場合でも、失効値が残されています。
By convention, when the IPFIX documents state a requirement for reliable delivery (as, for example, the IPFIX protocol document does for Template Sets, Options Template Sets, and Template Withdrawal Messages), an IPFIX Exporting Process must not use partially reliable delivery for those Messages. By default, and explicitly if the IPFIX documents call for "partially reliable" or "unreliable" delivery, an IPFIX Exporting Process may use partially reliable delivery if the other requirements of the application allow.
IPFIX文書が信頼できる配信の要件を述べるときに（例えば、IPFIXプロトコルドキュメントは、テンプレートセット、オプションテンプレートセット、およびテンプレート離脱メッセージの場合と同様に）慣例により、IPFIXエクスポートプロセスは、それらのために、部分的に信頼性の高い配信を使用してはなりませんメッセージ。 IPFIX文書は「部分的に信頼できる」または「信頼できない」の配信を要求した場合、アプリケーションの他の要件が許す場合、デフォルトでは、明示的、IPFIXエクスポートプロセスは、部分的に信頼性の高い配信を使用することができます。
The Collecting Process may check whether IPFIX Messages are lost by checking the Sequence Number in the IPFIX header. The Collecting Process should use the Sequence Number in the IPFIX Message Header to determine whether any messages are lost when sent with partial reliability. Sequence Numbers should be tracked independently for each stream.
収集プロセスはIPFIXメッセージがIPFIXヘッダ内のシーケンス番号をチェックすることによって失われているかどうかをチェックすることができます。収集プロセスは、部分的な信頼性を備えて送信時にすべてのメッセージが失われているかどうかを判断するためにIPFIXメッセージヘッダ内のシーケンス番号を使用する必要があります。シーケンス番号は、各ストリームに対して独立に追跡されなければなりません。
The following may be done to mitigate message loss:
以下はメッセージの損失を軽減するために行うことができます。
o Increase the SCTP buffer size on the Exporter.
OエクスポーターのSCTPバッファサイズを増やします。
o Increase the bandwidth available for communicating the exported Data Records.
Oエクスポートされたデータレコードを通信するための利用可能な帯域幅を増やします。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data (see [RFC5101], Section 10.4.2.3).
Oエクスポートされたデータの量を減少させるために計量プロセスにサンプリング、フィルタリング、または集合を使用する（[RFC5101]セクション10.4.2.3を参照）。
o If partial reliability is used, switch to fully reliable delivery on the Exporting Process or increase the level of partial reliability (e.g., when using timed reliability, by specifying a longer lifetime for exported IPFIX Messages).
部分的な信頼性が使用される場合、O、エクスポートプロセスで完全に信頼できる配信するためのスイッチまたは部分信頼のレベルを増加させる（例えば、エクスポートされたIPFIXメッセージの長寿命を指定することにより、タイミング信頼性を使用する場合）。
If the SCTP association is brought down because the IFPIX Messages can't be exported reliably, the options are:
IFPIXメッセージが確実にエクスポートすることができないので、SCTPアソシエーションがダウンしている場合は、オプションは次のとおりです。
o Increase the SCTP buffer size on the Exporter.
OエクスポーターのSCTPバッファサイズを増やします。
o Increase the bandwidth available for communicating the exported Data Records.
Oエクスポートされたデータレコードを通信するための利用可能な帯域幅を増やします。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data.
Oエクスポートされたデータの量を減少させるために計量プロセスにサンプリング、フィルタリング、または凝集を使用。
Note that Templates must not be resent when using SCTP, without an intervening Template Withdrawal or SCTP association reset. Note also that since Template Sets and Template Withdrawal Messages may be sent on any SCTP stream, a Template Withdrawal Message may withdraw a Template sent on a different stream, and a Template Set may reuse a Template ID withdrawn by a Template Withdrawal Message sent on a different stream. Therefore, an Exporting Process sending Template Withdrawal Messages should ensure to the extent possible that the Template Withdrawal Messages and subsequent Template Sets reusing the withdrawn Template IDs are received and processed at the Collecting Process in proper order. The Exporting Process can achieve this by one of two possible methods: 1. by sending a Template Withdrawal Message reliably, in order, and on the same stream as the subsequent Template Set reusing its ID; or 2. by waiting an appropriate amount of time (on the scale of one minute) after sending a Template Withdrawal Message before attempting to reuse the withdrawn Template ID.
介在テンプレート撤退またはSCTP協会リセットせずに、SCTPを使用した場合、テンプレートを再送してはならないことに注意してください。注意また、そのテンプレートセットとテンプレート離脱メッセージは、任意のSCTPストリームで送信されてもよいので、テンプレート離脱メッセージは、異なるストリーム上で送信されたテンプレートを撤回することができ、テンプレートセット上で送信されたテンプレート離脱メッセージによって引き出さテンプレートIDを再利用することができます別のストリーム。したがって、テンプレート離脱メッセージを送信するエクスポートプロセスは、テンプレート離脱メッセージと引き抜かテンプレートIDを再利用し、その後のテンプレートセットが受信され、適切な順序で収集プロセスで処理されることが可能な範囲で確保すべきです。エクスポートプロセスは、2つの可能な方法のいずれかによって、これを達成することができます。ためには、そのIDを再利用し、その後のテンプレートセットと同じストリームに、確実テンプレート離脱メッセージを送信することにより、1。又は取り下げテンプレートIDを再利用しようとする前に、テンプレート無効化メッセージを送信した後（1分の規模の）適切な時間を待つこと2。
UDP is useful in simple systems where an SCTP stack is not available, and where there is insufficient memory for TCP buffering.
UDPは、SCTPスタックが利用できず、TCPバッファリングのためのメモリが不足している単純なシステムで有用です。
However, UDP is not a reliable transport protocol, and IPFIX Messages sent over UDP might be lost as with partially reliable SCTP streams. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties:
しかし、UDPは信頼性の高いトランスポートプロトコルではなく、UDPを介して送信されるIPFIXメッセージは、部分的に信頼性のSCTPストリームのように失われる可能性があります。 UDPは、IPFIXのために推奨されるプロトコルではなく、IPFIXは、次のプロパティで、既存のNetFlowインフラを交換している場合に使用するためのものです：
o A dedicated network,
O専用ネットワーク、
o within a single administrative domain,
単一の管理ドメイン内のO、
o where SCTP is not available due to implementation constraints, and
O SCTPは、実装上の制約のために利用できない、どこ
o the Collector is as topologically close as possible to the Exporter.
Oコレクターは、輸出業者にできるだけ位相幾何学的に近接しています。
Note that because UDP itself provides no congestion control mechanisms, it is recommended that UDP transport be used only on managed networks, where the network path has been explicitly provisioned for IPFIX traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations.
UDP自体は輻輳制御メカニズムを提供しないので、UDPトランスポートはネットワークパスが明示的なレート制限や容量の予約などのトラフィックエンジニアリングメカニズムを介して、IPFIXトラフィック用にプロビジョニングされた管理ネットワーク上でのみ使用することを推奨していることに注意してください。
An important example of an explicitly provisioned, managed network for IPFIX is the use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that Flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth.
IPFIXのために明示的にプロビジョニング、管理対象のネットワークの重要な例は、専用のネットワーク上で機能してNetFlowの実装を置き換えるために、IPFIXの使用です。このような状況では、専用のネットワークインターフェイスを監視することにより、生成されたフローのエクスポートトラフィックを監視インターフェイスの帯域幅の2から5パーセントに達するだろうというのNetFlowの展開の経験に基づいてプロビジョニングする必要があります。
As recommended in [TSVWG-UDP], an application should not send UDP messages that result in IP packets that exceed the MTU of the path to the destination and should enable UDP checksums (see Sections 3.2 and 3.4 of [TSVWG-UDP], respectively).
[TSVWG-UDP]で推奨されているように、アプリケーションは、目的地までの経路のMTUを超えたIPパケットを生じるUDPメッセージを送信してはならず、UDPチェックサムを有効にする必要があり（それぞれ、セクション3.2および[TSVWG-UDP]の3.4参照）。
Since IPFIX assumes reliable transport of Templates over SCTP, this necessitates some changes for IPFIX Template management over UDP. Templates sent from the Exporting Process to the Collecting Process over UDP MUST be resent at regular time intervals; these intervals MUST be configurable (see Section 10.3 of [RFC5101]).
IPFIXは、SCTPを超えるテンプレートの確実な輸送を想定しているので、これはUDP上IPFIXテンプレート管理のためのいくつかの変更が必要となります。 UDP上に収集プロセスにエクスポートプロセスから送信されたテンプレートは、規則的な時間間隔で再送信されなければなりません。これらの間隔は、（[RFC5101]のセクション10.3を参照）を構成可能でなければなりません。
We recommend a default Template-resend time of 10 minutes, configurable between 1 minute and 1 day.
私たちは、1分〜1日の間で設定可能な10分のデフォルトのテンプレート・再送時間を、お勧めします。
Note that this could become an interoperability problem; e.g., if an Exporter resends Templates once per day, while a Collector expires Templates hourly, then they may both be IPFIX-compatible, but not be interoperable.
これは、相互運用性の問題になる可能性があることに注意してください。コレクタは毎時テンプレートを期限切れにしながら、輸出は、1日に1回テンプレートを再送信する場合、例えば、それらは両方IPFIX互換であるが、相互運用可能ではないかもしれません。
Retransmission time intervals that are too short waste bandwidth on unnecessary Template retransmissions. On the other hand, time intervals that are too long introduce additional costs or risk of data loss by potentially requiring the Collector to cache more data without having the Templates available to decode it.
不要なテンプレートの再送信に短すぎる廃棄物の帯域幅のある再送信時間間隔。一方、長すぎる時間間隔は、潜在的にそれをデコードするために利用可能なテンプレートを持つことなく、より多くのデータをキャッシュするためにコレクタを必要とすることによって、追加のコストやデータ損失のリスクを紹介します。
To increase reliability and limit the amount of potentially lost data, the Exporting Process may resend additional Templates using a packet-based schedule. In this case, Templates are resent depending on the number of data packets sent. Similarly to the time interval, resending a Template every few packets introduces additional overhead, while resending after a large amount of packets have already been sent means high costs due to the data caching and potential data loss.
信頼性を高め、潜在的に失われたデータの量を制限するために、エクスポートプロセスは、パケットベースのスケジュールを使用して追加のテンプレートを再送信することができます。この場合、テンプレートは、送信されるデータパケットの数に応じて再送されます。大量のパケットが既に送信された後に再送信すると、データ・キャッシングおよび潜在的なデータ損失によるコスト高を意味している。同様に、時間間隔に、テンプレートごとにいくつかのパケットを再送することは、追加のオーバーヘッドを導入します。
We recommend a default Template-resend interval of 20 packets, configurable between 1 and 1000 data packets.
私たちは、1〜1000のデータパケットの間に設定可能な20個のパケットのデフォルトのテンプレート・再送間隔を、お勧めします。
Note that a sufficiently small resend time or packet interval may cause a system to become stuck, continually resending Templates or Options Data. For example, if the resend packet interval is 2 (i.e., Templates or Options Data are to be sent in every other packet) but more than two packets are required to send all the information, then the resend interval will have expired by the time the information has been sent, and Templates or Options Data will be sent continuously -- possibly preventing any data from being sent at all. Therefore, the resend intervals should be considered from the last data packet, and should not be tied to specific Sequence Numbers.
十分に小さい再送時間やパケット間隔は、システムが継続的にテンプレートやオプションデータを再送する、立ち往生になることを引き起こすかもしれないことに注意してください。再送パケット間隔が2（すなわち、テンプレートやオプションデータが他のすべてのパケットで送信される）されているが、二つ以上のパケットがすべての情報を送信するために必要とされる場合たとえば、その後、再送間隔が時間によって期限が切れています情報が送信されてきた、とテンプレートまたはオプションのデータが連続して送信されます - おそらく全く送信されてから任意のデータを防止することができます。そのため、再送間隔は、最後のデータパケットから考慮されなければならない、と特定のシーケンス番号に接続するべきではありません。
The Collecting Process should use the Sequence Number in the IPFIX Message Header to determine whether any messages are lost.
収集プロセスは、すべてのメッセージが失われているかどうかを判断するためにIPFIXメッセージヘッダ内のシーケンス番号を使用する必要があります。
The following may be done to mitigate message loss:
以下はメッセージの損失を軽減するために行うことができます。
o Move the Collector topologically closer to the Exporter.
O輸出業者への位相幾何学的に近いコレクターを移動します。
o Increase the bandwidth of the links through which the Data Records are exported.
Oデータレコードがエクスポートに使用するリンクの帯域幅を増やします。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data.
Oエクスポートされたデータの量を減少させるために計量プロセスにサンプリング、フィルタリング、または凝集を使用。
o Increase the buffer size at the Collector and/or the Exporter.
Oコレクタ及び/又は輸出におけるバッファサイズを大きくしてください。
Before using a Template for the first time, the Exporter may send it in several different IPFIX Messages spaced out over a period of packets in order to increase the likelihood that the Collector has received the Template.
最初にテンプレートを使用する前に、輸出業者は、コレクタテンプレートを受信した可能性を高めるために、パケットの期間にわたって間隔をあけ、いくつかの異なるIPFIXメッセージでそれを送信することができます。
Template Withdrawal Messages MUST NOT be sent over UDP (per Section 10.3.6 of [RFC5101]). The Exporter must rely on expiration at the Collector to expire old Templates or to reuse Template IDs.
テンプレート脱退メッセージ（[RFC5101]のセクション10.3.6あたり）UDP上で送ってはいけません。輸出業者は、古いテンプレートを期限切れにするか、テンプレートIDを再利用するコレクターで期限切れに依存しなければなりません。
We recommend that the Collector implements a Template Expiry of three times the Exporter refresh rate.
私たちは、コレクタが3倍、輸出のリフレッシュレートのテンプレート有効期限を実装することをお勧めします。
However, since the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about the Template Expiry time to the Collector, configuration must be done out of band.
IPFIXプロトコルはCollectorにテンプレート有効期限の時間に関する情報を伝えるために輸出業者のための任意のメカニズムを提供していないので、構成が帯域外で行う必要があります。
If no out-of-band configuration is made, we recommend to initially set a Template Expiry time at the Collector of 60 minutes. The Collecting Process may estimate each Exporting Process's resend time and adapt the Expiry time for the corresponding Templates accordingly.
何のアウトオブバンド設定がなされていない場合、我々は最初の60分のコレクターで、テンプレートの有効期限を設定することをお勧めします。収集プロセスは、各エクスポートプロセスの再送時間を推定し、それに応じて対応するテンプレートの有効期限を適応させることができます。
TCP can be used as a transport protocol for IPFIX if one of the endpoints has no support for SCTP, but a reliable transport is needed and/or the network between the Exporter and the Collector has not explicitly been provisioned for the IPFIX traffic. TCP is one of the core protocols of the Internet and is widely supported.
エンドポイントの1つは、SCTPをサポートしていませんが、信頼性の高い輸送が必要とされ、および/または輸出とコレクタ間のネットワークは、明示的にIPFIXトラフィック用にプロビジョニングされていない場合、TCPは、IPFIXのためのトランスポートプロトコルとして使用することができます。 TCPは、インターネットのコアプロトコルの一つであり、広くサポートされています。
The Exporting Process may resend Templates (per UDP, above), but it's not required to do so, per Section 10.4.2.2 of [RFC5101]:
エクスポートプロセスは、（上記のUDP、あたり）テンプレートを再送信することができるが、[RFC5101]のセクション10.4.2.2につき、そうする必要はないです。
"A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records."
「エクスポートプロセスが再輸出するテンプレートレコードを必要とされていないとして収集プロセスは、接続の期間中、すべてのテンプレートとオプションテンプレートレコードを記録しなければなりません。」
If the available bandwidth between Exporter and Collector is not sufficient or the Metering Process generates more Data Records than the Collector is capable of processing, then TCP congestion control may cause the Exporter to block. Options in this case are:
エクスポータとコレクタとの間に利用可能な帯域幅が十分でないか、計量プロセスは、コレクタが処理することが可能であるよりも多くのデータレコードを生成する場合、TCP輻輳制御は、輸出はブロックさせてもよいです。この場合のオプションは次のとおりです。
o Increase the TCP buffer size on the Exporter.
OエクスポーターのTCPバッファサイズを増やします。
o Increase the bandwidth of the links through which the Data Records are exported.
Oデータレコードがエクスポートに使用するリンクの帯域幅を増やします。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data.
Oエクスポートされたデータの量を減少させるために計量プロセスにサンプリング、フィルタリング、または凝集を使用。
The term middlebox is defined in [RFC3234] as:
用語ミドルボックスは、次のように[RFC3234]で定義されています。
"any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host."
「送信元ホストと宛先ホスト間のデータグラムの経路上のIPルータの通常の、標準的な機能以外の機能を実行する任意の中間デバイス。」
The list of middleboxes discussed in [RFC3234] contains:
[RFC3234]で議論ミドルボックスのリストが含まれています。
It is likely that since the publication of RFC 3234 new kinds of middleboxes have been added.
ミドルボックスのRFCの公表以来、3234の新しい種類が追加されている可能性があります。
While the IPFIX specifications [RFC5101] based the requirements on the export protocol only (as the IPFIX name implies), these sections cover the guidelines for the implementation of the Metering Process by recommending which Information Elements to export for the different middlebox considerations.
IPFIX仕様[RFC5101]は（IPFIX名が示すように）のみエクスポートプロトコルに要求をベースとしつつ、これらのセクションは、情報要素が異なるミドルボックスを考慮してエクスポートする推薦によって計量プロセスの実施のためのガイドラインを覆います。
Middleboxes may delay, reorder, drop, or multiply packets; they may change packet header fields and change the payload. All these actions have an impact on traffic Flow properties. In general, a middlebox transforms a unidirectional original traffic Flow T that arrives at the middlebox into a transformed traffic Flow T' that leaves the middlebox.
中間装置は、並べ替えドロップ、またはパケットを乗算し、遅延させることができます。彼らは、パケットヘッダフィールドを変更してペイロードを変更することができます。すべてのこれらのアクションは、トラフィックフローの特性に影響を与えます。一般的には、ミドルはミドルを残し変換トラフィックフローT」にミドルに到着する一方向の元トラフィックフローTを変換します。
+-----------+
T ---->| middlebox |----> T'
+-----------+
Figure 1: Unidirectional traffic Flow traversing a middlebox
図1：単方向トラフィックフローがミドルを横断
Note that in an extreme case, T' may be an empty traffic Flow (a Flow with no packets), for example, if the middlebox is a firewall and blocks the Flow.
ミドルボックスは、ファイアウォールとブロックフローである場合、極端な場合には、T」は、例えば、空のトラフィックフロー（NOパケットでフロー）であってもよいことに留意されたいです。
In case of a middlebox performing a multicast function, a single original traffic Flow may be transformed into more than one transformed traffic Flow.
マルチキャスト機能を実行するミドルの場合には、単一の元のトラフィックフローは、複数の形質転換されたトラフィックフローに変換することができます。
+------> T'
|
+---------+-+
T ---->| middlebox |----> T''
+---------+-+
|
+------> T'''
Figure 2: Unidirectional traffic Flow traversing a middlebox with multicast function
図2：単方向トラフィックフローがマルチキャスト機能とミドルを横断
For bidirectional traffic Flows, we identify Flows on different sides of the middlebox; say, T_l on the left side and T_r on the right side.
双方向のトラフィック・フローについては、我々はミドルの異なる側にフローを識別。右側、左側とT_Rに、T_Lを言います。
+-----------+
T_l <--->| middlebox |<---> T_r
+-----------+
Figure 3: Bidirectional unicast traffic Flow traversing a middlebox
図3：双方向ユニキャストトラフィックフローミドルを横断
In case of a NAT, T_l might be a traffic Flow in a private address realm and T_r the translated traffic Flow in the public address realm. If the middlebox is a NAT-PT, then T_l may be an IPv4 traffic Flow and T_r the translated IPv6 traffic Flow.
NATの場合は、T_Lは、パブリックアドレスレルムに翻訳されたトラフィックフロートラフィックのプライベートアドレスレルムの流れとT_Rかもしれません。ミドルは、NAT-PTの場合、T_Lは、IPv4トラフィックフローとT_R翻訳IPv6トラフィックフローかもしれません。
At tunnel endpoints, Flows are multiplexed or demultiplexed. In general, tunnel endpoints can deal with bidirectional traffic Flows.
トンネルエンドポイントで、フローは、多重化または逆多重化されます。一般的には、トンネルエンドポイントは、双方向のトラフィックフローを扱うことができます。
+------> T_r1
v
+---------+-+
T_l <--->| middlebox |<---> T_r2
+---------+-+
^
+------> T_r3
Figure 4: Multiple data reduction
図4：複数のデータリダクション
An example is a traffic Flow T_l of a tunnel and Flows T_rx that are multiplexed into or demultiplexed out of a tunnel. According to the IPFIX definition of traffic Flows in [RFC5101], T and T' or T_l and T_rx, respectively, are different Flows in general.
例では、トンネルのトラフィックフローT_Lとに多重化又はトンネルから逆多重化されるT_rx流れます。トラフィックのIPFIX定義によれば、[RFC5101]に流れ、T及びT」またはT_LとT_rxは、それぞれ、一般的に異なるフローです。
However, from an application point of view, they might be considered as closely related or even as the same Flow, for example, if the payloads they carry are identical.
彼らが運ぶペイロードが同一である場合は、アプリケーションの観点から、それらは、例えば、関連するまたは同じフロー限り密接に考えられるかもしれません。
Middleboxes might be integrated with other devices. An example is a router with a NAT or a firewall at a line card. If an IPFIX Observation Point is located at the line card, then the properties of measured traffic Flows may depend on the side of the integrated middlebox at which packets were captured for traffic Flow measurement.
Middleboxesは、他のデバイスと統合される可能性があります。例では、ラインカードでのNATやファイアウォールとルータです。 IPFIX観測点がライン・カードに配置されている場合には、測定されたトラフィックフローの特性は、パケットがトラフィック流量測定のために捕捉された時、統合ミドルボックスの側面に依存してもよいです。
Consequently, an Exporting Process reporting traffic Flows measured at a device that hosts one or more middleboxes should clearly indicate to Collecting Processes the location of the used Observation Point(s) with respect to the middlebox(es). This can be done by using Options with Observation Point as scope and elements like, for instance, lineCardID or samplerID. Otherwise, processing the measured Flow data could lead to wrong results.
したがって、エクスポートプロセス報告トラフィックは明らかミドル（ES）に関してプロセスを使用観測ポイント（複数可）の位置の収集に示すべき一つ以上の中間装置をホスト装置で測定流れます。これは、例えば、lineCardID又はsamplerIDため、範囲等要素として観測点にオプションを使用して行うことができます。それ以外の場合は、測定された流量データを処理することは、間違った結果につながる可能性があります。
At first glance, choosing an Observation Point that covers the entire middlebox looks like an attractive choice. But this leads to ambiguities for all kinds of middleboxes. Within the middlebox, properties of packets are modified, and it should be clear at a Collecting Process whether packets were observed and metered before or after modification. For example, it must be clear whether a reported source IP address was observed before or after a NAT changed it or whether a reported packet count was measured before or after a firewall dropped packets. For this reason, [RFC5102] provides Information Elements with prefix "post" for Flow properties that are changed within a middlebox.
一見すると、全体のミドルをカバー観測点を選択すると、魅力的な選択肢のように見えます。しかし、これはミドルボックスのすべての種類のあいまいさにつながります。ミドルボックス内で、パケットの特性が変更され、それはパケットが変更前又は後に観察され、計量されたかどうかを収集プロセスには明らかであろう。例えば、報告された送信元IPアドレスが前またはNATがそれを変更したり、ファイアウォールがパケットをドロップする前または後に報告されたパケット数を測定したかどうかを後に観察されたかどうかは明確でなければなりません。このため、[RFC5102]はミドル内で変更された流動性の接頭辞「ポスト」との情報要素を提供します。
If an Observation Point is located inside a middlebox, the middlebox must have well-defined and well-separated internal functions, for example, a combined NAT and firewall, and the Observation Point should be located on a boundary between middlebox functions rather than within one of the functions.
観測点がミドルボックスの内側に位置する場合、ミドルボックスは、明確に定義されている必要があり、十分に分離された内部機能は、例えば、合成NATやファイアウォール、および観測点は、ミドルボックス機能との間の境界上ではなく、一つの中に配置されなければなりません機能の。
While this document recommends IPFIX implementations using Observation Points outside of middlebox functions, there are a few special cases where reporting Flow-related internals of a middlebox is of interest.
この文書はミドル関数の外で観測ポイントを使用してIPFIX実装を推奨していますが、ミドルのフローに関連した内部を報告することは重要であるいくつかの特別な場合があります。
For many applications that use traffic measurement results, it is desirable to get more information than can be derived from just observing packets on one side of a middlebox. If, for example, packets are dropped by the middlebox acting as a firewall, NAT, or traffic shaper, then information about how many observed packets are dropped may be of high interest.
トラフィック測定結果を使用する多くのアプリケーションでは、それだけで、ミドルの片側上のパケットを観測から導出することができるよりも多くの情報を得ることが望ましいです。例えば、パケットがファイアウォール、NAT、またはトラフィックシェーパーとして動作するミドルによって破棄され、場合、そのパケットは廃棄されますどのように多くの観測についての情報は、高い関心であってもよいです。
This section gives recommendations on middlebox internal information that may be reported if the IPFIX Observation Point is co-located with one or more middleboxes. Since the internal information to be reported depends on the kind of middlebox, it is discussed per kind.
このセクションでは、IPFIXの観測ポイントは、1つのまたは複数のミドルボックスと同じ場所に配置された場合に報告することができるミドル内部情報に関する推奨事項を提供します。報告される内部情報は、ミドルボックスの種類に依存するので、種類ごとに説明されています。
The recommendations cover middleboxes that act per packet and that do not modify the application-level payload of the packet (except by dropping the entire packet) and that do not insert additional packets into an application-level or transport-level traffic stream.
推奨事項は、パケットごとに作用し、それが（全体のパケットをドロップすることによって除く）パケットのアプリケーションレベルのペイロードを変更しないと、それは、アプリケーションレベルまたはトランスポートレベルのトラフィックストリームに追加パケットを挿入していない中間装置を覆います。
Covered are the packet-level middleboxes of kinds 1, 2, 3, 5, 9, 10, 21, and 22 (according to the enumeration given at the beginning of Section 7 of this document). Not covered are 4, 6-8 and 11-20. TCP performance-enhancing proxies (7) are not covered because they may add ACK packets to a TCP connection.
被覆（このドキュメントのセクション7の初めに与えられた列挙に従って）種類1、2、3、5、9、10、21、及び22のパケットレベルの中間装置です。カバーされていない4、6-8と11-20です。彼らはTCP接続にACKパケットを追加する可能性があるため、（7）TCP性能増強プロキシがカバーされていません。
Still, if possible, IPFIX implementations co-located with uncovered middleboxes (i.e., of type 7 or 11-20) should follow the recommendations given in this section if they can be applied in a way that reflects the intention of these recommendations.
依然として、可能な場合、IPFIX実装の覆われていない中間装置と同じ場所に配置（すなわち、タイプ7または11-20の）は、これらの勧告の意図を反映するように適用することができる場合は、このセクションに記載された推奨事項に従うべきです。
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially drop packets, then the corresponding IPFIX Exporting Process should be able to report the number of packets that were dropped per reported Flow.
IPFIX観測点は、潜在的にパケットをドロップ一つ以上の中間装置と同じ場所に配置されている場合、対応するIPFIXエクスポートプロセスは、報告されたフローごとに廃棄されたパケットの数を報告することができなければなりません。
Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway (3), packet schedulers (5), IP firewalls (9) and application-level firewalls (10).
中間装置の当該種類のNAT（1）、NAT-PT（2）、SOCKSゲートウェイ（3）、パケットスケジューラ（5）、IPファイアウォール（9）とアプリケーションレベルのファイアウォール（10）です。
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially modify the Diffserv Code Point (DSCP, see [RFC2474]) in the IP header, then the corresponding IPFIX Exporting Process should be able to report both the observed incoming DSCP value and also the DSCP value on the 'other' side of the middlebox (if this is a constant value for the particular traffic flow). The related Information Elements specified in [RFC5102] are: IpClassOfService and postIpClassOfService.
IPFIX観測点は、潜在的にDiffservのコードポイント変更一つ以上の中間装置と同じ場所に配置されている場合（DSCPを、[RFC2474]参照）IPヘッダに、対応するIPFIXエクスポートプロセスが観察着信DSCPの両方を報告することができなければなりません値またミドルボックスの「その他」側のDSCP値（これは、特定のトラフィックフローのために一定の値である場合）。 [RFC5102]で指定された関連情報要素は以下のとおりです。IpClassOfServiceとpostIpClassOfService。
Note that the current IPFIX information model only contains Information Elements supporting packets observed before the DSCP change, i.e. ipClassOfService and postIpClassOfService, where the latter reports the value of the IP TOS field after the DSCP change. We recommend, whenever possible, to move the Observation Point to the point before the DSCP change and report the Observed and post-values. If reporting the value of the IP TOS field before DSCP change is required, "pre" values can be exported using enterprise-specific Information Elements.
現在IPFIX情報モデルは後者のみがDSCP変更後のIP TOSフィールドの値を報告DSCP変更前に観察パケット、すなわちipClassOfServiceとpostIpClassOfServiceを支持する情報要素を含むことに留意されたいです。私たちは、DSCPの変更前のポイントへの観測ポイントを移動して観察し、後の値を報告するために、可能な限り、お勧めします。 DSCPの変更前のIP TOSフィールドの値を報告必要な場合は、「前」の値は、企業固有の情報要素を使用してエクスポートすることができます。
Note also that a classifier may change the same DSCP value of packets from the same Flow to different values depending on the packet or other conditions. Also, it is possible that packets of a single unidirectional arriving Flow contain packets with different DSCP values that are all set to the same value by the middlebox. In both cases, there is a constant value for the DSCP field in the IP packet header to be observed on one side of the middlebox, but on the other side the value may vary. In such a case, reliable reporting of the DSCP value on the 'other' side of the middlebox is not possible by just reporting a single value. According to the IPFIX information model [RFC5102], the first value observed for the DSCP is reported by the IPFIX protocol in that case.
分類器は、パケットまたは他の条件に応じて異なる値に同じフローからのパケットの同じDSCP値を変更してもよいことにも留意されたいです。また、単一の一方向の到着フローのパケットはすべてミドルによって同じ値に設定されている別のDSCP値を持つパケットが含まれている可能性があります。両方の場合において、ミドルボックスの一方の側に観察されるIPパケットのヘッダ内のDSCPフィールドの定数値であるが、他の側で値が変化してもよいです。そのような場合には、ミドルの「その他」側のDSCP値の信頼性の報告は、単一の値のみを報告することによって可能ではありません。 IPFIX情報モデル[RFC5102]によれば、DSCPについて観察された最初の値は、その場合のIPFIXプロトコルによって報告されています。
This recommendation applies to packet markers (5).
この勧告は、パケットマーカー（5）に適用されます。
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially modify the:
：IPFIXの観測ポイントは、潜在的に修正する1つの以上のミドルボックスと同じ場所に配置されている場合
o IP version field,
O IPバージョンフィールド、
o IP source address header field,
O IPソースアドレスヘッダフィールド、
o IP destination address header field,
O IP宛先アドレスヘッダフィールド、
o Source transport port number, or
Oソーストランスポートのポート番号、または
o Destination transport port number
O送信先トランスポートポート番号
in one of the headers, then the corresponding IPFIX Exporting Process should be able to report the 'translated' value of these fields, as far as they have constant values for the particular traffic Flow, in addition to the observed values of these fields.
ヘッダーの1つに、対応するIPFIXエクスポートプロセスは、これらのフィールドの観測値に加えて、限り、彼らは、特定のトラフィックフローの一定の値を持っているように、これらのフィールドの「翻訳」の値を報告することができるはずです。
If the changed values are not constant for the particular traffic Flow but still reporting is desired, then it is recommended that the general rule from [RFC5102] for Information Elements with changing values is applied: the reported value is the one that applies to the first packet observed for the reported Flow.
変更された値は、特定のトラフィックフローの一定ではないが、まだ報告を希望する場合は、それを変更する値を持つ情報要素のための[RFC5102]からの一般的なルールが適用されることをお勧めします。報告された値は、最初に適用されるものです報告されたフローのために観測されたパケット。
Note that the 'translated' value of the fields can be the values before or after the translation depending on the Flow direction and the location of the Observation Point with respect to the middlebox. We always call the value that is not the one observed at the Observation Point the translated value.
フィールドの「翻訳」値は、流れ方向とミドルに対して観測ポイントの位置に応じて、翻訳の前または後の値であることができることに留意されたいです。我々は常に翻訳された値の観測点で観測されたものではない値を呼び出します。
Note also that a middlebox may change the same port number value of packets from the same Flow to different values depending on the packet or other conditions. Also, it is possible that packets of different unidirectional arriving Flows with different source/ destination port number pairs may be mapped to a single Flow with a single source/destination port number pair by the middlebox. In both cases, there is a constant value for the port number pair to be observed on one side of the middlebox, but on the other side the values may vary. In such a case, reliable reporting of the port number pairs on the 'other' side of the middlebox is not possible. According to the IPFIX information model [RFC5102], the first value observed for each port number is reported by the IPFIX protocol in that case.
ミドルボックスは、パケットまたは他の条件に応じて異なる値に同じフローからのパケットの同一のポート番号の値を変更してもよいことにも留意されたいです。また、異なる送信元/宛先ポート番号の組を有する異なる一方向到着フローのパケットがミドルボックスによって、単一のソース/宛先ポート番号の対を有する単一のフローにマッピングされることが可能です。両方の場合において、ミドルボックスの一方の側に観察されるポート番号のペアの一定値とされているが、他の側に値が変化してもよいです。このような場合には、ミドルボックスの「その他」側のポート番号のペアの信頼できる報告は不可能です。 IPFIX情報モデル[RFC5102]によれば、各ポート番号について観察最初の値は、その場合のIPFIXプロトコルによって報告されています。
This recommendation applies to NAT (1), NAT-PT (2), SOCKS gateway (3) and involuntary packet redirection (21) middleboxes. It may also be applied to anonymizers (22), though it should be noted that this carries the risk of losing the effect of anonymization.
この推奨は、NAT（1）、NAT-PT（2）、SOCKSゲートウェイ（3）及び不随意パケットのリダイレクション（21）中間装置に適用されます。これは匿名の効果を失うリスクを運ぶことに留意すべきであるけれども、それはまた、アノニマイザ（22）に適用してもよいです。
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] are the REQUIRED protocols for securing network traffic exported with IPFIX (see Section 11 of [RFC5101]). TLS requires a reliable transport channel and is selected as the security mechanism for TCP. DTLS is a version of TLS capable of securing datagram traffic and is selected for UDP, SCTP, and PR-SCTP.
トランスポート層セキュリティ（TLS）[RFC4346]とデータグラムトランスポート層セキュリティ（DTLS）[RFC4347]は（[RFC5101]のセクション11を参照）IPFIXでエクスポートしたネットワークトラフィックを確保するために必要なプロトコルです。 TLSは、信頼性の高いトランスポート・チャネルを必要とし、TCPのためのセキュリティメカニズムとして選択されています。 DTLSは、データグラムトラフィックを確保できるTLSのバージョンであり、UDP、SCTP、およびPR-SCTPのために選択されています。
When mapping TLS terminology used in [RFC4346] to IPFIX terminology, keep in mind that the IPFIX Exporting Process, as it is the connection initiator, corresponds to the TLS client, and the IPFIX Collecting Process corresponds to the TLS server. These terms apply only to the bidirectional TLS handshakes done at Transport Session establishment and completion time; aside from TLS connection set up between the Exporting Process and the Collecting Process, and teardown at the end of the session, the unidirectional Flow of messages from Exporting Process to Collecting Process operates over TLS just as over any other transport layer for IPFIX.
IPFIX用語に[RFC4346]で使用されるTLS用語をマッピングする場合、それは接続開始剤であるとしてIPFIXエクスポートプロセスは、TLSのクライアントに対応することに注意してください、そしてIPFIX収集プロセスは、TLSサーバーに相当します。これらの用語は、唯一の交通セッション確立と終了時に行わ双方向TLSハンドシェイクに適用されます。脇セッションの終了時にエクスポートプロセスと収集プロセス、及びティアダウンの間に設定TLS接続から、収集処理するためのプロセスをエクスポートからのメッセージの一方向の流れだけIPFIXのための任意の他のトランスポート層の上のようTLSで動作します。
When using TLS or DTLS to secure an IPFIX Transport Session, the Collecting Process and Exporting Process must use strong mutual authentication. In other words, each IPFIX endpoint must have its own X.509 certificate [RFC3280] and private key, and the Collecting Process, which acts as the TLS or DTLS server, must send a Certificate Request to the Exporting Process during the TLS handshake, and fail to establish a session if the Exporting Process does not present a valid certificate.
IPFIX交通セッションを確保するために、TLSまたはDTLSを使用する場合は、収集プロセスとエクスポートプロセスは、強力な相互認証を使用する必要があります。言い換えれば、各IPFIXエンドポイントは、TLSハンドシェイク中にエクスポートプロセスに証明書要求を送信する必要があり、TLSまたはDTLSサーバとして動作し、独自のX.509証明書[RFC3280]と秘密鍵、および収集プロセスを、持っている必要がありますおよびエクスポートプロセスは、有効な証明書を提示していない場合は、セッションを確立するために失敗します。
Each Exporting Process and Collecting Process must verify the identity of its peer against a set of authorized peers. This may be done by configuring a set of authorized distinguished names and comparing the peer certificate's subject distinguished name against each name in the set. However, if a private certification authority (CA) is used to sign the certificates identifying the Collecting Processes and Exporting Processes, and the set of certificates signed by that private CA may be restricted to those identifying peers authorized to communicate with each other, it is sufficient to merely verify that the peer's certificate is issued by this private CA.
各処理をエクスポートし、収集プロセスは、許可ピアのセットに対して、そのピアのIDを確認しなければなりません。これは、認可識別名のセットを設定し、セット内の各名称に対してピア証明書のサブジェクト識別名を比較することによって行うことができます。しかし、プライベート証明機関（CA）がプロセスを収集プロセスを識別し、エクスポート証明書に署名するために使用される場合、そのプライベートCAによって署名された証明書のセットが互いに通信することを許可もの特定のピアに制限することができる、それは単にピアの証明書は、このプライベートCAによって発行されていることを確認するのに十分な
When verifying the identity of its peer, an IPFIX Exporting Process or Collecting Process must verify that the peer certificate's subject common name or subjectAltName extension dNSName matches the fully-qualified domain name (FQDN) of the peer. This involves retrieving the expected domain name from the peer certificate and the address of the peer, then verifying that the two match via a DNS lookup. Such verification should require both that forward lookups (FQDN to peer address) and reverse lookups (peer address to FQDN) match. In deployments without DNS infrastructure, it is acceptable to represent the FQDN as an IPv4 dotted-quad or a textual IPv6 address as in [RFC1924].
ピアの身元を確認すると、IPFIXエクスポートプロセスまたは収集プロセスは、ピア証明書のサブジェクト共通名またはsubjectAltName拡張のdNSNameは、ピアの完全修飾ドメイン名（FQDN）と一致していることを確認しなければなりません。そして、これは、DNSルックアップを経由していること2試合を検証し、ピア証明書とピアのアドレスから予想されるドメイン名を取得する必要。そのような検証は、フォワードルックアップの両方が一致（FQDNにピアアドレス）ルックアップを（FQDNアドレスをピアに）およびリバース要求すべきです。 DNSインフラストラクチャ無し配置では、[RFC1924]のようにIPv4のドット付きクワッドまたはテキストのIPv6アドレスとしてFQDNを表すために許容可能です。
Of the security solutions specified for IPFIX, TLS over TCP is as of this writing the most mature and widely implemented. Until stable implementations of DTLS over SCTP are widely available (see Section 8.5, below), it is recommended that applications requiring secure transport for IPFIX Messages use TLS over TCP.
TCP上IPFIX、TLSのために指定されたセキュリティ・ソリューションの最も成熟したと広く実装を書いて、こののようです。 SCTPを超えるDTLSの安定した実装は（以下、セクション8.5を参照）が広く利用できるようになるまで、IPFIXメッセージのための安全な輸送を必要とするアプリケーションは、TCP上のTLSを使用することをお勧めします。
When using TLS over TCP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using TCP as the transport protocol, especially as regards the handling of Templates and Template withdrawals.
TCP上のTLSを使用する場合は、トランスポートプロトコルとしてTCPを使用しているかのように、IPFIXのエクスポートプロセスと収集プロセスは、テンプレートとテンプレートの引き出しの取り扱いに関しては、特にとして、全ての他の側面に振る舞うべきです。
An implementation of the DTLS protocol version 1, described in [RFC4347] and required to secure IPFIX over UDP, is available in OpenSSL [OPENSSL] as of version 0.9.8. However, DTLS support is as of this writing under active development and certain implementations might be unstable. We recommend extensive testing of DTLS-based IPFIX implementations to build confidence in the DTLS stack over which your implementation runs.
DTLSプロトコルバージョン1の実装、[RFC4347]に記載されており、UDP上IPFIXを確保するために必要では、バージョン0.9.8のようOPENSSL] OpenSSLのに利用可能です。しかし、DTLSのサポートが活発な開発下にこれを書いているようで、特定の実装が不安定になることがあります。私たちはあなたのインプリメンテーションの実行オーバーDTLSスタックの信頼を構築するためにDTLSベースのIPFIX実装の広範なテストをお勧めします。
When using DTLS over UDP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using UDP as the transport protocol, especially as regards the handling of Templates and Template timeouts.
UDP上でDTLSを使用する場合は、トランスポートプロトコルとしてUDPを使用しているかのように、IPFIXのエクスポートプロセスと収集プロセスは、テンプレートとテンプレートタイムアウトの取り扱いに関しては、特にとして、全ての他の側面に振る舞うべきです。
Note that the selection of IPFIX Message sizes for DTLS over UDP must account for overhead per packet introduced by the DTLS layer.
UDPを超えるDTLSがDTLS層によって導入されたパケットごとのオーバーヘッドを考慮しなければならないためIPFIXメッセージの選択はサイズことに注意してください。
As of this writing, there is no publicly available implementation of DTLS over SCTP as described in [RFC4347] and [TUEXEN].
これを書いているように、NO [TUEXEN] [RFC4347]に記載されたようにSCTP上DTLSの公的に利用可能な実装は存在しません。
When using DTLS over SCTP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using SCTP as the transport protocol, especially as regards the handling of Templates and the use of reliable transport for Template and scope information.
SCTP上でDTLSを使用する場合は、トランスポートプロトコルとしてSCTPを使用しているかのように、IPFIXのエクスポートプロセスと収集プロセスは、テンプレートの取り扱いとテンプレートとスコープ情報のための信頼性の高い交通機関の利用に関しては、特にとして、全ての他の側面に振る舞うべきです。
An implementation of the DTLS protocol version 1, described in [RFC4347] and required to secure IPFIX over SCTP, is available in OpenSSL [OPENSSL] as of version 0.9.8. However, DTLS support is as of this writing under active development and certain implementations might be unstable. We recommend extensive testing of DTLS-based IPFIX implementations to build confidence in the DTLS stack over which your implementation runs.
DTLSプロトコルバージョン1の実装、[RFC4347]に記載されており、SCTP上IPFIXを確保するために必要では、バージョン0.9.8のようOPENSSL] OpenSSLのに利用可能です。しかし、DTLSのサポートが活発な開発下にこれを書いているようで、特定の実装が不安定になることがあります。私たちはあなたのインプリメンテーションの実行オーバーDTLSスタックの信頼を構築するためにDTLSベースのIPFIX実装の広範なテストをお勧めします。
IPFIX supports two sets of Information Elements: IANA-registered Information Elements and enterprise-specific Information Elements. New Information Elements can be added to both sets as described in this section. If an Information Element is considered of general interest, it should be added to the set of IETF-specified Information Elements that is maintained by IANA.
IANA登録情報要素とエンタープライズ固有の情報エレメント：IPFIXは、情報要素の2セットをサポートします。このセクションで説明するように新しい情報要素は、両方のセットに追加することができます。情報要素は、一般的な関心を考えると、それはIANAによって維持されているIETF指定の情報要素の集合に追加する必要があります。
Alternatively, private enterprises can define proprietary Information Elements for internal purposes. There are several potential reasons for doing so. For example, the Information Element might only relate to proprietary features of a device or protocol of the enterprise. Also, pre-standard product delivery or commercially sensitive product features might cause the need for enterprise-specific Information Elements.
また、民間企業は、内部目的のために独自の情報要素を定義することができます。そうするためのいくつかの潜在的理由があります。例えば、情報要素は、企業のデバイスまたはプロトコルの独自の機能に関連するかもしれません。また、前の標準製品出荷または商業的に敏感な製品機能は、エンタープライズ固有の情報要素の必要性が発生することがあります。
The IPFIX information model [RFC5102] document contains an XML-based specification of Template, abstract data types, and IPFIX Information Elements, which may be used to create consistent machine-readable extensions to the IPFIX information model. This description can be used for automatically checking syntactic correctness of the specification of IPFIX Information Elements and for generating code that deals with processing IPFIX Information Elements.
IPFIX情報モデル[RFC5102]ドキュメントはIPFIX情報モデルに一致する機械読み取り可能なオプションを作成するために使用することができるテンプレート、抽象データ型、およびIPFIX情報エレメントのXMLベースの仕様を含んでいます。この説明は、自動的にIPFIX情報要素の仕様の構文の正しさをチェックするためと処理IPFIX情報要素を扱うコードを生成するために使用することができます。
New IPFIX Information Elements that are considered to be of general interest should be added to the set of IETF-specified Information Elements that is maintained by IANA.
一般的な関心であると考えられる新IPFIX情報要素はIANAによって維持されているIETF指定の情報要素の集合に追加する必要があります。
The introduction of new Information Elements in the IANA registry is subject to expert review. As described in Section 7.1 of [RFC5102], an expert review is performed by one of a group of experts designated by an IETF Operations and Management Area Director. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. The group of experts must double check the Information Elements definitions with already defined Information Elements for completeness, accuracy, redundancy, and correct naming following the naming conventions in [RFC5102], Section 2.3.
IANAレジストリに新しい情報要素の導入は、専門家の審査の対象となります。 [RFC5102]のセクション7.1で説明したように、専門家レビューは、IETF操作と管理領域ディレクターによって指定された専門家のグループの1つによって実行されます。専門家は当初、IPFIXとPSAMPワーキンググループの作業部会の議長とドキュメントエディタから描画されます。専門家のグループは、完全性、正確性、冗長性、および中命名規則[RFC5102]、セクション2.3以下の正しい名前について、すでに定義されている情報要素と情報要素の定義を再確認しなければなりません。
The specification of new IPFIX Information Elements must use the Template specified in [RFC5102], Section 2.1, and must be published using a well-established and persistent publication medium.
新しいIPFIX情報要素の仕様は、[RFC5102]、セクション2.1で指定されたテンプレートを使用する必要があり、かつ十分に確立し、持続的な出版媒体を使用して公開する必要があります。
Enterprises or other organizations holding a registered Structure of Management Information (SMI) network management private enterprise code number can specify enterprise-specific Information Elements. Their identifiers can be chosen arbitrarily within the range of 1-32767 and have to be coupled with a Private Enterprise Identifier [PEN]. Enterprise identifiers MUST be registered as SMI network management private enterprise code numbers with IANA. The registry can be found at http://www.iana.org/assignments/enterprise-numbers.
管理情報（SMI）ネットワーク管理、民間企業コード番号の登録構造を保持している企業や他の組織は、企業固有の情報要素を指定することができます。その識別子は、1〜32767の範囲内で任意に選択することができ、民間企業識別子[PEN]と結合しなければなりません。エンタープライズ識別子は、IANAとのSMIネットワーク管理プライベート企業コード番号として登録する必要があります。レジストリはhttp://www.iana.org/assignments/enterprise-numbersで見つけることができます。
The issues listed in this section were identified during implementation and interoperability testing. They do not stem from insufficient clarity in the protocol, but each of these was an actual mistake made in a tested IPFIX implementation. They are listed here for the convenience of future implementers.
このセクションに記載されている問題は、実装との相互運用性のテスト中に同定されました。彼らは、プロトコルに不十分明快に由来していないが、これらのそれぞれは、試験されたIPFIX実装で行われた実際の間違いでした。これらは、将来の実装者の便宜のためにここに記載されています。
A large group of mistakes stems from the fact that many implementers started implementing IPFIX from an existing version of NetFlow version 9 [RFC3954]. Despite their similarity, the two protocols differ in many aspects. We list here some of the most important differences.
ミスの大規模なグループは、多くの実装がのNetFlowバージョン9 [RFC3954]の既存のバージョンからIPFIXを実装し始めているという事実に由来します。その類似性にもかかわらず、2つのプロトコルは、多くの点で異なります。私たちは、ここで最も重要な相違点のいくつかをリストアップ。
o Transport protocol: NetFlow version 9 initially ran over UDP, while IPFIX must have a congestion-aware transport protocol. IPFIX specifies PR-SCTP as its mandatory protocol, while TCP and UDP are optional.
Oトランスポートプロトコル：IPFIXは混雑対応のトランスポートプロトコルを持っている必要がありながら、当初のNetFlowバージョン9は、UDPの上に走りました。 TCPとUDPはオプションである一方、IPFIXは、その必須プロトコルとしてPR-SCTPを指定します。
o IPFIX differentiates between IANA-registered and enterprise-specific Information Elements. Enterprise-specific Information Elements can be specified by coupling a non-IANA-registered Information Element identifier with an Enterprise ID (corresponding to the vendor that defined the Information Element).
O IPFIXは、IANAに登録し、エンタープライズ固有の情報要素を区別しています。企業固有の情報要素（情報要素を定義したベンダーに対応）エンタープライズIDと非IANA登録情報要素識別子を結合することによって特定することができます。
o Options Templates: in IPFIX, an Options Template must have a scope, and the scope is not allowed to be of length zero. The NetFlow version 9 specifications [RFC3954] don't specify that the scope must not be of length zero.
オプションテンプレート（O）IPFIXに、オプションテンプレートは、スコープを持っている必要があり、本発明の範囲は長さゼロであることが許されません。 NetFlowバージョン9の仕様[RFC3954]は範囲が長さゼロであってはならないことを指定していません。
Message Header:
メッセージヘッダ：
o Set ID: Even if the packet headers are different between IPFIX and NetFlow version 9, similar fields are used in both of them. The difference between the two protocols is in the values that these fields can assume. A typical example is the Set ID values: the Set ID values of 0 and 1 are used in NetFlow version 9, while they are not used in IPFIX.
O IDを設定しますパケットヘッダはIPFIXとNetFlowバージョン9と異なっていても、同様のフィールドは、それらの両方で使用されています。 2つのプロトコルの違いは、これらのフィールドが取り得る値です。典型的な例は、セットID値である：それらはIPFIXに使用されていないながら、0と1のセットID値は、NetFlowのバージョン9で使用されています。
o Length field: in NetFlow version 9, this field (called count) contains the number of Records. In IPFIX, it indicates the total length of the IPFIX Message, measured in octets (including Message Header and Set(s)).
O Lengthフィールド：のNetFlowバージョン9で、（数と呼ばれる）このフィールドは、レコードの数が含まれています。 IPFIXでは、（メッセージヘッダーとセット（S）を含む）をオクテット単位で測定された、IPFIXメッセージの全長を示します。
o Timestamp: the NetFlow version 9 header has an additional timestamp: sysUpTime. It indicates the time in milliseconds since the last reboot of the Exporting Process.
Oタイムスタンプは：のsysUpTime：NetFlowバージョン9ヘッダは、追加のタイムスタンプを有します。これは、エクスポートプロセスの最後に再起動してからの時間をミリ秒単位で示します。
o The version number is different. NetFlow version 9 uses the version number 9, while IPFIX uses the version number 10.
Oバージョン番号が異なっています。 IPFIXは、バージョン番号10を使用しながらのNetFlowバージョン9は、バージョン番号9を使用します。
[RFC5101] specifies that the Exporting Process MAY insert some octets for set padding to align Data Sets within a Message. The padding length must be shorter than any allowable Record in that set.
[RFC5101]はエクスポートプロセスは、メッセージ内のデータセットを整列させるために設定されたパディングのためのいくつかのオクテットを挿入することができることを指定します。パディング長は、そのセット内の任意の許容録音よりも短くする必要があります。
It is important to respect this limitation: if the padding length is equal to or longer than the length of the shortest Record, it will be interpreted as another Record.
パディングの長さに等しい又は最短レコードの長さよりも長い場合、それは別のレコードとして解釈される：この制限を尊重することが重要です。
An alternative is to use the paddingOctets Information Element in the Template definition.
代替テンプレート定義でpaddingOctets情報要素を使用することです。
Information Element numbers in IPFIX have the range 0-32767 (0-0x7FFF). Information Element numbers outside this range (i.e., with the high bit set) are taken to be enterprise-specific Information Elements, which have an additional four-byte Private Enterprise Number following the Information Element number and length. Inadvertently setting the high bit of the Information Element number by selecting a number out of this range will therefore cause Template scanning errors.
IPFIXの情報要素番号は0から32767の範囲（0-0x7FFFの）を持っています。この範囲外の情報要素番号（すなわち、高ビットがセットされた）は、情報要素の数及び長さ以下の追加の4バイトのプライベート企業番号を持っている企業固有の情報要素であると解釈されます。誤ってこの範囲外の数を選択することで、情報要素数の高いビットを設定するため、テンプレートのスキャンエラーが発生します。
Template IDs are generated as required by the Exporting Process. When the same set of Information Elements is exported at different times, the corresponding Template is usually identified by different Template IDs. Similarly, if multiple co-existing Templates are composed of the same set of Information Elements, they are also identified by different Template IDs. The Collecting Process does not know in advance which Template ID a particular Template will use.
エクスポートプロセスによって要求されるテンプレートIDが生成されます。情報要素の同じセットが異なる時間にエクスポートすると、対応するテンプレートは、通常、別のテンプレートIDによって識別されます。複数の共同既存のテンプレートは、情報要素の同じセットで構成されている場合は同様に、彼らはまた、別のテンプレートIDによって識別されます。収集プロセスは、特定のテンプレートが使用するテンプレートID、事前に知っていません。
This document describes the implementation guidelines of IPFIX. The security requirements for the IPFIX target applications are addressed in the IPFIX requirements document [RFC3917]. These requirements are considered for the specification of the IPFIX protocol [RFC5101], for which a Security Considerations Section exists.
このドキュメントは、IPFIXの実装ガイドラインを説明します。 IPFIXのターゲットアプリケーションのセキュリティ要件は、IPFIX要件ドキュメント[RFC3917]で扱われています。これらの要件は、セキュリティ上の考慮事項のセクションが存在するIPFIXプロトコル[RFC5101]の仕様のために考慮されます。
Section 7 of this document recommends that IPFIX Exporting Processes report internals about middleboxes. These internals may be security-relevant, and the reported information needs to be protected appropriately for reasons given below.
このドキュメントのセクション7は、IPFIXのエクスポートがミドルボックスに関するレポートの内部を処理することをお勧めします。これらの内部には、セキュリティに関連する可能性がある、と報告された情報は、下記の理由のために、適切に保護される必要があります。
Reporting of packets dropped by firewalls and other packet-dropping middleboxes carries the risk that this information can be used by attackers for analyzing the configuration of the middlebox and for developing attacks against it. Address translation may be used for hiding the network structure behind an address translator. If an IPFIX Exporting Process reports the translations performed by an address translator, then parts of the network structure may be revealed. If an IPFIX Exporting Process reports the translations performed by an anonymizer, the main function of the anonymizer may be compromised.
ファイアウォールやその他のパケットドロップするミドルボックスでドロップされたパケットの報告は、この情報がミドルの構成を分析するために、それに対する攻撃を開発するために攻撃者によって使用することができないリスクを運びます。アドレス変換は、アドレス変換の後ろにネットワーク構造を隠蔽するために使用することができます。 IPFIXエクスポートプロセスは、アドレス変換によって行わ翻訳を報告する場合、ネットワーク構造の一部が明らかにされてもよいです。 IPFIXエクスポートプロセスは、アノニマイザによって実行される変換を報告する場合、アノニマイザの主な機能は損なわれる可能性があります。
Note that there exist vulnerabilities in DTLS over SCTP as specified in the IPFIX protocol, such that a third party could cause messages to be undetectably lost, or an SCTP association to shut down. These vulnerabilities are addressed by [TUEXEN]; however, it is unclear whether initial OpenSSL-based implementations of DTLS over SCTP will contain the required fixes. DTLS over SCTP should be used with caution in production environments until these issues are completely addressed.
第三者がメッセージが検出できないほど失われるために、またはSCTPアソシエーションがシャットダウンする可能性がありますよう、IPFIXプロトコルに指定されているSCTPオーバーDTLSの脆弱性が存在することに注意してください。これらの脆弱性は、[TUEXEN]によって対処されます。しかし、SCTPを超えるDTLSの初期のOpenSSLベースの実装が必要な修正が含まれるかどうかは不明です。これらの問題が完全に解決されるまで、SCTPを超えるDTLSは、本番環境では注意して使用する必要があります。
We would like to thank the MoMe project for organizing two IPFIX Interoperability Events in July 2005 and in March 2006, and Fraunhofer Fokus for organizing the third one in November 2006. The Interoperability Events provided us precious input for this document. Thanks to Brian Trammell for his contributions to the SCTP section and the security guidelines and for the multiple thorough reviews. We would also like to thank Benoit Claise, Carsten Schmoll, and Gerhard Muenz for the technical review and feedback, and Michael Tuexen, Randall Stewart, and Peter Lei for reviewing the SCTP section.
当社は、2006年11月に相互運用性イベントは私たちに、このドキュメントのための貴重な入力を設けられた第3の1を整理するため、2005年7月にと2006年3月2つのIPFIXの相互運用性のイベントを開催してMoMeプロジェクトに感謝したい、とフラウンホーファーFOKUSでしょう。 SCTPセクションおよびセキュリティガイドラインへの貢献のために、複数の徹底的なレビューのためのブライアン・トラメルに感謝します。また、SCTPのセクションをレビューするためブノワClaise、カールステンSchmoll、およびゲルハルトMuenz技術的なレビューとフィードバックのために、そしてマイケル・Tuexen、ランドール・スチュワート、そしてピーター・レイに感謝したいと思います。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"。
[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月。
[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月。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, July 2007.
[IPFIX-AS] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPFIX適用"、進歩、2007年7月ワーク。
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", Work in Progress, September 2006.
[IPFIX - ARCH] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、 "IPフロー情報のエクスポートのためのアーキテクチャ"、進歩、2006年9月での作業。
[IPFIX-REDUCING] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", Work in Progress, May 2007.
、進捗状況、2007年5月の仕事 "IPフロー情報のエクスポート（IPFIX）とパケットサンプリング（PSAMP）レポートで冗長性の削減"、ボスキ、E.、マーク、L.、およびB. Claiseを[IPFIX低減]。
[PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", Work in Progress, December 2007.
[PSAMP-PROTO] Claise、B.、Quittek、J.、およびA.ジョンソン、 "パケットサンプリング（PSAMP）プロトコル仕様" は進歩、2007年12月に働いています。
[TUEXEN] Tuexen, M. and E. Rescorla, "Datagram Transport Layer Security for Stream Control Transmission Protocol", Work in Progress, November 2007.
[TUEXEN] Tuexen、M.およびE.レスコラ、「ストリーム制御伝送プロトコルのためのデータグラムトランスポート層セキュリティ」、進歩、2007年11月に作業。
[TSVWG-UDP] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", Work in Progress, February 2008.
[TSVWG-UDP]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのUDP使用上の注意事項"、進歩、2008年2月に作業。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, April 1996.
[RFC1924]エルツ、R.、 "IPv6アドレスのコンパクトな表現"、RFC 1924、1996年4月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[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., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、エド。、 "シスコシステムズのNetFlowサービスエクスポートバージョン9"、RFC 3954、2004年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[OPENSSL] OpenSSL, "OpenSSL: The Open Source toolkit for SSL/ TLS", <http://www.openssl.org/>.
[OPENSSL] OpenSSLに、 "OpenSSLの：SSL / TLSのためのオープンソースのツールキット"、<http://www.openssl.org/>。
[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http:// www.iana.org/assignments/enterprise-numbers>.
[PEN] IANA、 "民間企業番号"、<のhttp：// www.iana.org/assignments/enterprise-numbers>。
Authors' Addresses
著者のアドレス
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastr. 35 8092 Zurich Switzerland
エリサボスキ日立ヨーロッパ/ ETHチューリッヒO Gloriastr C。 35 8092チューリッヒスイス
Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
電話：+41 44 6327057 Eメール：elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer FOKUS Kaiserin Augusta Allee 31 10589 Berlin Germany
ルッツマーク・フラウンホーファーFOKUS皇后オーガスタアリー31 10589ベルリンドイツ
Phone: +49 421 2246-206 EMail: lutz.mark@ifam.fraunhofer.de
電話：+49 421 2246-206メールアドレス：lutz.mark@ifam.fraunhofer.de
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパ社Kurfuerstenコンディショニング36 69115ハイデルベルク、ドイツ
Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu
電話：+49 6221 4342-115電子メール：quittek@nw.neclab.eu
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
マーティンStiemerling NECヨーロッパ社Kurfürsten-Anlageの36 69115ハイデルベルクドイツ
Phone: +49 6221 4342-113 EMail: stiemerling@nw.neclab.eu
電話：+49 6221 4342-113電子メール：stiemerling@nw.neclab.eu
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
ポール・エイトケンシスコシステムズ社96商業埠頭エジンバラEH6 6LXスコットランド
Phone: +44 131 561 3616 EMail: paitken@cisco.com
電話：+44 131 561 3616 Eメール：paitken@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。