Network Working Group G. Malkin
Request for Comments: 2701 Nortel Networks
Category: Informational September 1999
Nortel Networks
Multi-link Multi-node PPP Bundle Discovery Protocol
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified.
この文書では、マルチリンクPPPは、複数のノード間で動作するための標準的な方法を指定します。バンドルヘッドが発見されるメカニズムとPPP断片カプセル化の両方が指定されています。
Acknowledgements
謝辞
I would like to thank Joe Frazier for filling in some of the details and reviewing this document.
私は詳細の一部に充填し、この文書をレビューするジョー・フレイジャーに感謝したいと思います。
Multi-link PPP [MP] allows a dial-in user to open multiple PPP connections to a given host. In general, this is done on an on-demand basis. That is, a secondary link, or multiple secondary links, are established when the data load on the primary link, and any previously established secondary links, nears capacity. As the load decreases, the secondary link(s) may be disconnected.
マルチリンクPPP [MP]は、ダイヤルインユーザが所与のホストに複数のPPP接続を開くことができます。一般的に、これはオンデマンドベースで行われています。すなわち、プライマリリンク上のデータロード、および任意の以前に確立された二次リンクは、容量に近づくと二次リンク、または複数の二次リンクが確立されています。負荷が減少するにつれて、二次リンク（複数可）が切断されてもよいです。
Many dial-in hosts which support multi-link PPP dial the same phone number for all links. This implies that there exists a rotary at the Point Of Presence (POP) which routes incoming calls to a bank of modems. These may be physically independent modems connected to Remote Access Server (RAS) and a rotary of analog phone lines, or a RAS with internal modems connected to analog lines or a T1/E1 or T3/E3 channel. In any case, a given RAS can only handle just so many simultaneous connections. A typical POP may need to support hundreds of connections, but no RAS today can handle that many. This creates a problem when a user's primary PPP connection is established to one
マルチリンクPPPをサポートする多くのダイヤルインのホストは、すべてのリンクに同じ電話番号をダイヤルします。これは、ロータリー経路がモデムバンクへの電話を着信存在のポイント（POP）に存在することを意味します。これらはリモートアクセスサーバ（RAS）と、アナログ電話回線の回転、またはアナログ回線またはT1 / E1またはT3 / E3チャネルに接続された内部モデムでRASに接続された物理的に独立したモデムであってもよいです。いずれの場合も、与えられたRASはちょうどそう多くの同時接続を処理することができます。典型的なPOPは、接続の数百人をサポートする必要があるかもしれませんが、ないRAS今日はその多くを扱うことはできません。これは、ユーザーのプライマリPPP接続が一つに確立されている問題を作成し、
RAS in a POP and a secondary connection is established to another. This may occur because the first RAS has no available modems, or because incoming calls are assigned to ports in a round-robin fashion, for example, and the second call is simply assigned to another RAS.
POPと二次接続でのRASは別のものに確立されています。最初のRASが利用可能なモデムを有していないため、または着信コールは、例えば、ラウンドロビン方式でポートに割り当てられ、第2の呼を単に別のRASに割り当てられているので、これは起こり得ます。
The solution to this problem is to provide a mechanism by which a RAS can determine if a Multi-link PPP connection is a primary or secondary and, if a secondary, where the Bundle Head (the process within a RAS which reassembles the PPP fragments transmitted over the primary and secondary links) resides. If the Bundle Head resides on a different RAS, a protocol must be used to transfer the PPP fragments to the RAS containing the Bundle Head so that the PPP frame can be reassembled.
この問題を解決するには、RASがマルチリンクPPP接続は、第一級または第二級とあるかどうかを決定することができるメカニズムを提供することで、二次ならどこバンドルヘッド（送信PPPフラグメントを再構成RAS内のプロセスプライマリとセカンダリのリンク上）に存在します。バンドルヘッドが異なるRASに存在する場合、プロトコルは、PPPフレームを再組立することができるように、バンドルヘッドを含むRASにPPPフラグメントを転送するために使用されなければなりません。
Section 2 of this document specifies the Discovery Mechanism. Section 3 specifies the Transfer Protocol. Section 4 specifies the configuration parameters needed for the Discovery Protocol.
このドキュメントのセクション2は、ディスカバリーメカニズムを指定します。第3節では、転送プロトコルを指定します。第4節では、検出プロトコルのために必要な設定パラメータを指定します。
When a user dials into a RAS and negotiates Multi-link PPP (MP) during the Link Control Protocol (LCP) phase, the RAS must determine which one of the following three cases exists:
リンク制御プロトコル（LCP）フェーズ中にユーザRASにダイヤルとネゴシエートし、マルチリンクPPP（MP）は、RASは次の3つの場合のいずれかが存在するかを決定しなければならない場合。
1- This is the primary (first) link of the MP connection. In this case, the RAS should create the Bundle Head.
1-これは、MP接続のプライマリ（最初の）リンクです。この場合、RASは、バンドルヘッドを作成する必要があります。
2- This is a secondary link of the MP connection and the Bundle Head resides on this RAS. In this case, the RAS should add the link to the Bundle (standard MP).
2-これは、MP接続の二次リンクとバンドルヘッドは、このRASに存在します。この場合、RASは、バンドル（標準MP）へのリンクを追加する必要があります。
3- This is a secondary link of the MP connection and the Bundle Head resides on a different RAS. In this case, the RAS should establish a path (see section 3) to the RAS that has the Bundle Head, and use that path to transfer MP fragments.
3-これは、MP接続の二次リンクとバンドルヘッドは異なるRASに常駐。この場合、RASは、バンドルヘッドを有するRASに（セクション3参照）パスを確立し、MPフラグメントを転送するために、そのパスを使用する必要があります。
In operation, a RAS will make the determination for case 2 first (because it is the easiest and requires no communication with other RASes. If the Bundle Head is not local, the Discovery Protocol is used to determine where the Bundle Head is, if it exists at all.
それは最も簡単であり、他のRASesとの通信を必要としないため、操作において、RASは、（最初のケース2に対する決意を行います。バンドルヘッドがローカルでない場合は、ディスカバリープロトコルがそれ場合バンドルヘッドは、ある場所を決定するために使用されます全く存在します。
See "IANA Considerations" (section 6) for UDP port number assignment.
UDPポート番号の割り当てのための「IANAの考慮事項」（第6章）を参照してください。
A Discovery Message has the following format:
ディスカバリーメッセージの形式は次のとおりです。
+------+------+------------+------+----======----+
| type |length| random ID | hash | endpoint ID |
+------+------+------------+------+----======----+
where:
どこ：
type - 2 octets
タイプ - 2つのオクテット
Message type: 1-query, 2-response.
メッセージタイプ：1-クエリ、2-応答。
length - 2 octets
長さ - 2つのオクテット
The length (in octets) of the endpoint ID.
エンドポイントIDの長さ（オクテットで）。
Random ID - 4 octets
ランダムID - 4つのオクテット
A random identifier generated by the RAS used to resolve contention. See "Contention Handling" (section 2.4) for the use of this field.
RASによって生成されるランダムな識別子は、競合を解決するために使用しました。このフィールドを使用するために、「競合の取り扱い」（セクション2.4）を参照してください。
hash - 2 octets
ハッシュ - 2つのオクテット
The unsigned sum (modulo 2^16) of the unsigned octets of the Endpoint ID. A value of zero indicates that no hash has been generated. See "Endpoint Identifier Matching" (section 2.2) for the use of this field.
エンドポイントIDの符号なしオクテットの符号なし和（モジュロ2 ^ 16）。ゼロという値は、ハッシュが生成されていないことを示しています。このフィールドの使用は、「エンドポイント識別子マッチング」（セクション2.2）を参照してください。
endpoint ID - variable length
エンドポイントID - 可変長
The endpoint identifier of the connection. From the discovery protocol's point of view, this is an opaque value. However, to ensure multi-vendor interoperability, the format of this field must be defined. The descriptions of, and legal values for, the fields in the endpoint ID are defined in [MP].
接続のエンドポイント識別子。ビューの発見プロトコルの観点から、これは不透明な値です。しかし、マルチベンダーの相互運用性を確保するために、このフィールドのフォーマットを定義する必要があります。説明、および有効な値のためには、エンドポイントIDのフィールドは、[MP]で定義されています。
+------+------+--==--+------+------+--==--+------+--==--+
|remote|remote|remote|local |local |local |user | user |
|EPD |EPD |EPD |EPD |EPD |EPD |name | name |
|class |length|data |class |length|data |length| data |
+------+------+--==--+------+------+--==--+------+--==--+
Notes: EPD = EndPoint Descriminator. remote = dial-in host. local = RAS. class and length fields are 1-octet in length. data fields are of variable (including zero) length.
注：EPD =エンドポイントDescriminator。リモート=ダイヤルインのホスト。 =ローカルRAS。クラスと長さフィールドの長さは1オクテットです。データフィールドの長さ（ゼロを含む）変数です。
The MP protocol requires that the RASes all have the same Local EPD. For MMP, this implies that a RAS may not use its IP or Ethernet address as an EPD. This also implies that all RASes on a rotary must have the same EPD. RASes on different rotaries may share different EPDs. The Local EPD is included in the endpoint identifier to ensure that RASes on different rotaries, but sharing a common Ethernet, will not join a particular discovery if the Remote EPDs just happen to be the same.
MPプロトコルはRASesすべてが同じローカルEPDを持っていることが必要です。 MMPの場合、これはRASがEPDとして、そのIPまたはEthernetアドレスを使用することはできませんことを意味します。また、これは、ロータリーのすべてのRASesが同じEPDを持たなければならないことを意味します。別のロータリ上RASesは異なるたEPDを共有することがあります。ローカルEPDは、リモートのEPDがちょうど同じことが起こる場合は、別のロータリ上RASesが、一般的なイーサネットを共有するには、特定の発見に参加しないことを保証するために、エンドポイント識別子に含まれています。
Except for unicast Response Messages, all messages are sent to the multicast address specified in "IANA Considerations". If a system cannot send multicast messages, the limited broadcast address (255.255.255.255) should be used.
ユニキャスト応答メッセージを除き、すべてのメッセージは、「IANAの考慮事項」で指定されたマルチキャストアドレスに送信されます。システムは、マルチキャストメッセージを送信できない場合は、制限されたブロードキャストアドレス（255.255.255.255）を使用する必要があります。
Comparing Endpoint IDs can be time consuming. First, the classes of the EPDs must be determined, then the values compared. These comparisons might be fast arithmetic compares or slow octet-wise compares of 20-octet long values. To improve performance, because the protocol is time-driven, the hash field may be used for a fast comparison.
エンドポイントIDを比較すると、時間がかかることがあります。まず、のEPDのクラスは、その後、決定されなければならない値を比較します。これらの比較は、高速算術比較やスローオクテット単位の20オクテット長い値の比較であるかもしれません。プロトコルは、時間駆動されるので、パフォーマンスを向上させるために、ハッシュ・フィールドは、高速比較のために使用されてもよいです。
When a Bundle Head is created, the hash is created and stored along with the Endpoint ID. When a Query or Response Message is generated, the hash is created and stored in the message. When a RAS receives a message, it can do a quick comparison of the hash in the message to the hashes in its tables. If a hash does not match, the Endpoint ID cannot match. However, if a hash does match, the Endpoint IDs must be properly compared to verify the match.
バンドルヘッドが作成されると、ハッシュが作成され、エンドポイントIDとともに記憶されます。クエリまたは応答メッセージが生成されると、ハッシュが作成され、メッセージに格納されています。 RASがメッセージを受信すると、そのテーブルのハッシュへのメッセージで、ハッシュの簡単な比較を行うことができます。ハッシュが一致しない場合、エンドポイントIDが一致することはできません。ハッシュが一致しない場合は、エンドポイントIDが正しく一致を確認するために比較されなければなりません。
Obviously, there is a cost associated with creating the hashes, but they are created only once per message and once for each Bundle Head creation. However, the comparisons occur multiple times in multiple RASes for each new secondary connection. Therefore, there is a net savings in processing.
明らかに、ハッシュの作成に関連するコストがありますが、それらは、各バンドルヘッド作成のために一度だけメッセージごとに、一度作成されます。しかし、比較はそれぞれの新しいセカンダリ接続するための複数のRASesに複数回発生します。そのため、処理の純貯蓄があります。
Throughout this section, configurable variables are specified by their names (e.g., ROBUSTNESS refers to the number of transmits).
このセクション全体を通して、構成変数は、その名前によって指定されている（例えば、ロバスト性は送信の数を意味します）。
The Discovery Protocol begins by multicasting ROBUSTNESS Query Messages at QUERY_INTERVAL intervals. If no Response Message for that Request is received within QUERY_INTERVAL of the last broadcast (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS assumes that this is the primary link and begins to build the Bundle Head. It then sends a multicast Response Message (in case another link comes up after the time-out but before the Bundle Head is built). If a Response Message is received (i.e., a Bundle Head exists on another RAS), no additional Query Messages are sent and the RAS establishes a path to the RAS containing the Bundle Head.
ディスカバリプロトコルはQUERY_INTERVAL間隔で堅牢クエリーメッセージをマルチキャストすることから始まります。その要求には応答メッセージが最後の放送（ロバストネス* QUERY_INTERVALの合計時間）のQUERY_INTERVAL内に受信されない場合、RASは、これはプライマリリンクであることを前提とバンドル頭を構築するために開始します。それから、（別のリンクはタイムアウト後にアップしますが、バンドル頭の前に構築されている場合）、マルチキャスト応答メッセージを送信します。応答メッセージが（すなわち、バンドルヘッドが別のRASに存在する）を受信した場合、追加のクエリメッセージが送信されず、RASはバンドルヘッドを含むRASへの経路を確立しています。
If a RAS receives a Query Message for an MP connection for which it has the Bundle Head, it sends a unicast Response Message to the querier. Note that no repetition of the Response Message is necessary because, if it is lost, the querier's next query message will trigger a new Response Message.
RASは、それがバンドル頭を持っているMP接続のためのクエリメッセージを受信した場合、それがクエリアにユニキャスト応答メッセージを送信します。それが失われた場合、クエリアの次のクエリメッセージは、新しい応答メッセージをトリガーする、ため、応答メッセージのない繰り返しを必要としないことに注意してください。
If, while sending Query Messages, a Query Message for the same MP connection is received, it indicates that the Dial-in Node has brought up multiple links simultaneously. The resolution to this contention is to elect the bundle head. To do this, each RAS waits until all Query Messages are sent (ROBUSTNESS * QUERY_INTERVAL). At that time, the RAS with the lowest Random ID becomes the Bundle Head. If two or more RASes have the same Random ID, the RAS with the lowest IP address becomes the Bundle Head. That RAS then sends TWO Response Messages, with a QUERY_INTERVAL interval, and indicates to the MP process that a Bundle Head should be formed. When the other RAS(es) receive the Response Message, they cease broadcasting (if they haven't already sent ROBUSTNESS Query Messages), stop listening for additional Response Messages, and indicate to their respective MP processes where the Bundle Head resides.
クエリーメッセージを送信しているときに、同じMP接続のためのクエリメッセージを受信した場合、それはダイヤルインのノードが同時に複数のリンクを育てたことを示します。この競合の解決は、バンドルの頭を選出することです。これを行うには、各RASは、すべてのクエリメッセージを待つ（ロバストネス* QUERY_INTERVAL）送信されます。当時、最低のランダムIDを持つRASがバンドル頭になります。二つ以上のRASesが同じランダムIDをお持ちの場合は、最小のIPアドレスを持つRASがバンドル頭になります。すなわちRASは次にQUERY_INTERVAL間隔で、2つの応答メッセージを送信し、そしてバンドルヘッドが形成されるべきであるMP処理を示します。他のRAS（ES）は、応答メッセージを受信すると、彼らは（彼らはすでに堅牢クエリーメッセージを送信していない場合）放送中止、追加の応答メッセージのリスニングを停止、およびバンドル頭が常駐するそれぞれのMPプロセスに示しています。
Note that a RAS generates a Random ID for each connection and uses that value for all Query and Response messages associated with that connection. The same Random ID must not be reused until it can be guaranteed that another RAS will not mistake the message for an old message from a previous connection. For this reason, it is recommended that the Random ID be either monotonically increasing or a clock value (either time since boot or time of day).
RASは、接続ごとにランダムIDを生成し、その接続に関連するすべてのクエリと応答メッセージのためにその値を使用することに注意してください。別のRASは、以前の接続からの古いメッセージのメッセージを間違えないであろうことを保証できるまで、同じランダムIDは再利用してはいけません。このため、ランダムIDが単調に増加またはクロック値（当日のブートまたは時間以降のいずれかの時間）のいずれかにすることをお勧めします。
MP must use the following algorithm to ensure that there are no windows of vulnerability during which multiple Bundle Heads might be created for the same MP connection.
MPは、複数のバンドルヘッドは同じMP接続のために作成されるかもしれない間、脆弱性のない窓がないことを確認するために、次のアルゴリズムを使用する必要があります。
When an MP link is negotiated, MP first checks to see if it already has the Bundle Head for this connection (i.e., is this a secondary link). If it does, it should attach to it and not initiate a discovery. As an optimization, if MP does not have a Bundle Head for this connection, but does have a existing secondary link for it, MP should attach to the known Bundle Head without initiating discovery.
MPリンクがネゴシエートされる場合、MPは、まず、それは既に、この接続用のバンドルヘッドを有しているかどうかをチェックする（すなわち、これは、二次リンクです）。それがない場合は、それに接続し、検出を開始してはなりません。 MPは、この接続のバンドル頭を持っていないが、それのために、既存の二次のリンクを持っていない場合は最適化として、MPは発見を開始せずに知られているバンドルの頭に添付してください。
If MP knows of no Bundle Head for this connection, it should initiate a discovery. If the discovery should locate a Bundle Head, it should attach to the indicated bundle head. If no Bundle Head is found, MP should create a Bundle Head.
MPは、この接続のためノーバンドルヘッドの知っているなら、それは検出を開始すべきです。発見がバンドル頭を見つけなければならない場合は、指示されたバンドルヘッドに添付してください。何のバンドルヘッドが見つからない場合は、MPがバンドルヘッドを作成する必要があります。
When a RAS determines that it is to become the Bundle Head for a connection, it should establish the Bundle Head as quickly as possible so Query Messages for that connection from other RASes will be recognized. If a RAS indicates that it will become the Bundle Head, but delays establishment of it, other RASes may time out on their discovery and begin to establish additional Bundle Heads of their own.
RASは、それが接続のためにバンドル頭になることであると判断した場合、それはとても他のRASesからその接続のためのクエリーメッセージが認識され、可能な限り迅速にバンドル頭を確立すべきです。 RASはそれがバンドル頭になるだろうことを示しているが、それの遅延の確立した場合、他のRASesは自分の発見にタイムアウトして、独自の追加バンドルヘッドを確立し始める可能性があります。
The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer PPP fragments from a RAS containing a secondary link to the RAS containing the Bundle Head. By specifying the use of an existing protocol, it is neither necessary to create nor implement a new protocol.
レイヤ2トンネリングプロトコル（L2TP）は、[L2TP]バンドルヘッドを含むRASに補助リンクを含むRASからPPPフラグメントを転送するために使用されるであろう。既存のプロトコルの使用を指定することで、それが作成したり、新しいプロトコルを実装するのでもない必要があります。
There are two required configuration switches and one conditional configuration switch. None of the switches are optional.
2つの必要な構成スイッチと1つの条件設定スイッチがあります。スイッチのいずれもオプションではありません。
This switch sets the number of transmits (repetitions) for Query Messages. It may be set between 1 and 15. The default is 3. Be aware that lower settings may create windows of vulnerability. Higher settings may cause MP timeouts, but may be needed on very lossy or congested networks.
このスイッチは、クエリメッセージの送信（繰り返し）の数を設定します。デフォルトは3.下の設定は、脆弱性のウィンドウを作成することがあるので注意してくださいで1と15の間に設定することができます。高い設定は、MPのタイムアウトが発生することがありますが、非常に非可逆や混雑したネットワークを上必要な場合があります。
This switch sets the interval between Query Messages and the interval between multicast Response Messages. It should be calibrated in deciseconds (1/10 second) and may be set between 1 and 15. The default is 1. Be aware that higher settings may cause MP timeouts, but may be needed on very slow systems/networks.
このスイッチは、クエリメッセージとマルチキャスト応答メッセージ間の間隔の間の間隔を設定します。それは（1/10秒）1/10秒単位で校正されなければならないと、デフォルトは1ですが、より高い設定はMPのタイムアウトが発生することがありますが、非常に遅いシステム/ネットワーク上で必要になることがあるので注意してくださいで1と15の間に設定することができます。
This switch sets the IP Time-To-Live (TTL) of all Discovery packets. For systems which are using the limited broadcast address, this switch should not be implemented and the TTL should be set to 1. The default value should be 1.
このスイッチは、すべてのディスカバリーパケットのIP生存時間（TTL）を設定します。制限されたブロードキャストアドレスを使用しているシステムの場合、このスイッチが実装されるべきではないとTTLは、デフォルト値は1であるべきである1に設定されるべきです。
No security is designed into the Discovery Mechanism. When not forwarding multicast packets (or when using the limited broadcast address), the discovery packets are restricted to a single LAN. If the LAN is physically secure, there is no need for software security. If the multicast packets are forwarded, but the range is limited to a small, physically secure network (e.g., a POP), there is still no need for software security. If the discovery packets are allowed to cross an internet (and this is NOT recommended for timing reasons), authentication of RASes may be done with IPSEC. For increased security on a LAN, or in a POP, IPSEC may still be used.
いいえセキュリティはディスカバリーメカニズムの中に設計されていません。マルチキャストパケットを転送しない場合（または制限されたブロードキャストアドレスを使用している場合）、ディスカバリパケットは、単一のLANに制限されています。 LANは物理的に安全である場合は、ソフトウェアのセキュリティは必要ありません。マルチキャストパケットが転送されるが、範囲が小さい、物理的にセキュアなネットワーク（例えば、POP）に制限されている場合は、ソフトウェアセキュリティの必要性が依然として存在しません。ディスカバリパケットがインターネットを横断するために許可されている（これは、タイミングの理由から推奨されていない）場合は、RASesの認証がIPSECで行うことができます。 LAN上のセキュリティを強化するため、またはPOPに、IPSECはまだ使用することができます。
L2TP security is discussed in [L2TP].
L2TPセキュリティは、[L2TP]で議論されています。
UDP port number: 581 Multicast address: 224.0.1.69
UDPポート番号：581マルチキャストアドレス：224.0.1.69
[MP] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[MP] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル（MP）"、RFC 1990、1996年8月。
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TP] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
Author's Address
著者のアドレス
Gary Scott Malkin Nortel Networks 11 Elizabeth Drive Chelmsford, MA 01824-4111
ゲーリースコットマルキンNortel Networksの11エリザベスドライブチェルムズフォード、マサチューセッツ州01824から4111
Phone: +1 (978) 250-3635 Email: gmalkin@nortelnetworks.com
電話：+1（978）250-3635 Eメール：gmalkin@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。