Network Working Group A. Okmianski
Request for Comments: 5426 Cisco Systems, Inc.
Category: Standards Track March 2009
Transmission of Syslog Messages over UDP
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping.
この文書では、UDP / IPv4またはUDP / IPv6を介しsyslogメッセージの転送を説明しています。 syslogプロトコル階層化アーキテクチャは、トランスポートマッピングの任意の数のサポートのために用意されています。ただし、相互運用性の目的のためには、Syslogプロトコルの実装は、このトランスポートマッピングをサポートするために必要とされます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Transport Protocol ..............................................3
3.1. One Message Per Datagram ...................................3
3.2. Message Size ...............................................3
3.3. Source and Target Ports ....................................4
3.4. Source IP Address ..........................................4
3.5. UDP/IP Structure ...........................................4
3.6. UDP Checksums ..............................................4
4. Reliability Considerations ......................................5
4.1. Lost Datagrams .............................................5
4.2. Message Corruption .........................................5
4.3. Congestion Control .........................................5
4.4. Sequenced Delivery .........................................5
5. Security Considerations .........................................6
5.1. Sender Authentication and Message Forgery ..................6
5.2. Message Observation ........................................7
5.3. Replaying ..................................................7
5.4. Unreliable Delivery ........................................7
5.5. Message Prioritization and Differentiation .................7
5.6. Denial of Service ..........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Informational RFC 3164 [8] describes the syslog protocol as it was observed in existing implementations. It describes both the format of syslog messages and a UDP [1] transport. Subsequently, a Standards-Track syslog protocol has been defined in RFC 5424 [2].
それは既存の実装で観察されたように、情報RFC 3164 [8]のsyslogプロトコルを記載しています。これは、syslogメッセージのフォーマットおよびUDP [1]輸送の両方を説明しています。その後、標準化過程のsyslogプロトコルはRFC 5424で定義されている[2]。
RFC 5424 specifies a layered architecture that provides for support of any number of transport layer mappings for transmitting syslog messages. This document describes the UDP transport mapping for the syslog protocol.
RFC 5424には、syslogメッセージを送信するためのトランスポート層のマッピングの任意の数のサポートを提供階層化アーキテクチャを指定します。この文書は、syslogプロトコルのUDPトランスポートマッピングを説明しています。
The transport described in this document can be used for transmitting syslog messages over both IPv4 [3] and IPv6 [4].
本書では説明輸送は、IPv4 [3]とIPv6の両方の上にsyslogメッセージを送信するために使用することができる[4]。
Network administrators and architects should be aware of the significant reliability and security issues of this transport, which stem from the use of UDP. They are documented in this specification. However, this transport is lightweight and is built upon the existing popular use of UDP for syslog.
ネットワーク管理者やアーキテクトは、UDPの使用から生じるこの輸送の重要な信頼性とセキュリティの問題、注意する必要があります。彼らは、この仕様書に記載されています。しかし、このトランスポートは、軽量で、syslogのためのUDPの既存の一般的な使用に基づいて構築されています。
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 [5].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[5]。
Each syslog UDP datagram MUST contain only one syslog message, which MAY be complete or truncated. The message MUST be formatted and truncated according to RFC 5424 [2]. Additional data MUST NOT be present in the datagram payload.
各Syslog UDPデータグラムは、完全または切り捨てられる可能性が唯一のsyslogメッセージを、含まなければなりません。メッセージは、RFC 5424に従ってフォーマットおよび切り捨てなければならない[2]。追加データは、データグラムのペイロード中に存在してはなりません。
This transport mapping supports transmission of syslog messages up to 65535 octets minus the UDP header length. This limit stems from the maximum supported UDP size of 65535 octets specified in RFC 768 [1]. For IPv4, the maximum payload size is 65535 octets minus the UDP header and minus the IP header because IPv4 has a 16-bit length field that also includes the header length.
このトランスポートマッピングは65535オクテットマイナスUDPヘッダ長までのsyslogメッセージの送信をサポートしています。この制限は、RFC 768 [1]で指定65535オクテットの最大サポートされているUDPサイズに由来します。 IPv4のはまた、ヘッダ長を含む16ビットの長さフィールドを持っているのでIPv4の場合、最大ペイロードサイズが65535オクテットマイナスUDPヘッダとマイナスIPヘッダです。
IPv4 syslog receivers MUST be able to receive datagrams with message sizes up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message sizes up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams with message sizes of up to and including 2048 octets. The ability to receive larger messages is encouraged.
IPv4 syslogの受信機は、最大サイズと480個のオクテットを含むメッセージをデータグラムを受け取ることができなければなりません。 IPv6 syslogの受信機は、最大サイズ1180個のオクテットを含むメッセージをデータグラムを受け取ることができなければなりません。すべてのsyslog受信機は、最大2048オクテットを含むのメッセージサイズでデータグラムを受信することができます。大きなメッセージを受信する機能が奨励されます。
The above restrictions and recommendations establish a baseline for interoperability. The minimum required message size support was determined based on the minimum MTU size that Internet hosts are required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 [4]. Datagrams that conform to these limits have the greatest chance of being delivered because they do not require fragmentation.
上記の制限および推奨事項は、相互運用性のためのベースラインを確立します。最低限必要なメッセージサイズをサポートは、インターネットホストをサポートするために必要な最小のMTUサイズに基づいて決定した：IPv4の576オクテット[3]とIPv6 1280オクテット[4]。彼らは断片化を必要としないため、これらの制限に準拠してデータグラムが配信されるの最大のチャンスがあります。
It is RECOMMENDED that syslog senders restrict message sizes such that IP datagrams do not exceed the smallest MTU of the network in use. This avoids datagram fragmentation and possible issues surrounding fragmentation such as incorrect MTU discovery.
syslogの送信者がメッセージをIPデータグラムは、使用中のネットワークの最小MTUを超えないようにサイズを制限することをお勧めします。これは、データグラムの断片化と、このような間違ったMTUディスカバリとして断片化を取り巻く潜在的な問題を回避できます。
Fragmentation can be undesirable because it increases the risk of the message being lost due to loss of just one datagram fragment. Syslog has no acknowledgement facility, and therefore there is no effective way to handle retransmission. This makes it impossible for syslog to utilize packetization layer path MTU discovery [9]. When network MTU is not known in advance, the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6.
それにより、ひとつのデータグラムフラグメントの損失に失われるメッセージのリスクを増大させるため、断片化が望ましくないとすることができます。 syslogは肯定応答機能を持っていないので、再送を処理するための効果的な方法はありません。これは、syslogは、パケットレイヤパスMTUディスカバリを利用することができなくなります[9]。ネットワークMTUが事前に知られていない場合は、最も安全な仮定は、IPv4のための480オクテットとIPv6のための1180個のオクテットにメッセージを制限することです。
Syslog receivers MUST support accepting syslog datagrams on the well-known UDP port 514, but MAY be configurable to listen on a different port. Syslog senders MUST support sending syslog message datagrams to the UDP port 514, but MAY be configurable to send messages to a different port. Syslog senders MAY use any source UDP port for transmitting messages.
Syslogの受信機は、よく知られたUDPポート514上のsyslogデータグラムを受け入れてサポートしなければならないが、別のポートをリッスンするように構成可能です。 Syslogの送信者は、UDPポート514へのsyslogメッセージのデータグラムの送信をサポートしなければならないが、別のポートにメッセージを送信するように構成してもよい（MAY）。 Syslogの送信者は、メッセージを送信するための任意の送信元UDPポートを使用するかもしれません。
The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host that originated the syslog message. The entity sending the syslog message could be merely a relay. The syslog message itself contains the identifier of the originator of the message.
UDPデータグラムの送信元IPアドレスは、syslogメッセージを発信したホストの識別子として解釈されるべきではありません。 Syslogメッセージを送信エンティティは、単にリレーである可能性があります。 syslogのメッセージ自体は、メッセージの発信者の識別子が含まれています。
Each UDP/IP datagram sent by the transport layer MUST completely adhere to the structure specified in the UDP RFC 768 [1] and either the IPv4 RFC 791 [3] or IPv6 RFC 2460 [4], depending on which protocol is used.
トランスポート層によって送信された各UDP / IPデータグラムが完全UDP RFC 768で指定された構造に準拠する必要があり[1]、いずれかのIPv4 RFC 791 [3]またはIPv6 RFC 2460 [4]は、使用されるプロトコルに応じ。
Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums when sending messages. Note that RFC 2460 [4] mandates the use of UDP checksums when sending UDP datagrams over IPv6.
Syslogの送信者は、UDPチェックサムを無効にしてはなりません。メッセージを送信するときのIPv4 syslogの送信者は、UDPチェックサムを使用すべきです。そのRFC 2460 IPv6の上にUDPデータグラムを送信する場合、[4] UDPチェックサムの使用を義務付けに注意してください。
Syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog receivers SHOULD check UDP checksums and SHOULD accept a syslog message with a zero checksum. Note that RFC 2460 [4] mandates the use of checksums for UDP over IPv6.
Syslogの受信機は、UDPチェックサムのチェックを無効にしてはなりません。 IPv4 syslogの受信機は、UDPチェックサムを確認する必要がありますし、ゼロのチェックサムとのSyslogメッセージを受け入れる必要があります。 RFC 2460 [4] IPv6を介しUDPのチェックサムの使用を義務付けていることに注意してください。
The UDP is an unreliable, low-overhead protocol. This section discusses reliability issues inherent in UDP that implementers and users should be aware of.
UDPは信頼性の低い、低オーバーヘッドのプロトコルです。このセクションでは、実装者とユーザーが知っておくべきUDPに固有の信頼性の問題について説明します。
This transport mapping does not provide any mechanism to detect and correct loss of datagrams. Datagrams can be lost in transit due to congestion, corruption, or any other intermittent network problem. IP fragmentation exacerbates this problem because loss of a single fragment will result in the entire message being discarded.
このトランスポートマッピングを検出し、データグラムの正しい喪失する任意のメカニズムを提供しません。データグラムは、輻輳、破損、またはその他の断続的なネットワークの問題に輸送中に紛失することができます。単一フラグメントの損失がメッセージ全体が廃棄されることになるので、IPフラグメンテーションは、この問題を悪化させます。
The UDP/IP datagrams can get corrupted in transit due to software, hardware, or network errors. This transport mapping specifies use of UDP checksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols. However, checksums do not guarantee corruption detection, and this transport mapping does not provide for message acknowledgement or retransmission mechanism.
UDP / IPデータグラムが原因ソフトウェア、ハードウェア、またはネットワークエラーのために輸送中に破損することができます。このトランスポートマッピングはIPで使用されるチェックサムおよびレイヤ2プロトコルに加えて、破損検出を可能にするためにUDPチェックサムの使用を指定します。しかし、チェックサムが破損検出を保証するものではありませんし、このトランスポートマッピングは、メッセージの確認や再送メカニズムのために用意されていません。
Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet [6]. This is why the syslog TLS transport [7] is REQUIRED to implement and RECOMMENDED for general use.
syslogのは、データの無制限の量を生成することができますので、UDPは輻輳制御メカニズムがないため、UDPを介してこのデータを転送することは、一般的に問題があります。トラフィックレートを低減することによって、輻輳に応答し、同じ経路を共有するフロー間の公平性の程度を確立する輻輳制御メカニズムは、[6]、インターネットの安定動作に不可欠です。 [7]のsyslog TLSトランスポートを実装するために必要と一般的な使用は推奨されているのはこのためです。
The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport [7] SHOULD be used.
syslogのUDPトランスポートはTLS輸送の代替として使用されるかもしれのみの環境では、ネットワーク・パスを明示的な速度制限や容量の予約などのトラフィックエンジニアリングメカニズムを介して、UDPのsyslogトラフィック用にプロビジョニングされたネットワークを、管理されています。他のすべての環境では、[7] TLSトランスポートを使用すべきです。
The IP transport used by the UDP does not guarantee that the sequence of datagram delivery will match the order in which the datagrams were sent. The time stamp contained within each syslog message can serve as a rough guide in establishing sequence order. However, it will not help in cases where multiple messages were generated during the same time slot, the sender could not generate a time stamp, or messages originated from different hosts whose clocks were not synchronized. The order of syslog message arrival via this transport SHOULD NOT be used as an authoritative guide in establishing an absolute or relative sequence of events on the syslog sender hosts.
UDPが使用するIPトランスポートは、データグラムの配信のシーケンスはデータグラムが送信された順序と一致することを保証するものではありません。各ログメッセージ内に含まれるタイムスタンプは、シーケンス順序を確立する目安として働くことができます。しかし、それは複数のメッセージが送信者は、タイムスタンプを生成することができませんでした、同じタイムスロットの間に発生した、またはメッセージがそのクロック同期されませんでした別のホストから発信された場合には助けにはなりません。このトランスポートを介して、システムログメッセージの到着の順序は、syslog送信元ホストのイベントの絶対的または相対的な順序を確立する権限のガイドとして使用することはできません。
Using this specification on an unsecured network is NOT RECOMMENDED. Several syslog security considerations are discussed in RFC 5424 [2]. This section focuses on security considerations specific to the syslog transport over UDP. Some of the security issues raised in this section can be mitigated through the use of IPsec as defined in RFC 4301 [10].
保護されていないネットワーク上でこの仕様を使用することは推奨されません。いくつかのsyslogのセキュリティの考慮事項は、RFC 5424で説明されている[2]。このセクションでは、UDP上のsyslogトランスポートに固有のセキュリティ上の考慮事項に焦点を当てています。 RFC 4301 [10]で定義されるように、このセクションで提起されたセキュリティ上の問題のいくつかは、IPsecを使用して緩和することができます。
This transport mapping does not provide for strong sender authentication. The receiver of the syslog message will not be able to ascertain that the message was indeed sent from the reported sender, or whether the packet was sent from another device. This can also lead to a case of mistaken identity if an inappropriately configured machine sends syslog messages to a receiver representing itself as another machine.
このトランスポートマッピングは、強力な送信者認証のために用意されていません。シスログメッセージの受信側は、メッセージが実際に報告された送信者から送信されたこと、またはパケットを他の装置から送信されたか否かを確認することができません。不適切構成されたマシンが別のマシンとしての地位を表すレシーバにsyslogメッセージを送信した場合にも人違いのケースにつながることができます。
This transport mapping does not provide protection against syslog message forgery. An attacker can transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a receiver.
このトランスポートマッピングは、syslogメッセージ偽造に対する保護を提供していません。攻撃者は、受信機に（メッセージがうわさによれば送信されるマシンまたは他のマシンからのいずれか）syslogメッセージを送信することができます。
In one case, an attacker can hide the true nature of an attack amidst many other messages. As an example, an attacker can start generating forged messages indicating a problem on some machine. This can get the attention of the system administrators, who will spend their time investigating the alleged problem. During this time, the attacker could be able to compromise a different machine or a different process on the same machine.
あるケースでは、攻撃者は、他の多くのメッセージに囲まれた攻撃の本質を隠すことができます。一例として、攻撃者は、いくつかのマシン上の問題を示す偽造メッセージの生成を開始することができます。これは、申し立てられた問題を調査して自分の時間を過ごすことになります、システム管理者の注意を引くことができます。この間、攻撃者は別のマシンまたは同じマシン上の異なるプロセスを妥協することである可能性があります。
Additionally, an attacker can generate false syslog messages to give untrue indications of the status of systems. As an example, an attacker can stop a critical process on a machine, which could generate a notification of exit. The attacker can subsequently generate a forged notification that the process had been restarted. The system administrators could accept that misinformation and not verify that the process had indeed not been restarted.
また、攻撃者はシステムのステータスの虚偽表示を与えるために虚偽のSyslogメッセージを生成することができます。一例として、攻撃者は、出口の通知を生成することができるマシン上で重要なプロセスを停止することができます。攻撃者は、その後、プロセスが再開されていた偽造通知を生成することができます。システム管理者は、その誤った情報を受け入れ、プロセスが実際に再起動されていないことを確認できませんでした。
This transport mapping does not provide confidentiality of the messages in transit. If syslog messages are in clear text, this is how they will be transferred. In most cases, passing clear-text, human-readable messages is a benefit to the administrators. Unfortunately, an attacker could also be able to observe the human-readable contents of syslog messages. The attacker could then use the knowledge gained from these messages to compromise a machine. It is RECOMMENDED that no sensitive information be transmitted via this transport mapping or that transmission of such information be restricted to properly secured networks.
このトランスポート・マッピングは、輸送中のメッセージの機密性を提供していません。 syslogメッセージがクリアテキストである場合、これは、彼らが転送される方法です。ほとんどの場合、クリアテキスト、人間が読めるメッセージを渡すことは、管理者にとって有益です。残念ながら、攻撃者はまた、syslogメッセージの人間が読めるコンテンツを観察することができる可能性があります。その後、攻撃者はマシンを侵害するためにこれらのメッセージから得られた知識を使用することができます。機密情報は、このトランスポート・マッピングを介して送信されないこと、またはそのような情報の送信が正しく固定ネットワークに制限されることが推奨されます。
Message forgery and observation can be combined into a replay attack. An attacker could record a set of messages that indicate normal activity of a machine. At a later time, an attacker could remove that machine from the network and replay the syslog messages with new time stamps. The administrators could find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine.
メッセージ偽造と観察がリプレイ攻撃にまとめることができます。攻撃者は、機械の通常の活動を示す一連のメッセージを録音できます。後の時点では、攻撃者がネットワークからそのマシンを削除し、新しいタイムスタンプを持つsyslogメッセージを再生することができます。管理者は、受信したメッセージで珍しい何も見つけることができなかった、と彼らの領収書は、誤って機械の正常な活動を示すことになります。
As was previously discussed in Section 4, Reliability Considerations, the UDP transport is not reliable, and packets containing syslog message datagrams can be lost in transit without any notice. There can be security consequences to the loss of one or more syslog messages. Administrators could be unaware of a developing and potentially serious problem. Messages could also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
先に第4、信頼性に関する考慮事項で説明したように、UDPトランスポートは信頼できない、およびsyslogメッセージデータグラムを含むパケットは、予告なしに輸送中に失われる可能性があります。一つ以上のSyslogメッセージの損失にセキュリティ上の影響が存在する場合があります。管理者は、現像し、潜在的に深刻な問題に気付かない可能性があります。メッセージはまた、傍受や不正な活動を隠蔽するための方法として、攻撃者によって破棄することができます。
This transport mapping does not mandate prioritization of syslog messages either on the wire or when processed on the receiving host based on their severity. Unless some prioritization is implemented by sender, receiver, and/or network, the security implication of such behavior is that the syslog receiver or network devices could get overwhelmed with low-severity messages and be forced to discard potentially high-severity messages.
このトランスポート・マッピングは、ワイヤ上のいずれかのsyslogメッセージの優先順位付けを強制しないか、その重要度に基づいて、受信側ホスト上で処理したとき。いくつかの優先順位付けは、送信者、受信者、および/またはネットワークによって実現されていない限り、そのような行動のセキュリティ含意はsyslogの受信機やネットワーク機器が低重要度のメッセージに圧倒得ることができ、潜在的に高い重要度のメッセージを破棄することを余儀なくされることです。
An attacker could overwhelm a receiver by sending more messages to it than could be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat, such as optionally restricting reception of messages to a set of known source IP addresses.
攻撃者は、インフラストラクチャまたは器具自体によって処理することができるよりも、それに多くのメッセージを送信することによって受信機を圧倒する可能性があります。実装者は、必要に応じて、既知の送信元IPアドレスのセットにメッセージの受信を制限するとして、この脅威を最小限に抑える機能を提供しようとすべきです。
This transport uses UDP port 514 for syslog, as recorded in the IANA port-numbers registry.
IANAポート番号のレジストリに記録されているように、この輸送は、syslogのためにUDPポート514を使用しています。
The author gratefully acknowledges the contributions of: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch, Richard Graveman, and all others who have commented on the various versions of this proposal.
クリスLonvick、レイナー・ガーハーズ、デヴィッド・ハリントン、アンドリュー・ロス、アルバートMietus、バーニーフォルツ、ミカエル・グラハム、グレッグ・モリス、アレクサンドラフェドロワ、デヴィンKowatch、リチャードGraveman、および様々な上コメントしている他のすべて：著者は感謝の貢献を認めてこの提案のバージョン。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[2] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[2] Gerhards氏、R.、 "Syslogのプロトコル"、RFC 5424、2009年3月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[6]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[7] Miao, F. and Y. Ma, "TLS Transport Mapping for Syslog", RFC 5425, March 2009.
[7]ミャオ族、F.およびY.馬、 "SyslogのためのTLSトランスポート・マッピング"、RFC 5425、2009年3月。
[8] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[8] Lonvick、C.、 "BSDシスログプロトコル"、RFC 3164、2001年8月。
[9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[9]モーグル、J.およびS.デアリング、 "経路MTUディスカバリ"、RFC 1191、1990年11月。
[10] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[10]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
Author's Address
著者のアドレス
Anton Okmianski Cisco Systems, Inc. 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada
アントンOkmianskiシスコシステムズ社595バラードセント、スイート2123年バンクーバー、BC V7X 1J1カナダ
Phone: +1-978-936-1612 EMail: aokmians@cisco.com
電話：+ 1-978-936-1612 Eメール：aokmians@cisco.com