Network Working Group J. Quittek
Request for Comments: 3917 NEC Europe Ltd.
Category: Informational T. Zseby
Fraunhofer FOKUS
B. Claise
Cisco Systems
S. Zander
Swinburne University
October 2004
Requirements for IP Flow Information Export (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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.
このメモは、ルータ、トラフィック測定プローブ、およびミドルボックスのうち、測定IPフロー情報の輸出のための要件を定義します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IP Traffic Flow. . . . . . . . . . . . . . . . . . . . 3
2.2. Observation Point. . . . . . . . . . . . . . . . . . . 4
2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4
2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5
2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 5
2.6. Collecting Process . . . . . . . . . . . . . . . . . . 5
3. Applications Requiring IP Flow Information Export . . . . . . 6
3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6
3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7
3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7
3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 7
3.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 8
4. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
4.3. IP Header Fields . . . . . . . . . . . . . . . . . . . 9
4.4. Transport Header Fields. . . . . . . . . . . . . . . . 10
4.5. MPLS Label . . . . . . . . . . . . . . . . . . . . . . 10
4.6. DiffServ Code Point. . . . . . . . . . . . . . . . . . 10
5. Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Reliability. . . . . . . . . . . . . . . . . . . . . . 10
5.2. Sampling . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Overload Behavior. . . . . . . . . . . . . . . . . . . 11
5.4. Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Time Synchronization . . . . . . . . . . . . . . . . . 12
5.6. Flow Expiration. . . . . . . . . . . . . . . . . . . . 13
5.7. Multicast Flows. . . . . . . . . . . . . . . . . . . . 13
5.8. Packet Fragmentation . . . . . . . . . . . . . . . . . 13
5.9. Ignore Port Copy . . . . . . . . . . . . . . . . . . . 13
6. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Information Model. . . . . . . . . . . . . . . . . . . 14
6.2. Data Model . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Data Transfer. . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16
6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17
6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18
6.4. Push and Pull Mode Reporting . . . . . . . . . . . . . 18
6.5. Regular Reporting Interval . . . . . . . . . . . . . . 18
6.6. Notification on Specific Events. . . . . . . . . . . . 18
6.7. Anonymization. . . . . . . . . . . . . . . . . . . . . 18
7. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Configuration of the Metering Process. . . . . . . . . 19
7.2. Configuration of the Exporting Process . . . . . . . . 19
8. General Requirements. . . . . . . . . . . . . . . . . . . . . 20
8.1. Openness . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Scalability. . . . . . . . . . . . . . . . . . . . . . 20
8.3. Several Collecting Processes . . . . . . . . . . . . . 20
9. Special Device Considerations . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Disclosure of Flow Information Data. . . . . . . . . . 23
10.2. Forgery of Flow Records. . . . . . . . . . . . . . . . 24
10.3. Denial of Service (DoS) Attacks. . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. Appendix: Derivation of Requirements from Applications. . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . 31
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
There are several applications that require flow-based IP traffic measurements. Such measurements could be performed by a router while forwarding the traffic, by a middlebox [RFC3234], or by a traffic measurement probe attached to a line or a monitored port. This memo defines requirements for exporting traffic flow information out of these boxes for further processing by applications located on other devices. They serve as input to the standardization of the IPFIX protocol specifications.
フローベースのIPトラフィックの測定を必要とするいくつかのアプリケーションがあります。そのような測定は、トラフィックを転送しながら、ミドル[RFC3234]で、ルータによって実行される、またはラインまたは監視ポートに取り付けられたトラフィック測定プローブによることができます。このメモは、他のデバイス上に位置するアプリケーションによるさらなる処理のためにこれらのボックスのうち、トラフィックフロー情報をエクスポートするための要件を定義します。彼らは、IPFIXプロトコル仕様の標準化への入力としての役割を果たす。
In section 3, a selection of such applications is presented. The following sections list requirements derived from these applications.
セクション3では、そのようなアプリケーションの選択が提示されます。次のセクションでは、これらのアプリケーションから派生要件を示します。
In its early discussions the IPFIX Working Group chose to evaluate existing flow export protocols at the same time it was developing this 'requirements' document.
その初期の議論でIPFIXワーキンググループは、それがこの「要件」の文書を開発していたと同時に、既存のフローエクスポートプロトコルを評価することにしました。
Flow export, however, is not performed by a protocol acting alone, it also requires a system of co-operating processes. In producing IPFIX requirements, therefore, the Working Group decided to specify what was required by these various processes - the metering process, the exporting process, etc. In these specifications we use lower-case for the words must, may, and should, to indicate that IPFIX implementors have some freedom as to how to meet the requirements.
輸出フロー、しかし、単独で作用するプロトコルによって行われていない、それはまた、共同業務プロセスのシステムが必要です。私たちは言葉なければならない、かもしれない、とすべき、とのために小文字を使用する計量工程、輸出プロセス、などが挙げられる。これらの仕様は - IPFIX要件を製造する際には、そのため、ワーキンググループは、これらの様々なプロセスによって要求されたものを指定することにしましたIPFIXの実装が要件を満たす方法についてのいくつかの自由を持っていることを示しています。
The Working Group's goal is to produce standards-track RFCs describing the IPFIX information model and export protocol RFCs. As well as meeting the requirements set out in this document, the information model and protocol documents will provide a full specification of the IPFIX system, and will use uppercase keywords as in [RFC 2119].
ワーキンググループの目標はIPFIX情報モデルとエクスポートプロトコルRFCを記述する標準トラックRFCを生産することです。同様に、本書に定める要件を満たすものとして、情報モデルとプロトコルドキュメントは、IPFIXシステムの完全な仕様を提供し、[RFC 2119]のように大文字のキーワードを使用します。
The following terminology is used in this document:
以下の用語は、本書で使用されます。
There are several definitions of the term 'flow' being used by the Internet community. Within this document we use the following one:
インターネットコミュニティによって使用されている用語「流れ」のいくつかの定義があります。この文書の中で、私たちは、次のいずれかを使用します。
A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
フローは、特定の時間間隔中にネットワーク内の観測点を通過するIPパケットの集合として定義されます。特定のフローに属するすべてのパケットは、一般的なプロパティのセットを持っています。各プロパティは、の値に関数を適用した結果のように定義されます。
1. one or more packet header field (e.g., destination IP address), transport header field (e.g., destination port number), or application header field (e.g., RTP header fields [RFC3550])
1.一つ以上のパケットヘッダフィールド（例えば、宛先IPアドレス）、トランスポートヘッダフィールド（例えば、宛先ポート番号）、またはアプリケーションヘッダフィールド（例えば、RTPヘッダフィールド[RFC3550]）
2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc.)
パケット自体の2.一つ以上の特性（例えば、等MPLSラベルの数）
3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc.)
前記パケット処理（等例えば、次ホップIPアドレス、出力インタフェース）に由来する1つまたは複数のフィールドを
A packet is defined to belong to a flow if it completely satisfies all the defined properties of the flow.
パケットは、それが完全に流れのすべての定義された特性を満たす場合、フローに属するものと定義されます。
This definition covers the range from a flow containing all packets observed at a network interface to a flow consisting of just a single packet between two applications with a specific sequence number. Please note that the flow definition does not necessarily match a general application-level end-to-end stream. However, an application may derive properties of application-level streams by processing measured flow data. Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to application headers.
この定義は、特定のシーケンス番号を持つ2つのアプリケーション間のちょうど単一のパケットからなるフローへのネットワークインタフェースで観察されたすべてのパケットを含む流れの範囲をカバーします。フロー定義は、必ずしも一般的なアプリケーションレベルのエンド・ツー・エンドの流れと一致しないことに注意してください。しかし、アプリケーションは、測定されたフローデータを処理することによって、アプリケーション・レベルのストリームの特性を導出することができます。また、パケットプロパティは、アプリケーションヘッダーにもよるが、アプリケーションのヘッダーに関連し、この文書で定義されている必要はないことに注意してください。
The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.
観測点は、IPパケットを観察することができるネットワーク内の場所です。例には、プローブが結合している線、イーサネットベースのLAN、ルータの単一ポート、またはルータの（物理的または論理的な）インターフェイスのセットとして共有媒体です。
Note that one observation point may be a superset of several other observation points. For example one observation point can be an entire line card. This would be the superset of the individual observation points at the line card's interfaces.
一個の観察点は、いくつかの他の観測点のスーパーセットであってもよいことに留意されたいです。例えば、一個の観察点は、全体のラインカードとすることができます。これは、ラインカードのインターフェイスで、個々の観測点のスーパーセットになります。
The metering process generates flow records. Input to the process are packet headers observed at an observation point and packet treatment at the observation point, for example the selected output interface. The metering process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining flow records.
計量プロセスは、フローレコードを生成します。プロセスへの入力は、選択された出力インタフェース、例えば、観測点での観測点とパケット処理で観察されたパケットのヘッダです。計量プロセスは、サンプリング、分類、およびフローレコードを維持するタイムスタンプ、パケットヘッダキャプチャを含む関数のセットから成ります。
The maintenance of flow records may include creating new records, updating existing ones, computing flow statistics, deriving further flow properties, detecting flow expiration, passing flow records to the exporting process, and deleting flow records.
フローレコードのメンテナンスは、新しいレコードを作成する既存の更新、フロー統計情報を計算し、さらに流動特性を導出する、フローの有効期限を検出し、エクスポートプロセスにフローレコードを通過し、フローレコードを削除含むことができます。
The sampling function and the classifying function may be applied more than once with different parameters. Figure 1 shows the sequence in which the functions are applied. Sampling is not illustrated in the figure; it may be applied before any other function.
サンプリング機能と分類機能は、異なるパラメータで複数回適用することができます。図1は、機能が適用される順序を示しています。サンプリングは、図に示されていません。それは他の関数の前に適用することができます。
packet header capturing
|
timestamping
|
v
+----->+
| |
| classifying
| |
+------+
|
maintaining flow records
|
v
Figure 1: Functions of the metering process
図1：計量プロセスの機能
A flow record contains information about a specific flow that was metered at an observation point. A flow record contains measured properties of the flow (e.g., the total number of bytes of all packets of the flow) and usually characteristic properties of the flow (e.g., source IP address).
フローレコードは、観測点で計量した特定のフローに関する情報が含まれています。フローレコードは、フローの測定された特性（例えば、フローのすべてのパケットの合計バイト数）と流れの通常の特性（例えば、送信元IPアドレス）を含みます。
The exporting process sends flow records to one or more collecting processes. The flow records are generated by one or more metering processes.
エクスポートプロセスは、1つまたは複数の収集プロセスにフローレコードを送信します。フローレコードは、一つ以上の計量プロセスによって生成されます。
The collecting process receives flow records from one or more exporting processes. The collecting process might store received flow records or further process them, but these actions are out of the scope of this document.
収集プロセスは、1つまたは複数の輸出プロセスからフローレコードを受け取ります。収集処理は、受信したフローレコードを保存したり、さらにそれらを処理しますが、これらのアクションは、この文書の範囲外である可能性があります。
This section describes a selection of applications requiring IP flow information export. Because requirements for flow export listed in further sections below are derived from these applications, their selection is crucial. The goal of this requirements document is not to cover all possible applications with all their flow export requirements, but to cover applications which are considered to be of significant importance in today's and/or future IP networks, and for which requirements can be met with reasonable technical effort.
このセクションでは、IPフロー情報のエクスポートを必要とするアプリケーションの選択を説明します。以下にさらにセクションに記載されているフロー・輸出のための要件は、これらのアプリケーションから派生しているので、彼らの選択は非常に重要です。この要件ドキュメントの目標は、すべてのフローの輸出要件を持つすべての可能なアプリケーションをカバーするために、今日のおよび/または将来のIPネットワークでは非常に重要であると考えられているアプリケーションをカバーすることはなく、そのための要件は、合理的に満たすことができます技術的な努力。
The list of applications should lead to a better understanding of the requirements which is particularly important when designing or implementing traffic flow metering functions. A detailed overview of which requirement was derived from which application(s) is given in the appendix.
アプリケーションのリストは、設計またはトラフィックフローメータリング機能を実装する際に特に重要である要件のより良い理解につながるはず。要件がどのアプリケーション（複数可）に由来したの詳細な概要は、付録に記載されています。
Please note that the described applications can have a large number of differing implementations. Requirement details or requirement significance (required (must), recommended (should), optional (may)) could differ for specific implementations and/or for specific application scenarios. Therefore we derive the requirements from the general functionality of the selected applications. Some particular cases will even mandate more stringent requirements than the ones defined in this document. For example, usage-based accounting is certainly the application that will probably mandate the highest degree of reliability amongst the applications discussed below. The reliability requirements defined in sections 5.1 and 6.3.2. are not sufficient to guarantee the level of reliability that is needed for many usage-based accounting systems. Particular reliability requirements for accounting systems are discussed in [RFC2975].
説明アプリケーションが異なる実装の数が多いことに注意してください。要件の詳細や要件の重要性（必要な（）は、推奨（）、オプション（）することができるべきでなければならない）、及び/又は特定のアプリケーションシナリオの特定の実装のために異なる可能性があります。そこで我々は、選択したアプリケーションの一般的な機能から要件を導き出します。いくつかの特定のケースでも、この文書で定義されたものより厳しい要件を強制します。例えば、使用量ベースの会計は、おそらく、以下に説明するアプリケーションの中で信頼性の最高度を強制するアプリケーションは確かです。セクション5.1および6.3.2で定義された信頼性要件。多くの使用量ベースの会計システムのために必要とされる信頼性のレベルを保証するのに十分ではありません。会計システムのための特定の信頼性要件は[RFC2975]で議論されています。
Several new business models for selling IP services and IP-based services are currently under investigation. Beyond flat rate services which do not need accounting, accounting can be based on time or volume. Accounting data can serve as input for billing systems. Accounting can be performed per user or per user group, it can be performed just for basic IP service or individually per high-level service and/or per content type delivered. For advanced/future services, accounting may also be performed per class of service, per application, per time of day, per (label switched) path used, etc.
IPサービスおよびIPベースのサービスを販売するためのいくつかの新しいビジネスモデルは、現在調査中です。会計処理を必要としない定額サービスに加え、会計は、時間またはボリュームに基づいて行うことができます。会計データは、課金システムへの入力として使用することができます。会計はそれだけで、基本的なIPサービスのための、または個別の高レベルのサービスごとに、および/または配信されたコンテンツの種類ごとに行うことができ、ユーザごと又はユーザグループごとに行うことができます。将来的/高度なサービスのために、会計は、アプリケーションごとに、一日の時間あたり、使用されるパス（ラベルスイッチ）あたり、など、サービスのクラスごとに実行することができます
Traffic profiling is the process of characterizing IP flows by using a model that represents key parameters of the flows such as flow duration, volume, time, and burstiness. It is a prerequisite for network planning, network dimensioning, trend analysis, business model development, and other activities. It depends heavily on the particular traffic profiling objective(s), which statistics, and which accuracy are required from the measurements. Typical information needed for traffic profiling is the distribution of used services and protocols in the network, the amount of packets of a specific type (e.g., percentage of IPv6 packets) and specific flow profiles.
トラフィックプロファイルは、フロー継続時間、音量、時間、及びバーストとして流れの重要なパラメータを表すモデルを使用して、IPフローを特徴づけるプロセスです。これは、ネットワーク計画、ネットワークの寸法、傾向分析、ビジネスモデルの開発、およびその他の活動のための前提条件です。これは、特定のトラフィックプロファイル目的（複数可）、統計に大きく依存し、その精度は測定から求められています。トラフィックプロファイリングのために必要な一般的な情報は、ネットワークで使用されるサービスおよびプロトコルの分布、（例えば、IPv6パケットのパーセンテージ）および特定のフロープロファイル特定タイプのパケットの量です。
Since objectives for traffic profiling can vary, this application requires a high flexibility of the measurement infrastructure, especially regarding the options for measurement configuration and packet classification.
トラフィックプロファイリングのための目的が変わることがあるので、このアプリケーションは、特に測定構成とパケット分類のためのオプションについて、測定インフラの高い柔軟性を必要とします。
Traffic Engineering (TE) comprises methods for measurement, modelling, characterization and control of a network. The goal of TE is the optimization of network resource utilization and traffic performance [RFC2702]. Since control and administrative reaction to measurement results requires access to the involved network nodes, TE mechanisms and the required measurement function usually are performed within one administrative domain. Typical parameters required for TE are link utilization, load between specific network nodes, number, size and entry/exit points of the active flows and routing information.
トラフィックエンジニアリング（TE）は、測定、モデリング、特性評価およびネットワークの制御のための方法を含みます。 TEの目標は、ネットワークリソースの使用率とトラフィックのパフォーマンス[RFC2702]の最適化です。測定結果を制御および管理の反応が関与するネットワークノードへのアクセスを必要とするため、TE機構および必要な測定機能は、通常、1つの管理ドメイン内で実行されます。 TEに必要な典型的なパラメータは、特定のネットワーク・ノード、数、大きさ及びアクティブフローの入口/出口点と経路情報との間のリンク利用率、負荷です。
Capturing flow information plays an important role for network security, both for detection of security violation, and for subsequent defense. In case of a Denial of Service (DOS) attack, flow monitoring can allow detection of unusual situations or suspicious flows. In a second step, flow analysis can be performed in order to gather information about the attacking flows, and for deriving a defense strategy.
フロー情報をキャプチャすると、セキュリティ違反の検出のために、そしてその後の防衛のために、両方の、ネットワークセキュリティのために重要な役割を果たしています。サービス拒否（DOS）攻撃の場合には、フローモニタリングは、異常な状況または疑わしいフローの検出を可能にすることができます。第二ステップでは、フロー分析は、攻撃フローに関する情報を収集するために、及び防御戦略を導出するために行うことができます。
Intrusion detection is a potentially more demanding application which would not only look at specific characteristics of flows, but may also use a stateful packet flow analysis for detecting specific, suspicious activities, or unusually frequent activities. Such activities may be characterized by specific communication patterns, detectable by characteristic sequences of certain packet types.
侵入検知は、フローの特定の特性に見えるだけでなく、潜在的により厳しいアプリケーションであるが、特定の、疑わしい活動、または異常に頻繁な活動を検出するためのステートフルパケットフロー分析を使用してもよいです。そのような活動は、特定のパケットタイプの特徴的な配列によって検出特定の通信パターンによって特徴付けることができます。
QoS monitoring is the passive measurement of quality parameters for IP flows. In contrast to active measurements, passive measurements utilize the existing traffic in the network for QoS analysis. Since no test traffic is sent, passive measurements can only be applied in situations where the traffic of interest is already present in the network. One example application is the validation of QoS parameters negotiated in a service level specification. Note that passive/active measurement is also referred to as non-intrusive/intrusive measurement or as measurement of observed/synthetic traffic.
QoSのモニタリングは、IPフローのための品質パラメータの受動的な測定です。活性測定とは対照的に、受動的測定は、QoS分析のためにネットワーク内の既存のトラフィックを利用します。いかなるテストトラフィックが送信されないので、受動的測定は、関心のトラフィックは既にネットワークに存在している状況で適用することができます。一例のアプリケーションは、サービスレベル仕様で交渉されたQoSパラメータの検証です。また、非侵入/侵入的測定として、または観察/合成トラフィックの測定と呼ばれている受動/能動的測定に留意されたいです。
Passive measurements cannot provide the kind of controllable experiments that can be achieved with active measurements. On the other hand passive measurements do not suffer from undesired side effects caused by sending test traffic (e.g., additional load, potential differences in treatment of test traffic and real customer traffic).
パッシブ測定は、アクティブな測定を達成することができ、制御の実験のようなものを提供することはできません。一方、受動的測定は、試験トラフィック（例えば、追加の負荷、試験トラフィックと実際の顧客トラフィックの治療における電位差）を送信することによって引き起こされる望ましくない副作用を受けません。
QoS monitoring often requires the correlation of data from multiple observation points (e.g., for measuring one-way metrics). This requires proper clock synchronization of the involved metering processes. For some measurements, flow records and/or notifications on specific events at the different observation points must be correlated, for example the arrival of a certain packet. For this, the provisioning of post-processing functions (e.g., the generation of packet IDs) at the metering processes would be useful. Since QoS monitoring can lead to a huge amount of measurement result data, it would highly benefit from mechanisms to reduce the measurement data, like aggregation of results and sampling.
QoSのモニタリングは、多くの場合（例えば、一方向の指標を測定するための）複数の観測点からのデータの相関を必要とします。これは、関与計量プロセスの適切なクロック同期を必要とします。いくつかの測定、フローレコードおよび/または異なる観測点で特定のイベントに通知するための例示特定のパケットの到着を、相関されなければなりません。このため、後処理機能のプロビジョニングは、（例えば、パケットIDの生成）計量プロセスでは有用であろう。 QoSのモニタリングは、測定結果データの膨大な量につながることができるので、それは非常に結果とサンプリングの凝集と同様に、測定データを減少させるためのメカニズムから恩恵を受ける。
Please note that not all requirements for QoS monitoring are covered by the IPFIX requirements specified in the following sections. The IPFIX requirements are targeted at per flow information including summaries of per-packet properties for packets within a flow, but not per-packet information itself. For example jitter measurement requires timestamping each packet and reporting of all timestamps of a flow, but the IPFIX requirements only cover timestamps of first and last packet of a flow.
QoSの監視のためのすべての要件は、次のセクションで指定されたIPFIX要件によってカバーされていないことに注意してください。 IPFIX要件は、フロー内のパケットのためのパケットごとの性質の要約を含むフロー情報あたりをターゲットにではなく、パケットごとの情報自体されています。例えば、ジッタ測定は、フローのすべてのタイムスタンプの各パケットと報告をタイムスタンプが必要ですが、IPFIX要件が流れのみの最初と最後のパケットのタイムスタンプをカバーしています。
Packets are mapped to flows by evaluating their properties. Packets with common properties are considered to belong to the same flow. A packet showing at least one difference in the set of properties is considered to belong to a different flow.
パケットは、その特性を評価することにより、フローにマッピングされます。共通のプロパティを持つパケットは、同じフローに属していると考えられています。プロパティのセットにおける少なくとも1点の差を示すパケットが異なるフローに属すると考えられます。
The following subsections list a set of properties which a metering process must, should, or may be able to evaluate for mapping packets to flows. Please note that requiring the ability to evaluate a certain property does not imply that this property must be evaluated for each packet. In other words, meeting the IPFIX requirements means that the metering process in general must be able, via its configuration, to somehow support to distinguish flows via all the must fields, even if in certain circumstances/for certain applications, only a subset of the must fields is needed and effectively used to distinguish flows.
以下のサブセクションでは、計量工程が、、またはフローにマッピングするパケットのために評価することができるかもしれなければならない必要があるプロパティのセットを一覧表示します。このプロパティは、各パケットのために評価されなければならないことを意味するものではありません特定の性質を評価する能力を必要とすることに注意してください。換言すれば、IPFIX要件を満たすことは、一般に、計量プロセスは、その構成を介して、何らかの方法で、すべての必須フィールドを介してフローを区別するのにも特定の状況では、IF /特定の用途のために、サブセットのみをサポートするために、できなければならないことを意味しますフィールドには、必要に応じて、効果的に流れを区別するために使用されている必要があります。
Which combination of properties is used for distinguishing flows and how these properties are evaluated depends on the configuration of the metering process. The configured choice of evaluated properties strongly depends on the environment and purpose of the measurement and on the information required by the collecting process. But in any case, a collecting process must be able to clearly identify, for each received flow record, which set of properties was used for distinguishing this flow from other ones.
プロパティのどの組み合わせが特徴的な流れのために使用され、どのようにこれらの特性が評価されているが計量プロセスの構成によって異なります。評価したプロパティの構成された選択が強く、測定の環境や目的にして収集プロセスが必要とする情報に依存します。各プロパティのセットを他のものからこのフローを区別するために使用したフローレコードを、受信したためではなく、いずれの場合にも、回収プロセスは、明瞭に識別することができなければなりません。
For specific deployments, only a subset of the required properties listed below can be used to distinguish flows. For example, in order to aggregate the flow records and reduce the number of flow records exported. On the other hand, some other deployments will require distinguishing flows by some extra parameters, such as the TTL field of the IP header or the BGP Autonomous System number [RFC1771] of the IP destination address.
特定の展開のために、下記の要求される特性のサブセットのみがフローを区別するために使用することができます。例えば、フローレコードを集約し、エクスポートされたフローレコードの数を減少させるためです。一方、いくつかの他の展開は、IPヘッダやIP宛先アドレスのBGP自律システム番号[RFC1771]のTTLフィールドのようないくつかの追加のパラメータによって区別フローを必要とするであろう。
If encryption is used, the metering process might not be able to access all header fields. A metering process must meet the requirements stated in this section 4 only for packets that have the relevant header fields not encrypted.
暗号化が使用されている場合は、計量プロセスは、すべてのヘッダフィールドにアクセスすることができない場合があります。計量プロセスは、暗号化されていない関連するヘッダフィールドを有するパケットは、このセクション4で述べた要件を満たさなければなりません。
The metering process must be able to separate flows by the incoming interface or by the outgoing interface or by both of them.
計量プロセスは、着信インターフェースによって、または発信インターフェイスによって、またはそれらの両方で流れを分離することができなければなりません。
The metering process must be able to separate flows by the following fields of the IP header:
計量プロセスは、IPヘッダの次のフィールドによって流れを分離することができなければなりません。
For source address and destination address, separating by full match must be supported as well as separation by prefix match.
送信元アドレスと宛先アドレスの場合は、完全一致によって分離するだけでなくプレフィックス一致による分離としてサポートする必要があります。
The metering process should be able to separate flows by the IP version number if the observation point is located at a device that is supporting more than one IP version.
計量プロセスは、観測点が複数のIPバージョンをサポートしているデバイスに配置されている場合は、IPバージョン番号で流れを分離することができなければなりません。
The metering process must be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol. The metering process should be able to separate flows by the port numbers of the transport header in case of SCTP [RFC2960].
TCPまたはUDPトランスポートプロトコルとして使用されるの計量プロセスが場合にトランスポートヘッダのポート番号で流れを分離することができなければなりません。計量プロセスはSCTP [RFC2960]の場合に、トランスポートヘッダのポート番号で流れを分離することができなければなりません。
For separation, both, source and destination port number must be supported for distinguishing flows, individually as well as in combination.
分離のために、双方は、送信元および宛先ポート番号は区別フローのため、個別ならびに組み合わせでサポートされなければなりません。
If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process must be able to separate flows by the MPLS label.
観測点は、（MPLS、[RFC3031]を参照）、マルチプロトコルラベルスイッチングをサポートするデバイスに配置されている場合、計量プロセスはMPLSラベルで別個の流れにできなければなりません。
If the observation point is located at a device supporting Differentiated Services (DiffServ) then the metering process must be able to separate flows by the DiffServ Code Point (DSCP, see [RFC2474]).
観測点は、差別化サービス（DiffServの）をサポートするデバイスに配置されている場合、計量プロセスは、のDiffServコードポイント（DSCP、[RFC2474]を参照）によって流れを分離することができなければなりません。
The following are requirements for the metering process. All measurements must be conducted from the point of view of the observation point.
以下の計量工程のための要件です。全ての測定は、観測点の観点から行われなければなりません。
The metering process must either be reliable or the absence of reliability must be known and indicated. The metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process. If, e.g., due to some overload, not all passing packets can be included into the metering process, then the metering process must be able to detect this failure and to report it.
計量プロセスは、いずれかの信頼できるものでなければならない、または信頼性の欠如は、知られており、示さなければなりません。観測点を通過する各パケットが計量プロセスの構成に応じて計量された場合、計量プロセスが信頼性があります。例えば、いくつかの過負荷に起因する、すべて通過するパケットは、計量プロセスに含めることができない場合は、計量プロセスは、この障害を検出すると、それを報告することができなければなりません。
Sampling describes the systematic or random selection of a subset of elements (the sample) out of a set of elements (the parent population). Usually the purpose of applying sampling techniques is to estimate a parameter of the parent population by using only the elements of the subset. Sampling techniques can be applied for instance to select a subset of packets out of all packets of a flow or to select a subset of flows out of all flows on a link. Sampling methods differ in their sampling strategy (e.g., systematic or random) and in the event that triggers the selection of an element. The selection of one packet can for instance be triggered by its arrival time (time-based sampling), by its position in the flow (count-based sampling) or by the packet content (content-based sampling).
サンプリングは、要素のセット（母集団）のうち、要素のサブセット（サンプル）の体系的またはランダムな選択を説明します。通常、サンプリング技術を適用する目的は、一部の要素のみを使用して母集団のパラメータを推定することです。サンプリング技術は、フローのすべてのパケットのうちのパケットのサブセットを選択するか、リンク上のすべてのフローのうち、フローのサブセットを選択する場合に適用することができます。サンプリング方法は、（例えば、体系的またはランダム）、それらのサンプリング戦略の要素の選択をトリガするイベントが異なります。 1つのパケットの選択は、例えば、フロー（カウントベースサンプリング）またはパケットのコンテンツ（コンテンツベースのサンプリング）によってその位置によって、その到着時間（時間ベースのサンプリング）によってトリガすることができます。
The metering process may support packet sampling. If sampling is supported, the sampling configuration must be well defined. The sampling configuration includes the sampling method and all its parameters.
計量プロセスは、パケットサンプリングをサポートすることができます。サンプリングがサポートされている場合、サンプリング構成が明確に定義されなければなりません。サンプリング構成は、サンプリング法とそのすべてのパラメータを含んでいます。
If the sampling configuration is changed during operation, the new sampling configuration with its parameters must be indicated to all collecting processes receiving the affected flow records. Changing the sampling configuration includes: adding a sampling function to the metering process, removing a sampling function from the metering process, change sampling method, and change sampling parameter(s).
サンプリング構成は、動作中に変更された場合、そのパラメータで新しいサンプリング構成は、影響を受けたフローレコードを受信しているすべての収集プロセスに指示する必要があります。サンプリングの構成を変更するステップは、計量プロセス、変更サンプリング方法、および変更サンプリングパラメータ（単数または複数）からサンプリング機能を除去し、計量工程にサンプリング機能を追加します。
In case of any change in the sampling configuration, all flow records metered by the previous sampling configuration must be terminated and exported according to the export configuration. The metering process must not merge the flow records generated with the new sampling configuration with the flow records generated with the previous sampling configuration.
サンプリング構成の変更の場合は、前回のサンプリング構成によって計量すべてのフローレコードがエクスポート設定に応じて終了してエクスポートする必要があります。計量プロセスは、前回のサンプリング設定で生成されたフローレコードを持つ新しいサンプリング構成で生成されたフローレコードをマージしてはなりません。
In case of an overload, for example lack of memory or processing power, the metering process may change its behavior in order to cope with the lack of resources. Possible reactions include:
過負荷の場合には、メモリや処理能力の一例の欠如のために、計量プロセスは、リソースの不足に対処するために、その動作を変更することができます。可能な反応は、次のとおりです。
- Reduce the number of flows to be metered. This can be
achieved by more coarse-grained flow measurement or by a
restriction of the flow records to a subset of the set of
original ones.
- Start sampling packets before they are processed by the metering process or - if sampling is already performed - reduce the sampling frequency.
サンプリングがすでに実行されている場合 - - - 彼らは計量法によって処理されるか、される前に、パケットをサンプリング開始サンプリング周波数を下げます。
- Stop metering.
- ストップ計量。
- Reducing the resource usage of competing processes on the same device. Example: reducing the packet forwarding throughput
- 同じデバイス上で競合するプロセスのリソース使用量を減らします。例：パケット転送のスループットを低下させます
Overload behavior is not restricted to the four options listed above. But in case the overload behavior induces a change of the metering process behavior, the overload behavior must be clearly defined.
過負荷の動作は、上記の4つのオプションに限定されるものではありません。過負荷動作が計量プロセスの挙動の変化を引き起こす場合でも、過負荷動作が明確に定義する必要があります。
For some flows, the change of behavior might have an impact on the data that would be stored in the associated flow records after the change, for example if the packet classification is changed or the sampling frequency. These flows must be considered as terminated and the associated flow records must be exported separately from new ones generated after the behavior change. The terminated flow records and new ones generated after the behavior change must not be merged by the metering process. The collecting process must be able to distinguish the affected flow records generated before and after the change of behavior. This requirement does not apply to flows and associated flow records not affected by the change of metering process behavior.
いくつかのフローのため、行動の変化は、パケットの分類が変更された場合、例えば、変更後の関連したフローレコードに格納されるデータやサンプリング周波数に影響を与える可能性があります。終了としてこれらのフローは考慮しなければならず、関連するフローレコードは、動作の変更後に生成された新しいものとは別にエクスポートする必要があります。終了フローレコードおよび行動の変更後に生成された新しいものが計量工程でマージされてはなりません。収集プロセスは、行動の変更前と後に生成され、影響を受けたフローレコードを区別できなければなりません。この要件はありません計量プロセスの挙動の変化に影響フローと関連するフローレコードには適用されません。
The metering process must be able to generate timestamps for the first and the last observation of a packet of a flow at the observation point. The timestamp resolution must be at least the one of the sysUpTime [RFC3418], which is one centisecond.
計量プロセスは、第一及び観測点におけるフローのパケットの最後の観察のためのタイムスタンプを生成することができなければなりません。タイムスタンプの分解能は、一センチあるのsysUpTime [RFC3418]、の少なくともいずれかでなければなりません。
It must be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC).
協定世界時（UTC）と計量プロセスによって生成されたタイムスタンプを同期させることが可能でなければなりません。
Note that the possibility of synchronizing timestamps of each single metering process with UTC implies the possibility of synchronizing timestamps generated by different metering processes.
UTCと各単一の計量プロセスのタイムスタンプを同期させる可能性が異なる計量プロセスによって生成されたタイムスタンプを同期化する可能性を意味することに注意してください。
Note that this does not necessarily imply that timestamps generated by the metering process are UTC timestamps. For example, this requirement can be met by using local system clock values as timestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can synchronize the timestamps by calculating the offset between UTC and the system clock of the metering process.
これは必ずしも計量プロセスによって生成されたタイムスタンプがUTCタイムスタンプであることを意味するものではないことに注意してください。例えば、この要求は、タイムスタンプとしてローカルシステムクロック値を使用して収集プロセスにレポートをエクスポートするとき、追加のタイムスタンプを追加することによって満たすことができます。次いで、回収プロセスはUTCと計量プロセスのシステム・クロックとの間のオフセットを計算することによって、タイムスタンプを同期させることができます。
The metering process must be able to detect flow expirations. A flow is considered to be expired if no packet of this flow has been observed for a given timeout interval. The metering process may support means for detecting the expiration of a flow before a timeout occurs, for example by detecting the FIN or RST bits in a TCP connection. The procedure for detecting a flow expiration must be clearly defined.
計量プロセスは、フローの有効期限を検出することができなければなりません。流れは、この流れのないパケットが与えられたタイムアウト間隔のために観察されていない場合は有効期限が切れていると考えられます。計量プロセスは、TCP接続でFINまたはRSTビットを検出することにより、例えば、タイムアウトが発生する前に、流れの満了を検出するための手段をサポートすることができます。フローの有効期限を検出するための手順を明確に定義する必要があります。
For multicast flows containing packets replicated to multiple output interfaces, the metering process should be able to maintain discrete flow records per different output interface. For example, the metering process should be able to report an incoming multicast packet that is replicated to four output interfaces in four different flow records that differ by the output interface.
複数の出力インターフェイスに複製パケットを含むマルチキャストフローのために、計量プロセスは、異なる出力インターフェイスごと離散フローレコードを維持することができなければなりません。例えば、計量プロセスは、出力インターフェースによって異なる四つの異なるフローレコード内の4つの出力インターフェイスに複製され、着信マルチキャストパケットを報告することができなければなりません。
In case of IP packet fragmentation and depending on the classification scheme, only the zero-offset fragment of a single initial packet might contain sufficient information to classify the packet. Note that this fragment should be the first one generated by the router imposing the fragmentation [RFC791], but might not be the first one observed by the IPFIX device, due to reordering reasons. The metering process may keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows.
IPパケット断片化の場合と分類体系に応じて、単一の最初のパケットの唯一のゼロオフセット断片は、パケットを分類するために十分な情報を含むかもしれません。この断片は、断片化[RFC791]を課すルータによって生成された最初のものであるべきであるが、原因並べ替え理由に、IPFIXデバイスによって観察された最初のものではないかもしれないことに留意されたいです。計量プロセスは、フローに正しく十分なヘッダー情報が含まれていないフラグメントをマッピングするために、IPパケットの断片化の状態を保つことがあります。
The metering process may be able to ignore packets which are generated by a port copy function acting at the device where the observation point of a flow is located.
計量プロセスは、フローの観測点が配置されているデバイスで作用ポートコピー機能によって生成されたパケットを無視することができるかもしれません。
The following are requirements for exporting flow records out of the exporting process. Beside requirements on the data transfer, we separate requirements concerning the information model from requirements concerning the data model. Furthermore, we list requirements on reporting times and notification on specific events, and on anonymization of flow records.
以下のエクスポート・プロセスのアウトフローレコードをエクスポートするための要件です。データ転送の要件のほかに、我々は、データモデルに関する要件からの情報モデルに関する要件を分けます。さらに、我々は特定のイベントに時間と通知の報告に関する要件をリストアップし、フローレコードの匿名化に。
The information model for the flow information export is the list of attributes of a flow to be contained in the report (including the semantics of the attributes).
フロー情報をエクスポートするための情報モデルは、（属性のセマンティクスを含む）のレポートに含まれるフローの属性のリストです。
This section lists attributes an exporting process must, should or may be able to report. This does not imply that each exported flow record must contain all required attributes. But it implies that it must be possible to configure the exporting process in a way that the information of all required attributes can be transmitted from the exporting process to the receiving collecting process(es) for each exported flow.
このセクションでエクスポートプロセスは、またはレポートすることができるかもしれなければならない必要があります属性。これは、各エクスポートフローレコードは、必要なすべての属性を含んでいなければならないことを意味するものではありません。しかし、すべての必要な属性の情報は、各エクスポートフローのための受信収集プロセス（ES）へのエクスポートプロセスから送信されることができるような方法でエクスポートするプロセスを設定することが可能でなければならないことを意味します。
In other words, meeting the IPFIX requirements means that the exporting process in general must be able, via its configuration, to somehow support to report all the must fields, even if in certain circumstances or for certain applications, only a subset of the set of all must fields is needed and effectively reported.
言い換えれば、IPFIX要件を満たすことが一般的でエクスポートプロセスがその構成を経由して、何とか場合でも、特定の状況や特定のアプリケーションのセットのサブセットのみのために、すべての必須フィールドを報告してサポートするために、できなければならないことを意味しますすべての必須フィールドに必要かつ効果的に報告されます。
Beyond that, the exporting process might offer to report further attributes not mentioned here. A particular flow record may contain some of the "required" attributes as well as some additional ones, for example covering future technologies.
それ以上に、エクスポートプロセスは、ここでは言及されていない更なる属性を報告して提供するかもしれません。特定のフローレコードは、将来の技術をカバーする例えば属性「必須」だけでなく、いくつかの追加的なもののいくつかを含んでいてもよいです。
This document does not impose that the following attributes are reported for every single flow record, especially for repetitive attributes. For example, if the observation point is the incoming packet stream at the IP interface with the ifIndex value 3, then this observation point does not have to be exported as part of every single flow record. Exporting it just once might give sufficient information to the collecting process.
この文書では、特に反復的な属性のために、以下の属性は、すべて単一のフローレコードについて報告されていることを課していません。観測点は、ifIndex値3とのIPインターフェイスで着信パケットストリームである場合、例えば、この観測点は、すべて単一のフローレコードの一部としてエクスポートする必要はありません。一度だけ、それをエクスポートすると、収集プロセスに十分な情報を与えるかもしれません。
The exporting process must be able to report the following attributes for each metered flow:
エクスポートプロセスは、各計量されたフローの次の属性を報告することができなければなりません。
1. IP version number This requirement only applies if the observation point is located at a device supporting more than one version of IP.
観測点は、IPの複数のバージョンをサポートしているデバイスに配置されている場合は、この要件にのみ適用1. IPバージョン番号。
2. source IP address 3. destination IP address 4. IP protocol type (TCP,UDP,ICMP,...) 5. if protocol type is TCP or UDP: source TCP/UDP port number 6. if protocol type is TCP or UDP: destination TCP/UDP port number 7. packet counter If a packet is fragmented, each fragment is counted as an individual packet. 8. byte counter The sum of the total length in bytes of all IP packets belonging to the flow. The total length of a packet covers IP header and IP payload. 9. type of service octet (in case of IPv4), traffic class octet (in case of IPv6). According to [RFC2474], these octets include the DiffServ Code Point that has a length of 6 bits. 10. in case of IPv6: Flow Label 11. if MPLS is supported at the observation point: the top MPLS label or the corresponding forwarding equivalence class (FEC, [RFC3031]) bound to that label. The FEC is typically defined by an IP prefix. 12. timestamp of the first packet of the flow 13. timestamp of the last packet of the flow 14. if sampling is used: sampling configuration 15. unique identifier of the observation point 16. unique identifier of the exporting process
2.ソースIPアドレス3.宛先IPアドレス4. IPプロトコルタイプ（TCP、UDP、ICMP、...）5.プロトコルタイプがTCPまたはUDPである場合：送信元TCP / UDPポート番号6.プロトコルタイプがTCPである場合、またはUDP：パケットが断片化されている場合は、宛先TCP / UDPポート番号7パケットカウンタが、各フラグメントは、個々のパケットとしてカウントされます。 8バイトカウンタフローに属するすべてのIPパケットのバイト単位の合計の長さの合計。パケットの全長は、IPヘッダとIPペイロードを覆います。 （のIPv4の場合）サービスオクテット、トラフィッククラスオクテットの9種類（のIPv6の場合）。 [RFC2474]によれば、これらのオクテットは、6ビットの長さを有するのDiffServコードポイントを含みます。 10は、IPv6の場合：MPLSは、観測点で支持されている場合はフローラベル11：トップMPLSラベルまたは対応する転送等価クラス（FEC、[RFC3031]）をそのラベルに結合しました。 FECは通常、IPプレフィックスによって定義されます。サンプリングが使用される場合、フロー14の最後のパケットの流れ13タイムスタンプの最初のパケットのタイムスタンプ12：サンプリング構成15エクスポートプロセスの観測点16一意の識別子の一意の識別子
The exporting process should be able to report the following attributes for each metered flow:
エクスポートプロセスは、各計量されたフローの次の属性を報告することができるはずです。
17. if protocol type is ICMP: ICMP type and code 18. input interface (ifIndex) This requirement does not apply if the observation point is located at a probe device. 19. output interface (ifIndex) This requirement does not apply if the observation point is located at a probe device. 20. multicast replication factor the number of outgoing packets originating from a single incoming multicast packet. This is a dynamic property of multicast flows, that may change over time. For unicast flows it has the constant value 1. The reported value must be the value of the factor at the time the flow record is exported.
17.プロトコルタイプがICMPである場合：ICMPタイプとコード18入力インタフェース（ifIndexの）観測点は、プローブ装置に配置されている場合、この要件は適用されません。 19出力インタフェース（ifIndexの）観測点は、プローブ装置に配置されている場合、この要件は適用されません。 20.マルチキャスト複製因子単一着信マルチキャストパケットに由来する送信パケットの数。これは、時間とともに変化することができるマルチキャストフローの動的特性です。ユニキャストのためにそれを一定値1が報告された値は、フローレコードがエクスポートされた時点で係数の値でなければならない持って流れます。
The exporting process may be able to report the following attributes for each metered flow:
エクスポートプロセスは、各計量されたフローの次の属性を報告することができる場合があります
22. IP header flags 23. TCP header flags 24. dropped packet counter at the observation point If a packet is fragmented, each fragment must be counted as an individual packet. 25. fragmented packet counter counter of all packets for which the fragmented bit is set in the IP header 26. next hop IP address 27. source BGP Autonomous System number (see [RFC1771]) 28. destination BGP Autonomous System number 29. next hop BGP Autonomous System number
22 IPヘッダフラグ23 TCPヘッダフラグ24は、パケットが断片化されている場合、各フラグメントは、個々のパケットとしてカウントされなければならない観測点におけるパケットカウンタを落としました。断片化されたビットは、IPヘッダ26、ネクストホップIPアドレス27、ソースBGP自律システム番号（参照[RFC1771]）28.宛先BGP自律システム番号29次ホップに設定されているすべてのパケットの25断片化パケットカウンタカウンタBGP自律システム番号
The data model describes how information is represented in flow records.
データモデルは、情報がフローレコードで表される方法を説明します。
The data model must be extensible for future attributes to be added. Even if a set of attributes is fixed in the flow record, the data model must provide a way of extending the record by configuration or for certain implementations.
未来が追加される属性のデータモデルは拡張可能でなければなりません。属性のセットは、フローレコードに固定されている場合でも、データ・モデルは、コンフィギュレーションによって、または特定の実装のためのレコードを拡張する方法を提供しなければなりません。
The data model used for exporting flow information must be flexible concerning the flow attributes contained in flow records. A flexible record format would offer the possibility of defining records in a flexible (customizable) way regarding the number and type of contained attributes.
フロー情報をエクスポートするために使用されるデータモデルは、フローレコードに含まれるフロー属性に関する柔軟でなければなりません。柔軟なレコード形式が含まれる属性の数及びタイプに関するフレキシブル（カスタマイズ）方法でレコードを定義する可能性を提供するであろう。
The data model should be independent of the underlying transport protocol, i.e., the data transfer.
データモデルは、基礎となるトランスポートプロトコル、すなわち、データの転送とは無関係であるべきです。
Requirements for the data transfer include reliability, congestion awareness, and security requirements. For meeting these requirements the exporting process can utilize existing security features provided by the device hosting the process and/or provided by the transport network. For example it can use existing security technologies for authentication and encryption or it can rely on physical protection of a separated network for transferring flow information.
データ転送のための要件は、信頼性、渋滞意識、およびセキュリティ要件が含まれます。これらの要件を満たすためにエクスポートするプロセスは、プロセスをホスティングおよび/またはトランスポート・ネットワークが提供するデバイスが提供する既存のセキュリティ機能を利用することができます。例えば、それは、認証と暗号化のために、既存のセキュリティ技術を使用することができるか、それがフロー情報を転送するために分離ネットワークの物理的な保護に頼ることができます。
For the data transfer, a congestion aware protocol must be supported.
データ転送のために、混雑意識プロトコルがサポートされなければなりません。
Loss of flow records during the data transfer from the exporting process to the collecting process must be indicated at the collecting process. This indication must allow the collecting process to gauge the number of flow records lost. Possible reasons for flow records loss include but are not limited to:
収集プロセスへのエクスポートプロセスからのデータ転送時のフローレコードの損失は、収集プロセスで示されなければなりません。この指示は、収集プロセスが失われたフローレコードの数を測定できるようにする必要があります。フローレコードの損失の考えられる理由は、これらに限定されません：
1. Metering process limitations: lack of memory, processing power, etc. These limitations are already covered in section 5.1.
1.計量プロセスの制限：メモリなどの不足、処理能力は、これらの制限は、すでに5.1節で覆われています。
2. Exporting process limitations: lack of memory, processing power, etc.
2.エクスポート・プロセスの制限：メモリの不足、処理能力など
3. Data transfer problems: packets that carry flow records sent from the exporting process to the collecting process, are dropped by the network. Examples are connection failures and losses by a transport protocol that specifically offers congestion avoidance without persistent transport-level reliability.
3.データ転送の問題：収集プロセスへのエクスポートプロセスから送信されたフローレコードを運ぶパケットは、ネットワークによって廃棄されます。例としては、具体的には持続的なトランスポート・レベルの信頼性なしで輻輳回避を提供するトランスポート・プロトコルによって接続障害及び損失です。
4. Collecting process limitations: it may be experiencing congestion and not able to buffer new flows records.
4.プロセスの制限の収集：それは、新しいフローレコードをバッファリングすることができ、輻輳を経験していないことがあります。
5. Operation and Maintenance: the collecting process is taken down for maintenance or other administrative purposes.
5.操作とメンテナンス：収集プロセスは、メンテナンスなどの管理目的のために降ろされます。
Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. If reliability is provided by higher layers, only lack of overall reliability must be indicated. For example reordering could be dealt with by adding a sequence number to each packet.
信頼性のないトランスポートプロトコルが使用されている場合、信頼性がより高い層によって提供されていることに注意してください。信頼性がより高い層によって提供されている場合、全体的な信頼性の唯一の欠如が示されなければなりません。例えば、並べ替えは、各パケットにシーケンス番号を追加することで対応することができます。
The data transfer between exporting process and collecting process must be open to reliability extensions including at least
プロセスをエクスポートし、収集処理の間のデータ転送は、少なくとも含む信頼性の拡張に開いている必要があります
- retransmission of lost flow records, - detection of disconnection and fail-over, and - acknowledgement of flow records by the collecting process.
- 失われたフローレコードの再送信、 - 断線の検出とフェイルオーバーを、そして - 収集プロセスによってフローレコードの確認。
This extensibility may be used to provide additional reliability. The extended protocol must still meet the requirements described in this section, particularly, it must still be congestion aware. Therefore, extensions using retransmissions must use exponential backoff.
この拡張は、追加の信頼性を提供するために使用することができます。拡張プロトコルはまだ特に、それはまだ認識して混雑にする必要があり、このセクションで説明する要件を満たしている必要があります。そのため、再送信を使用して拡張子が指数バックオフを使用する必要があります。
Confidentiality of IPFIX data transferred from an exporting process to a collecting process must be ensured.
回収プロセスにエクスポートプロセスから転送されたIPFIXデータの機密性が保証されなければなりません。
Integrity of IPFIX data transferred from an exporting process to a collecting process must be ensured.
回収プロセスにエクスポートプロセスから転送されたIPFIXデータの整合性が保証されなければなりません。
Authenticity of IPFIX data transferred from an exporting process to a collecting process must be ensured.
回収プロセスにエクスポートプロセスから転送されたIPFIXデータの真正性が保証されなければなりません。
The security requirements have been derived from an analysis of potential security threads. The analysis is summarized in Section 10.
セキュリティ要件は、潜在的なセキュリティスレッドの解析に由来しています。分析はセクション10に要約されています。
In general, there are two ways of deciding on reporting times: push mode and pull mode. In push mode, the exporting process decides without an external trigger when to send flow records. In pull mode, sending flow records is triggered by an explicit request from a collecting process. The exporting process must support push mode reporting, it may support pull mode reporting.
プッシュモードとプルモード：一般的には、回をレポートに決定する2つの方法があります。プッシュモードでは、エクスポートプロセスは、フローレコードを送信するための外部トリガなしに決定します。プルモードでは、フローレコードを送信する回収工程からの明示的な要求によってトリガされます。エクスポートプロセスは、それがプルモードのレポートをサポートすることができ、プッシュモードのレポートをサポートしている必要があります。
The exporting process should be capable of reporting measured traffic data regularly according to a given interval length.
エクスポートプロセスは、与えられた区間長に応じて定期的に測定されたトラフィックデータを報告することができなければなりません。
The exporting process may be capable of sending notifications to a collecting process, if a specific event occurs. Such an event can be, for instance, the arrival of the first packet of a new flow, or the termination of a flow after flow timeout.
特定のイベントが発生した場合にエクスポートプロセスは、収集プロセスに通知を送信することが可能です。そのようなイベントは、例えば、新たなフローの最初のパケット、またはフロータイムアウト後の流れの終結の到着であることができます。
The exporting process may be capable of anonymizing source and destination IP addresses in flow data before exporting them. It may support anonymization of port numbers and other fields. Please note that anonymization is not originally an application requirement, but derived from general requirements for treatment of measured traffic data within a network.
エクスポートプロセスは、それらをエクスポートする前に、フローデータの送信元と宛先IPアドレスを匿名化することが可能であり得ます。これは、ポート番号などの分野の匿名化をサポートすることができます。匿名化は、もともとアプリケーションの要件ではなく、ネットワーク内で測定されたトラフィックデータの処理のための一般的な要件に由来していることに注意してください。
For several applications anonymization cannot be applied, for example for accounting and traffic engineering. However, for protecting the network user's privacy, anonymization should be applied whenever possible. In many cases it is sufficient if anonymization is performed at the collecting process after flow information has been exported. This provides a reasonable protection of privacy as long as confidentiality of the export is provided.
いくつかのアプリケーションでは匿名化は、会計およびトラフィックエンジニアリングのための、たとえば、適用することはできません。しかし、ネットワークのユーザーのプライバシーを保護するために、匿名化は可能な限り適用されるべきです。フロー情報は、エクスポートされた後に匿名化は回収プロセスで実行された場合、多くのケースでは十分です。これは、限り、輸出の機密性を提供するよう、プライバシーの合理的な保護を提供します。
It would be desirable to request that all IPFIX exporters provide anonymization of flow records, but algorithms for anonymization are still a research issue. Several are known but the security they provide and their other properties are not yet studied sufficiently. Also, there is no standardized method for anonymization. Therefore, the requirement for the exporting process supporting anonymization is qualified with 'may' and not with 'must'.
すべてのIPFIX輸出はフローレコードの匿名化を提供していますが、匿名化のためのアルゴリズムは、まだ研究課題であることを要求することが望ましいであろう。いくつかは、知られているが、それらが提供するセキュリティやそのほかの特性はまだ十分に研究されていません。また、匿名化のための標準化された方法はありません。そのため、匿名化をサポートするエクスポート・プロセスのための要件は、WITH「しなければならない」「かもしれない」とないで修飾されています。
If anonymized flow data is exported, this must be clearly indicated to all receiving collecting processes, such that they can distinguish anonymized data from non-anonymized data.
匿名化フローデータをエクスポートする場合、これは明らかに、彼らは非匿名データから匿名データを区別できるように、すべての受信収集プロセスに指示する必要があります。
If configuration is done remotely, security should be provided for the configuration process covering confidentiality, integrity, and authenticity. The means used for remote configuration are out of the scope of this document.
設定がリモートで実行されている場合は、セキュリティは、機密性、完全性、および信頼性をカバーする設定プロセスのために提供されるべきです。リモート設定のために使用される手段は、この文書の範囲外です。
The metering process must provide a way of configuring traffic measurement. The following parameters of the metering process should be configurable:
計量プロセスは、トラフィック測定を設定する方法を提供する必要があります。計量プロセスの次のパラメータは、設定する必要があります：
1. specification of the observation point
e.g., an interface or a list of interfaces to be monitored.
2. specifications of flows to be metered
3. flow timeouts
The following parameters may be configurable:
次のパラメータが設定可能です。
4. sampling method and parameters, if feature is supported
5. overload behavior, if feature is supported
The exporting process must provide a way of configuring the data export. The following parameters of the exporting process should be configurable:
エクスポートプロセスは、データエクスポートを設定する方法を提供する必要があります。エクスポートプロセスの次のパラメータは、設定する必要があります：
1. reporting data format
Specifying the reporting data format must include a selection of attributes to be reported for each flow.
2. the collecting process(es) to which flows are reported
3. the reporting interval
This requirement only applies if the exporting process
supports reporting in regular intervals.
4. notifications to be sent to the collecting process(es)
This requirement only applies if the exporting process
supports notifications.
5. flow anonymization
This requirement only applies if the exporting process
supports flow anonymization.
IPFIX specifications should be open to future technologies. This includes extensibility of configuration of the metering process and the exporting process.
IPFIX仕様は、将来の技術に開いている必要があります。これは、計量工程およびエクスポートプロセスの構成の拡張を含んでいます。
Openness is also required concerning the extensibility of the data model, as stated in section 6.2.
セクション6.2で述べたように開放性はまた、データモデルの拡張性について必要とされます。
Data collection from hundreds of different exporting processes must be supported. The collecting process must be able to distinguish several hundred exporting processes by their identifiers.
異なるエクスポートプロセスの数百からのデータ収集はサポートされなければなりません。収集プロセスは、その識別子によって数百のエクスポートプロセスを区別できなければなりません。
The exporting process may be able to export flow information to more than one collecting process. If an exporting process is able to export flow records to multiple collecting processes then it must be able to ensure that the flow records can be identified so that duplicates can be detected between different collecting processes and double counting problems can be avoided.
エクスポートプロセスは、複数の収集プロセスにフロー情報をエクスポートすることができてもよいです。エクスポートプロセスは、複数の収集プロセスにフローレコードをエクスポートすることができている場合、重複が異なる収集プロセスの間に検出することができ、二重計算の問題を回避することができるようにフローレコードを識別できることを保証できなければなりません。
This document intends to avoid constraining the architecture of probes, routers, and other devices hosting observation points, metering processes, exporting processes, and/or collecting processes. It can be expected that typically observation point, metering process, and exporting process are co-located at a single device. However, the requirements defined in this document do not exclude devices that derive from this configuration. Figure 2 shows some examples.
この文書では、プローブ、ルータ、およびその他のデバイスの観測点をホスティング、計量プロセスのアーキテクチャを制約するプロセスをエクスポート、および/またはプロセスを収集避けることを意図しています。典型的には、観測点、計量工程、およびエクスポートプロセスを単一のデバイスに同じ場所に配置されることが期待できます。しかし、この文書で定義された要件は、この構成から派生デバイスを排除するものではありません。図2は、いくつかの例を示しています。
All examples are composed of one or more of the following elements: observation point (O), metering process (M), exporting process (E), and collecting process (C). The observation points shown in the figure are always the most fine-granular ones supported by the respective device.
工程（E）をエクスポートし、処理（C）を収集し、観測点（O）、計量工程（M）：すべての例は、以下の要素のうちの1つ以上の構成されています。図に示した観測点は、常に、それぞれのデバイスでサポートされているほとんどの細粒状のものです。
+---+ +-----+ +---------+ +---------+
| E-+-> | E--+-> | E----+-> <-+--E E--+->
| | | | | | | / \ | | | | |
| M | | M | | M M | | M M |
| | | | /|\ | | /|\ /|\ | | /|\ /|\ |
| O | | OOO | | OOO OOO | | OOO OOO |
+---+ +-----+ +---------+ +---------+
Probe Basic Complex Multiple
Router Router Exporting
Processes
+---+ +---+ +---+
| E-+-> | E-+-> | E-+------------->---+
| | | | | | | | | +---+ +-+-----+
+-+-+ | M | | M | | E-+------->-+-C-M-E-+->
| | | | | | | | | | +---+ +-+-----+
+-+-+ +-+-+ | O | | M | | E-+->---+
| | | | +---+ | | | | | |
| M | +-+-+ | O | | M |
| | | | | | +---+ | | | +-----+
| O | | O | | O | ->-+-C-E-+->
+---+ +---+ +---+ +-----+
Protocol Remote Concentrator Proxy Converter Observation
プロトコルリモートコンセントレータプロキシコンバータ観察
Figure 2: IPFIX-related Devices
図2：IPFIX関連のデバイス
A very simple device is a probe. A typical probe contains a single observation point, a single metering process, and a single exporting process.
非常に単純なデバイスは、プローブです。典型的なプローブは、単一の観測点は、単一の計量工程、および単一エクスポートプロセスを含んでいます。
A basic router extends this structure by multiple observation points. Here, the observation point of a particular flow may be one of the displayed most fine-granular observation points, but also it may be a set of them.
基本的なルータは、複数の観測点によってこの構造を拡張します。ここでは、特定のフローの観測点が表示され、ほとんどの細粒状の観測点の一つであってもよいが、それはそれらのセットであってもよいです。
A more complex router may host more than one metering process, for example one per line card. Please note that here, the observation point of a single flow cannot exceed the set of most fine-granular observation points linked to a single metering process, because only the metering process can merge packets observed at different fine- granular observation points to a joint flow. An observation point containing all most fine-granular observation points of this router is not possible with this structure. Alternatively, a complex router may host different exporting processes for flow records generated by different metering processes.
より複雑なルータは、ラインカードごとに、一例のために、複数の計量プロセスをホストすることができます。唯一の計量工程が合流に異なる微粒状の観測点で観測されたパケットをマージすることができますので、ここでは、単一の流れの観測点は、単一計量プロセスにリンクされている最も細かい粒状の観測点のセットを超えることはできませんのでご注意ください。このルータのすべての最も細かい粒状の観測点を含む観測点は、この構造では不可能です。あるいは、複合ルータは、異なる計量プロセスによって生成されたフローレコードの異なるエクスポートプロセスをホストすることができます。
A protocol converter makes use of a metering process that can be accessed only by protocol(s) other than the one defined for IPFIX, for example, the SNMP and the Meter MIB module [RFC2720]. Then the exporting process receives flow records from a remote metering process and exports these records using the IPFIX protocol. Please note that this document does not make any particular assumption on how metering processes and export processes exchange information, as long as all individual requirements for these processes are met. Also the locations of metering processes are not of any relevance for this document (in contrast to the locations of observation points and the exporting processes).
プロトコル変換器は、例えば、IPFIXのみに対して定義されたもの以外のプロトコル（単数または複数）によってアクセス可能な計量プロセスを利用して、SNMP及びMIBメーターモジュール[RFC2720]。次いで、エクスポートプロセスは、遠隔計量工程からフローレコードを受信し、IPFIXプロトコルを使用してこれらのレコードをエクスポートします。この文書は、計量プロセスと輸出プロセスがある限り、これらのプロセスのためのすべての個々の要件が満たされているとして、情報を交換する方法上の任意の特定の仮定を行いませんので、予めご了承ください。また、計量プロセスの位置は、（観測点の位置およびエクスポートプロセスとは対照的に）この文書の任意の関連性はありません。
In the example of remote packet observation in Figure 2 the metering process and the observation point are not co-located. Packet headers captured at an observation point may be exported as raw data to a device hosting metering process and exporting process. Again, this document does not make any particular assumption on how packet headers are transferred from observation points to metering processes, as long as all requirements for the metering processes are met.
図2計量工程と観測点における遠隔パケット観測の例では、共配置されていません。観測点でキャプチャパケットヘッダは、装置の計量プロセスをホストし、エクスポートプロセスに生データとしてエクスポートすることができます。ここでも、この文書では、パケットヘッダは限り計量プロセスのためのすべての要件が満たされているとして、計量プロセスに観測点から転送する方法上の任意の特定の仮定をしません。
An intermediate structure between protocol converter and remote observation (not shown in the Figure) would be a split metering process, for example performing timestamping and sampling at the device hosting the observation point and performing packet classification at another device hosting the exporting process.
プロトコル変換器と遠隔観察の中間的な構造（図には示されていない）デバイス観測点をホストし、エクスポートプロセスをホストする別のデバイスにおいてパケット分類を行うにタイムスタンプ及びサンプリングを行う、例えば、分割計量プロセスであろう。
A concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow records, and exports them again using the IPFIX protocol. Please note that for the final flow records the resulting observation point may be a superset of the more fine-granular observation points at the first level devices. The metering process of the final flow records is composed by the (partial) metering processes at the first level devices and the partial metering process at the concentrator.
集光器は、より集約フローレコードにそれらをマージし、IPFIXプロトコルを介してフローレコードを受信し、そして再びIPFIXプロトコルを使用してエクスポート。最終流量は、記録のために、得られた観測点が第1のレベルのデバイスで、より細かい粒状の観測点のスーパーセットであってもよいことに注意してください。最終的なフローレコードの計量プロセスは、最初のレベルのデバイスで（部分）計量プロセス及びコンセントレータでの部分計量プロセスによって構成されています。
Finally, a very simple IPFIX-related device is a proxy. It just receives flow records using the IPFIX protocol and sends them further using the same protocol. A proxy might be useful for traversing firewalls or other gateways.
最後に、非常に単純なIPFIX関連のデバイスは、プロキシです。それはちょうどIPFIXプロトコルを使用して、フローレコードを受信し、さらに同じプロトコルを使用してそれらを送信します。プロキシは、ファイアウォールやその他のゲートウェイを通過するのに有用である可能性があります。
An IPFIX protocol must be capable of transporting data over the public Internet. Therefore it cannot be excluded that an attacker captures or modifies packets or inserts additional packets.
IPFIXプロトコルは、公共のインターネット上でデータを輸送することが可能でなければなりません。したがって、攻撃者がキャプチャ又は修正パケットまたは追加パケットを挿入することを排除することはできません。
This section describes security requirements for IPFIX. Like other requirements, the security requirements differ among the considered applications. The incentive to modify collected data for accounting or intrusion detection for instance is usually higher than the incentive to change data collected for traffic profiling. A detailed list of the required security features per application can be found in the appendix.
このセクションでは、IPFIXのセキュリティ要件について説明します。その他の要件と同様に、セキュリティ要件が考えられ、アプリケーション間で異なります。例えば、会計や侵入検知のために収集されたデータを修正するためのインセンティブは、トラフィックプロファイリングのために収集されたデータを変更する動機よりも通常は高いです。アプリケーションごとに必要なセキュリティ機能の詳細なリストは、付録に記載されています。
The suggestion of concrete solutions for achieving the required security properties should be part of an IPFIX architecture and protocol. It is out of scope of this document. Also methods for remote configuration of the metering processes and exporting processes are out of scope. Therefore, threats that are caused by data exchange for remote configuration are not considered here.
必要なセキュリティ特性を達成するための具体的な解決策の提案はIPFIXアーキテクチャ及びプロトコルの一部であるべきです。これは、この文書の範囲外です。また、計量プロセスの遠隔構成およびエクスポートプロセスのための方法が範囲外です。そのため、リモートコンフィギュレーションのためのデータ交換によって引き起こされる脅威はここでは考慮されていません。
The following potential security hazards for an IPFIX protocol have been identified: disclosure of IP flow information, forgery of flow records, and Denial of Service (DoS) attacks.
IPFIXプロトコルのため、次の潜在的なセキュリティ上の危険が同定されている：IPフロー情報の開示、フローレコードの偽造、およびサービス拒否（DoS）攻撃を。
The content of data exchanged by an IPFIX protocol (for example IPFIX flow records) should be kept confidential between the involved parties (exporting process and collecting process). Observation of IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints and traffic patterns. This information cannot only be used to spy on user behavior but also to plan and conceal future attacks. Therefore, the requirements specified in section 6.3.3. include confidentiality of the transferred data. This can be achieved for instance by encryption.
IPFIXプロトコル（例えばIPFIXフローレコード）によって交換されるデータの内容は、関係者（プロセスをエクスポートし、収集処理）との間秘密にされるべきです。 IPFIXフローレコードの観測は、アクティブネットワークに流れる通信エンドポイントおよびトラフィックパターンについての攻撃の情報を与えます。この情報は、ユーザーの行動をスパイするだけでなく、将来の攻撃を計画して隠すために使用することはできません。したがって、要件は、セクション6.3.3で指定されました。転送されるデータの機密性が含まれます。これは、暗号化して、インスタンスのために達成することができます。
Also the privacy of users acting as sender or receiver of the measured traffic needs to be protected when they use the Internet. In many countries the right to store user-specific data (including the user's traffic profiles) is restricted by law or by regulations.
彼らはインターネットを使用する際にも測定したトラフィックの送信者や受信機として動作するユーザーのプライバシーを保護する必要があります。多くの国では（ユーザーのトラフィックプロファイルを含む）、ユーザー固有のデータを格納するための権利は、法律または規制により制限されています。
In addition to encryption, this kind of privacy can also be protected by anonymizing flow records. For many traffic flow measurements, anonymized data is as useful as precise data. Therefore, it is desirable to support anonymization in IPFIX implementations. It is beyond the scope of the IPFIX Working Group to develop and standardize anonymization methods. However, the requirements for extensibility of the IPFIX protocol are sufficient to support anonymized flow records when appropriate methods are standardized.
暗号化に加えて、プライバシーのこの種はまた、フローレコードを匿名化により保護することができます。多くのトラフィック・フローの測定のために、匿名データは、正確なデータとしてとして有用です。したがって、IPFIX実装で匿名化をサポートすることが望ましいです。これは、匿名化方法を開発し、標準化するIPFIXワーキンググループの範囲を超えています。しかし、IPFIXプロトコルの拡張のための要件は、適切な方法が標準化されているときに匿名化フローレコードをサポートするのに十分です。
If flow records are used in accounting and/or security applications, there are potentially strong incentives to forge exported IPFIX flow records (for example, to save money or prevent the detection of an attack). This can be done either by altering flow records on the path or by injecting forged flow records that pretend to be originated by the original exporting process.
フローレコードは、会計および/またはセキュリティアプリケーションで使用されている場合は、（お金を保存したり、攻撃の検出を防止するために、例えば）にエクスポートIPFIXフローレコードを偽造する可能性の強いインセンティブがあります。これは、パス上のフローレコードを変更することによって、または、元のエクスポートプロセスによって発信されるふり鍛造フローレコードを注入することによってのいずれかで行うことができます。
Special caution is required if security applications rely on flow measurements. With forged flow records it is possible to trick security applications. For example, an application may be lead to falsely conclude that a DoS attack is in progress. If such an injection of IPFIX traffic flow records fools the security application, causing it to erroneously conclude that a DoS attack is underway, then the countermeasures employed by the security application may actually deny useful non-malicious services.
セキュリティアプリケーションは、流量測定に依存している場合は特別な注意が必要です。鍛造フローレコードで、セキュリティアプリケーションをだますことが可能です。例えば、アプリケーションが誤ってDoS攻撃が進行中であることを結論を導くことができます。 IPFIXトラフィックフローレコードの、このような注入は、それが誤ってDoS攻撃が進行中であると結論させ、セキュリティアプリケーションを愚か者場合、セキュリティアプリケーションによって使用される対策は、実際に有用な非悪意のサービスを拒否することができます。
In order to make an IPFIX protocol resistant against such attacks, authentication and integrity must be provided, as specified in section 6.3.3.
セクション6.3.3で指定されるように、このような攻撃に対するIPFIXプロトコル耐性にするために、認証と完全性は、提供されなければなりません。
DoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect the IPFIX protocol and impair the sending of IPFIX records. Nevertheless, since such hazards are not induced specifically by the IPFIX protocol the prevention of such attacks is out of scope of this document.
IPFIXプロトコルが実装されているルータや他のミドルボックス上のDoS攻撃もIPFIXプロトコルに影響し、IPFIXレコードの送信を損ないます。そのような危険がIPFIXプロトコルによって特異的に誘導されていないので、それにも関わらず、このような攻撃の防止は、この文書の範囲外です。
However, IPFIX itself also causes potential hazards for DoS attacks. All processes that expect the reception of traffic can be target of a DoS attack. With the exporting process this is only the case if it supports the pull mode (which can be an optional feature of the IPFIX protocol according to this document). The collecting process always expects data and therefore can be flooded by flow records.
しかし、IPFIX自体もDoS攻撃のための潜在的な危険の原因となります。トラフィックの受信を期待するすべてのプロセスは、DoS攻撃のターゲットになることができます。それは（この文書に係るIPFIXプロトコルのオプション機能であることができる）、プル・モードをサポートしている場合、エクスポートプロセスでこれが唯一のケースです。収集プロセスは、常にデータを期待し、したがって、フローレコードによって浸水することができます。
Many thanks to Georg Carle for contributing to the application analysis, to K.C. Norseth for several fine-tunings, to Sandra Tartarelli for checking the appendix, and to a lot of people on the mailing list for providing valuable comments and suggestions including Nevil Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and many more.
K.C.に、アプリケーション分析に貢献するためのゲオルグ・カールに感謝いくつかの細かいチューニングのために、サンドラTartarelliの付録をチェックするため、およびメーリングリストの多くの人々にNevilブラウンリー、カーターブラード、ポールCalato、ラムゴパル、タルGivoly、ジェフ・メイヤーなどの貴重な意見や提案を提供するためのNorseth、レイナルドPenno、ソニアパンチェン、サイモンLeinen、デビッドPlonka、ガネーシャSadasivan、ケビン・チャン、そしてより多くの。
The following table documents, how the requirements stated in sections 3-7 are derived from requirements of the applications listed in section 2.
セクション3-7で述べた要件は、セクション2に記載されているアプリケーションの要件から派生する方法を次の表文書、。
Used abbreviations: M = must S = should O = may (optional) - = DONT CARE
使用される略語：M =なければなりませんS =べきO =は、（オプション） - = DONT CARE
-----------------------------------------------------------------------.
IPFIX |
----------------------------------------------------------------. |
E: QoS Monitoring | |
----------------------------------------------------------. | |
D: Attack/Intrusion Detection | | |
----------------------------------------------------. | | |
C: Traffic Engineering | | | |
----------------------------------------------. | | | |
B: Traffic Profiling | | | | |
----------------------------------------. | | | | |
A: Usage-based Accounting | | | | | |
----------------------------------. | | | | | |
| | | | | | |
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | DISTINGUISHING FLOWS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | Combination of | M | M | M | M | M | M |
| | required attributes | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.1. | in/out IF | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | Masking of IP addresses | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | version field | - | S | S | O | O | S |
| | | | | (b) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.3. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.4. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.5. | DSCP (a) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5. | METERING PROCESS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.1. | Reliability | M | S | S | S | S | |
|-------+-------------------------+-----+-----+-----+-----+-----+ M |
| 5.1. | Indication of | - | M | M | M | M | |
| | missing reliability | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.2. | Sampling (d,e) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.3. | Overload Behavior (f) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.4. | Timestamps | M | O | O | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.5. | Time synchronization | M | S | S | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.6. | Flow timeout | M | S | - | O | O | M |
| | | (g) | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.7. | Multicast flows | S | O | O | O | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.8. | Packet fragmentation | O | O | - | - | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.9. | Ignore port copy | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6. | DATA EXPORT |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | INFORMATION MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP Version | - | M | M | O | O | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Packet counter (h) | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Byte counter | M | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M |
| | class octet (IPv6) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Flow Label (IPv6) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Timestamps for | M | O | O | S | S | M |
| | first/last packet | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Sampling configuration | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | observation point | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | export process | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ICMP type and code (i) | S | S | - | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | input/output interface | S | S | S | S | S | S |
| | (j) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Multicast | O | S | S | - | S | S |
| | replication factor | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TTL | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP header flags | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TCP header flags | - | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Dropped Packet | O | O | O | O | O | O |
| | Counter (h,k) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Fragment counter | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | next hop IP address | O | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src / dst / next hop | - | O | O | - | - | O |
| | BGP AS # | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | DATA MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Flexibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Extensibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3. | DATA TRANSFER |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.1.| Congestion aware | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.2.| Reliability | M | S | S | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.3.| Confidentiality | M | S | S | M | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.4.| Integrity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.5.| Authenticity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | REPORTING TIMES |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Push mode | M | O | O | M | S | M |
| | | | (l) | (l) | |(l,m)| |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Pull mode | O | O | O | O | O | O |
| | | | (l) | (l) | | (l) | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4.1.| Regular interval | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.6. | Notifications | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.7. | Anonymization (n) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | CONFIGURATION |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | Secure remote | S | S | S | S | S | S |
| | configuration (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config observation point| S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow | S | S | S | S | S | S |
| | specifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow timeouts | S | S | S | S | O | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config sampling | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config overload | O | O | O | O | O | O |
| | behavior (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config report | S | S | S | S | S | S |
| | data format | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config | S | S | S | S | S | S |
| | notifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8. | GENERAL REQUIREMENTS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.1. | Openness | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.2. | Scalability: | | | | | | |
| | data collection | M | S | M | O | S | M |
| | from hundreds of | | | | | | |
| | measurement devices | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.3. | Several collectors | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
Remarks:
備考：
(a) If feature is supported. (b) The differentiation of IPv4 and IPv6 is for TE of importance. So we tended to make this a must. Nevertheless, a should seems to be sufficient to perform most TE tasks and allows us to have a should for IPFIX instead of a must. (c) For TE in an MPLS network the label is essential. Therefore a must is given here leading to a must in IPFIX. (d) If sampling is supported, the methods and parameters must be well defined. (e) If sampling is supported, sampling configuration changes must be indicated to all collecting processes. (f) If overload behavior is supported and it induces changes in the metering process behavior, the overload behavior must be clearly defined. (g) Precise time-based accounting requires reaction to a flow timeout. (h) If a packet is fragmented, each fragment is counted as an individual packet. (i) If protocol type is ICMP.
（a）の機能がサポートされている場合。 （b）は、IPv4とIPv6の分化が重要TEのためのものです。だから我々は、この必須にする傾向が見られました。それにもかかわらず、ほとんどのTEのタスクを実行するのに十分であるように思われると私たちはIPFIXのためのSHOULD代わりの必須を持つことができなければなりません。 MPLSネットワークにおけるTEの場合（c）は、ラベルが不可欠です。したがって、必須はIPFIXで必須につながる、ここで与えられています。 （D）サンプリングがサポートされている場合、方法及びパラメータが明確に定義されなければなりません。サンプリングがサポートされている場合（e）は、サンプリング設定の変更は、すべての収集プロセスに示されなければなりません。過負荷の動作がサポートされ、それは、計量プロセス挙動の変化を誘導する場合（F）、過負荷動作は明確に定義されなければなりません。 （g）の正確な時間ベースの課金は、フロータイムアウトに反応を必要とします。 （H）パケットが断片化されている場合、各フラグメントは、個々のパケットとしてカウントされます。 （I）プロトコル種別がICMPである場合。
(j) This requirement does not apply if the observation point is located at a probe device. (k) Only if measurement is done on data path i.e., has access to forwarding decision. (l) Either push or pull has to be supported. (m) Required, in order to immediately report drop indications for SLA validation. (n) Anonymization must be clearly indicated to all receiving collecting processes.
観測点は、プローブ装置に配置されている場合（J）この要件は適用されません。測定は、データパス、すなわち上で行われる場合にのみ（k）は、転送決定へのアクセスを有します。 （L）プッシュまたはプルのいずれかがサポートされなければなりません。 （m）は、直ちにSLAの検証のためのドロップ兆候を報告するために、必要です。 （n）を匿名化は、明らかに、すべての受信回収プロセスに示されなければなりません。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[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月。
[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月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）" [RFC3418] Presuhn、R.、。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RFC2720]ブラウンリー、N.、 "トラフィックフロー測定：メーターMIB"、RFC 2720、1999年10月。
Juergen Quittek NEC Europe Ltd., Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパ社ネットワーク研究所Kurfuerstenコンディショニング36 69115ハイデルベルク、ドイツ
Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de
電話：+49 6221 90511 15電子メール：quittek@netlab.nec.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany
オープン通信システムのためのターニャZsebyフラウンホーファー研究所（FOKUS）皇后-オーガスタダレ31 10589ベルリンドイツ
Phone: +49 30 3463 7153 EMail: zseby@fokus.fhg.de
電話：+49 30 3463 7153 Eメール：zseby@fokus.fhg.de
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
ブノワClaiseシスコシステムズデKleetlaan 6aはB1 1831ディーゲムベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com
Sebastian Zander Centre for Advanced Internet Architectures, Mail H31 Swinburne University of Technology PO Box 218 John Street, Hawthorn Victoria 3122, Australia
高度なインターネットアーキテクチャ、メールH31スウィンバーン工科大学の私書箱218ジョンストリート、ホーソンビクトリア3122、オーストラリアのためのセバスチャンザンダーセンター
Phone: +61 3 9214 8089 EMail: szander@swin.edu.au
電話：+61 3 9214 8089 Eメール：szander@swin.edu.au
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。