Network Working Group T. Zseby
Request for Comments: 5472 Fraunhofer FOKUS
Category: Informational E. Boschi
Hitachi Europe
N. Brownlee
CAIDA
B. Claise
Cisco Systems, Inc.
March 2009
IP Flow Information Export (IPFIX) Applicability
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.
この文書では、我々は、様々なアプリケーションのためのIPフロー情報のエクスポート（IPFIX）プロトコルの適用性を説明します。私たちは、アプリケーションは、関連する情報要素（IE）それらのアプリケーションのために、そして現在の機会とプロトコルの制限事項について説明し、IPFIXを使用する方法を示しています。さらに、我々は他のアーキテクチャやフレームワークにIPFIXフレームワークの関係を説明します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Applications of IPFIX ...........................................4
2.1. Accounting .................................................4
2.1.1. Example .............................................5
2.2. Traffic Profiling ..........................................7
2.3. Traffic Engineering ........................................8
2.4. Network Security ...........................................9
2.5. QoS Monitoring ............................................11
2.5.1. Correlating Events from Multiple
Observation Points .................................12
2.5.2. Examples ...........................................12
2.6. Inter-Domain Exchange of IPFIX Data .......................14
2.7. Export of Derived Metrics .................................14
2.8. Summary ...................................................15
3. Relation of IPFIX to Other Frameworks and Protocols ............16
3.1. IPFIX and IPv6 ............................................16
3.2. IPFIX and PSAMP ...........................................16
3.3. IPFIX and RMON ............................................16
3.4. IPFIX and IPPM ............................................18
3.5. IPFIX and AAA .............................................18
3.5.1. Connecting via a AAA Client ........................20
3.5.2. Connecting via an Application Specific
Module (ASM) .......................................21
3.6. IPFIX and RTFM ............................................21
3.6.1. Architecture .......................................21
3.6.2. Flow Definition ....................................22
3.6.3. Configuration and Management .......................22
3.6.4. Data Collection ....................................22
3.6.5. Data Model Details .................................23
3.6.6. Transport Protocol .................................23
3.6.7. Summary ............................................23
4. Limitations ....................................................24
4.1. Using IPFIX for Other Applications than Listed in
RFC 3917 ..................................................24
4.2. Using IPFIX for Billing (Reliability Limitations) .........24
4.3. Using a Different Transport Protocol than SCTP ............25
4.4. Push vs. Pull Mode ........................................25
4.5. Template ID Number ........................................26
4.6. Exporting Bidirectional Flow Information ..................26
4.7. Remote Configuration ......................................27
5. Security Considerations ........................................27
6. Acknowledgements ...............................................28
7. Normative References ...........................................28
8. Informative References .........................................28
The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. IP Flow information provides important input data for a variety of applications. The IPFIX protocol is a general data transport protocol that is easily extensible to suit the needs of such applications. In this document, we describe how typical applications can use the IPFIX protocol and show opportunities and limitations of the protocol. Furthermore, we describe the relationship of IPFIX to other frameworks and architectures. Although examples in this document are shown for IPv4 only, the applicability statements apply to IPv4 and IPv6. IPFIX provides appropriate Information Elements for both IP versions.
IPFIXプロトコルは、IPフロー情報は、ルータ、計測プローブ、または他のデバイスからエクスポートすることができる方法を定義します。 IPフロー情報は、様々な用途に重要な入力データを提供します。 IPFIXプロトコルは、そのようなアプリケーションのニーズに合わせて容易に拡張可能であり、一般的なデータ転送プロトコルです。この文書では、我々は、IPFIXプロトコルを使用して、プロトコルの機会と限界を表示することができますどのように典型的なアプリケーションについて説明します。さらに、我々は他のフレームワークとアーキテクチャへのIPFIXの関係を説明します。このドキュメントの例は、IPv4のみのために示されているが、適用文は、IPv4とIPv6に適用されます。 IPFIXは、両方のIPバージョンのために適切な情報要素を提供します。
IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. In this document, as in [RFC5101], the first letter of each IPFIX-specific term is capitalized.
この文書で使用IPFIX固有の用語は[RFC5101]のセクション2で定義されています。この文書では、[RFC5101]のように、各IPFIX固有の用語の最初の文字を大文字にします。
IPFIX data enables several critical applications. The IPFIX target applications and the requirements that originate from those applications are described in [RFC3917]. Those requirements were used as basis for the design of the IPFIX protocol. This section describes how these target applications can use the IPFIX protocol. Considerations for using IPFIX for other applications than those described in [RFC3917] can be found in Section 4.1.
IPFIXデータは、いくつかの重要なアプリケーションを可能にします。 IPFIXターゲットアプリケーションとそれらのアプリケーションから発信要求は[RFC3917]に記載されています。これらの要件は、IPFIXプロトコルの設計のための基礎として使用されました。このセクションでは、これらのターゲットアプリケーションがIPFIXプロトコルを使用する方法について説明します。 [RFC3917]に記載されたもの以外の用途にIPFIXを使用するための考慮事項は、4.1節に見出すことができます。
Usage-based accounting is one of the target applications for IPFIX as defined in [RFC3917]. IPFIX records provide fine-grained measurement results for highly flexible and detailed usage reporting. Such data is used to realize usage-based accounting. Nevertheless, IPFIX does not provide the reliability required by usage-based billing systems as defined in [RFC2975] (see Section 4.2). The accounting scenarios described in this document only provide limited reliability as explained in Section 4.2 and should not be used in environments where reliability as demanded by [RFC2975] is mandatory.
[RFC3917]で定義されるように従量課金は、IPFIXのためのターゲットアプリケーションの一つです。 IPFIXレコードは非常に柔軟で詳細な使用状況レポートのためのきめ細かな測定結果を提供します。このようなデータは、使用量ベースの会計を実現するために使用されます。それにもかかわらず、IPFIXは[RFC2975]で定義されるように従量課金システムによって必要とされる信頼性を提供しない（セクション4.2を参照）。 4.2節で説明した[RFC2975]によって要求としての信頼性は必須である環境で使用されるべきではないとして、この文書に記載された会計シナリオは限られた信頼性を提供します。
In order to realize usage-based accounting with IPFIX, the Flow definition has to be chosen in accordance to the accounting purpose, such as trend analysis, capacity planning, auditing, or billing and cost allocation where some loss of data can be tolerated (see Section 4.2).
IPFIXと従量課金を実現するために、フロー定義は、傾向分析、容量計画、監査、又は課金データの一部の損失を許容できるコスト配分として、会計目的に応じて選択されなければならない（参照4.2節）。
Flows can be distinguished by various IEs (e.g., packet header fields) from [RFC5102]. Due to the flexible IPFIX Flow definition, arbitrary Flow-based accounting models can be realized without extensions to the IPFIX protocol.
フローは[RFC5102]から種々のIE（例えば、パケットヘッダフィールド）によって識別することができます。柔軟なIPFIXフロー定義に、任意のフローベースの会計モデルは、IPFIXプロトコルに拡張することなく実現することができます。
Accounting can, for instance, be based on individual end-to-end Flows. In this case, it can be realized with a Flow definition determined by the quintuple consisting of source address (sourceIPv4Address), destination address (destinationIPv4Address), protocol (protocolIdentifier), and port numbers (udpSourcePort, udpDestinationPort). Another example is class-dependent accounting (e.g., in a Diffserv network). In this case, Flows could be distinguished just by the Diffserv codepoint (DSCP) (ipDiffServCodePoint) and IP addresses (sourceIPv4Address, destinationIPv4Address). The essential elements needed for accounting are the number of transferred packets and bytes per Flow, which can be represented by the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount).
会計は、例えば、個々のエンド・ツー・エンドのフローに基づくことができます。この場合には、送信元アドレス（sourceIPv4Address）からなる五重、宛先アドレス（destinationIPv4Address）、プロトコル（プロトコル識別子）とポート番号（udpSourcePort、udpDestinationPort）によって決定されるフロー定義で実現することができます。別の例は、クラス依存アカウンティング（例えば、Diffservのネットワーク内）です。この場合、フローはただのDiffservコードポイント（DSCP）（ipDiffServCodePoint）とIPアドレス（sourceIPv4Address、destinationIPv4Address）によって区別することができました。アカウンティングのために必要不可欠な要素は、フローごとのカウンタのIE（例えば、packetTotalCount、octetTotalCount）で表すことができるフローごと転送されたパケットとバイトの数です。
For accounting purposes, it would be advantageous to have the ability to use IPFIX Flow Records as accounting input in an Authentication, Authorization, and Accounting (AAA) infrastructure. AAA servers then could provide the mapping between user and Flow information. Again for such scenarios the limited reliability currently provided by IPFIX has to be taken into account.
会計目的のために、認証、許可、アカウンティング（AAA）インフラストラクチャの会計入力としてIPFIXフローレコードを使用する能力を有することが有利であろう。 AAAサーバは、ユーザとフロー情報との間のマッピングを提供することができます。再び、そのようなシナリオについて現在IPFIXによって提供される限られた信頼性を考慮に入れなければなりません。
Please note: As noted in [RFC3330], the address block 192.0.2.0/24 may be used for example addresses. In the example below, we use two example networks. In order to be conformant to [RFC3330], we divide the given address block into two networks by subnetting with a 25-bit netmask (192.0.2.0/25) as follows:
注意：[RFC3330]で述べたように、アドレスブロック192.0.2.0/24は、例えばアドレスのために使用することができます。以下の例では、我々は2つのサンプルネットワークを使用しています。 [RFC3330]に準拠するために、我々は次のように25ビットネットマスク（192.0.2.0/25）とサブネットことにより、2つのネットワークに与えられたアドレスブロックを分割します。
Network A: 192.0.2.0 ... 192.0.2.127 Network B: 192.0.2.128 ... 192.0.2.255
ネットワークA：192.0.2.0 ... 192.0.2.127ネットワークB：192.0.2.128 ... 192.0.2.255
Let's suppose someone needs to monitor the individual Flows in a Diffserv network in order to compare traffic amount trend with the terms outlined in a Service Level Agreement (SLA). Flows are distinguished by source and destination address. The information to export in this case is:
誰かがサービスレベル契約（SLA）に概説用語とトラフィック量の傾向を比較するためにはDiffservネットワーク内の個々のフローを監視する必要があるとしましょう。フローは、送信元と宛先のアドレスで区別されています。この場合にエクスポートする情報は次のとおりです。
- IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4ソースIPアドレス：sourceIPv4Address [RFC5102]で、4つのオクテットの長さ
- IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4宛先IPアドレス：4つのオクテットの長さを有する、[RFC5102]でdestinationIPv4Address、
- DSCP: ipDiffServCodePoint in [RFC5102], with a length of 1 octet
- DSCP：[RFC5102]でipDiffServCodePoint、1つのオクテットの長さを有します
- Number of octets of the Flow: octetDeltaCount in [RFC5102], with a length of 4 octets
- フローのオクテットの数：[RFC5102]でoctetDeltaCount、4つのオクテットの長さ
The Template set will look as follows:
次のようにテンプレートのセットが表示されます：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information to be exported might be as listed in the following example table:
次の例の表に示すように、エクスポートされる情報は次のようになります。
Src. IP addr. | Dst. IP addr. | DSCP | Octets Number
--------------+---------------+--------+--------------
192.0.2.12 | 192.0.2.144 | 46 | 120868
192.0.2.24 | 192.0.2.156 | 46 | 310364
192.0.2.36 | 192.0.2.168 | 46 | 241239
In the example we use Diffserv codepoint 46, recommended for the Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC3246].
例では、Diffservのを使用し、46のコードポイント[RFC3246]で緊急転送毎のホップ行動（EF PHB）を推奨。
The Flow Records will then look as follows:
次のようにフローレコードはその後になります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.144 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 46 | 120868 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.156 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | 310364 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 241239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measurement results reported in IPFIX records can provide useful input for traffic profiling. IPFIX records captured over a long period of time can be used to track and anticipate network growth and usage. Such information is valuable for trend analysis and network planning.
IPFIXレコードで報告された測定結果は、トラフィックプロファイリングのための便利な入力を提供することができます。長期間にわたって撮影しIPFIXレコードは、ネットワークの成長と使用状況を追跡し、予測することができます。このような情報は、傾向分析、およびネットワーク計画のための価値があります。
The parameters of interest are determined by the profiling objectives. Example parameters for traffic profiling are Flow duration, Flow volume, burstiness, the distribution of used services and protocols, the amount of packets of a specific type, etc. [RFC3917].
興味のあるパラメータは、プロファイリングの目的によって決定されます。トラフィックプロファイリングのための例示的なパラメータ等フロー持続時間、流量、バースト性、使用されるサービスおよびプロトコルの分布、特定の種類のパケットの量は、[RFC3917]です。
The distribution of services and protocols in use can be analyzed by configuring appropriate Flows Keys for Flow discrimination. Protocols can be distinguished by the protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) often provide information about services in use. Those Flow Keys are defined in [RFC5102]. If
使用中のサービスとプロトコルの分布は、フロー識別のための適切なフロー・キーを設定することによって分析することができます。プロトコルは、プロトコル識別子IEで区別することができます。 Portnumbers（例えば、udpDestinationPort）は、多くの場合、使用中のサービスに関する情報を提供しています。これらのフローキーは[RFC5102]で定義されています。もし
portnumbers are not sufficient for service discrimination, further parts of the packet may be needed. Header fields can be expressed by IEs from [RFC5102].
ポート番号は、パケットの更なる部品が必要になる場合があり、サービスの差別のために十分ではありません。ヘッダフィールドは、[RFC 5102]からのIEで表すことができます。
Packet payload can be reported by using the IE ipPayloadPacketSection in [RFC5477].
パケットペイロードは、[RFC5477]にIE ipPayloadPacketSectionを使用して報告することができます。
The Flow duration can be calculated from the Flow Timestamp IEs defined in [RFC5102] (e.g., flowEndMicroseconds - flowStartMicroseconds). The number of packets and number of bytes of a Flow are represented in the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount). The burstiness of a Flow can be calculated from the Flow volume measured at different time intervals.
フロー時間は、[RFC5102]（ - flowStartMicroseconds例えば、flowEndMicroseconds）で定義されたフローのタイムスタンプのIEから計算することができます。パケットおよびフローのバイト数の数は、フローごとのカウンタのIE（例えば、packetTotalCount、octetTotalCount）で表されます。フローのバーストは、異なる時間間隔で測定された流量から計算することができます。
Traffic engineering aims at the optimization of network resource utilization and traffic performance [RFC2702]. Typical parameters are link utilization, load between specific network, nodes, number, size and entry/exit points of active Flows, and routing information [RFC3917].
トラフィックエンジニアリングは、ネットワークリソースの使用率とトラフィックのパフォーマンスの最適化[RFC2702]を目指しています。典型的なパラメータは、特定のネットワーク、ノード、数、サイズおよびエントリ/アクティブフローの出口点、およびルーティング情報[RFC3917]との間のリンク利用率、負荷です。
The size of Flows in packets and bytes can be reported by the IEs packetTotalCount and octetTotalCount. Utilization of a physical link can be reported by using a coarse-grained Flow definition (e.g., based on identifier IEs such as egressInterface or ingressInterface) and per-flow counter IEs (e.g., packetTotalCount, octetTotalCount) defined in [RFC5102].
パケットおよびバイトに流れるの大きさは、IEをpacketTotalCountとoctetTotalCountによって報告することができます。物理リンクの利用粗粒フロー定義を使用して報告することができる（例えば、egressInterface又はingressInterfaceなどの識別子のIEに基づいて）およびフローごとのカウンタのIE（例えば、packetTotalCount、octetTotalCount）は[RFC5102]で定義されます。
The load between specific network nodes can be reported in the same way if one interface of a network node receives only traffic from exactly one neighbor node (as is usually the case). If the ingress interface is not sufficient for an unambiguous identification of the neighbor node, sub-IP header fields IEs (like sourceMacAddress) can be added as Flow Keys.
ネットワーク・ノードの一つのインタフェースは、正確に一つの隣接ノードからのトラフィックのみを受信した場合（通常の場合のように）特定のネットワーク・ノード間の負荷も同様に報告することができます。入力インターフェイスは、隣接ノードの明確な同定のために十分でない場合、サブIPヘッダフィールド（sourceMacAddress等）IEは、フローキーとして添加することができます。
The IE observedFlowTotalCount provides the number of all Flows exported for the Observation Domain since the last initialization of the Metering Process [RFC5102]. If this IE is exported at subsequent points in time, one can derive the number of active Flows in a specific time interval from the difference of the reported counters. The configured Flow termination criteria have to be taken into account to interpret those numbers correctly.
IE observedFlowTotalCountは、計量プロセス[RFC5102]の最後の初期化以来観測ドメインのためにエクスポートされたすべてのフローの数を提供します。このIEは、時間的に後続の点でエクスポートされる場合、一方が報告カウンタの差から特定の時間間隔中にアクティブフローの数を導出することができます。構成されたフローの終了基準は正しくこれらの数字を解釈するために考慮しなければなりません。
Entry and exit points can be derived from Flow Records if Metering Processes are installed at all edges of the network and results are mapped in accordance to Flow Keys. For this and other analysis methods that require the mapping of records from different
計量プロセスは、ネットワークの全ての辺に設置され、その結果、フローキーに応じてマッピングされている場合、エントリポイントと終了ポイントはフローレコードから誘導することができます。これと異なるからレコードのマッピングを必要とする他の分析方法については
Observation Points, the same Flow Keys should be used at all Observation Points. The path that packets take through a network can be investigated by using hash-based sampling techniques as described in [DuGr00] and [RFC5475]. For this, IEs from [RFC5477] are needed.
観測点は、同じフローキーは、すべての観測点で使用する必要があります。パケットがネットワークを通過するパスは、[DuGr00]と[RFC5475]で説明されるようにハッシュベースのサンプリング技術を使用することにより調べることができます。このために、[RFC5477]からのIEが必要とされています。
Neither [RFC5102] nor [RFC5477] defines IEs suitable for exporting routing information.
[RFC5102]や[RFC5477]も、ルーティング情報をエクスポートするのに適したIEを定義します。
Attack and intrusion detection are among the IPFIX target applications described in [RFC3917]. Due to the enormous amount of different network attack types, only general requirements could be addressed in [RFC3917].
攻撃と侵入検知は、[RFC3917]に記載IPFIX対象アプリケーションの一つです。異なるネットワーク攻撃タイプの膨大な量に、唯一の一般的な要件は、[RFC3917]で対処することができます。
The number of metrics useful for attack detection is as diverse as attack patterns themselves. Attackers adapt rapidly to circumvent detection methods and try to hide attack patterns using slow or stealth attacks. Furthermore, unusual traffic patterns are not always caused by malicious activities. A sudden traffic increase may be caused by legitimate users who seek access to a recently published web content. Strange traffic patterns may also be caused by misconfiguration.
攻撃の検出のための便利なメトリックの数は、攻撃パターンそのものと同じくらい多様です。攻撃者は、検出方法を回避し、低速またはステルス攻撃を使って攻撃パターンを隠そうとして迅速に適応します。さらに、異常なトラフィックパターンは、常に悪意のある活動によって引き起こされていません。突然のトラフィックの増加は、最近公開されたWebコンテンツへのアクセスを求める正当なユーザーによって引き起こされることがあります。奇妙なトラフィックパターンも設定ミスによって引き起こされることがあります。
IPFIX can export Flow information for arbitrary Flow definitions as defined in [RFC5101]. Packet information can be exported with IPFIX by using the additional Information Elements described in [RFC5477]. With this, theoretically all information about traffic in the network at the IP layer and above is accessible. This data either can be used directly to detect anomalies or can provide the basis for further post-processing to generate more complex attack detection metrics.
[RFC5101]で定義されるようIPFIXは、任意のフロー定義のフロー情報をエクスポートすることができます。パケット情報は、[RFC5477]に記載の追加の情報要素を用いて、IPFIXでエクスポートすることができます。これにより、上記のIP層でのネットワークにおけるトラフィックの約理論的にはすべての情報がアクセス可能です。このデータは、いずれかの異常を検出するために直接使用することができ、又はより複雑な攻撃の検出メトリックを生成するために、さらに後処理のための基礎を提供することができます。
Depending on the attack type, different metrics are useful. A sudden increase of traffic load can be a hint that an attack has been launched. The overall traffic at an Observation Point can be monitored using per-flow counter IEs like packetTotalCount or octetTotalCount as described in Section 2.3. The number of active Flows can be monitored by regular reporting of the observedFlowTotalCount defined in [RFC5102].
攻撃の種類に応じて、異なるメトリックが便利です。トラフィック負荷の急激な増加は、攻撃が開始されたことをヒントすることができます。 2.3節で説明したようにObservation Pointの全体的なトラフィックがpacketTotalCountまたはoctetTotalCountのようなフローごとのカウンタのIEを使用して監視することができます。アクティブフローの数は、[RFC5102]で定義さobservedFlowTotalCountの定期的な報告によりモニターすることができます。
A sudden increase of Flows from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses. The number of Flows from or to specific networks or hosts can be observed by using source and destination addresses as Flow Keys and observing the number of active Flows as explained above. Many Flows to the same machine, but on different ports, or many Flows to the same port and different machines may be an indicator for vertical or horizontal port scanning activities. The number of Flows to different ports can be reported by using the portnumber Information Elements (udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort) defined in [RFC5102] as Flow Keys.
1つの宛先への異なるソースからの流れの急激な増加は、スプーフィングされたアドレスを使用して、特定のホストまたはネットワーク・ノード上の攻撃によって引き起こされる可能性があります。上述したように、特定のネットワークまたはホストから又はへのフローの数がフローキーとして、送信元および宛先アドレスを使用して、アクティブフローの数を観察することによって観察することができます。多くは、同じマシンに流れるが、異なるポート、または同じポートに多くのフローと異なるマシン上に垂直または水平ポートスキャン活動の指標であってもよいです。異なるポートへのフローの数がフローキーとして[RFC5102]で定義されたポート番号情報要素（udpSourcePort、udpDestinationPort、tcpSourcePort、tcpDestinationPort）を使用して報告することができます。
An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN-flooding. The number of SYN and FIN packets in a Flow can be reported with the IPFIX Information Elements tcpSynTotalCount and tcpFinTotalCount defined in [RFC5102].
TCP-FINパケットへのTCP-SYNの珍しい比は、SYNフラッディングを参照することができます。フローでSYNとFINパケットの数は、[RFC5102]で定義されたIPFIX情報要素tcpSynTotalCountとtcpFinTotalCountで報告することができます。
Worms may leave signatures in traffic patterns. Detecting such events requires more detailed measurements and post-processing than detecting simple changes in traffic volumes.
ワームは、トラフィックパターンに署名を残すことができます。このようなイベントを検出するトラフィック量に単純な変更を検出するより詳細な測定と後処理を必要とします。
A difficult task is the separation of good from bad packets to prepare and launch counteraction. This may require a deeper look into packet content by using further header field IEs from [RFC5102] and/or packet payloads from IE ipPayloadPacketSection in [RFC5477].
困難な作業は、反作用を準備し、起動する不良パケットから良いの分離です。これは、[RFC5477]にIE ipPayloadPacketSectionから[RFC5102]及び/又はパケットペイロードからさらにヘッダーフィールドIEを使用して、パケットの内容に深く外観を必要とするかもしれません。
Furthermore, the amount of resources needed for measurement and reporting increases with the level of granularity required to detect an attack. Multi-step analysis techniques may be useful, e.g., to launch an in-depth analysis (e.g., based on packet information) in case the Flow information shows suspicious patterns. In order to supervise traffic to a specific host or network node, it is useful to apply filtering methods such as those described in [RFC5475].
また、測定および報告のために必要なリソースの量は、攻撃を検出するのに必要な粒度のレベルと共に増加します。多段階の分析技術は、詳細な分析を起動するために、例えば、有用であり得る（例えば、パケットの情報に基づいて）場合のフロー情報は、疑わしいパターンを示します。特定のホストまたはネットワークノードへのトラフィックを監視するためには、例えば、[RFC5475]に記載されているようなフィルタリング方法を適用することが有用です。
Mapping the two directions of communication is often useful for checking correct protocol behavior (see Section 4.6). A correlation of IPFIX data from multiple Observation Points (see Section 2.5.1) allows assessing the propagation of an attack and can help to locate its source.
通信の二つの方向をマッピングすることは、多くの場合、正しいプロトコルの動作を確認するために有用である（4.6節を参照）。複数の観測点からIPFIXデータの相関は、攻撃の伝播を評価することができます（2.5.1項を参照）、その原因を突き止めるのに役立ちます。
The integration of previous measurement results helps to review traffic changes over time for detection of traffic anomalies and provides the basis for forensic analysis. A standardized storage format for IPFIX data would support the offline analysis of data from different operators.
前回の測定結果の統合は、トラフィック異常の検出のために時間をかけて、トラフィックの変化を確認するのに役立ち、法医学的分析のための基礎を提供します。 IPFIXデータの標準化された保存形式が異なるオペレータからのデータのオフライン分析をサポートします。
Nevertheless, capturing full packet traces at all Observation Points in the network is not viable due to resource limitations and privacy concerns. Therefore, metrics should be chosen wisely to allow a solid detection with minimal resource consumption. Resources can be saved, for instance, by using coarser-grained Flow definitions, reporting pre-processed metrics (e.g., with additional Information Elements), or deploying sampling methods.
それにも関わらず、ネットワーク内のすべての観測点での完全なパケットトレースをキャプチャすることは、リソースの制限やプライバシーの問題に実行可能ではありません。したがって、メトリックは、最小のリソース消費と固体検出を可能にするために賢明に選択されるべきです。リソースは、例えば、粗いグレインフロー定義を使用して（追加の情報要素と、例えば、）前処理されたメトリックを報告する、またはサンプリング法を展開することによって、保存することができます。
In many cases, only derived metrics provide sufficient evidence about security incidents. For example, comparing the number of SYN and FIN packets for a specific time interval can reveal an ongoing SYN attack, which is not obvious from unprocessed packet and Flow data. Further metrics like the cumulated sum of various counters, distributions of packet attributes, or spectrum coefficients have been used to identify a variety of attacks.
多くの場合、唯一の派生メトリックは、セキュリティインシデントに関する十分な証拠を提供します。例えば、特定の時間間隔でSYNとFINパケットの数を比較すると、未処理のパケットおよびフローデータから明らかでない進行中のSYN攻撃を、明らかにすることができます。各種カウンタの累積合計などのさらにメトリックは、パケットの属性、またはスペクトル係数の分布は、さまざまな攻撃を識別するために使用されています。
In order to detect attacks early, it is useful to process the data as soon as possible in order to generate significant metrics for the detection. Pre-processing of raw packet and Flow data already at the measurement device can speed up the detection process and reduces the amount of data that need to be exported. Furthermore, it is possible to directly report derived metrics by defining appropriate Information Elements. Immediate data export in case of a potential incident is desired. IPFIX supports such source-triggered exporting of information due to the push model approach. Nevertheless, further exporting criteria have to be implemented to export IPFIX records upon incident detection events and not only upon flow-end or fixed-time intervals.
早期に攻撃を検出するためには、検出のための重要なメトリックを生成するためには、できるだけ早くデータを処理するのに便利です。既に測定装置において生のパケットおよびフローデータの前処理は、検出プロセスをスピードアップし、エクスポートする必要があるデータの量を減少させることができます。さらに、直接、適切な情報要素を定義することで派生メトリックを報告することが可能です。潜在的な事件の場合に即時のデータのエクスポートが望まれています。 IPFIXは、ソース・トリガによるプッシュモデルのアプローチに情報のエクスポートをサポートしています。それにもかかわらず、さらにエクスポート基準は、とだけでなく、フロー・エンドまたは固定の時間間隔に入射検出イベント時にIPFIXレコードをエクスポートするために実装する必要があります。
Intrusion detection would profit from the combination of IPFIX functions with AAA functions (see Section 3.5). Such an interoperation enables further means for attacker detection, advanced defense strategies, and secure inter-domain cooperation.
侵入検知は、AAA機能を備えたIPFIXの機能の組み合わせから利益でしょう（3.5節を参照してください）。このような相互運用は、攻撃者の検出、高度な防衛戦略、およびドメイン間の協力を確保するためのさらなる手段を可能にします。
Quality of service (QoS) monitoring is one target application of the IPFIX protocol [RFC3917]. QoS monitoring is the passive observation of the transmission quality for single Flows or traffic aggregates in the network. One example of its use is the validation of QoS guarantees in service level agreements (SLAs). Typical QoS parameters are loss [RFC2680], one-way [RFC2679] and round-trip delay [RFC2681], and delay variation [RFC3393]. Whenever applicable, the IP Performance Metrics (IPPM) definitions [RFC4148] should be used when reporting QoS metrics.
サービス（QoS）のモニタリングの質がIPFIXプロトコル[RFC3917]のいずれかのターゲットアプリケーションです。 QoSのモニタリングは、ネットワーク内の単一フローまたはトラフィック集合体のための伝送品質の受動的な観察です。その使用の一例は、サービスレベル契約（SLA）におけるQoS保証の検証です。典型的なQoSパラメータは、一方向[RFC2679]と往復遅延[RFC2681]、および遅延変動[RFC3393]損失[RFC2680]です。たび該当するQoSメトリックを報告するとき、IPパフォーマンス・メトリック（IPPM）の定義[RFC4148]は使用すべきです。
The calculation of those QoS metrics requires per-packet processing. Reporting packet information with IPFIX is possible by simply considering a single packet as Flow. [RFC5101] also allows the reporting of multiple identical Information Elements in one Flow Record. Using this feature for reporting information about multiple packets in one record would require additional agreement on semantics regarding the order of Information Elements (e.g., which timestamp belongs to which packet payload in a sequence of Information Elements). [RFC5477] defines useful additional Information Elements for exporting per-packet information with IPFIX.
これらのQoSメトリックの計算は、パケットあたりの処理が必要となります。 IPFIXでパケット情報を報告することは、単に流れとして単一のパケットを考慮することによって可能です。 [RFC5101]も1フローレコード内に複数の同一の情報要素の報告を可能にします。一つのレコードに複数のパケットに関する情報を報告するため、この機能を使用すると、情報要素（例えば、情報要素の順序でパケットペイロードどの属するタイムスタンプ）の順序に関するセマンティクスの追加契約が必要となります。 [RFC5477]はIPFIXとパケット単位の情報をエクスポートするために有用な追加の情報要素を定義します。
Some QoS metrics require the correlation of data from multiple Observation Points. For this, the clocks of the involved Metering Processes must be synchronized. Furthermore, it is necessary to recognize that the same packet was observed at different Observation Points.
いくつかのQoSメトリックは、複数の観測点からのデータの相関を必要とします。このため、関係する計量プロセスのクロックを同期させる必要があります。さらに、同じパケットが別の観測点で観測されたことを認識する必要があります。
This can be done by capturing parts of the packet content (packet header and/or parts of the payload) that do not change on the way to the destination. Based on the packet content, it can be recognized when the same packet arrived at another Observation Point. To reduce the amount of measurement data, a unique packet ID can be calculated from the packet content, e.g., by using a Cyclic Redundancy Check (CRC) or hash function instead of transferring and comparing the unprocessed content. Considerations on collision probability and efficiency of using such packet IDs are described in [GrDM98], [DuGr00], and [ZsZC01].
これは、目的地までの途中で変化しないパケットの内容（パケットヘッダ及び/又はペイロードの部分）の一部を捕捉することにより行うことができます。同じパケットが別の観測ポイントに到着したときに、パケットの内容に基づいて、それを認識することができます。測定データの量を減らすために、固有のパケットIDは、巡回冗長検査（CRC）やハッシュ関数を使用して代わりに未処理の内容を転送し、比較することによって、例えば、パケットの内容から算出することができます。そのようなパケットIDを使用しての衝突確率と効率に関する考察[GrDM98]に記載されている、[DuGr00]、および[ZsZC01]。
IPFIX allows the reporting of several IP and transport header fields (see Sections 5.3 and 5.4 in [RFC5102]). Using only those fields for packet recognition or ID generation can be sufficient in scenarios where those header fields vary a lot among subsequent packets, where a certain amount of packet ID collisions are tolerable, or where packet IDs need to be unique only for a small time interval.
IPFIXは（[RFC5102]のセクション5.3および5.4を参照）は、いくつかのIPとトランスポートヘッダフィールドの報告を可能にします。パケット認識またはIDの生成のためのフィールドのみを使用してそれらのヘッダフィールドは、パケットIDは少ない時間の間で一意である必要があり、パケットIDの衝突の一定量が許容され、またはその後のパケットのうち多くを変えるシナリオで十分であることができます間隔。
For including packet payload information, the Information Element ipPayloadPacketSection defined in [RFC5477] can be used. The Information Element ipHeaderPacketSection can also be used. However, header fields that can change on the way from source to destination have to be excluded from the packet ID generation because they may differ at different Observation Points.
パケットのペイロード情報を含むために、[RFC5477]で定義された情報要素ipPayloadPacketSectionを使用することができます。情報要素ipHeaderPacketSectionも使用することができます。しかし、ソースから目的地までの途中で変更することができるヘッダフィールドは、異なる観察点で異なる可能性があるため、パケットIDの生成から除外されなければなりません。
For reporting packet IDs generated by a CRC or hash function, the Information Element digestHashValue defined in [RFC5477] can be used.
CRCまたはハッシュ関数によって生成されたパケットのIDを報告するために、[RFC5477]で定義された情報要素digestHashValueを使用することができます。
The following examples show which Information Elements need to be reported by IPFIX to generate specific QoS metrics. As an alternative, the metrics can be generated directly at the exporter and IPFIX can be used to export the metrics (see Section 2.7).
次の例では、情報要素は、特定のQoSメトリックを生成するために、IPFIXで報告する必要がある示しています。代替として、メトリックが輸出に直接生成することができ、IPFIXメトリック（セクション2.7を参照）をエクスポートするために使用することができます。
The passive measurement of round-trip time (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, DATA/ACK) are utilized to passively observe the RTT [Brow00]. This technique requires the correlation of data from both directions.
【Brow00]で説明されるように、ラウンドトリップ時間（RTT）の受動的測定は、パケットペアマッチング技術を用いて行うことができます。測定のために、そのようなDNS、ICMP、SNMPまたはTCP（SYN / SYN_ACK、DATA / ACK）などのプロトコルからの要求/応答パケットペアは受動的に観察するために利用されるRTT [Brow00]。この技術は、両方向からのデータの相関を必要とします。
Required Information Elements per packet (DNS example): - Packet arrival time: observationTimeMicroseconds [RFC5477] - DNS header: ipPayloadPacketSection [RFC5477]
パケットごとに必要な情報要素（DNS例）： - パケット到着時間：観測時間マイクロ秒[RFC 5477] - DNSヘッダー：ipPayloadPacketSection [RFC5477]
Required functions: - Recognition of request/response packet pairs
必要な機能： - 要求/応答パケットのペアの認識
Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102] because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
備考： - [RFC5477]からの情報要素が必要です。 - 単一のパケットがフローとして表すことができるのでobservationTimeMicrosecondsはflowStartMicroseconds [RFC5102]で置換することができます。 - より細かい粒度で時間値が必要な場合は、observationTimeNanosecondsを使用することができます。
Passive one-way delay measurements require the collection of data at two Observation Points. As mentioned above, synchronized clocks are needed to avoid time-differences at the involved Observation Points.
パッシブ一方向遅延測定は2観測点のデータの収集を必要としています。前述したように、同期クロックが関与観測点での時間の違いを回避するために必要とされています。
The recognition of packets at the second Observation Point can be based on parts of the packet content directly. A more efficient way is to use a packet ID (generated from packet content).
第二の観測点におけるパケットの認識が直接パケットコンテンツの部分に基づくことができます。より効率的な方法は、（パケットの内容から生成された）パケットのIDを使用することです。
Required Information Elements per packet (with packet ID): - Packet arrival time: observationTimeMicroseconds [RFC5477] - Packet ID: digestHashValue [RFC5477]
（パケットIDを持つ）パケットごとに必要な情報要素： - パケット到着時間：observationTimeMicroseconds [RFC5477] - パケットID：digestHashValue [RFC5477]
Required functions: - Packet ID generation - Delay calculation (from arrival times at the two Observation Points)
必要な機能： - パケットIDの生成 - （2つの観測点での到着時間からの）遅延計算
Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102], because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
備考： - [RFC5477]からの情報要素が必要です。 - 単一のパケットがフローとして表すことができるのでobservationTimeMicrosecondsは、flowStartMicroseconds [RFC5102]で置換することができます。 - より細かい粒度で時間値が必要な場合は、observationTimeNanosecondsを使用することができます。
- The amount of content used for ID generation influences the number of collisions (different packets that map to the same ID) that can occur. Investigations on this and other considerations on packet ID generation can be found in [GrDM98], [DuGr00], and [ZsZC01].
- IDの生成に使用されるコンテンツの量が発生する可能性が衝突（同じIDにマップ異なるパケット）の数に影響を与えます。このパケットID生成に関する他の考慮事項は、[GrDM98]に見出すことができ、[DuGr00]、および[ZsZC01]の検討。
IPFIX data can be used to share information with neighbor providers. A few recommendations should be considered if IPFIX records travel over the public Internet, compared to its usage within a single domain. First of all, security threat levels are higher if data travels over the public Internet. Protection against disclosure or manipulation of data is even more important than for intra-domain usage. Therefore, Transport Layer Security (TLS) or Datagram Transport Layer Security should be used as described in [RFC5101].
IPFIXデータは、隣接プロバイダと情報を共有するために使用することができます。 IPFIXレコードが公共のインターネット上で旅行する場合、いくつかの推奨事項は、単一のドメイン内でその使用法に比べて、考慮されるべきです。データは、公衆インターネット上を移動する場合はまず、セキュリティ上の脅威のレベルが高くなっています。データの漏洩や不正操作に対する保護がさらに重要ドメイン内の使用のために超えています。 [RFC5101]に記載されているように、したがって、トランスポート層セキュリティ（TLS）またはデータグラムトランスポート層セキュリティを使用すべきです。
Furthermore, data transfer should be congestion-aware in order to allow untroubled coexistence with other data Flows in public or foreign networks. That means transport over Stream Control Transmission Protocol (SCTP) or TCP is required.
また、データ転送は、輻輳対応他のデータとuntroubled共存パブリックまたは外部ネットワークに流れることを可能にするためであるべきです。これは、ストリーム制御伝送プロトコル（SCTP）またはTCP経由の輸送が必要とされることを意味します。
Some ISPs are still reluctant to share information due to concerns that competing ISPs might exploit network information from neighbor providers to strengthen their own position in the market. Nevertheless, technical needs have already triggered the exchange of data in the past (e.g., exchange of routing information by BGP). The need to provide inter-domain guarantees is one big incentive to increase inter-domain cooperation. The necessity to defend networks against current and future threats (denial-of-service attacks, worm distributions, etc.) will hopefully increase the willingness to exchange measurement data between providers.
一部のISPは、まだ競合するISPは、市場での自分の立場を強化するために、近隣のプロバイダからのネットワーク情報を悪用する可能性があることを懸念による情報の共有に消極的です。それにもかかわらず、技術的ニーズは既に過去のデータの交換を誘発した（例えば、BGPによりルーティング情報の交換）。ドメイン間の保証を提供する必要性は、ドメイン間の連携を高めるために一つの大きな動機です。現在および将来の脅威からネットワークを守るために必要（など、サービス拒否攻撃、ワームの分布は、）うまくいけば、プロバイダ間の測定データを交換する意欲を高めます。
The IPFIX protocol is used to transport Flow and packet information to provide the input for the calculation of a variety of metrics (e.g., for QoS validation or attack detection). IPFIX can also be used to transfer these metrics directly, e.g., if the metric calculation is co-located with the Metering and Exporting Processes.
IPFIXプロトコルは、メトリック（例えば、QoSの検証や攻撃検出のため）の種々の計算のために入力を提供するために、フローおよびパケット情報を転送するために使用されます。メトリック計算は、計量およびエクスポートプロセスと同じ場所に配置されている場合IPFIXはまた、例えば、直接これらの指標を転送するために使用することができます。
It doesn't matter which measurement and post-processing functions are applied to generate a specific metric. IPFIX can be used to transport the results from passive and active measurements and from post-processing operations. For the reporting of derived metrics, additional Information Elements need to be defined.
計測および後処理機能は、特定のメトリックを生成するために適用されている問題ではありません。 IPFIXは、受動的および能動的測定から後処理操作からの結果を輸送するために使用することができます。派生メトリックの報告のために、追加の情報要素を定義する必要があります。
For most QoS metrics like loss, delay, delay variation, etc., standard IPPM definitions exist. In case such metrics are reported with IPFIX, the IPPM standard definition should be used.
等の損失、遅延、遅延変動、などのほとんどのQoSメトリックの場合は、標準のIPPM定義が存在します。ケースでは、そのようなメトリックはIPFIXで報告され、IPPM標準の定義が使用されるべきです。
The following table shows an overview of the Information Elements required for the target applications described in [RFC3917] (M-mandatory, R-recommended, O-optional).
以下の表は、[RFC3917]（M-必須の、R-推奨、O-オプション）に記載のターゲット・アプリケーションに必要な情報要素の概要を示しています。
| Application | [RFC5102] | [RFC5477] | additional IEs |
+-------------+------------+--------------+-----------------+
| Accounting | M | - | - |
+-------------+------------+--------------+-----------------+
| Traffic | M | O | - |
| Profiling | | | |
+-------------+------------+--------------+-----------------+
| Traffic | M | - | O |
| Engineering | | | (routing info) |
+-------------+------------+--------------+-----------------+
| Attack | M | R | R |
| Detection | | |(derived metrics)|
+-------------+------------+--------------+-----------------+
| QoS | M | M | O |
| Monitoring | |(most metrics)|(derived metrics)|
+-------------+------------+--------------+-----------------+
For accounting, the IEs in [RFC5102] are sufficient. As mentioned above, IPFIX does not conform to the reliability requirements demanded by [RFC2975] for usage-based billing systems (see Section 4.2). For traffic profiling, additional IEs from [RFC5477] can be useful to gain more insight into the traffic. For traffic engineering, Flow information from [RFC5102] is sufficient, but it would profit from routing information, which could be exported by IPFIX. Attack detection usually profits from further insight into the traffic. This can be achieved with IEs from [RFC5477]. Furthermore, the reporting of derived metrics in additional IEs would be useful. Most QoS metrics require the use of IEs from [RFC5477]. IEs from [RFC5477] are also useful for the mapping of results from different Observation Points as described in Section 2.5.1.
会計については、[RFC5102]でのIEで十分です。上述したように、IPFIXは、従量課金システム（セクション4.2を参照）[RFC2975]によって要求信頼性要件に適合しません。トラフィックプロファイリングのために、[RFC5477]から追加のIEは、トラフィックに多くの洞察を得るために有用であり得ます。トラフィックエンジニアリングのために、[RFC5102]からのフロー情報は十分であるが、それはIPFIXによってエクスポートすることができ、ルーティング情報、から利益でしょう。攻撃の検出は、通常、トラフィックへのさらなる洞察から利益を。これは[RFC5477]からのIEを用いて達成することができます。さらに、追加のIEでの派生メトリックの報告は有用であろう。ほとんどのQoSメトリックは、[RFC5477]からのIEを使用する必要があります。セクション2.5.1に記載したように[RFC5477]からIEは、異なる観察点からの結果のマッピングのために有用です。
From the beginning, IPFIX has been designed for IPv4 and IPv6. Therefore, IPFIX can be used in IPv4 and IPv6 networks without limitations. The usage of IPFIX in IPv6 networks has two aspects:
当初から、IPFIXは、IPv4とIPv6のために設計されています。したがって、IPFIXは、制限なく、IPv4とIPv6ネットワークで使用することができます。 IPv6ネットワークでのIPFIXの使用は、2つの側面があります。
- Generation and reporting of IPFIX records about IPv6 traffic - Exporting IPFIX records over IPv6
- 世代およびIPv6トラフィックに関するIPFIXレコードの報告 - IPv6の上IPFIXレコードのエクスポート
The generation and reporting of IPFIX records about IPv6 traffic is possible. Appropriate Information Elements for the reporting of IPv6 traffic are defined in [RFC5102]. Exporting IPFIX records over IPv6 is not explicitly addressed in [RFC5101]. Since IPFIX runs over a transport protocol (SCTP, PR-SCTP, UDP, or TCP) and all potential IPFIX transport protocols can run in IPv6 networks, one just needs to provide the chosen transport protocol in the IPv6 network to run IPFIX over IPv6.
IPv6トラフィックに関するIPFIXレコードの生成と報告が可能です。 IPv6トラフィックの報告のための適切な情報要素は[RFC5102]で定義されています。 IPv6の上IPFIXレコードをエクスポートするには、明示的に[RFC5101]で扱われていません。 IPFIXので、トランスポートプロトコル（SCTP、PR-SCTP、UDP、またはTCP）上で実行され、すべての潜在的なIPFIXのトランスポートプロトコルは、IPv6ネットワークで実行することができ、一つはただのIPv6上でIPFIXを実行するために、IPv6ネットワークで選択されたトランスポートプロトコルを提供する必要があります。
PSAMP defines packet selection methods, their configuration at routers and probes, and the reporting of packet information.
PSAMPは、パケットの選択方法、ルータおよびプローブでその構成、及びパケット情報の報告を規定します。
PSAMP uses IPFIX as a basis for exporting packet information [RFC5476]. [RFC5477] describes further Information Elements for exporting packet information and reporting configuration information.
PSAMPは、パケット情報[RFC5476]をエクスポートするための基礎としてIPFIXを使用します。 [RFC5477]はパケット情報をエクスポートし、設定情報を報告するために更なる情報要素について説明します。
The main difference between IPFIX and PSAMP is that IPFIX addresses the export of Flow Records, whereas PSAMP addresses the export of packet records. Furthermore, PSAMP explicitly addresses remote configuration. It defines a MIB for the configuration of packet selection processes. Remote configuration is not (yet) addressed in IPFIX, but one could consider extending the PSAMP MIB to also allow configuration of IPFIX processes.
IPFIXとPSAMPの主な違いは、PSAMPは、パケットレコードのエクスポートを扱うのに対し、IPFIXは、フローレコードの輸出を扱っていることです。さらに、PSAMPは、明示的にリモート設定に対応しています。これは、パケット選択プロセスの構成のためのMIBを定義します。リモート構成は（まだ）ないIPFIXで対処、しかし、1つはまた、IPFIXプロセスの設定を可能にPSAMP MIBを拡張考えることができます。
Remote Monitoring (RMON) [RFC3577] is a widely used monitoring system that gathers traffic data from RMON Agents in network devices. One major difference between RMON and IPFIX is that RMON uses SNMP for data export, whereas IPFIX defines its own push-oriented protocol. RMON defines MIBs that contain the information to be exported. In IPFIX, the data to be exported is defined as Information Elements.
リモートモニタリング（RMON）[RFC3577]は、ネットワークデバイスにRMONエージェントからのトラフィック・データを収集広く使用されている監視システムです。 RMONとIPFIXとの間の1つの大きな違いは、IPFIXは、独自のプッシュ指向のプロトコルを定義するのに対し、RMONは、データエクスポート用にSNMPを使用していることです。 RMONは、エクスポートされる情報が含まれているMIBを定義します。 IPFIXでは、エクスポートされるデータは、情報要素として定義されます。
The most relevant MIBs for comparison with IPFIX are the Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. The APM-MIB has a complex system for tracking user application performance, with reporting about transactions and SLA threshold notification-trigger configuration, and persistence across DHCP lease expirations. It requires a full RMON2-MIB protocolDirTable implementation.
IPFIXとの比較のために最も関連のMIBは、アプリケーションのパフォーマンス測定MIB（APM-MIB）[RFC3729]とトランスポート・パフォーマンス・メトリックMIB（TPM-MIB）[RFC4150]です。 APM-MIBは、DHCPリース満了横切ってトランザクションとSLAしきい値通知トリガ構成、および持続性について報告して、ユーザアプリケーションのパフォーマンスを追跡するための複雑なシステムを有します。これは、完全なRMON2-MIB protocolDirTableの実装が必要です。
The APM-MIB reports the performance of transactions. A transaction is a service-oriented term and describes the data exchange from the transaction start (when a user requests a service) until its completion. The performance parameters include response times, throughput, streaming responsiveness, and availability of services.
APM-MIBは、トランザクションのパフォーマンスを報告します。トランザクションは、サービス指向の用語であり、その完了までの取引開始からのデータ交換を（ユーザがサービスを要求した場合）について説明します。性能パラメータは、応答時間、スループット、ストリーミング応答性、およびサービスの可用性があります。
The RMON transaction concept differs from the IPFIX Flow concept. A Flow is a very generic term that allows one to group IP packets in accordance with common properties. In contrast to this, the term transaction is service-oriented and contains all data exchange required for service completion.
RMONトランザクションのコンセプトは、IPFIXフロー概念とは異なります。フローは、共通の性質に応じてグループのIPパケットに1を可能にする非常に一般的な用語です。これとは対照的に、長期的な取引は、サービス指向であり、サービスの完了に必要なすべてのデータ交換が含まれています。
In order to report such data with IPFIX, one would probably need a specific combination of multiple Flows and the ability to map those to the transaction. Due to the service-oriented focus of APM, the required metrics also differ. For instance, the RMON APM requires a metric for the responsiveness of services. Such metrics are not addressed in IPFIX.
IPFIXと、このようなデータを報告するためには、おそらく、複数のフローの特定の組み合わせとの取引にそれらをマッピングする機能が必要になります。 APMのサービス指向焦点のため、必要な測定基準も異なります。たとえば、RMON APMは、サービスの応答性のメトリックが必要です。このようなメトリックは、IPFIXで対処されていません。
Furthermore, the APM-MIB allows the configuration of the transaction type to be monitored, which is currently not addressed in IPFIX.
さらに、APM-MIBは現在IPFIXで対処されていない、トランザクションタイプの構成を監視することを可能にします。
The APM MIB could be considered as an extension of the IPFIX Metering Process where the application performance of a combination of multiple Flows is measured. If appropriate, IEs would be defined in the IPFIX information model and the IPFIX Device would support the APM MIB data collection, the solutions could be complementary. That means one could use IPFIX to export APM MIB transaction information.
APM MIBは、複数のフローの組み合わせのアプリケーションのパフォーマンスが測定されるIPFIX計量プロセスの拡張とみなすことができます。適切な場合、IEはIPFIX情報モデルで定義されることになると、APM MIBデータの収集をサポートするIPFIXデバイスは、ソリューションが補完的である可能性があります。それは1つがAPM MIBのトランザクション情報をエクスポートするIPFIXを使用することができますを意味します。
The TPM-MIB breaks out the APM-MIB transactions into sub-application level transactions. For instance, a web request is broken down into DNS, TCP, and HTTP sub-transactions. Such sub-transactions can be considered as bidirectional Flows. With an appropriate Flow definition and the ability to map both directions of a Flow (see Section 4.6), one could measure and report Flow characteristics of such sub-application level transaction with IPFIX.
TPM-MIBは、サブアプリケーションレベルのトランザクションにAPM-MIBの取引を勃発します。たとえば、Web要求はDNS、TCP、およびHTTPのサブトランザクションに分割されます。そのようなサブトランザクションは、双方向フローとして考えることができます。適切なフロー定義とフローの両方の方向をマッピングする機能（セクション4.6を参照）と、一方がIPFIXこのようなサブアプリケーションレベルのトランザクションの特性を測定し、報告フローができました。
The TPM-MIB requires APM-MIB and RMON2-MIB.
TPM-MIBは、APM-MIBおよびRMON2-MIBが必要です。
The IPFIX protocol can be used to carry IPPM network performance metrics or information that can be used to calculate those metrics (see Sections 2.5 and 2.7 for details and references).
IPFIXプロトコルは（セクション2.5および詳細および参照の2.7を参照）、これらのメトリックを計算するために使用することができるIPPMネットワーク性能メトリクスまたは情報を運ぶために使用することができます。
AAA defines a protocol and architecture for authentication, authorization, and accounting for service usage [RFC2903]. The DIAMETER protocol [RFC3588] is used for AAA communication, which is needed for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending AAA support to other services. DIAMETER defines the exchange of messages between AAA entities, e.g., between AAA clients at access devices and AAA servers, and among AAA servers. DIAMETER is used for the transfer of accounting records. In order to form accounting records for usage-based accounting measurement, data from the network is required. IPFIX defines a protocol to export such data from routers, measurement probes, and other devices. Therefore, it looks promising to connect those two architectures.
AAAは、サービス利用[RFC2903]のための認証、許可、およびアカウンティングのためのプロトコルおよびアーキテクチャを定義します。 DIAMETERプロトコル[RFC3588]は、ネットワーク・アクセス・サービス（モバイルIP、NASREQ、及びROAMOPS）のために必要とされるAAAの通信に使用されます。 AAAアーキテクチャ[RFC2903]は、他のサービスにAAAサポートを拡張するためのフレームワークを提供します。 DIAMETERは、例えば、アクセスデバイスでのAAAクライアントとAAAサーバの間、およびAAAサーバ間で、AAAエンティティ間のメッセージの交換を定義します。 DIAMETERは、会計記録の転送に使用されます。従量課金測定用アカウンティングレコードを形成するために、ネットワークからのデータが必要です。 IPFIXは、ルータ、測定プローブ、および他のデバイスからそのようなデータをエクスポートするためのプロトコルを定義します。したがって、これらの二つのアーキテクチャを接続するために有望に見えます。
For all scenarios described here, one has to keep in mind that IPFIX does not conform to the reliability requirements for usage-based billing described in [RFC2975] (see Section 4.2). Using IPFIX without reliability extensions together with AAA would result in accounting scenarios that do not conform to usage-based billing requirements described in [RFC2975].
ここに記載されているすべてのシナリオでは、1はIPFIXは、[RFC2975]で説明使用量ベースの課金のための信頼性要件に準拠していないことを心に留めておく必要があります（セクション4.2を参照してください）。 AAAと一緒に、信頼性の拡張子なしIPFIXを使用すると、[RFC2975]で説明使用量ベースの課金の要件に準拠していない会計のシナリオにつながります。
As shown in Section 2.1, accounting applications can directly incorporate an IPFIX Collecting Process to receive IPFIX records with information about the transmitted volume. Nevertheless, if a AAA infrastructure is in place, the cooperation between IPFIX and AAA provides many valuable synergistic benefits. IPFIX records can provide the input for AAA accounting functions and provide the basis for the generation of DIAMETER accounting records. However, as stated in Section 4.2, the use of IPFIX as described in [RFC5101] is currently limited to situations where the purpose of the accounting does not require reliability.
セクション2.1に示されているように、会計アプリケーションに直接送信容量に関する情報をIPFIXレコードを受信するようにIPFIX収集プロセスを組み込むことができます。 AAAインフラが整備されている場合にもかかわらず、IPFIXとAAAとの協力は、多くの貴重な相乗的な利点を提供します。 IPFIXレコードは、AAAアカウンティング機能のための入力を提供し、DIAMETERのアカウンティングレコードの生成のための基礎を提供することができます。セクション4.2で述べたようしかし、[RFC5101]に記載されているようにIPFIXの使用は、現在の会計の目的は、信頼性を必要としない状況に限定されています。
Further potential features include the mapping of a user ID to Flow information (by using authentication information) or using the secure authorized exchange of DIAMETER accounting records with neighbor domains. The last feature is especially useful in roaming scenarios where the user connects to a foreign network and the home provider generates the invoice.
さらに潜在的機能はまたは隣接ドメインとDIAMETERアカウンティングレコードの安全な許可交換を使用して、（認証情報を使用して）情報を流すためのユーザIDのマッピングを含みます。最後の機能は、ユーザーが外部ネットワークに接続し、自宅のプロバイダが請求書を生成したシナリオをローミングに特に有用です。
Coupling an IPFIX Collecting Process with AAA functions also has high potential for intrusion and attack detection. AAA controls network access and maintains data about users and nodes. AAA functions can help to identify the source of malicious traffic. Authorization functions are able to deny access to suspicious users or nodes. Therefore, coupling those functions with an IPFIX Collecting Process can provide an efficient defense against network attacks.
AAA機能を収集処理IPFIXを結合することも侵入や攻撃検出のための高い可能性を有します。 AAAは、ネットワークアクセスを制御し、ユーザーやノードに関するデータを保持します。 AAA機能は、悪意のあるトラフィックの送信元を識別するのに役立ちます。認証機能は、不審なユーザーやノードへのアクセスを拒否することができます。したがって、IPFIX収集プロセスとそれらの機能を結合することは、ネットワーク攻撃に対する効率的な防御を提供することができます。
Sharing IPFIX records (either directly or encapsulated in DIAMETER) with neighbor providers allows an efficient inter-domain attack detection. For this, it would be useful to allow remote configuration of measurement and record generation in order to provide information in the required granularity and accuracy. Since remote configuration is currently not addressed in IPFIX, this would require additional work. The AAA infrastructure itself may be used to configure measurement functions in the network as proposed in [RFC3334].
隣人プロバイダーとIPFIXレコードを（直接またはDIAMETERにカプセル化）共有することで、効率的なドメイン間の攻撃を検出することができます。このため、必要な精度と正確さの情報を提供するために測定及び記録世代の遠隔構成を可能にするのに有用であろう。リモート設定が現在IPFIXで対処されていないので、これは追加の作業が必要になります。 [RFC3334]で提案されているようにAAAインフラストラクチャ自体は、ネットワーク内の測定機能を設定するために使用することができます。
Furthermore, the transport of IPFIX records with DIAMETER would require the translation of IPFIX Information Elements into DIAMETER attribute value pairs (AVPs) defined in [RFC3588]. Since the DIAMETER AVPs do not comprise all IPFIX Information Elements, it is necessary to define new AVPs to transport them over DIAMETER.
さらに、直径IPFIXレコードの輸送は、[RFC3588]で定義されたDIAMETER属性値ペア（AVPの）にIPFIX情報要素の翻訳を必要とします。 DIAMETERのAVPのは、すべてのIPFIX情報要素を含んでいないので、DIAMETERの上にそれらを輸送するために新しいAVPを定義する必要があります。
Two possibilities exist to connect IPFIX and AAA:
二つの可能性がIPFIXとAAAを接続するために存在します。
- Connecting via a AAA Client - Connecting via an Application Specific Module (ASM)
- AAAクライアントを介して接続 - アプリケーション固有モジュール（ASM）を介して接続
Both are explained in the following sections. The approaches only require a few additional functions. They do not require any changes to IPFIX or DIAMETER.
どちらも、次のセクションで説明されています。アプローチはいくつかの追加機能が必要になります。彼らは、IPFIXまたはDIAMETERを変更する必要はありません。
One possibility of connecting IPFIX and AAA is to run a AAA client on the IPFIX Collector. This client can generate DIAMETER accounting messages and send them to a AAA server. The mapping of the Flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g., in roaming scenarios).
IPFIXとAAAを接続する一つの可能性はIPFIXコレクターにAAAクライアントを実行することです。このクライアントは、DIAMETERアカウンティングメッセージを生成し、AAAサーバに送信することができます。ユーザーIDにフロー情報のマッピングは、認証プロセスからのデータを使用して、AAAサーバで行うことができます。 DIAMETERアカウンティングメッセージは、会計アプリケーション、または他のAAAサーバ（例えば、ローミングのシナリオで）に送信することができます。
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 1: IPFIX Collector connects to AAA server via AAA client
図1：IPFIXコレクターは、AAAクライアント経由でAAAサーバに接続します
Another possibility is to directly connect the IPFIX Collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case, the IPFIX Collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA servers.
別の可能性は、直接アプリケーション固有モジュール（ASM）を介してAAAサーバとIPFIXコレクタを接続することです。特定用途向けモジュールは、[RFC2903]にIRTFのAAAアーキテクチャ研究グループ（AAARCH）によって提案されています。彼らは、AAAサーバとサービス機器間のインタフェースとして機能します。この場合、IPFIXコレクターは、ASMの一部です。 ASMは、IPFIXプロトコルとAAAサーバの入力インタフェースとの間のインタフェースとして機能します。 ASMは、AAAサーバに適したフォーマットに受け入れIPFIXデータを変換します。 AAAサーバは、ユーザIDに関する情報を追加して、DIAMETERアカウンティングレコードを生成することができます。このアカウンティングレコードは、会計アプリケーションや他のAAAサーバに送信することができます。
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 2: IPFIX connects to AAA server via ASM
図2：IPFIXはASMを介してAAAサーバに接続します
The Realtime Traffic Flow Measurement (RTFM) working group defined an architecture for Flow measurement [RFC2722]. This section compares the RTFM framework with the IPFIX framework.
リアルタイム交通流計測（RTFM）ワーキンググループは、流量測定[RFC2722]のためのアーキテクチャを定義しました。このセクションでは、IPFIXフレームワークとRTFMフレームワークを比較します。
The RTFM architecture [RFC2722] is very similar to the IPFIX architecture. It defines meter, meter reader, and a manager as building blocks of the measurement architecture. The manager configures the meter, and the meter reader collects data from the meter. In RTFM, the building blocks communicate via SNMP.
RTFMアーキテクチャ[RFC2722]はIPFIXアーキテクチャに非常に類似しています。これは、測定アーキテクチャのビルディングブロックとして計、メータリーダ、およびマネージャを定義します。マネージャは、計器を構成し、メーター読者は、メータからデータを収集します。 RTFMでは、ビルディングブロックは、SNMPを介して通信します。
The IPFIX architecture [RFC5470] defines Metering, Exporting, and Collecting Processes. IPFIX speaks about processes instead of devices to clarify that multiple of those processes may be co-located on the same machine.
IPFIXアーキテクチャ[RFC5470]は測光、エクスポート、および収集プロセスを定義します。 IPFIXは、プロセスの代わりに、それらのプロセスの複数が同じマシン上で同じ場所に配置することができることを明確にする装置について話します。
These definitions do not contradict each other. One could see the Metering Process as part of the meter, and the Collecting Process as part of the meter reader.
これらの定義は互いに矛盾していません。一つは、計器の一部、及びメータ読取装置の一部として収集プロセスとして計量プロセスを見ることができます。
One difference is that IPFIX currently does not define a managing process because remote configuration was (at least initially) out of scope for the working group.
一つの違いは、リモート構成は、（少なくとも最初は）ワーキンググループの範囲外であったためIPFIXが現在管理プロセスを定義していないことです。
RTFM and IPFIX both consider Flows as a group of packets that share a common set of properties. A Flow is completely specified by that set of values, together with a termination criterion (like inactivity timeout).
RTFMとIPFIXは、両方のプロパティの共通セットを共有するパケットのグループとして流れるを検討してください。流れが完全に（非活動タイムアウトなど）終了基準と共に、値のセットによって指定されます。
A difference is that RTFM defines Flows as bidirectional. An RTFM meter matches packets from B to A and A to B as separate parts of a single Flow, and it maintains two sets of packet and byte counters, one for each direction.
違いはRTFMが双方向としてフローを定義することです。 RTFMメーターは単一のフローの別個の部品としてBにAをBとAからのパケットと一致し、それは、パケットおよびバイトカウンタを、各方向に1つの二組を維持します。
IPFIX does not explicitly state whether Flows are uni- or bidirectional. Nevertheless, Information Elements for describing Flow properties were defined for only one direction in [RFC5102]. There are several solutions for reporting bidirectional Flow information (see Section 4.6).
IPFIXは、明示的にフローがユニまたは双方向であるかどうかを述べるものではありません。それにもかかわらず、流動性を記述するための情報要素は[RFC5102]で一方向のみのために定義されました。双方向のフロー情報を報告するためのいくつかのソリューションは、（4.6節を参照）があります。
In RTFM, remote configuration is the only way to configure a meter. This is done by using SNMP and a specific Meter MIB [RFC2720]. The IPFIX group currently does not address IPFIX remote configuration.
RTFMでは、リモート設定はメーターを設定するための唯一の方法です。これは、SNMPおよび特定のメーターMIB [RFC2720]を使用して行われます。 IPFIXグループは、現在、IPFIXリモート設定に対応していません。
IPFIX Metering Processes export the layout of data within their Templates, from time to time. IPFIX Collecting Processes use that Template information to determine how they should interpret the IPFIX Flow data they receive.
IPFIX計量プロセスは、随時、そのテンプレート内のデータのレイアウトをエクスポートします。プロセスを収集IPFIXは、彼らが受け取るIPFIXフローデータをどのように解釈すべきかを決定するためにそのテンプレートの情報を使用しています。
One major difference between IPFIX and RTFM is the data collection model. RTFM retrieves data in pull mode, whereas IPFIX uses a push mode model to send data to Collecting Processes.
IPFIXとRTFMとの間の1つの大きな違いは、データ収集モデルです。 IPFIXは収集プロセスにデータを送信するためにプッシュ・モード・モデルを使用し、一方RTFMは、プルモードでデータを取得します。
An RTFM meter reader pulls data from a meter by using SNMP. SNMP security on the meter determines whether a reader is allowed to pull data from it. An IPFIX Exporting Process is configured to export records to a specified list of IPFIX Collecting Processes. The condition of when to send IPFIX records (e.g., Flow termination) has to be configured in the Exporting or Metering Process.
RTFMメーターリーダーは、SNMPを使って計からデータを取得します。メーターのSNMPセキュリティは、リーダーがそれからデータを取得することが許可されているかどうかを決定します。 IPFIXエクスポートプロセスは、プロセスを収集IPFIXの指定されたリストにレコードをエクスポートするよう構成されています。 IPFIXレコード（例えば、フローターミネーション）を送信する場合の条件は、エクスポートまたは計量プロセスで構成されなければなりません。
RTFM defines all its attributes in the RTFM Meter MIB [RFC2720]. IPFIX Information Elements are defined in [RFC5102].
RTFMはRTFMメーターMIB [RFC2720]ですべての属性を定義します。 IPFIX情報要素は[RFC5102]で定義されています。
RTFM uses continuously-incrementing 64-bit counters for the storage of the number of packets of a Flow. The counters are never reset and just wrap back to zero if the maximum value is exceeded. Flows can be read at any time. The difference between counter readings gives the counts for activity in the interval between readings.
RTFMは、フローのパケット数を格納するために連続的にインクリメント64ビットカウンタを使用します。カウンタはリセットされず、単に最大値を超えた場合は、ゼロに戻ってラップありません。フローは、いつでも読むことができます。カウンタの読みの違いは、測定値の間の間隔での活動のためのカウントを提供します。
IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [RFC5102]. The totalCounter is never reset and just wraps to zero if values are too large, exactly as the counters used in RTFM. The deltaCounter is reset to zero when the associated Flow Record is exported.
IPFIXは、絶対（totalCounter）及び相対カウンタ（deltaCounter）[RFC5102]を可能にします。 totalCounterは正確にRTFMに使用されるカウンタとして、リセットされず、ただ値が大きすぎる場合は、ゼロにラップありません。 deltaCounterは、関連するフローレコードがエクスポートされたときにゼロにリセットされます。
RTFM has a Standards-Track Meter MIB [RFC2720], which is used both to configure a meter and to store metering results. The MIB provides a way to read lists of attributes with a single Object Identifier (called a 'package'), which reduces the SNMP overhead for Flow data collection. SNMP, of course, normally uses UDP as its transport protocol. Since RTFM requires a reliable Flow data transport system, an RTFM meter reader must time out and resend unanswered SNMP requests. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader.
RTFMメーターを設定し、計量結果を格納するための両方に使用される標準トラックメーターMIB [RFC2720]を有します。 MIBは、フローデータ収集のためのSNMPのオーバーヘッドを削減（「パッケージ」と呼ばれる）、単一のオブジェクト識別子と属性のリストを読み込むための方法を提供します。 SNMPは、当然のことながら、通常、そのトランスポートプロトコルとしてUDPを使用しています。 RTFMは、信頼性の高いフローデータ転送システムを必要とするので、RTFMメーターリーダーはタイムアウトして未解決のSNMP要求を再送信する必要があります。離れ不器用であるから、これはメーターからメーター読者に最大データ転送速度を制限することができます。
IPFIX is designed to work over a variety of different transport protocols. SCTP [RFC4960] and PR-SCTP [RFC3758] are mandatory. UDP and TCP are optional. In addition, the IPFIX protocol encodes data much more efficiently than SNMP does, hence IPFIX has lower data transport overheads than RTFM.
IPFIXは、異なるトランスポートプロトコルのさまざまなオーバー動作するように設計されています。 SCTP [RFC4960]とPR-SCTP [RFC3758]は必須です。 UDPとTCPはオプションです。また、IPFIXプロトコルは、はるかに効率的にSNMPをよりもデータを符号化し、それゆえIPFIXはRTFMより低いデータ転送オーバーヘッドを有しています。
IPFIX exports Flow information in a push model by using SCTP, TCP, or UDP. It currently does not address remote configuration. RTFM data collection is using the pull model and runs over SNMP. RTFM addresses remote configuration, which also runs over SNMP. Both frameworks allow a very flexible Flow definition, although RTFM is based on a bidirectional Flow definition.
IPFIXはSCTP、TCP、またはUDPを使用して、プッシュモデルでフロー情報をエクスポートします。これは、現在のリモート設定に対応していません。 RTFMデータ収集は、SNMP経由プルモデルと実行を使用しています。 RTFMはまた、SNMP上で実行するリモートコンフィギュレーションを、対応しています。 RTFMが双方向フロー定義に基づいているが、両方のフレームワークは、非常に柔軟なフロー定義を可能にします。
The goal of this section is to show the limitations of IPFIX and to give advice where not to use IPFIX or in which cases additional considerations are required.
このセクションの目標は、IPFIXの限界を示すこととIPFIXを使用するか、追加の考慮が必要とされている場合はしないように助言を与えることです。
IPFIX provides a generic export mechanism. Due to its Template-based structure, it is a quite flexible protocol. Network operators and users may want to use it for other applications than those described in [RFC3917].
IPFIXは、一般的な輸出メカニズムを提供します。 、そのテンプレートベース構造に、それは非常に柔軟なプロトコルです。ネットワークオペレータおよびユーザーは、[RFC3917]に記載されているもの以外の用途のためにそれを使用することをお勧めします。
Apart from sending raw Flow information, it can be used to send per-packet data, aggregated or post-processed data. For this, new Templates and Information Elements can be defined if needed. Due to its push mode operation, IPFIX is also suited to send network initiated events like alarms and other notifications. It can be used for exchanging information among network nodes to autonomously improve network operation.
別に生のフロー情報を送信するから、パケットごとのデータ、集計またはポスト処理されたデータを送信するために使用することができます。必要に応じて、このために、新しいテンプレートと情報要素を定義することができます。そのプッシュモード動作のために、IPFIXは、アラームや他の通知などのイベントを開始し、ネットワークを送信するのに適しています。これは、自律的にネットワークの動作を改善するために、ネットワークノード間で情報を交換するために使用することができます。
Nevertheless, the IPFIX design is based on the requirements that originate only from the target applications stated in [RFC3917]. Using IPFIX for other purposes requires a careful checking of IPFIX capabilities against application requirements. Only with this, one can decide whether IPFIX is a suitable protocol to meet the needs of a specific application.
それにも関わらず、IPFIXのデザインは、[RFC3917]に記載されたターゲット・アプリケーションからのみ発生要件に基づいています。他の目的のためにIPFIXを使用すると、アプリケーションの要件に対してIPFIX能力を慎重にチェックする必要があります。これだけで、一つはIPFIXは、特定のアプリケーションのニーズを満たすために適切なプロトコルであるかどうかを決定することができます。
The reliability requirements defined in [RFC3917] are not sufficient to guarantee the level of reliability that is needed for usage-based billing systems as described in [RFC2975]. In particular, IPFIX does not support the following features required by [RFC2975]:
[RFC3917]で定義された信頼性要件は、[RFC2975]に記載されているように従量課金システムに必要とされる信頼性のレベルを保証するのに十分ではありません。特に、IPFIXは、[RFC2975]で必要な次の機能をサポートしていません。
- Record loss: IPFIX allows the usage of different transport protocols for the transfer of data records. Resilience against the loss of IPFIX data records can be only provided if TCP or SCTP is used for the transfer of data records.
- レコード損失：IPFIXは、データレコードの転送のためのさまざまなトランスポートプロトコルの使用を可能にします。 TCPまたはSCTPは、データレコードの転送に使用されている場合IPFIXデータレコードの損失に対する弾力性にのみ提供することができます。
- Network or device failures: IPFIX does allow the usage of multiple Collectors for one Exporter, but it neither specifies nor demands the use of multiple Collectors for the provisioning of fault tolerance.
- ネットワークやデバイスの故障：IPFIXは1つの輸出業者のために複数のコレクターの使用を許可しませんが、それは指定しないでもフォールトトレランスのプロビジョニングのために複数のコレクターの使用を要求し、どちらも。
- Detection and elimination of duplicate records: This is currently not supported by IPFIX.
- 重複レコードの検出と除去：これは、現在IPFIXによってサポートされていません。
- Application layer acknowledgements: IPFIX does not support the control of measurement and Exporting Processes by higher-level applications. Application layer acknowledgements are necessary, e.g., to inform the Exporter in case the application is not able to process the data exported with IPFIX. Such acknowledgements are not supported in IPFIX.
- アプリケーション層肯定応答：IPFIXは、より高いレベルのアプリケーションによる測定の制御およびエクスポートプロセスをサポートしません。アプリケーション層肯定応答は、アプリケーションがIPFIXとエクスポートされたデータを処理することができない場合に輸出を通知するために、例えば、必要です。このような確認応答は、IPFIXではサポートされていません。
Further features like archival accounting and pre-authorization are out of scope of the IPFIX specification but need to be realized in billing system architectures as described in [RFC2975].
アーカイブ会計および事前承認様さらなる特徴は、IPFIX仕様の範囲外であるが、[RFC2975]に記載されるように課金システムのアーキテクチャで実現される必要があります。
SCTP is the preferred protocol for IPFIX, i.e., a conforming implementation must work over SCTP. Although IPFIX can also work over TCP or UDP, both protocols have drawbacks [RFC5101]. Users should make sure they have good reasons before using protocols other than SCTP in a specific environment.
SCTPは、IPFIXのための好ましいプロトコルである、すなわち、適合実装は、SCTP上に働かなければなりません。 IPFIXはまた、TCPやUDP上で動作することができますが、両方のプロトコルには欠点[RFC5101]を持っています。ユーザーは、特定の環境でSCTP以外のプロトコルを使用する前に十分な理由を持っていることを確認しなければなりません。
IPFIX works in push mode. That means IPFIX records are automatically exported without the need to wait for a request. The responsibility for initiating a data export lies with the Exporting Process.
IPFIXは、プッシュモードで動作します。それはIPFIXのレコードが自動的にリクエストを待つ必要なしに輸出されていることを意味します。データのエクスポートを開始するための責任は、エクスポートプロセスです。
Criteria for exporting data need to be configured at the Exporting Process. Therefore, push mode has more benefits if the trigger for data export is related to events at the Exporting Process (e.g., Flow termination, memory shortage due to large amount of Flows, etc.). If the protocol used pull mode, the Exporting Process would need to wait for a request to send the data. With push mode, it can send data immediately, e.g., before memory shortage would require a discarding of data.
データをエクスポートするための基準は、エクスポートプロセスで設定する必要があります。データのエクスポートのためにトリガがエクスポートプロセスでイベントに関連している場合したがって、プッシュモード（例えば、フロー終了等による流れの大量に、メモリ不足の）より多くの利益を有しています。プロトコルがプルモードを使用した場合、エクスポートプロセスは、データを送信するための要求を待つ必要があるだろう。メモリ不足がデータの破棄を必要とする前に、プッシュモードでは、それは、例えば、すぐにデータを送信することができます。
With push mode, one can prevent the overloading of resources at the Exporting Process by simply exporting the information as soon as certain thresholds are about to be exceeded. Therefore, exporting criteria are often related to traffic characteristics (e.g., Flow timeout) or resource limitations (e.g., size of Flow cache). However, traffic characteristics are usually quite dynamic and often impossible to predict. If they are used to trigger Flow export, the exporting rate and the resource consumption for Flow export becomes variable and unpredictable.
プッシュモードでは、1はすぐに特定のしきい値を超えれようとしているとして、単に情報をエクスポートすることにより、エクスポートプロセスでリソースの過負荷を防ぐことができます。したがって、輸出基準は、多くの場合、トラフィック特性に関連している（例えば、フロータイムアウト）またはリソースの制限（例えば、フローキャッシュのサイズ）。しかし、トラフィック特性は、通常、非常にダイナミックで予測することはしばしば不可能です。それらはフローエクスポートをトリガーするために使用されている場合は、エクスポート率とフローの輸出のためのリソース消費量は変数と予測不可能になります。
Pull mode has advantages if the trigger for data export is related to events at the Collecting Process (e.g., a specific application requests immediate input).
データのエクスポートのためにトリガが収集プロセス（例えば、特定のアプリケーションの要求即時入力）でイベントに関連している場合、プル・モードは、利点を有します。
In a pull mode, a request could simply be forwarded to the Exporting Process. In a push mode, the exporting configuration must be changed to trigger the export of the requested data. Furthermore, with pull mode, one can prevent the overloading of the Collecting Process by the arrival of more records than it can process.
プルモードでは、要求は、単にエクスポートプロセスに転送することができます。プッシュモードでは、エクスポートする構成が要求されたデータのエクスポートをトリガーするために変更する必要があります。また、引張りモードで、一つは、それが処理できるよりも多くのレコードの到着によって収集プロセスの過負荷を防止することができます。
Whether this is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented.
これは、関連する欠点であるかどうかは、IPFIX構成の柔軟性に依存し、IPFIXの構成規則がどのように実装されています。
The IPFIX specification limits the different Template ID numbers that can be assigned to the newly generated Template records in an Observation Domain. In particular, Template IDs up to 255 are reserved for Template or option sets (or other sets to be created) and Template IDs from 256 to 65535 are assigned to data sets. In the case of many exports requiring many different Templates, the set of Template IDs could be exhausted.
IPFIX仕様は観測ドメインに新たに生成されたテンプレートレコードに割り当てることができる異なるテンプレートID番号を制限します。具体的には、テンプレートIDは255までの256から65535にテンプレートまたはオプションセット（または作成する他のセット）とテンプレートIDのために予約されているデータ・セットに割り当てられています。多くの異なるテンプレートを必要とする多くの輸出の場合には、テンプレートIDのセットを排出することができます。
Although IPFIX does not explicitly state that Flows are unidirectional, Information Elements that describe Flow characteristics are defined only for one direction in [RFC5102]. [RFC5101] allows the reporting of multiple identical Information Elements in one Flow Record. With this, Information Elements for forward and reverse directions can be reported in one Flow Record.
IPFIXは、明示的にフローが単方向であることを述べる、情報要素流量特性を記述しているものではないが唯一[RFC5102]で一つの方向のために定義されています。 [RFC5101]は1フローレコード内に複数の同一の情報要素の報告を可能にします。これにより、前進方向と逆方向のための情報要素は、1フローレコードで報告することができます。
However, this is not sufficient. Using this feature for reporting bidirectional Flow information would require an agreement on the semantics of Information Elements (e.g., first counter is the counter for the forward direction, the second counter for the reverse direction).
しかし、これは十分ではありません。情報要素の意味論上の合意を必要とする双方向フロー情報を報告するためにこの機能を使用して（例えば、第1のカウンタは、順方向、逆方向のための第二カウンタのカウンタです）。
Another option is to use two adjacent Flow Records to report both directions of a bidirectional Flow separately. This approach requires additional means for mapping those records and is quite inefficient due to the redundant reporting of Flow Keys.
別のオプションは、別途双方向フローの両方向を報告するために、2つの隣接するフローレコードを使用することです。このアプローチは、それらのレコードをマッピングするための追加の手段を必要とし、原因の流れキーズの冗長報告には非常に非効率的です。
Remote configuration was initially out of scope of the IPFIX working group in order to concentrate on the protocol specification. Therefore, there is currently no standardized way to configure IPFIX processes remotely. Nevertheless, due to the broad need for this feature, it is quite likely that solutions for this will be standardized soon.
リモート設定は、プロトコル仕様に集中するために、最初にIPFIXワーキンググループの範囲外でした。そのため、リモートでIPFIXプロセスを設定するための標準化の方法は現在ありません。それにもかかわらず、この機能の幅広いニーズに起因し、このための解決策はすぐに標準化される可能性が極めて高いです。
This document describes the usage of IPFIX in various scenarios. Security requirements for IPFIX target applications and security considerations for IPFIX are addressed in [RFC3917] and [RFC5101]. Those requirements have to be met for the usage of IPFIX for all scenarios described in this document. To our current knowledge, the usage scenarios proposed in Section 2 do not induce further security hazards.
この文書では、さまざまなシナリオにIPFIXの使用方法について説明します。 IPFIXのためのIPFIXターゲットアプリケーションとセキュリティ上の配慮のためのセキュリティ要件は[RFC3917]と[RFC5101]で扱われています。これらの要件は、本書に記載されているすべてのシナリオのIPFIXの使用のために満たされなければなりません。私たちの現在の知識に、第2節で提案されている使用シナリオは、さらにセキュリティ上の危険を誘発しません。
The threat level to IPIFX itself may depend on the usage scenario of IPFIX. The usage of IPFIX for accounting or attack detection may increase the incentive to attack IPFIX itself. Nevertheless, security considerations have to be taken into account in all described scenarios.
IPIFX自体への脅威レベルは、IPFIXの利用シナリオに依存してもよいです。会計や攻撃検出のためのIPFIXの使用は、IPFIX自身を攻撃するインセンティブを増大させることができます。それにもかかわらず、セキュリティ上の考慮事項が記載されたすべてのシナリオで考慮しなければなりません。
As described in the security considerations in [RFC5101], security incidents can become a threat to IPFIX processes themselves, even if IPIFX is not the target of the attack. If an attack generates a large amount of Flows (e.g., by sending packets with spoofed addresses or simulating Flow termination), Exporting and Collecting Processes may get overloaded by the immense amount of records that are exported. A flexible deployment of packet or Flow sampling methods can be useful to prevent the exhaustion of resources.
[RFC5101]のセキュリティ上の考慮事項で説明したように、セキュリティインシデントはIPIFXが攻撃の対象でない場合であっても、IPFIXへの脅威は、プロセス自体になることができます。攻撃フローを大量に生成する場合（例えば、スプーフィングされたアドレスを持つパケットを送信またはフロー終了をシミュレートすることにより）、エクスポートおよびプロセスを収集エクスポートされたレコードの膨大な量によって過負荷を受けることができます。パケットまたはフローサンプリング法の柔軟な展開は、資源の枯渇を防ぐのに役立ちます。
Section 3 of this document describes how IPFIX can be used in combination with other technologies. New security hazards can arise when two individually secure technologies or architectures are combined. For the combination of AAA with IPFIX, an application specific module (ASM) or an IPFIX Collector can function as a transit point for the messages. One has to ensure that at this point the applied security mechanisms (e.g., encryption of messages) are maintained.
このドキュメントのセクション3は、IPFIXは、他の技術と組み合わせて使用することができる方法を説明します。 2人の個別に安全な技術やアーキテクチャを組み合わせた場合、新たなセキュリティ上の危険が発生する可能性があります。 IPFIXとAAAとの組み合わせのために、アプリケーション固有のモジュール（ASM）またはIPFIXコレクタはメッセージの中継点として機能することができます。一つは、適用されるセキュリティメカニズムが（例えば、メッセージの暗号化）が維持され、この時点でそれを確実にしなければなりません。
We would like to thank the following people for their contributions, discussions on the mailing list, and valuable comments:
我々は彼らの貢献、メーリングリストでの議論、そして貴重なコメントについては、以下の人々に感謝したいと思います：
Sebastian Zander Robert Loewe Reinaldo Penno Lutz Mark Andy Biermann
セバスチャンザンダーロバート・ロエベレイナルドPennoルッツマークアンディビーアマン
Part of the work has been developed in the research project 6QM, co-funded with support from the European Commission.
作品の一部は、欧州委員会からの支援を受けて共同出資、研究プロジェクトの6QMで開発されてきました。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148]ステファン、E.、 "IPパフォーマンス・メトリック（IPPM）メトリクスレジストリ"、BCP 108、RFC 4148、2005年8月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]ディーツ、T.、Claise、B.、エイトケン、P.、ドレスラー、F.、およびG.カール、RFC 5477 "情報モデルパケットサンプリングの輸出について"、2009年3月。
[Brow00] Brownlee, N., "Packet Matching for NeTraMet Distributions", <http://www.caida.org/tools/measurement/ netramet/packetmatching/>.
"パケットマッチング毛皮netramet分布"、オン[BR 00] braunli。<HTTP：vvvsaidaargtulsmessurment netramet / paketamatacing />。
[DuGr00] Duffield, N. and M. Grossglauser, "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.
[DuGr00]ダッフィールド、N.およびM. Grossglauser、 "ノーリファラー観察のための軌道サンプリング"、ACMのSIGCOMM 2000の議事録、ストックホルム、スウェーデン、2000年8月28日から9月1日まで。
[GrDM98] Graham, I., Donnelly, S., Martin, S., Martens, J., and J. Cleary, "Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet", INET'98, Geneva, Switzerland, 21-24 July, 1998.
【GrDM98]グラハム、I.、ドネリー、S.、マーティン、S.、マルテンス、J.、およびJ.クリアリー、「一方向遅延と遅延変動の非侵入と正確な測定インターネット上」、INET'98、ジュネーブスイス、21-24 1998年7月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "一方向IPPMの遅延メトリック"、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMための一方向パケット損失メトリック"、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMのラウンドトリップ遅延メトリック"、RFC 2681、1999年9月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RFC2720]ブラウンリー、N.、 "トラフィックフロー測定：メーターMIB"、RFC 2720、1999年10月。
[RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RFC2722]ブラウンリー、N.、ミルズ、C.、およびG.ルース、 "トラフィックフロー測定：アーキテクチャ"、RFC 2722、1999年10月。
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[RFC2903]デLAAT、C.、グロス、G.、Gommans、L.、Vollbrecht、J.、およびD.スペンス、 "汎用AAAアーキテクチャ"、RFC 2903、2000年8月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba、B.、Arkko、J.、およびD.ハリントン、 "会計管理の概要"、RFC 2975、2000年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC3334] Zseby, T., Zander, S., and C. Carle, "Policy-Based Accounting", RFC 3334, October 2002.
[RFC3334] Zseby、T.、ザンダー、S.、およびC.カール、 "ポリシーベースの会計"、RFC 3334、2002年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]デミチェリス、C.およびP. Chimento、 "IPパフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、RFC 3393、2002年11月。
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003.
[RFC3577] Waldbusser、S.、コール、R.、Kalbfleisch、C.、およびD. Romascanu、 "MIBモジュールのリモートモニタリング（RMON）ファミリーの紹介"、RFC 3577、2003年8月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
[RFC3729] Waldbusser、S.、 "アプリケーションのパフォーマンス測定MIB"、RFC 3729、2004年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4150]ディーツ、R.とR.コール、 "交通パフォーマンス・メトリックMIB"、RFC 4150、2005年8月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、エド。、 "パケットサンプリング（PSAMP）プロトコル仕様"、RFC 5476、2009年3月。
[ZsZC01] Zseby, T., Zander, S., and G. Carle, "Evaluation of Building Blocks for Passive One-way-delay Measurements", Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001
【ZsZC01] Zseby、T.、ザンダー、S.、およびG.カール、「受動的一方向遅延測定のためのビルディング・ブロックの評価」、受動的および能動的測定ワークショップの議事録（2001 PAM）、アムステルダム、オランダ、 4月23-24、2001
Authors' Addresses
著者のアドレス
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 EMail: tanja.zseby@fokus.fraunhofer.de
オープン通信システムのためのターニャZsebyフラウンホーファー研究所（FOKUS）カイザリンオーガスタダレ31 10589ベルリン、ドイツ電話：+49 30 3463 7153 Eメール：tanja.zseby@fokus.fraunhofer.de
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
エリサボスキ日立ヨーロッパのC / O ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス電話：+41 44 6327057電子メール：elisa.boschi@hitachi-eu.com
Nevil Brownlee CAIDA (UCSD/SDSC) 9500 Gilman Drive La Jolla, CA 92093-0505 Phone: +1 858 534 8338 EMail: nevil@caida.org
NevilブラウンリーCAIDA（UCSD / SDSC）9500ギルマンドライブラ・ホーヤ、カリフォルニア州92093から0505電話：+1 858 534 8338 Eメール：nevil@caida.org
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1 1831ディーゲムベルギー電話：+32 2 704 5622 Eメール：bclaise@cisco.com