[要約] RFC 2701は、Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol（MLNBDP）に関する規格です。このプロトコルの目的は、複数のPPPバンドルを持つネットワークでのバンドルの発見と管理を効率化することです。
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
Nortel NetworksマルチリンクマルチノードPPPバンドルディスカバリープロトコル
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.
Copyright（c）The Internet Society（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.
いくつかの詳細を記入してこのドキュメントをレビューしてくれたJoe Frazierに感謝します。
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.
Multi-Link 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 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.
マルチリンクPPPをサポートする多くのダイヤルインホストは、すべてのリンクに対して同じ電話番号をダイヤルします。これは、モデムの銀行に着信コールをルーティングする存在時点（POP）にロータリーが存在することを意味します。これらは、リモートアクセスサーバー（RAS）に接続された物理的に独立したモデムと、アナログ電話ラインのロータリー、またはアナログラインまたはT1/E1またはT3/E3チャネルに接続された内部モデムを備えたRASである場合があります。いずれにせよ、特定のRAは、非常に多くの同時接続のみを処理できます。典型的なポップは何百もの接続をサポートする必要があるかもしれませんが、今日のRASはそれほど多くを処理できません。これにより、ユーザーのプライマリPPP接続がPOPで1つのRAに確立され、二次接続が別のRAに確立された場合に問題が生じます。これは、最初のRAに使用可能なモデムがない、または着信コールがラウンドロビンの方法でポートに割り当てられ、2回目の呼び出しが単純に別のRAに割り当てられるために発生する可能性があります。
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接続が一次またはセカンダリであるかどうかを判断できるメカニズムを提供することです。プライマリおよびセカンダリリンク上）存在します。バンドルヘッドが別の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:
ユーザーがRASにダイヤルし、リンク制御プロトコル（LCP）フェーズでマルチリンク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接続の二次リンクであり、バンドルヘッドは別のRAに存在します。この場合、RAはバンドルヘッドを持つ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.
操作中、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の符号なしオクテットの符号なしの合計（Modulo 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 =エンドポイント説明。remote =ダイヤルインホスト。local = ras。クラスと長さのフィールドの長さは1-OCTETです。データフィールドの長さは可変（ゼロを含む）です。
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プロトコルでは、Raseがすべて同じローカルEPDを持つことが必要です。MMPの場合、これは、RAがIPまたはイーサネットアドレスをEPDとして使用できないことを意味します。これはまた、ロータリーのすべてのレースが同じEPDを持っている必要があることを意味します。異なるローターのレースは、異なるEPDを共有する場合があります。ローカルEPDはエンドポイント識別子に含まれており、異なるローターでのレースを確保するが、共通のイーサネットを共有することは、リモートEPDがたまたま同じである場合、特定の発見に参加しません。
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.
明らかに、ハッシュの作成に関連するコストがありますが、それらはメッセージごとに1回だけ、バンドルヘッドの作成ごとに1回しか作成されません。ただし、比較は、新しいセカンダリ接続ごとに複数のレースで複数回発生します。したがって、処理には純節約があります。
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内で受信されていない場合（robust性の合計時間 * query_interval）、Rasはこれが主要なリンクであると想定し、バンドルヘッドの構築を開始します。次に、マルチキャスト応答メッセージを送信します（タイムアウト後に別のリンクが表示され、バンドルヘッドが構築される前に）。応答メッセージが受信された場合（つまり、別のRASにバンドルヘッドが存在する）、追加のクエリメッセージは送信されず、RAはバンドルヘッドを含む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接続のクエリメッセージを受信した場合、クエリエにユニキャスト応答メッセージを送信します。Querierの次のクエリメッセージが新しい応答メッセージをトリガーするため、応答メッセージの繰り返しは不要であることに注意してください。
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はすべてのクエリメッセージが送信されるまで待機します（robustness * query_interval）。当時、ランダムIDが最も低いRASがバンドルヘッドになります。2つ以上のレイズが同じランダムIDを持っている場合、最も低いIPアドレスを持つRASがバンドルヘッドになります。その後、RASはquery_interval間隔で2つの応答メッセージを送信し、バンドルヘッドを形成する必要があることをMPプロセスに示します。他のRasが応答メッセージを受信すると、ブロードキャストを停止し（Robustnessクエリメッセージをまだ送信していない場合）、追加の応答メッセージのリスニングを停止し、バンドルヘッドが存在するそれぞれの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を生成し、その接続に関連付けられたすべてのクエリおよび応答メッセージに対してその値を使用することに注意してください。同じランダムIDを、別のRAが以前の接続からの古いメッセージとメッセージを間違えないことを保証できるようになるまで再利用してはなりません。このため、ランダム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が接続のバンドルヘッドになることを決定すると、バンドルヘッドをできるだけ早く確立する必要があるため、他のレイズからの接続のメッセージが認識されます。RASがバンドルヘッドになることを示しているが、それの確立を遅らせると、他のレイズが発見にタイムアウトし、独自の追加のバンドルヘッドを確立し始める可能性があります。
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.
必要な構成スイッチと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.
このスイッチは、クエリメッセージの送信数（繰り返し）を設定します。1〜15の間に設定される場合があります。デフォルトは3です。設定が低いと脆弱性のウィンドウが作成される可能性があることに注意してください。より高い設定は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月（1/10秒）で調整し、1〜15の間に設定することができます。デフォルトは1です。より高い設定がMPのタイムアウトを引き起こす可能性があることに注意してください。
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が物理的に安全な場合、ソフトウェアセキュリティは必要ありません。マルチキャストパケットが転送されているが、範囲が小さくて物理的に安全なネットワーク（ポップなど）に限定されている場合、ソフトウェアセキュリティはまだ必要ありません。ディスカバリーパケットがインターネットを横断することを許可されている場合（そして、これはタイミング上の理由で推奨されません）、Raseの認証はIPSECで行われる場合があります。LANのセキュリティの向上、またはポップでは、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.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Palter、「Layer Two Tunneling Protocol "L2TP" "、RFC 2661、1999年8月。
Author's Address
著者の連絡先
Gary Scott Malkin Nortel Networks 11 Elizabeth Drive Chelmsford, MA 01824-4111
ゲイリー・スコット・マルキン・ノーテル・ネットワーク11エリザベス・ドライブ・チェルムスフォード、マサチューセッツ州01824-4111
Phone: +1 (978) 250-3635
Email: gmalkin@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。