Network Working Group P. Arberg
Request for Comments: 4638 D. Kourkouzelis
Category: Informational Redback Networks
M. Duckett
T. Anschutz
BellSouth
J. Moisand
Juniper Networks
September 2006
Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
最大トランジット単位/最大は、イーサネット上のポイントツーポイントプロトコル（PPPoEの）で1492より大きい単位（MTU / MRU）を受信収容
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 (2006).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
As of this writing, no current IEEE standard supports the use of "jumbo frames" (MTU greater than 1500). Although this document contains recommended mechanisms to detect problems in the path, interoperability and reliability of non-standard extensions cannot be assured. Both implementors and users of the protocol described here should exercise caution in its use.
この記事の執筆時点では、何の現在のIEEE規格では、「ジャンボフレーム」（1500より大きいMTU）の使用をサポートしていません。このドキュメントは、パス内の問題を検出するための推奨メカニズムが含まれていますが、非標準の拡張機能の相互運用性と信頼性を確保することができません。ここで説明されたプロトコルの両方実装し、ユーザーがその使用に注意を払う必要があります。
Abstract
抽象
The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks.
イーサネット上のポイントツーポイントプロトコル（PPPoEの）は、RFC 2516に記載されているように、最大ネゴシエート最大1492単位（MRU）を受信する義務この文書では、この制限を緩和し、1492よりMRUをネゴシエート最大値の方が大きい可能溶液を概説します次世代ブロードバンドネットワークでの断片化を最小限にします。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Proposed Solution ...............................................4
4. PPPoE Discovery Stage ...........................................5
5. LCP Considerations ..............................................5
5.1. MRU Negotiations ...........................................5
5.2. MRU Test and Troubleshooting ...............................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................7
8. Acknowledgements ................................................7
9. Normative References ............................................7
10. Informative References .........................................8
As broadband network designs are changing from PC-initiated PPPoE [1] sessions in a combined Ethernet/Asynchronous Transfer Mode (ATM) setup, as shown in Figure 1, to more intelligent PPPoE-capable Residential Gateway (RG) and Gigabit Ethernet/ATM broadband network designs, as shown in Figures 2 and 3, the need to increase the maximum transmit and receive unit in the PPPoE protocol is becoming more important in order to reduce fragmentation in the network.
ブロードバンドネットワークの設計は、PC-開始のPPPoEから変化している[1]複合イーサネット/非同期転送モード（ATM）の設定でセッションを、図1に示すように、よりインテリジェントにPPPoE対応レジデンシャルゲートウェイ（RG）及びギガビットイーサネット/ ATMに図2及び図3に示すように、ブロードバンドネットワークの設計は、最大送信を高め、PPPoEプロトコルの単位を受信する必要性は、ネットワーク内の断片化を低減するために、より重要になってきています。
<------------------ PPPoE session ------------------>
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------|CPE|-----------|DSLAM|-----------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <ATM> | |
+-----+ +-----+
Figure 1. Initial broadband network designs with PPPoE
図1.初期ブロードバンドネットワークは、PPPoEとデザイン
In the network design shown in Figure 1, fragmentation is typically not a problem, since the subscriber session is PPPoE end to end from the PC to the BRAS. Therefore, a PPP-negotiated MRU of 1492 octets is fully acceptable, as it makes the largest PPPoE frame adhere to the standard Ethernet MTU of 1500 octets.
加入者セッションがBRASにPCから最後までのPPPoE端であるので、図1に示すネットワーク設計では、断片化は、典型的には問題ではありません。それが最大PPPoEフレームが1500オクテットの標準イーサネットMTUに付着させるしたがって、1492オクテットのPPPネゴシエーションMRUは、完全に許容可能です。
<----- IPoE -----> <--------- PPPoE session --------->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|-----------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
Figure 2. Next-generation broadband network designs with PPPoE
図2次世代ブロードバンドネットワークは、PPPoEを用いて設計します
In the network design shown in Figure 2, fragmentation becomes a major problem, since the subscriber session is a combination of IPoE and PPPoE. The IPoE typically uses a Maximum Transit Unit (MTU) of 1500 octets. However, when the Residential Gateway and the Broadband Remote Access Server (BRAS) are the PPPoE session endpoints and therefore negotiate an MTU/MRU of 1492 octets, the result is a large number of fragmented packets in the network.
加入者セッションがIPoEでおよびPPPoEの組み合わせであるため、図2に示すネットワーク設計において、断片は、大きな問題となります。 IPoEでは一般的に1500オクテットの最大トランジット単位（MTU）を使用しています。しかし、レジデンシャルゲートウェイとブロードバンドリモートアクセスサーバ（BRAS）がPPPoEセッションのエンドポイントであるため、1492オクテットのMTU / MRUをネゴシエートするとき、結果は、ネットワーク内の断片化されたパケットの数が多いです。
<----- IPoE -----> <---- PPPoA ----> <- PPPoE session ->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|------------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
<-------------- PPPoA -------------> <- PPPoE session ->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------|CPE|------------|DSLAM|------------| BRAS|
+--+ <ATM> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
Figure 3. Broadband network designs with PPPoA-to-PPPoE conversion
PPPoAのツーのPPPoE変換図3.ブロードバンドネットワークの設計
In the network design shown in Figure 3, which is studied by the DSL-Forum in the context of the migration to Ethernet for broadband aggregation networks, fragmentation is not the only problem when MRU differences exist in Point-to-Point Protocol over AAL5 (PPPoA) and PPPoE sessions.
ブロードバンドアグリゲーションネットワークのイーサネットへの移行の文脈においてDSL-フォーラムによって研究され、図3に示すネットワーク設計において、断片は、MRU差がAAL5上のポイントツーポイントプロトコル（に存在する唯一の問題ではありませんPPPoAの）およびPPPoEセッション。
The subscriber session is a PPP session running over a combination of PPPoA and PPPoE. The PPP/PPPoA host typically negotiates a 1500- octet MRU. Widely deployed PPP/PPPoA hosts in Customer Premises Equipment (CPE) do not support a 1492-octet MRU, which creates an issue in turn for the BRAS (PPPoE server) if strict compliance to RFC
加入者セッションがPPPoAのおよびPPPoEの組み合わせを介して実行されているPPPセッションです。 PPP / PPPoAのホストは、通常、1500 - オクテットMRUを交渉します。顧客宅内機器で広く導入されているPPP / PPPoAのホスト（CPE）は、RFCに厳密に準拠場合BRAS（PPPoEサーバ）に対して順番に問題を作成し、1492オクテットMRUをサポートしていません。
2516 [1] is mandated. For PPP/PPPoA hosts capable of negotiating a 1492-octet MRU size, then we are back to a fragmentation issue.
[1] 2516が義務付けられています。 1492オクテットMRUサイズを交渉できるPPP / PPPoAのホストの場合、我々は戻って断片化の問題にしています。
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 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。
ATM - Asynchronous Transfer Mode PPP - Point-to-Point Protocol PPPoA - PPP over AAL5 PPPoE - PPP over Ethernet MTU - Maximum Transmit Unit MRU - Maximum Receive Unit PC - Personal Computer CPE - Customer Premises Equipment RG - Residential Gateway BRAS - Broadband Remote Access Server DSLAM - Digital Subscriber Line Access Multiplexer PPPoE - client PC, RG, or CPE that initiates a PPPoE session PPPoE - server BRAS terminating PPPoE sessions initiated by client PADI - PPPoE Active Discovery Initiation PADO - PPPoE Active Discovery Offer PADR - PPPoE Active Discovery Request PADS - PPPoE Active Discovery Session-confirmation
ATM - 非同期転送モードPPP - ポイントツーポイントプロトコルのPPPoA - AAL5のPPPoE上のPPP - イーサネットのMTUを超えるPPP - 最大送信ユニットMRU - 最大はユニットのPCを受け取る - パソコンのCPEを - 顧客宅内機器RG - レジデンシャルゲートウェイBRAS - ブロードバンドリモートアクセスサーバーのDSLAM - デジタル加入者線アクセスマルチプレクサのPPPoE - クライアントPC、RG、またはCPEのPPPoEセッションのPPPoEを開始 - PPPoEセッションを終了し、サーバーBRASは、クライアントPADIによって開始 - PPPoEのアクティブディスカバリーイニシエーションPADO - のPPPoEアクティブディスカバリーオファーPADR - PPPoEのアクティブディスカバリリクエストPADS - PPPoEのアクティブディスカバリセッションの確認
The procedure described in this document does not strictly conform to IEEE standards for Ethernet packet size but relies on a widely deployed behavior of supporting frames with Ethernet packet format, but exceeding the maximum packet lengths defined by [4].
この文書に記載された手順は、厳密には、イーサネット・パケット・サイズのためのIEEE規格に準拠するが、イーサネットパケット形式でフレームを支持するが、[4]で定義された最大パケット長を超える広く展開挙動に依存していません。
Since next-generation broadband networks are built around Ethernet systems supporting baby-giants and jumbo frames with payload sizes larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 octets in order to limit the amount of fragmented packets in networks similar to those described in Section 1.
次世代ブロードバンド・ネットワークは、1500オクテットの通常のイーサネットMTU、するために、1492オクテットより大きいのPPPoE MRU交渉をサポートしなければならないPPPoEサーバとしてBRASの演技よりも大きいサイズのペイロードで赤ちゃん-巨人とジャンボフレームをサポートしているイーサネットシステムを中心に構築されているので、第1節に記載のものと同様のネットワークにおける断片化されたパケットの量を制限します。
By default, the Maximum-Receive-Unit (MRU) option MUST follow the rules set forward in RFC 1661 [2] but MUST NOT be negotiated to a size larger than 1492 to guarantee compatibility with Ethernet network segments limited to 1500-octet frames. In such a case, as the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MRU MUST NOT be greater than 1492.
デフォルトでは、最大受信・ユニット（MRU）オプションは、RFC 1661に前方に設定されたルールに従わなければならない[2]が、1500オクテットのフレームに制限され、イーサネットネットワークセグメントとの互換性を保証するために、1492年よりも大きいサイズに交渉してはいけません。 PPPoEヘッダは6つのオクテットであり、PPPプロトコルIDは、2つのオクテットであるような場合には、PPP MRUは1492を超えてはなりません。
An optional PPPoE tag, "PPP-Max-Payload", allows a PPPoE client to override this default behavior by providing a maximum size for the PPP payload it can support in both the sending and receiving directions. When such a tag is received by the PPPoE server, the server MAY allow the negotiation of an MRU larger than 1492 and the use of an MTU larger than 1492, subject to limitations of its local configuration and according to the rules set forward in RFC 1661 [2], within the limits of the maximum payload size indicated by the PPPoE client.
オプションのPPPoEのタグ、「PPP-マックス・ペイロード」、PPPoEクライアントは、それが両方の送信側と受信側の方向にサポートできるPPPペイロードの最大サイズを提供することによって、このデフォルトの動作をオーバーライドすることができます。そのようなタグは、PPPoEサーバによって受信されると、サーバは、そのローカル構成の制限を受けるとRFC 1661年フォワード設定規則に従って、1492よりも大きいMRU 1492より大きいMTUの使用のネゴシエーションを可能にすることができます[2]、PPPoEクライアントで示される最大ペイロードサイズの限界内。
If a PPPoE client wants to use an MTU/MRU higher than 1492 octets, then it MUST include an optional PPP-Max-Payload Tag in the PADI and PADR packets. If the PPPoE server can support an MTU/MRU higher than 1492 octets, it MUST respond with an echo of the clients tag in the PADO and PADS packets when the PPP-Max-Payload tag is received from the client.
PPPoEクライアントは、MTU / MRUが高ければ高いほど、より1492個のオクテットを使用したい場合は、それはPADIとPADRパケット内の任意のPPP-マックス・ペイロードタグを含まなければなりません。 PPPoEサーバはMTU / MRUが高ければ高いほど、より1492個のオクテットをサポートすることができた場合はPPP-マックス・ペイロードタグは、クライアントから受信したとき、それはPADOとPADSパケット内のクライアントタグのエコーで応じなければなりません。
Tag-name: PPP-Max-Payload Tag-value: 0x0120 Tag-length: 2 octets Tag-value: binary encoded value (max PPP payload in octets)
タグ名：PPP-最大ペイロードタグ値：0x0120タグの長さ：2オクテットのタグ値：バイナリエンコードされた値（オクテットで最大PPPペイロード）
Tag-description: This TAG indicates that the client and server are capable of supporting a given maximum PPP payload greater than 1492 octets for both the sending and receiving directions. Note that this value represents the PPP payload; therefore it is directly comparable with the value used in the PPP MRU negotiation.
タグ説明：このタグは、クライアントとサーバの両方が送受信方向についてより大きい1492個のオクテットを所与の最大PPPペイロードを支持することが可能であることを示しています。この値はPPPペイロードを表すことに留意されたいです。そのためには、PPP MRUネゴシエーションに使用される値と直接比較です。
Since Ethernet (without jumbo frames) has a maximum payload size of 1500 octets, the PPPoE header is 6 octets, and the PPP Protocol ID is 2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a size larger than 1492, unless both the PPPoE client and server have indicated the ability to support a larger MRU in the PPPoE Discovery Stage.
（ジャンボフレームなし）イーサネットが1500オクテットの最大ペイロードサイズを有するので、PPPoEヘッダは、6つのオクテットであり、PPPプロトコルIDは2つのオクテットで、最大受信・ユニット（MRU）オプションは、より大きなサイズにネゴシエートしてはいけません1492年より、PPPoEクライアントとサーバーの両方がPPPoEディスカバリーステージで大きなMRUをサポートする能力を示していない限り。
The initial MRU negotiation for the PPP/PPPoE server MUST follow a flow as shown below:
以下に示すようにPPP / PPPoEサーバの初期MRUネゴシエーションが流れに従う必要があります。
If PPPoE { PPP_MRU_Max = 1492 If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492) Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) } "Normal" PPP_MRU_Negotiation (PPP_MRU_Max)
もしPPPoEの{PPP_MRU_Max = 1492の場合（PPP-最大ペイロードタグ）AND（PPP-最大ペイロードタグ> 1492）そしてPPP_MRU_Max =分（PPP-最大ペイロードタグ、インタフェースMTU-8）} "ノーマル" PPP_MRU_Negotiation（PPP_MRU_Max）
If the PPP-Max-Payload tag is present and greater than 1492, it MUST be considered along with the server's interface MTU settings when the maximum value is selected for the normal RFC 1661 [2] MRU negotiation which decides the actual MRU to use.
PPP-最大ペイロードタグが存在し、1492よりも大きい場合には最大値を使用する実際のMRUを決定通常RFC 1661 [2] MRUネゴシエーションのために選択された場合、それはサーバのインターフェイスMTUの設定と一緒に考慮されなければなりません。
If the PPP-Max-Payload tag isn't present or is present but below 1492, then the existing MRU constraint of 1492 octets MUST stay applicable, thus preserving backward compatibility.
PPP-マックス・ペイロードのタグが存在しないか、存在しているが、1492年を下回る場合には、1492オクテットの既存のMRU制約は、このように、下位互換性を維持し、適用滞在しなければなりません。
This, in summary, indicates the following behavior:
これは、要約すると、次の動作を示します。
a. the value in this tag will indicate the maximum MRU allowed to be accepted or suggested in an MRU negotiation; and
A。このタグの値は最大MRUがMRUネゴシエーションで受け入れ又は示唆する許可を示します。そして
b. if MRU is not negotiated, then RFC 1661 [2] will set the default MRU at 1500. This will say that the "PPP-Max-Payload" tag can have a value greater than 1500, but in this case RFC 1661 [2] sets the default MRU to 1500, and only if MRU is negotiated higher (up to maximum payload) will the "PPP-Max-Payload" tag value be used.
B。 MRUが交渉されていない場合は、RFC 1661 [2]これは、「PPP-マックス・ペイロード」のタグが1500より大きい値を持つことができると言うだろう1500でデフォルトのMRUを設定しますが、この場合のRFCで1661 [2] 1500にデフォルトMRUを設定し、MRUは（最大ペイロードまで）より高いネゴシエートされた場合にのみ、「PPP-最大ペイロード」タグの値が使用されます。
2. When a "PPP-Max-Payload" tag is not received by either end, then RFC 2516 [1] sets the rule.
「PPP-最大ペイロード」タグは、いずれかの端部により受信されない場合2.次にRFC 2516 [1]ルールを設定します。
If the MRU is negotiated to a value larger than 1492 octets, the sending side SHOULD have the option of sending one or more MRU-sized Echo-Request packets once the session is opened. This allows it to test that the receiving side and any intermediate Ethernet segments and equipment can handle such a packet size.
MRUが1492オクテットより大きな値に交渉された場合、送信側は、セッションが開かれた後、一つ以上のMRUサイズのエコー要求パケットを送信するオプションを持っているべきです。これは、受信側と任意の中間イーサネットセグメントおよび装置は、パケットサイズを扱うことができることをテストすることを可能にします。
If no Echo-Replies are received, the sending side MAY choose to repeat the test with 1492 octets Echo-Request packets. If these packets receive replies, the sending side MUST not send packets bigger than 1492 octets for this session.
何のエコー応答が受信されない場合、送信側は、1492オクテットエコー要求パケットでテストを繰り返すように選ぶかもしれません。これらのパケットは、応答を受信した場合、送信側は、このセッションのために1492オクテットより大きいパケットを送信してはなりません。
This capability SHOULD be enabled by default. It SHOULD be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary.
この機能はデフォルトで有効にする必要があります。これは設定されるべきであり、テストが必要ではないことを示すいくつかの予備知識があるネットワーク上で無効になることがあります。
This document does not introduce new security issues. The security considerations pertaining to the original PPPoE protocol [1] remain relevant.
この文書は、新しいセキュリティ問題を紹介しません。オリジナルのPPPoEプロトコルに関するセキュリティ上の考慮事項[1]関連したまま。
This document defines a new value in a space that currently has no IANA registry. There is work in progress to define a registry [5] and that document already contains the value assigned here. No IANA action is required for this document.
この文書では、現在、IANAレジストリを持っていないスペースに新しい値を定義します。そこレジストリを定義するために進行中の作業は、[5]であり、その文書がすでにここに割り当てられた値が含まれています。何IANAのアクションは、このドキュメントのために必要とされません。
The authors would like to thank Prakash Jayaraman, Amit Cohen, Jim Ellis, David Thorne, John Reid, Oliver Thorp, Wojciech Dec, Jim Wilks, Mark Townsley, Bart Salaets, Tom Mistretta, Paul Howard, Dave Bernard, and Darren Nobel for their contributions and comments to this document.
著者は彼らのためにプラカシュJayaraman、アミット・コーエン、ジム・エリス、デビッド・ソーン、ジョン・リード、オリバー・ソープ、ヴォイチェフ12月、ジム・ウィルクス、マークTownsley、バートSalaets、トムMistretta、ポール・ハワード、デイブ・バーナード、とダレン・ノーベルに感謝したいと思いますこのドキュメントへの貢献とコメント。
[1] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[1] Mamakos、L.、Lidlの、K.、Evarts、J.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2005, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters", December 2005.
[4]電気電子学会、IEEE規格802.3-2005の研究所、「IEEE衝突検出（CSMA / CD）アクセス方法および物理層仕様搬送波感知多重アクセスのための標準 - 情報技術 - - にドラフト改正電気通信と情報交換衝突検出（CSMA / CD）アクセス方式および物理層仕様とキャリア検知多重アクセス - メディアアクセス制御パラメータ、物理レイヤと管理パラメータ」、2005年12月：ローカルおよびメトロポリタンエリアネットワーク - - - 固有の要件パート3システム間で。
[5] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE), Work in Progress, June 2006.
[5]アーベルク、P.およびV. Mammoliti、「イーサネット上のPPPのためのIANAの考慮事項（PPPoEの）、進歩、2006年6月での作業。
Authors' Addresses
著者のアドレス
Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
ピーターアーベルクレッドバックネットワークス株式会社300ホルガー・ウェイサンノゼ、CA 95134
EMail: parberg@redback.com
メールアドレス：parberg@redback.com
Diamantis Kourkouzelis Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Diamantis Kourkouzelisレッドバックネットワークス株式会社300ホルガー・ウェイサンノゼ、CA 95134
EMail: diamondk@redback.com
メールアドレス：diamondk@redback.com
Mike Duckett BellSouth Telecommunications, Inc. 575 Morosgo Drive Atlanta, GA 30324
マイク・ダケットベルサウステレコミュニケーションズ株式会社575 Morosgoドライブアトランタ、GA 30324
EMail: mike.duckett@bellsouth.com
メールアドレス：mike.duckett@bellsouth.com
Tom Anschutz BellSouth Science and Technology 725 W. Peachtree St. Atlanta, GA 30308
トム・アンシュッツベルサウス科学技術725 W.ピーチセントアトランタ、GA 30308
EMail: tom.anschutz@bellsouth.com
メールアドレス：tom.anschutz@bellsouth.com
Jerome Moisand Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886
ジェロームMoisandジュニパーネットワークス、株式会社10・テクノロジー・パークドライブウェストフォード、MA 01886
EMail: jmoisand@juniper.net
メールアドレス：jmoisand@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。