[要約] 要約： RFC 4638は、イーサネット上のポイントツーポイントプロトコル（PPPoE）で1492より大きな最大転送ユニット（MTU）/最大受信ユニット（MRU）をサポートするためのガイドラインです。目的： このRFCの目的は、PPPoEを使用してイーサネット上で大容量のデータ転送を可能にするために、MTU/MRUを1492より大きく設定する方法を提供することです。
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).
Copyright（c）The Internet Society（2006）。
IESG Note
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.
RFC 2516で説明されているように、イーサネット上のポイントツーポイントプロトコル（PPPOE）は、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.
ブロードバンドネットワークの設計は、図1に示すように、イーサネット/非同期移転モード（ATM）のセットアップを組み合わせたPCで開始したPPPOE [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.
図1に示すネットワーク設計では、サブスクライバーセッションがPPPOEの終わりからBRAまでの端から端までの断片化は問題ではありません。したがって、最大の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.
図2に示すネットワーク設計では、サブスクライバーセッションはIPOEとPPPOEの組み合わせであるため、断片化が大きな問題になります。IPOEは通常、1500オクテットの最大輸送ユニット（MTU）を使用します。ただし、住宅用ゲートウェイとブロードバンドリモートアクセスサーバー（BRA）が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
図3. PPPOAからPPPOEへの変換を備えたブロードバンドネットワーク設計
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.
図3に示されているネットワーク設計では、ブロードバンド集約ネットワークのイーサネットへの移行のコンテキストでDSL-Forumによって研究されているため、AAL5のポイントツーポイントプロトコルにMRUの違いが存在する場合、フラグメンテーションは唯一の問題ではありません（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 2516 [1] is mandated. For PPP/PPPoA hosts capable of negotiating a 1492-octet MRU size, then we are back to a fragmentation issue.
サブスクライバーセッションは、PPPOAとPPPOEの組み合わせで実行されるPPPセッションです。PPP/PPPOAホストは通常、1500-オクテットのmRUを交渉します。顧客施設機器（CPE）に広く展開されているPPP/PPPOAホストは、1492-OCTET MRUをサポートしていません。これは、RFC 2516 [1]への厳格な準拠が義務付けられている場合、BRA（PPPOEサーバー）の問題を作成します。1492-OCTET 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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 -PPP Over AAL5 PPPOE -PPP Over Ethernet MTU -Maximum Transmit Unit MRU-最大受信ユニットPC -Personal Computer CPE -Customer PremsemequipアクセスサーバーDSLAM-デジタルサブスクライバーラインアクセスマルチプレクサPPPOE-クライアントPC、RG、またはCPE PPPOE SESSION PPPOE PPPOE -BRAS ENTERING PPPOE SESSIONSはクライアントPADIによって開始されました - PPPOEアクティブ発見開始パド - PPPOEアクティブ発見が提供されるPADR -PPPOEアクティブ発見リクエストパッド-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よりも大きいペイロードサイズのベビーガントとジャンボフレームをサポートするイーサネットシステムを中心に構築されているため、PPPOEサーバーとして機能するブラジャーは、1492オクテットよりも大きいPPPOE MRU交渉をサポートする必要があります。セクション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.
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.
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クライアントが1492オクテットを超えるMTU/MRUを使用したい場合は、PADIおよびPADRパケットにオプションのPPP-Max-Payloadタグを含める必要があります。PPPOEサーバーが1492オクテットを超えるMTU/MRUをサポートできる場合、PPP-Max-Payloadタグがクライアントから受信されたときに、PADOおよびPADSパケットのクライアントタグのエコーで応答する必要があります。
Tag-name: PPP-Max-Payload Tag-value: 0x0120 Tag-length: 2 octets Tag-value: binary encoded value (max PPP payload in octets)
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オクテットです。PPPOEクライアントとサーバーの両方が、PPPOEディスカバリー段階でより大きなMRUをサポートする能力を示していない場合を除き、1492年より。
The initial MRU negotiation for the PPP/PPPoE server MUST follow a
flow as shown below:
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)
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-Max-Payloadタグが存在し、1492を超える場合は、通常のRFC 1661 [2] MRU交渉で最大値が選択されている場合に、使用する実際のMRUを決定する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-Max-Payloadタグが存在しないか、1492未満である場合、1492オクテットの既存のMRU制約が適用されたままである必要があるため、後方互換性を維持する必要があります。
This, in summary, indicates the following behavior:
これは、要約すると、次の動作を示しています。
1. When a "PPP-Max-Payload" tag is received,
1. 「PPP-Max-Payload」タグが受信されたら、
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]はデフォルトのMRUを1500に設定します。これは、「PPP-Max-Payload」タグは1500を超える値を持つことができると言うでしょうが、この場合はRFC 1661 [2]デフォルトのMRUを1500に設定し、MRUがより高い交渉（最大ペイロードまで）の場合にのみ、「PPP-Max-Payload」タグ値が使用されます。
2. When a "PPP-Max-Payload" tag is not received by either end, then RFC 2516 [1] sets the rule.
2. 「PPP-Max-Payload」タグがどちらの端でも受信されない場合、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のオクテットを超える値と交渉された場合、セッションが開かれたら、送信側には1つ以上の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.
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.
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.
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.
著者は、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、Darren Nobelに感謝します。この文書への貢献とコメント。
[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.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPを超えるPPP（PPPOE）を送信する方法」、RFC 2516、1999年2月。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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]
[5] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE), Work in Progress, June 2006.
[5]
Authors' Addresses
著者のアドレス
Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Peter Arberg Redback Networks、Inc。300 Holger Way San Jose、CA 95134
EMail: parberg@redback.com
Diamantis Kourkouzelis Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
EMail: diamondk@redback.com
Mike Duckett BellSouth Telecommunications, Inc. 575 Morosgo Drive Atlanta, GA 30324
Mike Duckett Bellsouth Telecommunications、Inc。575 Morosgo Drive Atlanta、GA 30324
EMail: mike.duckett@bellsouth.com
Tom Anschutz BellSouth Science and Technology 725 W. Peachtree St. Atlanta, GA 30308
トム・アンシュッツ・ベルサウス科学技術725 W.ピーチツリー・セント・アトランタ、ジョージア州30308
EMail: tom.anschutz@bellsouth.com
Jerome Moisand Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886
Jerome Moisand Juniper Networks、Inc。10テクノロジーパークドライブウェストフォード、マサチューセッツ州01886
EMail: jmoisand@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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).