[要約] RFC 7373は、IPFIXの抽象データ型のテキスト表現に関するものであり、IPフロー情報のエクスポートに使用されます。このRFCの目的は、IPFIXデータのテキスト表現を定義し、データの相互運用性を向上させることです。
Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 7373 ETH Zurich
Category: Standards Track September 2014
ISSN: 2070-1721
Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types
IPフロー情報エクスポート（IPFIX）抽象データ型のテキスト表現
Abstract
概要
This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.
このドキュメントでは、IPフロー情報エクスポート（IPFIX）抽象データ型（ADT）のUTF-8表現を定義して、テキストエンコーディングに基づくプロトコルでIPFIX情報要素の相互運用可能な使用をサポートします。
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/rfc7373.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7373で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Information Elements . . . . . . . . . . . . . . 3
4. Data Type Encodings . . . . . . . . . . . . . . . . . . . . . 3
4.1. octetArray . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. unsigned8, unsigned16, unsigned32, and unsigned64 . . . . 4
4.3. signed8, signed16, signed32, and signed64 . . . . . . . . 5
4.4. float32 and float64 . . . . . . . . . . . . . . . . . . . 6
4.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. macAddress . . . . . . . . . . . . . . . . . . . . . . . 7
4.7. string . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.8. The dateTime ADTs . . . . . . . . . . . . . . . . . . . . 8
4.9. ipv4Address . . . . . . . . . . . . . . . . . . . . . . . 8
4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . . 9
4.11. basicList, subTemplateList, and subTemplateMultiList . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . .
The IP Flow Information Export (IPFIX) Information Model [RFC7012] provides a set of abstract data types (ADTs) for the IANA "IPFIX Information Elements" registry [IANA-IPFIX], which contains a rich set of Information Elements for description of information about network entities and network traffic data, and abstract data types for these Information Elements. The IPFIX Protocol Specification [RFC7011], in turn, defines a big-endian binary encoding for these abstract data types suitable for use with the IPFIX protocol.
IPフロー情報エクスポート（IPFIX）情報モデル[RFC7012]は、IANAの「IPFIX情報要素」レジストリ[IANA-IPFIX]に一連の抽象データタイプ（ADT）を提供します。これには、情報の説明用の豊富な情報要素のセットが含まれていますネットワークエンティティとネットワークトラフィックデータ、およびこれらの情報要素の抽象データ型について。次に、IPFIXプロトコル仕様[RFC7011]は、IPFIXプロトコルでの使用に適したこれらの抽象データ型のビッグエンディアンバイナリエンコーディングを定義しています。
However, present and future operations and management protocols and applications may use textual encodings, and generic framing and structure, as in JSON [RFC7159] or XML. A definition of canonical textual encodings for the IPFIX abstract data types would allow this set of Information Elements to be used for such applications and for these applications to interoperate with IPFIX applications at the Information Element definition level.
ただし、現在および将来の運用および管理プロトコルとアプリケーションは、JSON [RFC7159]またはXMLのように、テキストエンコーディング、および一般的なフレーム構成と構造を使用する可能性があります。 IPFIX抽象データ型の標準テキストエンコーディングの定義により、この情報要素のセットをそのようなアプリケーションに使用し、これらのアプリケーションが情報要素定義レベルでIPFIXアプリケーションと相互運用できるようになります。
Note that templating or other mechanisms used for data description for such applications and protocols are application specific and, therefore, out of scope for this document: only Information Element identification and value representation are defined here.
このようなアプリケーションやプロトコルのデータ記述に使用されるテンプレートやその他のメカニズムはアプリケーション固有であるため、このドキュメントの範囲外であることに注意してください。ここでは情報要素の識別と値の表現のみが定義されています。
In most cases where a textual representation will be used, an explicit tradeoff is made for human readability or manipulability over compactness; this assumption is used in defining standard representations of IPFIX ADTs.
テキスト表現が使用されるほとんどの場合、コンパクトさよりも人間の可読性または操作性の明示的なトレードオフが行われます。この仮定は、IPFIX ADTの標準表現を定義する際に使用されます。
Capitalized terms defined in the IPFIX Protocol Specification [RFC7011] and the IPFIX Information Model [RFC7012] are used in this document as defined in those documents. 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]. In addition, this document defines the following terminology for its own use:
このドキュメントでは、IPFIXプロトコル仕様[RFC7011]およびIPFIX情報モデル[RFC7012]で定義されている大文字の用語が、これらのドキュメントで定義されているとおりに使用されています。このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。さらに、このドキュメントでは、独自に使用するために次の用語を定義しています。
Enclosing Context A textual representation of Information Element values is applied to use the IPFIX Information Model within some existing textual format (e.g., XML [W3C-XML] and JSON [RFC7159]). This outer format is referred to as the Enclosing Context within this document. Enclosing Contexts define escaping and quoting rules for represented values.
囲みコンテキスト情報要素の値のテキスト表現は、既存のテキスト形式（XML [W3C-XML]やJSON [RFC7159]など）内でIPFIX情報モデルを使用するために適用されます。この外部形式は、このドキュメントでは「囲みコンテキスト」と呼ばれます。囲みコンテキストは、表現された値のエスケープと引用のルールを定義します。
The "IPFIX Information Elements" registry [IANA-IPFIX] defines a set of Information Elements numbered by Information Element identifiers and named for human readability. These Information Element identifiers are meant for use with the IPFIX protocol and have little meaning when applying the "IPFIX Information Elements" registry to textual representations.
「IPFIX情報要素」レジストリ[IANA-IPFIX]は、情報要素識別子によって番号が付けられ、人間が読みやすいように名前が付けられた一連の情報要素を定義します。これらの情報要素識別子は、IPFIXプロトコルで使用するためのものであり、「IPFIX情報要素」レジストリをテキスト表現に適用する場合はほとんど意味がありません。
Instead, applications using textual representations of Information Elements use Information Element names to identify them; see Appendix A for examples illustrating this principle.
代わりに、情報要素のテキスト表現を使用するアプリケーションは、情報要素名を使用してそれらを識別します。この原則を示す例については、付録Aを参照してください。
Each subsection of this section defines a textual encoding for the abstract data types defined in [RFC7012]. This section uses ABNF, including the Core Rules in Appendix B of [RFC5234], to describe the format of textual representations of IPFIX abstract data types.
このセクションの各サブセクションは、[RFC7012]で定義されている抽象データ型のテキストエンコーディングを定義します。このセクションでは、[RFC5234]の付録Bのコアルールを含むABNFを使用して、IPFIX抽象データ型のテキスト表現の形式について説明します。
If future documents update [RFC7012] to add new abstract data types to the IPFIX Information Model, and those abstract data types are generally useful, this document will also need to be updated in order to define textual encodings for those abstract data types.
今後のドキュメントが[RFC7012]を更新して新しい抽象データタイプをIPFIX情報モデルに追加し、それらの抽象データタイプが一般的に有用である場合、これらの抽象データタイプのテキストエンコーディングを定義するために、このドキュメントも更新する必要があります。
If the Enclosing Context defines a representation for binary objects, that representation SHOULD be used.
囲みコンテキストがバイナリオブジェクトの表現を定義する場合、その表現を使用する必要があります（SHOULD）。
Otherwise, since the goal of textual representation of Information Elements is human readability over compactness, the values of Information Elements of the octetArray data type are represented as a string of pairs of hexadecimal digits, one pair per byte, in the order the bytes would appear on the wire were the octetArray encoded directly in IPFIX per [RFC7011]. Whitespace may occur between any pair of digits to assist in human readability of the string but is not necessary. In ABNF:
それ以外の場合、情報要素のテキスト表現の目的はコンパクトさよりも人間が読みやすいことであるため、octetArrayデータ型の情報要素の値は、バイトが表示される順序で、16進数字のペアの文字列として、バイトごとに1つのペアとして表されます。回線上には、[RFC7011]に従ってIPFIXに直接エンコードされたoctetArrayがありました。文字列を人間が読みやすくするために、数字のペアの間に空白が発生する場合がありますが、必須ではありません。 ABNFの場合：
hex-octet = 2HEXDIG
octetarray = hex-octet *([WSP] hex-octet)
octetarray = hex-octet *（[WSP] hex-octet）
If the Enclosing Context defines a representation for unsigned integers, that representation SHOULD be used.
包含コンテキストが符号なし整数の表現を定義する場合、その表現を使用する必要があります（SHOULD）。
In the special case where the unsigned Information Element has identifier semantics and refers to a set of codepoints either in an external registry, in a sub-registry, or directly in the description of the Information Element, then the name or short description for that codepoint as a string MAY be used to improve readability.
署名されていない情報要素に識別子のセマンティクスがあり、外部レジストリ、サブレジストリ、または情報要素の説明で直接コードポイントのセットを参照する特別な場合は、そのコードポイントの名前または短い説明文字列として使用すると、読みやすさを向上させることができます。
Otherwise, the values of Information Elements of an unsigned integer type may be represented as either unprefixed base-10 (decimal) strings, base-16 (hexadecimal) strings prefixed by "0x", or base-2 (binary) strings prefixed by "0b". In ABNF:
それ以外の場合、符号なし整数型の情報要素の値は、接頭辞のない10進数（10進数）文字列、接頭辞が0xの16進数（16進数）文字列、または接頭辞が2進数（2進数）の文字列として表すことができます。 0b "。 ABNFの場合：
unsigned = 1*DIGIT / "0x" 1*HEXDIG / "0b" 1*BIT
Leading zeroes are allowed in any representation and do not signify base-8 (octal) representation. Binary representation is intended for use with Information Elements with flag semantics, but it can be used in any case.
先行ゼロは任意の表現で許可され、8進数（8進）表現を意味しません。バイナリ表現は、フラグセマンティクスを持つ情報要素での使用を目的としていますが、どのような場合でも使用できます。
The encoded value MUST be in range for the corresponding abstract data type or Information Element. Values that are out of range are interpreted as clipped to the implicit range for the Information Element as defined by the abstract data type or to the explicit range of the Information Element if defined. Minimum and maximum values for abstract data types are shown in Table 1 below.
エンコードされた値は、対応する抽象データ型または情報要素の範囲内にある必要があります。範囲外の値は、抽象データ型で定義されている情報要素の暗黙的な範囲、または定義されている場合は情報要素の明示的な範囲にクリップされると解釈されます。抽象データ型の最小値と最大値を以下の表1に示します。
+------------+---------+----------------------+
| type | minimum | maximum |
+------------+---------+----------------------+
| unsigned8 | 0 | 255 |
| unsigned16 | 0 | 65535 |
| unsigned32 | 0 | 4294967295 |
| unsigned64 | 0 | 18446744073709551615 |
+------------+---------+----------------------+
Table 1: Ranges for Unsigned Abstract Data Types (in Decimal)
表1：符号なし抽象データ型の範囲（10進数）
If the Enclosing Context defines a representation for signed integers, that representation SHOULD be used.
包含コンテキストが符号付き整数の表現を定義する場合、その表現を使用する必要があります（SHOULD）。
Otherwise, the values of Information Elements of signed integer types are represented as optionally prefixed base-10 (decimal) strings. In ABNF:
それ以外の場合、符号付き整数型の情報要素の値は、オプションで接頭辞付きの基数10（10進数）文字列として表されます。 ABNFの場合：
sign = "+" / "-"
signed = [sign] 1*DIGIT
If the sign is omitted, it is assumed to be positive. Leading zeroes are allowed and do not signify base-8 (octal) encoding. The representation "-0" is explicitly allowed and is equal to zero.
符号を省略した場合は正と見なされます。先行ゼロは許可され、base-8（8進）エンコードを意味しません。表現「-0」は明示的に許可され、ゼロに等しくなります。
The encoded value MUST be in range for the corresponding abstract data type or Information Element. Values that are out of range are to be interpreted as clipped to the implicit range for the Information Element as defined by the abstract data type or to the explicit range of the Information Element if defined. Minimum and maximum values for abstract data types are shown in Table 2 below.
エンコードされた値は、対応する抽象データ型または情報要素の範囲内にある必要があります。範囲外の値は、抽象データ型で定義されている情報要素の暗黙的な範囲、または定義されている場合は情報要素の明示的な範囲にクリップされると解釈されます。抽象データ型の最小値と最大値を以下の表2に示します。
+----------+----------------------+----------------------+
| type | minimum | maximum |
+----------+----------------------+----------------------+
| signed8 | -128 | +127 |
| signed16 | -32768 | +32767 |
| signed32 | -2147483648 | +2147483647 |
| signed64 | -9223372036854775808 | +9223372036854775807 |
+----------+----------------------+----------------------+
Table 2: Ranges for Signed Abstract Data Types (in Decimal)
表2：符号付き抽象データ型の範囲（10進数）
If the Enclosing Context defines a representation for floating-point numbers, that representation SHOULD be used.
囲みコンテキストが浮動小数点数の表現を定義する場合、その表現を使用する必要があります（SHOULD）。
Otherwise, the values of Information Elements of float32 or float64 types are represented as optionally sign-prefixed, optionally base-10 exponent-suffixed, floating-point decimal numbers, as in [IEEE.754.2008]. The special strings "NaN", "+inf", and "-inf" represent "not a number", "positive infinity", and "negative infinity", respectively.
それ以外の場合、float32またはfloat64型の情報要素の値は、[IEEE.754.2008]のように、オプションで符号接頭辞付き、オプションで底が10の指数サフィックス付き浮動小数点10進数として表されます。特殊文字列「NaN」、「+ inf」、および「-inf」は、それぞれ「非数」、「正の無限大」、および「負の無限大」を表します。
In ABNF:
ABNFの場合：
sign = "+" / "-"
exponent = "e" [sign] 1*3DIGIT
指数= "e" [符号] 1 * 3DIGIT
right-decimal = "." 1*DIGIT
右10進数= "。" 1 * DIGIT
mantissa = 1*DIGIT [right-decimal]
num = [sign] mantissa [exponent]
naninf = "NaN" / (sign "inf")
なにんｆ ＝ ”なん” ／ （しｇん ”いんｆ”）
float = num / naninf
The expressed value is ( mantissa * 10 ^ exponent ). If the sign is omitted, it is assumed to be positive. If the exponent is omitted, it is assumed to be zero. Leading zeroes may appear in the mantissa and/or the exponent. Values MUST be within range for single- or double-precision numbers as defined in [IEEE.754.2008]; finite values outside the appropriate range are to be interpreted as clamped to be within the range. Note that no more than three digits are required or allowed for exponents in this encoding due to these ranges.
表現される値は（仮数* 10 ^指数）です。符号を省略した場合は正と見なされます。指数を省略すると、ゼロと見なされます。先行ゼロが仮数または指数、あるいはその両方に現れる場合があります。 [IEEE.754.2008]で定義されているように、値は単精度または倍精度の数値の範囲内でなければなりません。適切な範囲外の有限値は、範囲内に収まるようにクランプされていると解釈されます。これらの範囲のため、このエンコードの指数には3桁以下が必要または許可されていることに注意してください。
Note that since this representation is meant for human readability, writers MAY sacrifice precision to use a more human-readable representation of a given value, at the expense of the ability to recover the exact bit pattern at the reader. Therefore, decoders MUST NOT assume that the represented values are exactly comparable for equality.
この表現は人間の可読性を目的としているため、ライターは、正確なビットパターンを復元する能力を犠牲にして、特定の値のより人間が読み取り可能な表現を使用するために精度を犠牲にする場合があります。したがって、デコーダは、表現された値が等しいかどうかを正確に比較できると仮定してはなりません（MUST NOT）。
If the Enclosing Context defines a representation for boolean values, that representation SHOULD be used.
包含コンテキストがブール値の表現を定義する場合、その表現を使用する必要があります（SHOULD）。
Otherwise, a true boolean value is represented by the literal string "true" and a false boolean value by the literal string "false". In ABNF:
それ以外の場合、真のブール値はリテラル文字列「true」で表され、偽のブール値はリテラル文字列「false」で表されます。 ABNFの場合：
boolean-true = "true"
boolean-false = "false"
boolean = boolean-true / boolean-false
Media Access Control (MAC) addresses are represented as IEEE 802 MAC-48 addresses, hexadecimal bytes with the most significant byte first, separated by colons. In ABNF:
メディアアクセスコントロール（MAC）アドレスは、IEEE 802 MAC-48アドレスとして表されます。コロンで区切られた、最上位バイトが最初の16進バイトです。 ABNFの場合：
hex-octet = 2HEXDIG
macaddress = hex-octet 5( ":" hex-octet )
As Information Elements of the string type are simply Unicode strings (encoded as UTF-8 when appearing in Data Sets in IPFIX Messages [RFC7011]), they are represented directly, using the Unicode encoding rules and quoting and escaping rules of the Enclosing Context.
文字列型の情報要素は単なるUnicode文字列（IPFIXメッセージ[RFC7011]のデータセットに表示されるときはUTF-8としてエンコードされる）であるため、Unicodeエンコーディングルールとエンクロージングコンテキストの引用およびエスケープルールを使用して直接表現されます。
If the Enclosing Context cannot natively represent Unicode characters, the escaping facility provided by the Enclosing Context MUST be used for nonrepresentable characters. Additionally, strings containing characters reserved in the Enclosing Context (e.g., control characters, markup characters, and quotes) MUST be escaped or quoted according to the rules of the Enclosing Context.
囲みコンテキストがUnicode文字をネイティブに表現できない場合は、囲みコンテキストによって提供されるエスケープ機能を、表現できない文字に使用する必要があります。さらに、囲みコンテキストで予約された文字（制御文字、マークアップ文字、引用符など）を含む文字列は、囲みコンテキストのルールに従ってエスケープまたは引用符で囲む必要があります。
It is presumed that the Enclosing Context has sufficient restrictions on the use of Unicode to prevent the unsafe use of nonprinting and control characters. As there is no accepted solution for the processing and safe display of mixed-direction strings, mixed-direction strings should be avoided using this encoding. Note also that since this document presents no additional requirements for the normalization of Unicode strings, care must be taken when comparing strings using this encoding; direct byte-pattern comparisons are not sufficient for determining whether two strings are equivalent. See
非印刷および制御文字の安全でない使用を防ぐために、囲みコンテキストにはUnicodeの使用に十分な制限があると想定されています。混合方向文字列の処理と安全な表示のための受け入れられた解決策はないので、混合エンコード文字列はこのエンコーディングを使用して避けられるべきです。また、このドキュメントではUnicode文字列の正規化に関する追加要件がないため、このエンコーディングを使用して文字列を比較する場合は注意が必要です。 2つの文字列が等しいかどうかを判断するには、バイトパターンを直接比較するだけでは不十分です。見る
[RFC6885] and [PRECIS] for more on possible unexpected results and related risks in comparing Unicode strings.
[RFC6885]と[PRECIS]は、Unicode文字列を比較する際の予期しない結果と関連するリスクの詳細について説明しています。
Timestamp abstract data types are represented generally as in [RFC3339], with two important differences. First, all IPFIX timestamps are expressed in terms of UTC, so textual representations of these Information Elements are explicitly in UTC as well. Time zone offsets are, therefore, not required or supported. Second, there are four timestamp abstract data types, separated by the precision that they can express. Fractional seconds are omitted in dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds, and so on.
タイムスタンプの抽象データ型は一般に[RFC3339]のように表されますが、2つの重要な違いがあります。まず、すべてのIPFIXタイムスタンプはUTCで表現されるため、これらの情報要素のテキスト表現はUTCでも明示されます。したがって、タイムゾーンオフセットは必須またはサポートされていません。次に、4つのタイムスタンプ抽象データ型があり、それらが表現できる精度で区切られています。小数秒はdateTimeSecondsでは省略され、dateTimeMillisecondsではミリ秒で表されます。
In ABNF, taken from [RFC3339] and modified as follows:
ABNFでは、[RFC3339]から取得され、次のように変更されました。
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60
time-msec = "." 3DIGIT
time-usec = "." 6DIGIT
time-nsec = "." 9DIGIT
full-date = date-fullyear "-" date-month "-" date-mday
integer-time = time-hour ":" time-minute ":" time-second
datetimeseconds = full-date "T" integer-time datetimemilliseconds = full-date "T" integer-time "." time-msec datetimemicroseconds = full-date "T" integer-time "." time-usec datetimenanoseconds = full-date "T" integer-time "." time-nsec
datetimeseconds =完全な日付 "T" integer-time datetimemilliseconds =完全な日付 "T" integer-time "。" time-msec datetimemicroseconds =完全な日付 "T" integer-time "。" time-usec datetimenanoseconds = full-date "T" integer-time "。"時間n秒
IP version 4 addresses are represented in dotted-quad format, most significant byte first, as it would be in a Uniform Resource Identifier [RFC3986]; the ABNF for an IPv4 address is taken from [RFC3986] and reproduced below:
IPバージョン4のアドレスは、Uniform Resource Identifier [RFC3986]の場合と同様に、ドット付きクワッド形式で表され、最上位バイトが最初になります。 IPv4アドレスのABNFは[RFC3986]から取得され、以下に再現されています。
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
ipv4address = dec-octet 3( "." dec-octet )
ipv4address = dec-octet 3（ "。" dec-octet）
IP version 6 addresses are represented as in Section 2.2 of [RFC4291], as updated by Section 4 of [RFC5952]. The ABNF for an IPv6 address is taken from [RFC3986] and reproduced below, using the ipv4address production from the previous section:
[RFC5952]のセクション4で更新されているように、IPバージョン6のアドレスは[RFC4291]のセクション2.2のように表されます。 IPv6アドレスのABNFは[RFC3986]から取得され、前のセクションのipv4addressプロダクションを使用して以下に再現されています。
ls32 = ( h16 ":" h16 ) / ipv4address
; least significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
; zeroes to be suppressed as in RFC 5952
ipv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ h16 ":" h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
These abstract data types, defined for IPFIX Structured Data [RFC6313], do not represent actual data types; they are instead designed to provide a mechanism by which complex structure can be represented in IPFIX below the template level. It is assumed that protocols using textual Information Element representation will provide their own structure. Therefore, Information Elements of these data types MUST NOT be used in textual representations.
IPFIX構造化データ[RFC6313]で定義されているこれらの抽象データ型は、実際のデータ型を表すものではありません。代わりに、テンプレートレベルの下のIPFIXで複雑な構造を表すことができるメカニズムを提供するように設計されています。テキストの情報要素表現を使用するプロトコルが独自の構造を提供すると想定されています。したがって、これらのデータ型の情報要素をテキスト表現で使用してはなりません。
The security considerations for the IPFIX protocol [RFC7011] apply.
IPFIXプロトコル[RFC7011]のセキュリティに関する考慮事項が適用されます。
Implementations of decoders of Information Element values using these representations must take care to correctly handle invalid input, but the encodings presented here are not special in that respect.
これらの表現を使用した情報要素値のデコーダーの実装は、無効な入力を正しく処理するように注意する必要がありますが、ここに示すエンコーディングは、その点で特別なものではありません。
The encoding specified in this document, and representations that may be built upon it, are specifically not intended for the storage of data. However, since storage of data in the format in which it is exchanged is a very common practice, and the ubiquity of tools for indexing and searching text significantly increases the ease of searching and the risk of privacy-sensitive data being accidentally indexed or searched, the privacy considerations in Section 11.8 of
このドキュメントで指定されているエンコーディング、およびその上に構築される可能性のある表現は、特にデータの格納を目的としたものではありません。ただし、データが交換される形式でデータを保存することは非常に一般的な方法であり、テキストのインデックス作成と検索を行うツールが広く普及しているため、検索が簡単になり、プライバシーに配慮したデータが誤ってインデックス化または検索されるリスクが高まります。セクション11.8のプライバシーに関する考慮事項
[RFC7011] are especially important to observe when storing data using the encoding specified in this document that was derived from the measurement of network traffic.
[RFC7011]は、ネットワークトラフィックの測定から得られた、このドキュメントで指定されたエンコーディングを使用してデータを保存するときに注意することが特に重要です。
When using representations based on this encoding to transmit or store network traffic data, consider omitting especially privacy-sensitive values by not representing the columns or keys containing those values, as in black-marker anonymization as discussed in Section 4 of [RFC6235]. Other anonymization techniques described in [RFC6235] may also be useful in these situations.
このエンコーディングに基づく表現を使用してネットワークトラフィックデータを送信または保存する場合は、[RFC6235]のセクション4で説明されているブラックマーカーの匿名化のように、これらの値を含む列またはキーを表現しないことで、特にプライバシーの影響を受けやすい値を省略することを検討してください。 [RFC6235]で説明されている他の匿名化手法も、これらの状況で役立つ場合があります。
The encodings for all abstract data types other than 'string' are defined in such a way as to be representable in the US-ASCII character set and, therefore, should be unproblematic for all Enclosing Contexts. However, the 'string' abstract data type may be vulnerable to problems with ill-formed UTF-8 strings as discussed in Section 6.1.6 of [RFC7011]; see [UTF8-EXPLOIT] for background.
「文字列」以外のすべての抽象データ型のエンコーディングは、US-ASCII文字セットで表現できるように定義されているため、すべてのエンクロージングコンテキストに問題がないはずです。ただし、[string]抽象データ型は、[RFC7011]のセクション6.1.6で説明されているように、不正な形式のUTF-8文字列の問題に対して脆弱である可能性があります。背景については[UTF8-EXPLOIT]を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3339]クライン、G、エド。 C.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、2002年7月、<http://www.rfc-editor.org/info/rfc3986>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010、<http://www.rfc-editor.org/info/rfc5952>。
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B.、Trammell、B。、およびP. Aitken、「フロー情報交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、2013年9月、<http： //www.rfc-editor.org/info/rfc7011>。
[IANA-IPFIX] IANA, "IPFIX Information Elements", <http://www.iana.org/assignments/ipfix/>.
[IANA-IPFIX] IANA、「IPFIX情報要素」、<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月。
[PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, draft-ietf-precis-framework-18, September 2014.
[PRECIS]セントアンドレ、P。およびM.ブランシェ、「PRECISフレームワーク：アプリケーションプロトコルにおける国際化文字列の準備と比較」、進行中の作業、draft-ietf-precis-framework-18、2014年9月。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011, <http://www.rfc-editor.org/info/rfc6235>.
[RFC6235] Boschi、E。およびB. Trammell、「IP Flow Anonymization Support」、RFC 6235、2011年5月、<http://www.rfc-editor.org/info/rfc6235>。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011, <http://www.rfc-editor.org/info/rfc6313>.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月、<http：// www .rfc-editor.org / info / rfc6313>。
[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, March 2013, <http://www.rfc-editor.org/info/rfc6885>.
[RFC6885] Blanchet、M。およびA. Sullivan、「国際化された文字列（PRECIS）の準備と比較のためのStringprepの改訂と問題の説明」、RFC 6885、2013年3月、<http://www.rfc-editor.org/ info / rfc6885>。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7012] Claise、B。およびB. Trammell、「IP Flow Information Export（IPFIX）の情報モデル」、RFC 7012、2013年9月、<http://www.rfc-editor.org/info/rfc7012>。
[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, <http://www.rfc-editor.org/info/rfc7013>.
[RFC7013] Trammell、B。およびB. Claise、「作成者とIPフロー情報エクスポート（IPFIX）情報要素のレビューアのためのガイドライン」、BCP 184、RFC 7013、2013年9月、<http：//www.rfc-editor。 org / info / rfc7013>。
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、「JavaScriptオブジェクト記法（JSON）データ交換形式」、RFC 7159、2014年3月、<http://www.rfc-editor.org/info/rfc7159>。
[UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", The Unicode Consortium, November 2012.
[UTF8-EXPLOIT] Davis、M.およびM. Suignard、「Unicode Technical Report＃36：Unicode Security Considerations」、Unicode Consortium、2012年11月。
[W3C-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml, November 2008.
[W3C-XML] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、W3C勧告REC- xml、2008年11月。
In this section, we examine an IPFIX Template and a Data Record defined by that Template and show how that Data Record would be represented in JSON according to the specification in this document. Note that this is specifically NOT a recommendation for a particular representation but merely an illustration of the encodings in this document; the quoting and formatting in the example are JSON specific.
このセクションでは、IPFIXテンプレートとそのテンプレートによって定義されたデータレコードを調べ、このデータレコードがこのドキュメントの仕様に従ってJSONでどのように表現されるかを示します。これは特定の表現に対する推奨ではなく、このドキュメントのエンコーディングの図にすぎないことに注意してください。この例の引用とフォーマットはJSON固有です。
Figure 1 shows a Template in Information Element Specifier (IESpec) format as defined in Section 10.1 of [RFC7013]; a corresponding JSON object representing a record defined by this template in the text format specified in this document is shown in Figure 2.
図1は、[RFC7013]のセクション10.1で定義されている情報要素指定子（IESpec）形式のテンプレートを示しています。このドキュメントで指定されているテキスト形式でこのテンプレートによって定義されたレコードを表す対応するJSONオブジェクトを図2に示します。
flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
octetDeltaCount(1)<unsigned64>[4]
packetDeltaCount(2)<unsigned64>[4]
sourceIPv6Address(27)<ipv6Address>[16]{key}
destinationIPv6Address(28)<ipv6Address>[16]{key}
sourceTransportPort(7)<unsigned16>[2]{key}
destinationTransportPort(11)<unsigned16>[2]{key}
protocolIdentifier(4)<unsigned8>[1]{key}
tcpControlBits(6)<unsigned16>[2]
flowEndReason(136)<unsigned8>[1]
Figure 1: Sample Flow Template in IESpec Format
図1：IESpec形式のサンプルフローテンプレート
{
"flowStartMilliseconds": "2012-11-05T18:31:01.135",
"flowEndMilliseconds": "2012-11-05T18:31:02.880",
"octetDeltaCount": 195383,
"packetDeltaCount": 88,
"sourceIPv6Address": "2001:db8:c:1337::2",
"destinationIPv6Address": "2001:db8:c:1337::3",
"sourceTransportPort": 80,
"destinationTransportPort": 32991,
"protocolIdentifier": "tcp",
"tcpControlBits": 19,
"flowEndReason": 3
}
Figure 2: JSON Object Containing Sample Flow
図2：サンプルフローを含むJSONオブジェクト
Acknowledgments
謝辞
Thanks to Paul Aitken, Benoit Claise, Andrew Feren, Juergen Quittek, David Black, and the IESG for their reviews and comments. Thanks to Dave Thaler and Stephan Neuhaus for discussions that improved the floating-point representation section. This work is materially supported by the European Union Seventh Framework Programme under grant agreement 318627 mPlane.
レビューとコメントを提供してくれたPaul Aitken、Benoit Claise、Andrew Feren、Juergen Quittek、David Black、およびIESGに感謝します。浮動小数点表現セクションを改善する議論をしてくれたDave ThalerとStephan Neuhausに感謝します。この作業は、助成金契約318627 mPlaneに基づく欧州連合第7フレームワークプログラムによって実質的にサポートされています。
Author's Address
著者のアドレス
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメルスイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13
EMail: ietf@trammell.ch