[要約] RFC 5153は、IPFIXの実装ガイドラインであり、IPフロー情報のエクスポートに関する標準化を目的としています。このRFCは、IPFIXの実装者に対して、IPフロー情報のエクスポートに関するベストプラクティスとガイドラインを提供します。
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
IPフロー情報エクスポート（IPFIX）実装ガイドライン
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フロー情報へのアクセスを提供します。[RFC3917]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャが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プロトコルでは、{type、length、value}タプルは、{type、length}ペアを含むテンプレートで表現され、テンプレートに適合するデータレコードに存在する{値}フィールドを指定し、データが送信されるデータの柔軟性を非常に提供します。。
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.
新しいデータ形式の{type、length}ペアを指定する新しいテンプレートを送信するだけで、さまざまなデータレコードを送信できます。詳細については、[RFC5101]を参照してください。
The IPFIX information model [RFC5102] defines a large number of standard Information Elements that provide the necessary { type } information for Templates.
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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標準文書からの引用と修正を除き、「必須」や「必須」などの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).
エクスポートプロセスは、関連するデータレコードの前にテンプレートレコードを送信するように常に努力する必要があります。ただし、対応するデータレコードの前にテンプレートレコードが到着しない場合があるため、収集プロセスは、対応するテンプレートの到着が保留されている未知のテンプレートIDでデータレコードを保存する場合があります（[RFC5101]のセクション9を参照）。テンプレートが利用できない場合は、イベントをログに記録して対応するデータレコードを破棄することをお勧めします。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）Association Restart、ユーザーデータグラムプロトコル（UDP）テンプレートの更新、または送信制御プロトコル（TCP）接続再起動の場合にresする必要があります。
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 reducing]で完全に説明されています。
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).
任意の観測ドメインの外に存在するエンティティ、または複数の観測ドメイン内に存在するエンティティに関する情報をエクスポートする必要がある場合があることに注意してください（たとえば、メータリングプロセシドにスコープされた計量プロセスに関する情報）。このような情報は、観測ドメインID 0を使用したIPFIXメッセージにエクスポートする必要があります（[RFC5101]、セクション3.1を参照）。
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]で同じタイプの複数の情報要素の使用をサポートする必要があります。これは、複数のセレクターIDのエクスポートにパケットサンプリング（PSAMP）[PSAMP-PROTO]によって最初に必要でした。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は、PATH MTUによって制約されるようにUDPを介して輸送されるIPFIXメッセージの最大メッセージサイズを定義します。（セクション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）。フローに関する情報が一度だけエクスポートされた場合、デルタまたは合計カウンターが使用されるかどうかは重要ではありません。ただし、フロー内の追加のパケットに関するさらなる情報が最初のエクスポート後にエクスポートされる場合は、次のとおりです。
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].
デルタカウンターはいくつかの利点を提供します。フローに関する情報は永久に維持する必要はなく、情報の損失は、収集プロセスに保存されている総計にわずかな影響しかありません。最後に、Deltasは、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.
データレコード内の情報要素のアライメントは、各整理されていない情報要素の前に適切な長さのPadningoctets情報要素のインスタンスを挿入することにより達成されます。この挿入は、データレコードに対応するテンプレートレコードまたはオプションテンプレートレコード内で明示的に指定されています。
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.
データレコードは、レコードの最後にあるPadningoctets情報要素のインスタンスを追加することにより、セット内で並べることができます。セット内のすべてのデータレコードには同じ構造とサイズがあるため、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.
Padningoctets情報要素を使用してセット内でレコードが既に整合している場合、このアライメントはすでに達成されています。ただし、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]は、2番目、ミリ秒、マイクロ秒、およびナノ秒解像度で時間値を転送する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デバイスは、計量プロセスで使用されるタイムスタンプよりも高い精度のタイムスタンプ情報要素をエクスポートしてはなりません（たとえば、ミリ秒前の予測フローは、フロースタートマイクロシェーコンドおよびフローエンドマイクロシェーコンドでエクスポートしてはなりません）。
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メッセージヘッダーのエクスポート時間フィールドに基づいて、時間関連情報要素の最適化されたエクスポートの方法を定義しています。[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メッセージのエクスポート時間（つまり、メッセージがエクスポートプロセスを離れるとき）に関する情報がないため、Delta Time情報要素を適切に使用できません。絶対的なタイムスタンプを保存し、これらをエクスポートプロセスに送信する必要があります。エクスポートプロセスは、エクスポート時間がわかったら、これらをデルタタイムスタンプに変換する必要があります。これにより、エクスポートプロセスの処理負担が増加します。また、絶対的なタイムスタンプは、デルタタイムスタンプのカウンターパートよりも多くのストレージが必要であることに注意してください。ただし、この方法により、輸出帯域幅が減少する可能性があります。
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およびflowEndSuptimeの情報要素をあらゆる種類の精度で絶対時間に使用してエクスポートされる相対時間を変換することが困難です。したがって、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の実装は、部分信頼性拡張（PR-SCTP）でSCTPをサポートする必要があり、TCPおよび/またはUDPをサポートする場合があります（[RFC5101]、セクション10.1を参照）。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.
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.
[RFC4960]で指定されているSCTPは、[RFC3758]で定義されているPR-SCTP拡張を使用して、TCPまたはUDPで利用できないいくつかの機能を提供します。これらの2つは、IPFIXの実装に最も普遍的に適用可能であり、IPFIXの実装者が知っておく必要があるのは、複数のストリームと出気ごとの部分的信頼性です。
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アソシエーションには、複数のストリームが含まれる場合があります。ストリームは、ヘッドオブラインブロッキングを回避するのに役立ち、それにより、エクスポートプロセスから収集プロセスへのエンドツーエンドの遅延を最小限に抑えることができます。この機能のアプリケーションの例は、観測ドメインごとに1つのSCTPストリーム、データのタイプごとに1つのストリーム（またはテンプレート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 Associationの特別な利点の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メッセージは、1人のメッセージベースで、完全または部分的な信頼性で送信される場合があります。完全に信頼できる配信は、IPFIXメッセージが収集プロセスで受信されること、またはTCPと同様にSCTP協会がリセットされることを保証します。部分的に信頼性の高い配信は、収集プロセスでの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]は、部分的に信頼性の高い配信を制御するために使用されるインターフェイスを指定する部分信頼性ポリシーの概念を定義します。また、単一のパラメーターであるlifetimeを使用する「タイミングされた信頼性」と呼ばれる単一の例の部分的信頼性ポリシーを定義します。寿命はメッセージごとにミリ秒単位で指定されており、有効期限が切れた後、メッセージを送信する試みは行われません。より長い寿命は、メッセージごとにより多くの再送信試行を指定し、したがって信頼性が高いことを指定します。ただし、特定の寿命によって提供される絶対的な信頼性はネットワーク条件に大きく依存しているため、時限信頼性サービスを使用したエクスポートプロセスは、エクスポートされた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.
SCTPが提供する追加のサービスがあり、PR-SCTP：Un-Ordered Deliveryと組み合わせて役立ちます。また、これは、特定のメッセージを順番に保持するのではなく、キューに入れるとすぐに受信機に配信する必要があることを宣言することにより、1人の男性ベースでも機能します。ただし、送信者によって明示的に要求されない限り、部分的に信頼できるメッセージでさえも順番に配信されることに注意する必要があります。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を使用する場合、テンプレートをresしないでください。また、テンプレートセットとテンプレートの引き出しメッセージは任意のSCTPストリームに送信される可能性があるため、テンプレートの引き出しメッセージは別のストリームに送信されたテンプレートを撤回する場合があり、テンプレートセットは、送信されたテンプレートの引き出しメッセージによって撤回されたテンプレートIDを再利用する場合があります。別のストリーム。したがって、テンプレートの引き出しメッセージを送信するエクスポートプロセスでは、テンプレートの引き出しメッセージとその後のテンプレートセットが撤回されたテンプレートIDを再利用することを可能にして、収集プロセスで適切な順序で処理されるようにする必要があります。エクスポートプロセスは、2つの可能な方法のいずれかでこれを達成できます。1。テンプレートの引き出しメッセージを確実に、順番に送信し、その後のテンプレートセットと同じストリームでIDを再利用することにより。または2.撤回したテンプレートIDを再利用しようとする前に、テンプレートの引き出しメッセージを送信した後、適切な時間（1分のスケールで）待機します。
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の明示的にプロビジョニングされた管理ネットワークの重要な例は、IPFIXを使用して専用ネットワーク上の機能するNetFlow実装を置き換えることです。この状況では、インターフェイスを監視することによって生成されるフローエクスポートトラフィックが監視されているインターフェイスの帯域幅の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-UUDP]で推奨されているように、アプリケーションは、宛先へのパスのMTUを超えてUDPチェックサムを有効にするIPパケットをもたらすUDPメッセージを送信してはなりません（それぞれ[TSVWG-UUDP]のセクション3.2および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]).
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.
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.
信頼性を高め、潜在的に失われたデータの量を制限するために、エクスポートプロセスは、パケットベースのスケジュールを使用して追加のテンプレートを再送信する場合があります。この場合、送信されるデータパケットの数に応じてテンプレートがresします。時間間隔と同様に、数個のパケットごとにテンプレートを控えると、追加のオーバーヘッドが導入されますが、大量のパケットがすでに送信された後にリセンディングは、データのキャッシュと潜在的なデータ損失のために高いコストを意味します。
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.
十分に少ない再送信時間またはパケット間隔により、システムが停止し、継続的に控えめなテンプレートまたはオプションデータになる可能性があることに注意してください。たとえば、resendパケット間隔が2（つまり、テンプレートまたはオプションデータを他のすべてのパケットで送信する）がすべての情報を送信するために必要な場合、再送信間隔は期限切れになります。情報が送信されており、テンプレートまたはオプションデータが継続的に送信されます。おそらく、データが送信されるのを防ぐことができます。したがって、resend間隔は最後のデータパケットから考慮されるべきであり、特定のシーケンス番号に結び付けないでください。
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.
テンプレートの引き出しメッセージは、UDPを介して送信してはなりません（[RFC5101]のセクション10.3.6）。輸出業者は、古いテンプレートの有効期限を切るため、またはテンプレート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プロトコルは、輸出業者がテンプレートの有効期限に関する情報をコレクターに伝えるメカニズムを提供しないため、構成はバンドから実行する必要があります。
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.
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.
Endpointsの1つがSCTPをサポートしていない場合、TCPはIPFIXのトランスポートプロトコルとして使用できますが、信頼できるトランスポートが必要であり、/または輸出業者とコレクターの間のネットワークはIPFIXトラフィックに明示的にプロビジョニングされていません。TCPは、インターネットのコアプロトコルの1つであり、広くサポートされています。
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."
The list of middleboxes discussed in [RFC3234] contains:
[RFC3234]で説明されているミドルボックスのリストには次のものが含まれています。
1. Network Address Translation (NAT),
1. ネットワークアドレス変換（NAT）、
2. NAT-Protocol Translation (NAT-PT), 3. SOCKS gateway,
2. Nat-Protocol翻訳（Nat-PT）、3。SocksGateway、
4. IP tunnel endpoints,
4. IPトンネルエンドポイント、
5. packet classifiers, markers, schedulers,
5. パケット分類器、マーカー、スケジューラー、
6. transport relay,
6. 輸送リレー、
7. TCP performance enhancing proxies,
7. プロキシを向上させるTCPパフォーマンス、
8. load balancers that divert/munge packets,
8. 迂回/マンゲのパケットをロードバランサー、
9. IP firewalls,
9. IPファイアウォール、
10. application firewalls,
10. アプリケーションファイアウォール、
11. application-level gateways,
11. アプリケーションレベルのゲートウェイ、
12. gatekeepers / session control boxes,
12. ゲートキーパー /セッション制御ボックス、
13. transcoders,
13. トランスコダー、
14. proxies,
14. プロキシ、
15. caches,
15. キャッシュ、
16. modified DNS servers,
16. 変更されたDNSサーバー、
17. content and applications distribution boxes,
17. コンテンツとアプリケーションの配布ボックス、
18. load balancers that divert/munge URLs,
18. 迂回/マンゲのurlを削減するバランサー、
19. application-level interceptors,
19. アプリケーションレベルのインターセプター、
20. application-level multicast,
20. アプリケーションレベルのマルチキャスト、
21. involuntary packet redirection,
21.
22. anonymizers.
22. 匿名。
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名が示すように）、これらのセクションは、さまざまなMiddleBoxの考慮事項にどの情報要素をエクスポートするかを推奨することにより、計測プロセスの実装のガイドラインをカバーしています。
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
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 'は空のトラフィックフロー（パケットのないフロー）である可能性があることに注意してください。たとえば、ミドルボックスがファイアウォールであり、フローをブロックする場合。
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_L、右側にT_Rを使用します。
+-----------+
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.
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
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を流します。[RFC5101]のトラフィックフローのIPFIX定義によれば、それぞれ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.
ミドルボックスは他のデバイスと統合される場合があります。例は、ラインカードに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.
その結果、1つ以上のミドルボックスをホストするデバイスで測定されたトラフィックフローを報告するエクスポートプロセスは、ミドルボックス（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]は、ミドルボックス内で変更されるフロープロパティのプレフィックス「POST」を備えた情報要素を提供します。
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.
このドキュメントでは、Middlebox関数以外の観測ポイントを使用して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つ以上のミドルボックスと共同で報告される場合に報告される可能性のあるMiddlebox内部情報に関する推奨事項を示します。報告される内部情報はミドルボックスの種類に依存するため、種類ごとに説明されています。
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.
カバーされているのは、種類のパケットレベルのミドルボックスです。カバーされていないのは、4、6-8、11-20です。TCPパフォーマンスを向上させるプロキシ（7）は、ACKパケットを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.
それでも、可能であれば、覆われていないミドルボックス（つまり、タイプ7または11-20の）と共同住宅されたIPFIX実装は、これらの推奨事項の意図を反映する方法で適用できる場合は、このセクションで与えられた推奨事項に従う必要があります。
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の観測ポイントがパケットを潜在的にドロップする潜在的な1つ以上のミドルボックスと共同で配置されている場合、対応する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）、ソックスゲートウェイ（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の観測ポイントが、IPヘッダーのDiffServコードポイント（DSCP、[RFC2474]を参照）を潜在的に変更する可能性のある1つまたは複数のミドルボックスと共同住宅されている場合、対応するIPFIXエクスポートプロセスは、観測された着信DSCPの両方を報告できるはずです。値とミドルボックスの「他の」側のDSCP値（これが特定のトラフィックフローの一定の値である場合）。[RFC5102]で指定されている関連情報要素は、IPCLASSOFSERVICEおよびPOSIPCLASSOFSERVICEです。
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の変更前に観察されたパケット、つまり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値を変更する場合があることに注意してください。また、単一の単方向到着フローのパケットには、Middleboxによって同じ値に設定された異なる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）、ソックスゲートウェイ（3）、および不随意パケットリダイレクト（21）ミドルボックスに適用されます。また、匿名化者にも適用される場合がありますが、これは匿名化の効果を失うリスクがあることに注意する必要があります。
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]は、IPFIXでエクスポートされるネットワークトラフィックを保護するために必要なプロトコルです（[RFC5101]のセクション11を参照）。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.
[RFC4346]で使用されるTLS用語をIPFIX用語にマッピングする場合、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.
TLSまたはDTLSを使用してIPFIXトランスポートセッションを保護する場合、収集プロセスとエクスポートプロセスは強力な相互認証を使用する必要があります。言い換えれば、各IPFIXエンドポイントには独自のx.509証明書[RFC3280]と秘密鍵が必要であり、TLSまたはDTLSサーバーとして機能する収集プロセスは、TLSハンドシェーク中にエクスポートプロセスに証明書要求を送信する必要があります。エクスポートプロセスが有効な証明書を提示しない場合、セッションを確立できません。
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.
各エクスポートプロセスと収集プロセスは、許可された一連のピアに対してピアの身元を検証する必要があります。これは、承認された著名な名前のセットを設定し、ピア証明書の件名をセット内の各名前と比較することで行うことができます。ただし、収集プロセスとエクスポートプロセスを特定する証明書に署名するために民間認定機関（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]のように、FQDNをIPv4点線またはテキストIPv6アドレスとして表すことは許容されます。
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.
IPFIXに指定されたセキュリティソリューションのうち、TCPを超えるTLSは、この時点で最も成熟しており、広く実装されています。SCTPを介したDTLの安定した実装が広く利用可能になるまで（以下のセクション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を使用する場合、IPFIXのエクスポートプロセスと収集プロセスは、特にテンプレートとテンプレート引き出しの取り扱いに関して、TCPを輸送プロトコルとして使用するかのように他のすべての側面で動作する必要があります。
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.
[RFC4347]で説明され、UDPを介してIPFIXを保護するために必要なDTLSプロトコルバージョン1の実装は、バージョン0.9.8の時点でOpenSSL [OpenSSL]で利用可能です。ただし、DTLSのサポートは、この記述の積極的な開発の際には、特定の実装が不安定である可能性があります。DTLSベースのIPFIX実装の広範なテストをお勧めします。IPFIX実装は、実装が実行されるDTLSスタックに信頼性を構築することをお勧めします。
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でDTLを使用する場合、IPFIXのエクスポートプロセスと収集プロセスは、特にテンプレートとテンプレートのタイムアウトの処理に関して、輸送プロトコルとしてUDPを使用するかのように他のすべての側面で動作する必要があります。
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のIPFIXメッセージサイズの選択は、DTLSレイヤーによって導入されたパケットごとのオーバーヘッドを考慮する必要があることに注意してください。
As of this writing, there is no publicly available implementation of DTLS over SCTP as described in [RFC4347] and [TUEXEN].
この執筆時点では、[RFC4347]および[Tuexen]で説明されているように、SCTPを介したDTLの公開可能な実装はありません。
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を使用する場合、IPFIXのエクスポートプロセスと収集プロセスは、特にテンプレートの取り扱いとテンプレートおよびスコープ情報の信頼できるトランスポートの使用に関して、輸送プロトコルとしてSCTPを使用するかのように他のすべての側面で動作する必要があります。
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.
[RFC4347]で説明され、SCTPを介してIPFIXを保護するために必要なDTLSプロトコルバージョン1の実装は、バージョン0.9.8の時点でOpenSSL [OpenSSL]で利用可能です。ただし、DTLSのサポートは、この記述の積極的な開発の際には、特定の実装が不安定である可能性があります。DTLSベースのIPFIX実装の広範なテストをお勧めします。IPFIX実装は、実装が実行されるDTLSスタックに信頼性を構築することをお勧めします。
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.
IPFIXは、IANA登録情報要素とエンタープライズ固有の情報要素の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情報要素のXMLベースの仕様が含まれています。これは、IPFIX情報モデルに一貫したマシン読み取り可能な拡張機能を作成するために使用できます。この説明は、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情報要素は、IEANAによって維持される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 トランスポートプロトコル：Netflowバージョン9は最初にUDPを介して実行されましたが、IPFIXにはうっ血を認識するトランスポートプロトコルが必要です。IPFIXは、PR-SCTPを必須プロトコルとして指定し、TCPとUDPはオプションです。
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（情報要素を定義したベンダーに対応）と結合することで指定できます。
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値です。0と1の設定されたID値は、Netflowバージョン9で使用されますが、IPFIXでは使用されていません。
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
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 タイムスタンプ：Netflowバージョン9ヘッダーには、追加のタイムスタンプ：sysuptimeがあります。エクスポートプロセスの最後の再起動以来、ミリ秒単位での時間を示します。
o The version number is different. NetFlow version 9 uses the version number 9, while IPFIX uses the version number 10.
o バージョン番号は異なります。Netflowバージョン9はバージョン番号9を使用し、IPFIXはバージョン番号10を使用します。
[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.
別の方法は、テンプレート定義でPadningoctets情報要素を使用することです。
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.
IPFIXプロトコルで指定されているように、SCTPを介したDTLに脆弱性が存在するため、サードパーティがメッセージを検出できないこと、またはSCTPアソシエーションがシャットダウンする可能性があることに注意してください。これらの脆弱性は[tuexen]によって対処されています。ただし、SCTPを介したDTLの初期OpenSSLベースの実装に必要な修正が含まれるかどうかは不明です。SCTPを介したDTLは、これらの問題が完全に対処されるまで、生産環境では注意して使用する必要があります。
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.
2005年7月と2006年3月に2つのIPFIX相互運用性イベントを開催してくれたMOMEプロジェクトと、2006年11月に3番目のイベントを開催してくれたFraunhofer Fokusに感謝します。SCTPセクションへの貢献とセキュリティガイドラインと複数の徹底的なレビューについて、ブライアントラメルに感謝します。また、技術レビューとフィードバックについては、Benoit Claise、Carsten Schmoll、およびGerhard Muenzに感謝します。MichaelTuexen、Randall Stewart、Peter Leiは、SCTPセクションのレビューをしてくれました。
[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.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, July 2007.
[Ipfix-as] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「Ipfix Applicability」、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.、Brownlee、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.
[IPFIXを減らす] Boschi、E.、Mark、L。、およびB. Claise、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」、2007年5月の作業。
[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. Johnson、「パケットサンプリング（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. Rescorla、「Datagram Transport Layer Security for Stream Control Transmission Protocol」、Progress、2007年11月。
[TSVWG-UDP] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", Work in Progress, February 2008.
[TSVWG-UUDP] Eggert、L。およびG. Fairhurst、「アプリケーションデザイナーのUDP使用ガイドライン」、2008年2月、Work in Progress。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, April 1996.
[RFC1924] Elz、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.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「ストリーム制御伝送プロトコル（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. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、ed。、「Cisco Systems Netflow Services Export Version 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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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
Elisa Boschi Hitachi Europe c/o eth zurich gloriest。35 8092チューリッヒスイス
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer FOKUS Kaiserin Augusta Allee 31 10589 Berlin Germany
Lutz Mark Fraunhofer Fokus Kaiserin Augusta Allee 31 10589ベルリンドイツ
Phone: +49 421 2246-206
EMail: lutz.mark@ifam.fraunhofer.de
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Juergen Quittek Nec Europe Ltd. Kurfuersten-Anlage 36 69115ハイデルベルクドイツ
Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
電話：49 6221 4342-115メール：quittek@nw.neclab.eu Martin Stiemerling Nec Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelbergドイツ
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
Paul Aitken Cisco Systems、Inc。96コマーシャルキーエディンバラEH6 6LXスコットランド
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。