[要約] RFC 7012は、IPFIX（IP Flow Information Export）の情報モデルに関する規格であり、IPフロー情報のエクスポートに関する標準化を目的としています。
Internet Engineering Task Force (IETF) B. Claise, Ed.
Request for Comments: 7012 Cisco Systems, Inc.
Obsoletes: 5102 B. Trammell, Ed.
Category: Standards Track ETH Zurich
ISSN: 2070-1721 September 2013
Information Model for IP Flow Information Export (IPFIX)
IPフロー情報エクスポートの情報モデル（IPFIX）
Abstract
概要
This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.
このドキュメントでは、IPフロー情報エクスポート（IPFIX）プロトコルの情報モデルのデータタイプと管理ポリシーを定義します。この情報モデルは、IANA「IPFIX情報要素」レジストリとして維持されます。その初期コンテンツはRFC 5102によって定義されました。この情報モデルは、測定されたトラフィック情報とトラフィック監視ポイントに関連する情報をエンコードするためにIPFIXプロトコルによって使用されます。トラフィック測定プロセス、およびエクスポートプロセス。このモデルはIPFIXプロトコル用に開発されましたが、他のプロトコル、インターフェース、およびアプリケーションで簡単に使用できるようにオープンな方法で定義されています。このドキュメントはRFC 5102を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7012.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7012で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Changes since RFC 5102 .....................................4
1.2. IPFIX Documents Overview ...................................4
2. Properties of IPFIX Protocol Information Elements ...............5
2.1. Information Element Specification Template .................5
2.2. Scope of Information Elements ..............................7
2.3. Naming Conventions for Information Elements ................8
3. Type Space ......................................................9
3.1. Abstract Data Types ........................................9
3.1.1. unsigned8 ...........................................9
3.1.2. unsigned16 ..........................................9
3.1.3. unsigned32 ..........................................9
3.1.4. unsigned64 ..........................................9
3.1.5. signed8 ............................................10
3.1.6. signed16 ...........................................10
3.1.7. signed32 ...........................................10
3.1.8. signed64 ...........................................10
3.1.9. float32 ............................................10
3.1.10. float64 ...........................................10
3.1.11. boolean ...........................................10
3.1.12. macAddress ........................................10
3.1.13. octetArray ........................................10
3.1.14. string ............................................11
3.1.15. dateTimeSeconds ...................................11
3.1.16. dateTimeMilliseconds ..............................11
3.1.17. dateTimeMicroseconds ..............................11
3.1.18. dateTimeNanoseconds ...............................11
3.1.19. ipv4Address .......................................11
3.1.20. ipv6Address .......................................11
3.1.21. basicList .........................................11
3.1.22. subTemplateList ...................................11
3.1.23. subTemplateMultiList ..............................12
3.2. Data Type Semantics .......................................12
3.2.1. quantity ...........................................12
3.2.2. totalCounter .......................................12
3.2.3. deltaCounter .......................................12
3.2.4. identifier .........................................13
3.2.5. flags ..............................................13
4. Information Element Identifiers ................................13
5. Information Elements ...........................................14
6. Extending the Information Model ................................15
7. IANA Considerations ............................................15
7.1. IPFIX Information Elements ................................16
7.2. MPLS Label Type Identifier ................................17
7.3. XML Namespace and Schema ..................................17
7.4. Addition, Revision, and Deprecation .......................18
8. Security Considerations ........................................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
Contributors ......................................................23
The IP Flow Information Export (IPFIX) protocol serves as a means for transmitting information related to network traffic measurement. The IPFIX Protocol Specification [RFC7011] defines how Information Elements are transmitted and also specifies the encoding of a set of basic data types for these Information Elements. However, the list of Information Elements that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering Process and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in [RFC7011].
IPフロー情報エクスポート（IPFIX）プロトコルは、ネットワークトラフィック測定に関連する情報を送信する手段として機能します。 IPFIXプロトコル仕様[RFC7011]は、情報要素の送信方法を定義し、これらの情報要素の一連の基本データ型のエンコーディングも指定します。ただし、フロー属性（送信元IPアドレス、パケット数など）などのプロトコルで送信できる情報要素のリストと、メータリングプロセスとエクスポートプロセスに関する情報（パケット監視ポイント、サンプリングレート、フロータイムアウト）間隔など）は、[RFC7011]で指定されていません。
The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the current complete reference for IPFIX Information Elements. The initial values for this registry were provided by [RFC5102].
IANAの「IPFIX情報要素」レジストリ[IANA-IPFIX]は、IPFIX情報要素の現在の完全なリファレンスです。このレジストリの初期値は[RFC5102]によって提供されました。
This document complements the IPFIX Protocol Specification [RFC7011] by providing an overview of the IPFIX information model and specifying data types for it. IPFIX-specific terminology used in this document is defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.
このドキュメントは、IPFIXプロトコル仕様[RFC7011]を補足するもので、IPFIX情報モデルの概要を提供し、そのデータタイプを指定します。このドキュメントで使用されているIPFIX固有の用語は、[RFC7011]のセクション2で定義されています。 [RFC7011]と同様に、これらのIPFIX固有の用語は、このドキュメントで使用される場合、単語の最初の文字が大文字になります。
The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444], as the IPFIX information model does not specify relationships between Information Elements, nor does it specify a concrete encoding of Information Elements. For an encoding suitable for use with the IPFIX protocol, see [RFC7011]. Besides the encoding used by the IPFIX protocol, other encodings of IPFIX Information Elements can be applied, for example, XML-based encodings.
「情報モデル」という用語の使用は、[RFC3444]でのこの用語の定義と完全には一致していません。IPFIX情報モデルは情報要素間の関係を指定しておらず、情報要素の具体的なエンコーディングも指定していないためです。 IPFIXプロトコルでの使用に適したエンコーディングについては、[RFC7011]を参照してください。 IPFIXプロトコルで使用されるエンコードに加えて、IPFIX情報要素の他のエンコード（XMLベースのエンコードなど）を適用できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document obsoletes the Proposed Standard revision of the IPFIX information model specification [RFC5102]. The following changes have been made to this document with respect to the previous document:
このドキュメントは、IPFIX情報モデル仕様[RFC5102]の提案された標準リビジョンを廃止します。前のドキュメントと比較して、このドキュメントには次の変更が加えられています。
- At the time of this publication, technical and editorial errata reported for [RFC5102] have been reviewed and addressed as needed.
- この公開の時点で、[RFC5102]について報告された技術的および編集上の正誤表は、レビューされ、必要に応じて対処されています。
- All references to [RFC5101] have been updated to [RFC7011], reflecting changes to [RFC5101].
- [RFC5101]への変更を反映して、[RFC5101]へのすべての参照が[RFC7011]に更新されました。
- Information Element definitions have been removed, as the reference for these is now [IANA-IPFIX]; a historical note on categorizations of Information Elements as defined in [RFC5102] has been retained in Section 5.
- 情報要素の定義は削除されました。これらの参照が現在[IANA-IPFIX]になっているためです。 [RFC5102]で定義されている情報要素の分類に関する歴史的メモは、セクション5に保持されています。
- The process for modifying [IANA-IPFIX] has been improved and is now described in [RFC7013]; Section 6 has been updated accordingly, and a new Section 7.3 provides IANA considerations for this process.
- [IANA-IPFIX]を変更するプロセスが改善され、[RFC7013]で説明されています。セクション6はそれに応じて更新され、新しいセクション7.3はこのプロセスに関するIANAの考慮事項を提供します。
- Definitions of timestamp data types have been clarified.
- タイムスタンプデータ型の定義が明確になりました。
- Appendices A and B have been removed.
- 付録AとBは削除されました。
The IPFIX protocol provides network administrators with access to network flow information. The architecture for the export of measured flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX Protocol Specification [RFC7011] defines how IPFIX Data Records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIXプロトコルは、ネットワーク管理者にネットワークフロー情報へのアクセスを提供します。 IPFIXエクスポートプロセスから収集プロセスへの測定されたフロー情報のエクスポートのアーキテクチャは、[RFC3917]で定義されている要件に従って、[RFC5470]で定義されています。 IPFIXプロトコル仕様[RFC7011]は、IPFIXデータレコードとテンプレートが、IPFIXエクスポートプロセスからIPFIX収集プロセスへの多数のトランスポートプロトコルを介してどのように運ばれるかを定義します。
Four IPFIX optimizations/extensions are currently specified: a bandwidth-saving method for the IPFIX protocol [RFC5473], an efficient method for exporting bidirectional flows [RFC5103], a method for the definition and export of complex data structures [RFC6313], and the specification of the Protocol on IPFIX Mediators [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183].
現在、4つのIPFIX最適化/拡張が指定されています。IPFIXプロトコルの帯域幅を節約する方法[RFC5473]、双方向フローをエクスポートする効率的な方法[RFC5103]、複雑なデータ構造を定義およびエクスポートする方法[RFC6313]、およびIPFIXメディエーターフレームワーク[RFC6183]に基づくIPFIXメディエーターのプロトコル[IPFIX-MED-PROTO]の仕様。
IPFIX has a formal description of IPFIX Information Elements -- their names, data types, and additional semantic information -- as specified in this document. The export of the Information Element types is specified in [RFC5610].
このドキュメントで指定されているように、IPFIXには、IPFIX情報要素（その名前、データ型、および追加のセマンティック情報）の正式な説明があります。情報要素タイプのエクスポートは[RFC5610]で指定されています。
[RFC6728] specifies a data model for configuring and monitoring devices that are IPFIX and Packet Sampling (PSAMP) compliant using the Network Configuration Protocol (NETCONF), while [RFC6615] specifies MIB modules for monitoring.
[RFC6728]は、ネットワーク構成プロトコル（NETCONF）を使用してIPFIXおよびパケットサンプリング（PSAMP）に準拠するデバイスを構成および監視するためのデータモデルを指定し、[RFC6615]は、監視用のMIBモジュールを指定します。
In terms of development, [RFC5153] provides guidelines for the implementation and use of the IPFIX protocol, while [RFC5471] provides guidelines for testing.
開発に関しては、[RFC5153]はIPFIXプロトコルの実装と使用に関するガイドラインを提供し、[RFC5471]はテストのためのガイドラインを提供します。
Finally, [RFC5472] describes what types 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.
最後に、[RFC5472]は、IPFIXプロトコルを使用できるアプリケーションのタイプと、提供された情報をどのように使用できるかについて説明しています。さらに、IPFIXフレームワークが他のアーキテクチャーやフレームワークとどのように関連しているかを示しています。
Information in messages of the IPFIX protocol is modeled in terms of Information Elements of the IPFIX information model. The IPFIX Information Elements mentioned in Section 5 are specified in [IANA-IPFIX].
IPFIXプロトコルのメッセージ内の情報は、IPFIX情報モデルの情報要素の観点からモデル化されています。セクション5で言及されているIPFIX情報要素は、[IANA-IPFIX]で指定されています。
All Information Elements specified for the IPFIX protocol MUST have the following properties defined:
IPFIXプロトコルに指定されたすべての情報要素には、次のプロパティが定義されている必要があります。
name - A unique and meaningful name for the Information Element.
name-情報要素の一意で意味のある名前。
elementId - A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [RFC7011] and the definition of enterpriseId listed below), then it is globally unique, and the list of allowed values is administered by IANA. It is used for compact identification of an Information Element when encoding Templates in the protocol.
elementId-情報要素の数値識別子。この識別子がエンタープライズ識別子なしで使用される場合（[RFC7011]および以下にリストされているenterpriseIdの定義を参照）、グローバルに一意であり、許可される値のリストはIANAによって管理されます。プロトコルでテンプレートをエンコードするときに情報要素をコンパクトに識別するために使用されます。
description - The semantics of this Information Element. Describes how this Information Element is derived from the Flow or other information available to the observer. Information Elements of dataType string or octetArray that have length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their descriptions.
description-この情報要素のセマンティクス。この情報要素が、フローまたはオブザーバーが利用できるその他の情報からどのように導出されるかを説明します。長さの制約（固定長、最小長、最大長、あるいはその両方）を持つdataType文字列またはoctetArrayの情報要素は、これらの制約の説明に注意する必要があります。
dataType - One of the types listed in Section 3.1 of this document or registered in the IANA "IPFIX Information Element Data Types" subregistry. The type space for attributes is constrained to facilitate implementation. The existing type space encompasses most primitive types used in modern programming languages, as well as some derived types (such as ipv4Address) that are common to this domain.
dataType-このドキュメントのセクション3.1に記載されているタイプ、またはIANAの「IPFIX情報要素データタイプ」サブレジストリに登録されているタイプの1つ。属性の型空間は、実装を容易にするために制限されています。既存の型空間には、最新のプログラミング言語で使用されているほとんどのプリミティブ型と、このドメインに共通のいくつかの派生型（ipv4Addressなど）が含まれています。
status - The status of the specification of this Information Element. Allowed values are 'current' and 'deprecated'. All newly defined Information Elements have 'current' status. The process for moving Information Elements to the 'deprecated' status is defined in Section 5.3 of [RFC7013].
status-この情報要素の仕様のステータス。許可される値は「現在」および「非推奨」です。新しく定義されたすべての情報要素には、「現在」のステータスがあります。情報要素を「非推奨」ステータスに移行するプロセスは、[RFC7013]のセクション5.3で定義されています。
Enterprise-specific Information Elements MUST have the following property defined:
企業固有の情報要素には、次のプロパティが定義されている必要があります。
enterpriseId - Enterprises may wish to define Information Elements without registering them with IANA, for example, for enterprise-internal purposes. For such Information Elements, the Information Element identifier described above is not sufficient when the Information Element is used outside the enterprise. If specifications of enterprise-specific Information Elements are made public and/or if enterprise-specific identifiers are used by the IPFIX protocol outside the enterprise, then the enterprise-specific identifier MUST be made globally unique by combining it with an enterprise identifier. Valid values for the enterpriseId are defined by IANA as Structure of Management Information (SMI) network management private enterprise numbers, defined at [IANA-PEN].
enterpriseId-企業は、たとえば企業内部の目的で、IANAに登録せずに情報要素を定義したい場合があります。そのような情報要素について、情報要素が企業外で使用される場合、上記の情報要素識別子は十分ではありません。企業固有の情報要素の仕様が公開されている場合、および/または企業固有の識別子が企業外のIPFIXプロトコルで使用されている場合、企業固有の識別子は、企業識別子と組み合わせることにより、グローバルに一意にする必要があります。 enterpriseIdの有効な値は、IANAによって、[IANA-PEN]で定義されている管理情報の構造（SMI）ネットワーク管理のプライベートエンタープライズ番号として定義されています。
All Information Elements specified for the IPFIX protocol either in this document or by any future extension MAY have the following properties defined:
このドキュメントまたは将来の拡張によってIPFIXプロトコルに指定されたすべての情報要素には、次のプロパティが定義されている場合があります。
dataTypeSemantics - The integral types are qualified by additional semantic details. Valid values for the data type semantics are either specified in Section 3.2 of this document or will be specified in a future extension of the information model.
dataTypeSemantics-整数型は、追加のセマンティックの詳細によって修飾されます。データ型セマンティクスの有効な値は、このドキュメントのセクション3.2で指定されるか、情報モデルの将来の拡張で指定されます。
units - If the Information Element is a measure of some kind, the units identify what the measure is.
units-情報要素が何らかのメジャーである場合、ユニットはメジャーが何であるかを識別します。
range - Some Information Elements may only be able to take on a restricted set of values that can be expressed as a range (e.g., 0 through 511, inclusive). If this is the case, the valid inclusive range SHOULD be specified; values for this Information Element outside the range are invalid and MUST NOT be exported.
範囲-一部の情報要素は、範囲（0から511など）として表すことができる値の制限されたセットのみを取ることができる場合があります。この場合、有効な包含範囲を指定する必要があります（SHOULD）。この情報要素の範囲外の値は無効であり、エクスポートしてはなりません。
reference - Identifies additional specifications that more precisely define this item or provide additional context for its use.
参照-この項目をより正確に定義する、またはその使用のための追加のコンテキストを提供する追加の仕様を識別します。
The following two Information Element properties are defined to allow the management of an Information Elements registry with Information Element definitions that may be updated over time, per the process defined in Section 5.2 of [RFC7013]:
次の2つの情報要素プロパティは、[RFC7013]のセクション5.2で定義されているプロセスに従って、時間の経過とともに更新される情報要素の定義で情報要素レジストリを管理できるように定義されています。
revision - The revision number of an Information Element, starting at 0 for Information Elements at time of definition and incremented by one for each revision.
リビジョン-情報エレメントのリビジョン番号。定義時に情報エレメントの0から始まり、リビジョンごとに1ずつ増加します。
date - The date of the entry of this revision of the Information Element into the registry.
date-情報要素のこのリビジョンがレジストリに登録された日付。
A template for specifying Information Elements is given in Section 9.1 of [RFC7013].
情報要素を指定するためのテンプレートは、[RFC7013]のセクション9.1に記載されています。
By default, most Information Elements have a scope specified in their definitions. Within Data Records defined by Options Templates, the IPFIX protocol allows further limiting of the Information Element scope. The new scope is specified by one or more scope fields and defined as the combination of all specified scope values; see Section 3.4.2.1 on IPFIX scopes in [RFC7011].
デフォルトでは、ほとんどの情報要素の定義に範囲が指定されています。オプションテンプレートで定義されたデータレコード内で、IPFIXプロトコルにより、情報要素のスコープをさらに制限できます。新しいスコープは1つ以上のスコープフィールドで指定され、指定されたすべてのスコープ値の組み合わせとして定義されます。 [RFC7011]のIPFIXスコープに関するセクション3.4.2.1を参照してください。
The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions.
このドキュメントの情報要素の命名には、次の命名規則が使用されています。モデルの拡張で同じ規則を使用することをお勧めします。
o Names of Information Elements SHOULD be descriptive.
o 情報要素の名前は説明的である必要があります。
o Names of Information Elements MUST be unique within the "IPFIX Information Elements" registry [IANA-IPFIX]. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name.
o 情報要素の名前は、「IPFIX情報要素」レジストリ[IANA-IPFIX]内で一意である必要があります。企業固有の情報要素には、ベンダー名を前に付ける必要があります（SHOULD）。
o Names of Information Elements MUST start with lowercase letters.
o 情報要素の名前は小文字で始める必要があります。
o Composed names MUST use capital letters for the first letter of each component (except for the first one). All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as 'IPv4' and 'IPv6'. Examples are "sourceMacAddress" and "destinationIPv4Address".
o 構成された名前は、各コンポーネントの最初の文字に大文字を使用する必要があります（最初のものを除く）。他のすべての文字は、頭字語であっても小文字です。例外は、「IPv4」や「IPv6」のように、小文字と大文字が混在した頭字語に対して行われます。例は「sourceMacAddress」および「destinationIPv4Address」です。
o Middleboxes [RFC3234] may change Flow properties, such as the Differentiated Services Code Point (DSCP) value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to also report Flow properties after the modification performed by the middleboxes. An example is an Observation Point before a packet marker changing a packet's IPv4 Type of Service (TOS) field that is encoded in Information Element ipClassOfService. Then the value observed and reported by Information Element ipClassOfService is valid at the Observation Point but not after the packet passed the packet marker. For reporting the change value of the TOS field, the IPFIX information model uses Information Elements that have a name prefix "post", for example, "postIpClassOfService". Information Elements with prefix "post" report on Flow properties that are not necessarily observed at the Observation Point but that are obtained within the Flow's Observation Domain by other means considered to be sufficiently reliable, for example, by analyzing the packet marker's marking tables.
o Middleboxes [RFC3234]は、Differentiated Services Code Point（DSCP）値やソースIPアドレスなどのフロープロパティを変更する場合があります。 IPFIX観測ポイントが、フローのパケットを変更する可能性のある1つ以上のミドルボックスの前のフローのパスにある場合、ミドルボックスによって実行された変更後にフロープロパティも報告することが望ましい場合があります。例は、情報要素ipClassOfServiceでエンコードされたパケットのIPv4 Type of Service（TOS）フィールドをパケットマーカーが変更する前の監視ポイントです。次に、情報要素ipClassOfServiceによって監視および報告される値は、観測ポイントで有効ですが、パケットがパケットマーカーを通過した後は無効です。 TOSフィールドの変更値を報告するために、IPFIX情報モデルは、「postIpClassOfService」など、名前の接頭辞が「post」である情報要素を使用します。接頭辞が「post」の情報要素は、必ずしも観測ポイントで観測されるわけではないが、パケットマーカーのマーキングテーブルを分析するなど、十分に信頼できると見なされる他の手段によってフローの観測ドメイン内で取得されたフロープロパティについて報告します。
This section describes the abstract data types that can be used for the specification of IPFIX Information Elements in Section 4. Section 3.1 describes the set of abstract data types.
このセクションでは、セクション4のIPFIX情報要素の仕様に使用できる抽象データ型について説明します。セクション3.1では、抽象データ型のセットについて説明します。
Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described in Section 3.2, their data type semantics can be further specified, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags'.
抽象データ型unsigned8、unsigned16、unsigned32、unsigned64、signed8、signed16、signed32、signed64は整数データ型です。セクション3.2で説明したように、それらのデータ型のセマンティクスは、たとえば、「totalCounter」、「deltaCounter」、「identifier」、または「flags」によってさらに指定できます。
This section describes the set of valid abstract data types of the IPFIX information model, independent of encoding. Note that further abstract data types may be specified by future updates to this document. Changes to the associated IPFIX "Information Element Data Types" subregistry [IANA-IPFIX] specified in [RFC5610] require a Standards Action [RFC5226].
このセクションでは、エンコーディングに関係なく、IPFIX情報モデルの有効な抽象データ型のセットについて説明します。このドキュメントの将来の更新では、さらに抽象的なデータ型が指定される可能性があることに注意してください。 [RFC5610]で指定されている、関連するIPFIX "情報要素データタイプ"サブレジストリ[IANA-IPFIX]を変更するには、標準アクション[RFC5226]が必要です。
The current encodings of these data types for use with the IPFIX protocol are defined in [RFC7011]; encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document.
IPFIXプロトコルで使用するこれらのデータ型の現在のエンコーディングは、[RFC7011]で定義されています。他のプロトコルでIPFIX情報要素[IANA-IPFIX]を使用できるようにするエンコーディングは、このドキュメントを参照することにより、将来的に定義される可能性があります。
The type "unsigned8" represents a non-negative integer value in the range of 0 to 255.
タイプ「unsigned8」は、0から255の範囲の負でない整数値を表します。
The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535.
タイプ「unsigned16」は、0〜65535の範囲の非負の整数値を表します。
The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295.
タイプ「unsigned32」は、0から4294967295の範囲の負でない整数値を表します。
The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615.
タイプ「unsigned64」は、0から18446744073709551615の範囲の負でない整数値を表します。
The type "signed8" represents an integer value in the range of -128 to 127.
タイプ「signed8」は、-128から127の範囲の整数値を表します。
The type "signed16" represents an integer value in the range of -32768 to 32767.
タイプ「signed16」は、-32768〜32767の範囲の整数値を表します。
The type "signed32" represents an integer value in the range of -2147483648 to 2147483647.
タイプ「signed32」は、-2147483648〜2147483647の範囲の整数値を表します。
The type "signed64" represents an integer value in the range of -9223372036854775808 to 9223372036854775807.
タイプ「signed64」は、-9223372036854775808から9223372036854775807の範囲の整数値を表します。
The type "float32" corresponds to an IEEE single-precision 32-bit floating-point type as defined in [IEEE.754.2008].
「float32」型は、[IEEE.754.2008]で定義されているIEEE単精度32ビット浮動小数点型に対応します。
The type "float64" corresponds to an IEEE double-precision 64-bit floating-point type as defined in [IEEE.754.2008].
「float64」型は、[IEEE.754.2008]で定義されているIEEE倍精度64ビット浮動小数点型に対応しています。
The type "boolean" represents a binary value. The only allowed values are "true" and "false".
タイプ「ブール」はバイナリ値を表します。許可される値は「true」と「false」のみです。
The type "macAddress" represents a MAC-48 address as defined in [IEEE.802-3.2012].
タイプ「macAddress」は、[IEEE.802-3.2012]で定義されているMAC-48アドレスを表します。
The type "octetArray" represents a finite-length string of octets.
タイプ「octetArray」は、オクテットの有限長ストリングを表します。
The type "string" represents a finite-length string of valid characters from the Unicode coded character set [ISO.10646]. Unicode incorporates ASCII [RFC20] and the characters of many other international character sets.
タイプ「文字列」は、Unicodeコード化文字セット[ISO.10646]からの有効な文字の有限長文字列を表します。 Unicodeには、ASCII [RFC20]と他の多くの国際的な文字セットの文字が組み込まれています。
The type "dateTimeSeconds" represents a time value expressed with second-level precision.
タイプ「dateTimeSeconds」は、第2レベルの精度で表現された時刻値を表します。
The type "dateTimeMilliseconds" represents a time value expressed with millisecond-level precision.
タイプ「dateTimeMilliseconds」は、ミリ秒レベルの精度で表現された時間値を表します。
The type "dateTimeMicroseconds" represents a time value expressed with microsecond-level precision.
タイプ「dateTimeMicroseconds」は、マイクロ秒レベルの精度で表現された時間値を表します。
The type "dateTimeNanoseconds" represents a time value expressed with nanosecond-level precision.
タイプ「dateTimeNanoseconds」は、ナノ秒レベルの精度で表現された時間値を表します。
The type "ipv4Address" represents an IPv4 address.
タイプ「ipv4Address」はIPv4アドレスを表します。
The type "ipv6Address" represents an IPv6 address.
タイプ「ipv6Address」はIPv6アドレスを表します。
The type "basicList" supports structured data export as described in [RFC6313]; see Section 4.5.1 of that document for encoding details.
タイプ「basicList」は、[RFC6313]で説明されている構造化データのエクスポートをサポートしています。エンコーディングの詳細については、そのドキュメントのセクション4.5.1を参照してください。
The type "subTemplateList" supports structured data export as described in [RFC6313]; see Section 4.5.2 of that document for encoding details.
タイプ「subTemplateList」は、[RFC6313]で説明されているように、構造化データのエクスポートをサポートしています。エンコーディングの詳細については、そのドキュメントのセクション4.5.2を参照してください。
The type "subTemplateMultiList" supports structured data export as described in [RFC6313]; see Section 4.5.3 of that document for encoding details.
タイプ「subTemplateMultiList」は、[RFC6313]で説明されている構造化データのエクスポートをサポートしています。エンコーディングの詳細については、そのドキュメントのセクション4.5.3を参照してください。
This section describes the set of valid data type semantics of the IPFIX information model. A subregistry of data type semantics [IANA-IPFIX] is established in [RFC5610]; the restrictions on the use of semantics below are compatible with those specified in Section 3.10 of that document. These semantics apply only to numeric types, as noted in the description of each semantic below.
このセクションでは、IPFIX情報モデルの有効なデータ型セマンティクスのセットについて説明します。データ型セマンティクスのサブレジストリ[IANA-IPFIX]が[RFC5610]で確立されました。以下のセマンティクスの使用に関する制限は、そのドキュメントのセクション3.10で指定されているものと互換性があります。以下の各セマンティクスの説明に記載されているように、これらのセマンティクスは数値型にのみ適用されます。
Further data type semantics may be specified by future updates to this document. Changes to the associated "IPFIX Information Element Semantics" subregistry [IANA-IPFIX] require a Standards Action [RFC5226].
このドキュメントの将来の更新では、さらにデータ型のセマンティクスが指定される可能性があります。関連する「IPFIX Information Element Semantics」サブレジストリ[IANA-IPFIX]を変更するには、標準アクション[RFC5226]が必要です。
"quantity" is a numeric (integral or floating point) value representing a measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record. This is the default semantic type of all numeric data types.
「量」は、レコードに関連する測定値を表す数値（整数または浮動小数点）です。これは、「走行距離計」の読み取り値が特定のレコードの一部としてキャプチャされる、進行中の測定値を表すカウンターとは異なります。これは、すべての数値データ型のデフォルトのセマンティック型です。
"totalCounter" is an integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in the Simple Network Management Protocol (SNMP), such as Counter32 as defined in [RFC2578]. The only difference between total counters and counters used in SNMP is that the total counters have an initial value of 0. A total counter counts independently of the export of its value.
「totalCounter」は、カウンターの値を報告する整数値です。カウンターは符号なしで、型の制限に達した後にゼロに戻ります。たとえば、カウンターセマンティクスを持つunsigned64は、2 ** 64-1の値に達するまで増分を続けます。この時点で、次の増分はその値をゼロにラップし、ゼロからカウントし続けます。トータルカウンターのセマンティクスは、[RFC2578]で定義されているCounter32など、簡易ネットワーク管理プロトコル（SNMP）で使用されるカウンターのセマンティクスに似ています。合計カウンターとSNMPで使用されるカウンターの唯一の違いは、合計カウンターの初期値が0であることです。合計カウンターは、その値のエクスポートとは関係なくカウントされます。
"deltaCounter" is an integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32 as defined in [RFC2578]. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time it is exported and/or expires without export.
「deltaCounter」は、カウンターの値を報告する整数値です。カウンターは符号なしで、型の制限に達した後にゼロに戻ります。たとえば、カウンターセマンティクスを持つunsigned64は、2 ** 64-1の値に達するまで増分を続けます。この時点で、次の増分はその値をゼロにラップし、ゼロからカウントし続けます。デルタカウンタのセマンティクスは、[RFC2578]で定義されているCounter32など、SNMPで使用されるカウンタのセマンティクスに似ています。デルタカウンターとSNMPで使用されるカウンターの唯一の違いは、デルタカウンターの初期値が0であることです。デルタカウンターは、エクスポートされるか、エクスポートせずに期限切れになるたびに0にリセットされます。
"identifier" is an integral value that serves as an identifier. Specifically, mathematical operations on two identifiers (aside from the equality operation) are meaningless. For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless. Identifiers MUST be one of the signed or unsigned data types.
「識別子」は、識別子となる整数値です。具体的には、2つの識別子の算術演算（等価演算を除く）は無意味です。たとえば、自律システムID 1 *自律システムID 2は無意味です。識別子は、署名付きまたは署名なしのデータ型のいずれかである必要があります。
"flags" is an integral value that represents a set of bit fields. Logical operations are appropriate on such values, but other mathematical operations are not. Flags MUST always be of an unsigned data type.
「フラグ」は、ビットフィールドのセットを表す整数値です。そのような値には論理演算が適切ですが、他の数学演算は適切ではありません。フラグは常に符号なしデータ型でなければなりません。
All Information Elements defined in the IANA "IPFIX Information Elements" registry [IANA-IPFIX] have their identifiers assigned by IANA.
IANAの「IPFIX情報要素」レジストリ[IANA-IPFIX]で定義されているすべての情報要素には、IANAによって割り当てられた識別子があります。
The values of these identifiers are in the range of 1-32767. Within this range, Information Element identifier values in the sub-range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954] for historical reasons.
これらの識別子の値は、1〜32767の範囲です。この範囲内で、1〜127のサブ範囲の情報要素識別子の値は、歴史的な理由により、NetFlowバージョン9 [RFC3954]で使用されるフィールドタイプと互換性があります。
In general, IANA will add newly registered Information Elements to the registry, assigning the lowest available Information Element identifier in the range of 128-32767.
一般に、IANAは新しく登録された情報要素をレジストリに追加し、128〜32767の範囲で利用可能な最小の情報要素識別子を割り当てます。
Enterprise-specific Information Element identifiers have the same range of 1-32767, but they are coupled with an additional enterprise identifier. For enterprise-specific Information Elements, Information Element identifier 0 is also reserved. Enterprise-specific Information Element identifiers can be chosen by an enterprise arbitrarily within the range of 1-32767. The same identifier may be assigned by other enterprises for different purposes; these Information Elements are distinct because the Information Element identifier is coupled with an enterprise identifier.
企業固有の情報要素識別子は、1〜32767の同じ範囲ですが、追加の企業識別子と結合されます。企業固有の情報要素の場合、情報要素識別子0も予約されています。企業固有の情報要素識別子は、企業が1〜32767の範囲内で任意に選択できます。同じ識別子が他の企業によって異なる目的で割り当てられる場合があります。これらの情報要素は、情報要素識別子が企業識別子と結合されているため、区別されます。
Enterprise identifiers are to be registered as SMI network management private enterprise code numbers with IANA. The registry can be found at [IANA-PEN].
エンタープライズ識別子は、SMIネットワーク管理のプライベートエンタープライズコード番号としてIANAに登録されます。レジストリは[IANA-PEN]にあります。
[IANA-IPFIX] is now the normative reference for IPFIX Information Elements. When [RFC5102] was published, it defined, in its Section 5, the initial contents of that registry.
[IANA-IPFIX]は、IPFIX情報要素の規範的なリファレンスになりました。 [RFC5102]が公開されたとき、そのセクション5でそのレジストリの初期コンテンツを定義しました。
As a historical note, Information Elements (IEs) were organized into categories in [RFC5102] according to their semantics and their applicability; these categories were not carried forward into [IANA-IPFIX] as an organizing principle. The categories (with example IEs) were:
歴史的なメモとして、情報要素（IE）は、その意味論と適用性に従って[RFC5102]のカテゴリに編成されました。これらのカテゴリは、組織化の原則として[IANA-IPFIX]に持ち越されませんでした。カテゴリー（IEの例を含む）は次のとおりです。
1. Identifiers (e.g., ingressInterface) 2. Metering and Exporting Process Configuration (e.g., exporterIPv4Address) 3. Metering and Exporting Process Statistics (e.g., exportedOctetTotalCount) 4. IP Header Fields (e.g., sourceIPv4Address) 5. Transport Header Fields (e.g., sourceTransportPort) 6. Sub-IP Header Fields (e.g., sourceMacAddress) 7. Derived Packet Properties (e.g., bgpSourceAsNumber) 8. Min/Max Flow Properties (e.g., minimumIpTotalLength) 9. Flow Timestamps (e.g., flowStartTimeMilliseconds) 10. Per-Flow Counters (e.g., octetDeltaCount) 11. Miscellaneous Flow Properties (e.g., flowEndReason) 12. Padding (paddingOctets)
1. 識別子（たとえば、ingressInterface）2.計測およびエクスポートプロセス構成（たとえば、exporterIPv4Address）3.計測およびエクスポートプロセス統計（たとえば、exportedOctetTotalCount）4. IPヘッダーフィールド（たとえば、sourceIPv4Address）5.トランスポートヘッダーフィールド（たとえば、sourceTransportPort） 6.サブIPヘッダーフィールド（たとえば、sourceMacAddress）7.派生したパケットプロパティ（たとえば、bgpSourceAsNumber）8.最小/最大フロープロパティ（たとえば、minimumIpTotalLength）9.フロータイムスタンプ（たとえば、flowStartTimeMilliseconds）10.フローごとのカウンター（例：octetDeltaCount）11.その他のフロープロパティ（例：flowEndReason）12.パディング（paddingOctets）
Information Elements derived from fields of packets or from Packet Treatment can typically serve as Flow Keys used for mapping packets to Flows. These Information Elements were placed in categories 4-7 in the original categorization.
パケットのフィールドまたはパケット処理から派生した情報要素は、通常、パケットをフローにマッピングするために使用されるフローキーとして機能します。これらの情報要素は、元のカテゴリのカテゴリ4〜7に配置されていました。
Information Elements not serving as Flow Keys may have different values for each packet in a Flow. For Information Elements with values derived from fields of packets or from Packet Treatment, and for which the value may change from packet to packet within a single Flow, the exported value of an Information Element is by default determined by the first packet observed for the corresponding Flow; the description of the Information Element may, however, explicitly specify different semantics. This simple rule allows the writing of all Information Elements related to header fields once, when the first packet of the Flow is observed. For further observed packets of the same Flow, only Flow properties that depend on more than one packet need to be updated; these Information Elements were placed in categories 8-11 in the original categorization.
フローキーとして機能しない情報要素は、フロー内のパケットごとに異なる値を持つ場合があります。パケットのフィールドまたはパケット処理から導出された値を持つ情報要素の場合、単一のフロー内でパケットごとに値が変化する可能性があります。情報要素のエクスポートされた値は、デフォルトで、対応するフロー;ただし、情報要素の説明では、異なるセマンティクスを明示的に指定できます。この単純なルールにより、フローの最初のパケットが観察されたときに、ヘッダーフィールドに関連するすべての情報要素を一度に書き込むことができます。同じフローのさらに観測されたパケットについては、複数のパケットに依存するフロープロパティのみを更新する必要があります。これらの情報要素は、元のカテゴリのカテゴリ8〜11に配置されていました。
Information Elements with a name having the "post" prefix (e.g., postIpClassOfService) do not necessarily report properties that were actually observed at the Observation Point but may be retrieved by other means within the Observation Domain. These Information Elements can be used if there are middlebox functions within the Observation Domain changing Flow properties after packets passed the Observation Point; they may also be reported directly by the Observation Point if the Observation Point is situated where it can observe packets on both sides of the middlebox.
接頭辞が「post」の名前を持つ情報要素（postIpClassOfServiceなど）は、必ずしも観測ポイントで実際に観測されたプロパティを報告するわけではありませんが、観測ドメイン内の他の手段で取得できます。これらの情報要素は、パケットが観測ポイントを通過した後にフロープロパティを変更する観測ドメイン内のミドルボックス関数がある場合に使用できます。ミドルボックスの両側でパケットを監視できる場所に観測ポイントが配置されている場合は、観測ポイントから直接報告される場合もあります。
A key requirement for IPFIX is to allow for extension of the Information Model via the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX]. New Information Element definitions can be added to this registry subject to Expert Review [RFC5226], with additional process considerations as described in [RFC7013]; that document also provides guidelines for authors and reviewers of new Information Element definitions.
IPFIXの重要な要件は、「IPフロー情報エクスポート（IPFIX）エンティティ」レジストリ[IANA-IPFIX]を介して情報モデルを拡張できるようにすることです。 [RFC7013]で説明されているように、プロセスに関する追加の考慮事項とともに、新しい情報要素の定義をエキスパートレビュー[RFC5226]の対象となるこのレジストリに追加できます。このドキュメントは、新しい情報要素定義の作成者とレビュー担当者向けのガイドラインも提供します。
For new Information Elements, the type space defined in Section 3 can be used. If required, new abstract data types can be added to the "IPFIX Information Element Data Types" subregistry [IANA-IPFIX] as defined in [RFC5610]. New abstract data types and semantics are subject to Standards Action [RFC5226] and MUST be defined in IETF Standards Track documents updating this document.
新しい情報要素については、セクション3で定義されたタイプスペースを使用できます。必要に応じて、[RFC5610]で定義されているように、新しい抽象データ型を「IPFIX情報要素データ型」サブレジストリ[IANA-IPFIX]に追加できます。新しい抽象データ型とセマンティクスは、標準アクション[RFC5226]の対象であり、このドキュメントを更新するIETF標準トラックドキュメントで定義する必要があります。
Enterprises may wish to define Information Elements without registering them with IANA. IPFIX explicitly supports enterprise-specific Information Elements. Enterprise-specific Information Elements are described in Sections 2.1 and 4; guidelines for using them appear in [RFC7013].
企業は、IANAに登録せずに情報要素を定義したい場合があります。 IPFIXは、企業固有の情報要素を明示的にサポートしています。エンタープライズ固有の情報要素については、セクション2.1および4で説明しています。それらを使用するためのガイドラインは[RFC7013]に表示されます。
As this document obsoletes [RFC5102], IANA has updated the references in the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX], the "IPFIX MPLS label type" subregistry of that registry, the urn:ietf:params:xml:ns:ipfix-info XML namespace, and the urn:ietf:params:xml:schema:ipfix-info XML schema to refer to this document.
このドキュメントは廃止されたため[RFC5102]、IANAは「IP Flow Information Export（IPFIX）Entities」レジストリ[IANA-IPFIX]、そのレジストリの「IPFIX MPLS label type」サブレジストリ、urn：ietf：paramsの参照を更新しました：xml：ns：ipfix-info XML名前空間、およびこのドキュメントを参照するためのurn：ietf：params：xml：schema：ipfix-info XMLスキーマ。
However, [RFC5102] still provides a historical reference for the initial entries in the "IPFIX Information Elements" registry. Therefore, IANA has kept [RFC5102] as the requestor of those Information Elements in the "IPFIX Information Elements" registry that list [RFC5102] as their requestor and added the following explanatory note to the "IPFIX Information Elements" registry:
ただし、[RFC5102]は、「IPFIX情報要素」レジストリの初期エントリの履歴参照をまだ提供しています。したがって、IANAは[RFC5102]をリクエスタとしてリストする「IPFIX情報要素」レジストリの情報要素のリクエスタとして[RFC5102]を保持し、次の説明を「IPFIX情報要素」レジストリに追加しました。
"RFC 7012 has obsoleted RFC 5102; references to RFC 5102 in this registry remain as part of the historical record".
「RFC 7012はRFC 5102を廃止しました。このレジストリでのRFC 5102への参照は、歴史的な記録の一部として残ります。」
The Information Element Specification Template (Section 2.1) requires two new columns not present in [RFC5102]. IANA has created a new Revision column in the "IPFIX Information Elements" registry and set the Revision of existing Information Elements to 0. IANA has also created a new Date column in that registry and set the Date of all existing Information Elements to the publication date of this document.
情報要素仕様テンプレート（セクション2.1）には、[RFC5102]にはない2つの新しい列が必要です。 IANAは「IPFIX情報要素」レジストリに新しいリビジョン列を作成し、既存の情報要素のリビジョンを0に設定しました。IANAはそのレジストリに新しい日付列を作成し、既存のすべての情報要素の日付を公開日に設定しましたこのドキュメントの。
To identify Information Elements with identifiers 127 or below as NetFlow version 9 [RFC3954] compatible, IANA has set the Name of all existing Reserved Information Elements with identifier 127 or less to "Assigned for NetFlow v9 compatibility" and the Reference of those Information Elements to [RFC3954].
識別子127以下の情報要素をNetFlowバージョン9 [RFC3954]互換として識別するために、IANAは、識別子127以下の既存のすべての予約済み情報要素の名前を「割り当てられたNetFlow v9互換性」に設定し、それらの情報要素の参照を[RFC3954]。
As IANA now has change control of the schema used for the IANA "IPFIX Information Elements" registry [IANA-IPFIX], IANA has deprecated the previous XML schema for the description of Information Elements urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA].
IANAはIANAの「IPFIX情報要素」レジストリ[IANA-IPFIX]に使用されるスキーマの変更制御を持っているため、IANAは情報要素urn：ietf：params：xml：schema：ipfix-の説明のために以前のXMLスキーマを廃止しました。 info [IPFIX-XML-SCHEMA]。
To support the process described in Section 7.4, IANA has established a mailing list for communicating with the IE-DOCTORS, named ie-doctors@ietf.org.
セクション7.4で説明されているプロセスをサポートするために、IANAはie-doctors@ietf.orgという名前のIE-DOCTORSと通信するためのメーリングリストを確立しています。
The remaining subsections of this section contain no actions for IANA.
このセクションの残りのサブセクションには、IANAに対するアクションは含まれていません。
This document refers to Information Elements, for which the Internet Assigned Numbers Authority (IANA) has created the IPFIX "Information Elements" registry [IANA-IPFIX]. The columns of this registry must, at minimum, be able to store the information defined in the template detailed in Section 2.1; it may contain other information as necessary for the management of the registry.
このドキュメントは、Internet Assigned Numbers Authority（IANA）がIPFIXの「情報要素」レジストリ[IANA-IPFIX]を作成した情報要素に言及しています。このレジストリの列は、少なくとも、セクション2.1で説明されているテンプレートで定義された情報を格納できる必要があります。レジストリの管理に必要な他の情報が含まれている場合があります。
The process for making additions or other changes to the "IPFIX Information Elements" registry is given in Section 7.4.
「IPFIX情報要素」レジストリに追加またはその他の変更を加えるプロセスについては、セクション7.4を参照してください。
Information Element #46, named mplsTopLabelType, carries MPLS label types. Values for 5 different types have initially been defined. For ensuring the extensibility of this information, IANA has created a new subregistry for MPLS label types and filled it with the initial list from the description Information Element #46, mplsTopLabelType.
mplsTopLabelTypeという名前の情報要素＃46には、MPLSラベルタイプが含まれています。 5つの異なるタイプの値が最初に定義されています。この情報の拡張性を確保するために、IANAはMPLSラベルタイプの新しいサブレジストリを作成し、情報要素＃46、mplsTopLabelTypeの説明からの初期リストを記入しました。
New assignments for MPLS label types are administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must double-check the label type definitions with already-defined label types for completeness, accuracy, and redundancy. The specification of new MPLS label types MUST be published using a well-established and persistent publication medium.
MPLSラベルタイプの新しい割り当ては、エキスパートレビュー[RFC5226]を通じてIANAによって管理されます。つまり、IETF Area Directorによって指定されたエキスパートグループの1人によるレビューです。専門家グループは、完全性、正確性、および冗長性について、すでに定義されているラベルタイプを使用してラベルタイプ定義を再確認する必要があります。新しいMPLSラベルタイプの仕様は、確立された永続的な発行媒体を使用して発行する必要があります。
The prior version of this document [RFC5102] specified an XML schema for IPFIX Information Element definitions [IPFIX-XML-SCHEMA] that was used in the generation of the document text itself. When the IANA "IPFIX Information Elements" registry [IANA-IPFIX] was created, change control on the registry and the schema used to validate it passed to IANA.
このドキュメントの以前のバージョン[RFC5102]では、ドキュメントテキスト自体の生成に使用されたIPFIX情報要素定義[IPFIX-XML-SCHEMA]のXMLスキーマが指定されていました。 IANAの「IPFIX情報要素」レジストリ[IANA-IPFIX]が作成されたときに、レジストリの制御と、IANAに渡された検証に使用されるスキーマを変更します。
The use of a machine-readable syntax for the registry enables the creation of IPFIX tools that can automatically adapt to extensions to the information model. It should be noted that the use of XML in Exporters, Collectors, or other tools is not mandatory for the deployment of IPFIX. In particular, Exporting Processes do not produce or consume XML as part of their operation. IPFIX Collectors MAY take advantage of the machine-readability of the information model versus hard-coding their behavior or inventing proprietary means for accommodating extensions. However, in order to avoid unnecessary load on the IANA infrastructure serving the registry, Collectors SHOULD NOT poll the IANA registry [IANA-IPFIX] directly at runtime.
レジストリに機械可読構文を使用すると、情報モデルの拡張機能に自動的に適応できるIPFIXツールを作成できます。エクスポーター、コレクター、またはその他のツールでのXMLの使用は、IPFIXの展開に必須ではないことに注意してください。特に、エクスポートプロセスは、操作の一部としてXMLを生成または消費しません。 IPFIXコレクターは、情報モデルの機械可読性を利用して、動作をハードコーディングしたり、拡張機能に対応するための独自の手段を考案したりできます。ただし、レジストリを提供するIANAインフラストラクチャへの不要な負荷を回避するために、コレクターは実行時にIANAレジストリ[IANA-IPFIX]を直接ポーリングしてはなりません（SHOULD NOT）。
The reference to the current schema is embedded in the registry [IANA-IPFIX]; this schema may change from time to time as necessary to support the maintenance of the registry. As such, the schema urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] specified in [RFC5102] has been deprecated.
現在のスキーマへの参照は、レジストリ[IANA-IPFIX]に埋め込まれています。このスキーマは、レジストリのメンテナンスをサポートするために必要に応じて時々変更される場合があります。そのため、[RFC5102]で指定されたスキーマurn：ietf：params：xml：schema：ipfix-info [IPFIX-XML-SCHEMA]は廃止されました。
New assignments for the "IPFIX Information Elements" registry are administered by IANA through Expert Review [RFC5226]. These experts are referred to as IE-DOCTORS and are appointed by the IESG. The process they follow is defined in [RFC7013].
「IPFIX情報要素」レジストリの新しい割り当ては、IANAによってExpert Review [RFC5226]を通じて管理されます。これらの専門家はIE-DOCTORSと呼ばれ、IESGによって任命されます。彼らが従うプロセスは[RFC7013]で定義されています。
Information Element identifiers in the range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954] for historical reasons and must not be assigned unless the Information Element is compatible with the NetFlow version 9 protocol, as determined by one of the IE-DOCTORS designated by the IESG as a NetFlow version 9 expert.
1〜127の範囲の情報要素識別子は、歴史的な理由からNetFlowバージョン9 [RFC3954]で使用されるフィールドタイプと互換性があり、情報要素がNetFlowバージョン9プロトコルと互換性がない限り割り当てないでください。 IESGによってNetFlowバージョン9エキスパートとして指定されたIE-DOCTORS。
Future assignments added to the "IPFIX Information Elements" registry that require subregistries for enumerated values (e.g., Section 7.2) must have those subregistries added simultaneously with the new assignment; additions to these subregistries must be subject to Expert Review [RFC5226]. Unless specified at assignment time, the experts for the subregistry will be the same as for the "IPFIX Information Elements" registry as a whole.
列挙値にサブレジストリを必要とする「IPFIX情報要素」レジストリに追加される将来の割り当て（たとえば、セクション7.2）では、それらのサブレジストリを新しい割り当てと同時に追加する必要があります。これらのサブレジストリへの追加は、専門家によるレビューの対象となる必要があります[RFC5226]。割り当て時に指定されていない限り、サブレジストリのエキスパートは「IPFIX情報要素」レジストリ全体と同じです。
When IANA receives a request to add, revise, or deprecate an Information Element in the "IPFIX Information Elements" registry, it forwards the request to the IE-DOCTORS for review.
IANAは、「IPFIX情報要素」レジストリの情報要素を追加、変更、または廃止する要求を受け取ると、その要求をレビューのためにIE-DOCTORSに転送します。
When IANA receives an approval for a request to add an Information Element definition from the IE-DOCTORS, it adds that Information Element to the registry. The approved request may include changes made by the requestor and/or reviewers as compared to the original request.
IANAは、IE-DOCTORSから情報要素定義を追加する要求の承認を受け取ると、その情報要素をレジストリに追加します。承認された要求には、元の要求と比較して、要求者および/またはレビューアによって行われた変更が含まれる場合があります。
When IANA receives an approval for a request to revise an Information Element definition from the IE-DOCTORS, it changes that Information Element's definition in the registry and updates the Revision and Date columns as appropriate. The approved request may include changes from the original request. If the original Information Element was added to the registry with IETF consensus (i.e., was defined by an RFC), the revision will require IETF consensus as well.
IANAは、IE-DOCTORSから情報要素定義を改訂する要求の承認を受け取ると、レジストリ内のその情報要素の定義を変更し、必要に応じて改訂列と日付列を更新します。承認されたリクエストには、元のリクエストからの変更が含まれる場合があります。元の情報要素がIETFコンセンサスを使用してレジストリに追加された場合（つまり、RFCによって定義された場合）、改訂にはIETFコンセンサスも必要になります。
When IANA receives an approval for a request to deprecate an Information Element definition from the IE-DOCTORS, it changes that Information Element's definition in the registry and updates the Revision and Date columns as appropriate. The approved request may include changes from the original request. If the original Information Element was added to the registry with IETF consensus (i.e., was defined by an RFC), the deprecation will require IETF consensus as well.
IANAは、IE-DOCTORSから情報要素の定義を廃止する要求の承認を受け取ると、レジストリ内のその情報要素の定義を変更し、必要に応じてRevision列とDate列を更新します。承認されたリクエストには、元のリクエストからの変更が含まれる場合があります。元の情報要素がIETFコンセンサスを使用してレジストリに追加された場合（つまり、RFCによって定義された場合）、廃止にはIETFコンセンサスも必要になります。
The IPFIX information model itself does not directly introduce security issues. Rather, it defines a set of attributes that may, for privacy or business issues, be considered sensitive information.
IPFIX情報モデル自体は、直接セキュリティ問題を引き起こしません。むしろ、プライバシーやビジネスの問題では機密情報と見なされる可能性のある一連の属性を定義しています。
For example, exporting values of header fields may make attacks possible for the receiver of this information; this would otherwise only be possible for direct observers of the reported Flows along the data path.
たとえば、ヘッダーフィールドの値をエクスポートすると、この情報の受信者が攻撃される可能性があります。そうでなければ、これはデータパスに沿って報告されたフローの直接オブザーバーのみが可能です。
The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. These protocols are defined in separate documents, specifically the IPFIX protocol document [RFC7011].
したがって、ここで説明する情報を交換するために使用される基になるプロトコルは、エクスポートされた情報の完全性と機密性を保証するために適切な手順を適用する必要があります。これらのプロトコルは、個別のドキュメント、特にIPFIXプロトコルドキュメント[RFC7011]で定義されています。
This document is substantially based on [RFC5102]. The editors thank the authors of that document; those authors are listed below as contributors. Special thanks go to Paul Aitken for the detailed review. Finally, the authors thank the IPFIX WG chairs: Nevil Brownlee and Juergen Quittek.
この文書は実質的に[RFC5102]に基づいています。編集者はそのドキュメントの作者に感謝します。それらの作者は貢献者として以下にリストされています。詳細なレビューについては、Paul Aitkenに特に感謝します。最後に、著者はIPFIX WGの議長であるNevil BrownleeとJuergen Quittekに感謝します。
[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月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 2013年9月。
[RFC7013] Trammell, B., and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013.
[RFC7013] Trammell、B。、およびB. Claise、「作成者とIPフロー情報エクスポート（IPFIX）情報要素のレビューアーのためのガイドライン」、BCP 184、RFC 7013、2013年9月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix/>.
[IANA-IPFIX] IANA、「IP Flow Information Export（IPFIX）Entities」、<http://www.iana.org/assignments/ipfix/>。
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[IEEE.754.2008] Institute of Electrical and Electronics Engineers、「IEEE Standard for Floating-Point Arithmetic」、IEEE Standard 754、2008年8月。
[IEEE.802-3.2012] Institute of Electrical and Electronics Engineers, "IEEE Standard for Ethernet", IEEE Standard 802.3, 2012.
[IEEE.802-3.2012] Institute of Electrical and Electronics Engineers、「IEEE Standard for Ethernet」、IEEE Standard 802.3、2012。
[IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators", Work in Progress, July 2013.
[IPFIX-MED-PROTO] Claise、B.、Kobayashi、A。、およびB. Trammell、「IPFIX MediatorsでのIPフロー情報エクスポート（IPFIX）プロトコルの動作」、2013年7月、進行中。
[IPFIX-XML-SCHEMA] IANA, "IETF XML Registry", <http://www.iana.org/assignments/xml-registry/>.
[IPFIX-XML-SCHEMA] IANA、「IETF XML Registry」、<http://www.iana.org/assignments/xml-registry/>。
[ISO.10646] International Organization for Standardization, "Information technology - Universal Coded Character Set (UCS)", ISO/IEC 10646:2012, November 2012.
[ISO.10646]国際標準化機構、「情報技術-ユニバーサルコード化文字セット（UCS）」、ISO / IEC 10646：2012、2012年11月。
[IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[IANA-PEN] IANA、「Private Enterprise Numbers」、<http://www.iana.org/assignments/enterprise-numbers>。
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969.
[RFC20] Cerf、V。、「ネットワークインターチェンジのASCII形式」、RFC 20、1969年10月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Structure of Management Information Version 2（SMIv2）"、STD 58、RFC 2578、April 1999。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、RFC 3234、2002年2月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「On the Difference between Information Models and Data Models」、RFC 3444、2003年1月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IPフロー情報エクスポート（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B。、編、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、編、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103] Trammell、B。およびE. Boschi、「IP Flow Information Export（IPFIX）を使用した双方向フローエクスポート」、RFC 5103、2008年1月。
[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008.
[RFC5153] Boschi、E.、Mark、L.、Quittek、J.、Stiemerling、M。、およびP. Aitken、「IPフロー情報エクスポート（IPFIX）実装ガイドライン」、RFC 5153、2008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、2009年3月。
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009.
[RFC5471] Schmoll、C.、Aitken、P。、およびB. Claise、「IPフロー情報エクスポート（IPFIX）テストのガイドライン」、RFC 5471、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、RFC 5472、2009年3月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473] Boschi、E.、Mark、L。、およびB. Claise、「Reduce Redundancy in IP Flow Information Export（IPFIX）and Packet Sampling（PSAMP）Reports」、RFC 5473、2009年3月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610] Boschi、E.、Trammell、B.、Mark、L。、およびT. Zseby、「Exporting Type Information for IP Flow Information Export（IPFIX）Information Elements」、RFC 5610、2009年7月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]小林明朗、クレイズB.、ムエンツG.、石橋健二、「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」、RFC 6183、2011年4月。
[RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 2012.
[RFC6615] Dietz、T.、Ed。、Kobayashi、A.、Claise、B.、およびG. Muenz、「Definions of Managed Objects for IP Flow Information Export」、RFC 6615、2012年6月。
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, October 2012.
[RFC6728] Muenz、G.、Claise、B。、およびP. Aitken、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）プロトコルの構成データモデル」、RFC 6728、2012年10月。
Contributors
貢献者
Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Juergen Quittek NEC Kurfuersten-Anlage 36ハイデルベルク69115ドイツ
Phone: +49 6221 90511-15
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/
Stewart Bryant Cisco Systems, Inc. 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA United Kingdom
Stewart Bryant Cisco Systems、Inc. 10 New Square、Bedfont Lakes Feltham、Middlesex TW18 8HAイギリス
EMail: stbryant@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
Paul Aitken Cisco Systems、Inc. 96 Commercial QuayエディンバラEH6 6LXスコットランド
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US
Jeff Meyer PayPal 2211 N. First St. San Jose、CA 95131-2021 US
Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI: http://www.paypal.com
Authors' Addresses
Benoit Claise (editor) Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise（編集者）Cisco Systems、Inc. De Kleetlaan 6a b1 1831 Diegemベルギー
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Brian Trammell (editor) Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメル（編集者）スイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch