RFC 6759 - Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6759
タイトル : RFC 6759 - シスコシステムズのIPフロー情報エクスポート（IPFIX）でのアプリケーション情報のエクスポート
翻訳編集 : 自動生成

[要約] RFC 6759は、IP Flow Information Export（IPFIX）でのアプリケーション情報のエクスポートに関するCisco Systemsの提案です。その目的は、ネットワークトラフィックの分析と監視を向上させるために、アプリケーションレベルの情報をIPFIXフローレコードに追加することです。

Internet Engineering Task Force (IETF)                         B. Claise
Request for Comments: 6759                                     P. Aitken
Category: Informational                                     N. Ben-Dvora
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                           November 2012

Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)

シスコシステムズのIPフロー情報エクスポート（IPFIX）でのアプリケーション情報のエクスポート

Abstract

概要

This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information.

このドキュメントでは、アプリケーション情報をエクスポートするために、RFC 5102で指定されているIPFIX情報モデルに対するシスコシステムズの拡張を指定しています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6759.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6759で入手できます。

著作権表示

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. Application Information Use Cases ..........................5
      1.2. Conventions Used in This Document ..........................5
   2. IPFIX Documents Overview ........................................5
   3. Terminology .....................................................6
      3.1. New Terminology ............................................6
   4. applicationId Information Element Specification .................6
      4.1. Existing Classification Engine IDs .........................7
      4.2. Selector ID Length per Classification ID ..................11
      4.3. Application Name Options Template Record ..................12
      4.4. Resolving IANA L4 Port Discrepancies ......................13
   5. Grouping Applications with Attributes ..........................13
      5.1. Options Template Record for Attribute Values ..............15
   6. Application ID Examples ........................................15
      6.1. Example 1: Layer 2 Protocol ...............................15
      6.2. Example 2: Standardized IANA Layer 3 Protocol .............16
      6.3. Example 3: Proprietary Layer 3 Protocol ...................17
      6.4. Example 4: Standardized IANA Layer 4 Port .................18
      6.5. Example 5: Layer 7 Application ............................19
      6.6. Example 6: Layer 7 Application with Private
           Enterprise Number (PEN) ...................................21
      6.7. Example: Port Obfuscation .................................22
      6.8. Example: Application Name Mapping Options Template ........23
      6.9. Example: Attributes Values Options Template Record ........24
   7. IANA Considerations ............................................25
      7.1. New Information Elements ..................................25
           7.1.1. applicationDescription .............................25
           7.1.2. applicationId ......................................26
           7.1.3. applicationName ....................................26
           7.1.4. classificationEngineId .............................26
           7.1.5. applicationCategoryName ............................29
           7.1.6. applicationSubCategoryName .........................29
           7.1.7. applicationGroupName ...............................29
           7.1.8. p2pTechnology ......................................29
           7.1.9. tunnelTechnology ...................................30
           7.1.10. encryptedTechnology ...............................30
      7.2. Classification Engine ID Registry .........................30
   8. Security Considerations ........................................30
   9. References .....................................................31
      9.1. Normative References ......................................31
      9.2. Informative References ....................................32
   10. Acknowledgements ..............................................33
   Appendix A. Additions to XML Specification of IPFIX Information
               (Non-normative) .......................................34
   Appendix B. Port Collisions Tables (Non-normative) ................39
   Appendix C. Application Registry Example (Non-normative) ..........43
List of Figures

   Figure 1: applicationId Information Element .......................7
   Figure 2: Selector ID Encoding ...................................12

List of Tables

テーブルのリスト

   Table 1: Existing Classification Engine IDs .......................7
   Table 2: Selector ID Default Length per Classification
            Engine ID ...............................................11
   Table 3: Application ID Static Attributes ........................13
   Table 4: Different Protocols on UDP and TCP ......................39
   Table 5: Different Protocols on SCTP and TCP .....................40

1. Introduction

1. はじめに

Today, service providers and network administrators are looking for visibility into the packet content rather than just the packet header. Some network devices' Metering Processes inspect the packet content and identify the applications that are utilizing the network traffic. Applications in this context are defined as networking protocols used by networking processes that exchange packets between them (such as web applications, peer-to-peer applications, file transfer, e-mail applications, etc.). Applications can be further characterized by other criteria, some of which are application specific. Examples include: web application to a specific domain, per-user specific traffic, a video application with a specific codec, etc.

今日、サービスプロバイダーとネットワーク管理者は、パケットヘッダーだけでなく、パケットコンテンツの可視性を求めています。一部のネットワークデバイスのメータリングプロセスは、パケットの内容を検査し、ネットワークトラフィックを利用しているアプリケーションを識別します。このコンテキストのアプリケーションは、それらの間でパケットを交換するネットワークプロセスで使用されるネットワークプロトコルとして定義されます（Webアプリケーション、ピアツーピアアプリケーション、ファイル転送、電子メールアプリケーションなど）。アプリケーションは、他の基準によってさらに特徴付けることができ、そのいくつかはアプリケーション固有です。例には、特定のドメインへのWebアプリケーション、ユーザーごとの特定のトラフィック、特定のコーデックを備えたビデオアプリケーションなどがあります。

The application identification is based on several different methods or even a combination of methods:

アプリケーションの識別は、いくつかの異なる方法または方法の組み合わせに基づいています。

1. L2 (Layer 2) protocols (such as ARP (Address Resolution Protocol), PPP (Point-to-Point Protocol), LLDP (Link Layer Discovery Protocol))

1. L2（レイヤー2）プロトコル（ARP（アドレス解決プロトコル）、PPP（ポイントツーポイントプロトコル）、LLDP（リンク層検出プロトコル）など）

