[要約] RFC 5101は、ネットワークトラフィックの詳細な統計情報（フロー情報）を計測デバイスから収集サーバーへ転送するためのプロトコル「IPFIX（IP Flow Information Export）」の基本仕様を定義しています。NetFlow v9をベースに標準化され、テンプレートを用いた柔軟なデータ構造によって、セキュリティ分析やトラフィックエンジニアリングに必要な多角的なフローデータの交換を実現します（RFC 7011によって上書きされました）。
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 Flow Information Export (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.
観測ドメイン（Observation Domain）は、メータリングプロセスによってフロー情報を集約できる観測点（Observation Point）の最大の集合です。例えば、ルータのラインカードが複数のインタフェースで構成され、そのそれぞれが観測点である場合、そのラインカードは1つの観測ドメインになることがあります。観測ドメインは、生成するIPFIXメッセージ内に、エクスポートプロセスごとに一意であるObservation Domain IDを含めます。これにより、収集プロセスは、IPFIXメッセージを送信するエクスポータからの特定の観測ドメインを識別できます。すべての観測点は1つの観測ドメインに関連付けられます。Observation Domain IDは、IPFIXデバイスごとにも一意であることが推奨されます (RECOMMENDED)。
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).
エクスポータは、Message Headerおよび各種Setのすべてのバイナリ整数をネットワークバイト順（ビッグエンディアンバイト順としても知られる）で符号化しなければなりません (MUST)。
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 Data Recordの増分シーケンスカウンタ（modulo 2^32）。トランスポートプロトコルとしてUDPまたはTCPが選択されている場合のこのフィールドの特定の意味については、セクション10のサブセクションを確認してください。この値は、IPFIX Data Recordが欠落したかどうかを識別するために収集プロセスによって使用されるべきです (SHOULD)。Template RecordおよびOptions Template RecordはSequence Numberを増加させません。
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ビット識別子。エクスポートプロセスは、フローを測定した観測ドメインを収集プロセスに対して一意に識別するためにObservation Domain IDを使用します。この識別子は、IPFIXデバイスごとにも一意であることが推奨されます (RECOMMENDED)。収集プロセスは、同じエクスポートプロセスから発生する異なるエクスポートストリームを分離するために、Transport SessionとObservation Domain IDフィールドを使用すべきです (SHOULD)。IPFIXメッセージ全体に対して特定のObservation Domain IDが関連しない場合（例えばExporting Process Statisticsをエクスポートする場合や、集約されたData Recordがエクスポートされるコレクタの階層構造の場合など）、Observation Domain IDは0であるべきです (SHOULD)。
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.
情報要素（Information Element）は、情報要素識別子によって識別されます。Enterpriseビットが0に設定されている場合、対応する情報要素識別子はIETF指定の情報要素を報告し、Enterprise Numberは存在してはなりません (MUST NOT)。Enterpriseビットが1に設定されている場合、対応する情報要素識別子は企業固有の情報要素を報告し、Enterprise Numberが存在しなければなりません (MUST)。この例はセクション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.
Enterpriseビット。これはField Specifierの最初のビットです。このビットが0の場合、情報要素識別子はIETF指定の情報要素を識別し、4オクテットのEnterprise Numberフィールドは存在してはなりません (MUST NOT)。このビットが1の場合、情報要素識別子は企業固有の情報要素を識別し、Enterprise Numberフィールドが存在しなければなりません (MUST)。
Information Element identifier
情報要素識別子
A numeric value that represents the type of Information Element. Refer to [RFC5102].
情報要素のタイプを表す数値。[RFC5102]を参照してください。
Field Length
フィールドの長さ
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.
Setは図Hに示す形式を持ちます。レコードタイプは、Template Record、Options Template Record、またはData Recordのいずれかです。Set内でレコードタイプを混在させてはなりません (MUST NOT)。
+--------------------------------------------------+
| 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.
エクスポートプロセスは、後続のSetがアライメントされた境界から始まるように、いくつかのパディングオクテットを挿入してもよい (MAY)。セキュリティ上の理由から、パディングオクテットは値ゼロ（0）のオクテットで構成されなければなりません (MUST)。パディング長は、このSet内の許容されるいかなるレコードよりも短くなければなりません (MUST)。非常に短いレコードと組み合わせてIPFIXメッセージのパディングを行うことが望まれる場合、パディング情報要素 'paddingOctets' [RFC5102] を使用して、レコードの長さが4または8オクテットの倍数に増加するようにレコードをパディングできます。Template Setは定義上常に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.
Set Header、すべてのレコード、および任意のパディングを含む、Setの全長（オクテット単位）。個々のSetには複数のレコードが含まれてもよい (MAY) ため、次のSetの位置を特定するにはLength値を使用しなければなりません (MUST)。
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.
Options Template Setでのみ利用可能なスコープは、Data Record内で報告される情報要素のコンテキストを提供します。IPFIX Message HeaderにはすでにObservation Domain ID（観測ドメインの識別子）が含まれていることに注意してください。ゼロでない場合、このObservation Domain IDはIPFIXメッセージ内のData Recordに対する暗黙のスコープと見なすことができます。IPFIXメッセージにスコープとして定義された異なるObservation Domain ID値を持つData Recordが含まれている場合、Observation Domain IDはゼロでなければなりません (MUST)。
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.
Options Template Recordには複数のScope Fieldが存在してもよく (MAY)、その場合、複合スコープはそれらのスコープの組み合わせとなります。例えば、2つのスコープが「メータリングプロセス」と「テンプレート」として定義されている場合、組み合わされたスコープはこのメータリングプロセスに対するこのテンプレートになります。Options Template Recordで定義されているScope Fieldの順序は、この場合は無関係です。ただし、Options Template Record内のScope Fieldの順序が意味を持つ場合、そのScope Fieldの順序を使用しなければなりません (MUST)。例えば、第1のスコープがフィルタリング機能を定義し、第2のスコープがサンプリング機能を定義する場合、スコープの順序が重要になります。最初にサンプリング機能を適用し、その後にフィルタリング機能を適用すると、最初にフィルタリング機能を適用し、その後にサンプリング機能を適用した場合とは潜在的に異なるData Recordが生成されます。この場合、コレクタはOptions Template Record内のスコープの順序を見ることによって機能の順序を推測します。
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準拠実装は、スコープとして以下の情報要素の最小セットをサポートすべきです (SHOULD)：LineCardId、TemplateId、exporterIPv4Address、exporterIPv6Address、およびingressInterface。meteringProcessId、exportingProcessId、observationDomainIdなどの他の情報要素も有効なスコープであることに注意してください。IPFIXプロトコルは、スコープとして任意の情報要素を使用することを妨げません。ただし、一部の情報要素タイプはスコープとして指定しても意味をなしません（例えばカウンタ情報要素など）。
Finally, note that the Scope Field Count MUST NOT be zero.
最後に、Scope Field Countはゼロであってはならない (MUST NOT) ことに注意してください。
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.
このOptions Template Record内のスコープフィールドの数。Scope Fieldは、コレクタにおいてスコープとして解釈されることを除いて通常のフィールドです。Scope Field Countはゼロであってはなりません (MUST NOT)。
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.
これらのサブセクションで定義されているOption TemplateおよびOptions Template Recordは、メータリングプロセスおよびエクスポートプロセスの実装にいくつかの制約を課すものであり、実装してもよい (MAY)。実装される場合、特定のOption Templateはこれらのサブセクションで指定されているとおりに実装されるべきです (SHOULD)。
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.
Metering Process Statistics Option Templateは、メータリングプロセスの統計情報を報告するためのData Recordの構造を指定します。これには [RFC5102] で定義されている以下の情報要素を含めるべきです (SHOULD)：observationDomainId：エクスポートプロセスに対してローカルに一意である観測ドメインの識別子。この情報要素はScope Fieldとして定義しなければなりません (MUST)。
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.
エクスポートプロセスは、Metering Process Statistics Option Templateで指定されたData Recordを定期的に、または何らかのエクスポートポリシーに基づいてエクスポートすべきです (SHOULD)。この周期性またはエクスポートポリシーは設定可能であるべきです (SHOULD)。
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を追加のScope Fieldとして指定しなければならない (MUST) ことに注意してください。
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]:
Metering Process Reliability Option Templateは、メータリングプロセスにおける信頼性の欠如を報告するためのData Recordの構造を指定します。これには [RFC5102] で定義されている以下の情報要素を含めるべきです (SHOULD)：
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.
observationDomainId：エクスポートプロセスに対してローカルに一意である観測ドメインの識別子。この情報要素はScope Fieldとして定義しなければなりません (MUST)。
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.
エクスポートプロセスは、Metering Process Reliability Statistics Option Templateで指定されたData Recordを定期的に、または何らかのエクスポートポリシーに基づいてエクスポートすべきです (SHOULD)。この周期性またはエクスポートポリシーは設定可能であるべきです (SHOULD)。
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を追加のScope Fieldとして指定しなければならない (MUST) ことに注意してください。
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]:
Exporting Process Reliability Option Templateは、エクスポートプロセスにおける信頼性の欠如を報告するためのData Recordの構造を指定します。これには [RFC5102] で定義されている以下の情報要素を含めるべきです (SHOULD)：
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.
Exporting Process ID：信頼性の欠如が報告されるエクスポートプロセスの識別子。この目的で使用できる情報要素として [RFC5102] で指定されているものが3つあります：exporterIPv4Address、exporterIPv6Address、またはexportingProcessId。この情報要素はScope Fieldとして定義しなければなりません (MUST)。
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.
エクスポートプロセスは、Exporting Process Reliability Statistics Option Templateで指定されたData Recordを定期的に、または何らかのエクスポートポリシーに基づいてエクスポートすべきです (SHOULD)。この周期性またはエクスポートポリシーは設定可能であるべきです (SHOULD)。
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 Option Templateには、[RFC5102] で定義されている以下の情報要素を含めるべきです (SHOULD)：
templateId An identifier of a Template. This Information Element MUST be defined as a Scope Field.
templateId：テンプレートの識別子。この情報要素はScope Fieldとして定義しなければなりません (MUST)。
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 Message Headerの "Export Time" フィールドは、IPFIX Message Headerがエクスポータを離れた、1970年1月1日00:00 UTCからの秒単位の時刻です。[RFC5102] で指定されている時間関連の情報要素は、1970年1月1日00:00 UTCなどの共通の基準時刻を使用する代わりに、この "Export Time" を基準時刻として使用し、それに対する相対オフセットを指定してもよい (MAY)。データ型によって基準時刻が定義されていないすべての情報要素は、その説明の中で基準時刻が明確に指定されていなければなりません (MUST)。
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] は、ネットワークバイト順（ビッグエンディアンバイト順としても知られる）の標準形式で送信しなければなりません (MUST)。
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）は、ネットワークバイト順のデフォルトの標準形式を使用してエンコードしなければなりません (MUST)。符号付き整数データ型は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）は、整数データ型と同じ方法でエンコードしなければなりません (MUST)。macAddressは6オクテットの整数、ipv4Addressは4オクテットの整数、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ビット浮動小数点型としてエンコードしなければなりません (MUST)。
The float64 data type MUST be encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985].
float64データ型は、[IEEE.754.1985] で指定されているIEEE倍精度64ビット浮動小数点型としてエンコードしなければなりません (MUST)。
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.
booleanデータ型は [RFC2579] のTruthValueに従って指定されます：trueの場合は値1、falseの場合は値2を持つ整数です。他のすべての値は未定義です。booleanデータ型は単一のオクテットでエンコードしなければなりません (MUST)。
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.
stringデータ型は、Unicode文字符号化セットの有効な文字からなる有限長の文字列を表します。stringデータ型はUTF-8形式でエンコードしなければなりません (MUST)。文字列は、固定長または可変長の情報要素を使用してオクテットの配列として送信されます。
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タイムゾーンに正規化された秒単位の時間値を表します。これは、1970年1月1日00:00 UTCからの秒数を含む32ビット整数でエンコードしなければなりません (MUST)。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タイムゾーンに正規化されたミリ秒単位の時間値を表します。これは、1970年1月1日00:00 UTCからのミリ秒数を含む64ビット整数でエンコードしなければなりません (MUST)。
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タイムゾーンに正規化されたマイクロ秒単位の時間値を表します。これは、[RFC1305] で示されているNTP形式に従って64ビット整数でエンコードしなければなりません (MUST)。
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].
dateTimeNanosecondsデータ型は、GMTタイムゾーンに正規化されたナノ秒単位の時間値を表します。これは、[RFC1305] で示されているNTP形式に従って64ビット整数でエンコードしなければなりません (MUST)。
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.
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).
サイズ縮小を使用する場合、以下の整数型にのみ適用しなければなりません (MUST)：unsigned64、signed64、unsigned32、signed32、unsigned16、およびsigned16。報告される値の符号付きまたは符号なしの特性は維持されなければなりません (MUST)。データ値が収まる場合（すなわち先行ゼロのみが削除される場合）、元の型より小さい任意のオクテット数にサイズを縮小できます。例えば、unsigned64は7、6、5、4、3、2、または1オクテットにサイズを縮小できます。
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またはdateTimeNanosecondsに適用してはなりません (MUST NOT)。これらは、元のバイト数未満を使用することによって破壊されてしまう固有の構造を表しているためです。
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および独自の情報要素の両方に対して長さ情報を運ぶために、以下のメカニズムを使用しなければなりません (MUST)。
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.
長さを運ぶオクテット（最初の1オクテットまたは最初の3オクテット）は、情報要素の長さに含めてはなりません (MUST NOT)。
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.
特定の情報要素がテンプレートによって要求されているものの、観察されたパケット内で利用できない場合、エクスポートプロセスは、新しいテンプレートによって定義されたData Record内でこの情報要素を含めずにFlow Recordをエクスポートすることを選択してもよい (MAY)。
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.
テンプレート内で情報要素が複数回要求される場合、この情報要素の異なる出現は、メータリングプロセスによる処理の論理的順序に従うべきです (SHOULD)。例えば、選択されたパケットが2つのハッシュ関数を通過し、その2つのハッシュ値が単一のテンプレート内で送信される場合、ハッシュ値の最初の出現はメータリングプロセスにおける最初のハッシュ関数に属するべきです。例えば、IPv4 in 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.
Template SetおよびOptions Template Setは、任意のSCTPストリーム上で送信できます。Template SetおよびOptions Template Setは、SCTPの順序保証配送（SCTP-ordered delivery）を使用して確実に送信されなければなりません (MUST)。そのため、収集プロセスは、後続のData Setで受信される対応するData Recordを解釈できるように、SCTPアソシエーションの期間中、Template Record情報を保存しなければなりません (MUST)。
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).
エクスポートプロセスは、コレクタが最初のData Recordを受信する前にTemplate Recordを持っていることを確実にするために、その（Options）Template IDを使用するいかなるData Setよりも前にTemplate SetおよびOptions Template Setを送信すべきです (SHOULD)。Template Recordに対応するData Recordは、同一および/または後続のIPFIXメッセージ内に現れてもよい (MAY)。
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.
もはや使用されないテンプレートは削除すべきです (SHOULD)。Template IDを再利用する前に、そのテンプレートは削除されなければなりません (MUST)。割り当てられたテンプレートを削除するために、テンプレートはTemplate Withdrawal Messageを使用して撤回されます。
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.
Template Withdrawal Messageは、収集プロセスがこのテンプレート情報を使用して最新のData Recordを受信および処理できるように十分な時間が経過するまで送信してはなりません (MUST NOT)。この時間は設定可能でなければなりません (MUST)。適切なデフォルト値は、最新のData Recordが送信されてから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.
撤回されたテンプレートからのTemplate IDは、収集プロセスがTemplate Withdrawal Messageを受信および処理できるように十分な時間が経過するまで再利用してはなりません (MUST NOT)。
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.
Set IDフィールドは、Template Setの撤回の場合は値2を、Options Template Setの撤回の場合は値3を含まなければなりません (MUST)。単一のTemplate Withdrawal Messageで複数のTemplate IDを撤回してもよく (MAY)、その場合、パディングを使用してもよい (MAY)。
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.
Template Withdrawal Messageは、任意のSCTPストリーム上で送信してもよい。Template Withdrawal Messageは、SCTPの順序保証配送を使用して確実に送信されなければなりません (MUST)。
The Template Withdrawal Message MUST NOT contain new Template or Options Template Records.
Template Withdrawal Messageには、新しいTemplate RecordまたはOptions Template Recordを含めてはなりません (MUST NOT)。
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.
新しいテンプレートが必要になるように測定パラメータが変更された場合、そのテンプレートを撤回しなければならないか (MUST)（Template Withdrawal Messageと新しいテンプレート定義を使用）、あるいは未使用のTemplate IDを使用しなければなりません (MUST)。測定の変更の例としては、新しいサンプリングレート、新しいフロー期限切れ処理、新しいフィルタリング定義などがあります。
When the SCTP association shuts down or the Exporting Process restarts, all Template assignments are lost and Template IDs MUST be reassigned.
SCTPアソシエーションがシャットダウンするか、エクスポートプロセスが再起動した場合、すべてのテンプレート割り当ては失われ、Template IDは再割り当てされなければなりません (MUST)。
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.
メータリングプロセスが再起動した場合、エクスポートプロセスは、各テンプレートに対して以前に割り当てられたTemplate IDを再利用するか (MUST)、あるいは再利用する前にTemplate Withdrawal Messageを送信して以前に発行されたTemplate IDを撤回しなければなりません (MUST)。
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 Message Headerで指定されたObservation Domain IDのすべてのテンプレートを撤回するために、Template Withdrawal Messageを使用してもよい (MAY)。その形式を図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 Message Headerで指定されたObservation Domain IDのすべてのOptions Templateを撤回するために、Template Withdrawal Messageを使用してもよい (MAY)。その形式を図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アソシエーションが再起動した際、エクスポートプロセスはすべてのTemplate Recordを再送信しなければなりません (MUST)。
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.
収集プロセスは、エクスポートプロセスからの新しいアソシエーション要求を待ち受けるべきです (SHOULD)。エクスポートプロセスは、エクスポートに使用するいくつかのストリームを要求します。エクスポートプロセスは、SCTPアソシエーションあたり複数のストリームを要求およびサポートしてもよい (MAY)。
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アソシエーションをリセットしなければならず (MUST)、そのIPFIXメッセージを破棄しなければならず (MUST)、そのエラーをログに記録すべきです (SHOULD)。非ゼロのSetパディングは不正な形式の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.
Template SetおよびOptions Template Setは一度しか送信されません。収集プロセスは、後続のData Setで受信される対応するData Recordを解釈できるように、アソシエーションの期間中、Template Record情報を保存しなければなりません (MUST)。
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.
Template IDは、SCTPアソシエーションごとおよび観測ドメインごとに一意です。収集プロセスが、すでに受信されているが以前に撤回されていないテンプレートを受信した場合（すなわち、そのSCTPアソシエーション上で受信された同じTemplate IDを持つ同一エクスポータ観測ドメインからのTemplate Record）、収集プロセスはそのアソシエーションをシャットダウンしなければなりません (MUST)。
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アソシエーションが切断された場合、収集プロセスはそのアソシエーション経由で受信されたすべてのテンプレートを破棄しなければならず (MUST)、それらのテンプレートを使用するIPFIXメッセージのデコードを停止しなければなりません (MUST)。
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.
収集プロセスは通常、Data Recordを受信する前にエクスポートプロセスからTemplate Recordを受信します。その後、Data Recordはコレクタによってデコードされ保存されます。Data Recordを受信した時点でTemplate Recordを受信していない場合、収集プロセスはData Recordを短期間保存し、Template Recordを受信した後にデコードしてもよい (MAY)。収集プロセスは、Data Setと関連するTemplate Set（またはOptions Template Set）が同じIPFIXメッセージ内でエクスポートされると想定してはなりません (MUST NOT)。
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.
収集プロセスは、自身が理解できないすべての情報要素の情報要素識別子を記録しなければならず (MUST)、Flow Recordからその情報要素を破棄してもよい (MAY)。
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.
コレクタは、Data RecordおよびTemplate Record内のパディングを受け入れなければなりません (MUST)。パディングサイズは、Set LengthからSet Headerのサイズ（Set IDとSet Lengthの4オクテット）を差し引いた値を、Template Recordから推測されるRecordサイズで割った余り（modulo）です。
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 Data Recordの数とともに増加するSequence NumberフィールドをExportヘッダに持っています。コレクタは、Sequence Numberを追跡することによって順序の乱れ、欠落、または重複したIPFIXメッセージを検出できます。コレクタは、順序が乱れたIPFIXメッセージを追跡するためのロギングメカニズムを提供するべきです (SHOULD)。このような順序の乱れた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.
収集プロセスがTemplate Withdrawal Messageを受信した場合、収集プロセスは、その特定のSCTPアソシエーションおよび特定の観測ドメインに関連付けられた対応するTemplate Recordを削除しなければならず (MUST)、撤回されたテンプレートを使用するIPFIXメッセージのデコードを停止しなければなりません (MUST)。
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アソシエーション上で以前に受信したことのないTemplate Recordに対するTemplate Withdrawal Messageを受信した場合、収集プロセスはSCTPアソシエーションをリセットしなければならず (MUST)、そのIPFIXメッセージを破棄しなければならず (MUST)、不正な形式のIPFIXメッセージの場合と同様にそのエラーをログに記録すべきです (SHOULD)。
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.
同じTransport Session上で複数の観測ドメインからIPFIXメッセージを受信する収集プロセスは、観測ドメイン間でTemplate IDの一意性が保証されていないことを認識しなければなりません (MUST)。
The Collector MUST support the use of Templates containing multiple occurrences of the similar Information Elements.
コレクタは、同様の情報要素が複数回出現するテンプレートの使用をサポートしなければなりません (MUST)。
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 Message Headerの16ビットのLengthフィールドは、ヘッダを含めてIPFIXメッセージの長さを65535オクテットに制限します。収集プロセスは、最大65535オクテットまでのIPFIXメッセージ長を処理できなければなりません (MUST)。
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.
実装する必要があるもの（オペレーターが異なるベンダーから準拠した実装を相互に展開できるように）と、さまざまな運用環境で使用できるもの、または使用できるものを区別する必要があります。また、すべての実装が輻輳認識および輻輳回避モードで動作できることを確認する必要があります。
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を使用すべきです (SHOULD)。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を使用してもよい (MAY) が、エクスポータへのバックプレッシャーを制限する能力、およびストリーム指向ではなくメッセージ指向であることから、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は輻輳を認識するプロトコルではありませんが、使用してもよい (MAY)。ただし、エクスポータとコレクタ間のIPFIXトラフィックは、IPFIXトラフィックがプロビジョニングされているか、他の手段によって封じ込められている環境で実行されなければなりません (MUST)。
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による送信が一時的に不可能であることを検出した場合、送信が再び可能になるまで待機するか、またはレコードを破棄することを決定できます。後者の場合、破棄されたエクスポートデータの量を報告できるように、破棄されたエクスポートデータを記録しなければなりません (MUST)。
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メッセージを使用することは、それ自体ですべてのData Recordが配信されることを保証するものではありません。エクスポートプロセスから収集プロセスへのリンク上で輻輳が発生した場合、または大量の再送が必要になった場合、エクスポートプロセス上の送信キューがいっぱいになることがあります。エクスポートプロセスは、IPFIXメッセージを一時停止、エクスポート、または破棄してもよい (MAY)。Data Recordが破棄された場合、エクスポートに使用されるIPFIX Sequence Numberはデータの損失を反映しなければなりません (MUST)。
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アソシエーションを開始すべきです (SHOULD)。デフォルトでは、収集プロセスはSCTPポート4739で接続を待ち受けます。デフォルトでは、収集プロセスはSCTPポート4740でセキュアな接続を待ち受けます（「セキュリティの考慮事項」セクションを参照）。デフォルトでは、エクスポートプロセスはこれらのポートのいずれかに接続を試みます。エクスポートプロセスと収集プロセスの両方について、異なるSCTPポートを使用するように設定可能でなければなりません (MUST)。
The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
エクスポートプロセスは、収集プロセスに対して複数のアソシエーション（SCTP用語における接続の「バンドル」）を確立してもよい (MAY)。
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).
エクスポートプロセスは、異なる収集プロセス（同一ホスト上の異なる収集プロセスの場合を含む）に対する複数のアクティブなアソシエーションをサポートしてもよい (MAY)。
When an Exporting Process is shut down, it SHOULD shut down the SCTP association.
エクスポートプロセスがシャットダウンされる際、SCTPアソシエーションをシャットダウンすべきです (SHOULD)。
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メッセージの受信をこれ以上望まない場合、自身側のアソシエーションをシャットダウンすべきです (SHOULD)。収集プロセスは、エクスポートプロセスが自身側のアソシエーションを閉じるまで、IPFIXメッセージを受信および処理し続けるべきです (SHOULD)。
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment.
収集プロセスは、SCTPアソシエーションが異常終了したことを検出した場合、新しいアソシエーションの確立を待ち受け続けなければなりません (MUST)。
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アソシエーションが異常終了したことを検出した場合、アソシエーションの再確立を試みるべきです (SHOULD)。
Association timeouts SHOULD be configurable.
アソシエーションのタイムアウトは設定可能であるべきです (SHOULD)。
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ストリームを要求してもよい (MAY)。これらの各ストリームは、Data Set、Template Set、および/またはOptions Template Setを含む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エクスポートプロセスは、Data Setのみを含むIPFIXメッセージを送信するために部分信頼性を使用する場合、PR-SCTP [RFC3758] 仕様のセクション4に従った任意のPR-SCTPサービス定義を使用してもよい (MAY)。
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow.
ただし、エクスポートプロセスは、リソースまたはその他の制約が許す限り、そのようなIPFIXメッセージを再送対象としてマークすべきです (SHOULD)。
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の指数バックオフ機能を使用して再試行すべきです。エクスポータは、アソシエーション確立までの時間がエクスポータ上で設定可能な指定の閾値を超えた場合、アラームをログに記録してもよい (MAY)。
If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance.
エクスポートプロセスによって収集プロセスのフェイルオーバーがサポートされている場合、事前に第2のSCTPアソシエーションを開いておいてもよい (MAY)。
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を使用してもよい (MAY)。
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を使用してはなりません (MUST NOT)。
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 Sequence Numberの不連続性を確認することにより、IPFIX Data Recordの損失および順序入れ替わりを推測すべきです (SHOULD)。UDPの場合、IPFIX Sequence Numberには、このIPFIXメッセージの受信前にそのUDP Transport Sessionに対して送信されたIPFIX Data Recordの総数が modulo 2^32 で格納されています。コレクタは、Sequence Numberを追跡することにより、順序の乱れ、欠落、または重複したIPFIXメッセージを検出すべきです (SHOULD)。以前のコピーが失われた場合に備えて、トランスポートとしてUDPを使用してエクスポートプロセスから収集プロセスに送信されるテンプレートは、一定の間隔で再送信されなければなりません (MUST)。
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を超えないように設定されなければなりません (MUST)。パスMTUが不明な場合、512オクテットの最大パケットサイズが使用されるべきです (SHOULD)。
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ポートを使用するように設定可能でなければなりません (MUST)。
The Exporting Process MAY duplicate the IPFIX Message to the several Collecting Processes.
エクスポートプロセスは、複数の収集プロセスに対してIPFIXメッセージを複製してもよい (MAY)。
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がトランスポートプロトコルとしてUDPを使用する場合、Template SetおよびOptions Template Setは一定の間隔で再送信されなければなりません (MUST)。（Options）Template送信の頻度は設定可能でなければなりません (MUST)。（Options）Template送信の頻度のデフォルト値は10分です。エクスポートプロセスは、コレクタが最初のData Recordを受信する前にTemplate Recordを確実に保持できるように、その（Options）Template IDを使用するいかなるData Setよりも前にTemplate SetおよびOptions Template Setを送信すべきです (SHOULD)。
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メッセージにおいて、短縮された間隔で新しいテンプレート定義の複数のコピーを送信すべきです (SHOULD)。そのような場合、コレクタが最初のデータを受信する前に正しいテンプレート情報を確実に保持できるように、変更されたTemplate RecordおよびOptions Template Recordを、データを含めずに事前に送信すべきです (SHOULD)。
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.
Option Templateのスコープが別のテンプレートで定義されている場合、両方のテンプレートを同じIPFIXメッセージ内で送信すべきです (SHOULD)。例えば、Flow Key Option Template（セクション4.4を参照）がOption Template内で送信される場合、関連付けられたテンプレートは同じIPFIXメッセージ内で送信されるべきです (SHOULD)。
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.
Data Recordの解釈を変更する可能性のある設定変更（例えばサンプリングレートの変更）の後には、新しいTemplate IDを使用しなければならず (MUST)、その有効期間（セクション10.3.7を参照）が満了するまで古いTemplate IDを再利用してはなりません (MUST NOT)。
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の信頼性のない性質のためにこの方法は非効率的であるため、Template Withdrawal Messageを使用してはなりません (MUST NOT)。
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経由で受信した各テンプレート（またはTransport Session内で一意と見なされる識別子のその他の定義）に有効期間を関連付けなければなりません (MUST)。その有効期間内にエクスポートプロセスによって更新（refresh）されなかったテンプレート（および同様の定義）は、収集プロセスにおいて期限切れとなります。その有効期間が満了する前にテンプレート（またはその他の定義）が更新されない場合、収集プロセスはその定義および関連する現在および将来のすべてのData Recordを破棄しなければならず (MUST)、その場合にはアラームをログに記録しなければなりません (MUST)。収集プロセスは、期限切れのテンプレートに関連付けられたそれ以降のData Recordをデコードしてはなりません (MUST NOT)。テンプレートが以前に受信したTemplate Recordとは異なるTemplate Recordで更新された場合、収集プロセスは警告をログに記録し、以前に受信したTemplate Recordを新しいもので置き換えるべきです (SHOULD)。収集プロセスにおけるテンプレートの有効期間は、エクスポートプロセスで設定されたテンプレート更新タイムアウトの少なくとも3倍以上でなければなりません (MUST)。
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>.
Template IDは、UDPセッションごとおよび観測ドメインごとに一意です。いかなる時点においても、収集プロセスはすべての現在のTemplate RecordおよびOptions Template Recordについて、<IPFIX Device, Exporter source UDP port, Observation Domain ID, Template ID, Template Definition, Last Received> を維持すべきです (SHOULD)。
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.
収集プロセスは、Data Recordのデコードに必要な関連付けられたTemplate Record（またはその他の定義）がないData Recordを受け入れるべきです (SHOULD)。Data Recordを受信した時点でTemplate Record（またはCommon Propertiesなどの他の定義）を受信していない場合、収集プロセスはData Recordを短期間保存し、Template Record（または他の定義）を受信した後にそれらをデコードすべきです (SHOULD)。その短期間は、UDPセッション内で一意と見なされる識別子に関連付けられた定義の有効期間よりも短くなければなりません (MUST)。
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error.
収集プロセスは、不正な形式のIPFIXメッセージを受信した場合、そのIPFIXメッセージを破棄しなければならず (MUST)、そのエラーをログに記録すべきです (SHOULD)。
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メッセージを複数の収集プロセスに複製してもよいです (MAY)。
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ポートを使用するように設定可能でなければなりません (MUST)。
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).
エクスポートプロセスは、異なる収集プロセス（同一ホスト上の異なる収集プロセスの場合を含む）への複数のアクティブな接続をサポートしてもよいです (MAY)。
The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter.
エクスポータで設定可能な、接続確立にかかる時間が指定された閾値を超えた場合、エクスポータはアラームをログに記録してもよいです (MAY)。
When an Exporting Process is shut down, it SHOULD shut down the TCP connection.
エクスポートプロセスがシャットダウンされるときは、TCP接続をシャットダウンすべきです (SHOULD)。
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メッセージの受信を望まない場合、接続の自端を閉じるべきです (SHOULD)。収集プロセスは、エクスポートプロセスがその自端を閉じるまで、IPFIXメッセージの読み取りを継続すべきです (SHOULD)。
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接続が異常終了したことを検出した場合、新しい接続の待ち受けを継続しなければなりません (MUST)。
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接続が異常終了したことを検出した場合、接続の再確立を試みるべきです (SHOULD)。接続タイムアウトおよび再試行スケジュールは設定可能であるべきです (SHOULD)。デフォルト設定では、エクスポートプロセスは1分間に1回を超える頻度で接続の確立を試みてはなりません (MUST NOT)。
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接続を事前に開設してもよいです (MAY)。
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.
エクスポートプロセスが複数のObservation Domainからデータをエクスポートする場合、異なるObservation Domain間のヘッドオブラインブロッキングを最小限に抑えるよう、IPFIXメッセージ長を適切に選択するよう注意する必要があります。異なるObservation Domain間のヘッドオブラインを回避するために、複数のTCP接続を使用してもよいです (MAY)。
For each Template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that Template.
各Templateについて、エクスポートプロセスは、そのTemplateを参照するData Recordをエクスポートする前にTemplate Recordを送信しなければなりません (MUST)。
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.
Template IDは、TCP接続ごと、およびObservation Domainごとに一意です。エクスポートプロセスはTemplate Recordの再エクスポートを要求されないため、収集プロセスは接続の継続期間中、すべてのTemplate RecordおよびOptions Template Recordを記録しなければなりません (MUST)。
When the TCP connection restarts, the Exporting Process MUST resend all the Template Records.
TCP接続が再起動したとき、エクスポートプロセスはすべてのTemplate Recordを再送信しなければなりません (MUST)。
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接続が閉じられたとき、収集プロセスはその接続を介して受信したすべてのTemplateを破棄し、それらのTemplateを使用するIPFIXメッセージのデコードを停止しなければなりません (MUST)。
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.
もはや使用されないTemplateは削除すべきです (SHOULD)。Template IDを再利用する前に、そのTemplateを削除しなければなりません (MUST)。割り当てられたTemplateを削除するために、TCP接続を介したTemplate Withdrawal Messageの使用によってTemplateが取り消されます。
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メッセージを破棄しなければならず (MUST)、そのエラーをログに記録すべきです (SHOULD)。
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.
エクスポートプロセスにエクスポートすべきData Recordがあるものの送信バッファが満杯であり、ブロッキングを回避したい場合、一部のData Recordを破棄することを決定できます。その数量を後でエクスポートできるように、破棄されたData Recordを計上しなければなりません (MUST)。
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接続を待ち受けるべきです (SHOULD)。
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メッセージを破棄しなければならず (MUST)、そのエラーをログに記録すべきです (SHOULD)。ゼロ以外のSetパディングは不正な形式の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.
Template SetおよびOption Template Setは1回だけ送信されます。後続のData Setで受信される対応するData Recordを解釈できるように、収集プロセスは接続の継続期間中、Template Record情報を保存しなければなりません (MUST)。
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.
Template IDは、TCP接続ごと、およびObservation Domainごとに一意です。収集プロセスが、すでに受信されているが以前に取り消されていないTemplate（すなわち、TCP接続上で受信された同じTemplate IDを持つ同一エクスポータObservation DomainからのTemplate Record）を受信した場合、収集プロセスは接続をシャットダウンしなければなりません (MUST)。
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接続が閉じられたとき、収集プロセスはその接続を介して受信したすべてのTemplateを破棄し、それらのTemplateを使用するIPFIXメッセージのデコードを停止しなければなりません (MUST)。
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.
収集プロセスがTemplate Withdrawal Messageを受信した場合、収集プロセスは特定のTCP接続および特定のObservation Domainに関連付けられた対応するTemplate Recordを削除し、取り消されたTemplateを使用するIPFIXメッセージのデコードを停止しなければなりません (MUST)。
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接続上で以前に受信していないTemplate Recordに対するTemplate Withdrawal Messageを受信した場合、TCPアソシエーションをリセットし、そのIPFIXメッセージを破棄しなければならず (MUST)、不正な形式のIPFIXメッセージの場合と同様にエラーをログに記録すべきです (SHOULD)。
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メッセージ自体にも、ネットワークの構成に関する情報やエンドユーザのトラフィックおよびペイロードデータなど、攻撃者にとって価値のある情報が含まれる可能性があるため、その可視性を承認されたユーザに限定するよう注意を払う必要があります。エンドユーザのペイロード情報を含むInformation Elementがエクスポートされる場合、盗聴に対してその内容を保護する手段を使用して収集プロセスに送信すべきです (SHOULD)。適切なメカニズムには、直接のポイントツーポイント接続の使用、または暗号化メカニズムの使用のいずれかが含まれます。必要に応じて報告されたデータの匿名化を含め、この収集されたデータに対して十分な程度のセキュリティを提供することは、収集プロセスの責任です。
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メッセージが送信されることを保証しなければなりません (MUST)。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の両方で使用しなければなりません (MUST)。IPFIXエクスポートプロセスおよび収集プロセスの各々は、承認された証明書に対してピアのアイデンティティを検証しなければならず (MUST)、ピアの証明書がその完全修飾ドメイン名、またはSCTPの場合はそのエンドポイントのいずれかの完全修飾ドメイン名と一致することを検証しなければなりません (MUST)。
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拡張機能に優先順位が与えられます。
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.
SCTPは、SCTP状態枯渇サービス拒否攻撃を防ぐために設計されたクッキー交換メカニズムを義務付けています。同様に、TCPは状態枯渇を緩和するための「SYN cookie」メカニズムを提供しています。TCP接続を受け入れるすべての収集プロセスは、SYN cookieを使用すべきです (SHOULD)。DTLSもDTLSサーバの状態枯渇を防ぐためのクッキー交換を提供しています。
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およびDTLSの使用は明らかに偽の状態の作成を防ぐことができますが、それら自体が状態枯渇攻撃を受けやすいです。したがって、TLSおよびDTLSを保護するためにコレクタのレート制限を使用すべきです (SHOULD)（毎秒の新しい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メッセージが受け入れられるレートを制限し、保持される状態の量、特にTemplateを待機しているレコードを適応的に制限することによって緩和できます。これらのレートおよび状態の制限は収集プロセスによって提供されてもよく (MAY)、提供される場合、その制限はユーザが設定可能であるべきです (SHOULD)。
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メッセージを受け入れるもの）の使用は落胆します。
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 Sequence Numberを追跡することによって潜在的なIPFIXメッセージの挿入または損失状態を検出しなければならず (MUST)、順序外のメッセージを報告するためのロギングメカニズムを提供すべきです (SHOULD)。攻撃者は収集プロセスにおける順序外メッセージの処理を悪用できる可能性があるため、これらの状態の処理には注意を払う必要があることに注意してください。たとえば、後のSequence Numberの受信時に期待されるSequence Numberを単にリセットする収集プロセスは、後のSequence Numberの意図的な注入によって一時的に無力化される可能性があります。
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アドレスからの接続試行によるかを問わず、認証の失敗により失敗した接続試行をログに記録すべきです (SHOULD)。
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset.
IPFIXエクスポートプロセスおよび収集プロセスは、SCTPアソシエーションのリセットまたはTCP接続のリセットを検出してログに記録すべきです (SHOULD)。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[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. and 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., and 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., and 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., and 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. and 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. and 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., and 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月。
[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., and 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., and 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., and 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., and 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., and 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] Institute of Electrical and Electronics Engineers、「バイナリフローティングポイント算術の標準」、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. and E. Rescola、「Stream Control Transmission Protocolのデータグラムトランスポートレイヤーセキュリティ」、2007年11月、進行中の作業。
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への情報をお問い合わせください。