[要約] RFC 5101は、IPトラフィックフロー情報の交換のためのIP Flow Information Export（IPFIX）プロトコルの仕様を定めています。このRFCの目的は、ネットワーク管理者がネットワークトラフィックの詳細な情報を収集し、分析するための標準的な方法を提供することです。
Network Working Group B. Claise, Ed.
Request for Comments: 5101 Cisco Systems, Inc.
Category: Standards Track January 2008
Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの指定
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.
このドキュメントは、ネットワーク上でIPトラフィックフロー情報を送信するのに役立つIPフロー情報エクスポート（IPFIX）プロトコルを指定します。IPトラフィックフロー情報をエクスポートプロセスから情報収集プロセスに送信するには、フローデータの一般的な表現とそれらを通信する標準的な手段が必要です。このドキュメントでは、IPFIXデータとテンプレートレコードが、IPFIXのエクスポートプロセスからIPFIXの収集プロセスへの多数のトランスポートプロトコルにどのように掲載されるかについて説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................9
3. IPFIX Message Format ...........................................10
3.1. Message Header Format .....................................11
3.2. Field Specifier Format ....................................13
3.3. Set and Set Header Format .................................14
3.3.1. Set Format .........................................14
3.3.2. Set Header Format ..................................15
3.4. Record Format .............................................16
3.4.1. Template Record Format .............................16
3.4.2. Options Template Record Format .....................18
3.4.2.1. Scope .....................................19
3.4.2.2. Options Template Record Format ............20
3.4.3. Data Record Format .................................22
4. Specific Reporting Requirements ................................23
4.1. The Metering Process Statistics Option Template ...........23
4.2. The Metering Process Reliability Statistics Option
Template ..................................................24
4.3. The Exporting Process Reliability Statistics
Option Template ...........................................25
4.4. The Flow Keys Option Template .............................26
5. IPFIX Message Header "Export Time" and Flow Record Time ........27
6. Linkage with the Information Model .............................28
6.1. Encoding of IPFIX Data Types ..............................28
6.1.1. Integral Data Types ................................28
6.1.2. Address Types ......................................28
6.1.3. float32 ............................................28
6.1.4. float64 ............................................28
6.1.5. boolean ............................................28
6.1.6. string and octetarray ..............................28
6.1.7. dateTimeSeconds ....................................29
6.1.8. dateTimeMilliseconds ...............................29
6.1.9. dateTimeMicroseconds ...............................29
6.1.10.dateTimeNanoseconds.................................29
6.2. Reduced Size Encoding of Integer and Float Types ..........29
7. Variable-Length Information Element ............................30
8. Template Management ............................................31
9. The Collecting Process's Side ..................................34
10. Transport Protocol ............................................36
10.1. Transport Compliance and Transport Usage .................36
10.2. SCTP .....................................................37
10.2.1. Congestion Avoidance ..............................37
10.2.2. Reliability .......................................37
10.2.3. MTU ...............................................37
10.2.4. Exporting Process .................................38
10.2.4.1. Association Establishment ................38
10.2.4.2. Association Shutdown .....................38
10.2.4.3. Stream ...................................38
10.2.4.4. Template Management ......................39
10.2.5. Collecting Process ................................39
10.2.6. Failover ..........................................39
10.3. UDP ......................................................39
10.3.1. Congestion Avoidance ..............................39
10.3.2. Reliability .......................................40
10.3.3. MTU ...............................................40
10.3.4. Port Numbers ......................................40
10.3.5. Exporting Process .................................40
10.3.6. Template Management ...............................40
10.3.7. Collecting Process ................................41
10.3.8. Failover ..........................................42
10.4. TCP ......................................................42
10.4.1. Connection Management .............................42
10.4.1.1. Connection Establishment .................42
10.4.1.2. Graceful Connection Release ..............43
10.4.1.3. Restarting Interrupted Connections .......43
10.4.1.4. Failover .................................43
10.4.2. Data Transmission .................................43
10.4.2.1. IPFIX Message Encoding ...................43
10.4.2.2. Template Management ......................44
10.4.2.3. Congestion Handling and Reliability ......44
10.4.3. Collecting Process ................................45
11. Security Considerations .......................................46
11.1. Applicability of TLS and DTLS ............................47
11.2. Usage ....................................................48
11.3. Authentication ...........................................48
11.4. Protection against DoS Attacks ...........................48
11.5. When DTLS or TLS Is Not an Option ........................50
11.6. Logging an IPFIX Attack ..................................50
11.7. Securing the Collector ...................................51
12. IANA Considerations ...........................................51
Appendix A. IPFIX Encoding Examples ...............................52
A.1. Message Header Example.....................................52
A.2. Template Set Examples......................................53
A.2.1. Template Set Using IETF-Specified Information
Elements ...........................................53
A.2.2. Template Set Using Enterprise-Specific Information
Elements ...........................................53
A.3. Data Set Example ..........................................55
A.4. Options Template Set Examples .............................56
A.4.1. Options Template Set Using IETF-Specified
Information Elements ...............................56
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ...............................56
A.4.3. Options Template Set Using an Enterprise-Specific
Scope ..............................................57
A.4.4. Data Set Using an Enterprise-Specific Scope ........58
A.5. Variable-Length Information Element Examples ..............59
A.5.1. Example of Variable-Length Information Element
with Length Inferior to 255 Octets .................59
A.5.2. Example of Variable-Length Information Element
with Length 255 to 65535 Octets ....................59
References ........................................................59
Normative References ...........................................59
Informative References .........................................60
Acknowledgments ...................................................61
A data network with IP traffic primarily consists of IP flows passing through the network elements. It is often interesting, useful, or even required to have access to information about these flows that pass through the network elements for administrative or other purposes. The IPFIX Collecting Process should be able to receive the flow information passing through multiple network elements within the data network. This requires uniformity in the method of representing the flow information and the means of communicating the flows from the network elements to the collection point. This document specifies the protocol to achieve these aforementioned requirements. This document specifies in detail the representation of different flows, the additional data required for flow interpretation, packet format, transport mechanisms used, security concerns, etc.
IPトラフィックを備えたデータネットワークは、主にネットワーク要素を通過するIPフローで構成されています。多くの場合、それは、管理またはその他の目的のためにネットワーク要素を通過するこれらのフローに関する情報にアクセスするために、興味深い、有用であるか、さらには必要です。IPFIXの収集プロセスは、データネットワーク内の複数のネットワーク要素を通過するフロー情報を受信できるはずです。これには、フロー情報を表す方法と、ネットワーク要素からコレクションポイントへのフローを通信する手段の均一性が必要です。このドキュメントは、これらの前述の要件を達成するためのプロトコルを指定します。このドキュメントは、さまざまなフローの表現、フローの解釈に必要な追加データ、パケット形式、使用される輸送メカニズム、セキュリティの懸念などを詳細に指定しています。
The IPFIX protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [IPFIX-ARCH], per the requirements defined in [RFC3917]. This document specifies how IPFIX data records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in [RFC5102]. Finally, [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
IPFIXプロトコルは、ネットワーク管理者にIPフロー情報へのアクセスを提供します。[RFC3917]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャが[IPFix-Arch]で定義されます。このドキュメントでは、IPFIXデータレコードとテンプレートが、IPFIXのエクスポートプロセスからIPFIXの収集プロセスへの多数のトランスポートプロトコルを介してどのように携帯されるかを指定します。IPFIXには、[RFC5102]で指定されているように、IPFIX情報要素、その名前、タイプ、および追加のセマンティック情報の正式な説明があります。最後に、[IPFIX-AS]は、IPFIXプロトコルを使用できるアプリケーションの種類と、提供された情報をどのように使用できるかを説明します。さらに、IPFIXフレームワークが他のアーキテクチャとフレームワークとどのように関連するかを示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The definitions of the basic terms like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. are semantically identical to those found in the IPFIX requirements document [RFC3917]. Some of the terms have been expanded for more clarity when defining the protocol. Additional terms required for the protocol have also been defined. Definitions in this document and in [IPFIX-ARCH] are equivalent, except that definitions that are only relevant to the IPFIX protocol only appear here.
IPトラフィックフロー、エクスポートプロセス、プロセスの収集、観測ポイントなどの基本的な用語の定義は、IPFIX要件ドキュメント[RFC3917]にあるものと意味的に同一です。一部の用語は、プロトコルを定義する際に、より明確に拡張されています。プロトコルに必要な追加の用語も定義されています。このドキュメントおよび[IPFIX-ARCH]の定義は同等ですが、IPFIXプロトコルにのみ関連する定義はここにのみ表示されます。
The terminology summary table in Section 2.1 gives a quick overview of the relationships between some of the different terms defined.
セクション2.1の用語の要約表は、定義された異なる用語のいくつかの関係の概要を簡単に概説します。
Observation Point
観測点
An Observation Point is a location in the network where IP packets can be observed. Examples include: 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 every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces.
すべての観測点は観測ドメイン（以下に定義）に関連付けられており、1つの観測点は他のいくつかの観測点のスーパーセットである可能性があることに注意してください。たとえば、1つの観測点は、ラインカード全体にすることができます。これは、ラインカードのインターフェイスでの個々の観測ポイントのスーパーセットです。
Observation Domain
観察ドメイン
An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device.
観測ドメインは、メータープロセスによってフロー情報を集約できる最大の観測点です。たとえば、ルーターラインカードは、いくつかのインターフェイスで構成されている場合、観測ドメインである場合があります。それぞれが観測点です。生成するIPFIXメッセージには、観測ドメインには観測ドメインIDが含まれています。これは、エクスポートごとに一意のプロセスです。そうすれば、収集プロセスは、IPFIXメッセージを送信する輸出業者から特定の観測ドメインを識別できます。すべての観測点は、観測ドメインに関連付けられています。観測ドメインIDは、IPFIXデバイスごとに一意にすることをお勧めします。
IP Traffic Flow or Flow
IPトラフィックフローまたはフロー
There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition:
インターネットコミュニティが使用する「フロー」という用語の定義はいくつかあります。IPFIXのコンテキスト内で、次の定義を使用します。
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 fields (e.g., destination IP address), transport header fields (e.g., destination port number), or application header fields (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 as belonging 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. It includes packets selected by a sampling mechanism.
この定義は、ネットワークインターフェイスで観察されたすべてのパケットを含むフローから、2つのアプリケーション間の単一のパケットのみで構成されるフローまでの範囲をカバーします。サンプリングメカニズムによって選択されたパケットが含まれています。
Flow Key
FlowKey
Each of the fields that:
それぞれのフィールド：
1. belong to the packet header (e.g., destination IP address),
1. パケットヘッダーに属します（例：宛先IPアドレス）、
2. are a property of the packet itself (e.g., packet length),
2. パケット自体（パケットの長さなど）のプロパティです。
3. are derived from packet treatment (e.g., Autonomous System (AS) number),
3. パケット処理（たとえば、自律システム（AS）数）に由来します。
and that are used to define a Flow are termed Flow Keys.
そして、それはフローを定義するために使用されますフローキーと呼ばれます。
Flow Record
フローレコード
A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g., source IP address).
フローレコードには、観測点で観察された特定のフローに関する情報が含まれています。フローレコードには、フローの測定された特性（たとえば、すべてのフローのパケットのバイトの総数）と、通常、フローの特徴的な特性（例：ソースIPアドレス）が含まれます。
Metering Process
計量プロセス
The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics 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.
フローレコードのメンテナンスには、新しいレコードの作成、既存のレコードの更新、フロー統計の計算、さらなるフロープロパティの導出、フローの有効期限の検出、エクスポートプロセスへのフローレコードの渡し、フローレコードの削除が含まれます。
Exporting Process
エクスポートプロセス
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つ以上の計量プロセスによって生成されます。
Exporter
輸出業者
A device that hosts one or more Exporting Processes is termed an Exporter.
1つ以上のエクスポートプロセスをホストするデバイスは、輸出者と呼ばれます。
IPFIX Device
IPFIXデバイス
An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes.
IPFIXデバイスは、少なくとも1つのエクスポートプロセスをホストします。さらに、プロセスをさらにエクスポートし、任意の数の観測ポイントと計量プロセスをホストする場合があります。
Collecting Process
収集プロセス
A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but such actions are out of scope for this document.
収集プロセスは、1つ以上のエクスポートプロセスからフローレコードを受信します。収集プロセスは受信したフロー記録を処理または保存する可能性がありますが、このようなアクションはこのドキュメントの範囲外です。
Collector
A device that hosts one or more Collecting Processes is termed a Collector.
1つ以上の収集プロセスをホストするデバイスは、コレクターと呼ばれます。
Template
レンプレート
A Template is an ordered sequence of <type, length> pairs used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID.
テンプレートは、IPFIXデバイスからコレクターに伝える必要がある特定の情報セットの構造とセマンティクスを完全に指定するために使用される<タイプ、長さ>ペアの順序付けられたシーケンスです。各テンプレートは、テンプレートIDを使用して一意に識別できます。
IPFIX Message
ipfixメッセージ
An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer.
Message Header
メッセージヘッダー
The Message Header is the first part of an IPFIX Message, which provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc.
メッセージヘッダーは、IPFIXメッセージの最初の部分であり、メッセージに関する基本情報、IPFIXバージョン、メッセージの長さ、メッセージシーケンス番号などを提供します。
Template Record
テンプレートレコード
A Template Record defines the structure and interpretation of fields in a Data Record.
テンプレートレコードは、データレコード内のフィールドの構造と解釈を定義します。
Data Record
データレコード
A Data Record is a record that contains values of the parameters corresponding to a Template Record.
データレコードは、テンプレートレコードに対応するパラメーターの値を含むレコードです。
Options Template Record
オプションテンプレートレコード
An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record.
オプションテンプレートレコードは、データレコード内のフィールドの構造と解釈を定義するテンプレートレコードです。
Set
設定
Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header.
セットは、類似した構造を持つレコードのコレクションの一般的な用語です。IPFIXメッセージでは、1つ以上のセットがメッセージヘッダーに従います。
There are three different types of Sets: Template Set, Options Template Set, and Data Set.
Template Set
テンプレートセット
A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message.
テンプレートセットは、IPFIXメッセージにグループ化された1つ以上のテンプレートレコードのコレクションです。
Options Template Set
オプションテンプレート設定
An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message.
オプションテンプレートセットは、IPFIXメッセージにグループ化された1つ以上のオプションテンプレートレコードのコレクションです。
Data Set
データセット
A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record.
データセットは、同じタイプの1つ以上のデータレコードであり、IPFIXメッセージにグループ化されています。各データレコードは、以前にテンプレートレコードまたはオプションテンプレートレコードによって定義されています。
Information Element
情報要素
An Information Element is a protocol and encoding-independent description of an attribute that may appear in an IPFIX Record. The IPFIX information model [RFC5102] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX.
情報要素は、IPFIXレコードに表示される可能性のある属性のプロトコルとエンコードに依存しない説明です。IPFIX情報モデル[RFC5102]は、IPFIXの情報要素のベースセットを定義します。情報要素に関連付けられているタイプは、それに含まれるものに対する制約を示し、IPFIXで使用する有効なエンコーディングメカニズムも決定します。
Transport Session
交通セッション
In Stream Control Transmission Protocol (SCTP), the transport session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC4960]; in TCP, the transport session is known as the TCP connection, which is uniquely identified by the combination of IP addresses and TCP ports used. In UDP, the transport session is known as the UDP session, which is uniquely identified by the combination of IP addresses and UDP ports used.
ストリーム制御伝送プロトコル（SCTP）では、トランスポートセッションはSCTPアソシエーションとして知られており、SCTPエンドポイント[RFC4960]によって一意に識別されます。TCPでは、トランスポートセッションはTCP接続として知られています。これは、使用されるIPアドレスとTCPポートの組み合わせによって一意に識別されます。UDPでは、トランスポートセッションはUDPセッションとして知られています。これは、使用されるIPアドレスとUDPポートの組み合わせによって一意に識別されます。
+------------------+---------------------------------------------+
| | contents |
| +--------------------+------------------------+
| Set | Template | record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Figure A: Terminology Summary Table
図A：用語の要約表
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record.
データセットは、データレコードで構成されています。テンプレートレコードは含まれていません。テンプレートレコードまたはオプションテンプレートレコードは、データレコードを定義します。
A Template Set contains only Template Record(s).
テンプレートセットには、テンプレートレコードのみが含まれています。
An Options Template Set contains only Options Template Record(s).
オプションテンプレートセットには、オプションテンプレートレコードのみが含まれています。
An IPFIX Message consists of a Message Header, followed by one or more Sets. The Sets can be any of the possible three types: Data Set, Template Set, or Options Template Set.
IPFIXメッセージは、メッセージヘッダーで構成され、その後1つ以上のセットが続きます。セットは、データセット、テンプレートセット、またはオプションテンプレートセットの3つのタイプのいずれかになります。
The format of the IPFIX Message is shown in Figure B.
IPFIXメッセージの形式を図Bに示します。
+----------------------------------------------------+
| Message Header |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
Figure B: IPFIX Message Format
図B：IPFIXメッセージ形式
The Exporter MUST code all binary integers of the Message Header and the different Sets in network-byte order (also known as the big-endian byte ordering).
輸出業者は、メッセージヘッダーのすべてのバイナリ整数と、ネットワークバイトの順序で異なるセットをコーディングする必要があります（ビッグエンディアンバイトの注文とも呼ばれます）。
Following are some examples of IPFIX Messages:
以下は、IPFIXメッセージの例です。
1. An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets -- A newly created Template is exported as soon as possible. So, if there is already an IPFIX Message with a Data Set that is being prepared for export, the Template and Option Template Sets are interleaved with this information, subject to availability of space.
1. インターリーブテンプレート、データ、およびオプションテンプレートセットで構成されるIPFIXメッセージ - 新しく作成されたテンプレートができるだけ早くエクスポートされます。したがって、エクスポート用に準備されているデータセットを備えたIPFIXメッセージが既にある場合、テンプレートとオプションテンプレートセットは、スペースの可用性を条件として、この情報とインターリーブされます。
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | Set | | Set | ... | Template | | Set | |
| | | | | | | Set | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+
Figure C: IPFIX Message, Example 1 2. An IPFIX Message consisting entirely of Data Sets -- After the appropriate Template Records have been defined and transmitted to the Collecting Process, the majority of IPFIX Messages consist solely of Data Sets.
図C：IPFIXメッセージ、例1 2.完全にデータセットからなるIPFIXメッセージ - 適切なテンプレートレコードが定義され、収集プロセスに送信された後、IPFIXメッセージの大部分はデータセットのみで構成されています。
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | | Data | | Data | |
| Header | | Set | ... | Set | ... | Set | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+
Figure D: IPFIX Message, Example 2
図D：IPFIXメッセージ、例2
3. An IPFIX Message consisting entirely of Template and Options Template Sets.
3. 完全にテンプレートとオプションテンプレートセットで構成されるIPFIXメッセージ。
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | Set | ... | Set | ... | Template | |
| | | | | | | Set | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+
Figure E: IPFIX Message, Example 3
図E：IPFIXメッセージ、例3
The format of the IPFIX Message Header is shown in Figure F.
IPFIXメッセージヘッダーの形式を図Fに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure F: IPFIX Message Header Format Message Header Field Descriptions:
図F：IPFIXメッセージヘッダー形式メッセージヘッダーフィールドの説明：
Version
バージョン
Version of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].
このメッセージでエクスポートされるフローレコード形式のバージョン。このフィールドの値は、現在のバージョンの0x000Aであり、Netflow Services Exportバージョン9 [RFC3954]で使用されているバージョンを増やします。
Length
長さ
Total length of the IPFIX Message, measured in octets, including Message Header and Set(s).
メッセージヘッダーとセットを含むオクテットで測定されたIPFIXメッセージの全長。
Export Time
エクスポート時間
Time, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter.
0000 0000以来、1970年1月1日以来、秒単位で、IPFIXメッセージヘッダーが輸出者を離れます。
Sequence Number
シーケンス番号
Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent on this PR-SCTP stream from the current Observation Domain by the Exporting Process. Check the specific meaning of this field in the subsections of Section 10 when UDP or TCP is selected as the transport protocol. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number.
このPR-SCTPストリームで送信されたすべてのIPFIXデータレコードの増分シーケンスカウンターモジュロ2^32は、エクスポートプロセスによって現在の観測ドメインから送信されます。UDPまたはTCPが輸送プロトコルとして選択されている場合、セクション10のサブセクションでこのフィールドの特定の意味を確認してください。この値は、IPFIXデータレコードが見逃されているかどうかを特定するために、収集プロセスで使用する必要があります。テンプレートとオプションテンプレートレコードは、シーケンス番号を増やしません。
Observation Domain ID
観察ドメインID
A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported.
エクスポートプロセスに局所的にユニークな観測ドメインの32ビット識別子。エクスポートプロセスは、観測ドメインIDを使用して、収集プロセスに一意に識別し、フローを計量した観測ドメインを識別します。この識別子は、IPFixデバイスごとに一意にすることをお勧めします。収集プロセスでは、トランスポートセッションと観測ドメインIDフィールドを使用して、同じエクスポートプロセスから発生するさまざまなエクスポートストリームを分離する必要があります。特定の観察ドメインIDがIPFIXメッセージ全体に関連する場合、たとえばエクスポートプロセス統計をエクスポートする場合、または集計されたデータレコードがエクスポートされる場合のコレクターの階層の場合、観測ドメインIDは0である必要があります。
Vendors need the ability to define proprietary Information Elements, because, for example, they are delivering a pre-standards product, or the Information Element is, in some way, commercially sensitive. This section describes the Field Specifier format for both IETF-specified Information Elements [RFC5102] and enterprise-specific Information Elements.
たとえば、標準以前の製品を提供しているか、情報要素が何らかの形で商業的に敏感であるため、ベンダーは独自の情報要素を定義する機能を必要とします。このセクションでは、IETF指定情報要素[RFC5102]とエンタープライズ固有の情報要素の両方のフィールド指定形式について説明します。
The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element identifier will report an IETF-specified Information Element, and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Section A.4.2.
情報要素は、情報要素識別子によって識別されます。エンタープライズビットが0に設定されている場合、対応する情報要素識別子はIETF指定の情報要素を報告し、エンタープライズ番号を存在してはなりません。エンタープライズビットが1に設定されると、対応する情報要素識別子はエンタープライズ固有の情報要素を報告します。エンタープライズ番号が存在する必要があります。この例は、セクションA.4.2に示されています。
The Field Specifier format is shown in Figure G.
フィールド仕様形式を図Gに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure G: Field Specifier Format
図G：フィールド仕様形式
Where:
ただし：
E
e
Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number filed MUST be present.
エンタープライズビット。これは、フィールド仕様の最初のビットです。このビットがゼロの場合、情報要素識別子はIETF指定情報要素を識別し、4オクテットのエンタープライズ番号フィールドを存在してはなりません。このビットが1つの場合、情報要素識別子はエンタープライズ固有の情報要素を識別し、提出されたエンタープライズ番号が存在する必要があります。
Information Element identifier
情報要素識別子
A numeric value that represents the type of Information Element. Refer to [RFC5102].
情報要素のタイプを表す数値。[RFC5102]を参照してください。
Field Length
フィールドの長さ
The length of the corresponding encoded Information Element, in octets. Refer to [RFC5102]. The field length may be smaller than the definition in [RFC5102] if the reduced size encoding is used (see Section 6.2). The value 65535 is reserved for variable-length Information Elements (see Section 7).
オクテットの対応するエンコードされた情報要素の長さ。[RFC5102]を参照してください。縮小サイズのエンコードを使用する場合、フィールドの長さは[RFC5102]の定義よりも小さくなる場合があります（セクション6.2を参照）。値65535は、さまざまな長さの情報要素のために予約されています（セクション7を参照）。
Enterprise Number
エンタープライズ番号
IANA enterprise number [PEN] of the authority defining the Information Element identifier in this Template Record.
このテンプレートレコードで情報要素識別子を定義する当局のIANAエンタープライズ番号[PEN]。
A Set is a generic term for a collection of records that have a similar structure. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets. Each of these Sets consists of a Set Header and one or more records. The Set Format and the Set Header Format are defined in the following sections.
セットは、類似した構造を持つレコードのコレクションの一般的な用語です。セットには、テンプレートセット、オプションテンプレートセット、データセットの3つの異なるタイプがあります。これらの各セットは、セットヘッダーと1つ以上のレコードで構成されています。セット形式とセットヘッダー形式は、次のセクションで定義されています。
A Set has the format shown in Figure H. The record types can be either Template Records, Options Template Records, or Data Records. The record types MUST NOT be mixed within a Set.
セットには、図Hに示されている形式があります。レコードタイプは、テンプレートレコード、オプションテンプレートレコード、またはデータレコードのいずれかです。レコードタイプをセット内で混合してはなりません。
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+
Figure H: Set Format
図H：形式を設定します
The Set Field Definitions are as follows:
セットフィールドの定義は次のとおりです。
Set Header
ヘッダーを設定します
The Set Header Format is defined in Section 3.3.2.
セットヘッダー形式は、セクション3.3.2で定義されています。
Record
記録
One of the record Formats: Template Record, Options Template Record, or Data Record Format.
レコード形式の1つは、テンプレートレコード、オプションテンプレートレコード、またはデータレコード形式です。
Padding
パディング
The Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets. The padding length MUST be shorter than any allowable record in this Set. If padding of the IPFIX Message is desired in combination with very short records, then the padding Information Element 'paddingOctets' [RFC5102] can be used for padding records such that their length is increased to a multiple of 4 or 8 octets. Because Template Sets are always 4-octet aligned by definition, padding is only needed in case of other alignments e.g., on 8-octet boundaries.
エクスポートプロセスには、いくつかのパディングオクテットが挿入されるため、後続のセットがアラインされた境界で始まります。セキュリティ上の理由から、パディングオクテットはゼロ（0）の価値のあるオクテットで構成されている必要があります。パディングの長さは、このセットの許容レコードよりも短くなければなりません。IPFIXメッセージのパディングが非常に短い記録と組み合わせて望まれる場合、パディング情報要素「パディングコンテット」[RFC5102]を使用して、その長さが4オクテットまたは8オクテットの倍数に増加するように記録をパディングすることができます。テンプレートセットは定義上4オクタートアラインドされているため、たとえば8オクテットの境界にある他のアライメントの場合にのみパディングが必要です。
Every Set contains a common header. This header is defined in Figure I.
すべてのセットには共通のヘッダーが含まれています。このヘッダーは図Iで定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure I: Set Header Format
図I：ヘッダー形式を設定します
The Set Header Field Definitions are as follows:
セットヘッダーフィールドの定義は次のとおりです。
Set ID
セットID
Set ID value identifies the Set. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954].
Length
長さ
Total length of the Set, in octets, including the Set Header, all records, and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set.
セットヘッダー、すべてのレコード、およびオプションのパディングを含むオクテットのセットの全長。個々のセットには複数のレコードが含まれる可能性があるため、次のセットの位置を決定するために長さの値を使用する必要があります。
IPFIX defines three record formats, defined in the next sections: the Template Record Format, the Options Template Record Format, and the Data Record Format.
IPFIXは、次のセクションで定義されている3つのレコード形式を定義します。テンプレートレコード形式、オプションテンプレートレコード形式、およびデータレコード形式です。
One of the essential elements in the IPFIX record format is the Template Record. Templates greatly enhance the flexibility of the record format because they allow the Collecting Process to process IPFIX Messages without necessarily knowing the interpretation of all Data Records. A Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
IPFIXレコード形式の重要な要素の1つは、テンプレートレコードです。テンプレートは、すべてのデータレコードの解釈を必ずしも知ることなく、収集プロセスがIPFIXメッセージを処理することを可能にするため、レコード形式の柔軟性を大幅に向上させます。テンプレートレコードには、IANAが割り当てられたINAおよび/またはエンタープライズ固有の情報要素識別子の任意の組み合わせが含まれています。
The format of the Template Record is shown in Figure J. It consists of a Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above.
テンプレートレコードの形式を図Jに示します。テンプレートレコードヘッダーと1つ以上のフィールド仕様で構成されています。フィールド仕様の定義は、上記の図Gに示されています。
+--------------------------------------------------+
| Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure J: Template Record Format
図J：テンプレートレコード形式
The format of the Template Record Header is shown in Figure K.
テンプレートレコードヘッダーの形式を図Kに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure K: Template Record Header Format The Template Record Header Field Definitions are as follows:
図K：テンプレートレコードヘッダー形式テンプレートレコードヘッダーフィールドの定義は次のとおりです。
Template ID
テンプレートID
Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation.
新しく生成された各テンプレートレコードには、一意のテンプレートIDが与えられます。この一意性は、テンプレートIDを生成したトランスポートセッションおよび観測ドメインのローカルです。テンプレートID 0-255は、テンプレートセット、オプションテンプレートセット、およびまだ作成されていないその他の予約セット用に予約されています。データセットのテンプレートIDには、256〜65535に番号が付けられています。テンプレートID割り当ての順序に関する制約はありません。
Field Count
フィールドカウント
Number of fields in this Template Record.
このテンプレートレコードのフィールド数。
The example in Figure L shows a Template Set with mixed standard and enterprise-specific Information Elements. It consists of a Set Header, a Template Header, and several Field Specifiers.
図Lの例は、標準とエンタープライズ固有の情報要素が混在するテンプレートセットを示しています。セットヘッダー、テンプレートヘッダー、およびいくつかのフィールド仕様で構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 | Field Length 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 | Field Length 1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N | Field Length 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 | Field Length 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 | Field Length 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M | Field Length 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure L: Template Set Example
図L：テンプレートの設定例
Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them.
情報要素識別子1.2および2.1は、IETF（エンタープライズビット= 0）によって定義されるため、それらを識別するためにエンタープライズ番号は必要ありません。
Thanks to the notion of scope, The Options Template Record gives the Exporter the ability to provide additional information to the Collector that would not be possible with Flow Records alone.
範囲の概念のおかげで、オプションテンプレートレコードにより、輸出業者は、フローレコードだけでは不可能な追加情報をコレクターに提供する機能を提供します。
One Options Template Record example is the "Flow Keys", which reports the Flow Keys for a Template, which is defined as the scope. Another example is the "Template configuration", which reports the configuration sampling parameter(s) for the Template, which is defined as the scope.
オプションテンプレートレコードの例の1つは、「フローキー」です。これは、スコープとして定義されるテンプレートのフローキーを報告します。別の例は、「テンプレート構成」です。これは、テンプレートの構成サンプリングパラメーターを報告します。これは、スコープとして定義されます。
The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records. Note that the IPFIX Message Header already contains the Observation Domain ID (the identifier of the Observation Domain). If not zero, this Observation Domain ID can be considered as an implicit scope for the Data Records in the IPFIX Message. The Observation Domain ID MUST be zero when the IPFIX Message contains Data Records with different Observation Domain ID values defined as scopes.
オプションテンプレートセットでのみ利用可能なスコープは、データレコード内の報告された情報要素のコンテキストを提供します。IPFIXメッセージヘッダーには、観測ドメインID（観測ドメインの識別子）が既に含まれていることに注意してください。ゼロでない場合、この観察ドメインIDは、IPFIXメッセージのデータレコードの暗黙的な範囲と見なすことができます。IPFIXメッセージには、スコープとして定義された異なる観測ドメインID値を持つデータレコードが含まれている場合、観測ドメインIDはゼロでなければなりません。
Multiple Scope Fields MAY be present in the Options Template Record, in which case, the composite scope is the combination of the scopes. For example, if the two scopes are defined as "metering process" and "template", the combined scope is this Template for this Metering Process. The order of the Scope Fields, as defined in the Options Template Record, is irrelevant in this case. However, if the order of the Scope Fields in the Options Template Record is relevant, the order of the Scope Fields MUST be used. For example, if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function. In this case, the Collector deduces the function order by looking at the order of the scope in the Options Template Record.
複数のスコープフィールドがオプションテンプレートレコードに存在する場合があります。その場合、複合スコープはスコープの組み合わせです。たとえば、2つのスコープが「メータープロセス」と「テンプレート」として定義されている場合、結合されたスコープはこのメータープロセスのこのテンプレートです。この場合、オプションテンプレートレコードで定義されているスコープフィールドの順序は無関係です。ただし、オプションテンプレートレコードのスコープフィールドの順序が関連する場合、スコープフィールドの順序を使用する必要があります。たとえば、最初のスコープがフィルタリング関数を定義し、2番目のスコープがサンプリング関数を定義する場合、スコープの順序が重要です。最初にサンプリング関数を適用してフィルタリング関数が続くと、最初にフィルタリング関数を適用し、その後サンプリング関数が適用するよりも潜在的に異なるデータレコードが得られます。この場合、コレクターは、オプションテンプレートレコードのスコープの順序を調べることにより、関数の順序を推測します。
The scope is an Information Element specified in the IPFIX Information Model [RFC5102]. An IPFIX-compliant implementation of the Collecting Process SHOULD support this minimum set of Information Elements as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements, such as meteringProcessId, exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However, some Information Element types don't make sense if specified as scope; for example, the counter Information Elements.
スコープは、IPFIX情報モデル[RFC5102]で指定された情報要素です。収集プロセスのIPFIXに準拠した実装は、範囲としてのこの最小情報要素のセットをサポートする必要があります：LineCardID、TemplateID、ExporterIPv4Address、ExporterIPv6Address、およびIngressInterface。MeteringProcessid、ExportingProcessid、観測ドメインなどの他の情報要素も有効なスコープであることに注意してください。IPFIXプロトコルは、範囲に情報要素を使用することを妨げません。ただし、一部の情報要素タイプは、範囲として指定されている場合は意味がありません。たとえば、カウンター情報要素。
Finally, note that the Scope Field Count MUST NOT be zero.
最後に、スコープフィールドカウントはゼロではないことに注意してください。
An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
オプションテンプレートレコードには、IANAが割り当てられたINAおよび/またはエンタープライズ固有の情報要素識別子の任意の組み合わせが含まれています。
The format of the Options Template Record is shown in Figure M. It consists of an Options Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above.
オプションテンプレートレコードの形式を図Mに示します。オプションテンプレートレコードヘッダーと1つ以上のフィールド仕様で構成されています。フィールド仕様の定義は、上記の図Gに示されています。
+--------------------------------------------------+
| Options Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure M: Options Template Record Format
図M：オプションテンプレートレコード形式
The format of the Options Template Record Header is shown in Figure N.
オプションテンプレートレコードヘッダーの形式を図Nに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure N: Options Template Record Header Format
図N：オプションテンプレートレコードヘッダー形式
The Options Template Record Header Field Definitions are as follows:
オプションテンプレートレコードヘッダーフィールドの定義は次のとおりです。
Template ID
テンプレートID
Template ID of this Options Template Record. This value is greater than 255.
このオプションテンプレートレコードのテンプレートID。この値は255を超えています。
Field Count
フィールドカウント
Number of all fields in this Options Template Record, including the Scope Fields.
スコープフィールドを含む、このオプションテンプレートレコードのすべてのフィールドの数。
Scope Field Count
スコープフィールドカウント
Number of scope fields in this Options Template Record. The Scope Fields are normal Fields except that they are interpreted as scope at the Collector. The Scope Field Count MUST NOT be zero.
このオプションテンプレートレコードのスコープフィールドの数。スコープフィールドは、コレクターのスコープとして解釈されることを除いて、通常のフィールドです。スコープフィールドカウントはゼロである必要はありません。
The example in Figure O shows an Option Template Set with mixed IETF and enterprise-specific Information Elements. It consists of a Set Header, an Option Template Header, and several Field Specifiers.
図oの例は、IETFとエンタープライズ固有の情報要素を混合したオプションテンプレートセットを示しています。セットヘッダー、オプションテンプレートヘッダー、およびいくつかのフィールド仕様で構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = N + M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = N |0| Scope 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length |0| Scope 2 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 2 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1| Scope N Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Scope N Enterprise Number |1| Option 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |0| Option M Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure O: Option Template Set Example
図O：オプションテンプレートの設定例
The Data Records are sent in Data Sets. The format of the Data Record is shown in Figure P. It consists only of one or more Field Values. The Template ID to which the Field Values belong is encoded in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".
データレコードはデータセットで送信されます。データレコードの形式を図Pに示します。これは、1つ以上のフィールド値のみで構成されています。フィールド値が属するテンプレートIDは、セットヘッダーフィールド「設定ID」、つまり「設定ID」=「テンプレートID」にエンコードされます。
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure P: Data Record Format
図P：データレコード形式
Note that Field Values do not necessarily have a length of 16 bits. Field Values are encoded according to their data type specified in [RFC5102].
フィールド値の長さは必ずしも16ビットではないことに注意してください。フィールド値は、[RFC5102]で指定されたデータ型に従ってエンコードされます。
Interpretation of the Data Record format can be done only if the Template Record corresponding to the Template ID is available at the Collecting Process.
データレコード形式の解釈は、テンプレートIDに対応するテンプレートレコードが収集プロセスで利用可能である場合にのみ実行できます。
The example in Figure Q shows a Data Set. It consists of a Set Header and several Field Values.
図Qの例は、データセットを示しています。セットヘッダーといくつかのフィールド値で構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure Q: Data Set, Containing Data Records
図Q：データセット、データレコードを含む
Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process.
いくつかの特定のオプションテンプレートとオプションテンプレートレコードは、フローレコードと計量プロセスに関する追加情報を提供するために必要です。
The Option Template and Options Template Records defined in these subsections, which impose some constraints on the Metering Process and Exporting Process implementations, MAY be implemented. If implemented, the specific Option Templates SHOULD be implemented as specified in these subsections.
これらのサブセクションで定義されているオプションテンプレートとオプションテンプレートレコードは、計量プロセスとエクスポートプロセスの実装にいくつかの制約を課すことができます。実装されている場合、これらのサブセクションで指定されているように、特定のオプションテンプレートを実装する必要があります。
The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates.
情報要素の最小セットは、これらの特定のIPFIXオプションテンプレートで常に指定されています。それにもかかわらず、これらの特定のオプションテンプレートでは、追加の情報要素を使用できます。
The Metering Process Statistics Option Template specifies the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements that are defined in [RFC5102]: observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field.
計測プロセス統計オプションテンプレートは、計量プロセス統計を報告するためのデータレコードの構造を指定します。[RFC5102]で定義されている次の情報要素を含める必要があります。観察ドメインは、エクスポートプロセスに局所的に一意の観測ドメインの識別子です。この情報要素は、スコープフィールドとして定義する必要があります。
exportedMessageTotalCount The total number of IPFIX Messages that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
ExportedMessagetotalCountエクスポートプロセスがエクスポートプロセスの再イナイト化以来、収集プロセスに正常に送信されたIPFIXメッセージの総数。
exportedFlowTotalCount The total number of Flow Records that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
ExportedFlowTotalCountエクスポートプロセスが再目的化されてから収集プロセスに成功したフロー記録の総数。
exportedOctetTotalCount The total number of octets that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
エクスポートcttettotalcountエクスポートプロセスが輸出プロセスの再初期化以来、収集プロセスに正常に送信されたオクテットの総数。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、メータリングプロセス統計オプションテンプレートで指定されたデータレコードを定期的に、または一部のエクスポートポリシーに基づいてエクスポートする必要があります。この周期性または輸出ポリシーは構成可能である必要があります。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
輸出機観測ドメインでいくつかの計量プロセスが利用可能な場合、情報要素MeteringProcessIDを追加のスコープフィールドとして指定する必要があることに注意してください。
The Metering Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
メータリングプロセス信頼性オプションテンプレートは、メータープロセスにおける信頼性の欠如を報告するためのデータレコードの構造を指定します。[RFC5102]で定義されている次の情報要素を含める必要があります。
observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field.
観測DomainIDエクスポートプロセスに局所的に独特な観測ドメインの識別子。この情報要素は、スコープフィールドとして定義する必要があります。
ignoredPacketTotalCount The total number of IP packets that the Metering Process did not process.
無視されたPackettotalCount計量プロセスが処理しなかったIPパケットの総数。
ignoredOctetTotalCount The total number of octets in observed IP packets that the Metering Process did not process.
無視されたcutettotalcount計量プロセスが処理しなかった観測されたIPパケットのオクテットの総数。
time first ignored The timestamp of the first IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used.
最初に、計量プロセスで無視された最初のIPパケットのタイムスタンプを無視しました。このタイムスタンプでは、「フロースタート」タイムスタンプ情報要素のいずれかがフロースタートアートマリシェーコンド、フロースタートマイクロシェーコンド、フロースタートナノセカンド、およびフロースタートデルタミクロシロセクションを使用できます。
time last ignored The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used.
最後の時間は、メータープロセスによって無視された最後のIPパケットのタイムスタンプを無視しました。このタイムスタンプでは、「フローエンド」のタイムスタンプ情報要素のいずれかが、flowendmilliseconds、flowendmicroseconds、flowendnananoseconds、およびflowenddeltamicrosecondsを使用できます。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的に、または一部のエクスポートポリシーに基づいて、計量プロセスの信頼性統計オプションテンプレートで指定されたデータレコードをエクスポートする必要があります。この周期性または輸出ポリシーは構成可能である必要があります。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
輸出機観測ドメインでいくつかの計量プロセスが利用可能な場合、情報要素MeteringProcessIDを追加のスコープフィールドとして指定する必要があることに注意してください。
The Exporting Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
エクスポートプロセス信頼性オプションテンプレートは、エクスポートプロセスにおける信頼性の欠如を報告するためのデータレコードの構造を指定します。[RFC5102]で定義されている次の情報要素を含める必要があります。
Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field.
エクスポートプロセスID信頼性の欠如が報告されているエクスポートプロセスの識別子。[RFC5102]で指定された3つの情報要素があり、この目的に使用できます：ExporterIPv4Address、ExporterIPv6Address、またはExportingProcessid。この情報要素は、スコープフィールドとして定義する必要があります。
notSentFlowTotalCount The total number of Flows that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
notsentflowtotalcount計量プロセスによって生成され、計量プロセスまたは輸出プロセスによって生成されたフローの総数。
notSentPacketTotalCount The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
notsentpackettotalcountメータリングプロセスによって生成され、計量プロセスまたは輸出プロセスによって削除されたフローレコードのパケットの総数。
notSentOctetTotalCount The total number of octets in packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
notoctettotalcountメータリングプロセスによって生成され、計量プロセスまたは輸出プロセスによって生成されたフローレコードのパケットのオクテットの総数。
time first flow dropped The timestamp of the first Flow was dropped by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used.
タイムファーストフローが落とした最初のフローのタイムスタンプは、計量プロセスによって落とされました。このタイムスタンプでは、「フロースタート」タイムスタンプ情報要素のいずれかがフロースタートアートマリシェーコンド、フロースタートマイクロシェーコンド、フロースタートナノセカンド、およびフロースタートデルタミクロシロセクションを使用できます。
time last flow dropped The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used.
時間の最後のフローは、計量プロセスによって無視された最後のIPパケットのタイムスタンプを落としました。このタイムスタンプでは、「フローエンド」のタイムスタンプ情報要素のいずれかが、flowendmilliseconds、flowendmicroseconds、flowendnananoseconds、およびflowenddeltamicrosecondsを使用できます。
The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、エクスポートプロセス信頼性統計オプションテンプレートによって指定されたデータレコードを定期的に、または一部のエクスポートポリシーに基づいてエクスポートする必要があります。この周期性または輸出ポリシーは構成可能である必要があります。
The Flow Keys Option Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow.
Flow Keysオプションテンプレートは、報告されたフローのフローキーを報告するためのデータレコードの構造を指定します。Flow Keysデータレコードは、テンプレート識別子によって参照される特定のテンプレートレコードを拡張します。テンプレートレコードは、対応するデータレコードに含まれる情報要素のどれが報告されたフローのフローキーとして機能するフロープロパティを記述するかを指定することにより拡張されます。
The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [RFC5102]:
Flow Keysオプションテンプレートには、[RFC5102]で定義されている次の情報要素を含める必要があります。
templateId An identifier of a Template. This Information Element MUST be defined as a Scope Field.
TemplateIDテンプレートの識別子。この情報要素は、スコープフィールドとして定義する必要があります。
flowKeyIndicator Bitmap with the positions of the Flow Keys in the Data Records.
FlowKeyIndicatorデータレコード内のフローキーの位置を備えたBitMap。
The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter. The time-related Information Elements specified in [RFC5102] MAY use this "Export Time" as base time and specify an offset relative to it, instead of using a common base time, such as 0000 UTC Jan 1, 1970. All Information Elements that do not have their base time defined by their data type MUST have the base time clearly specified in their description.
IPFIXメッセージヘッダー「エクスポート時間」フィールドは、1970年1月1日0000 UTC以来の数秒での時間です。[RFC5102]で指定された時間関連情報要素は、この「エクスポート時間」を基本時間として使用し、1970年1月1日などの一般的なベースタイムを使用する代わりに、オフセットを指定することができます。データ型で定義されている基本時間を説明しないでください。説明では、基本時間を明確に指定している必要があります。
For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements [RFC5102], containing the time since 0000 UTC Jan 1, 1970. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102] in the Data Record, which respectively report the flow start and end time offsets compared to the IPFIX Message Header "Export Time". The latter solution lowers the export bandwidth requirement while it increases the load on the Exporter, as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message.
たとえば、マイクロ秒の精度を必要とするデータレコードは、フロースタートアートマイクロシェーコンドとフローエンドマイクロシェーコンドの情報要素[RFC5102]でフロースタートとエンドタイムをエクスポートできます。データレコードの要素[RFC5102]は、IPFIXメッセージヘッダー「エクスポート時間」と比較して、それぞれフロー開始時間および終了時間オフセットを報告します。後者のソリューションは、輸出帯域幅の要件を低下させます。エクスポートプロセスは、IPFIXメッセージをエクスポートする前に、すべてのデータレコードのフロースタートデルタミクロセカンドとフローエンドデルタミクロセクションを計算する必要があるためです。
It must be noted that using time-related Information Elements with offset times, compared to the IPFIX Message Header "Export Time", imposes some time constraints on the Data Records contained in the IPFIX Message. In the example of flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102], the Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset.
IPFIXメッセージヘッダー「エクスポート時間」と比較して、オフセット時間の時間に関連する情報要素を使用すると、IPFIXメッセージに含まれるデータレコードに時間の制約を課すことに注意する必要があります。FlowStartDeltamicroSecondsおよびFlowEndDeltamicroSeconds情報要素[RFC5102]の例では、データレコードは作成後最大71分以内にエクスポートする必要があります。それ以外の場合、32ビットカウンターは、フロー開始時間オフセットを封じ込めるのに十分ではありません。
The Information Elements [RFC5102] MUST be sent in canonical format in network-byte order (also known as the big-endian byte ordering).
情報要素[RFC5102]は、ネットワークバイトの順序で正規形式で送信する必要があります（ビッグエンディアンバイト順序とも呼ばれます）。
The following sections will define the encoding of the data types specified in [RFC5102].
次のセクションでは、[RFC5102]で指定されたデータ型のエンコードを定義します。
Integral data types -- octet, signed8, unsigned16, signed16, unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded using the default canonical format in network-byte order. Signed Integral data types are represented in two's complement notation.
統合データ型 - octet、signed8、unsigned16、signed16、unsigned32、signed32、signed64、およびunsigned64-は、デフォルトの標準形式をネットワークバイト順序でエンコードする必要があります。署名された積分データ型は、2つの補数表記で表されます。
Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types. The macAddress is treated as a 6-octet integer, the ipv4Address as a 4-octet integer, and the ipv6Address as a 16-octet integer.
アドレスタイプ（MacAddress、IPv4Address、およびIPv6Address）は、積分データ型と同じ方法でエンコードする必要があります。MacAddressは、6オクテットの整数、IPv4Addressは4-OCTET整数として、IPv6Addressは16オクテットの整数として扱われます。
The float32 data type MUST be encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985].
FLOAT32データ型は、[IEEE.754.1985]で指定されているように、IEEEシングルプレシジョン32ビットフローティングポイントタイプとしてエンコードする必要があります。
The float64 data type MUST be encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985].
[IEEE.754.1985]で指定されているように、FLOAT64データ型は、IEEEダブルサイジョン64ビットフローティングポイントタイプとしてエンコードする必要があります。
The boolean data type is specified according to the TruthValue in [RFC2579]: it is an integer with the value 1 for true and a value 2 for false. Every other value is undefined. The boolean data type MUST be encoded in a single octet.
ブールデータ型は、[RFC2579]のTruthValueに従って指定されています。これは、Trueの値1、Falseの値2を持つ整数です。他のすべての値は未定義です。ブールデータ型は、単一のオクテットでエンコードする必要があります。
The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length.
データ型文字列は、Unicode文字エンコードセットの有効な文字の有限長文字列を表します。文字列データ型は、UTF-8形式でエンコードする必要があります。文字列は、固定または可変長の情報要素を使用して、オクテットの配列として送信されます。
The length of the Information Element specifies the length of the octetarray.
情報要素の長さは、オクタレーの長さを指定します。
The data type dateTimeseconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years.
データ型DateTimeseCondsは、GMT TimeZoneに正規化された秒単位の時間値を表します。1970年1月1日以降、秒数を含む32ビット整数でエンコードする必要があります。32ビット整数は、最大136年のエンコードを可能にします。
The data type dateTimeMilliseconds represents a time value in units of milliseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer containing the number of milliseconds since 0000 UTC Jan 1, 1970.
データ型DateTimemilliseCondsは、GMT TimeZoneに正規化されたミリ秒単位の時間値を表します。1970年1月1日以降、ミリ秒数を含む64ビット整数でエンコードする必要があります。
The data type dateTimeMicroseconds represents a time value in units of microseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305].
データ型DateTimemicRosecondsは、GMT TimeZoneに正規化されたマイクロ秒単位の時間値を表します。[RFC1305]に与えられたNTP形式に従って、64ビット整数でエンコードする必要があります。
The data type of dateTimeNanoseconds represents a time value in units of nanoseconds normalized to the GMT time zone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305].
DateTimenanAnoSecondsのデータ型は、GMTタイムゾーンに正規化されたNAN秒単位の時間値を表します。[RFC1305]に与えられたNTP形式に従って、64ビット整数でエンコードする必要があります。
Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [RFC5102], based on the assumption that the smaller size is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [RFC5102] will always define the maximum encoding size.
情報モデルに整数、文字列、フロート、およびオクタレータイプを含む情報要素は、情報モデル定義のタイプ[RFC5102]で暗示されているオクテットよりも少ないオクテットを使用してエンコードされる場合があります。輸出業者が提供する必要がある場合があります。これにより、輸出業者とコレクターの間のネットワーク帯域幅要件が削減されます。情報要素定義[RFC5102]は、常に最大エンコーディングサイズを定義することに注意してください。
For instance, the information model [RFC5102] defines byteCount as an unsigned64 type, which would require 64 bits. However, if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount, while an unsigned32 might be sufficient for an access router.
たとえば、情報モデル[RFC5102]は、bytecountをunsigned64タイプとして定義し、64ビットを必要とします。ただし、輸出国が4294967295を超える値を送信する必要性に局所的に遭遇しない場合、代わりに値をunsigned32として送信することを選択する場合があります。たとえば、コアルーターにはunsigned64 bytecountが必要ですが、Unsigned32ではアクセスルーターに十分である可能性があります。
This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element. In the example above, the Exporter would place a length of 4 versus 8 in the Template.
この動作は、割り当てられたタイプの情報要素に関連付けられたものよりも長い長さのタイプサイズを指定することにより、輸出者によって示されます。上記の例では、輸出国はテンプレートに4対8の長さを配置します。
If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The signed versus unsigned property of the reported value MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e., so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
サイジングの削減を使用する場合は、次の整数タイプにのみ適用する必要があります：unsigned64、signed64、unsigned32、signed32、unsigned16、およびsigned16にのみ適用する必要があります。報告された値の署名されたものと署名されていないプロパティを保持する必要があります。サイズの縮小は、データ値がまだ適合している場合、つまり先行ゼロのみがドロップされる場合、元のタイプよりも小さいオクテットの数になります。たとえば、unsigned64のサイズは7、6、5、4、3、2、または1オクテット（s）に縮小できます。
Reduced sizing can also be used to reduce float64 to float32. The float32 not only has a reduced number range, but due to the smaller mantissa, is also less precise.
サイジングの削減は、float64をfloat32に減らすためにも使用できます。Float32の数範囲は範囲を減らすだけでなく、マンティッサが小さいため、正確ではありません。
The reduced size encoding MUST NOT be applied to dateTimeMicroseconds or to dateTimeNanoseconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes.
縮小サイズのエンコーディングは、DateTimemicRosecondsまたはDateTimenananocondsに適用してはなりません。これは、元のバイト数より少ない数よりも少ないことで破壊される固有の構造を表すためです。
The IPFIX Template mechanism is optimized for fixed-length Information Elements [RFC5102]. Where an Information Element has a variable length, the following mechanism MUST be used to carry the length information for both the IETF and proprietary Information Elements.
IPFIXテンプレートメカニズムは、固定長の情報要素[RFC5102]に最適化されています。情報要素の長さの長さがある場合、IETFと独自の情報要素の両方の長さ情報を運ぶために、次のメカニズムを使用する必要があります。
In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that length of the Information Element will be carried in the Information Element content itself.
テンプレートセットでは、情報要素フィールドの長さは65535として記録されます。この予約された長さの値は、情報要素の長さが情報要素コンテンツ自体に伝達されることを収集プロセスに通知します。
In most cases, the length of the Information Element will be less than 255 octets. The following length-encoding mechanism optimizes the overhead of carrying the Information Element length in this majority case. The length is carried in the octet before the Information Element, as shown in Figure R.
ほとんどの場合、情報要素の長さは255オクテット未満になります。次の長さをコードするメカニズムは、この過半数の場合に情報要素の長さを運ぶオーバーヘッドを最適化します。図Rに示すように、長さは情報要素の前のオクテットで運ばれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure R: Variable-Length Information Element (length < 255 octets)
図R：可変長情報要素（長さ<255オクテット）
If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255, and the length is carried in the second and third octets, as shown in Figure S.
情報要素の長さが255オクテット以上の場合、長さは情報要素の前に3オクテットにエンコードされます。最初のオクテットは255で、図Sに示すように、長さは2番目と3番目のオクテットに運ばれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure S: Variable-Length Information Element (length 0 to 65535 octets)
図S：可変長情報要素（長さ0〜65535オクテット）
The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Element.
長さ（最初または最初の3つのオクテットのいずれか）を運ぶオクテットは、情報要素の長さに含めてはなりません。
This section describes Template Management when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to Template Management specifically related to TCP or UDP transport protocols are specified in Section 10.
このセクションでは、SCTPとPR-SCTPを輸送プロトコルとして使用する場合のテンプレート管理について説明します。TCPまたはUDP輸送プロトコルに特に関連するテンプレート管理に必要な変更をセクション10で指定します。
The Exporting Process assigns and maintains the Template IDs per SCTP association for the Exporter's Observation Domains. A newly created Template Record is assigned an unused Template ID by the Exporting Process.
エクスポートプロセスは、輸出者の観測ドメインのSCTPアソシエーションごとのテンプレートIDを割り当てて維持します。新しく作成されたテンプレートレコードには、エクスポートプロセスによって未使用のテンプレートIDが割り当てられます。
If a specific Information Element is required by a Template, but is not available in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record defined by a new Template.
特定の情報要素がテンプレートで必要であるが、観測されたパケットで使用できない場合、エクスポートプロセスは、新しいテンプレートで定義されたデータレコードのこの情報要素なしでフローレコードをエクスポートすることを選択できます。
If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value should belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the inner header one.
テンプレートで情報要素が複数回必要な場合、この情報要素の異なる発生は、計量プロセスによって治療の論理順序に従う必要があります。たとえば、選択したパケットが2つのハッシュ関数を通過し、2つのハッシュ値が単一のテンプレート内で送信される場合、ハッシュ値の最初の発生はメータープロセスで最初のハッシュ関数に属する必要があります。たとえば、IPv4パケットでIPv4の2つのソースIPアドレスをエクスポートする場合、最初のsourceIPv4Address情報要素の発生は外側ヘッダーのIPv4アドレスである必要がありますが、2番目の発生は内側のヘッダーである必要があります。
Template Sets and Options Template Sets may be sent on any SCTP stream. Template Sets and Options Template Sets MUST be sent reliably, using SCTP-ordered delivery. As such, the Collecting Process MUST store the Template Record information for the duration of the SCTP association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
テンプレートセットとオプションテンプレートセットは、任意のSCTPストリームで送信できます。テンプレートセットとオプションテンプレートセットは、SCTP秩序配信を使用して確実に送信する必要があります。そのため、収集プロセスは、SCTP協会の期間中、テンプレートレコード情報を保存して、後続のデータセットで受信した対応するデータレコードを解釈できるようにする必要があります。
The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record. Data Records that correspond to a Template Record MAY appear in the same and/or subsequent IPFIX Message(s).
エクスポートプロセスでは、最初のデータレコードを受信する前にコレクターがテンプレートレコードを持っていることを確認するために、テンプレートセットとオプションテンプレートセットを（オプション）テンプレートIDを使用して送信する必要があります。テンプレートレコードに対応するデータレコードは、同じおよび/またはその後のIPFIXメッセージに表示される場合があります。
Different Observation Domains from the same SCTP association may use the same Template ID value to refer to different Templates.
同じSCTPアソシエーションの異なる観測ドメインは、同じテンプレートID値を使用して異なるテンプレートを参照する場合があります。
The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message.
使用されていないテンプレートは削除する必要があります。テンプレートIDを再利用する前に、テンプレートを削除する必要があります。割り当てられたテンプレートを削除するために、テンプレートはテンプレートの引き出しメッセージを使用して撤回されます。
The Template Withdrawal Message MUST NOT be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This time MUST be configurable. A suitable default value is 5 seconds after the last Data Record has been sent.
テンプレートの引き出しメッセージは、収集プロセスがこのテンプレート情報を使用して最後のデータレコードを受信および処理できるように十分な時間が経過するまで送信してはなりません。今回は設定可能でなければなりません。適切なデフォルト値は、最後のデータレコードが送信されてから5秒です。
The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template Withdrawal Message.
撤回されたテンプレートからのテンプレートIDは、収集プロセスがテンプレートの引き出しメッセージを受信して処理できるように、十分な時間が経過するまで再利用してはなりません。
A Template Withdrawal Message is a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Message is shown in Figure T.
テンプレートの引き出しメッセージは、フィールドカウント0のテンプレートIDのテンプレートレコードです。テンプレート引き出しメッセージの形式を図Tに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = (2 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure T: Template Withdrawal Message Format
図T：テンプレートの引き出しメッセージ形式
The Set ID field MUST contain the value 2 for Template Set Withdrawal and the value 3 for Options Template Set Withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message, in that case, padding MAY be used.
設定されたIDフィールドには、テンプレートセットの引き出しの値2とオプションテンプレートセットの引き出しの値3が含まれている必要があります。複数のテンプレートIDは、単一のテンプレート引き出しメッセージで撤回される場合があります。その場合、パディングを使用できます。
The Template Withdrawal Message withdraws the Template IDs for the Observation Domain ID specified in the IPFIX Message Header.
テンプレートの引き出しメッセージは、IPFIXメッセージヘッダーで指定された観測ドメインIDのテンプレートIDを撤回します。
The Template Withdrawal Message may be sent on any SCTP stream. The Template Withdrawal Message MUST be sent reliably, using SCTP-ordered delivery.
テンプレートの引き出しメッセージは、任意のSCTPストリームで送信される場合があります。SCTP順序配信を使用して、テンプレートの引き出しメッセージを確実に送信する必要があります。
The Template Withdrawal Message MUST NOT contain new Template or Options Template Records.
テンプレートの引き出しメッセージには、新しいテンプレートまたはオプションテンプレートレコードを含めてはなりません。
If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new Flow expiration process, a new filtering definition, etc.
新しいテンプレートが必要になるように測定パラメーターが変更された場合、テンプレートを撤回する必要があります（テンプレートの撤回メッセージと新しいテンプレート定義を使用）または未使用のテンプレートIDを使用する必要があります。測定の変更の例は、新しいサンプリングレート、新しいフローの満了プロセス、新しいフィルタリング定義などです。
When the SCTP association shuts down or the Exporting Process restarts, all Template assignments are lost and Template IDs MUST be reassigned.
SCTP協会がシャットダウンするか、エクスポートプロセスが再起動すると、すべてのテンプレート割り当てが失われ、テンプレートIDを再割り当てする必要があります。
If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdraw Message(s) before reusing them.
メータープロセスが再起動する場合、エクスポートプロセスは、各テンプレートの以前に割り当てられたテンプレートIDを再利用する必要があります。または、再利用する前にテンプレートの引き出しメッセージを送信して、以前に発行されたテンプレートIDを撤回する必要があります。
A Template Withdrawal Message to withdraw all Templates for the Observation Domain ID specified in the IPFIX Message Header MAY be used. Its format is shown in Figure U.
IPFIXメッセージヘッダーで指定された観測ドメインIDのすべてのテンプレートを撤回するテンプレート引き出しメッセージを使用できます。その形式を図Uに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure U: All Data Templates Withdrawal Message Format
図u：すべてのデータテンプレート撤回メッセージ形式
A Template Withdrawal Message to withdraw all Options Templates for the Observation Domain ID specified in the IPFIX Message Header MAY be used. Its format is shown in Figure V.
IPFIXメッセージヘッダーで指定された観測ドメインIDのすべてのオプションテンプレートを撤回するためのテンプレート撤回メッセージを使用することができます。その形式を図Vに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 3 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure V: All Options Templates Withdrawal Message Format
図V：すべてのオプションテンプレート撤回メッセージ形式
When the SCTP association restarts, the Exporting Process MUST resend all the Template Records.
SCTP協会が再起動すると、エクスポートプロセスはすべてのテンプレートレコードを再送信する必要があります。
This section describes the Collecting Process when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to the Collecting Process specifically related to TCP or UDP transport protocols are specified in Section 10.
このセクションでは、SCTPおよびPR-SCTPを輸送プロトコルとして使用する場合の収集プロセスについて説明します。TCPまたはUDP輸送プロトコルに特に関連する収集プロセスに必要な変更をセクション10で指定します。
The Collecting Process SHOULD listen for a new association request from the Exporting Process. The Exporting Process will request a number of streams to use for export. An Exporting Process MAY request and support more than one stream per SCTP association.
収集プロセスは、エクスポートプロセスからの新しい協会要求を聞く必要があります。エクスポートプロセスは、エクスポートに使用するために多くのストリームを要求します。エクスポートプロセスは、SCTP協会ごとに複数のストリームを要求し、サポートする場合があります。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error. Note that non-zero Set padding does not constitute a malformed IPFIX Message.
収集プロセスが奇形のIPFIXメッセージを受信した場合、SCTPアソシエーションをリセットし、IPFIXメッセージを破棄し、エラーをログに記録する必要があります。ゼロ以外のセットパディングは、奇形のIPFIXメッセージを構成しないことに注意してください。
Template Sets and Option Template Sets are only sent once. The Collecting Process MUST store the Template Record information for the duration of the association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
テンプレートセットとオプションテンプレートセットは、1回のみ送信されます。収集プロセスは、協会の期間中にテンプレートレコード情報を保存して、後続のデータセットで受信した対応するデータレコードを解釈できるようにする必要があります。
Template IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shut down the association.
テンプレートIDは、SCTPアソシエーションと観察ドメインごとに一意です。収集プロセスがすでに受信されているが、以前に撤回されていないテンプレートを受信した場合（つまり、SCTP協会で受信した同じテンプレートIDを使用して同じ輸出者観測ドメインからのテンプレートレコード）。協会。
When an SCTP association is closed, the Collecting Process MUST discard all Templates received over that association and stop decoding IPFIX Messages that use those Templates.
SCTPアソシエーションが閉鎖された場合、収集プロセスは、その関連性を介して受信したすべてのテンプレートを破棄し、それらのテンプレートを使用するIPFIXメッセージのデコードを停止する必要があります。
The Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. The Data Records are then decoded and stored by the Collector. If the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received. A Collecting Process MUST NOT assume that the Data Set and the associated Template Set (or Options Template Set) are exported in the same IPFIX Message.
収集プロセスは通常、データレコードを受信する前にエクスポートプロセスからテンプレートレコードを受信します。データレコードは、コレクターによってデコードされ、保存されます。データレコードが受信された時点でテンプレートレコードを受信していない場合、収集プロセスはデータレコードを短時間保存し、テンプレートレコードを受信した後にそれらをデコードする場合があります。収集プロセスは、データセットと関連するテンプレートセット（またはオプションテンプレートセット）が同じIPFIXメッセージにエクスポートされると仮定してはなりません。
The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record.
収集プロセスは、理解できない情報要素の情報要素識別子に注意し、フローレコードからその情報要素を破棄する必要があります。
The Collector MUST accept padding in Data Records and Template Records. The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the Record size deduced from the Template Record.
コレクターは、データレコードとテンプレートレコードのパディングを受け入れる必要があります。パディングサイズは、セットヘッダーのサイズ（セットIDの4オクテットとセット長）を差し引いて、テンプレートレコードから推定されるレコードサイズを差し引いたものです。
The IPFIX protocol has a Sequence Number field in the Export header that increases with the number of IPFIX Data Records in the IPFIX Message. A Collector may detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. A Collector SHOULD provide a logging mechanism for tracking out-of-sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be due to Exporter resource exhaustion where it cannot transmit messages at their creation rate, an Exporting Process reset, congestion on the network link between the Exporter and Collector, Collector resource exhaustion where it cannot process the IPFIX Messages at their arrival rate, out-of-order packet reception, duplicate packet reception, or an attacker injecting false messages.
IPFIXプロトコルには、IPFIXメッセージのIPFIXデータレコードの数とともに増加するエクスポートヘッダーにシーケンス番号フィールドがあります。コレクターは、シーケンス番号を追跡して、IPFIXメッセージをドロップしたり、複製したりすることができます。コレクターは、アウトシーケンスIPFIXメッセージを追跡するためのロギングメカニズムを提供する必要があります。このようなシーケンスのIPFIXメッセージは、作成率でメッセージを送信できない輸出者リソースの消耗、エクスポートプロセスのリセット、輸出業者とコレクター間のネットワークリンクの混雑、IPFIXを処理できない場合のコレクターリソースの消耗によるものである可能性があります。到着率でのメッセージ、注文不足のパケット受信、重複したパケット受信、または誤ったメッセージを注入する攻撃者。
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
収集プロセスがテンプレートの引き出しメッセージを受信した場合、収集プロセスは、特定のSCTP関連および特定の観測ドメインに関連付けられた対応するテンプレートレコードを削除し、撤回したテンプレートを使用するIPFIXメッセージの解読を停止する必要があります。
If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before on this SCTP association, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
収集プロセスが、このSCTPアソシエーションでこれまでに受信したことのないテンプレートレコードのテンプレート撤回メッセージを受信した場合、SCTPアソシエーションをリセットし、IPFIXメッセージを破棄し、奇形のIPFIXメッセージの場合と同様にエラーを記録する必要があります。
A Collecting Process that receives IPFIX Messages from several Observation Domains on the same Transport Session MUST be aware that the uniqueness of the Template ID is not guaranteed across Observation Domains.
同じトランスポートセッションでいくつかの観測ドメインからIPFIXメッセージを受信する収集プロセスは、テンプレートIDの一意性が観測ドメイン全体で保証されていないことを認識する必要があります。
The Collector MUST support the use of Templates containing multiple occurrences of the similar Information Elements.
コレクターは、同様の情報要素の複数の発生を含むテンプレートの使用をサポートする必要があります。
The IPFIX Protocol Specification has been designed to be transport protocol independent. Note that the Exporter can export to multiple Collecting Processes using independent transport protocols.
IPFIXプロトコルの仕様は、プロトコルを独立しているように設計されています。輸出業者は、独立した輸送プロトコルを使用して複数の収集プロセスにエクスポートできることに注意してください。
The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535 octets.
IPFIXメッセージヘッダー16ビットの長さフィールドは、ヘッダーを含むIPFIXメッセージの長さを65535オクテットに制限します。収集プロセスは、最大65535オクテットのIPFIXメッセージの長さを処理できる必要があります。
We need to differentiate between what must be implemented (so that operators can interoperably deploy compliant implementations from different vendors) and what should or could be used in various operational environments. We must also make sure that ALL implementations can operate in a congestion-aware and congestion-avoidance mode.
実装する必要があるもの（オペレーターが異なるベンダーから準拠した実装を相互に展開できるように）と、さまざまな運用環境で使用できるもの、または使用できるものを区別する必要があります。また、すべての実装が輻輳認識および輻輳回避モードで動作できることを確認する必要があります。
SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations. UDP [UDP] MAY also be implemented by compliant implementations. TCP [TCP] MAY also be implemented by compliant implementations.
[RFC3758]で指定されたPR-SCTP拡張を使用したSCTP [RFC4960]は、すべての準拠の実装によって実装する必要があります。UDP [UDP]は、準拠した実装によって実装される場合があります。TCP [TCP]は、準拠した実装によっても実装できます。
PR-SCTP SHOULD be used in deployments where Exporters and Collectors are communicating over links that are susceptible to congestion. PR-SCTP is capable of providing any required degree of reliability.
PR-SCTPは、輸出業者とコレクターが混雑の影響を受けやすいリンクを介して通信している展開に使用する必要があります。PR-SCTPは、必要な程度の信頼性を提供することができます。
TCP MAY be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but PR-SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation.
TCPは、輸出業者とコレクターが混雑の影響を受けやすいリンクを介して通信する展開で使用できますが、輸出業者とそのメッセージとストリーム方向への戻る圧力を制限する能力により、PR-SCTPが好まれます。
UDP MAY be used, although it is not a congestion-aware protocol. However, the IPFIX traffic between Exporter and Collector MUST run in an environment where IPFIX traffic has been provisioned for, or is contained through some other means.
UDPは使用される場合がありますが、混雑を認識するプロトコルではありません。ただし、ExporterとCollectorの間のIPFIXトラフィックは、IPFIXトラフィックがプロビジョニングされている、または他の手段に含まれている環境で実行する必要があります。
This section describes how IPFIX can be transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension.
このセクションでは、PR-SCTP [RFC3758]拡張を使用して、SCTP [RFC4960]を介してIPFIXを輸送する方法について説明します。
The SCTP transport protocol provides the required level of congestion avoidance by design.
SCTPトランスポートプロトコルは、設計による必要なレベルの混雑回避を提供します。
SCTP will detect congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limit the transfer rate accordingly. When an IPFIX Exporting Process has records to export, but detects that transmission by SCTP is temporarily impossible, it can either wait until sending is possible again, or it can decide to drop the record. In the latter case, the dropped export data MUST be accounted for, so that the amount of dropped export data can be reported.
SCTPは、IPFIXエクスポートプロセスとIPFIX収集プロセスの間のエンドツーエンドパスでの混雑を検出し、それに応じて転送速度を制限します。IPFIXのエクスポートプロセスにエクスポートするレコードがあるが、SCTPによる送信が一時的に不可能であることを検出すると、送信が再び可能になるまで待つか、レコードをドロップすることができます。後者の場合、ドロップされたエクスポートデータの量を報告できるように、ドロップされたエクスポートデータを考慮する必要があります。
The SCTP transport protocol is by default reliable, but has the capability to deliver messages with partial reliability [RFC3758].
SCTPトランスポートプロトコルはデフォルトで信頼性がありますが、部分的な信頼性を備えたメッセージを配信する機能があります[RFC3758]。
Using reliable SCTP messages for the IPFIX export is not in itself a guarantee that all Data Records will be delivered. If there is congestion on the link from the Exporting Process to the Collecting Process, or if a significant number of retransmissions are required, the send queues on the Exporting Process may fill up; the Exporting Process MAY either suspend, export, or discard the IPFIX Messages. If Data Records are discarded the IPFIX Sequence Numbers used for export MUST reflect the loss of data.
IPFIXエクスポートに信頼できるSCTPメッセージを使用すること自体は、すべてのデータレコードが配信されることを保証しません。エクスポートプロセスから収集プロセスへのリンクに混雑がある場合、またはかなりの数の再送信が必要な場合、エクスポートプロセスの送信キューが満たされる場合があります。エクスポートプロセスは、IPFIXメッセージを一時停止、エクスポート、または廃棄する場合があります。データレコードが破棄された場合、エクスポートに使用されるIPFIXシーケンス番号は、データの損失を反映する必要があります。
SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery.
SCTPは、PATH MTU Discoveryに基づいて、必要なIPFIXメッセージフラグメンテーションサービスを提供します。
The IPFIX Exporting Process SHOULD initiate an SCTP association with the IPFIX Collecting Process. By default, the Collecting Process listens for connections on SCTP port 4739. By default, the Collecting Process listens for secure connections on SCTP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different SCTP port.
IPFIXエクスポートプロセスは、IPFIX収集プロセスとSCTP関連を開始する必要があります。デフォルトでは、収集プロセスはSCTPポート4739の接続のリッスンを聴きます。デフォルトでは、SCTPポート4740のセキュア接続の収集プロセスが耳を傾けます（セキュリティ上の考慮事項セクションを参照）。デフォルトでは、エクスポートプロセスはこれらのポートのいずれかに接続しようとします。エクスポートと収集プロセスの両方を構成して、異なるSCTPポートを使用することが可能である必要があります。
The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
エクスポートプロセスは、収集プロセスに複数の関連付け（SCTP用語で接続「バンドル」）を確立する場合があります。
An Exporting Process MAY support more than one active association to different Collecting Processes (including the case of different Collecting Processes on the same host).
エクスポートプロセスは、異なる収集プロセス（同じホストの異なる収集プロセスの場合を含む）との複数のアクティブな関連付けをサポートする場合があります。
When an Exporting Process is shut down, it SHOULD shut down the SCTP association.
エクスポートプロセスがシャットダウンされると、SCTP協会をシャットダウンする必要があります。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shut down its end of the association. The Collecting Process SHOULD continue to receive and process IPFIX Messages until the Exporting Process has closed its end of the association.
収集プロセスがIPFIXメッセージを受信したくない場合、協会の終わりをシャットダウンする必要があります。収集プロセスは、エクスポートプロセスが協会の終了を終了するまで、引き続きIPFIXメッセージを処理し、処理する必要があります。
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment.
収集プロセスがSCTP協会が異常に終了したことを検出すると、新しい協会の施設を聞き続ける必要があります。
When an Exporting Process detects that the SCTP association to the Collecting Process is abnormally terminated, it SHOULD try to re-establish the association.
輸出プロセスが、収集プロセスへのSCTP関連が異常に終了したことを検出する場合、関連性を再確立しようとする必要があります。
Association timeouts SHOULD be configurable.
アソシエーションのタイムアウトは構成可能である必要があります。
An Exporting Process MAY request more than one SCTP stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets.
エクスポートプロセスは、アソシエーションごとに複数のSCTPストリームを要求する場合があります。これらの各ストリームは、データセット、テンプレートセット、および/またはオプションテンプレートセットを含むIPFIXメッセージの送信に使用できます。
Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP stream established during SCTP Association setup.
アプリケーションの要件に応じて、エクスポートプロセスは、SCTP Associationのセットアップ中に確立されたSCTPストリームを介して、順序付けられたまたは順序外配信を使用して、完全または部分的な信頼性を備えたデータセットを送信する場合があります。
An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as per Section 4 of the PR-SCTP [RFC3758] specification when using partial reliability to transmit IPFIX Messages containing only Data Sets.
IPFIXエクスポートプロセスは、部分的信頼性を使用してデータセットのみを含むIPFIXメッセージを送信する場合、PR-SCTP [RFC3758]仕様のセクション4に従って、PR-SCTPサービス定義を使用する場合があります。
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow.
ただし、エクスポートプロセスは、リソースやその他の制約が許可する限り、再送信のためにこのようなIPFIXメッセージをマークする必要があります。
When the transport protocol is SCTP, the default Template Management described in Section 8 is used.
トランスポートプロトコルがSCTPの場合、セクション8で説明されているデフォルトのテンプレート管理が使用されます。
When the transport protocol is SCTP, the default Collector processing described in Section 9 is used.
輸送プロトコルがSCTPの場合、セクション9で説明されているデフォルトのコレクター処理が使用されます。
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish an association, the Exporting Process should retry using the SCTP exponential backoff feature. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold, configurable on the Exporter.
収集プロセスがエクスポートプロセスによる関連付けを確立する試みを認めていない場合、エクスポートプロセスはSCTP指数バックオフ機能を使用して再試行する必要があります。輸出業者は、関連付けを確立する時間が指定されたしきい値を超えている場合、輸出業者で設定可能な指定されたしきい値を超える場合、アラームを記録できます。
If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance.
プロセスの収集フェールオーバーがエクスポートプロセスによってサポートされている場合、2番目のSCTP協会が事前に開かれる場合があります。
This section describes how IPFIX can be transported over UDP [UDP].
このセクションでは、IPFIXをUDP [UDP]で輸送する方法について説明します。
UDP has no integral congestion-avoidance mechanism. Its use over congestion-sensitive network paths is therefore not recommended. UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion, i.e., over provisioned links compared to the maximum export rate from the Exporters.
UDPには、統合渋滞回避メカニズムがありません。したがって、混雑に敏感なネットワークパスでの使用は推奨されません。UDPは、輸出業者とコレクターが、輸出業者からの最大輸出レートと比較して、輸出業者とコレクターが常に混雑の影響を受けにくい専用のリンク、つまりプロビジョニングされたリンクを常に通信する展開で使用できます。
UDP is not a reliable transport protocol, and cannot guarantee delivery of messages. IPFIX Messages sent from the Exporting Process to the Collecting Process using UDP may therefore be lost. UDP MUST NOT be used unless the application can tolerate some loss of IPFIX Messages.
UDPは信頼できる輸送プロトコルではなく、メッセージの配信を保証することはできません。したがって、エクスポートプロセスからUDPを使用して収集プロセスに送信されたIPFIXメッセージが失われる可能性があります。アプリケーションがIPFIXメッセージの損失を許容できない限り、UDPを使用してはなりません。
The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Templates sent from the Exporting Process to the Collecting Process using UDP as a transport MUST be re-sent at regular intervals, in case previous copies were lost.
収集プロセスは、IPFIXシーケンス番号の不連続性を調べることにより、IPFIXデータレコードの損失と並べ替えを推定する必要があります。UDPの場合、IPFIXシーケンス番号には、このIPFIXメッセージの受信前にUDPトランスポートセッションに送信されたIPFIXデータレコードの総数が含まれています。Modulo2^32。コレクターは、シーケンス番号を追跡して、IPFIXメッセージをドロップしたり、複製したりするか、複製する必要があります。以前のコピーが失われた場合に備えて、輸送プロセスからUDPを使用して輸送を使用して収集プロセスに送信されたテンプレートを定期的に再整理する必要があります。
The maximum size of exported messages MUST be configured such that the total packet size does not exceed the path MTU. If the path MTU is unknown, a maximum packet size of 512 octets SHOULD be used.
エクスポートされたメッセージの最大サイズは、合計パケットサイズがパスMTUを超えないように構成する必要があります。パスMTUが不明の場合、512オクテットの最大パケットサイズを使用する必要があります。
By default, the Collecting Process listens on the UDP port 4739. By default, the Collecting Process listens for secure connections on UDP port 4740 (refer to the "Security Considerations" section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different UDP port.
デフォルトでは、収集プロセスはUDPポート4739に耳を傾けます。デフォルトでは、UDPポート4740のセキュア接続の収集プロセスが耳を傾けます（「セキュリティ上の考慮事項」セクションを参照）。デフォルトでは、エクスポートプロセスはこれらのポートのいずれかに接続しようとします。別のUDPポートを使用するように、エクスポートと収集プロセスの両方を構成することが可能である必要があります。
The Exporting Process MAY duplicate the IPFIX Message to the several Collecting Processes.
エクスポートプロセスは、IPFIXメッセージを複数の収集プロセスに複製する場合があります。
When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID to help ensure that the Collector has the Template Record before receiving the first Data Record.
IPFIXがTransport ProtocolとしてUDPを使用する場合、テンプレートセットとオプションテンプレートセットを定期的に再配置する必要があります。（オプション）テンプレート伝送の頻度は構成可能でなければなりません。（オプション）テンプレート伝送の頻度のデフォルト値は10分です。エクスポートプロセスでは、テンプレートセットとオプションテンプレートを送信する必要があります。その（オプション）テンプレートIDを使用するデータセットの前に、コレクターが最初のデータレコードを受信する前にテンプレートレコードを確保するのに役立ちます。
In the event of configuration changes, the Exporting Process SHOULD send multiple copies of the new Template definitions, in different IPFIX Messages, at an accelerated rate. In such a case, it SHOULD transmit the changed Template Record(s) and Options Template Record(s), without any data, in advance to help ensure that the Collector will have the correct Template information before receiving the first data.
構成が変更された場合、エクスポートプロセスは、新しいテンプレート定義の複数のコピーを、異なるIPFIXメッセージで、加速レートで送信する必要があります。そのような場合、最初のデータを受信する前にコレクターが正しいテンプレート情報を確保することを保証するために、データなしで、変更されたテンプレートレコードおよびオプションテンプレートレコードを事前に送信する必要があります。
If the Option Template scope is defined in another Template, then both Templates SHOULD be sent in the same IPFIX Message. For example, if a Flow Key Option Template (see Section 4.4) is sent in an Option Template, then the associated Template SHOULD be sent in the same IPFIX Message.
オプションテンプレートスコープが別のテンプレートで定義されている場合、両方のテンプレートを同じIPFIXメッセージで送信する必要があります。たとえば、フローキーオプションテンプレート（セクション4.4を参照）がオプションテンプレートで送信される場合、関連するテンプレートを同じIPFIXメッセージで送信する必要があります。
Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change) a new Template ID MUST be used, and the old Template ID MUST NOT be reused until its lifetime (see Section 10.3.7) has expired.
データレコードの解釈を変更できる構成変更に続いて（たとえば、サンプリングレートの変更）新しいテンプレートIDを使用する必要があり、古いテンプレートIDをその寿命まで再利用してはなりません（セクション10.3.7を参照）期限切れ。
If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
UDPがトランスポートプロトコルとして選択されている場合、UDPの信頼性の低い性質のためにこの方法は非効率的であるため、テンプレートの引き出しメッセージを使用する必要はありません。
The Collecting Process MUST associate a lifetime with each Template (or another definition of an identifier considered unique within the Transport Session) received via UDP. Templates (and similar definitions) not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. If the Template (or other definition) is not refreshed before that lifetime has expired, the Collecting Process MUST discard that definition and any current and future associated Data Records. In which case, an alarm MUST be logged. The Collecting Process MUST NOT decode any further Data Records that are associated with the expired Template. If a Template is refreshed with a Template Record that differs from the previously received Template Record, the Collecting Process SHOULD log a warning and replace the previously received Template Record with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process.
収集プロセスは、UDPを介して受信した各テンプレート（またはトランスポートセッション内で一意と見なされる識別子の別の定義）に寿命を関連付ける必要があります。テンプレート（および同様の定義）は、生涯内のエクスポートプロセスによって更新されていません。収集プロセスでは期限切れです。テンプレート（または他の定義）がその寿命が切れる前に更新されていない場合、収集プロセスはその定義と現在および将来の関連データレコードを破棄する必要があります。その場合、アラームを記録する必要があります。収集プロセスは、期限切れのテンプレートに関連付けられているさらなるデータレコードをデコードしてはなりません。テンプレートが以前に受信したテンプレートレコードとは異なるテンプレートレコードで更新されている場合、収集プロセスは警告を記録し、以前に受信したテンプレートレコードを新しいレコードに置き換える必要があります。収集プロセスでのテンプレート寿命は、エクスポートプロセスで構成されたテンプレート更新タイムアウトの少なくとも3倍でなければなりません。
Template IDs are unique per UDP session and per Observation Domain. At any given time, the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template Records: <IPFIX Device, Exporter source UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>.
テンプレートIDは、UDPセッションと観察ドメインごとに一意です。いつでも、収集プロセスは、現在のすべてのテンプレートレコードとオプションテンプレートレコードに対して以下を維持する必要があります：<IPFIXデバイス、エクスポートソースUDPポート、観測ドメインID、テンプレートID、テンプレート定義、最後に受信>。
The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions) required to decode the Data Record. If the Template Records (or other definitions such as Common Properties) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session.
収集プロセスは、データレコードをデコードするために必要な関連テンプレートレコード（またはその他の定義）なしでデータレコードを受け入れる必要があります。データレコードが受信された時点でテンプレートレコード（または共通プロパティなどのその他の定義）が受信されていない場合、収集プロセスはデータレコードを短時間保存し、テンプレートレコード（または他の定義の後にそれらをデコードする必要があります。）受け取られます。短期間は、UDPセッション内で一意と見なされる識別子に関連付けられた定義の寿命よりも低くなければなりません。
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error.
収集プロセスが奇形のIPFIXメッセージを受信した場合、IPFIXメッセージを破棄する必要があり、エラーを記録する必要があります。
Because UDP is not a connection-oriented protocol, the Exporting Process is unable to determine from the transport protocol that the Collecting Process is no longer able to receive the IPFIX Messages. Therefore, it cannot invoke a failover mechanism. However, the Exporting Process MAY duplicate the IPFIX Message to several Collecting Processes.
UDPは接続指向のプロトコルではないため、エクスポートプロセスは、収集プロセスがIPFIXメッセージを受信できなくなったことをトランスポートプロトコルから決定することができません。したがって、フェールオーバーメカニズムを呼び出すことはできません。ただし、エクスポートプロセスでは、IPFIXメッセージを複数の収集プロセスに複製する場合があります。
This section describes how IPFIX can be transported over TCP [TCP].
このセクションでは、TCP [TCP]を介してIPFIXを輸送する方法について説明します。
The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. By default, the Collecting Process listens for connections on TCP port 4739. By default, the Collecting Process listens for secure connections on TCP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting Process and the Collecting Process to use a different TCP port.
IPFIXエクスポートプロセスは、収集プロセスへのTCP接続を開始します。デフォルトでは、収集プロセスはTCPポート4739の接続のリッスンを聴きます。デフォルトでは、TCPポート4740のセキュア接続の収集プロセスが耳を傾けます（セキュリティ上の考慮事項セクションを参照）。デフォルトでは、エクスポートプロセスはこれらのポートのいずれかに接続しようとします。別のTCPポートを使用するように、エクスポートプロセスと収集プロセスの両方を構成することが可能である必要があります。
An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host).
エクスポートプロセスは、異なる収集プロセス（同じホストの異なる収集プロセスの場合を含む）への複数のアクティブな接続をサポートする場合があります。
The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter.
接続を確立する時間が指定されたしきい値を超えている場合、輸出業者はアラームを記録できます。
When an Exporting Process is shut down, it SHOULD shut down the TCP connection.
エクスポートプロセスがシャットダウンされると、TCP接続をシャットダウンする必要があります。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end.
収集プロセスがIPFIXメッセージを受信したくない場合、接続の終了を閉じる必要があります。収集プロセスは、エクスポートプロセスが終了するまでIPFIXメッセージの読み取りを続ける必要があります。
When a Collecting Process detects that the TCP connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection.
収集プロセスが、エクスポートプロセスへのTCP接続が異常に終了したことを検出した場合、新しい接続を聞き続ける必要があります。
When an Exporting Process detects that the TCP connection to the Collecting Process has terminated abnormally, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute.
エクスポートプロセスが、収集プロセスへのTCP接続が異常に終了したことを検出する場合、接続を再確立しようとする必要があります。接続タイムアウトと再試行スケジュールは構成可能である必要があります。デフォルトの構成では、エクスポートプロセスが1分あたり1回よりも頻繁に接続を確立しようとしてはなりません。
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish a connection, it will retry using the TCP exponential backoff feature.
収集プロセスが、接続を確立するためのエクスポートプロセスによる試みを認めない場合、TCP指数バックオフ機能を使用して再試行します。
If Collecting Process failover is supported by the Exporting Process, a second TCP connection MAY be opened in advance.
プロセスの収集フェールオーバーがエクスポートプロセスによってサポートされている場合、2番目のTCP接続が事前に開かれる場合があります。
Once a TCP connection is established, the Exporting Process starts sending IPFIX Messages to the Collecting Process.
TCP接続が確立されると、エクスポートプロセスはIPFIXメッセージの送信を収集プロセスに開始します。
IPFIX Messages are sent over the TCP connection without any special encoding. The Length field in the IPFIX Message Header defines the end of each IPFIX Message and thus the start of the next IPFIX Message. This means that IPFIX Messages cannot be interleaved.
IPFIXメッセージは、特別なエンコードなしでTCP接続を介して送信されます。IPFIXメッセージヘッダーの長さフィールドは、各IPFIXメッセージの終了、したがって次のIPFIXメッセージの開始を定義します。これは、IPFIXメッセージをインターリーブできないことを意味します。
In the case of TCP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent from this TCP connection, from the current Observation Domain by the Exporting Process, prior to the receipt of this IPFIX Message, modulo 2^32.
TCPの場合、IPFIXシーケンス番号には、このTCP接続から送信されたIPFIXデータレコードの総数が含まれています。このIPFIXメッセージを受信する前に、モジュロ2^32を受信する前に、エクスポートプロセスによる現在の観測ドメインから。
If an Exporting Process exports data from multiple Observation Domains, it should be careful to choose IPFIX Message lengths appropriately to minimize head-of-line blocking between different Observation Domains. Multiple TCP connections MAY be used to avoid head-of-line between different Observation Domains.
エクスポートプロセスが複数の観測ドメインからデータをエクスポートする場合、IPFIXメッセージの長さを適切に選択して、異なる観測ドメイン間の頭のブロッキングを最小限に抑えるように注意する必要があります。複数のTCP接続を使用して、異なる観測ドメイン間の直線を避けることができます。
For each Template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that Template.
各テンプレートについて、エクスポートプロセスは、そのテンプレートを参照するデータレコードをエクスポートする前にテンプレートレコードを送信する必要があります。
Template IDs are unique per TCP connection and per Observation Domain. A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records.
テンプレートIDは、TCP接続と観測ドメインごとに一意です。収集プロセスは、テンプレートレコードの再輸出にエクスポートプロセスは必要ないため、接続期間中、すべてのテンプレートおよびオプションテンプレートレコードを記録する必要があります。
When the TCP connection restarts, the Exporting Process MUST resend all the Template Records.
TCP接続が再起動すると、エクスポートプロセスはすべてのテンプレートレコードを再送信する必要があります。
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates.
TCP接続が閉じられている場合、収集プロセスは、その接続で受信されたすべてのテンプレートを破棄し、それらのテンプレートを使用するIPFIXメッセージのデコードを停止する必要があります。
The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message over the TCP connection.
使用されていないテンプレートは削除する必要があります。テンプレートIDを再利用する前に、テンプレートを削除する必要があります。割り当てられたテンプレートを削除するために、テンプレートは、TCP接続を介してテンプレートの引き出しメッセージを使用して撤回されます。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error.
収集プロセスが奇形のIPFIXメッセージを受信した場合、TCP接続をリセットし、IPFIXメッセージを破棄し、エラーをログに記録する必要があります。
TCP ensures reliable delivery of data from the Exporting Process to the Collecting Process. TCP also controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that takes into account both congestion in the network and the capabilities of the receiver.
TCPは、エクスポートプロセスから収集プロセスへのデータの信頼できる配信を保証します。TCPは、ネットワーク内の混雑と受信機の機能の両方を考慮したメカニズムを使用して、エクスポートプロセスから収集プロセスにデータを送信できるレートも制御します。
Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate that the Metering Process generates it, either because of congestion in the network or because the Collecting Process cannot handle IPFIX Messages fast enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. But such buffering is necessarily limited, both because of resource limitations and because of timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked.
したがって、IPFIXのエクスポートプロセスは、ネットワーク内の輻輳のため、または収集プロセスがIPFIXメッセージを十分に速く処理できないため、計量プロセスが生成するレートでIPFIXメッセージを送信できない場合があります。混雑が一時的である限り、エクスポートプロセスは送信用のIPFIXメッセージをバッファすることができます。しかし、このようなバッファリングは、リソースの制限と適時の要件のために必然的に制限されているため、継続的および/または深刻な混雑が輸出プロセスがブロックされる状況につながる可能性があります。
When an Exporting Process has Data Records to export but the transmission buffer is full, and it wants to avoid blocking, it can decide to drop some Data Records. The dropped Data Records MUST be accounted for, so that the amount can later be exported.
エクスポートプロセスにデータレコードがエクスポートしているが、送信バッファーがいっぱいになり、ブロックを避けたい場合、データレコードを削除することを決定できます。削除されたデータレコードは、後でエクスポートできるように、説明する必要があります。
When an Exporting Process finds that the rate at which records should be exported is consistently higher than the rate at which TCP sending permits, it should provide back pressure to the Metering Processes. The Metering Process could then adapt by temporarily reducing the amount of data it generates, for example, using sampling or aggregation.
エクスポートプロセスで、レコードをエクスポートすべきレートがTCP送信許可証よりも一貫して高いことがわかった場合、計量プロセスに戻る圧力を提供する必要があります。メータープロセスは、サンプリングや集約を使用して生成するデータの量を一時的に削減することで適応できます。
The Collecting Process SHOULD listen for a new TCP connection from the Exporting Process.
収集プロセスは、エクスポートプロセスから新しいTCP接続をリッスンする必要があります。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error. Note that non-zero Set padding does not constitute a malformed IPFIX Message.
収集プロセスが奇形のIPFIXメッセージを受信した場合、TCP接続をリセットし、IPFIXメッセージを破棄し、エラーをログに記録する必要があります。ゼロ以外のセットパディングは、奇形のIPFIXメッセージを構成しないことに注意してください。
Template Sets and Option Template Sets are only sent once. The Collecting Process MUST store the Template Record information for the duration of the connection so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
テンプレートセットとオプションテンプレートセットは、1回のみ送信されます。収集プロセスは、接続の期間中、テンプレートレコード情報を保存して、後続のデータセットで受信した対応するデータレコードを解釈できるようにする必要があります。
Template IDs are unique per TCP connection and per Observation Domain. If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the TCP connection), then the Collecting Process MUST shut down the connection.
テンプレートIDは、TCP接続と観測ドメインごとに一意です。収集プロセスがすでに受信されているが、以前に撤回されていないテンプレートを受信した場合（つまり、TCP接続で受信した同じテンプレートIDを使用して同じ輸出者観測ドメインからのテンプレートレコード）。接続。
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates.
TCP接続が閉じられている場合、収集プロセスは、その接続で受信されたすべてのテンプレートを破棄し、それらのテンプレートを使用するIPFIXメッセージのデコードを停止する必要があります。
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific TCP connection and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
収集プロセスがテンプレートの引き出しメッセージを受信する場合、収集プロセスは、特定のTCP接続および特定の観測ドメインに関連付けられた対応するテンプレートレコードを削除し、撤回したテンプレートを使用するIPFIXメッセージの解読を停止する必要があります。
If the Collecting Process receives a Template Withdrawal Message for a Template Record it has not received before on this TCP connection, it MUST reset the TCP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
収集プロセスが、このTCP接続でこれまでに受信していなかったテンプレートレコードのテンプレート引き出しメッセージを受信した場合、TCPアソシエーションをリセットし、IPFIXメッセージを破棄し、不正なIPFIXメッセージの場合と同様にエラーを記録する必要があります。
The security considerations for the IPFIX protocol have been derived from an analysis of potential security threats, as discussed in the "Security Considerations" section of IPFIX requirements [RFC3917]. The requirements for IPFIX security are as follows:
IPFIXプロトコルのセキュリティに関する考慮事項は、IPFIX要件[RFC3917]の「セキュリティ上の考慮事項」セクションで説明されているように、潜在的なセキュリティ脅威の分析から導き出されています。IPFIXセキュリティの要件は次のとおりです。
1. IPFIX must provide a mechanism to ensure the confidentiality of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent disclosure of Flow Records transported via IPFIX.
1. IPFIXは、IPFIXを介して輸送されるフロー記録の開示を防ぐために、エクスポートプロセスから収集プロセスに転送されるIPFIXデータの機密性を確保するメカニズムを提供する必要があります。
2. IPFIX must provide a mechanism to ensure the integrity of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent the injection of incorrect data or control information (e.g., Templates) into an IPFIX Message stream.
2. IPFIXは、誤ったデータまたは制御情報（テンプレートなど）の注入をIPFIXメッセージストリームに挿入するのを防ぐために、エクスポートプロセスから収集プロセスに転送されるIPFIXデータの整合性を確保するメカニズムを提供する必要があります。
3. IPFIX must provide a mechanism to authenticate IPFIX Collecting and Exporting Processes, to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process.
3. IPFIXは、不正なエクスポートプロセスまたは不正な収集プロセスへのデータのエクスポートからのデータの収集を防ぐために、IPFIXの収集とエクスポートプロセスを認証するメカニズムを提供する必要があります。
Because IPFIX can be used to collect information for network forensics and billing purposes, attacks designed to confuse, disable, or take information from an IPFIX collection system may be seen as a prime objective during a sophisticated network attack.
IPFIXを使用してネットワークフォレンジックと請求の目的で情報を収集できるため、IPFIXコレクションシステムから情報を混同、無効、または撮影するように設計された攻撃は、洗練されたネットワーク攻撃中に主要な目的と見なされる場合があります。
An attacker in a position to inject false messages into an IPFIX Message stream can either affect the application using IPFIX (by falsifying data), or the IPFIX Collecting Process itself (by modifying or revoking Templates, or changing options); for this reason, IPFIX Message integrity is important.
誤ったメッセージをIPFIXメッセージストリームに挿入する位置にある攻撃者は、IPFIXを使用してアプリケーションに影響を与える（データを偽造することにより）またはIPFIXを収集するプロセス自体（テンプレートを変更または取り外し、またはオプションを変更すること）のいずれかです。このため、IPFIXメッセージの整合性が重要です。
The IPFIX Messages themselves may also contain information of value to an attacker, including information about the configuration of the network as well as end-user traffic and payload data, so care must be taken to confine their visibility to authorized users. When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping. Suitable mechanisms include the use of either a direct point-to-point connection or the use of an encryption mechanism. It is the responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, anonymization of any reported data.
IPFIXメッセージ自体には、ネットワークの構成に関する情報やエンドユーザートラフィックとペイロードデータなど、攻撃者への価値の情報も含まれている場合があるため、認可されたユーザーに可視性を限定するように注意する必要があります。エンドユーザーのペイロード情報を含む情報要素がエクスポートされる場合、盗聴に対して内容を確保する手段を使用して、収集プロセスに送信する必要があります。適切なメカニズムには、直接ポイントツーポイント接続の使用または暗号化メカニズムの使用が含まれます。報告されたデータの匿名化を含む、この収集されたデータに満足のいくセキュリティを提供することは、収集プロセスの責任です。
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] were designed to provide the confidentiality, integrity, and authentication assurances required by the IPFIX protocol, without the need for pre-shared keys.
トランスポートレイヤーセキュリティ（TLS）[RFC4346]およびデータグラムトランスポートレイヤーセキュリティ（DTLS）[RFC4347]は、事前に共有キーを必要とせずに、IPFIXプロトコルが必要とする機密性、完全性、および認証保証を提供するように設計されました。
With the mandatory SCTP and PR-SCTP transport protocols for IPFIX, DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is selected as the IPFIX transport protocol, TLS [RFC4346] MUST be implemented.
IPFIX用の必須のSCTPおよびPR-SCTP輸送プロトコルを使用すると、DTLS [RFC4347]を実装する必要があります。UDPがIPFIXトランスポートプロトコルとして選択されている場合、DTLS [RFC4347]を実装する必要があります。TCPがIPFIXトランスポートプロトコルとして選択されている場合、TLS [RFC4346]を実装する必要があります。
Note that DTLS is selected as the security mechanism for SCTP and PR-SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they require all communication to be over reliable, bidirectional streams, and require one TLS connection per stream. This arrangement is not compatible with the rationale behind the choice of SCTP as an IPFIX transport protocol.
DTLSは、SCTPおよびPR-SCTPのセキュリティメカニズムとして選択されることに注意してください。SCTPへのTLSバインディングは[RFC3436]で定義されていますが、すべての通信が信頼性の高い双方向のストリームを超えて、ストリームごとに1つのTLS接続を必要とする必要があります。この配置は、IPFIXトランスポートプロトコルとしてのSCTPの選択の背後にある理論的根拠と互換性がありません。
Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man in the middle may attempt to take data out of an association and fool the sender into thinking that the data was actually received by the peer. In generic TLS for SCTP (and/or TCP), this is not possible. This means that the removal of a message may become hidden from the sender or receiver. Another vulnerability of using PR-SCTP with DTLS is that someone could inject SCTP control information to shut down the SCTP association, effectively generating a loss of IPFIX Messages if those are buffered outside of the SCTP association. In the future, techniques such as [dtls-for-sctp] could be used to overcome these vulnerabilities.
DTLS [RFC4347]の使用には脆弱性があります。つまり、真ん中の真の男は、関連からデータを取り除き、送信者を欺き、データが実際にピアによって受信されたと考えていることに注意してください。SCTP（および/またはTCP）の一般的なTLSでは、これは不可能です。これは、メッセージの削除が送信者または受信機から隠される可能性があることを意味します。PR-SCTPをDTLSで使用するもう1つの脆弱性は、SCTP協会をシャットダウンするためにSCTP制御情報を挿入し、SCTP協会の外部でバッファリングされている場合にIPFIXメッセージの損失を効果的に生成できることです。将来、[DTLS-For-SCTP]などの手法を使用して、これらの脆弱性を克服することができます。
When using DTLS over SCTP, the Exporting Process MUST ensure that each IPFIX Message is sent over the same SCTP stream that would be used when sending the same IPFIX Message directly over SCTP. Note that DTLS may send its own control messages on stream 0 with full reliability; however, this will not interfere with the processing of stream 0 IPFIX Messages at the Collecting Process, because DTLS consumes its own control messages before passing IPFIX Messages up to the application layer.
SCTPを介してDTLSを使用する場合、エクスポートプロセスは、各IPFIXメッセージをSCTPを介して直接送信するときに使用される同じSCTPストリームで各IPFIXメッセージが送信されることを確認する必要があります。DTLSは、完全な信頼性でストリーム0に独自の制御メッセージを送信する場合があることに注意してください。ただし、DTLSはIPFIXメッセージをアプリケーションレイヤーに渡す前に独自の制御メッセージを消費するため、これは収集プロセスでストリーム0 IPFIXメッセージの処理を妨げません。
The IPFIX Exporting Process initiates the communication to the IPFIX Collecting Process, and acts as a TLS or DTLS client according to [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a TLS or DTLS server. The DTLS client opens a secure connection on the SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as the transport protocol. The TLS client opens a secure connection on the TCP port 4740 of the TLS server if TCP is selected as the transport protocol. The DTLS client opens a secure connection on the UDP port 4740 of the DTLS server if UDP is selected as the transport protocol.
IPFIXエクスポートプロセスは、IPFIX収集プロセスへの通信を開始し、[RFC4346]および[RFC4347]に従ってTLSまたはDTLSクライアントとして機能し、IPFIXの収集プロセスはTLSまたはDTLSサーバーとして機能します。DTLSクライアントは、SCTPまたはPR-SCTPが輸送プロトコルとして選択されている場合、DTLSサーバーのSCTPポート4740に安全な接続を開きます。TLSクライアントは、TCPが輸送プロトコルとして選択されている場合、TLSサーバーのTCPポート4740に安全な接続を開きます。DTLSクライアントは、UDPがトランスポートプロトコルとして選択されている場合、DTLSサーバーのUDPポート4740に安全な接続を開きます。
IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received, for purposes of X.509 client and server certificates as in [RFC3280].
IPFIXのエクスポートプロセスとIPFIXの収集プロセスは、[RFC3280]のようにX.509クライアントおよびサーバー証明書の目的で、IPFIXメッセージが送信または受信されるインターフェイスの完全に適格なドメイン名によって識別されます。
To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints.
中間の攻撃が詐欺師の輸出または収集プロセスを防ぐには、不正な輸出プロセスからのデータの受け入れ、または不正な収集プロセスへのデータの輸出を、両方のTLSに強力な相互認証を使用する必要がありますおよびdtls。IPFIXの各エクスポートと収集プロセスは、そのピアの承認された証明書に対して同業他社のIDを検証する必要があり、ピアの証明書が完全に認定されたドメイン名と一致していること、またはSCTPの場合、完全に適格なドメイン名と一致することを確認する必要があります。そのエンドポイント。
The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate. If both are present, the subjectAltName extension is given preference.
IPFIXの収集プロセスまたはエクスポートプロセスを識別するために使用される完全に適格なドメイン名は、タイプDNSNAMEのsumbutaltname拡張、またはx.509証明書のサブジェクトフィールドの最も特定の共通名フィールドのいずれかに保存できます。両方が存在する場合、submictaltname拡張機能に優先順位が与えられます。
Internationalized domain names (IDN) in either the subjectAltName extension of type dNSName or the most specific Common Name field of the Subject field of the X.509 certificate MUST be encoded using Punycode [RFC3492] as described in Section 4 of [RFC3490], "Conversion Operations".
[rfc3490]のセクション4に記載されているように、x.509証明書の主題フィールドの主題拡張またはx.509証明書の主題フィールドの主題フィールドの主題フィールドの拡張機能またはx.509証明書の最も具体的な一般名フィールドのいずれかの国際化されたドメイン名（IDN）のいずれかのいずれかのいずれかで、」変換操作」。
An attacker may mount a denial-of-service (DoS) attack against an IPFIX collection system either directly, by sending large amounts of traffic to a Collecting Process, or indirectly, by generating large amounts of traffic to be measured by a Metering Process.
攻撃者は、収集プロセスに大量のトラフィックを送信するか、計量プロセスによって測定される大量のトラフィックを生成することにより、IPFIXコレクションシステムに対するサービス拒否（DOS）攻撃を直接攻撃することができます。
Direct denial-of-service attacks can also involve state exhaustion, whether at the transport layer (e.g., by creating a large number of pending connections), or within the IPFIX Collecting Process itself (e.g., by sending Flow Records pending Template or scope information, a large amount of Options Template Records, etc.).
直接拒否攻撃には、輸送層（たとえば、多数の保留中の接続を作成することによる）、またはIPFIXの収集プロセス自体（たとえば、保留中のテンプレートまたはスコープ情報を送信することにより）内で、状態の疲労を含むこともできます。、大量のオプションテンプレートレコードなど）。
SCTP mandates a cookie-exchange mechanism designed to defend against SCTP state exhaustion denial-of-service attacks. Similarly, TCP provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be used by any Collecting Process accepting TCP connections. DTLS also provides cookie exchange to protect against DTLS server state exhaustion.
The reader should note that there is no way to prevent fake IPFIX Message processing (and state creation) for UDP & SCTP communication. The use of TLS and DTLS can obviously prevent the creation of fake states, but they are themselves prone to state exhaustion attacks. Therefore, Collector rate limiting SHOULD be used to protect TLS & DTLS (like limiting the number of new TLS or DTLS session per second to a sensible number).
読者は、UDP＆SCTP通信のために偽のIPFIXメッセージ処理（および州の作成）を防ぐ方法がないことに注意する必要があります。TLSとDTLの使用は、明らかに偽の状態の作成を防ぐことができますが、それ自体が疲労攻撃を受ける傾向があります。したがって、TLSとDTLSを保護するためにコレクターレートの制限を使用する必要があります（新しいTLSまたはDTLSセッションの数を秒に制限するなど）。
IPFIX state exhaustion attacks can be mitigated by limiting the rate at which new connections or associations will be opened by the Collecting Process, the rate at which IPFIX Messages will be accepted by the Collecting Process, and adaptively limiting the amount of state kept, particularly records waiting on Templates. These rate and state limits MAY be provided by a Collecting Process; if provided, the limits SHOULD be user configurable.
IPFIX州の枯渇攻撃は、収集プロセスによって新しい接続または関連付けが開かれるレート、IPFIXメッセージが収集プロセスによって受け入れられるレートを制限することにより、緩和され、特に記録されている状態の量、特に記録を制限することにより、軽減できます。テンプレートを待っています。これらのレートと状態の制限は、収集プロセスによって提供される場合があります。提供されている場合、制限はユーザー構成可能である必要があります。
Additionally, an IPFIX Collecting Process can eliminate the risk of state exhaustion attacks from untrusted nodes by requiring TLS or DTLS mutual authentication, causing the Collecting Process to accept IPFIX Messages only from trusted sources.
さらに、IPFIXの収集プロセスは、TLSまたはDTLS相互認証を必要とすることにより、信頼されていないノードからの状態消耗攻撃のリスクを排除し、収集プロセスが信頼できるソースからのみIPFIXメッセージを受け入れるようにします。
With respect to indirect denial of service, the behavior of IPFIX under overload conditions depends on the transport protocol in use. For IPFIX over TCP, TCP congestion control would cause the flow of IPFIX Messages to back off and eventually stall, blinding the IPFIX system. PR-SCTP improves upon this situation somewhat, as some IPFIX Messages would continue to be received by the Collecting Process due to the avoidance of head-of-line blocking by SCTP's multiple streams and partial reliability features, possibly affording some visibility of the attack. The situation is similar with UDP, as some datagrams may continue to be received at the Collecting Process, effectively applying sampling to the IPFIX Message stream, implying that some forensics may be left.
間接的なサービス拒否に関しては、過負荷条件下でのIPFIXの動作は、使用中の輸送プロトコルに依存します。TCPを介したIPFIXの場合、TCPの混雑制御により、IPFIXメッセージのフローがバックオフされ、最終的にはIPFIXシステムが盲目になります。PR-SCTPは、SCTPの複数のストリームと部分的な信頼性機能による頭部ブロッキングの回避により、一部のIPFIXメッセージが収集プロセスによって引き続き受信され続け、攻撃の視認性がある可能性があるため、この状況を多少改善します。一部のデータグラムは収集プロセスで受け取られ続け、IPFIXメッセージストリームにサンプリングを効果的に適用し、一部の法医学が残っている可能性があることを意味するため、状況はUDPと同様です。
To minimize IPFIX Message loss under overload conditions, some mechanism for service differentiation could be used to prioritize IPFIX traffic over other traffic on the same link. Alternatively, IPFIX Messages can be transported over a dedicated network. In this case, care must be taken to ensure that the dedicated network can handle the expected peak IPFIX Message traffic.
過負荷条件下でのIPFIXメッセージの損失を最小限に抑えるために、サービス差別化のメカニズムを使用して、同じリンクの他のトラフィック上のIPFIXトラフィックに優先順位を付けることができます。または、IPFIXメッセージは専用ネットワークを介して輸送できます。この場合、専用ネットワークが予想されるピークIPFIXメッセージトラフィックを処理できるように注意する必要があります。
The use of DTLS or TLS might not be possible in some cases due to performance issues or other operational concerns.
パフォーマンスの問題やその他の運用上の懸念により、場合によってはDTLまたはTLSの使用は不可能です。
Without TLS or DTLS mutual authentication, IPFIX Exporting Processes and Collecting Processes can fall back on using IP source addresses to authenticate their peers. A policy of allocating Exporting Process and Collecting Process IP addresses from specified address ranges, and using ingress filtering to prevent spoofing, can improve the usefulness of this approach. Again, completely segregating IPFIX traffic on a dedicated network, where possible, can improve security even further. In any case, the use of open Collecting Processes (those that will accept IPFIX Messages from any Exporting Process regardless of IP address or identity) is discouraged.
TLSまたはDTLS相互認証がなければ、IPFIXのエクスポートプロセスと収集プロセスは、IPソースアドレスを使用してピアを認証することに頼ることができます。指定されたアドレス範囲からプロセスのプロセスを割り当て、プロセスIPアドレスを収集し、イングレスフィルタリングを使用してスプーフィングを防ぐというポリシーは、このアプローチの有用性を改善できます。繰り返しますが、可能であれば、専用ネットワーク上のIPFIXトラフィックを完全に分離すると、さらにセキュリティを改善できます。いずれにせよ、オープン収集プロセス（IPアドレスやIDに関係なく、エクスポートプロセスからIPFIXメッセージを受け入れるもの）の使用は落胆します。
Modern TCP and SCTP implementations are resistant to blind insertion attacks (see [RFC1948], [RFC4960]); however, UDP offers no such protection. For this reason, IPFIX Message traffic transported via UDP and not secured via DTLS SHOULD be protected via segregation to a dedicated network.
最新のTCPおよびSCTP実装は、盲検挿入攻撃に耐性があります（[RFC1948]、[RFC4960]を参照）。ただし、UDPはそのような保護を提供しません。このため、UDPを介して輸送され、DTLを介して保護されていないIPFIXメッセージトラフィックは、専用ネットワークへの分離を介して保護する必要があります。
IPFIX Collecting Processes MUST detect potential IPFIX Message insertion or loss conditions by tracking the IPFIX Sequence Number, and SHOULD provide a logging mechanism for reporting out-of-sequence messages. Note that an attacker may be able to exploit the handling of out-of-sequence messages at the Collecting Process, so care should be taken in handling these conditions. For example, a Collecting Process that simply resets the expected Sequence Number upon receipt of a later Sequence Number could be temporarily blinded by deliberate injection of later Sequence Numbers.
IPFIXの収集プロセスは、IPFIXシーケンス番号を追跡することにより、潜在的なIPFIXメッセージ挿入または損失条件を検出する必要があり、アウトアウトシーケンスメッセージを報告するためのログメカニズムを提供する必要があります。攻撃者は、収集プロセスでアウトシーケンスメッセージの処理を悪用できる可能性があるため、これらの条件の処理には注意する必要があります。たとえば、後のシーケンス番号を受け取ったときに予想されるシーケンス番号を単純にリセットする収集プロセスは、後のシーケンス番号の意図的な注入によって一時的に盲目になる可能性があります。
IPFIX Exporting and Collecting Processes SHOULD log any connection attempt that fails due to authentication failure, whether due to being presented an unauthorized or mismatched certificate during TLS or DTLS mutual authentication, or due to a connection attempt from an unauthorized IP address when TLS or DTLS is not in use.
IPFIXのエクスポートと収集プロセスは、TLSまたはDTLS相互認証中に許可されていないまたは不一致の証明書を提示された場合、またはTLSまたはDTLSの場合の無許可のIPアドレスからの接続試行による、認証障害のために失敗する接続試行をログに記録する必要があります。使用されていません。
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset.
IPFIXのエクスポートと収集プロセスは、SCTP Association ResetまたはTCP Connection Resetを検出およびログに記録する必要があります。
The security of the Collector and its implementation is important to achieve overall security. However, it is outside the scope of this document.
コレクターのセキュリティとその実装は、全体的なセキュリティを達成するために重要です。ただし、このドキュメントの範囲外です。
IPFIX Messages use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message.
IPFIXメッセージは、割り当てられた値で2つのフィールドを使用します。これらはIPFIXバージョン番号であり、IPFIXプロトコルのバージョンがIPFIXメッセージをエクスポートするために使用されたか、IPFIXセットIDを示し、IPFIXメッセージ内の各情報セットのタイプを示します。
The IPFIX Version Number value of 10 is reserved for the IPFIX protocol specified in this document. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. The Set ID value of 2 is reserved for the Template Set. The Set ID value of 3 is reserved for the Option Template Set. All other Set ID values from 4 to 255 are reserved for future use. Set ID values above 255 are used for Data Sets.
10のIPFIXバージョン番号値は、このドキュメントで指定されたIPFIXプロトコルに予約されています。0および1の設定ID値は、歴史的な理由で使用されません[RFC3954]。2のセットID値は、テンプレートセットに予約されています。3の設定ID値は、オプションテンプレートセットに予約されています。4〜255の他のすべてのセットID値は、将来の使用のために予約されています。255を超える設定ID値は、データセットに使用されます。
New assignments in either IPFIX Version Number or IPFIX Set ID assignments require a Standards Action [RFC2434], i.e., they are to be made via Standards Track RFCs approved by the IESG.
IPFIXバージョン番号またはIPFIXセットID割り当てのいずれかの新しい割り当てには、標準アクション[RFC2434]が必要です。つまり、IESGによって承認された標準トラックRFCSを介して作成されます。
This appendix, which is a not a normative reference, contains IPFIX encoding examples.
規範的な参照ではないこの付録には、IPFIXをエンコードする例が含まれています。
Let's consider the example of an IPFIX Message composed of a Template Set, a Data Set (which contains three Data Records), an Options Template Set and a Data Set (which contains 2 Data Records related to the previous Options Template Record).
テンプレートセット、データセット（3つのデータレコードを含む）、オプションテンプレートセット、およびデータセット（以前のオプションテンプレートレコードに関連する2つのデータレコードが含まれる）で構成されるIPFIXメッセージの例を考えてみましょう。
IPFIX Message:
IPFIXメッセージ：
+--------+------------------------------------------. . .
| | +--------------+ +------------------+
|Message | | Template | | Data |
| Header | | Set | | Set | . . .
| | | (1 Template) | | (3 Data Records) |
| | +--------------+ +------------------+
+--------+------------------------------------------. . .
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+
The Message Header is composed of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x000a | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
次の情報要素を報告します。
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4ソースIPアドレス：[RFC5102]のsoulityIpv4Address、4オクテットの長さ
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4宛先IPアドレス：[RFC5102]のDestinationIPv4Address、4オクテットの長さ
- The next-hop IP address (IPv4): ipNextHopIPv4Address in [RFC5102], with a length of 4 octets
- 次のホップIPアドレス（IPv4）：[RFC5102]のIPNEXTHOPIPV4ADDRESS、4オクテットの長さ
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- フローのパケットの数：[RFC5102]のInpacketdeltacount、4オクテットの長さ
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
- フローのオクテットの数：[RFC5102]のinoctetdeltacount、4オクテットの長さ
Therefore, the Template Set will be composed of the following:
したがって、テンプレートセットは次のもので構成されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
次の情報要素を報告します。
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4ソースIPアドレス：[RFC5102]のsoulityIpv4Address、4オクテットの長さ
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4宛先IPアドレス：[RFC5102]のDestinationIPv4Address、4オクテットの長さ
- An enterprise-specific Information Element representing proprietary information, with a type of 15 and a length of 4
- 15のタイプと4の長さの独自の情報を表すエンタープライズ固有の情報要素
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- フローのパケットの数：[RFC5102]のInpacketdeltacount、4オクテットの長さ
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
- フローのオクテットの数：[RFC5102]のinoctetdeltacount、4オクテットの長さ
Therefore, the Template Set will be composed of the following:
したがって、テンプレートセットは次のもので構成されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element Id. = 15| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following three Flow Records:
この例では、次の3つのフローレコードを報告します。
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets
| | | Number | Number
------------------------------------------------------------------
192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that padding is not necessary in this example.
この例では、パディングは必要ないことに注意してください。
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
ラインカードごと（ルーターは2つのラインカードで構成されています）、次の情報要素を報告します。
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIXメッセージの総数：ExportedPacketCount [RFC5102]、2オクテットの長さ
- Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
- エクスポートされたフローの総数：exportedFlowCount [RFC5102]、2オクテットの長さ
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
LinecardID情報要素[RFC5102]で表されるラインカードは、スコープフィールドとして使用されます。
Therefore, the Options Template Set will be:
したがって、オプションテンプレートセットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
ラインカードごと（ルーターは2つのラインカードで構成されています）、次の情報要素を報告します。
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIXメッセージの総数：ExportedPacketCount [RFC5102]、2オクテットの長さ
- An enterprise-specific number of exported Flows, with a type of 42 and a length of 4 octets
- 42のタイプと4オクテットの長さのエンタープライズ固有のエクスポートフローの数
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
LinecardID情報要素[RFC5102]で表されるラインカードは、スコープフィールドとして使用されます。
The format of the Options Template Set is as follows:
オプションテンプレートセットの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |1|Information Element Id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Enterprise number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise number | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we want to export the same information as in the example in Section A.4.1:
この例では、セクションA.4.1の例と同じ情報をエクスポートする必要があります。
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIXメッセージの総数：ExportedPacketCount [RFC5102]、2オクテットの長さ
- Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
- エクスポートされたフローの総数：exportedFlowCount [RFC5102]、2オクテットの長さ
But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123.
しかし今回は、情報は、エンタープライズ固有の情報要素番号123によって特定された独自の範囲に関するものです。
The format of the Options Template Set is now as follows:
オプションテンプレートセットの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 260 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 | Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise Number |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following two Data Records:
この例では、次の2つのデータレコードを報告します。
Line Card ID | IPFIX Message | Exported Flow Records
-------------------------------------------------------------------
Line Card 1 (lineCardId=1) | 345 | 10201
Line Card 2 (lineCardId=2) | 690 | 20402
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 260 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 345 | 10201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | 1000 | IE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1000 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
References
参考文献
Normative References
引用文献
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、Rescorla、E。、およびM. Tuexen、「ストリーム制御伝送プロトコル上の輸送層セキュリティ」、RFC 3436、2002年12月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M.、およびP. Conrad、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5102] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
Informative References
参考引用
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture Model for IP Flow Information Export", Work in Progress, September 2006.
[Ipfix-arch] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートの建築モデル」、2006年9月、進行中の作業。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, June 2007.
[IPFIX-AS] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「Ipfix Applicability」、2007年6月、進行中の作業。
[PEN] IANA Private Enterprise Numbers registry http://www.iana.org/assignments/enterprise-numbers.
[PEN] IANAプライベートエンタープライズ番号レジストリhttp://www.iana.org/assignments/enterprise-numbers。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948] Bellovin、S。、「シーケンス番号攻撃に対する防御」、RFC 1948、1996年5月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[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月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、ed。、「Cisco Systems Netflow Services Export Version 9」、RFC 3954、2004年10月。
[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
[IEEE.754.1985]電気およびエレクトロニクスエンジニアの研究所、「バイナリフローティングポイント算術の標準」、IEEE Standard 754、1985年8月。
[dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer Security for Stream Control Transmission Protocol", Work in Progress, November 2007.
[DTLS-For-SCTP] Tuexen、M。およびE. Rescola、「Stream Control Transmission Protocolのデータグラムトランスポートレイヤーセキュリティ」、2007年11月、進行中の作業。
Acknowledgments
謝辞
We would like to thank the following persons: Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification; Juergen Quittek for the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and Andrew Johnson for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise and contributions; Martin Djernaes for the first essay on the SCTP section; Michael Behringer and Eric Vyncke for their advice and knowledge in security; Michael Tuexen for his help regarding the DTLS section; Elisa Boschi for her contribution regarding the improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, and many more, for the technical reviews and feedback.
次の人に感謝します。GaneshSadasivanは、プロトコル仕様の初期段階で重要な貢献をしてくれました。IPFIXとPSAMP内の調整ジョブのJuergen Quittek。徹底的なレビューのために、ネビル・ブラウンリー、デイブ・プロンカ、ポール・エイトケン、アンドリュー・ジョンソン。Randall StewartとPeter LeiのSCTPの専門知識と貢献について。SCTPセクションの最初のエッセイのMartin Djernaes。マイケル・ベーリンガーとエリック・ヴィンケは、セキュリティに関するアドバイスと知識を求めています。Michael Tuexenは、DTLSセクションに関する彼の助けについて。SCTPセクションの改善に関する貢献についてのElisa Boschi。マーク・フルマー、セバスチャン・ザンダー、ジェフ・マイヤー、マウリツィオ・モリナ、カーター・ブラード、タル・ギボリー、ルッツ・マーク、デビッド・ムーア、ロバート・ロウ、ポール・カラートなど、技術的なレビューとフィードバック。
Authors' Addresses
著者のアドレス
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
Benoit Claise Cisco Systems de Kleetlaan 6a B1 1831 Diegem Belgium電話：32 2 704 5622メール：bclaise@cisco.com
Stewart Bryant Cisco Systems, Inc. 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom Phone: +44 (0)20 8824-8828 EMail: stbryant@cisco.com
Stewart Bryant Cisco Systems、Inc。250、Longwater、Green Park、Reading、RG2 6GB、英国電話：44（0）20 8824-8828メール：stbryant@cisco.com
Simon Leinen SWITCH Werdstrasse 2 P.O. Box CH-8021 Zurich Switzerland Phone: +41 44 268 1536 EMail: simon.leinen@switch.ch
サイモンレイネンスイッチWerdstrasse 2 P.O.ボックスCH-8021チューリッヒスイス電話：41 44 268 1536メール：simon.leinen@switch.ch
Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 EMail: Thomas.Dietz@nw.neclab.eu
Thomas Dietz Nec Europe Ltd. Nec Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany電話：49 6221 4342-128メール：thomas.dietz@nw.neclab.eu
Brian H. Trammell CERT Network Situational Awareness Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213 United States Phone: +1 412 268 9748 EMail: bht@cert.org
ブライアンH.トラメルCERTネットワーク状況認識ソフトウェアエンジニアリングインスティテュート4500フィフスアベニューピッツバーグ、ペンシルバニア州15213米国電話：1 412 268 9748メール：bht@cert.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。