2. IP protocols (such as ICMP (Internet Control Message Protocol), IGMP (Internet Group Management Protocol), GRE (Generic Routing Encapsulation)

2. IPプロトコル（ICMP（インターネット制御メッセージプロトコル）、IGMP（インターネットグループ管理プロトコル）、GRE（汎用ルーティングカプセル化）など）

3. TCP or UDP ports (such as HTTP, Telnet, FTP)

3. TCPまたはUDPポート（HTTP、Telnet、FTPなど）

4. Application layer header (of the application to be identified)

4. アプリケーションレイヤーヘッダー（識別されるアプリケーションの）

5. Packet data content

5. パケットデータの内容

6. Packets and traffic behavior The exact application identification methods are part of the Metering Process internals that aim to provide an accurate identification and minimize false identification. This task requires a sophisticated Metering Process since the protocols do not behave in a standard manner.

6.パケットとトラフィックの動作正確なアプリケーション識別方法は、正確な識別を提供し、誤った識別を最小限に抑えることを目的としたメータリングプロセス内部の一部です。プロトコルは標準的な方法で動作しないため、このタスクには高度なメータリングプロセスが必要です。

1. Applications use port obfuscation where the application runs on a different port than the IANA assigned one. For example, an HTTP server might run on TCP port 23 (assigned to telnet in [IANA-PORTS]).

1. アプリケーションは、IANAが割り当てたポートとは異なるポートでアプリケーションが実行されるポート難読化を使用します。たとえば、HTTPサーバーがTCPポート23（[IANA-PORTS]でtelnetに割り当てられている）で実行される場合があります。

2. IANA port registries do not accurately reflect how certain ports are "commonly" used today. Some ports are reserved, but the application either never became prevalent or is not in use today.

2. IANAポートレジストリは、特定のポートが現在「一般的に」使用されている方法を正確に反映していません。一部のポートは予約されていますが、アプリケーションが普及したことがないか、今日は使用されていません。

3. The application behavior and identification logic become more and more complex.

3. アプリケーションの動作と識別ロジックは、ますます複雑になります。

For that reason, such Metering Processes usually detect applications based on multiple mechanisms in parallel. Detection based only on port matching might wrongly identify the application. If the Metering Process is capable of detecting applications more accurately, it is considered to be stronger and more accurate.

そのため、このようなメータリングプロセスは通常、複数のメカニズムに基づいてアプリケーションを並行して検出します。ポートの一致のみに基づく検出は、アプリケーションを誤って識別する可能性があります。メータリングプロセスがアプリケーションをより正確に検出できる場合、それはより強力でより正確であると見なされます。

Similarly, a reporting mechanism that uses L4 port based applications only, such as L4:<known port>, would have similar issues. The reporting system should be capable of reporting the applications classified using all types of mechanisms. In particular, applications that do not have any IANA port definition. While a mechanism to export application information should be defined, the L4 port being used must be exported using the destination port (destinationTransportPort at [IANA-IPFIX]) in the corresponding IPFIX record.

同様に、L4：<既知のポート>など、L4ポートベースのアプリケーションのみを使用するレポートメカニズムにも同様の問題があります。レポートシステムは、あらゆるタイプのメカニズムを使用して分類されたアプリケーションをレポートできる必要があります。特に、IANAポートが定義されていないアプリケーション。アプリケーション情報をエクスポートするメカニズムを定義する必要がありますが、使用されているL4ポートは、対応するIPFIXレコードの宛先ポート（[IANA-IPFIX]のdestinationTransportPort）を使用してエクスポートする必要があります。

Applications could be identified at different OSI layers, from layer 2 to layer 7. For example, the Link Layer Distribution Protocol (LLDP) [LLDP] can be identified in layer 2, ICMP can be identified in layer 3 [IANA-PROTO], HTTP can be identified in layer 4 [IANA-PORTS], and Webex can be identified in layer 7.

アプリケーションは、レイヤー2からレイヤー7までのさまざまなOSIレイヤーで識別できます。たとえば、リンクレイヤー配布プロトコル（LLDP）[LLDP]はレイヤー2で識別でき、ICMPはレイヤー3 [IANA-PROTO]で識別できます。 HTTPはレイヤー4 [IANA-PORTS]で識別でき、Webexはレイヤー7で識別できます。

While an ideal solution would be an IANA registry for applications above (or inside the payload of) the well-known ports [IANA-PORTS], this solution is not always possible. Indeed, the specifications for some applications embedded in the payload are not available. Some reverse engineering as well as a ubiquitous language for application identification would be required conditions to be able to manage an IANA registry for these types of applications. Clearly, these are blocking factors.

理想的なソリューションは、既知のポート[IANA-PORTS]の上（またはペイロード内）のアプリケーション用のIANAレジストリですが、このソリューションが常に可能であるとは限りません。実際、ペイロードに埋め込まれた一部のアプリケーションの仕様は利用できません。これらのタイプのアプリケーションのIANAレジストリを管理するためには、アプリケーション識別のためのいくつかのリバースエンジニアリングとユビキタス言語が必要です。明らかに、これらは阻害要因です。

This document specifies the Cisco Systems application information encoding (as described in Section 4) to export the application information with the IPFIX protocol [RFC5101]. However, the layer 7 application registry values are out of scope of this document.

このドキュメントでは、IPFIXプロトコル[RFC5101]を使用してアプリケーション情報をエクスポートするために、シスコシステムズのアプリケーション情報エンコーディング（セクション4で説明）を指定しています。ただし、レイヤー7アプリケーションのレジストリ値は、このドキュメントの範囲外です。

1.1. Application Information Use Cases

1.1. アプリケーション情報の使用例

There are several use cases for application information:

アプリケーション情報にはいくつかの使用例があります。

1. Application Visibility

1. アプリケーションの可視性

This is one of the main cases for using application information. Network administrators are using application visibility to understand the main network consumers, network trends, and user behavior.

これは、アプリケーション情報を使用する主なケースの1つです。ネットワーク管理者は、アプリケーションの可視性を使用して、主要なネットワークの消費者、ネットワークの傾向、およびユーザーの行動を理解しています。

2. Security Functions

2. セキュリティ機能

Application knowledge is sometimes used in security functions in order to provide comprehensive functions such as Application-based firewall, URL filtering, parental control, intrusion detection, etc.

アプリケーションベースのファイアウォール、URLフィルタリング、ペアレンタルコントロール、侵入検知などの包括的な機能を提供するために、アプリケーションの知識がセキュリティ機能で使用されることがあります。

All of the above use cases require exporting application information to provide the network function itself or to log the network function operation.

上記のすべてのユースケースでは、ネットワーク機能自体を提供したり、ネットワーク機能の動作をログに記録したりするために、アプリケーション情報をエクスポートする必要があります。

1.2. Conventions Used in This Document

1.2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. IPFIX Documents Overview

2. IPFIXドキュメントの概要

The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information.

IPFIXプロトコル[RFC5101]は、ネットワーク管理者にIPフロー情報へのアクセスを提供します。

The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX Architecture [RFC5470], per the requirements defined in RFC 3917 [RFC3917].

IPFIXエクスポートプロセスから収集プロセスへの測定IPフロー情報のエクスポートのアーキテクチャは、RFC 3917 [RFC3917]で定義されている要件に従って、IPFIXアーキテクチャ[RFC5470]で定義されています。

The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes.

IPFIXアーキテクチャ[RFC5470]は、IPFIXデータレコードとテンプレートが、IPFIXエクスポートプロセスからIPFIX収集プロセスへの輻輳認識トランスポートプロトコルを介してどのように運ばれるかを指定します。

IPFIX has a formal description of IPFIX Information Elements, their names, types, and additional semantic information, as specified in the IPFIX information model [RFC5102].

IPFIXには、IPFIX情報モデル[RFC5102]で指定されているように、IPFIX情報要素、その名前、タイプ、および追加のセマンティック情報の正式な説明があります。

In order to gain a level of confidence in the IPFIX implementation, probe the conformity and robustness, and allow interoperability, the Guidelines for IPFIX Testing [RFC5471] presents a list of tests for implementers of compliant Exporting Processes and Collecting Processes.

IPFIX実装の信頼性を確保し、適合性と堅牢性を検証し、相互運用性を可能にするために、IPFIXテストのガイドライン[RFC5471]は、準拠するエクスポートプロセスと収集プロセスの実装者向けのテストのリストを示しています。

The Bidirectional Flow Export [RFC5103] specifies a method for exporting bidirectional flow (biflow) information using the IPFIX protocol, representing each biflow using a single Flow Record.

双方向フローエクスポート[RFC5103]は、IPFIXプロトコルを使用して双方向フロー（biflow）情報をエクスポートする方法を指定し、単一のフローレコードを使用して各双方向フローを表します。

"Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth-saving method for exporting Flow or packet information, by separating information common to several Flow Records from information specific to an individual Flow Record: common Flow information is exported only once.

「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」[RFC5473]は、複数のフローレコードに共通の情報を個々のフローに固有の情報から分離することにより、フローまたはパケット情報をエクスポートするための帯域幅節約方法を指定しますレコード：共通のフロー情報は一度だけエクスポートされます。

3. Terminology

3. 用語

IPFIX-specific terminology used in this document is defined in Section 2 of the IPFIX protocol specification [RFC5101]. As in [RFC5101], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.

このドキュメントで使用されているIPFIX固有の用語は、IPFIXプロトコル仕様[RFC5101]のセクション2で定義されています。 [RFC5101]と同様に、これらのIPFIX固有の用語は、このドキュメントで使用される場合、単語の最初の文字が大文字になります。

3.1. New Terminology

3.1. 新しい用語

Application ID

アプリケーションID

A unique identifier for an application.

アプリケーションの一意の識別子。

When an application is detected, the most granular application is encoded in the Application ID.

アプリケーションが検出されると、最も詳細なアプリケーションがアプリケーションIDにエンコードされます。

4. applicationId Information Element Specification

4. applicationId情報要素の仕様

This document specifies the applicationId Information Element, which is a single field composed of two parts:

このドキュメントでは、applicationId情報要素を指定します。これは、2つの部分で構成される単一のフィールドです。

1. 8 bits of Classification Engine ID. The Classification Engine can be considered as a specific registry for application assignments.

1. 8ビットの分類エンジンID。分類エンジンは、アプリケーション割り当ての特定のレジストリと見なすことができます。

2. n bits of Selector ID. The Selector ID length varies depending on the Classification Engine ID.

2. nビットのセレクタID。セレクタIDの長さは、分類エンジンIDによって異なります。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Class. Eng. ID|         Selector ID  ...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: applicationId Information Element

図1：applicationId情報要素

Classification Engine ID

分類エンジンID

A unique identifier for the engine that determined the Selector ID. Thus, the Classification Engine ID defines the context for the Selector ID.

セレクタIDを決定したエンジンの一意の識別子。したがって、分類エンジンIDはセレクタIDのコンテキストを定義します。

Selector ID

セレクタID

A unique identifier of the application for a specific Classification Engine ID. Note that the Selector ID length varies depending on the Classification Engine ID.

特定の分類エンジンIDに対するアプリケーションの一意の識別子。セレクタIDの長さは、分類エンジンIDによって異なることに注意してください。

The Selector ID term is a similar concept to the selectorId Information Element, specified in the PSAMP Protocol [RFC5476][RFC5477].

セレクタIDの用語は、PSAMPプロトコル[RFC5476] [RFC5477]で指定されているselectorId情報要素と同様の概念です。

4.1. Existing Classification Engine IDs

4.1. 既存の分類エンジンID

The following Classification Engine IDs have been allocated:

次の分類エンジンIDが割り当てられています。

Name Value Description

名前値説明

0 Invalid.

0無効。

IANA-L3 1 The Assigned Internet Protocol Number (layer 3 (L3)) is exported in the Selector ID. See [IANA-PROTO].

IANA-L3 1割り当てられたインターネットプロトコル番号（レイヤー3（L3））がセレクタIDでエクスポートされます。 [IANA-PROTO]を参照してください。

PANA-L3 2 Proprietary layer 3 definition. An enterprise can export its own layer 3 protocol numbers. The Selector ID has a global significance for all devices from the same enterprise.

PANA-L3 2独自のレイヤー3定義。企業は独自のレイヤー3プロトコル番号をエクスポートできます。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。

IANA-L4 3 The IANA layer 4 (L4) well-known port number is exported in the Selector ID. See [IANA-PORTS]. Note: as an IPFIX flow is unidirectional, it contains the destination port.

IANA-L4 3 IANAレイヤー4（L4）ウェルノウンポート番号がセレクタIDでエクスポートされます。 [IANA-PORTS]を参照してください。注：IPFIXフローは単方向であるため、宛先ポートが含まれます。

PANA-L4 4 Proprietary layer 4 definition. An enterprise can export its own layer 4 port numbers. The Selector ID has global significance for devices from the same enterprise. Example: IPFIX was pre-assigned the port 4739 using the IANA early allocation process [RFC4020] years before the document was published as an RFC. While waiting for the RFC and its associated IANA registration, Selector ID 4739 was used with this PANA-L4.

PANA-L4 4独自のレイヤー4定義。企業は、独自のレイヤー4ポート番号をエクスポートできます。セレクタIDは、同じ企業のデバイスに対してグローバルに重要です。例：IPFIXは、ドキュメントがRFCとして公開される何年も前に、IANA早期割り当てプロセス[RFC4020]を使用してポート4739を事前に割り当てられていました。 RFCとそれに関連するIANA登録を待機している間、このPANA-L4でセレクタID 4739が使用されました。

5 Reserved.

5予約済み。

USER- 6 The Selector ID represents Defined applications defined by the user (using CLI, GUI, etc.) based on the methods described in Section 1. The Selector ID has a local significance per device.

USER- 6セレクタIDは、セクション1で説明した方法に基づいてユーザーが（CLI、GUIなどを使用して）定義した定義済みアプリケーションを表します。セレクタIDは、デバイスごとにローカルで重要です。

7 Reserved.

7予約済み。

8 Reserved.

8予約済み。

9 Reserved.

9予約済み。

10 Reserved.

10予約済み。

11 Reserved.

11予約済み。

PANA-L2 12 Proprietary layer 2 (L2) definition. An enterprise can export its own layer 2 identifiers. The Selector ID represents the enterprise's unique global layer 2 applications. The Selector ID has a global significance for all devices from the same enterprise. Examples include Cisco Subnetwork Access Protocol (SNAP).

PANA-L2 12独自のレイヤー2（L2）定義。企業は独自のレイヤー2識別子をエクスポートできます。セレクタIDは、企業固有のグローバルレイヤー2アプリケーションを表します。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。例には、Cisco Subnetwork Access Protocol（SNAP）が含まれます。

PANA-L7 13 Proprietary layer 7 definition. The Selector ID represents the enterprise's unique global ID for layer 7 applications. The Selector ID has a global significance for all devices from the same enterprise. This Classification Engine ID is used when the application registry is owned by the Exporter manufacturer (referred to as the "enterprise" in this document).

PANA-L7 13独自のレイヤー7定義。セレクターIDは、レイヤー7アプリケーションに対する企業固有のグローバルIDを表します。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。この分類エンジンIDは、アプリケーションレジストリがエクスポーターの製造元（このドキュメントでは「エンタープライズ」と呼ばれます）によって所有されている場合に使用されます。

14 Reserved.

14予約済み。

15 Reserved.

15予約済み。

16 Reserved.

16予約済み。

17 Reserved.

17予約済み。

ETHERTYPE 18 The Selector ID represents the well-known Ethertype. See [ETHERTYPE].

ETHERTYPE 18セレクタIDは、既知のEthertypeを表します。 [ETHERTYPE]を参照してください。

LLC 19 The Selector ID represents the well-known IEEE 802.2 Link Layer Control (LLC) Destination Service Access Point (DSAP). See [LLC].

LLC 19セレクタIDは、よく知られたIEEE 802.2リンク層制御（LLC）宛先サービスアクセスポイント（DSAP）を表します。 [LLC]を参照してください。

PANA-L7- 20 Proprietary layer 7 definition, PEN including a Private Enterprise Number (PEN) [IANA-PEN] to identify that the application registry being used is not owned by the Exporter manufacturer or to identify the original enterprise in the case of a mediator or 3rd party device. The Selector ID represents the enterprise unique global ID for the layer 7 applications. The Selector ID has a global significance for all devices from the same enterprise.

PANA-L7- 20独自のレイヤー7定義、PENにPrivate Enterprise Number（PEN）[IANA-PEN]を含めて、使用されているアプリケーションレジストリが輸出業者の製造元に所有されていないことを識別したり、メディエーターまたはサードパーティのデバイス。セレクターIDは、レイヤー7アプリケーションのエンタープライズ固有のグローバルIDを表します。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。

21 to 255 Available (255 is the maximum Engine ID)

21〜255使用可能（255は最大エンジンID）

Table 1: Existing Classification Engine IDs

表1：既存の分類エンジンID

"PANA = Proprietary Assigned Number Authority". In other words, an enterprise specific version of IANA for internal IDs.

「PANA = Proprietary Assigned Number Authority」。つまり、内部ID用の企業固有のバージョンのIANAです。

The PANA-L7 Classification Engine ID SHOULD be used when the application registry is owned by the Exporter manufacturer. Even if the application registry is owned by the Exporter manufacturer, the PANA-L7-PEN MAY be used, specifying the manufacturer.

PANA-L7分類エンジンIDは、アプリケーションレジストリがエクスポーターの製造元によって所有されている場合に使用する必要があります（SHOULD）。アプリケーションレジストリがエクスポーターの製造元によって所有されている場合でも、PANA-L7-PENを使用して、製造元を指定できます。

For example, if Exporter A (from enterprise-A) wants to export its enterprise-A L7 registry, then it uses the PANA-L7 Classification Engine ID. If Exporter B (from enterprise-B) wants to export its enterprise-B L7 registry, then it also uses the PANA-L7 Classification Engine ID.

たとえば、エクスポーターA（エンタープライズAから）がエンタープライズA L7レジストリをエクスポートする場合、PANA-L7分類エンジンIDを使用します。エンタープライズBからのエクスポーターBがエンタープライズB L7レジストリをエクスポートする場合は、PANA-L7分類エンジンIDも使用します。

The mechanism for the Collector to know about the Exporter PEN is out of scope of this document. Possible tracks are SNMP polling, an Options Template exporting the privateEnterpriseNumber Information Element [IANA-IPFIX], hardcoded value, etc.

コレクターがエクスポーターPENを認識するメカニズムは、このドキュメントの範囲外です。可能なトラックは、SNMPポーリング、privateEnterpriseNumber情報要素[IANA-IPFIX]をエクスポートするオプションテンプレート、ハードコードされた値などです。

An Exporter may classify the application according to another vendor's application registry. For example, an IPFIX Mediator [RFC6183] may need to re-export applications received from different Exporters using different PANA-L7 application registries. For example, if Exporter C (from enterprise-C) wants to reuse enterprise-D's application registry, then it uses PANA-L7-PEN with enterprise-D's PEN.

輸出業者は、別のベンダーのアプリケーションレジストリに従ってアプリケーションを分類できます。たとえば、IPFIX Mediator [RFC6183]は、異なるPANA-L7アプリケーションレジストリを使用して、異なるエクスポーターから受信したアプリケーションを再エクスポートする必要がある場合があります。たとえば、エクスポーターC（エンタープライズCから）がエンタープライズDのアプリケーションレジストリを再利用する場合、エンタープライズDのPENでPANA-L7-PENを使用します。

When reporting application information from multiple Exporters from different enterprises (different PENs), the PANA-L7-PEN Classification Engine MUST be used in exported Flow Records, which allows the original enterprise ID to be reported. The ID of the enterprise that defined the Application ID is identified by the enterprise's PEN. For example, an IPFIX Mediator aggregates traffic from some Exporters which report enterprise-E applications and other Exporters that report enterprise-F applications.

異なる企業（異なるPEN）の複数のエクスポーターからアプリケーション情報を報告する場合、元の企業IDを報告できるように、PANA-L7-PEN分類エンジンをエクスポートされたフローレコードで使用する必要があります。アプリケーションIDを定義した企業のIDは、企業のPENによって識別されます。たとえば、IPFIX Mediatorは、Enterprise-Eアプリケーションを報告する一部のエクスポーターとEnterprise-Fアプリケーションを報告する他のエクスポーターからのトラフィックを集約します。

An example is displayed in Section 6.6.

例をセクション6.6に示します。

Note that the PANA-L7 Classification Engine ID is also used for resolving IANA L4 port Discrepancies (see Section 4.4).

PANA-L7分類エンジンIDは、IANA L4ポートの不一致の解決にも使用されることに注意してください（セクション4.4を参照）。

The list in Table 1 is maintained by IANA thanks to the registry within the classificationEngineId Information Element. See the IANA Considerations section. The Classification Engine ID is part of the Application ID encoding, so the classificationEngineId Information Element is currently not required by the specifications in this document. However, this Information Element was created for completeness, as it was anticipated that this Information Element will be required in the future.

表1のリストは、classificationEngineId情報要素内のレジストリのおかげで、IANAによって管理されています。 IANAの考慮事項のセクションを参照してください。分類エンジンIDはアプリケーションIDエンコードの一部であるため、このドキュメントの仕様では、classificationEngineId情報要素は現在必要ありません。ただし、この情報要素は、将来必要になることが予想されるため、完全を期して作成されました。

4.2. Selector ID Length per Classification ID

4.2. 分類IDごとのセレクタIDの長さ

As the Selector ID part of the Application ID is variable based on the Classification Engine ID value, the applicationId SHOULD be encoded in a variable-length Information Element [RFC5101] for IPFIX export.

アプリケーションIDのセレクターID部分は分類エンジンID値に基づいて可変であるため、applicationFIXはIPFIXエクスポート用の可変長情報要素[RFC5101]にエンコードする必要があります（SHOULD）。

The following table displays the Selector ID default length for the different Classification Engine IDs.

次の表は、さまざまな分類エンジンIDのセレクターIDのデフォルトの長さを示しています。

Classification Selector ID default Engine ID Name length (in bytes)

分類セレクタIDのデフォルトのエンジンID名の長さ（バイト単位）

IANA-L3 1

行1

PANA-L3 1

IANA-L4 2

PANA-L4 2

USER-Defined 3

ユーザー定義3

PANA-L2 5

ブンク

PANA-L7 3

ETHERTYPE 2

LLC 1

PANA-L7-PEN 3 (*)

ぱなーＬ７ーぺん３（＊）

Table 2: Selector ID Default Length per Classification Engine ID

表2：分類エンジンIDごとのセレクターIDのデフォルトの長さ

(*) There are an extra 4 bytes for the PEN. However, the PEN is not considered part of the Selector ID.

（*）PENには追加の4バイトがあります。ただし、PENはセレクタIDの一部とは見なされません。

If a legacy protocol such as NetFlow version 9 [RFC3954] is used, and this protocol doesn't support variable-length Information Elements, then either multiple Template Records (one per applicationId length), or a single Template Record corresponding to the maximum sized applicationId MUST be used.

NetFlowバージョン9 [RFC3954]などのレガシープロトコルが使用され、このプロトコルが可変長の情報要素をサポートしていない場合、複数のテンプレートレコード（applicationIdの長さごとに1つ）または最大サイズに対応する単一のテンプレートレコードapplicationIdを使用する必要があります。

Application IDs MAY be encoded in a smaller number of bytes, following the same rules as for IPFIX Reduced Size Encoding [RFC5101].

アプリケーションIDは、IPFIX縮小サイズエンコーディング[RFC5101]と同じルールに従って、より少ないバイト数でエンコードされる場合があります。

Application IDs MAY be encoded with a larger length. For example, a normal IANA L3 protocol encoding would take 2 bytes since the Selector ID represents the protocol field from the IP header encoded in one byte. However, an IANA L3 protocol encoding may be encoded with 3 bytes. In this case, the Selector ID value MUST always be encoded in the least significant bits as shown in Figure 2.

アプリケーションIDは、より長い長さでエンコードされる場合があります。たとえば、セレクタIDは1バイトでエンコードされたIPヘッダーのプロトコルフィールドを表すため、通常のIANA L3プロトコルエンコードは2バイトかかります。ただし、IANA L3プロトコルエンコーディングは3バイトでエンコードされる場合があります。この場合、図2に示すように、セレクタID値は常に最下位ビットでエンコードする必要があります。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Class. Eng. ID |zero-valued upper-bits ... Selector ID         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Selector ID Encoding

図2：セレクターIDエンコーディング

4.3. Application Name Options Template Record

4.3. アプリケーション名オプションテンプレートレコード

For Classification Engines that specify locally unique Application IDs (which means unique per engine and per router), an Options Template Record (see [RFC5101]) MUST be used to export the correspondence between the Application ID, the Application Name, and the Application Description.

ローカルで一意のアプリケーションID（エンジンごとおよびルーターごとに一意を意味する）を指定する分類エンジンの場合、オプションテンプレートレコード（[RFC5101]を参照）を使用して、アプリケーションID、アプリケーション名、およびアプリケーションの説明間の対応をエクスポートする必要があります。。

For Classification Engines that specify globally unique Application IDs, an Options Template Record MAY be used to export the correspondence between the Application ID, the Application Name and the Application Description, unless the mapping is hardcoded in the Collector, or known out of band (for example, by polling a MIB).

グローバルに一意のアプリケーションIDを指定する分類エンジンの場合、マッピングがコレクターでハードコード化されているか、または帯域外（既知の場合）でない限り、オプションテンプレートレコードを使用して、アプリケーションID、アプリケーション名、およびアプリケーションの説明間の対応をエクスポートできます。たとえば、MIBをポーリングします）。

An example Options Template is shown in Section 6.8.

オプションテンプレートの例をセクション6.8に示します。

Enterprises may assign company-wide Application ID values for the PANA-L7 Classification Engine. In this case, a possible optimization for the Collector is to keep the mappings between the Application IDs and the Application Names per enterprise, as opposed to per Exporter.

企業は、PANA-L7分類エンジンに会社全体のアプリケーションID値を割り当てることができます。この場合、コレクターの最適化は、エクスポーターごとではなく、エンタープライズごとのアプリケーションIDとアプリケーション名の間のマッピングを維持することです。

4.4. Resolving IANA L4 Port Discrepancies

4.4. IANA L4ポートの不一致の解決

Even though IANA L4 ports usually point to the same protocols for both UDP, TCP or other transport types, there are some exceptions, as mentioned in Appendix B.

IANA L4ポートは通常、UDP、TCP、またはその他のトランスポートタイプの両方で同じプロトコルを指しますが、付録Bで説明されているように、いくつかの例外があります。

Instead of imposing the transport protocol (UDP/TCP/SCTP/etc.) in the scope of the "Application Name Options Template Record" (Section 6.8) for all applications (in addition to having the transport protocol as a key-field in the Flow Record definition), the convention is that the L4 application is always TCP related. So, whenever the Collector has a conflict in looking up IANA, it would choose the TCP choice. As a result, the UDP L4 applications from Table 3 and the SCTP L4 applications from Table 4 are assigned in the PANA_L7 Application ID range, i.e., under Classification Engine ID 13.

すべてのアプリケーションの「アプリケーション名オプションテンプレートレコード」（セクション6.8）のスコープにトランスポートプロトコル（UDP / TCP / SCTPなど）を課す代わりに（トランスポートプロトコルをフローレコードの定義）、慣例では、L4アプリケーションは常にTCP関連です。そのため、コレクターがIANAを検索する際に競合がある場合は常に、TCPを選択します。その結果、表3のUDP L4アプリケーションと表4のSCTP L4アプリケーションは、PANA_L7アプリケーションIDの範囲、つまり分類エンジンID 13に割り当てられます。

Currently, there are no discrepancies between the well-known ports for TCP and the Datagram Congestion Control Protocol (DCCP).

現在、TCPの既知のポートとデータグラム輻輳制御プロトコル（DCCP）の間に違いはありません。

5. Grouping Applications with Attributes

5. 属性によるアプリケーションのグループ化

Due to the high number of different Application IDs, Application IDs MAY be categorized into groups. This offers the benefits of easier reporting and action, such as QoS policies. Indeed, most applications with the same characteristics should be treated the same way; for example, all video traffic.

異なるアプリケーションIDの数が多いため、アプリケーションIDはグループに分類される場合があります。これにより、QoSポリシーなどのレポートとアクションが容易になるという利点があります。実際、同じ特性を持つほとんどのアプリケーションは同じ方法で処理する必要があります。たとえば、すべてのビデオトラフィック。

Attributes are statically assigned per Application ID and are independent of the traffic. The attributes are listed below:

属性はアプリケーションIDごとに静的に割り当てられ、トラフィックとは無関係です。属性は以下のとおりです。

Name Description

名前説明

Category An attribute that provides a first-level categorization for each Application ID. Examples include browsing, email, file-sharing, gaming, instant messaging, voice-and-video, etc. The category attribute is encoded by the applicationCategoryName Information Element.

カテゴリ各アプリケーションIDの第1レベルの分類を提供する属性。例としては、ブラウジング、電子メール、ファイル共有、ゲーム、インスタントメッセージング、音声とビデオなどがあります。カテゴリ属性は、applicationCategoryName情報要素によってエンコードされます。

Sub-Category An attribute that provides a second-level categorization for each Application ID. Examples include backup-systems, client-server, database, routing-protocol, etc. The sub-category attribute is encoded by the applicationSubCategoryName Information Element.

サブカテゴリ各アプリケーションIDの第2レベルの分類を提供する属性。例としては、バックアップシステム、クライアントサーバー、データベース、ルーティングプロトコルなどがあります。サブカテゴリ属性は、applicationSubCategoryName情報要素によってエンコードされます。

Application- An attribute that groups multiple Group Application IDs that belong to the same networking application. For example, the ftp-group contains ftp-data (port 20), ftp (port 20), ni-ftp (port 47), sftp (port 115), bftp (port 152), ftp-agent(port 574), ftps-data (port 989). The application-group attribute is encoded by the applicationGroupName Information Element.

アプリケーション-同じネットワークアプリケーションに属する複数のグループアプリケーションIDをグループ化する属性。たとえば、ftp-groupには、ftp-data（ポート20）、ftp（ポート20）、ni-ftp（ポート47）、sftp（ポート115）、bftp（ポート152）、ftp-agent（ポート574）、 ftps-data（ポート989）。 application-group属性は、applicationGroupName情報要素によってエンコードされます。

P2P-Technology Specifies if the Application ID is based on peer-to-peer technology. The P2P-technology attribute is encoded by the p2pTechnology Information Element.

P2P-TechnologyアプリケーションIDがピアツーピアテクノロジーに基づいているかどうかを指定します。 P2Pテクノロジー属性は、p2pTechnology情報要素によってエンコードされます。

Tunnel- Specifies if the Application ID is Technology used as a tunnel technology. The tunnel-technology attribute is encoded by the tunnelTechnology Information Element.

トンネル-アプリケーションIDがトンネル技術として使用される技術であるかどうかを指定します。トンネル技術属性は、tunnelTechnology情報要素によってエンコードされます。

Encrypted Specifies if the Application ID is an encrypted networking protocol. The encrypted attribute is encoded by the encryptedTechnology Information Element.

暗号化アプリケーションIDが暗号化されたネットワークプロトコルであるかどうかを指定します。暗号化された属性は、encryptedTechnology情報要素によってエンコードされます。

Table 3: Application ID Static Attributes

表3：アプリケーションIDの静的属性

Every application is assigned to one applicationCategoryName, one applicationSubCategoryName, one applicationGroupName, and it has one p2pTechnology, one tunnelTechnology, and one encryptedTechnology. These new Information Elements are specified in the IANA Considerations section (Section 7.1).

すべてのアプリケーションは、1つのapplicationCategoryName、1つのapplicationSubCategoryName、1つのapplicationGroupNameに割り当てられ、1つのp2pTechnology、1つのtunnelTechnology、および1つのencryptedTechnologyがあります。これらの新しい情報要素は、IANAの考慮事項セクション（セクション7.1）で指定されています。

Maintaining the attribute values in IANA seems impossible to realize. Therefore, the attribute values per application are enterprise specific.

IANAで属性値を維持することは実現不可能のようです。したがって、アプリケーションごとの属性値は企業固有です。

5.1. Options Template Record for Attribute Values

5.1. 属性値のオプションテンプレートレコード

An Options Template Record (see [RFC5101]) SHOULD be used to export the correspondence between each Application ID and its related Attribute values. An alternative way for the Collecting Process to learn the correspondence is to populate these mappings out of band, for example, by loading a CSV file containing the correspondence table.

オプションテンプレートレコード（[RFC5101]を参照）を使用して、各アプリケーションIDとそれに関連する属性値の間の対応をエクスポートする必要があります（SHOULD）。収集プロセスが通信を学習する別の方法は、たとえば、通信テーブルを含むCSVファイルをロードすることによって、これらのマッピングを帯域外に設定することです。

The Attributes Option Template contains the application ID as a scope field, followed by the applicationCategoryName, the applicationSubCategoryName, the applicationGroupName, the p2pTechnology, the tunnelTechnology, and the encryptedTechnology Information Elements.

属性オプションテンプレートには、スコープフィールドとしてアプリケーションIDが含まれ、その後にapplicationCategoryName、applicationSubCategoryName、applicationGroupName、p2pTechnology、tunnelTechnology、およびencryptedTechnology情報要素が続きます。

A list of attributes may conveniently be exported using a subTemplateList per [RFC6313].

属性のリストは、[RFC6313]によるsubTemplateListを使用して便利にエクスポートできます。

An example is given in Section 6.9.

例はセクション6.9にあります。

6. Application ID Examples

6. アプリケーションIDの例

The following examples are created solely for the purpose of illustrating how the extensions proposed in this document are encoded.

次の例は、このドキュメントで提案されている拡張機能がどのようにエンコードされるかを示す目的でのみ作成されています。

6.1. Example 1: Layer 2 Protocol

6.1. 例1：レイヤー2プロトコル

The list of Classification Engine IDs in Table 1 shows that the layer 2 Classification Engine IDs are 12 (PANA-L2), 18, (ETHERTYPE) and 19 (LLC).

表1の分類エンジンIDのリストは、レイヤー2分類エンジンIDが12（PANA-L2）、18（ETHERTYPE）および19（LLC）であることを示しています。

From the Ethertype list, LLDP [LLDP] has the Selector ID value 0x88CC, so 35020 in decimal:

Ethertypeリストから、LLDP [LLDP]にはセレクタID値0x88CCがあるため、10進数で35020になります。

NAME Selector ID LLDP 35020

NAMEセレクタID LLDP 35020

So, in the case of LLDP, the Classification Engine ID is 18 (LLC) while the Selector ID has the value 35020.

したがって、LLDPの場合、分類エンジンIDは18（LLC）ですが、セレクターIDの値は35020です。

Per Section 4, the applicationId Information Element is a single field composed of 8 bits of Classification Engine ID, followed by n bits of Selector ID. From Table 2, the Selector ID length n is 2 for the ETHERTYPE Engine ID.

セクション4に従って、applicationId情報要素は、8ビットの分類エンジンIDとそれに続くnビットのセレクタIDで構成される単一のフィールドです。表2から、セレクタIDの長さnは、ETHERTYPEエンジンIDに対して2です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       18      |             35020             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So the Application ID has the decimal value of 1214668. The format '18..35020' is used for simplicity in the examples below, to clearly express that two components of the Application ID.

したがって、アプリケーションIDの10進数値は1214668です。以下の例では、「18..35020」という形式を使用して、アプリケーションIDの2つのコンポーネントを明確に表現しています。

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- applicationId (key field) - octetTotalCount (non-key field)

- applicationId（キーフィールド）-octetTotalCount（非キーフィールド）

For example, a Flow Record corresponding to the above Template Record may contain:

たとえば、上記のテンプレートレコードに対応するフローレコードには以下が含まれます。

       { applicationId='18..35020',
         octetTotalCount=123456 }

The Collector has all the required information to determine that the application is LLDP, because the Application ID uses a global and well-known registry, i.e., the Ethertype. The Collector can determine which application is represented by the Application ID by loading the registry out of band.

アプリケーションIDはグローバルで既知のレジストリ、つまりEthertypeを使用するため、コレクターはアプリケーションがLLDPであることを確認するために必要なすべての情報を持っています。コレクターは、レジストリーを帯域外にロードすることにより、アプリケーションIDが表すアプリケーションを判別できます。

6.2. Example 2: Standardized IANA Layer 3 Protocol

6.2. 例2：標準化されたIANAレイヤー3プロトコル

From the list of Classification Engine IDs in Table 1, the IANA layer 3 Classification Engine ID (IANA-L3) is 1. From Table 2 the Selector ID length is 1 for the IANA-L3 Engine ID.

表1の分類エンジンIDのリストから、IANAレイヤー3分類エンジンID（IANA-L3）は1です。表2から、IANA-L3エンジンIDのセレクターIDの長さは1です。

From the list of IANA layer 3 protocols (see [IANA-PROTO]), ICMP has the value 1:

IANAレイヤー3プロトコル（[IANA-PROTO]を参照）のリストから、ICMPの値は1です。

Decimal Keyword Protocol Reference 1 ICMP Internet Control [RFC792] Message

Decimal Keyword Protocol Reference 1 ICMP Internet Control [RFC792]メッセージ

So, in the case of the standardized IANA layer 3 protocol ICMP, the Classification Engine ID is 1, and the Selector ID has the value of 1.

したがって、標準化されたIANAレイヤー3プロトコルICMPの場合、分類エンジンIDは1で、セレクターIDの値は1です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       1       |       1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So, the Application ID has the value of 257. The format '1..1' is used for simplicity in the examples below.

したがって、アプリケーションIDの値は257です。以下の例では、簡単にするために「1..1」という形式を使用しています。

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- sourceIPv4Address (key field) - destinationIPv4Address (key field) - ipDiffServCodePoint (key field) - applicationId (key field) - octetTotalCount (non-key field)

- sourceIPv4Address（キーフィールド）-destinationIPv4Address（キーフィールド）-ipDiffServCodePoint（キーフィールド）-applicationId（キーフィールド）-octetTotalCount（非キーフィールド）

For example, a Flow Record corresponding to the above Template Record may contain:

たとえば、上記のテンプレートレコードに対応するフローレコードには以下が含まれます。

       { sourceIPv4Address=192.0.2.1,
         destinationIPv4Address=192.0.2.2,
         ipDiffServCodePoint=0,
         applicationId='1..1',
         octetTotalCount=123456 }

The Collector has all the required information to determine that the application is ICMP, because the Application ID uses a global and well-known registry, i.e., the IANA L3 protocol number.

アプリケーションIDはグローバルで既知のレジストリ、つまりIANA L3プロトコル番号を使用するため、コレクターはアプリケーションがICMPであることを確認するために必要なすべての情報を持っています。

6.3. Example 3: Proprietary Layer 3 Protocol

6.3. 例3：独自のレイヤー3プロトコル

Assume that an enterprise has specified a new layer 3 protocol called "foo".

企業が "foo"と呼ばれる新しいレイヤー3プロトコルを指定したと仮定します。

From the list of Classification Engine IDs in Table 1, the proprietary layer 3 Classification Engine ID (PANA-L3) is 2. From Table 2 the Selector ID length is 1 for the PANA-L3 Engine ID.

表1の分類エンジンIDのリストから、独自のレイヤー3分類エンジンID（PANA-L3）は2です。表2から、PANA-L3エンジンIDのセレクターIDの長さは1です。

A global registry within the enterprise specifies that the "foo" protocol has the value 90:

企業内のグローバルレジストリは、「foo」プロトコルの値が90であることを指定しています。

Protocol Protocol ID foo 90 So, in the case of the layer 3 protocol foo specified by this enterprise, the Classification Engine ID is 2, and the Selector ID has the value of 90.

プロトコルプロトコルID foo 90したがって、このエンタープライズによって指定されたレイヤー3プロトコルfooの場合、分類エンジンIDは2で、セレクターIDの値は90です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       2       |       90      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So the Application ID has the value of 602. The format '2..90' is used for simplicity in the examples below.

したがって、アプリケーションIDの値は602です。以下の例では、簡単にするために「2..90」の形式を使用しています。

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- sourceIPv4Address (key field) - destinationIPv4Address (key field) - ipDiffServCodePoint (key field) - applicationId (key field) - octetTotalCount (non-key field)

For example, a Flow Record corresponding to the above Template Record may contain:

たとえば、上記のテンプレートレコードに対応するフローレコードには以下が含まれます。

       { sourceIPv4Address=192.0.2.1,
         destinationIPv4Address=192.0.2.2,
         ipDiffServCodePoint=0,
         applicationId='2..90',
         octetTotalCount=123456 }

Along with this Flow Record, a new Options Template Record would be exported, as shown in Section 6.8.

セクション6.8に示すように、このフローレコードとともに、新しいオプションテンプレートレコードがエクスポートされます。

6.4. Example 4: Standardized IANA Layer 4 Port

6.4. 例4：標準化されたIANAレイヤー4ポート

From the list of Classification Engine IDs in Table 1, the IANA layer 4 Classification Engine ID (IANA-L4) is 3. From Table 2 the Selector ID length is 2 for the IANA-L4 Engine ID.

表1の分類エンジンIDのリストから、IANAレイヤー4分類エンジンID（IANA-L4）は3です。表2から、IANA-L4エンジンIDのセレクターIDの長さは2です。

From the list of IANA layer 4 ports (see [IANA-PORTS]), SNMP has the value 161: Keyword Decimal Description snmp 161/tcp SNMP snmp 161/udp SNMP

IANAレイヤー4ポートのリスト（[IANA-PORTS]を参照）から、SNMPの値は161：キーワード10進数の説明

So, in the case of the standardized IANA layer 4 SNMP port, the Classification Engine ID is 3, and the Selector ID has the value of 161.

したがって、標準化されたIANAレイヤー4 SNMPポートの場合、分類エンジンIDは3で、セレクターIDの値は161です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       3       |              161              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So the Application ID has the value of 196769. The format '3..161' is used for simplicity in the examples below.

したがって、アプリケーションIDの値は196769です。以下の例では、簡単にするために「3..161」の形式を使用しています。

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- sourceIPv4Address (key field) - destinationIPv4Address (key field) - protocol (key field) - ipDiffServCodePoint (key field) - applicationId (key field) - octetTotalCount (non-key field)

- sourceIPv4Address（キーフィールド）-destinationIPv4Address（キーフィールド）-protocol（キーフィールド）-ipDiffServCodePoint（キーフィールド）-applicationId（キーフィールド）-octetTotalCount（非キーフィールド）

For example, a Flow Record corresponding to the above Template Record may contain:

たとえば、上記のテンプレートレコードに対応するフローレコードには以下が含まれます。

       { sourceIPv4Address=192.0.2.1,
         destinationIPv4Address=192.0.2.2,
         protocol=17, ipDiffServCodePoint=0,
         applicationId='3..161',
         octetTotalCount=123456 }

The Collector has all the required information to determine that the application is SNMP, because the Application ID uses a global and well-known registry, i.e., the IANA L4 protocol number.

アプリケーションIDはグローバルで既知のレジストリ、つまりIANA L4プロトコル番号を使用するため、コレクターはアプリケーションがSNMPであることを確認するために必要なすべての情報を持っています。

6.5. Example 5: Layer 7 Application

6.5. 例5：レイヤー7アプリケーション

In this example, the Metering Process has observed some Webex traffic.

この例では、メータリングプロセスが一部のWebexトラフィックを監視しています。

From the list of Classification Engine IDs in Table 1, the layer 7 unique Classification Engine ID (PANA-L7) is 13. From Table 2 the Selector ID length is 3 for the PANA-L7 Engine ID.

表1の分類エンジンIDのリストから、レイヤー7の一意の分類エンジンID（PANA-L7）は13です。表2から、PANA-L7エンジンIDのセレクターIDの長さは3です。

Suppose that the Metering Process returns the ID 10000 for Webex traffic.

メータリングプロセスがWebexトラフィックのID 10000を返すと仮定します。

So, in the case of this Webex application, the Classification Engine ID is 13 and the Selector ID has the value of 10000.

したがって、このWebexアプリケーションの場合、分類エンジンIDは13で、セレクターIDの値は10000です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      13       |                     10000                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So the Application ID has the value of 218113808. The format '13..10000' is used for simplicity in the examples below.

したがって、アプリケーションIDの値は218113808です。以下の例では、簡単にするために「13..10000」という形式を使用しています。

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- sourceIPv4Address (key field) - destinationIPv4Address (key field) - ipDiffServCodePoint (key field) - applicationId (key field) - octetTotalCount (non-key field)

For example, a Flow Record corresponding to the above Template Record may contain:

たとえば、上記のテンプレートレコードに対応するフローレコードには以下が含まれます。

       { sourceIPv4Address=192.0.2.1,
         destinationIPv4Address=192.0.2.2,
         ipDiffServCodePoint=0,
         applicationId='13..10000',
         octetTotalCount=123456 }

The 10000 value is globally unique for the enterprise, so that the Collector can determine which application is represented by the Application ID by loading the registry out of band.

10000の値は企業全体で一意であるため、コレクターは、レジストリーを帯域外にロードすることにより、アプリケーションIDによって表されるアプリケーションを判別できます。

Along with this Flow Record, a new Options Template Record would be exported, as shown in Section 6.8.

セクション6.8に示すように、このフローレコードとともに、新しいオプションテンプレートレコードがエクスポートされます。

6.6. Example 6: Layer 7 Application with Private Enterprise Number (PEN)

6.6. 例6：プライベートエンタープライズ番号（PEN）を使用したレイヤー7アプリケーション

In this example, the layer 7 Webex traffic from Example 5 above have been classified by enterprise X. The exported records have been received by enterprise Y's mediation device, which wishes to forward them to a top-level Collector.

この例では、上記の例5のレイヤー7 WebexトラフィックがエンタープライズXによって分類されています。エクスポートされたレコードは、トップレベルのコレクターに転送することを希望するエンタープライズYのメディエーションデバイスによって受信されています。

In order for the top-level Collector to know that the records were classified by enterprise X, the enterprise Y mediation device must report the records using the PANA-L7-PEN Classification Engine ID with enterprise X's Private Enterprise Number.

トップレベルのコレクターがレコードがエンタープライズXによって分類されたことを認識するために、エンタープライズYメディエーションデバイスは、PANA-L7-PEN分類エンジンIDとエンタープライズXのプライベートエンタープライズ番号を使用してレコードを報告する必要があります。

The PANA-L7-PEN Classification Engine ID is 20, and enterprise X's Selector ID for Webex traffic has the value of 10000. From Table 2 the Selector ID length is 3 for the PANA-L7-PEN Engine ID.

PANA-L7-PEN分類エンジンIDは20で、WebexトラフィックのエンタープライズXのセレクターIDの値は10000です。表2から、PANA-L7-PENエンジンIDのセレクターIDの長さは3です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      20       |               enterprise ID = X            ...|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |...Ent.ID.contd|                     10000                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format '20..X..10000' is used for simplicity in the examples below.

以下の例では、簡単にするために「20..X..10000」という形式を使用しています。

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- sourceIPv4Address (key field) - destinationIPv4Address (key field) - ipDiffServCodePoint (key field) - applicationId (key field) - octetTotalCount (non-key field)

For example, a Flow Record corresponding to the above Template Record may contain:

たとえば、上記のテンプレートレコードに対応するフローレコードには以下が含まれます。

       { sourceIPv4Address=192.0.2.1,
         destinationIPv4Address=192.0.2.2,
         ipDiffServCodePoint=0,
         applicationId='20..X..10000',
         octetTotalCount=123456 }

The 10000 value is globally unique for enterprise X, so that the Collector can determine which application is represented by the Application ID by loading the registry out of band.

10000の値はエンタープライズXでグローバルに一意であるため、コレクターは、レジストリーを帯域外にロードすることにより、アプリケーションIDによって表されるアプリケーションを判別できます。

Along with this Flow Record, a new Options Template Record would be exported, as shown in Section 6.8.

セクション6.8に示すように、このフローレコードとともに、新しいオプションテンプレートレコードがエクスポートされます。

6.7. Example: Port Obfuscation

6.7. 例：ポートの難読化

For example, an HTTP server might run on a TCP port 23 (assigned to telnet in [IANA-PORTS]). If the Metering Process is capable of detecting HTTP in the same case, the Application ID representation must contain HTTP. However, if the reporting application wants to determine whether or not the default HTTP port 80 or 8080 was used, the transport ports (sourceTransportPort and destinationTransportPort at [IANA-IPFIX]) must also be exported in the corresponding IPFIX record.

たとえば、HTTPサーバーはTCPポート23（[IANA-PORTS]でtelnetに割り当てられている）で実行される場合があります。メータリングプロセスが同じケースでHTTPを検出できる場合、アプリケーションID表現にはHTTPが含まれている必要があります。ただし、レポートアプリケーションがデフォルトのHTTPポート80または8080が使用されたかどうかを判断する場合、トランスポートポート（[IANA-IPFIX]のsourceTransportPortおよびdestinationTransportPort）も対応するIPFIXレコードにエクスポートする必要があります。

In the case of a standardized IANA layer 4 port, the Classification Engine ID (PANA-L4) is 3, and the Selector ID has the value of 80 for HTTP (see [IANA-PORTS]). From Table 2 the Selector ID length is 2 for the PANA-L4 Engine ID.

標準化されたIANAレイヤー4ポートの場合、分類エンジンID（PANA-L4）は3であり、セレクターIDの値はHTTPに対して80です（[IANA-PORTS]を参照）。表2から、PANA-L4エンジンIDのセレクタIDの長さは2です。

Therefore, the Application ID is encoded as:

したがって、アプリケーションIDは次のようにエンコードされます。

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       3       |             80                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Exporting Process creates a Template Record with a few Information Elements: amongst other things, the Application ID. For example:

エクスポートプロセスは、いくつかの情報要素、とりわけアプリケーションIDを含むテンプレートレコードを作成します。例えば：

- sourceIPv4Address (key field) - destinationIPv4Address (key field) - protocol (key field) - destinationTransportPort (key field) - applicationId (key field) - octetTotalCount (non-key field) For example, a Flow Record corresponding to the above Template Record may contain:

-sourceIPv4Address（キーフィールド）-destinationIPv4Address（キーフィールド）-protocol（キーフィールド）-destinationTransportPort（キーフィールド）-applicationId（キーフィールド）-octetTotalCount（非キーフィールド）たとえば、上記のテンプレートレコードに対応するフローレコード含有することができます：

       { sourceIPv4Address=192.0.2.1,
         destinationIPv4Address=192.0.2.2,
         protocol=17,
         destinationTransportPort=23,
         applicationId='3..80',
         octetTotalCount=123456 }

The Collector has all the required information to determine that the application is HTTP, but runs on port 23.

コレクターには、アプリケーションがHTTPであることを判別するために必要なすべての情報がありますが、ポート23で実行されます。

6.8. Example: Application Name Mapping Options Template

6.8. 例：アプリケーション名マッピングオプションテンプレート

Along with the Flow Records shown in the above examples, a new Options Template Record should be exported to express the Application Name and Application Description associated with each Application ID.

上記の例で示したフローレコードに加えて、新しいオプションテンプレートレコードをエクスポートして、各アプリケーションIDに関連付けられたアプリケーション名とアプリケーションの説明を表す必要があります。

The Options Template Record contains the following Information Elements:

オプションテンプレートレコードには、次の情報要素が含まれています。

1. Scope = applicationId.

1. スコープ= applicationId。

From RFC 5101: The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records.

RFC 5101から：オプションテンプレートセットでのみ使用可能なスコープは、データレコード内の報告された情報要素のコンテキストを提供します。

2. applicationName.

2. アプリケーション名。

3. applicationDescription.

3. applicationDescription。

The Options Data Record associated with the examples above would contain, for example:

上記の例に関連付けられているオプションデータレコードには、たとえば次のものが含まれます。

{ scope=applicationId='2..90', applicationName="foo", applicationDescription="The foo protocol",

{scope = applicationId = '2..90'、applicationName = "foo"、applicationDescription = "The foo protocol"、

         scope=applicationId='13..10000',
         applicationName="webex",
         applicationDescription="Webex application" }

         scope=applicationId='20..X..10000',
         applicationName="webex",
         applicationDescription="Webex application" }

When combined with the example Flow Records above, these Options Template Records tell the Collector:

上記のフローレコードの例と組み合わせると、これらのオプションテンプレートレコードはコレクタに通知します。

1. A flow of 123456 bytes exists from sourceIPv4Address 192.0.2.1 to destinationIPv4address 192.0.2.2 with an applicationId of '12..90', which maps to the "foo" application.

1. 123IPvバイトのフローは、sourcefoo4Address 192.0.2.1からdestinationIPv4address 192.0.2.2に存在し、applicationIdは「12..90」であり、これは「foo」アプリケーションにマップされます。

2. A flow of 123456 bytes exists from sourceIPv4Address 192.0.2.1 to destinationIPv4address 192.0.2.2 with an Application ID of '13..10000', which maps to the "Webex" application.

2. 123456バイトのフローは、「Webex」アプリケーションにマップする「13..10000」のアプリケーションIDを持つsourceIPv4Address 192.0.2.1からdestinationIPv4address 192.0.2.2まで存在します。

3. A flow of 123456 bytes exists from sourceIPv4Address 192.0.2.1 to destinationIPv4address 192.0.2.2 with an Application ID of '20..PEN..10000', which maps to the "Webex" application, according to the application registry from the enterprise X.

3. エンタープライズXからのアプリケーションレジストリによると、「Webex」アプリケーションにマップするアプリケーションID「20..PEN..10000」を持つsourceIPv4Address 192.0.2.1からdestinationIPv4address 192.0.2.2への123456バイトのフローが存在します。

6.9. Example: Attributes Values Options Template Record

6.9. 例：属性値オプションテンプレートレコード

Along with the Flow Records shown in the above examples, a new Options Template Record is exported to express the values of the different attributes related to the Application IDs.

上記の例で示したフローレコードに加えて、新しいオプションテンプレートレコードがエクスポートされ、アプリケーションIDに関連するさまざまな属性の値が表現されます。

The Options Template Record would contain the following Information Elements:

オプションテンプレートレコードには、次の情報要素が含まれます。

1. Scope = applicationId.

1. スコープ= applicationId。

From RFC 5101: The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records.

RFC 5101から：オプションテンプレートセットでのみ使用可能なスコープは、データレコード内の報告された情報要素のコンテキストを提供します。

2. applicationCategoryName.

2. applicationCategoryName。

3. applicationSubCategoryName.

3. applicationSubCategoryName。

4. applicationGroupName

5. p2pTechnology

6. tunnelTechnology

6. トンネル技術

7. encryptedTechnology The Options Data Record associated with the examples above would contain, for example:

7. encryptedTechnology上記の例に関連付けられたオプションデータレコードには、たとえば以下が含まれます。

       { scope=applicationId='2..90',
         applicationCategoryName="foo-category",
         applicationSubCategoryName="foo-subcategory",
         applicationGroupName="foo-group",
         p2pTechnology=NO
         tunnelTechnology=YES
         encryptedTechnology=NO

When combined with the example Flow Records above, these Options Template Records tell the Collector:

上記のフローレコードの例と組み合わせると、これらのオプションテンプレートレコードはコレクタに通知します。

A flow of 123456 bytes exists from sourceIPv4Address 192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP value of 0 and an applicationId of '12..90', which maps to the "foo" application. This application can be characterized by the relevant attributes values.

123456バイトのフローが存在し、sourceIPv4Address 192.0.2.1からdestinationIPv4address 192.0.2.2まで、DSCP値は0、applicationIdは「12..90」で、「foo」アプリケーションにマッピングされます。このアプリケーションは、関連する属性値によって特徴付けることができます。

7. IANA Considerations

7. IANAに関する考慮事項

7.1. New Information Elements

7.1. 新しい情報要素

This document specifies 10 new IPFIX Information Elements: applicationDescription, applicationId, applicationName, classificationEngineId, applicationCategoryName, applicationSubCategoryName, applicationGroupName, p2pTechnology, tunnelTechnology, and encryptedTechnology.

このドキュメントは、10の新しいIPFIX情報要素を指定します：applicationDescription、applicationId、applicationName、classificationEngineId、applicationCategoryName、applicationSubCategoryName、applicationGroupName、p2pTechnology、tunnelTechnology、およびencryptedTechnology。

The new Information Elements listed below have been added to the IPFIX Information Element registry at [IANA-IPFIX].

以下にリストされている新しい情報要素が、[IANA-IPFIX]のIPFIX情報要素レジストリに追加されました。

7.1.1. applicationDescription

Name: applicationDescription Description: Specifies the description of an application. Abstract Data Type: string Data Type Semantics: ElementId: 94 Status: current

名前：applicationDescription Description：アプリケーションの説明を指定します。抽象データ型：文字列データ型セマンティクス：ElementId：94ステータス：現在

7.1.2. applicationId

7.1.2. アプリケーションID

Name: applicationId Description: Specifies an Application ID. Abstract Data Type: octetArray Data Type Semantics: identifier Reference: See Section 4 of [RFC6759] for the applicationId Information Element Specification. ElementId: 95 Status: current

名前：applicationId説明：アプリケーションIDを指定します。抽象データタイプ：octetArrayデータタイプセマンティクス：識別子リファレンス：applicationId情報要素の仕様については、[RFC6759]のセクション4を参照してください。 ElementId：95ステータス：現在

7.1.3. applicationName

7.1.3. アプリケーション名

Name: applicationName Description: Specifies the name of an application. Abstract Data Type: string Data Type Semantics: ElementId: 96 Status: current

名前：applicationName説明：アプリケーションの名前を指定します。抽象データ型：文字列データ型セマンティクス：ElementId：96ステータス：現在

7.1.4. classificationEngineId

7.1.4. ClassificationEngineId

Name: classificationEngineId Description: A unique identifier for the engine that determined the Selector ID. Thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered as a specific registry for application assignments.

名前：ClassificationEngineId説明：セレクターIDを決定したエンジンの一意の識別子。したがって、分類エンジンIDはセレクタIDのコンテキストを定義します。分類エンジンは、アプリケーション割り当ての特定のレジストリと見なすことができます。

Initial values for this field are listed below. Further values may be assigned by IANA in the Classification Engine IDs registry per Section 7.2.

このフィールドの初期値は次のとおりです。セクション7.2に従って、分類エンジンIDレジストリでIANAによってさらに値が割り当てられる場合があります。

0 Invalid.

0無効。

1 IANA-L3: The Assigned Internet Protocol Number (layer 3 (L3)) is exported in the Selector ID. See http://www.iana.org/assignments/protocol-numbers.

1 IANA-L3：割り当てられたインターネットプロトコル番号（レイヤー3（L3））は、セレクターIDでエクスポートされます。 http://www.iana.org/assignments/protocol-numbersを参照してください。

2 PANA-L3: Proprietary layer 3 definition. An enterprise can export its own layer 3 protocol numbers. The Selector ID has a global significance for all devices from the same enterprise.

2 PANA-L3：独自のレイヤー3定義。企業は独自のレイヤー3プロトコル番号をエクスポートできます。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。

3 IANA-L4: The IANA layer 4 (L4) well-known port number is exported in the Selector ID. See [IANA-PORTS]. Note: as an IPFIX flow is unidirectional, it contains the destination port.

3 IANA-L4：IANAレイヤー4（L4）ウェルノウンポート番号がセレクターIDでエクスポートされます。 [IANA-PORTS]を参照してください。注：IPFIXフローは単方向であるため、宛先ポートが含まれます。

4 PANA-L4: Proprietary layer 4 definition. An enterprise can export its own layer 4 port numbers. The Selector ID has global significance for devices from the same enterprise. Example: IPFIX was pre-assigned port 4739 using the IANA early allocation process [RFC4020] years before the document was published as an RFC. While waiting for the RFC and it associated IANA registration, Selector ID 4739 was used with this PANA-L4.

4 PANA-L4：独自のレイヤー4定義。企業は、独自のレイヤー4ポート番号をエクスポートできます。セレクタIDは、同じ企業のデバイスに対してグローバルに重要です。例：IPFIXは、ドキュメントがRFCとして公開される何年も前に、IANA早期割り当てプロセス[RFC4020]を使用してポート4739が事前に割り当てられていました。 RFCとそれがIANA登録に関連付けられるのを待つ間、このPANA-L4でセレクタID 4739が使用されました。

5 Reserved

5予約済み

6 USER-Defined: The Selector ID represents applications defined by the user (using CLI, GUI, etc.) based on the methods described in Section 2. The Selector ID has a local significance per device.

6ユーザー定義：セレクタIDは、セクション2で説明した方法に基づいて（CLI、GUIなどを使用して）ユーザーが定義したアプリケーションを表します。セレクタIDは、デバイスごとにローカルで重要です。

7 Reserved

7予約済み

8 Reserved

8予約済み

9 Reserved

9予約済み

10 Reserved

10予約済み

11 Reserved

11予約済み

12 PANA-L2: Proprietary layer 2 (L2) definition. An enterprise can export its own layer 2 identifiers. The Selector ID represents the enterprise's unique global layer 2 applications. The Selector ID has a global significance for all devices from the same enterprise. Examples include the Cisco Subnetwork Access Protocol (SNAP).

12 PANA-L2：独自のレイヤー2（L2）定義。企業は独自のレイヤー2識別子をエクスポートできます。セレクタIDは、企業固有のグローバルレイヤー2アプリケーションを表します。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。例としては、Cisco Subnetwork Access Protocol（SNAP）があります。

13 PANA-L7: Proprietary layer 7 definition. The Selector ID represents the enterprise's unique global ID for layer 7 applications. The Selector ID has a global significance for all devices from the same enterprise. This Classification Engine ID is used when the application registry is owned by the Exporter manufacturer (referred to as the "enterprise" in this document).

13 PANA-L7：独自のレイヤー7定義。セレクターIDは、レイヤー7アプリケーションに対する企業固有のグローバルIDを表します。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。この分類エンジンIDは、アプリケーションレジストリがエクスポーターの製造元（このドキュメントでは「エンタープライズ」と呼ばれます）によって所有されている場合に使用されます。

14 Reserved

14予約済み

15 Reserved

15予約済み

16 Reserved

16予約済み

17 Reserved

17予約済み

18 ETHERTYPE: The Selector ID represents the well-known Ethertype. See [ETHERTYPE].

18 ETHERTYPE：セレクタIDは、既知のEthertypeを表します。 [ETHERTYPE]を参照してください。

19 LLC: The Selector ID represents the well-known IEEE 802.2 Link Layer Control (LLC) Destination Service Access Point (DSAP). See [LLC].

19 LLC：セレクタIDは、よく知られているIEEE 802.2リンク層制御（LLC）宛先サービスアクセスポイント（DSAP）を表します。 [LLC]を参照してください。

20 PANA-L7-PEN: Proprietary layer 7 definition, including a Private Enterprise Number (PEN) [IANA-PEN] to identify that the application registry being used is not owned by the Exporter manufacturer or to identify the original enterprise in the case of a mediator or 3rd party device. The Selector ID represents the enterprise unique global ID for layer 7 applications. The Selector ID has a global significance for all devices from the same enterprise.

20 PANA-L7-PEN：使用されているアプリケーションレジストリが輸出業者の製造元によって所有されていないことを識別するため、または、メディエーターまたはサードパーティのデバイス。セレクターIDは、レイヤー7アプリケーションのエンタープライズ固有のグローバルIDを表します。セレクタIDは、同じ企業のすべてのデバイスに対してグローバルに重要です。

Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), are reserved to be compliant with existing implementations already using the classificationEngineId.

一部の値（5、7、8、9、10、11、14、15、16、17）は、すでに分類エンジンIDを使用している既存の実装に準拠するために予約されています。

Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 101 Status: current

抽象データ型：unsigned8データ型セマンティクス：識別子ElementId：101ステータス：現在

7.1.5. applicationCategoryName

Name: applicationCategoryName Description: An attribute that provides a first-level categorization for each Application Id. Abstract Data Type: string Data Type Semantics: ElementId: 372 Status: current

名前：applicationCategoryName説明：各アプリケーションIDの第1レベルの分類を提供する属性。抽象データ型：文字列データ型セマンティクス：ElementId：372ステータス：現在

7.1.6. applicationSubCategoryName

Name: applicationSubCategoryName Description: An attribute that provides a second-level categorization for each Application Id. Abstract Data Type: string Data Type Semantics: ElementId: 373 Status: current

名前：applicationSubCategoryName説明：各アプリケーションIDの第2レベルの分類を提供する属性。抽象データ型：文字列データ型セマンティクス：ElementId：373ステータス：現在

7.1.7. applicationGroupName

Name: applicationGroupName Description: An attribute that groups multiple Application IDs that belong to the same networking application. Abstract Data Type: string Data Type Semantics: ElementId: 374 Status: current

名前：applicationGroupName説明：同じネットワークアプリケーションに属する複数のアプリケーションIDをグループ化する属性。抽象データ型：文字列データ型セマンティクス：ElementId：374ステータス：現在

7.1.8. p2pTechnology

   Name: p2pTechnology
   Description:
    Specifies if the Application ID is based on peer-to-peer
    technology.  Possible values are { "yes", "y", 1 },
    { "no", "n", 2 }, and { "unassigned", "u", 0 }.
   Abstract Data Type: string
   Data Type Semantics:
   ElementId: 288
   Status: current

7.1.9. tunnelTechnology

7.1.9. トンネル技術

   Name: tunnelTechnology
   Description:
     Specifies if the Application ID is used as a tunnel technology.
     Possible values are { "yes", "y", 1 }, { "no", "n", 2 },
     and { "unassigned", "u", 0 }.
   Abstract Data Type: string
   Data Type Semantics:
   ElementId: 289
   Status: current

7.1.10. encryptedTechnology

7.1.10. 暗号化されたテクノロジー

   Name: encryptedTechnology
   Description:
    Specifies if the Application ID is an encrypted networking
    protocol.  Possible values are { "yes", "y", 1 },
    { "no", "n", 2 }, and { "unassigned", "u", 0 }.
   Abstract Data Type: string
   Data Type Semantics:
   ElementId: 290
   Status: current

7.2. Classification Engine ID Registry

7.2. 分類エンジンIDレジストリ

The Information Element #101, named classificationEngineId, carries information about the context for the Selector ID, and can be considered as a specific registry for application assignments. For ensuring extensibility of this information, IANA has created a new registry for Classification Engine IDs and filled it with the initial list from the description Information Element #101, classificationEngineId, along with their respective default lengths (Table 2 in this document).

ClassificationEngineIdという名前の情報要素＃101は、セレクターIDのコンテキストに関する情報を保持し、アプリケーション割り当ての特定のレジストリーと見なすことができます。この情報の拡張性を確保するために、IANAは分類エンジンIDの新しいレジストリを作成し、説明の情報要素＃101、classificationEngineIdからの初期リストと、それぞれのデフォルトの長さ（このドキュメントの表2）を入力しました。

New assignments for Classification Engine IDs will be 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 new definitions with already defined Classification Engine IDs for completeness, accuracy, and redundancy. The specification of Classification Engine IDs MUST be published using a well-established and persistent publication medium.

分類エンジンIDの新しい割り当ては、専門家レビュー[RFC5226]を通じてIANAによって管理されます。つまり、IETFエリアディレクターによって指定された専門家グループの1人によるレビューです。専門家グループは、完全性、正確性、および冗長性について、定義済みの分類エンジンIDを使用して新しい定義を再確認する必要があります。分類エンジンIDの仕様は、確立された永続的な公開媒体を使用して公開する必要があります。

8. Security Considerations

8. セキュリティに関する考慮事項

The same security considerations as for the IPFIX protocol [RFC5101] apply. The IPFIX extension specified in this memo allows to identify what applications are used on the network. Consequently, it is possible to identify what applications are being used by the users, potentially threatening the privacy of those users, if not handled with great care.

IPFIXプロトコル[RFC5101]と同じセキュリティの考慮事項が適用されます。このメモで指定されているIPFIX拡張機能により、ネットワークで使用されているアプリケーションを識別できます。その結果、ユーザーが使用しているアプリケーションを特定することが可能になり、慎重に扱わないと、ユーザーのプライバシーが脅かされる可能性があります。

As mentioned in Section 1.1, the application knowledge is useful in security based applications. Security applications may impose supplementary requirements on the export of application information, and these need to be examined on a case by case basis.

セクション1.1で述べたように、アプリケーションの知識はセキュリティベースのアプリケーションで役立ちます。セキュリティアプリケーションは、アプリケーション情報のエクスポートに補足要件を課す場合があり、これらはケースバイケースで検討する必要があります。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[ETHERTYPE] IEEE, <http://standards.ieee.org/develop/regauth/ ethertype/eth.txt>.

[ETHERTYPE] IEEE、<http://standards.ieee.org/develop/regauth/ethertype/eth.txt>。

[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>。

[IANA-PORTS] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/port-numbers>.

[IANA-PORTS] IANA、「サービス名とトランスポートプロトコルのポート番号レジストリ」、<http://www.iana.org/assignments/port-numbers>。

[IANA-PROTO] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.

[IANA-PROTO] IANA、「プロトコル番号」、<http://www.iana.org/assignments/protocol-numbers>。

[LLC] IEEE, "LOGICAL LINK CONTROL (LLC) PUBLIC LISTING", <http://standards.ieee.org /develop/regauth/llc /public.html>.

[LLC] IEEE、「LOGICAL LINK CONTROL（LLC）PUBLIC LISTING」、<http://standards.ieee.org / develop / regauth / llc /public.html>。

[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月。

[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月。

[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月。

9.2. Informative References

9.2. 参考引用

[CISCO-APPLICATION-REGISTRY] Cisco, "Application Registry", <http://www.cisco.com/go/application_registry>.

[CISCO-APPLICATION-REGISTRY]シスコ、「アプリケーションレジストリ」、<http://www.cisco.com/go/application_registry>。

[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>。

[LLDP] IEEE, Std 802.1AB-2005, "Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2005 IEEE Std, 2005.

[LLDP] IEEE、Std 802.1AB-2005、「Local and Metropolitan Area Network-Station and Media Access Control Connectivity Discovery」、IEEE Std 802.1AB-2005 IEEE Std、2005。

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。

[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月。

[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.

[RFC4020] Kompella、K。およびA. Zinin、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 4020、2005年2月。

[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月。

[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月。

[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月。

[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.

[RFC5476] Claise、B.、Ed。、Johnson、A。、およびJ. Quittek、「Packet Sampling（PSAMP）Protocol Specifications」、RFC 5476、2009年3月。

[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.

[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F。、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。

[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.

[RFC5353] Xie、Q.、Stewart、R.、Stillman、M.、Tuexen、M。、およびA. Silverton、「Endpoint Handlespace Redundancy Protocol（ENRP）」、RFC 5353、2008年9月。

[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, March 2010.

[RFC5811] Hadi Salim、J。およびK. Ogawa、「Forwarding and Control Element Separation（ForCES）ProtocolのSCTPベースのトランスポートマッピングレイヤー（TML）」、RFC 5811、2010年3月。

[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月。

[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月。

10. Acknowledgements

10. 謝辞

The authors would like to thank their many colleagues across Cisco Systems who made this work possible. Specifically, Patrick Wildi for his time and expertise.

著者は、この作業を可能にしたシスコシステムズの多くの同僚に感謝します。具体的には、彼の時間と専門知識を提供するPatrick Wildi。

Appendix A. Additions to XML Specification of IPFIX Information Elements (Non-normative)

付録A. IPFIX情報要素のXML仕様への追加（非規範的）

This appendix contains additions to the machine-readable description of the IPFIX information model coded in XML in Appendix A and Appendix B in [RFC5102]. Note that this appendix is of informational nature, while the text in Section 7 (generated from this appendix) is normative.

この付録には、付録AのXMLおよび[RFC5102]の付録BでコーディングされたIPFIX情報モデルの機械可読な説明への追加が含まれています。この付録は情報提供を目的としていますが、セクション7のテキスト（この付録から生成）は規範的であることに注意してください。

The following field definitions are appended to the IPFIX information model in Appendix A of [RFC5102].

次のフィールド定義は、[RFC5102]の付録AのIPFIX情報モデルに追加されています。

     <field name="applicationDescription"
            dataType="string"
            group="application"
            elementId="94" applicability="all"
   status="current">
       <description>
         <paragraph>
            Specifies the description of an application.
         </paragraph>
       </description>
     </field>

     <field name="applicationId"
            dataType="octetArray"
            group="application"
            dataTypeSemantics="identifier"
            elementId="95" applicability="all"
   status="current">
       <description>
         <paragraph>
            Specifies an Application ID.
         </paragraph>
       </description>
       <reference>
         <paragraph>
            See Section 4 of [RFC6759]
           for the applicationId Information Element
           Specification.
         </paragraph>
       </reference>
     </field>

     <field name="applicationName"
            dataType="string"
            group="application"
            elementId="96" applicability="all"

   status="current">
       <description>
         <paragraph>
            Specifies the name of an application.
         </paragraph>
       </description>
     </field>

<field name="classificationEngineId" dataType="unsigned8" group="application" dataTypeSemantics="identifier" elementId="101" applicability="all" status="current"> <description> <paragraph> 0 Invalid.

<field name = "classificationEngineId" dataType = "unsigned8" group = "application" dataTypeSemantics = "identifier" elementId = "101" applicability = "all" status = "current"> <description> <paragraph> 0無効です。

1 IANA-L3: The Assigned Internet Protocol Number (layer 3 (L3)) is exported in the Selector ID. See http://www.iana.org/assignments/protocol-numbers.

2 PANA-L3: Proprietary layer 3 definition. An enterprise can export its own layer 3 protocol numbers. The Selector ID has a global significance for all devices from the same enterprise.

3 IANA-L4: The IANA layer 4 (L4) well-known port number is exported in the Selector ID. See [IANA-PORTS]. Note: as an IPFIX flow is unidirectional, it contains the destination port.

4 PANA-L4: Proprietary layer 4 definition. An enterprise can export its own layer 4 port numbers. The Selector ID has global significance for devices from the same enterprise. Example: IPFIX was pre-assigned port 4739 using the IANA early allocation process [RFC4020] years before the document was published as an RFC. While waiting for the RFC and its associated IANA registration, Selector ID 4739 was used with this PANA-L4.

4 PANA-L4：独自のレイヤー4定義。企業は、独自のレイヤー4ポート番号をエクスポートできます。セレクタIDは、同じ企業のデバイスに対してグローバルに重要です。例：IPFIXは、ドキュメントがRFCとして公開される何年も前に、IANA早期割り当てプロセス[RFC4020]を使用してポート4739が事前に割り当てられていました。 RFCとそれに関連するIANA登録を待機している間、このPANA-L4でセレクタID 4739が使用されました。

5 Reserved 6 USER-Defined: The Selector ID represents applications defined by the user (using CLI, GUI, etc.) based on the methods described in Section 2. The Selector ID has a local significance per device.

5予約済み6ユーザー定義：セレクターIDは、セクション2で説明した方法に基づいてユーザーが（CLI、GUIなどを使用して）定義したアプリケーションを表します。セレクターIDは、デバイスごとにローカルで重要です。

7 Reserved

7予約済み

8 Reserved

8予約済み

9 Reserved

9予約済み

10 Reserved

10予約済み

11 Reserved

11予約済み

14 Reserved

14予約済み

15 Reserved

15予約済み

16 Reserved

16予約済み

17 Reserved

17予約済み

18 ETHERTYPE: The Selector ID represents the well-known Ethertype. See [ETHERTYPE].

18 ETHERTYPE：セレクタIDは、既知のEthertypeを表します。 [ETHERTYPE]を参照してください。

19 LLC: The Selector ID represents the well-known IEEE 802.2 Link Layer Control (LLC) Destination Service Access Point (DSAP). See [LLC].

19 LLC：セレクタIDは、よく知られているIEEE 802.2リンク層制御（LLC）宛先サービスアクセスポイント（DSAP）を表します。 [LLC]を参照してください。

     <field name="applicationCategoryName"
            dataType="string"
            group="application"
            elementId="372"
            applicability="all"
            status="current">
       <description>
         <paragraph>
            An attribute that provides a first-level categorization
            for each Application Id.
         </paragraph>
       </description>
     </field>

     <field name="applicationSubCategoryName"
            dataType="string"
            group="application"
            elementId="373"
            applicability="all"
            status="current">
       <description>
         <paragraph>
            An attribute that provides a second-level
            categorization for each Application ID.
         </paragraph>
       </description>
     </field>

     <field name="applicationGroupName"
            dataType="string"
            group="application"
            elementId="374"
            applicability="all"
            status="current">
       <description>
         <paragraph>
            An attribute that groups multiple Application IDs
            that belong to the same networking application.
         </paragraph>
       </description>
     </field>

     <field name="p2pTechnology"
            dataType="string"
            group="application"
            elementId="288"
            applicability="all"
            status="current">
       <description>
         <paragraph>
            Specifies if the Application ID is based on peer-
            to-peer technology.  Possible values are
            { "yes", "y", 1 }, { "no", "n", 2 }, and
            { "unassigned", "u", 0 }.
         </paragraph>
       </description>
     </field>

     <field name="tunnelTechnology"
            dataType="string"
            group="application"
            elementId="289"
            applicability="all"
            status="current">
       <description>
         <paragraph>
            Specifies if the Application ID is used as a
            tunnel technology.  Possible values are
            { "yes", "y", 1 }, { "no", "n", 2 }, and
            { "unassigned", "u", 0 }.
         </paragraph>
       </description>
     </field>

     <field name="encryptedTechnology"
            dataType="string"
            group="application"
            elementId="290"
            applicability="all"
            status="current">
       <description>
         <paragraph>
            Specifies if the Application ID is an encrypted
            networking protocol.  Possible values are
            { "yes", "y", 1 }, { "no", "n", 2 }, and
            { "unassigned", "u", 0 }.
         </paragraph>
       </description>
     </field>

Appendix B. Port Collisions Tables (Non-normative)

付録B.ポートコリジョンテーブル（非規範的）

The following table lists the 10 ports that have different protocols assigned for TCP and UDP (at the time of writing this document):

次の表は、TCPとUDPに異なるプロトコルが割り当てられている10個のポートの一覧です（このドキュメントの執筆時点）。

exec 512/tcp remote process execution; authentication performed using passwords and UNIX login names

exec 512 / tcpリモートプロセス実行。パスワードとUNIXログイン名を使用して実行される認証

comsat/biff 512/udp used by mail system to notify users of new mail received; currently receives messages only from processes on the same machine

comsat / biff 512 / udpは、メールシステムが受信した新着メールをユーザーに通知するために使用されます。現在、同じマシン上のプロセスからのみメッセージを受信します

login 513/tcp remote login a la telnet; automatic authentication performed based on priviledged [sic] port numbers and distributed data bases which identify "authentication domains"

ログイン513 / tcp telnetによるリモートログイン。特権[sic]ポート番号と「認証ドメイン」を識別する分散データベースに基づいて実行される自動認証

who 513/udp maintains data bases showing who's logged in to machines on a local net and the load average of the machine

who 513 / udpは、ローカルネット上のマシンに誰がログインしているか、マシンの平均負荷を示すデータベースを管理しています。

shell 514/tcp cmd like exec, but automatic authentication is performed as for login server

execのようなシェル514 / tcp cmd、ただしログインサーバーの場合と同様に自動認証が実行されます

syslog 514/udp

syslog 514 / udp

oob-ws-https 664/tcp DMTF out-of-band secure web services management protocol Jim Davis <jim.davis@wbemsolutions.com>

oob-ws-https 664 / tcp DMTF帯域外セキュアWebサービス管理プロトコルJim Davis <jim.davis@wbemsolutions.com>

asf-secure-rmcp 664/udp ASF Secure Remote Management and Control Protocol

asf-secure-rmcp 664 / udp ASFセキュアリモート管理および制御プロトコル

rfile 750/tcp kerberos-iv 750/udp kerberos version iv

rfile 750 / tcp kerberos-iv 750 / udp kerberosバージョンiv

submit 773/tcp notify 773/udp

773 / tcpを送信773 / udpに通知

rpasswd 774/tcp acmaint_dbd 774/udp

rpasswd 774 / tcp acmaint_dbd 774 / udp

entomb 775/tcp acmaint_transd 775/udp

entomb 775 / tcp acmaint_transd 775 / udp

busboy 998/tcp puparp 998/udp

busboy 998 / tcp puparp 998 / udp

garcon 999/tcp applix 999/udp Applix ac

garcon 999 / tcp applix 999 / udp Applix ac

Table 4: Different Protocols on UDP and TCP

表4：UDPとTCPの異なるプロトコル

The following table lists the 19 ports that have different protocols assigned for TCP and SCTP (at the time of writing this document):

次の表に、TCPとSCTPに異なるプロトコルが割り当てられている19個のポートを示します（このドキュメントの執筆時点）。

# 3097/tcp Reserved

       itu-bicc-stc    3097/sctp   ITU-T Q.1902.1/Q.2150.3
                                   Greg Sidebottom
                                   <gregside@home.com>

       #               5090/tcp    <not assigned>

car 5090/sctp Candidate AR

車5090 / sctp候補AR

       #               5091/tcp    <not assigned>

cxtp 5091/sctp Context Transfer Protocol

cxtp 5091 / sctpコンテキスト転送プロトコル

# 6704/tcp Reserved

＃6704 / tcp予約済み

frc-hp 6704/sctp ForCES HP (High Priority) channel [RFC5811]

frc-hp 6704 / sctp ForCES HP（高優先度）チャネル[RFC5811]

# 6705/tcp Reserved

＃6705 / tcp予約済み

frc-mp 6705/sctp ForCES MP (Medium Priority) channel [RFC5811]

frc-mp 6705 / sctp ForCES MP（中優先度）チャネル[RFC5811]

# 6706/tcp Reserved

＃6706 / tcp予約済み

frc-lp 6706/sctp ForCES LP (Low Priority) channel [RFC5811]

frc-lp 6706 / sctp ForCES LP（低優先度）チャネル[RFC5811]

       #               9082/tcp    <not assigned>

lcs-ap 9082/sctp LCS Application Protocol Kimmo Kymalainen <kimmo.kymalainen@etsi.org>

lcs-ap 9082 / sctp LCSアプリケーションプロトコルKimmo Kymalainen <kimmo.kymalainen@etsi.org>

       #               9902/tcp    <not assigned>

enrp-sctp-tls 9902/sctp enrp/tls server channel [RFC5353]

enrp-sctp-tls 9902 / sctp enrp / tlsサーバーチャネル[RFC5353]

       #               11997/tcp   <not assigned>
       #               11998/tcp   <not assigned>
       #               11999/tcp   <not assigned>

wmereceiving 11997/sctp WorldMailExpress wmedistribution 11998/sctp WorldMailExpress wmereporting 11999/sctp WorldMailExpress Greg Foutz <gregf@adminovation.com>

wmereceive 11997 / sctp WorldMailExpress wmedistribution 11998 / sctp WorldMailExpress wmereporting 11999 / sctp WorldMailExpress Greg Foutz <gregf@adminovation.com>

       #               25471/tcp   <not assigned>

rna 25471/sctp RNSAP User Adaptation for Iurh Dario S. Tonesi <dario.tonesi@nsn.com> 07 February 2011

rna 25471 / sctp Iurh Dario S. Tonesi <dario.tonesi@nsn.com>のRNSAPユーザー適応2011年2月7日

# 29118/tcp Reserved

＃29118 / tcp予約済み

sgsap 29118/sctp SGsAP in 3GPP

sgsap 29118 / 3GPPのsctp SGsAP

# 29168/tcp Reserved

＃29168 / tcp予約済み

sbcap 29168/sctp SBcAP in 3GPP

3GPPのsbcap 29168 / sctp SBcAP

       #               29169/tcp   <not assigned>

iuhsctpassoc 29169/sctp HNBAP and RUA Common Association John Meredith <John.Meredith@etsi.org> 08 September 2009

iuhsctpassoc 29169 / sctp HNBAPおよびRUA Common Association John Meredith <John.Meredith@etsi.org> 2009年9月8日

       #               36412/tcp   <not assigned>

s1-control 36412/sctp S1-Control Plane (3GPP) Kimmo Kymalainen <kimmo.kymalainen@etsi.org> 01 September 2009

s1-control 36412 / sctp S1-Control Plane（3GPP）Kimmo Kymalainen <kimmo.kymalainen@etsi.org> 2009年9月1日

       #               36422/tcp   <not assigned>

x2-control 36422/sctp X2-Control Plane (3GPP) Kimmo Kymalainen <kimmo.kymalainen@etsi.org> 01 September 2009

x2-control 36422 / sctp X2-Control Plane（3GPP）Kimmo Kymalainen <kimmo.kymalainen@etsi.org> 2009年9月1日

       #               36443/tcp   <not assigned>

m2ap 36443/sctp M2 Application Part Dario S. Tonesi <dario.tonesi@nsn.com> 07 February 2011

m2ap 36443 / sctp M2アプリケーションパートDario S. Tonesi <dario.tonesi@nsn.com> 2011年2月7日

       #               36444/tcp   <not assigned>

m3ap 36444/sctp M3 Application Part Dario S. Tonesi <dario.tonesi@nsn.com> 07 February 2011

m3ap 36444 / sctp M3アプリケーションパートDario S. Tonesi <dario.tonesi@nsn.com> 2011年2月7日

Table 5: Different Protocols on SCTP and TCP

表5：SCTPとTCPの異なるプロトコル

Appendix C. Application Registry Example (Non-normative)

付録C.アプリケーションレジストリの例（非規範的）

A reference to the Cisco Systems assigned numbers for the Application ID and the different attribute assignments can be found at [CISCO-APPLICATION-REGISTRY].

シスコシステムズが割り当てたアプリケーションIDの番号とさまざまな属性の割り当ての参照は、[CISCO-APPLICATION-REGISTRY]にあります。

Authors' Addresses

著者のアドレス

Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium

Benoit Claise Cisco Systems、Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium

   Phone: +32 2 704 5622
   EMail: bclaise@cisco.com

Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX United Kingdom

Paul Aitken Cisco Systems、Inc. 96 Commercial Quay Commercial Street Edinburgh、EH6 6LX United Kingdom

   Phone: +44 131 561 3616
   EMail: paitken@cisco.com

Nir Ben-Dvora Cisco Systems, Inc. 32 HaMelacha St., P.O. Box 8735, I.Z.Sapir South Netanya, 42504 Israel

にｒべんーＤゔぉらしｓこＳｙｓてｍｓ、いんｃ。３２はめぁちゃＳｔ。、Ｐ。お。ぼｘ８７３５、い。…さぴｒそうｔｈねたにゃ、４２５０４いｓらえｌ

   Phone: +972 9 892 7187
   EMail: nirbd@cisco.com