[要約] RFC 3917は、IP Flow Information Export（IPFIX）の要件を定義しており、IPフロー情報のエクスポートに関する標準化を目指しています。IPFIXは、ネットワークトラフィックのモニタリングや分析に役立つ情報を収集するためのプロトコルです。
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)
IPフロー情報エクスポート（IPFIX）の要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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. 1つ以上のパケットヘッダーフィールド（例：宛先IPアドレス）、トランスポートヘッダーフィールド（例：宛先ポート番号）、またはアプリケーションヘッダーフィールド（例：RTPヘッダーフィールド[RFC3550]）
2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc.)
2. パケット自体の1つ以上の特性（例：MPLSラベルの数など）
3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc.)
3. パケットトリートメントから派生した1つ以上のフィールド（次のホップIPアドレス、出力インターフェイスなど）
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.
1つの観測点は、他のいくつかの観測点のスーパーセットである可能性があることに注意してください。たとえば、1つの観測点は、ラインカード全体にすることができます。これは、ラインカードのインターフェイスでの個々の観測ポイントのスーパーセットになります。
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つ以上の収集プロセスに送信します。フローレコードは、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月））は、特定の実装や特定のアプリケーションシナリオで異なる場合があります。したがって、選択したアプリケーションの一般的な機能から要件を導き出します。一部の特定のケースでは、このドキュメントで定義されている要件よりも厳しい要件を義務付けています。たとえば、使用法ベースの会計は、おそらく以下で説明するアプリケーションの中で最も高い信頼性を義務付けるアプリケーションです。セクション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）攻撃の場合、フロー監視により、異常な状況または疑わしいフローの検出が可能になります。2番目のステップでは、攻撃フローに関する情報を収集し、防御戦略を導き出すために、フロー分析を実行できます。
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分析のためにネットワーク内の既存のトラフィックを利用します。テストトラフィックは送信されないため、パッシブ測定は、ネットワーク内に関心のあるトラフィックがすでに存在する状況でのみ適用できます。アプリケーションの1つは、サービスレベルの仕様でネゴシエートされた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の要件を満たすことは、一般的に計量プロセスがその構成を介して、特定の状況/特定のアプリケーションの場合でも、すべての必須フィールドを介してフローを区別するために何らかの形でサポートできることを意味します。フィールドが必要であり、流れを区別するために効果的に使用されます。
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ヘッダーのTTLフィールドやIP宛先アドレスのBGP自律システム番号[RFC1771]など、いくつかの追加パラメーターでフローを区別する必要があります。
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ヘッダーの次のフィールドでフローを分離できる必要があります。
1. source IP address
1. ソースIPアドレス
2. destination IP address 3. protocol type (TCP, UDP, ICMP, ...)
2. 宛先IPアドレス3.プロトコルタイプ（TCP、UDP、ICMP、...）
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]の1つでなければなりません。これは1世紀です。
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つの異なるフローレコードの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.
このセクションには、エクスポートプロセスが報告する必要がある、、または報告できる場合、または報告できる場合、または属性がリストされています。これは、各エクスポートされたフローレコードに必要なすべての属性が含まれている必要があることを意味するものではありません。しかし、それは、すべての必要な属性の情報をエクスポートプロセスから各エクスポートフローの受信収集プロセスに送信できるように、エクスポートプロセスを構成することが可能であることを意味します。
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.
1. IPバージョン番号この要件は、観測点が複数のバージョンの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ペイロードをカバーしています。9.サービスの種類Octet（IPv4の場合）、トラフィッククラスOctet（IPv6の場合）。[RFC2474]によると、これらのオクテットには、6ビットの長さのdiffservコードポイントが含まれています。10. IPv6の場合：フローラベル11.観測点でMPLSがサポートされている場合：TOP MPLSラベルまたは対応する転送等価クラス（FEC、[RFC3031]）がそのラベルにバインドされています。FECは通常、IPプレフィックスによって定義されます。12.フローの最初のパケットのタイムスタンプ13.フローの最後のパケットのタイムスタンプ14.サンプリングが使用される場合：サンプリング構成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.マルチキャスト複製係数単一の着信マルチキャストパケットに由来する発信パケットの数。これは、マルチキャストフローの動的な特性であり、時間とともに変化する可能性があります。ユニキャストフローの場合、それは一定の値です。報告された値は、フローレコードがエクスポートされた時点での係数の値でなければなりません。
The exporting process may be able to report the following attributes for each metered flow:
エクスポートプロセスは、メーターのフローごとに次の属性を報告できる場合があります。
21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6) 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
21. ライブ（IPv4の場合）またはホップ制限（IPv6の場合）（IPv6の場合）22。IPヘッダーフラグ23. TCPヘッダーフラグ24.パケットが断片化されている場合、各フラグメントをカウントする必要があります。個々のパケット。25.断片化されたビットがIPヘッダーに設定されているすべてのパケットの断片化されたパケットカウンター26.次のホップIPアドレス27.ソースBGP自律システム番号（[RFC1771]を参照））28。宛先BGP自律システム番号29.次のホップ。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. プロセスの制限の収集：混雑が発生している可能性があり、新しいFlowsレコードをバッファリングできない場合があります。
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輸出業者がフローレコードの匿名化を提供することを要求することが望ましいでしょうが、匿名化のためのアルゴリズムは依然として研究の問題です。いくつかは知られていますが、彼らが提供するセキュリティと彼らの他のプロパティはまだ十分に研究されていません。また、匿名化のための標準化された方法はありません。したがって、匿名化をサポートするエクスポートプロセスの要件は、「Must」ではなく「May」で資格があります。
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
1. 監視するインターフェイスまたはインターフェイスのリストなど、観測点の仕様。2.メーターになるフローの仕様3.フロータイムアウト
The following parameters may be configurable:
次のパラメーターが構成可能である場合があります。
4. sampling method and parameters, if feature is supported 5. overload behavior, if feature is supported
4. サンプリング方法とパラメーター、機能がサポートされている場合5.過負荷動作、機能がサポートされている場合
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.
1. レポートデータ形式レポートデータ形式を指定すると、各フローについて報告する属性の選択を含める必要があります。2.フローが報告される収集プロセス（ES）3。レポート間隔この要件は、エクスポートプロセスが通常の間隔でレポートをサポートする場合にのみ適用されます。4.収集プロセスに送信される通知この要件は、エクスポートプロセスが通知をサポートしている場合にのみ適用されます。5.フロー匿名化この要件は、エクスポートプロセスがフローの匿名化をサポートしている場合にのみ適用されます。
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.
すべての例は、次の1つ以上の要素で構成されています：観測点（O）、メータリングプロセス（M）、エクスポート（E）、および収集プロセス（C）。図に示されている観測点は、常にそれぞれのデバイスによってサポートされる最も細かい粒状のポイントです。
+---+ +-----+ +---------+ +---------+
| 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.
基本的なルーターは、この構造を複数の観測点で拡張します。ここでは、特定のフローの観測点は、表示される最も細かい観測点の1つである可能性がありますが、それらのセットである可能性があります。
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.
より複雑なルーターは、ラインカードごとに1つ以上のメータープロセスをホストする場合があります。ここでは、単一のフローの観測点は、単一のメータープロセスにリンクされた最も細かい粒状観測点のセットを超えることはできません。。この構造では、このルーターのすべての最も細かい粒状観測点を含む観測点は不可能です。あるいは、複雑なルーターは、異なるメータープロセスによって生成されたフローレコードのさまざまなエクスポートプロセスをホストする場合があります。
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).
プロトコルコンバーターは、たとえばSNMPおよびMeter MIBモジュール[RFC2720]など、IPFIXで定義されたプロトコル以外のプロトコルでのみアクセスできる計測プロセスを使用します。次に、エクスポートプロセスはリモートメータープロセスからフローレコードを受信し、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 Flow Records）によって交換されるデータの内容は、関係者間で機密を保持する必要があります（プロセスのエクスポートと収集プロセス）。IPFIX Flow Recordsの観察により、ネットワーク内のアクティブなフロー、通信エンドポイント、トラフィックパターンに関する攻撃者情報が提供されます。この情報は、ユーザーの動作をスパイするだけでなく、将来の攻撃を計画および隠すために使用することはできません。したがって、セクション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.
セキュリティアプリケーションがフロー測定に依存している場合は、特に注意が必要です。Forged Flow Recordsを使用すると、セキュリティアプリケーションをトリックすることができます。たとえば、アプリケーションは、DOS攻撃が進行中であると誤って結論付けることができます。IPFix Traffic Flow Recordsのこのような注入がセキュリティアプリケーションを欺き、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.へのアプリケーション分析に貢献してくれたGeorg Carleに感謝します。いくつかの微調整、サンドラ・タルタレッリへの付録をチェックするために、そしてネビル・ブラウンリー、カーター・ブラード、ポール・カラート、ラム・ゴパル、タル・ギボリー、ジェフ・マイヤー、ジェフ・マイヤーなどの貴重なコメントや提案を提供するためにメーリングリストの多くの人々にReinaldo Penno、Sonia Panchen、Simon Leinen、David Plonka、Ganesh Sadasivan、Kevin Zhangなど。
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 = may（optional） - =気にしないでください
-----------------------------------------------------------------------.
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の必要性を持つことができます。（c）MPLSネットワーク内のTEの場合、ラベルは不可欠です。したがって、ここで必須が与えられ、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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Frederick、R。、およびV. Jacobson、「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. Harrington、「会計管理の紹介」、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.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「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. Li、「A Border Gateway Protocol 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.
[RFC3418] Presuhn、R。、「単純なネットワーク管理プロトコル（SNMP）の管理情報基盤（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RFC2720]ブラウンリー、N。、「トラフィックフロー測定：Meter MIB」、RFC 2720、1999年10月。
Juergen Quittek NEC Europe Ltd., Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany
Juergen Quittek Nec Europe Ltd.、Network Laboratories Kurfuersten-Anlage 36 69115 Heidelbergドイツ
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany
Tanja Zseby Fraunhofer Institute for Open Communication Systems（Fokus）Kaiserin-Augusta-Allee 31 10589ベルリンドイツ
Phone: +49 30 3463 7153
EMail: zseby@fokus.fhg.de
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems de Kleetlaan 6a B1 1831 Diegem Belgium
Phone: +32 2 704 5622
EMail: 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
Sebastian Zander Center for Advanced Internet Architectures、Mail H31 Swinburne University of Technology PO Box 218 John Street、ホーソーンビクトリア3122、オーストラリア
Phone: +61 3 9214 8089
EMail: szander@swin.edu.au
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。