Network Working Group J. Schoenwaelder
Request for Comments: 5345 Jacobs University Bremen
Category: Informational October 2008
Simple Network Management Protocol (SNMP)
Traffic Measurements and Trace Exchange Formats
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESG注意
The IESG thinks that this work is related to IETF work done in the Operations and Management Area related to SNMP, but this does not prevent publishing. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from the IETF Last Call on the allocation of a URI by IANA and the IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
IESGは、この作業はSNMPに関連する運用と管理領域で行わIETF仕事に関連していると思うが、これは公開を防ぐことはできません。このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開するための決定はIANAによってURIの割り当てやIETF仕事との競合のためにIESGのレビューに離れIETFラストコールからIETFレビューに基づいていないことを指摘します。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、RFC 3932を参照してください。
Abstract
抽象
The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
SNMP（Simple Network Management Protocol）は広く（時には）ネットワーク要素を設定し、制御を監視するために展開され、されています。 SNMP技術は十分に文書化されていても、それはSNMPは、実際に使用され、典型的なSNMPの使用パターンがどのようなものか、比較的不明なままです。
This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.
この文書では、SNMPは、実世界の生産ネットワークでどのように使用されるかのより良い理解を開発するために大規模なSNMPトラフィック測定を行うためのアプローチについて説明します。それはモチベーション、測定アプローチ、および、そのような研究を行うために必要なツールやデータ形式を説明しています。
This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group.
この文書では、IRTFのネットワーク管理研究グループ（NMRG）内で生産し、それがこのグループにアクティブな貢献者のすべての合意を表しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Measurement Approach ............................................4
2.1. Capturing Traffic Traces ...................................5
2.2. Converting Traffic Traces ..................................6
2.3. Filtering Traffic Traces ...................................7
2.4. Storing Traffic Traces .....................................7
2.5. Analyzing Traffic Traces ...................................8
3. Analysis of Traffic Traces ......................................9
3.1. Basic Statistics ...........................................9
3.2. Periodic versus Aperiodic Traffic ..........................9
3.3. Message Size and Latency Distributions .....................9
3.4. Concurrency Levels ........................................10
3.5. Table Retrieval Approaches ................................10
3.6. Trap-Directed Polling - Myths or Reality? .................10
3.7. Popular MIB Definitions ...................................11
3.8. Usage of Obsolete Objects .................................11
3.9. Encoding Length Distributions .............................11
3.10. Counters and Discontinuities .............................11
3.11. Spin Locks ...............................................12
3.12. Row Creation .............................................12
4. Trace Exchange Formats .........................................12
4.1. XML Representation ........................................12
4.2. CSV Representation ........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
The Simple Network Management Protocol (SNMP) was introduced in the late 1980s [RFC1052] and has since then evolved to what is known today as the SNMP version 3 Framework (SNMPv3) [RFC3410]. While SNMP is widely deployed, it is not clear what protocol versions are being used, which protocol features are being used, how SNMP usage differs in different types of networks or organizations, which information is frequently queried, and what typical SNMP interaction patterns occur in real-world production networks.
SNMP（Simple Network Management Protocol）は、1980年代後半[RFC1052]で導入され、それ以来、SNMPバージョン3のフレームワーク（SNMPv3の）[RFC3410]として今日知られているものに進化してきました。 SNMPは広く展開されているが、バージョンがSNMPの使用が頻繁に照会されている情報のネットワークや組織の異なるタイプにどのように異なるか、との相互作用のパターンがで発生する一般的なものをSNMPプロトコルの機能が使用されているか、使用されているかのプロトコル明確ではありません実世界の生産ネットワーク。
There have been several publications in the recent past dealing with the performance of SNMP in general [SM99][Mal02][Pat01], the impact of SNMPv3 security [DSR01][CT04], or the relative performance of SNMP compared to Web Services [PDMQ04][PFGL04]. While these papers are generally useful to better understand the impact of various design decisions and technologies, some of these papers lack a strong foundation because authors typically assume certain SNMP interaction patterns without having experimental evidence that the assumptions are correct. In fact, there are many speculations on how SNMP is being used in real-world production networks, and performance comparisons are based on limited test cases, but no systematic measurements have been performed and published so far.
[Mal02] [Pat01]、SNMPv3セキュリティ[DSR01] [CT04]、またはSNMPの相対的なパフォーマンスの影響は、Webサービスに比べて、一般的な[SM99]でSNMPのパフォーマンスを扱う最近の過去にいくつかの出版が行われています[ PDMQ04] [PFGL04]。これらの論文は、一般的に良く、様々な設計上の決定と技術の影響を理解するのに有用であるが、著者は、一般的な仮定が正しいことを実験的証拠がなくても、特定のSNMPの相互作用パターンを想定しているため、これらの論文の一部は、強力な基盤を欠いています。実際には、SNMPは、実世界の生産ネットワークで使用されている、との性能比較が限定されたテストケースに基づいていますが、系統的な測定は行われず、これまでに公開されている方法についての多くの憶測があります。
Many authors use the ifTable of the IF-MIB [RFC2863] or the tcpConnTable of the TCP-MIB [RFC4022] as a starting point for their analysis and comparison. Despite the fact that there is no evidence that operations on these tables dominate SNMP traffic, it is even more unclear how these tables are read and which optimizations are done (or not done) by real-world applications. It is also unclear what the actual traffic trade-off between periodic polling and more aperiodic bulk data retrieval is. Furthermore, we do not generally understand how much traffic is devoted to standardized MIB objects and how much traffic deals with proprietary MIB objects and whether the operation mix between these object classes differs between different operational environments (e.g., backbone networks, access networks, enterprise networks).
多くの著者は、彼らの分析と比較するための出発点としてIF-MIB [RFC2863]またはTCP-MIB [RFC4022]のtcpConnTableのifTableのを使用しています。これらのテーブル上の操作がSNMPトラフィックを支配という証拠がないという事実にもかかわらず、それは、これらのテーブルが読み込まれ、その最適化を行う（または行わない）実際のアプリケーションでされているか、さらには不明です。定期的なポーリングとより多くの非周期的な大量データの検索との間の実際のトラフィックのトレードオフが何であるかも不明です。さらに、我々は一般的に、独自のMIBオブジェクトを使用してトラフィックのお得な情報をMIBオブジェクトを標準化し、どのくらいに専念されてどのくらいのトラフィックを理解していないと、これらのオブジェクト・クラス間の操作ミックスは異なる運用環境（例えば、バックボーンネットワーク、アクセスネットワーク、エンタープライズネットワーク間で異なるかどうか）。
This document recommends an approach to collecting, codifying, and handling SNMP traffic traces in order to find answers to some of these questions. It describes the tools that have been developed to allow network operators to collect traffic traces and to share them with research groups interested in analyzing and modeling network management interactions.
この文書では、収集体系化、及びこれらの質問のいくつかに答えを見つけるためにSNMPトラフィックのトレースを処理するためのアプローチを推奨しています。これは、ネットワークオペレータは、トラフィックトレースを収集し、分析とモデリングのネットワーク管理の相互作用に興味を持つ研究グループとそれらを共有できるようにするために開発されているツールについて説明します。
While the SNMP trace collection and analysis effort was initiated by the research community, network operators can benefit from the SNMP measurements too. Several new tools are being developed as part of this effort that can be used to capture and analyze the traffic generated by management stations. This resulting information can then be used to improve the efficiency and scalability of management systems.
SNMPトレース収集と分析の努力は、研究コミュニティによって開始されたが、ネットワークオペレータは、あまりにもSNMP測定の恩恵を受けることができます。いくつかの新しいツールは、管理ステーションによって生成されたトラフィックをキャプチャし、分析するために使用することができ、この取り組みの一環として開発されています。この得られた情報は、管理システムの効率および拡張性を改善するために使用することができます。
The measurement approach described in this document is by design limited to the study of SNMP traffic. Studies of other management protocols or the impact of management protocols such as SNMP on other traffic sharing the same network resources is left to future efforts.
この文書で説明した測定アプローチは、SNMPトラフィックの研究に限定仕様です。他の管理プロトコルまたは同じネットワークリソースを共有する他のトラフィック上のSNMPなどの管理プロトコルの影響の研究は、今後の取り組みに任されています。
This is an Informational document, produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group.
これはIRTFのネットワーク管理研究グループ（NMRG）内に生産情報の文書であり、そしてそれがこのグループにアクティブな貢献者のすべての合意を表しています。
This section outlines the process of doing SNMP traffic measurements and analysis. The process consists of the following five basic steps:
このセクションでは、SNMPトラフィック測定と分析を行うためのプロセスの概要を説明します。このプロセスは、以下の5つの基本的な手順で構成されます。
2. Convert the raw traffic traces into a structured machine and human-readable format. A suitable XML schema has been developed for this purpose that captures all SNMP message details. Another more compact comma-separated values (CSV) format has been developed that only keeps key information about SNMP messages.
2.構造化された機械と人間が読める形式に生のトラフィックのトレースを変換します。適したXMLスキーマは、すべてのSNMPメッセージの詳細をキャプチャし、この目的のために開発されてきました。別のよりコンパクトなカンマ区切り（CSV）形式のみSNMPメッセージに関する重要な情報を保持していることが開発されてきました。
3. Filter the converted traffic traces to hide or anonymize sensitive information. While the filtering is conceptually a separate step, filtering may actually be implemented as part of the previous data conversion step for efficiency reasons.
3.フィルターは変換トラフィックは非表示にしたり、機密情報を匿名化するためのトレース。フィルタリングは、概念的に別個の工程であるが、フィルタリングは、実際には効率上の理由から、以前のデータ変換ステップの一部として実装されてもよいです。
4. Submit the filtered traffic traces to a repository from which they can be retrieved and analyzed. Such a repository may be public, under the control of a research group, or under the control of a network operator who commits to run analysis scripts on the repository on behalf of researchers.
4.彼らは、検索および分析することができ、そこからリポジトリにフィルタリングしたトラフィックのトレースを提出してください。このようなリポジトリは、研究グループの制御下、または研究者に代わって、リポジトリに解析スクリプトを実行するためにコミットするネットワークオペレータの制御下で、公共のかもしれません。
5. Analyze the traces by creating and executing analysis scripts that extract and aggregate information.
5.解析抽出スクリプトおよび集計情報を作成して実行することにより、トレースを分析します。
Several of the steps listed above require the involvement of network operators supporting the SNMP measurement projects. In many cases, the filtered XML and CSV representation of the SNMP traces will be the interface between the researchers writing analysis scripts and the operators involved in the measurement activity. It is therefore important to have a well-defined specification of these interfaces.
上記の手順のいくつかは、SNMP測定プロジェクトを支援するネットワークオペレータの関与を必要としています。多くの場合、SNMPトレースのフィルタリングXMLとCSV表現は、解析スクリプトを記述する研究者や測定活性に関与する事業者との間のインターフェイスとなります。これらのインタフェースの明確に定義された仕様を持つことが重要です。
This section provides some advice and concrete hints on how the steps listed above can be carried out efficiently. Some special tools have been developed to assist network operators and researchers so that the time spent on supporting SNMP traffic measurement projects is limited. The following sections describe the five steps and some tools in more detail.
このセクションでは、上記の手順を効率的に行うことができる方法についていくつかのアドバイスや具体的なヒントを提供します。 SNMPトラフィック測定プロジェクトの支援に費やした時間は限られているように、いくつかの特別なツールは、ネットワーク事業者や研究者を支援するために開発されています。次のセクションでは、5つのステップと、より詳細にいくつかのツールについて説明します。
Capturing SNMP traffic traces can be done using packet sniffers such as tcpdump [2], wireshark [3], or similar applications. Some care must be taken to specify pcap filter expressions that match the SNMP transport endpoints used to carry SNMP traffic (typically 'udp and (port 161 or port 162)'). Furthermore, it is necessary to ensure that full packets are captured, that is packets are not truncated (tcpdump option -s 0). Finally, it is necessary to carefully select the placement of the capturing probe within the network. Especially on bridged LANs, it is important to ensure that all management traffic is captured and that the probe has access to all virtual LANs carrying management traffic. This usually requires placing the probe(s) close to the management system(s) and configuring dedicated monitoring ports on bridged networks. Some bridges have restrictions concerning their monitoring capabilities, and this should be investigated and documented where necessary.
捕捉SNMPトラフィックトレースは、tcpdumpの[2]、[3]のwireshark、または同様の用途として用いてパケットスニファを行うことができます。いくつかの注意が（通常は「）、UDPと（ポート161またはポート162」）SNMPトラフィックを運ぶために使用されるSNMPトランスポートエンドポイントを一致させるのpcapフィルタ式を指定するために取られなければなりません。また、そのパケットが（0 -s tcpdumpのオプション）トランケートされないで、完全なパケットが捕捉されることを保証する必要があります。最後に、慎重に、ネットワーク内の捕獲プローブの配置を選択する必要があります。特に、ブリッジ接続されたLAN上で、すべての管理トラフィックをキャプチャおよびプローブは、管理トラフィックを運ぶすべての仮想LANへのアクセスを持っていることをされていることを確認することが重要です。これは、通常、管理システム（S）に近いプローブ（単数または複数）を配置し、ブリッジネットワーク上の専用モニタリングポートを設定する必要があります。いくつかの橋は、彼らの監視機能に関する制限があり、これを調査し、必要に応じて文書化する必要があります。
It is recommended to capture at least a full week of data to capture diurnal patterns and one cycle of weekly behavior. Operators are strongly encouraged to capture traces over even longer periods of time. Tools such as tcpdump and tcpslice [2] or mergecap and editcap [3] can be used to split or merge pcap trace files as needed.
日周パターンと毎週の行動の1サイクルをキャプチャするデータの少なくとも完全な一週間をキャプチャすることをお勧めします。オペレータが強く、時間のさらに長い期間にわたってトレースをキャプチャすることをお勧めします。このようtcpdumpのとtcpslice [2]またはmergecapとeditcap [3]分割または必要に応じてのpcapトレースファイルをマージするために用いることができるツール。
Several operating systems can offload some of the TCP/IP processing such as the calculation of transport layer checksum to network interface cards. Traces that include traffic to/from a capturing interface that supports TCP/IP offloading can include incorrect transport layer checksums. The simplest solution is of course to turn checksum offloading off while capturing traces (if that is feasible without losing too many packets). The other solution is to correct or ignore checksums during the subsequent conversion of the raw pcap files.
複数のオペレーティングシステムは、インターフェイスカードをネットワークにそのようなトランスポート層チェックサムの計算のようなTCP / IP処理の一部をオフロードすることができます。 TCP / IPオフロードをサポートしているキャプチャインタフェースへ/からのトラフィックを含めるトレースは正しくないトランスポート層チェックサムを含めることができます。最も簡単な解決策は、トレースをキャプチャしながら、（それはあまりにも多くのパケットを失うことなく、可能であるならば）、チェックサムオフロードをオフにすることはもちろんです。他の解決策は、生のpcapファイルのその後の変換時にチェックサムを修正するか無視することです。
It is important to note that the raw pcap files should ideally be kept in permanent storage (e.g., compressed and encrypted on a CD ROM or DVD). To verify measurements, it might be necessary to go back to the original pcap files if, for example, bugs in the tools described below have been detected and fixed.
生のpcapファイルは、理想的には、（例えば、圧縮およびCD-ROMまたはDVDに暗号化された）永続的なストレージに保管しなければならないことに注意することが重要です。例えば、以下のツールのバグが検出され、修正されている、場合の測定値を確認するには、元のpcapファイルに戻ってする必要があります。
For each captured trace, some meta data should be recorded and made available. The meta data should include information such as where the trace was collected (name of the network and name of the organization owning the network, description of the measurement point in the network topology where the trace was collected), when it was collected, contact information, the size of the trace, any known special events, equipment failures, or major infrastructure changes during the data collection period and so on. It is also extremely useful to provide a unique identification. There are special online services such as DatCat [4] where meta data can be stored and which provide unique identifiers.
各キャプチャされたトレースのために、いくつかのメタデータが記録され、利用できるようにすべきです。メタデータは、このようなトレースは、それが収集された、（ネットワーク、トレースが収集されたネットワークトポロジの測定点の記述を所有する組織のネットワークと名前の名前）を回収した場合などの情報を含める必要があり、連絡先情報、トレースのサイズ、任意の既知の特別なイベント、機器の故障、または主要なインフラストラクチャの変更データ収集期間中のように。ユニークな識別情報を提供するためにも極めて有用です。このようDatCatなどの特別なオンラインサービスがあります[4]メタデータを保存することができる場所と一意の識別子を提供します。
Raw traces in pcap format must be converted into a format that is human readable while also remaining machine readable for efficient post-processing. Human readability makes it easy for an operator to verify that no sensitive data is left in a trace while machine readability is needed to efficiently extract relevant information.
PCAPフォーマットの生のトレースはまた、効率的な後処理のための機械が読み取り可能なまま人間可読な形式に変換されなければなりません。オペレータが機械可読性が効率的に関連する情報を抽出するために必要とされている間は機密データがトレースに残っていないことを確認するために人間の読みやすさは、それが容易になります。
The natural choice here is to use an XML format since XML is human as well as machine readable and there are many tools and high-level scripting language application programming interfaces (APIs) that can be used to process XML documents and to extract meaningful information. However, XML is also pretty verbose, which increases processing overhead. In particular, the usage of XML streaming APIs is strongly suggested since APIs that require an in-memory representation of XML documents do not handle large traces well.
ここで自然な選択は、XMLは、ヒト、ならびに機械可読であり、XML文書を処理し、意味のある情報を抽出するために使用することができる多くのツールおよび高レベルスクリプト言語アプリケーション・プログラミング・インターフェース（API）があるので、XMLフォーマットを使用することです。しかし、XMLは、処理のオーバーヘッドが増加しており、また、かなり冗長です。具体的には、XMLストリーミングAPIを使用方法は、XML文書のメモリー内表現を必要とするAPIが良く、大きな痕跡を処理しないので、強く示唆しています。
Section 4.1 of this document defines a RELAX NG schema [OASISRNG] for representing SNMP traffic traces in XML. The schema captures all relevant details of an SNMP message in the XML format. Note that the XML format retains some information about the original ASN.1/BER encoding to support message size analysis.
この文書のセクション4.1は、XMLでSNMPトラフィックトレースを表すためRELAX NGスキーマ[OASISRNG]を定義します。スキーマは、XML形式のSNMPメッセージのすべての関連する詳細情報をキャプチャします。 XMLフォーマットはメッセージのサイズ分析をサポートするために、元のASN.1 / BER符号化に関するいくつかの情報を保持することに留意されたいです。
A lightweight alternative to the full-blown XML representation based on comma-separated values (CSV) is defined in Section 4.2. The CSV format only captures selected parts of SNMP messages and is thus more compact and faster to process.
カンマ区切り値（CSV）に基づいて、本格的なXML表現に軽量の代替は、セクション4.2で定義されています。 CSV形式はSNMPメッセージの選択した部分をキャプチャし、よりコンパクトにし、プロセスに高速です。
As explained in the previous sections, analysis programs that process raw pcap files should have an option to ignore incorrect checksums caused by TCP/IP offloading. In addition, analysis programs that process raw pcap files should be able to perform IP reassembly for SNMP messages that were fragmented at the IP layer.
前のセクションで説明したように、生のpcapファイルを処理する解析プログラムは、TCP / IPオフロードによって引き起こされる間違ったチェックサムを無視するオプションを持っている必要があります。また、生のpcapファイルを処理する解析プログラムは、IP層で断片化されたSNMPメッセージのIP再構築を実行することができるはずです。
The snmpdump [5] package has been developed to convert raw pcap files into XML and CSV format. The snmpdump program reads pcap, XML, or CSV files as input and produces XML files or CSV files as output.
snmpdump [5]パッケージは、XMLやCSV形式に生のpcapファイルを変換するために開発されてきました。 snmpdumpプログラムは、入力としてPCAP、XML、またはCSVファイルを読み込み、出力としてXMLファイルやCSVファイルを生成します。
Specific elements can be filtered as required to protect sensitive data.
機密データを保護するために必要に応じて特定の要素をフィルタリングすることができます。
Filtering sensitive data (e.g., access control lists or community strings) can be achieved by manipulating the XML representation of an SNMP trace. Standard XSLT processors (e.g., xsltproc [6]) can be used for this purpose. People familiar with the scripting language Perl might be interested in choosing a suitable Perl module to manipulate XML documents [7].
フィルタリング機密データ（例えば、アクセス制御リストやコミュニティストリング）SNMPトレースのXML表現を操作することによって達成することができます。標準XSLTプロセッサ（例えば、xsltprocの[6]）は、この目的のために使用することができます。スクリプト言語のPerlに精通している人々は、[7] XMLドキュメントを操作するために、適切なPerlモジュールを選択する際に興味があるかもしれません。
The snmpdump program, for example, can filter out sensitive information, e.g., by deleting or clearing all XML elements whose name matches a regular expression. Data type specific anonymization transformations that maintain lexicographic ordering for values that appear in instance identifiers [HS06] can be applied. Note that anonymization transformations are often bound to an initialization key and depend on the data being anonymized in an anonymization run. As a consequence, users must be careful when they merge data from independently anonymized traces. More information about network traffic trace anonymization techniques can be found in [XFA02], [FXAM04], [PAPL06], and [RW07].
snmpdumpプログラムは、例えば、名前の正規表現と一致するすべてのXML要素を削除またはクリアすることによって、例えば、機密情報を除外することができます。インスタンス識別子[HS06]に表示される値に対して辞書式順序を維持するデータ・タイプの特定の匿名化変換を適用することができます。匿名化変換は、多くの場合、初期設定キーにバインドされ、匿名の実行で匿名化されたデータに依存していることに注意してください。彼らは独立して匿名化トレースからのデータをマージするときその結果、ユーザーは注意しなければなりません。ネットワークの詳細については、トラフィックのトレース匿名化技術は、[FXAM04]、[PAPL06]、および[RW07]、[XFA02]で見つけることができます。
The raw pcap traces as well as the XML / CSV formatted traces should be stored in a stable archive or repository. Such an archive or repository might be maintained by research groups (e.g., the NMRG), network operators, or both. It is of key importance that captured traces are not lost or modified as they may form the basis of future research projects and may also be needed to verify published research results. Access to the archive might be restricted to those who have signed some sort of a non-disclosure agreement.
生PCAPトレースならびにXML / CSV形式のトレースは、安定したアーカイブまたはリポジトリに格納されるべきです。そのようなアーカイブまたはリポジトリは、研究グループ（例えば、NMRG）、ネットワークオペレータ、またはその両方によって維持されるかもしれません。これは、トレースが失われたり変更され、彼らは今後の研究プロジェクトの基礎を形成することができるよう、また、発表された研究結果を検証するために必要とすることができるされていませんキャプチャ極めて重要です。アーカイブへのアクセスは、非開示契約のいくつかの並べ替えを締結している人に制限されることがあります。
While this document recommends that raw traces should be kept, it must be noted that there are situations where this may not be feasible. The recommendation to keep raw traces may be ignored, for example, to comply with data-protection laws or to protect a network operator from being forced to provide the data to other organizations.
この文書は、生のトレースが保たれるべきであることをお勧めしますが、実現可能ではないかもしれない状況があることに留意しなければなりません。生の痕跡を維持するための推奨事項は、データ保護法を遵守するために、または他の組織にデータを提供することを余儀なくされることから、ネットワークオペレータを保護するために、例えば、無視することができます。
Lossless compression algorithms embodied in programs such as gzip or bzip2 can be used to compress even large trace files down to a size where they can be burned on DVDs for cheap long-term storage.
このようgzipやbzip2のようなプログラムで具体ロスレス圧縮アルゴリズムは、それらが安い長期保存のためにDVDに書き込むことができる大きさにダウンしても、大きなトレースファイルを圧縮するために使用することができます。
It must be stressed again that it is important to keep the original pcap traces in addition to the XML/CSV formatted traces since the pcap traces are the most authentic source of information. Improvements in the tool chain may require going back to the original pcap traces and rebuilding all intermediate formats from them.
のpcap跡が情報の最も本格的なソースであるため、XML / CSV形式のトレースに加えて、元のpcap跡を保つことが重要であることを改めて強調しておかなければなりません。ツールチェーンの改善は、元のpcap跡に戻って、そこからすべての中間フォーマットを再構築する必要があります。
Scripts that analyze traffic traces must be verified for correctness. Ideally, all scripts used to analyze traffic traces will be publically accessible so that third parties can verify them. Furthermore, sharing scripts will enable other parties to repeat an analysis on other traffic traces and to extend such analysis scripts. It might be useful to establish a common, versioning repository for analysis scripts.
トラフィックのトレースを分析するスクリプトが正しいか確認する必要があります。第三者がそれらを確認することができるように理想的には、トラフィックのトレースを分析するために使用されるすべてのスクリプトは、公にアクセスできるようになります。さらに、共有スクリプトは、他のトラフィックトレースの分析を繰り返すように他の当事者を可能にすると、このような解析スクリプトを拡張します。解析スクリプトのための共通、バージョン管理リポジトリを確立するために役に立つかもしれません。
Due to the availability of XML parsers and the simplicity of the CSV format, trace files can be processed with tools written in almost any programming language. However, in order to facilitate a common vocabulary and to allow operators to easily read scripts they execute on trace files, it is suggested that analysis scripts be written in scripting languages such as Perl using suitable Perl modules to manipulate XML documents <http://perl-xml.sourceforge.net/faq/>. Using a scripting language such as Perl instead of system programming languages such as C or C++ has the advantage of reducing development time and making scripts more accessible to operators who may want to verify scripts before running them on trace files that may contain sensitive data.
XMLパーサの可用性とCSV形式のシンプルさに、トレースファイルには、ほぼすべてのプログラミング言語で書かれたツールを用いて処理することができます。しかし、一般的な語彙を容易にし、オペレーターが簡単に彼らはトレースファイルに実行されるスクリプトを読み取ることができるようにするためには、HTTP <XMLドキュメントを操作するために、適切なPerlモジュールを用いた解析スクリプトはPerlなどのスクリプト言語で記述することが示唆されている：// perl-xml.sourceforge.net/faq/>。代わりに、CやC ++などのシステムのプログラミング言語のPerlなどのスクリプト言語を使用することで、開発時間を短縮し、機密データを含むことがトレースファイルにそれらを実行する前にスクリプトを確認する必要があり、オペレータへのスクリプトは、よりアクセスしやすくするという利点があります。
The snmpdump tool provides an API to process SNMP messages in C/C++. While the coding of trace analysis programs in C/C++ should in general be avoided for code readability, verifiability, and portability reasons, using C/C++ might be the only option in dealing with very large traces efficiently.
snmpdumpツールは、C / C ++でSNMPメッセージを処理するためのAPIを提供します。一方でC / C ++でのトレース解析プログラムのコーディングは、一般的にはC / C ++が効率的に非常に大きな痕跡を扱う唯一の選択肢かもしれません使用して、コードの可読性、検証可能性、および移植性の理由から避けるべきです。
Any results produced by analyzing a trace must be interpreted in the context of the trace. The nature of the network, the attachment point used to collect the trace, the nature of the applications generating SNMP traffic, or the events that happened while the trace was collected clearly influence the result. It is therefore important to be careful when drawing general conclusions based on a potentially (too) limited data set.
トレースを分析することによって生成される任意の結果は、トレースの文脈で解釈されなければなりません。ネットワークの性質上、トレース、SNMPトラフィックを生成するアプリケーションの性質、またはトレースが結果に影響を与える明確に収集している間に起こったイベントを収集するために使用される付着点。潜在的に（あまりにも）限られたデータセットに基づいて一般的な結論を描画するときに注意することが重要です。
This section discusses several questions that can be answered by analyzing SNMP traffic traces. The questions raised in the following subsections are meant to be illustrative and no attempt has been made to provide a complete list.
このセクションでは、SNMPトラフィックのトレースを解析することで答えることができるいくつかの質問について説明します。以下のサブセクションで提起された質問は、例示であることを意味していると何の試みは完全なリストを提供するために行われていません。
Basic statistics cover things such as:
基本的な統計情報は、次のような事柄を網羅します。
o protocol version used,
Oプロトコルバージョンを使用し、
o protocol operations used,
Oプロトコルの動作は、使用します
o message size distribution,
Oメッセージサイズ分布、
o error message type frequency, or
Oエラーメッセージタイプ周波数、又は
o usage of authentication and encryption mechanisms.
認証と暗号化メカニズムのOの使用。
The Object Identifier (OID) names of the objects manipulated can be categorized into OID subtrees, for example, to identify 'standardized', 'proprietary', and 'experimental' objects.
操作オブジェクトのオブジェクト識別子（OID）の名前は、例えば、「標準」、「独自の」、及び「実験」オブジェクトを識別するために、OIDサブツリーに分類することができます。
SNMP is used to periodically poll devices as well as to retrieve information at the request of an operator or application. The periodic polling leads to periodic traffic patterns while on-demand information retrieval causes more aperiodic traffic patterns. It is worthwhile to understand what the relationship is between the amount of periodic and aperiodic traffic. It will be interesting to understand whether there are multiple levels of periodicity at different time scales.
SNMPは、定期的にポーリングデバイスだけでなく、オペレータまたはアプリケーションの要求に応じて情報を取得するために使用されています。オンデマンドの情報検索は、より多くの非周期的なトラフィックパターンを起こしながら、定期的なポーリングは、定期的なトラフィックパターンにつながります。関係が周期的と非周期的なトラフィックの量との間にあるかを理解する価値があります。異なる時間スケールでの周期の複数のレベルがあるかどうかを理解することは興味深いものになります。
Periodic polling behavior may be dependent on the application and polling engine it uses. For example, some management platforms allow applications to specify how long polled values may be kept in a cache before they are polled again. Such optimizations need to be considered when analyzing traces for periodic and aperiodic traffic.
定期的なポーリング動作は、それが使用するアプリケーションとポーリングエンジンに依存してもよいです。例えば、いくつかの管理プラットフォームは、アプリケーションが、彼らが再びポーリングされる前に、長いポーリングされた値がキャッシュに保持することができる方法を指定することができます。このような最適化は、定期的および非周期的なトラフィックのトレースを分析する際に考慮する必要があります。
SNMP messages are size constrained by the transport mappings used and the buffers provided by the SNMP engines. For the further evolution of the SNMP framework, it would be useful to know what the actual message size distributions are. It would be useful to understand the latency distributions, especially the distribution of the processing times by SNMP command responders. Some SNMP implementations approximate networking delays by measuring request-response times, and it would be useful to understand to what extent this is a viable approach.
SNMPメッセージが使用されるトランスポートのマッピングおよびSNMPエンジンが提供するバッファによって制約サイズです。 SNMPフレームワークのさらなる進化のために、実際のメッセージのサイズ分布が何であるかを知っておくと便利でしょう。 SNMPコマンド応答により、処理時間の分布、特に待ち時間の分布を理解するのに有用であろう。いくつかのSNMP要求 - 応答時間を測定することにより、実装おおよそのネットワーク遅延を、そしてこれは実行可能なアプローチでどの程度まで理解することが有用であろう。
Some SNMP implementations update their counters from the underlying instrumentation following adaptive algorithms, not necessarily periodically, and not necessarily on-demand. The granularity of internal counter updates may impact latency measurements and should be taken into account.
いくつかのSNMPの実装は、必ずしも定期的に、適応アルゴリズム以下の基本的な計装から彼らのカウンターを更新し、必ずしもオンデマンド。内部カウンタの更新の粒度はレイテンシ測定値に影響を与える可能性があると考慮されるべきです。
SNMP allows management stations to retrieve information from multiple agents concurrently. It will be interesting to identify what the typical concurrency level is that can be observed on production networks or whether management applications prefer more sequential ways of retrieving data.
SNMPは、管理ステーションが同時に複数のエージェントから情報を取得することができます。典型的な同時実行レベルはそれが生産ネットワーク上または管理アプリケーションがデータを取得するより多くのシーケンシャルな方法を好むかどうかを観察することが可能であるものを識別するために興味深いものになります。
Furthermore, it will be interesting to analyze how many redundant requests coming from applications are processed almost simultaneously by a device. The concurrency level and the amount of redundant requests has implications on caching strategies employed by SNMP agents.
さらに、アプリケーションからの冗長な要求は、デバイスによってほぼ同時に処理され、どのように多くの分析は興味深いだろう。並行処理レベルと冗長リクエストの量はSNMPエージェントによって使用されるキャッシュ戦略上の意味を持ちます。
Tables can be read in several different ways. The simplest and most inefficient approach is to retrieve tables object-by-object in column-by-column order. More advanced approaches try to read tables row-by-row or even multiple-rows-by-multiple-rows. The retrieval of index elements can be suppressed in most cases or only a subset of columns of a table are retrieved. It will be useful to know which of these approaches are used on production networks since this has a direct implication on agent implementation techniques and caching strategies.
テーブルには、いくつかの異なる方法で読むことができます。最も簡単で最も非効率的なアプローチは、オブジェクトごとの列ごとに順番にテーブルを取得することです。より高度なアプローチは、テーブルに行単位、あるいは複数の行ごとの複数行を読み取るしようとします。インデックス要素の検索は、ほとんどの場合を抑制することができるか、または表の列のサブセットのみが検索されます。エージェントの実装技術とキャッシング戦略に直接的な意味を持っているので、生産ネットワーク上で使用されているこれらのアプローチのかを知るために有用であろう。
SNMP is built around a concept called trap-directed polling. Management applications are responsible to periodically poll SNMP agents to determine their status. In addition, SNMP agents can send traps to notify SNMP managers about events so that SNMP managers can adapt their polling strategy and basically react faster than normal polling would allow.
SNMPトラップ指向ポーリングと呼ばれる概念を中心に構築されています。管理アプリケーションは、定期的に自分の状態を判断するためにSNMPエージェントをポーリングする責任があります。また、SNMPエージェントは、SNMPマネージャがそのポーリング戦略を適応し、基本的にできるようになり、通常のポーリングよりも速く反応できるように、イベントについてのSNMPマネージャに通知するためにトラップを送信することができます。
Analysis of SNMP traffic traces can identify whether trap-directed polling is actually deployed. In particular, the question that should be addressed is whether SNMP notifications lead to changes in the short-term polling behavior of management stations. In particular, it should be investigated to what extent SNMP managers use automated procedures to track down the meaning of the event conveyed by an SNMP notification.
SNMPトラフィック跡の分析は、トラップ指向ポーリングが実際に配備されているかどうかを識別することができます。具体的には、対処すべき問題は、SNMP通知は、管理ステーションの短期ポーリング行動の変化につながるかどうかです。特に、それはある程度のSNMPマネージャは、SNMP通知によって搬送されたイベントの意味を追跡するために自動化された手順を使用しているものに調査する必要があります。
An analysis of object identifier prefixes can identify the most popular MIB modules and the most important object types or notification types defined by these modules. Such information would be very valuable for the further maintenance and development of these and related MIB modules.
オブジェクト識別子プレフィックスの分析では、最も人気のあるMIBモジュールと、これらのモジュールで定義された最も重要なオブジェクトタイプまたは通知タイプを識別することができます。このような情報は、これらと関連するMIBモジュールの更なる維持・発展のために非常に有益であろう。
Several objects from the early days have been obsoleted because they cannot properly represent today's networks. A typical example is the ipRouteTable that was obsoleted because it was not able to represent classless routing, introduced and deployed on the Internet in 1993. Some of these obsolete objects are still mentioned in popular publications as well as research papers. It will be interesting to find out whether they are also still used by management applications or whether management applications have been updated to use the replacement objects.
彼らは適切に、今日のネットワークを表すことができないので、初期の頃からいくつかのオブジェクトは廃止されました。典型的な例は、1993年にインターネット上で、クラスレスルーティングを表現することができませんでしたので、廃止導入と展開されたことipRouteTableであるこれらの時代遅れのオブジェクトのいくつかは、まだ人気のある出版物だけでなく、研究論文に記載されています。彼らがまだ管理アプリケーションによって、または管理アプリケーションは、交換用のオブジェクトを使用するように更新されたかどうかにも使用されているかどうかを知るのは興味深いだろう。
Depending on the data recorded in a trace, it might be possible to determine the age of devices by looking at the values of objects such as sysObjectID and sysDecr [RFC3418]. The age of a device can then be taken into consideration when analyzing the use of obsolete and deprecated objects.
トレースに記録されたデータによっては、そのようなのsysObjectIDとsysDecr [RFC3418]などのオブジェクトの値を見ることで、デバイスの年齢を決定することが可能かもしれません。廃止および非推奨のオブジェクトの使用を分析する際、デバイスの年齢は、次に考慮することができます。
It will be useful to understand the encoding length distributions for various data types. Assumptions about encoding length distributions are sometimes used to estimate SNMP message sizes in order to meet transport and buffer size constraints.
さまざまなデータ型の符号化長分布を理解するのに有用であろう。符号長分布に関する仮定は時々輸送を満たし、サイズの制約をバッファリングするために、SNMPメッセージのサイズを推定するために使用されます。
Counters can experience discontinuities [RFC2578]. A widely used discontinuity indicator is the sysUpTime scalar of the SNMPv2-MIB [RFC3418], which can be reset through a warm start to indicate counter discontinuities. Some MIB modules introduce more specific discontinuity indicators, e.g., the ifCounterDiscontinuityTime of the
カウンターは不連続[RFC2578]を体験することができます。広く使用されている不連続インジケータがカウンタの不連続性を示すために、ウォームスタートを介してリセットすることができるのSNMPv2-MIB [RFC3418]ののsysUpTimeスカラーです。一部のMIBモジュールはのifCounterDiscontinuityTime、例えば、より具体的な不連続性指標を導入します
IF-MIB [RFC2863]. It will be interesting to study to what extent these objects are actually used by management applications to handle discontinuity events.
IF-MIB [RFC2863]。これらのオブジェクトが実際に不連続イベントを処理するために、管理アプリケーションで使用されているどの程度に勉強するのは興味深いだろう。
Cooperating command generators can use advisory locks to coordinate their usage of SNMP write operations. The snmpSetSerialNo scalar of the SNMPv2-MIB [RFC3418] is the default coarse-grain coordination object. It will be interesting to find out whether there are command generators that coordinate themselves using these spin locks.
協力コマンドジェネレータは、SNMP書き込み操作の彼らの使用を調整するために諮問ロックを使用することができます。 SNMPv2-MIB [RFC3418]のsnmpSetSerialNoスカラーデフォルト粗粒調整オブジェクトです。これらのスピンロックを使用して自分自身を座標コマンドジェネレータがあるかどうかを調べるのは興味深いだろう。
Row creation is an operation not natively supported by the protocol operations. Instead, conceptual tables supporting row creation typically provide a control column that uses the RowStatus textual convention defined in the SNMPv2-TC [RFC2579] module. The RowStatus itself supports different row creation modes, namely createAndWait (dribble-mode) and createAndGo (one-shot mode). Different approaches can be used to derive the instance identifier if it does not have special semantics associated with it. It will be useful to study which of the various row creation approaches are actually used by management applications on production networks.
列の作成は、ネイティブプロトコル動作によってサポートされていない操作です。代わりに、行の作成を支援する概念テーブルは、典型的にはSNMPv2-TC [RFC2579]モジュールで定義されRowStatusテキストの表記法を使用して制御列を提供します。 RowStatusの自体は、異なる行作成モード、すなわちcreateAndWaitに（ドリブルモード）とcreateAndGo（ワンショットモード）をサポートします。別のアプローチは、それに関連付けられた特別な意味を持っていない場合、インスタンス識別子を導出するために使用することができます。実際に生産ネットワーク上の管理アプリケーションで使用される様々な列の作成手法のどの研究に有用であろう。
The XML format has been designed to keep all information associated with SNMP messages. The format is specified in RELAX NG compact notation [OASISRNC]. Freely available tools such as trang [8] can be used to convert RELAX NG compact syntax to other XML schema notations.
XML形式は、SNMPメッセージに関連付けられたすべての情報を保つように設計されています。フォーマットは、RELAX NGコンパクト表記[OASISRNC]で指定されています。このようなトランとして自由に利用できるツールは、[8]他のXMLスキーマ表記にNGコンパクト構文をRELAX変換するために使用することができます。
The XML format can represent SNMPv1, SNMPv2c, and SNMPv3 messages. In case a new version of SNMP is introduced in the future or existing SNMP versions are extended in ways that require changes to the XML format, a new XML format with a different namespace needs to be defined (e.g., by incrementing the version number included in the namespace URI).
XML形式は、SNMPv1、SNMPv2c、およびSNMPv3メッセージを表すことができます。ケースにはSNMPの新しいバージョンは、XML形式の変更が必要になる方法で拡張され、将来のか、既存のSNMPバージョンで導入され、異なる名前空間を持つ新しいXML形式は、例えば、中に含まれているバージョン番号をインクリメントすることにより（定義する必要があります名前空間URI）。
# Relax NG grammar for the XML SNMP trace format. # # Published as part of RFC 5345.
＃XML SNMPトレースフォーマットのNG文法をリラックス。 ## RFC 5345の一部として公開されました。
default namespace = "urn:ietf:params:xml:ns:snmp-trace-1.0"
デフォルトの名前空間= "壷：IETF：のparams：XML：NS：SNMPトレース-1.0"
start = element snmptrace { packet.elem* }
=開始素子snmptrace {packet.elemの*}
packet.elem = element packet { element time-sec { xsd:unsignedInt }, element time-usec { xsd:unsignedInt }, element src-ip { ipaddress.type }, element src-port { xsd:unsignedInt }, element dst-ip { ipaddress.type }, element dst-port { xsd:unsignedInt }, snmp.elem }
packet.elem =エレメントパケット{素子時間秒{XSD：unsignedInt型}、素子時間マイクロ秒{XSD：unsignedInt型}要素SRC-IP {ipaddress.type}要素SRCポート{XSD：unsignedInt型}、素子dst- IP {ipaddress.type}、素子DSTポート{XSD：unsignedInt型}、snmp.elem}
snmp.elem = element snmp { length.attrs?, message.elem }
snmp.elem =エレメントSNMP {length.attrs ?, message.elem}
message.elem = element version { length.attrs, xsd:int }, element community { length.attrs, xsd:hexBinary }, pdu.elem
message.elem =エレメントバージョン{length.attrs、XSD：INT}、素子コミュニティ{length.attrs、XSD：のhexBinary}、pdu.elem
message.elem |= element version { length.attrs, xsd:int }, element message { length.attrs, element msg-id { length.attrs, xsd:unsignedInt }, element max-size { length.attrs, xsd:unsignedInt }, element flags { length.attrs, xsd:hexBinary }, element security-model { length.attrs, xsd:unsignedInt } }, usm.elem?, element scoped-pdu { length.attrs, element context-engine-id { length.attrs, xsd:hexBinary }, element context-name { length.attrs, xsd:string }, pdu.elem }
message.elem | =エレメントバージョン{length.attrs、XSD：INT}、素子メッセージ{length.attrs、素子MSG-ID {length.attrs、XSD：unsignedInt型}、素子最大サイズ{length.attrs、XSD：unsignedInt型}、エレメントフラグ{length.attrs、XSD：のhexBinary}要素セキュリティモデル{length.attrs、XSD：unsignedInt型}}、usm.elem ?,素子スコープ-PDU {length.attrs、要素コンテキストエンジンID { length.attrs、XSD：のhexBinary}、要素コンテキスト名{length.attrs、XSD：文字列}、pdu.elem}
usm.elem = element usm {
usm.elem素子USM = {
length.attrs, element auth-engine-id { length.attrs, xsd:hexBinary }, element auth-engine-boots { length.attrs, xsd:unsignedInt }, element auth-engine-time { length.attrs, xsd:unsignedInt }, element user { length.attrs, xsd:hexBinary }, element auth-params { length.attrs, xsd:hexBinary }, element priv-params { length.attrs, xsd:hexBinary } }
length.attrs、要素のauth-エンジンID {length.attrs、XSD：のhexBinary}、要素のauth-エンジンブーツ{length.attrs、XSD：unsignedInt型}、要素のauth-エンジンタイム{length.attrs、XSD：unsignedInt型}、素子ユーザー{length.attrs、XSD：のhexBinary}、要素のauth-paramsは{length.attrs、XSD：のhexBinary}、素子PRIV-paramsは{length.attrs、XSD：のhexBinary}}
pdu.elem = element trap { length.attrs, element enterprise { length.attrs, oid.type }, element agent-addr { length.attrs, ipv4address.type }, element generic-trap { length.attrs, xsd:int }, element specific-trap { length.attrs, xsd:int }, element time-stamp { length.attrs, xsd:int }, element variable-bindings { length.attrs, varbind.elem* } }
pdu.elem =エレメントトラップ{length.attrs、素子企業{length.attrs、oid.type}、素子剤-ADDR {length.attrs、ipv4address.type}、素子汎用トラップ{length.attrs、XSD：INT} 、要素の特定のトラップ{length.attrs、XSD：INT}、素子タイムスタンプ{length.attrs、XSD：INT}、素子可変バインディング{length.attrs、varbind.elem *}}
pdu.elem |= element (get-request | get-next-request | get-bulk-request | set-request | inform-request | snmpV2-trap | response | report) { length.attrs, element request-id { length.attrs, xsd:int }, element error-status { length.attrs, xsd:int }, element error-index { length.attrs, xsd:int }, element variable-bindings { length.attrs, varbind.elem* } }
pdu.elem | =要素（取得要求|得る-NEXT要求|得るバルク要求を|設定要求|通知要求| SNMPv2のトラップ|応答|レポート）{length.attrs、要素リクエストID {長さ.attrs、XSD：INT}、要素エラーステータス{length.attrs、XSD：INT}、要素エラーインデックス{length.attrs、XSD：INT}、素子可変バインディング{length.attrs、varbind.elemの*} }
varbind.elem = element varbind { length.attrs, name.elem, value.elem }
varbind.elem =エレメントVARBIND {length.attrs、name.elem、value.elem}
name.elem = element name { length.attrs, oid.type }
name.elem =要素名{length.attrs、oid.type}
value.elem = element null { length.attrs, empty } | element integer32 { length.attrs, xsd:int } | element unsigned32 { length.attrs, xsd:unsignedInt } | element counter32 { length.attrs, xsd:unsignedInt } | element counter64 { length.attrs, xsd:unsignedLong } | element timeticks { length.attrs, xsd:unsignedInt } | element ipaddress { length.attrs, ipv4address.type } | element octet-string { length.attrs, xsd:hexBinary } | element object-identifier { length.attrs, oid.type } | element opaque { length.attrs, xsd:hexBinary } | element no-such-object { length.attrs, empty } | element no-such-instance { length.attrs, empty } | element end-of-mib-view { length.attrs, empty }
value.elem =エレメントヌル{length.attrs、空} |要素の構文Integer32 {length.attrs、XSD：int型} | {length.attrs、XSD：unsignedInt型} Unsigned32の要素|素子Counter32の{length.attrs、XSD：unsignedInt型} |素子Counter64の{length.attrs、XSD：なunsignedLong} |素子時間刻み{length.attrs、XSD：unsignedInt型} |要素IPアドレス{length.attrs、ipv4address.type} |要素のオクテット文字列{length.attrs、XSD：hexBinaryで} |要素オブジェクト識別子{length.attrs、oid.type} |要素の不透明{length.attrs、XSD：のhexBinary} |要素なしようなオブジェクト{length.attrs、空} |要素無ようインスタンス{length.attrs、空} |要素エンドの-MIB-図{length.attrs、空}
# The blen attribute indicates the number of octets used by the BER # encoded tag / length / value triple. The vlen attribute indicates # the number of octets used by the BER encoded value alone.
＃BLEN属性は三重BER位エンコードされたタグ/長さ/値によって使用されるオクテットの数を示します。 VLEN属性は、位に単独のBER符号化された値によって使用されるオクテットの数を示します。
length.attrs = ( attribute blen { xsd:unsignedShort }, attribute vlen { xsd:unsignedShort } )?
length.attrsは=（属性BLEN {XSD：なunsignedShort}、属性VLEN {XSD：なunsignedShort}）？
oid.type = xsd:string { pattern = "(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))" ~ "(\.(0|([1-9]\d*))){0,126}" }
oid.type = XSD：列{パターン=「（（[0-1]（\ [1-3] [0-9]））|（2.（0 |（[1-9] \ D *。？ ））））」〜 "（\（0 |。（[1-9] \ D *）））{0126}"}
# The types below are for IP addresses. Note that SNMP's buildin # IpAddress type only supports IPv4 addresses; IPv6 addresses are only # introduced to cover SNMP over IPv6 endpoints.
＃以下のタイプはIPアドレスのためのものです。 SNMPの建物＃IPアドレスタイプはIPv4アドレスのみをサポートしていることに注意してください。 IPv6アドレスだけ＃IPv6のエンドポイント上でSNMPをカバーするために導入されています。
ipv4address.type = xsd:string { pattern = "((0|(1[0-9]{0,2})" ~ "|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))\.){3}" ~ "(0|(1[0-9]{0,2})" ~ "|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))" }
ipv4address.type = XSD：列{パターン= "（（0 |（1 [0-9] {0,2}）" 〜「|（2（（[0-4] [0-9]）|（？ 5 [0-5]）|（[6-9]）））|？。（[3-9] [0-9]））\）{3} "〜"（0 |（1 [0 -9] {0,2}） "〜" |（2（（[0-4] [0-9]）|（5 [0-5]）|？（[6-9]））） |（？[3-9] [0-9]））」}
ipv6address.type = xsd:string { pattern = "(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|" ~ "(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?" }
ipv6address.type = XSD：列{パターン= "（（[0-9A-FA-F] +：）{7} [0-9A-FA-F] +）|" 〜「（（[0-9A-FA-F] +：）* [0-9A-FA-F] +）::（（[0-9A-FA-F] +：？）* [0-9A -fA-F] +）？」 }
ipaddress.type = ipv4address.type | ipv6address.type
ipaddress.type = ipv4address.type | ipv6address.type
The following example shows an SNMP trace file in XML format containing an SNMPv1 get-next-request message for the OID 1.3.6.1.2.1.1.3 (sysUpTime) and the response message returned by the agent.
次の例では、OID 1.3.6.1.2.1.1.3（のsysUpTime）およびエージェントによって返された応答メッセージのためのSNMPv1得る-NEXT-Requestメッセージを含むXML形式のSNMPトレースファイルを示しています。
<snmptrace xmlns="urn:ietf:params:xml:ns:snmp-trace-1.0"> <packet> <time-sec>1147212206</time-sec> <time-usec>739609</time-usec> <src-ip>192.0.2.1</src-ip> <src-port>60371</src-port> <dst-ip>192.0.2.2</dst-ip> <dst-port>12345</dst-port> <snmp blen="42" vlen="40"> <version blen="3" vlen="1">1</version> <community blen="8" vlen="6">7075626c6963</community> <get-next-request blen="29" vlen="27"> <request-id blen="6" vlen="4">1804289383</request-id> <error-status blen="3" vlen="1">0</error-status> <error-index blen="3" vlen="1">0</error-index> <variable-bindings blen="15" vlen="13"> <varbind blen="13" vlen="11"> <name blen="9" vlen="7">1.3.6.1.2.1.1.3</name> <null blen="2" vlen="0"/> </varbind> </variable-bindings> </get-next-request> </snmp> </packet> <packet> <time-sec>1147212206</time-sec> <time-usec>762891</time-usec> <src-ip>192.0.2.2</src-ip> <src-port>12345</src-port> <dst-ip>192.0.2.1</dst-ip> <dst-port>60371</dst-port> <snmp blen="47" vlen="45"> <version blen="3" vlen="1">1</version> <community blen="8" vlen="6">7075626c6963</community> <response blen="34" vlen="32"> <request-id blen="6" vlen="4">1804289383</request-id> <error-status blen="3" vlen="1">0</error-status> <error-index blen="3" vlen="1">0</error-index> <variable-bindings blen="20" vlen="18"> <varbind blen="18" vlen="16"> <name blen="10" vlen="8">1.3.6.1.2.1.1.3.0</name> <unsigned32 blen="6" vlen="4">26842224</unsigned32> </varbind> </variable-bindings> </response> </snmp> </packet> </snmptrace>
<Snmptraceののxmlns = "壷：IETF：のparams：XML：NS：snmptrace 1.0"> <パケット> <-time秒> 1147212206 </私の-秒> <時間USEC> 739 609 </私の-USEC> < SRC-IP> 192.0.2.1 </ SRC-IP> <SRC-port>は60 371 </ SRC-ポート> <DST-IP> 192.0.2.2 </ DST-IP> <DST-ポート> 12345 </ DSTポート> <SNMPは= "42" 適用さ= "40"> <バージョンを購入= "3" 適用= "1"> 1 </バージョン> <コミュニティが買う= "8" 適用= "6"> 7075626c6963 </コミュニティ>買います<GET-NEXT要求買う= "29" 適用さ= "27"> <リクエストID購入= "6" 印加= "4"> 1804289383 </リクエストID> <エラーステータスが購入= "3" =適用"1"> 0 </エラーステータス> <エラーインデックスが購入= "3" 適用= "1"> 0 </エラーインデックス> <変数バインディングが適用さ= "15" を購入= "13"> <VARBIND = "13" 適用さ= "11"> <購入名= "9" を適用= "7"> 1.3.6.1.2.1.1.3 </名前> <ヌルバイ= "2" は= "0" /> <適用買います> 762 891 / VARBIND> </変数バインディング> </取得 - 次の要求> </ SNMP> </パケット> <パケット> <-time秒> 1147212206 </私の-秒> <時間-USEC </時間を呼び出しますUSEC> <SRC-IP> 192.0.2.2 </ SRC-IP> <SRC-ポート> 12345 </ SRC-ポート> <DST-IP> 192.0.2.1 </ DST-IP> <ポート-DST> 60 371 </ DSTポート> <SNMPが適用さ= "47" を購入= "45"> <= "3" 適用= "1"> 1 </詩バージョンを購入します> <コミュニティが購入に= "8" = "6"> 7075626c6963 </コミュニティ> <応答が= "34" を購入= "32"> <リクエストIDが購入適用適用= "6" = "4"> 1804289383を適用< /リクエストID> <エラーステータス買う= "3" 適用= "1"> 0 </エラーステータス> <エラーインデックス買う= "3" 適用= "1"> 0 </エラーインデックス> <変数バインディング= "20" 適用さ= "18"> <VARBIND買う= "18" 適用さ= "16"> <購入名= "10" は= "8"> 1.3.6.1.2.1.1.3.0を<適用買います/名前> <Unsigned32の買い= "6" 印加= "4"> 26842224 </ Unsigned32の> </ VARBIND> </変数バインディング> </レスポンス> </ SNMP> </パケット> </ snmptrace>
The comma-separated values (CSV) format has been designed to capture only the most relevant information about an SNMP message. In situations where all information about an SNMP message must be captured, the XML format defined above must be used. The CSV format uses the following fields:
カンマ区切り値（CSV）フォーマットは、SNMPメッセージについてのみ、最も関連性の高い情報を捕捉するように設計されています。 SNMPメッセージに関するすべての情報が捕捉されなければならない状況では、上記で定義されたXML形式が使用されなければなりません。 CSV形式は、次のフィールドを使用しています：
1. Timestamp in the format seconds.microseconds since 1970, for example, "1137764769.425484".
1970年以降、フォーマットseconds.microseconds 1.タイムスタンプ、例えば、「1137764769.425484」。
2. Source IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
2.送信元IP点線クワッド表記（IPv4）の内のアドレス、例えば、 "192.0.2.1"、またはコンパクト16進数（IPv6）の、例えば、 "2001：DB8 :: 1"。
3. Source port number represented as a decimal number, for example, "4242".
進数、例えば、「4242」と表記3元ポート番号。
4. Destination IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
4.宛先IPの点線クワッド表記（IPv4）の内のアドレス、例えば、 "192.0.2.1"、またはコンパクト16進数（IPv6）の、例えば、 "2001：DB8 :: 1"。
5. Destination port number represented as a decimal number, for example, "161".
進数、例えば、「161」として表さ5.宛先ポート番号。
6. Size of the SNMP message (a decimal number) counted in octets, for example, "123". The size excludes all transport, network, and link-layer headers.
例えば、オクテットでカウントSNMPメッセージの6サイズ（10進数）、「123」。サイズは、すべてのトランスポート、ネットワーク、およびリンク層ヘッダを除外する。
7. SNMP message version represented as a decimal number. The version 0 stands for SNMPv1, 1 for SNMPv2c, and 3 for SNMPv3, for example, "3".
10進数で表される7 SNMPメッセージバージョン。バージョン0のSNMPv1を表し、SNMPv2cのための1、およびSNMPv3の3は、例えば、 "3"。
8. SNMP protocol operation indicated by one of the keywords get-request, get-next-request, get-bulk-request, set-request, trap, snmpV2-trap, inform-request, response, report.
8. SNMPプロトコルの動作は、キーワード取得要求、取得 - 次の要求を取得し、バルク要求、設定要求、トラップ、SNMPv2のトラップ、通知要求、応答、レポートのいずれかによって示されます。
12. Number of variable-bindings contained in the varbind-list in decimal notation, for example, "5".
、「5」は、例えば10進数でVARBINDリストに含まれる変数バインディングの12数。
13. For each varbind in the varbind list, three output elements are generated:
varbindリスト内の各VARBINDについて13は、3つの出力要素が生成されます。
1. Object name given as object identifier in dotted decimal
notation, for example, "1.3.6.1.2.1.1.3.0".
2. Object base type name or exception name, that is one of the following: null, integer32, unsigned32, counter32, counter64, timeticks, ipaddress, octet-string, object-identifier, opaque, no-such-object, no-such-instance, and end-of-mib-view.
2.オブジェクトベースタイプ名または例外名、それは次のいずれか：ヌル、Integer32の、Unsigned32の、Counter32の、Counter64の、時間刻み、IPアドレス、オクテットストリング、オブジェクト識別子、不透明、無例えばオブジェクト、無よう-instance、及びエンド・オブ・MIBビュー。
3. Object value is printed as a number if the underlying base type is numeric. An IPv4 addresses is rendered in the dotted quad notation and an IPv6 address is rendered in the usual hexadecimal notation. An octet string value is printed in hexadecimal format while an object identifier value is printed in dotted decimal notation. In case of an exception, the object value is empty.
3.オブジェクトの値は、基礎となる基本型は数値であれば数として印刷されます。 IPv4アドレスは、ドットクワッド表記でレンダリングされたIPv6アドレスは、通常の16進表記でレンダリングされます。オブジェクト識別子の値をドット十進表記で印刷されている間オクテットストリング値は、16進形式で印刷されています。例外の場合には、オブジェクトの値は空です。
Note that the format does not preserve the information needed to understand SNMPv1 traps. It is therefore recommended that implementations be able to convert the SNMPv1 trap format into the trap format used by SNMPv2c and SNMPv3, according to the rules defined in [RFC3584]. The activation of trap format conversion should be the user's choice.
フォーマットは、SNMPv1トラップを理解するために必要な情報を保持しないことに注意してください。従って、実装が[RFC3584]で定義されたルールに従って、SNMPv2cのおよびSNMPv3で使用トラップフォーマットにSNMPv1トラップ形式を変換することができることをお勧めします。トラップフォーマット変換の活性化は、ユーザーの選択する必要があります。
The following example shows an SNMP trace file in CSV format containing an SNMPv1 get-next-request message for the OID 1.3.6.1.2.1.1.3 (sysUpTime) and the response message returned by the agent. (Note that the example uses backslash line continuation marks in order to fit the example into the RFC format. Backslash line continuations are not part of the CSV format.)
次の例では、OID 1.3.6.1.2.1.1.3（のsysUpTime）およびエージェントによって返された応答メッセージのためのSNMPv1得る-NEXT-Requestメッセージを含むCSV形式でSNMPトレースファイルを示しています。 （例では、RFC形式に例に適合するために、バックスラッシュ行継続マークを使用することに注意してください。バックスラッシュライン継続は、CSVフォーマットの一部ではありません。）
1147212206.739609,192.0.2.1,60371,192.0.2.2,12345,42,1,\ get-next-request,1804289383,0,0,1,1.3.6.1.2.1.1.3,null, 1147212206.762891,192.0.2.2,12345,192.0.2.1,60371,47,1,\ response,1804289383,0,0,1,1.3.6.1.2.1.1.3.0,timeticks,26842224
1147212206.739609,192.0.2.1,60371,192.0.2.2,12345,42,1、\ GET-NEXT要求、1804289383,0,0,1,1.3.6.1.2.1.1.3、ヌル、1147212206.762891,192.0.2.2,12345 、192.0.2.1,60371,47,1、\応答、1804289383,0,0,1,1.3.6.1.2.1.1.3.0、時間刻み、26842224
SNMP traffic traces usually contain sensitive information. It is therefore necessary to (a) remove unwanted information and (b) to anonymize the remaining necessary information before traces are made available for analysis. It is recommended to encrypt traces when they are archived.
SNMPトラフィックのトレースは通常、機密情報が含まれています。これは、（a）は、不要な情報を削除して、トレースが分析のために利用可能になる前に、（b）は、残りの必要な情報を匿名化することが必要です。それらがアーカイブされたときにトレースを暗号化することをお勧めします。
Implementations that generate CSV or XML traces from raw pcap files should have an option to suppress or anonymize values. Note that instance identifiers of tables also include values, and it might therefore be necessary to suppress or anonymize (parts of) the instance identifiers. Similarly, the packet and message headers typically contain sensitive information about the source and destination of SNMP messages as well as authentication information (community strings or user names).
生のpcapファイルからCSVやXMLトレースを生成する実装は値を抑制または匿名化するためのオプションを持っている必要があります。注テーブルのインスタンス識別子はまた、値を含み、そしてそれ故、インスタンス識別子（の部分）を抑制又は匿名化することが必要かもしれません。同様に、パケット及びメッセージヘッダは、典型的に敏感なSNMPメッセージのソースおよび宛先に関する情報、並びに認証情報（コミュニティストリングまたはユーザ名）を含みます。
Anonymization techniques can be applied to keep information in traces that could otherwise reveal sensitive information. When using anonymization, values should only be kept when the underlying data type is known and an appropriate anonymization transformation is available (filter-in principle). For values appearing in instance identifiers, it is usually desirable to maintain the lexicographic order. Special anonymization transformations that preserve this property have been developed, although their anonymization strength is usually reduced compared to transformations that do not preserve lexicographic ordering [HS06].
匿名化技術は、そうでない場合は、機密情報を明らかにすることができトレースに情報を保持するために適用することができます。匿名を使用する場合、基礎となるデータ・タイプが知られており、適切な匿名化変換は、（フィルタ原理）が利用可能である場合、値のみ維持されるべきです。インスタンス識別子に現れる値の場合、通常辞書式順序を維持することが望ましいです。彼らの匿名化強度は通常、辞書式順序[HS06]を保存しないの変換と比較して減少しているものの、このプロパティを保持する特別な匿名化変換は、開発されています。
The meta data associated with traces and in particular information about the organization owning a network and the description of the measurement point in the network topology where a trace was collected may be misused to decide/pinpoint where and how to attack a network. Meta data therefore needs to be properly protected.
メタネットワークを所有している組織に関するトレース特に情報に関連付けられたデータとトレースが収集されたネットワークトポロジーにおける測定点の記述は、/ピンポイントどこで、どのようにネットワークを攻撃することを決定するために悪用されることがあります。メタデータは、したがって、適切に保護する必要があります。
Per this document, IANA has registered a URI for the SNMP XML trace format namespace in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration has been made:
このドキュメントごとに、IANAはIETF XMLレジストリ[RFC3688]でSNMP XMLトレースフォーマットの名前空間のURIを登録しています。 RFC 3688でフォーマットした後、以下の登録が行われています。
URI: "urn:ietf:params:xml:ns:snmp-trace-1.0"
URI： "URN：IETF：のparams：XML：NS：SNMPトレース-1.0"
Registrant Contact: The NMRG of the IRTF.
登録者連絡先：IRTFのNMRG。
XML: N/A, the URI is an XML namespace.
XML：N / A、URIは、XML名前空間です。
This document was influenced by discussions within the Network Management Research Group (NMRG). Special thanks to Remco van de Meent for writing the initial Perl script that lead to the development of the snmpdump software package and Matus Harvan for his work on lexicographic order preserving anonymization transformations. Aiko Pras contributed ideas to Section 3 while David Harrington helped to improve the readability of this document.
この文書は、ネットワーク管理研究グループ（NMRG）内の議論に影響を受けました。匿名化保存変換辞書順での彼の仕事のためのsnmpdumpソフトウェアパッケージとMatus Harvanの開発につながる最初のPerlスクリプトを書くためのレムコ・ファン・デ・Meentに感謝します。デヴィッドハリントンは、この文書の読みやすさを向上させるために貢献しながら、愛子PRASは、第3節にアイデアを貢献しました。
Last call reviews have been received from Bert Wijnen, Aiko Pras, Frank Strauss, Remco van de Meent, Giorgio Nunzi, Wes Hardacker, Liam Fallon, Sharon Chisholm, David Perkins, Deep Medhi, Randy Bush, David Harrington, Dan Romascanu, Luca Deri, and Marc Burgess. Karen R.
ラストコールレビューはバートWijnen、愛子PRAS、フランク・シュトラウス、レムコ・ファン・デ・Meent、ジョルジオNunzi、ウェス・ハードアッカー、リアム・ファロン、シャロン・チザム、デビッド・パーキンス、ディープMedhi、ランディブッシュ、デヴィッドハリントン、ダンRomascanu、ルカデリから受信されています、そしてマルク・バージェス。カレンR.
Sollins reviewed the document for the Internet Research Steering Group (IRSG). Jari Arkko, Pasi Eronen, Chris Newman, and Tim Polk provided helpful comments during the Internet Engineering Steering Group (IESG) review.
Sollinsはインターネットリサーチの運営グループ（IRSG）のための文書を検討しました。ヤリArkko、パシEronen、クリス・ニューマン、およびティムポークは、インターネットエンジニアリング運営グループ（IESG）レビュー時に役に立つコメントを提供しました。
Part of this work was funded by the European Commission under grant FP6-2004-IST-4-EMANICS-026854-NOE.
この作品の一部が助成金FP6-2004-IST-4-EMANICS-026854-NOEの下で、欧州委員会によって資金を供給されました。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[OASISRNG] Clark, J. and M. Makoto, "RELAX NG Specification", OASIS Committee Specification, December 2001.
【OASISRNG]クラーク、J.とM.誠、OASIS委員会仕様、2001年12月 "NG仕様RELAX"。
[OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002.
[OASISRNC]クラーク、J.、OASIS委員会仕様、2002年11月 "NGコンパクト構文をRELAX"。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、BCP 74、RFC 3584 、2003年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC1052] Cerf, V., "IAB Recommendations for the development of Internet network management standards", RFC 1052, April 1998.
[RFC1052]サーフ、V.、 "インターネットネットワークマネージメント規格の開発のためのIABの提言"、RFC 1052、1998年4月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R.、エド。、 "管理情報ベース（MIB）簡易ネットワーク管理プロトコル（SNMP）のために"、STD 62、RFC 3418、2002年12月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022] Raghunarayan、R.、 "伝送制御プロトコルのための管理情報ベース（TCP）"、RFC 4022、2005年3月。
[PDMQ04] Pras, A., Drevers, T., van de Meent, R., and D. Quartel, "Comparing the Performance of SNMP and Web Services based Management", IEEE Transactions on Network and Service Management 1(2), November 2004.
[PDMQ04] PRAS、A.、Drevers、T.、バン・デ・Meent、R.、およびD. Quartelは、ネットワークとサービスの管理1（2）に、IEEEトランザクション "SNMPのパフォーマンスとWebサービスベースの管理の比較"、 2004年11月。
[Pat01] Pattinson, C., "A Study of the Behaviour of the Simple Network Management Protocol", Proc. 12th IFIP/IEEE Workshop on Distributed Systems: Operations and Management , October 2001.
[Pat01]パティンソン、C.、PROC「簡易ネットワーク管理プロトコルの挙動の研究」。第12回分散システムIFIP / IEEEワークショップ：運用と管理、2001年10月。
[DSR01] Du, X., Shayman, M., and M. Rozenblit, "Implementation and Performance Analysis of SNMP on a TLS/TCP Base", Proc. 7th IFIP/IEEE International Symposium on Integrated Network Management , May 2001.
[DSR01]デュ、X.、Shayman、M.、およびM. Rozenblit、 "実装およびTLS / TCPベースのSNMPのパフォーマンス分析"、PROC。統合ネットワーク管理、2001年5月第7回IFIP / IEEE国際シンポジウム。
[CT04] Corrente, A. and L. Tura, "Security Performance Analysis of SNMPv3 with Respect to SNMPv2c", Proc. 2004 IEEE/IFIP Network Operations and Management Symposium , April 2004.
[CT04] Corrente、A.、およびL.トゥーラ、 "SNMPv2cのに対して、SNMPv3のセキュリティのパフォーマンス分析"、PROC。 2004 IEEE / IFIPネットワーク運用と管理シンポジウム、2004年4月。
[PFGL04] Pavlou, G., Flegkas, P., Gouveris, S., and A. Liotta, "On Management Technologies and the Potential of Web Services", IEEE Communications Magazine 42(7), July 2004.
[PFGL04] Pavlou、G.、Flegkas、P.、Gouveris、S.、およびA.リオッタ、 "管理技術とWebサービスの可能性について"、IEEE通信誌42（7）、2004年7月。
[SM99] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB Data", Simple Times 7(1), March 1999.
[SM99] Sprenkels、R.及びJ.マーティンFlatin、 "MIBデータのバルク転送"、シンプルタイムズ7（1）、1999年3月。
[Mal02] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), December 2002.
[Mal02] Malowidzki、M.、 "のGetBulk価値修正"、シンプルタイムズ10（1）、2002年12月。
[HS06] Harvan, M. and J. Schoenwaelder, "Prefix- and Lexicographical-order-preserving IP Address Anonymization", IEEE/IFIP Network Operations and Management Symposium NOMS 2006, April 2006.
[HS06] Harvan、M.とJ. Schoenwaelder、 "Prefix-と辞書的順序保存IPアドレスの匿名化"、IEEE / IFIPネットワーク運用と管理シンポジウムNOMS 2006、2006年4月。
[XFA02] Xu, J., Fan, J., and M. Ammar, "Prefix-Preserving IP Address Anonymization: Measurement-based Security Evaluation and a New Cryptography-based Scheme", 10th IEEE International Conference on Network Protocols ICNP'02, November 2002.
[XFA02]徐、J.、ファン、J.、およびM.アマル、「プレフィックス保存IPアドレスの匿名化：測定に基づくセキュリティ評価及び新暗号ベースのスキーム」、第10回IEEE国際会議ネットワークプロトコルICNP'02に、2002年11月。
[FXAM04] Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-Preserving IP Address Anonymization", Computer Networks 46(2), October 2004.
[FXAM04]ファン、J.、徐、J.、アマル、M.、およびS.月、 "プレフィックス保存IPアドレスの匿名化"、コンピュータネットワーク46（2）、2004年10月。
[PAPL06] Pang, R., Allman, M., Paxson, V., and J. Lee, "The Devil and Packet Trace Anonymization", Computer Communication Review 36(1), January 2006.
[PAPL06]パン、R.、オールマン、M.、パクソン、V.、およびJ.リー、 "悪魔とパケットトレース匿名化"、コンピュータコミュニケーションレビュー36（1）、2006年1月。
[RW07] Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving IP Address Anonymization for Passive Measurement Systems", IEEE Transactions on Networking 15(1), February 2007.
[RW07]ラマスワミ、R.とT.ウルフ、「パッシブ計測システムのための高速プレフィックス保存IPアドレスの匿名化」、ネットワーク15上のIEEEトランザクション（1）、2007年2月。
URIs
URI
[1] <http://en.wikipedia.org/wiki/Pcap>
「１」 ＜ｈっｔｐ：／／えん。うぃきぺぢあ。おｒｇ／うぃき／Ｐかｐ＞
[2] <http://www.tcpdump.org/>
「２」 ＜ｈっｔｐ：／／ｗっｗ。ｔｃｐづｍｐ。おｒｇ／＞
[3] <http://www.wireshark.org/>
「３」 ＜ｈっｔｐ：／／ｗっｗ。うぃれしゃｒｋ。おｒｇ／＞
[4] <http://www.datcat.org/>
「４」 ＜ｈっｔｐ：／／ｗっｗ。だｔかｔ。おｒｇ／＞
[5] <https://svn.eecs.jacobs-university.de/svn/schoenw/src/snmpdump>
「５」 ＜ｈっｔｐｓ：／／ｓｖん。ええｃｓ。じゃこｂｓーうにゔぇｒしｔｙ。で／ｓｖん／ｓちょえんｗ／ｓｒｃ／ｓんｍｐづｍｐ＞
[6] <http://xmlsoft.org/XSLT/>
「６」 ＜ｈっｔｐ：／／ｘｍｌそｆｔ。おｒｇ／ＸＳＬＴ／＞
[7] <http://perl-xml.sourceforge.net/faq/>
「７」 ＜ｈっｔｐ：／／ぺｒｌーｘｍｌ。そうｒせふぉｒげ。ねｔ／ふぁｑ／＞
[8] <http://www.relaxng.org/>
「８」 ＜ｈっｔｐ：／／ｗっｗ。れぁんｇ。おｒｇ／＞
Author's Address
著者のアドレス
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
ユルゲンSchoenwaelderジェイコブス大学ブレーメンキャンパスリング1 28725ブレーメンドイツ
Phone: +49 421 200-3587 EMail: j.schoenwaelder@jacobs-university.de
電話：+49 421 200-3587 Eメール：j.schoenwaelder@jacobs-university.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びhttp://www.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。