[要約] RFC 3115は、モバイルIPベンダー/組織固有の拡張機能に関する規格であり、モバイルIPプロトコルの拡張を提供します。このRFCの目的は、モバイルIPの実装においてベンダー/組織固有の拡張をサポートするためのガイドラインを提供することです。
Network Working Group G. Dommety
Request for Comments: 3115 K. Leung
Obsoletes: 3025 cisco Systems
Category: Standards Track April 2001
Mobile IP Vendor/Organization-Specific Extensions
モバイルIPベンダー/組織固有の拡張機能
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) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
RFC Editor Note:
RFCエディター注：
This memo corrects discrepancies between the values assigned for CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER in RFC 3025 and in the Internet Assigned Numbers Authority's (IANA) repository. The difference in the assigned values are as follows:
このメモは、RFC 3025とインターネットに割り当てられた番号当局（IANA）リポジトリで、CVSEタイプ番号とNVSEタイプ番号に割り当てられた値の間の不一致を修正します。割り当てられた値の違いは次のとおりです。
CVSE-TYPE-NUMBER = 37 in RFC 3025 CVSE-TYPE-NUMBER = 38 in IANA (Under Mobile IP numbers)
cvse-type-number = 37 in rfc 3025 cvse-type-number = 38 iana（モバイルIP番号の下）
NVSE-TYPE-NUMBER = 133 in RFC 3025 NVSE-TYPE-NUMBER = 134 in IANA (Under Mobile IP numbers)
nvse-type-number = 133 in rfc 3025 nvse-type-number = 134 iana（モバイルIP番号の下）
This memo obsoletes RFC 3025, since the current implementations follow the IANA assignments.
このメモは、現在の実装がIANAの割り当てに続くため、RFC 3025を廃止します。
Abstract
概要
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.
このドキュメントでは、モバイルIPへの2つの新しい拡張機能を定義しています。これらの拡張機能は、機器ベンダーや組織が、研究や展開の目的に適していると考えているため、これらの拡張機能を特定の使用するように促進します。
Current specification of Mobile IP [1] does not allow for organizations and vendors to include organization/vendor-specific information in the Mobile IP messages. With the imminent wide scale deployment of Mobile IP it is useful to have vendor or organization-Specific Extensions to support this capability. This document defines two extensions that can be used for making organization specific extensions by vendors/organizations for their own specific purposes.
モバイルIP [1]の現在の仕様では、組織やベンダーがモバイルIPメッセージに組織/ベンダー固有の情報を含めることはできません。モバイルIPの差し迫った大規模な展開により、この機能をサポートするためにベンダーまたは組織固有の拡張機能を持つことが役立ちます。このドキュメントでは、ベンダー/組織が独自の目的で組織固有の拡張機能を作成するために使用できる2つの拡張機能を定義します。
The keywords "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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" optional "は、RFC 2119 [3]に記載されているように解釈されます。
In addition, the following words are used to signify the requirements of the specification.
さらに、次の単語を使用して、仕様の要件を意味します。
silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
実装は、さらに処理せずに、および送信者へのエラーを示さずにデータグラムを廃棄します。実装は、破棄されたデータグラムの内容を含むエラーを記録する機能を提供し、統計カウンターにイベントを記録する必要があります。
Two Vendor/Organization Specific Extensions are described, Critical (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions. The basic differences between the Critical and Normal Extensions are that when the Critical extension is encountered but not recognized, the message containing the extension MUST be silently discarded, whereas when a Normal Vendor/Organization Specific Extension is encountered but not recognized, the extension SHOULD be ignored, but the rest of the Extensions and message data MUST still be processed. Another difference between the two is that Critical Vendor/Organization Extension has a length field of two octets and the NVSE has a length field of only one octet.
2つのベンダー/組織固有の拡張機能、クリティカル（CVSE）および通常（NVSE）ベンダー/組織固有の拡張機能が記載されています。クリティカルエクステンションと通常の拡張機能の基本的な違いは、批判的な拡張が遭遇したが認識されていない場合、拡張機能を含むメッセージを静かに破棄する必要があるのに対し、通常のベンダー/組織固有の拡張機能が発生したが認識されない場合、拡張機能は無視されますが、残りの拡張データとメッセージデータは引き続き処理する必要があります。2つの間のもう1つの違いは、重要なベンダー/組織拡張機能の長さフィールドが2つのオクテットであり、NVSEの長さフィールドは1オクテットのみです。
The format of this extension is as shown below.
この拡張機能の形式は、以下に示すように。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-CVSE-Type | Vendor-CVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Critical Vendor/Organization Specific Extension
図1：重要なベンダー/組織固有の拡張機能
Type CVSE-TYPE-NUMBER 38
タイプCVSEタイプ番号38
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
将来の使用のために予約された予約。送信時に0に設定する必要があります。受信で無視する必要があります。
Length Length in bytes of this extension, not including the Type and Length bytes.
この拡張機能のバイトの長さの長さは、タイプと長さのバイトを含まない。
Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2].
ベンダー/org-id高次のオクテットは0であり、低次の3オクテットは、割り当てられた数字RFC [2]で定義されているように、ネットワークバイト順序でベンダーのSMIネットワーク管理プライベートエンタープライズコードです。
Vendor-CVSE-Type Indicates the particular type of Vendor-CVSE-Extension. The administration of the Vendor-CVSE-Types is done by the Vendor.
ベンダー-CVSEタイプは、特定のタイプのベンダー-CVSE-Extensionを示します。ベンダーCVSEタイプの管理は、ベンダーによって行われます。
Vendor-CVSE-Value Vendor/organization specific data of this Vendor-CVSE-Extension. These data fields may be published in future RFCs. The Vendor-CVSE-Value is zero or more octets. The length of this field can be computed from the Length Field Value.
ベンダー-CVSE値ベンダー/組織このベンダーCVSE-Extensionの特定のデータ。これらのデータフィールドは、将来のRFCで公開される場合があります。ベンダー-CVSE値はゼロ以上のオクテットです。このフィールドの長さは、長さフィールド値から計算できます。
If an implementation does not recognize the CVSE, according to RFC 2002 [1], the entire packet is to be silently dropped.
RFC 2002 [1]によると、実装がCVSEを認識しない場合、パケット全体を静かに削除することになります。
The format of this extension is as shown below.
この拡張機能の形式は、以下に示すように。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type | Vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Normal Vendor/Organization Specific Extension
図2：通常のベンダー/組織固有の拡張機能
Type NVSE-TYPE-NUMBER 134
NVSE-Type-Number 134を入力します
Length Length in bytes of this extension, not including the Type and Length bytes.
この拡張機能のバイトの長さの長さは、タイプと長さのバイトを含まない。
Reserved Reserved for future use. To be set to 0.
将来の使用のために予約された予約。0に設定されます。
Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2].
ベンダー/org-id高次のオクテットは0であり、低次の3オクテットは、割り当てられた数字RFC [2]で定義されているように、ネットワークバイト順序でベンダーのSMIネットワーク管理プライベートエンタープライズコードです。
Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE-Extension. The administration of the Vendor-NVSE-Types is done by the Vendor.
ベンダーNVSEタイプは、特定のタイプのベンダーnvse-extensionを示します。ベンダーNVSEタイプの管理は、ベンダーによって行われます。
Vendor-NVSE-Value Vendor/organization specific data of this Vendor-NVSE-Extension. These data fields may be published in future RFCs. The Vendor-NVSE-Value is zero or more octets. The length of this field can be computed from the Length Field Value.
ベンダー-NVSE値ベンダー/組織このベンダーNVSE-Extensionの特定のデータ。これらのデータフィールドは、将来のRFCで公開される場合があります。ベンダーNVSE値はゼロ以上のオクテットです。このフィールドの長さは、長さフィールド値から計算できます。
When a Mobile IP entity receives a registration request message (or any other request/update message) with an extension of type CVSE-TYPE-NUMBER and recognizes it, but the extension contains an unknown/unsupported vendor ID or Vendor-CVSE-Type, a registration reject (or the appropriate deny message) MUST be sent with the error code to indicate that the registration was rejected due to the presence of an unknown CVSE.
モバイルIPエンティティが登録リクエストメッセージ（またはその他のリクエスト/更新メッセージ）をタイプCVSEタイプ番号の拡張機能で受信して認識しますが、拡張機能には不明/サポートされていないベンダーIDまたはベンダー-CVSEタイプが含まれています。登録拒否（または適切な拒否メッセージ）は、未知のCVSEの存在により登録が拒否されたことを示すために、エラーコードとともに送信する必要があります。
When a Mobile IP entity receives a registration reply (or any other mobile IP reply/acknowledgement message) with an extension of type CVSE-TYPE-NUMBER and recognizes it, but the extensions contains an unknown/unsupported vendor ID or Vendor-CVSE-Type, the processing is performed as described below.
モバイルIPエンティティが登録返信（またはその他のモバイルIP返信メッセージ/確認メッセージ）をタイプCVSEタイプ番号の拡張機能で受信して認識しますが、拡張機能には不明/サポートされていないベンダーIDまたはベンダー-CVSEタイプが含まれています。、処理は以下に説明するように実行されます。
1. If the Mobile IP entity is a transit node for the reply (i.e., this entity processes and sends the registration reply to another entity) a registration reject (or the appropriate deny message) MUST be sent with the error code to indicate that the registration was rejected due to the presence of an unknown CVSE. For example, FA when it receives an unknown CVSE in a registration reply from the HA, should send a registration reject to the MN.
1. モバイルIPエンティティが返信用のトランジットノードである場合（つまり、このエンティティが別のエンティティに登録返信を処理および送信する場合）、登録拒否（または適切な拒否メッセージ）をエラーコードで送信する必要があります。未知のCVSEの存在により拒否されました。たとえば、FAがHAからの登録返信で不明なCVSEを受け取った場合、MNに登録拒否を送信する必要があります。
2. If the Mobile IP entity is not a transit node for the reply, the reply is treated as a reject (or the appropriate deny message) due to the presence of an unknown CVSE.
2. モバイルIPエンティティが返信用のトランジットノードでない場合、返信は未知のCVSEの存在により拒否（または適切な拒否メッセージ）として扱われます。
While designing enhancements wherein a CVSE is included in a reply message, it should noted that the reply message could be discarded by the mobile IP entity processing this message. Enhancements that include a CVSE should take this into consideration during design.
CVSEが返信メッセージに含まれる強化の設計中、このメッセージを処理するモバイルIPエンティティによって返信メッセージが破棄される可能性があることに注意する必要があります。CVSEを含む機能強化は、設計中にこれを考慮に入れる必要があります。
When a Mobile IP entity receives a mobile IP related message (registration request/reply, advertisement/solicitation, etc.) with an extension of type NVSE-TYPE-NUMBER and recognizes it, but the extension contains an unknown/unsupported vendor ID or Vendor-NVSE-Type, the entire extension is skipped.
モバイルIPエンティティがタイプNVSEタイプの番号の拡張機能を使用してモバイルIP関連のメッセージ（登録リクエスト/返信、広告/勧誘など）を受信して認識しますが、拡張機能には不明/サポートされていないベンダーIDまたはベンダーが含まれています-nvse-type、拡張機能全体がスキップされます。
NOTE that according to RFC 2002 [1], when an extension numbered within the range 0 through 127 is encountered in a registration message but not recognized, the message containing that extension MUST be silently discarded. This document is compliant with the above specification and specifies the action if the extension of type CVSE-TYPE-NUMBER is encountered and recognized, but does not support the vendor ID or the vendor type extension within.
RFC 2002 [1]によると、登録メッセージで範囲0〜127内で番号が付けられている拡張機能が遭遇したが、認識されていない場合、拡張機能を含むメッセージは静かに破棄する必要があることに注意してください。このドキュメントは上記の仕様に準拠しており、タイプのCVSEタイプ番号の拡張が遭遇および認識された場合にアクションを指定しますが、ベンダーIDまたはベンダータイプの拡張機能をサポートしていません。
The following error codes are defined.
次のエラーコードが定義されています。
Registration denied by the Foreign agent:
外国人エージェントによる登録：
ERROR-FA-1 100: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Mobile Node to the Foreign Agent.
エラーFA-1 100：サポートされていないベンダーIDまたはモバイルノードから送信されたCVSEでベンダーCVSEタイプを外国人エージェントに送信することができません。
ERROR-FA-2 101: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Home Agent to the Foreign Agent.
エラーFA-2 101：サポートされていないベンダーIDまたはホームエージェントから外国人エージェントに送信されたCVSEのベンダーCVSEタイプを解釈できません。
Registration denied by the Home agent:
ホームエージェントが拒否した登録：
ERROR-HA-1 140: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Mobile Node to the Home Agent.
ERROR-HA-1 140：サポートされていないベンダーIDまたはモバイルノードからホームエージェントに送信されたCVSEでベンダーCVSEタイプを解釈できません。
ERROR-HA-2 141: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Foreign Agent to the Home Agent.
Error-HA-2 141：サポートされていないベンダーIDまたは外国人がホームエージェントに送信したCVSEでベンダーCVSEタイプを解釈できません。
Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER can be included in a message. TLVs with types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER can be placed anywhere after the fixed portion of the Mobile IP message. These TLVs are expected to be protected by the corresponding authenticator as necessary. Ordering of these TLV's should not be modified by intermediate nodes.
タイプのCVSEタイプ番号とNVSEタイプ番号を使用した複数のTLVをメッセージに含めることができます。タイプのCVSEタイプ番号とNVSEタイプの番号を持つTLVは、モバイルIPメッセージの固定部分の後、どこにでも配置できます。これらのTLVは、必要に応じて対応する認証器によって保護されると予想されます。これらのTLVの順序付けは、中間ノードによって変更されるべきではありません。
The Critical Vendor/Organization Specific Extension (CVSE) as defined in Section 2.1 and Normal Vendor/Organization Specific Extension (NVSE) as defined in section 2.2 are proposed new extensions to the Mobile IP protocol, defined in RFC 2002 [1] and extended in RFC 2356 [5].
セクション2.1およびセクション2.2で定義されているセクション2.1および通常のベンダー/組織固有の拡張（NVSE）で定義されている重要なベンダー/組織固有の拡張（CVSE）は、RFC 2002 [1]で定義され、拡張されたモバイルIPプロトコルへの新しい拡張機能が提案されています。RFC 2356 [5]。
IANA has assigned a Type value of CVSE-TYPE-NUMBER for the Critical Vendor/Organization Specific Extension (CVSE), and a Type value of NVSE-TYPE-NUMBER for the Normal Vendor/Organization Specific Extension (NVSE). The numbers CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER for the CVSE and the NVSE are taken from the numbering space defined for Mobile IP registration extensions [1].
IANAは、クリティカルベンダー/組織固有の拡張機能（CVSE）にCVSEタイプ番号のタイプ値を割り当て、通常のベンダー/組織固有の拡張機能（NVSE）にNVSEタイプ番号のタイプ値を割り当てました。CVSEおよびNVSEのCVSEタイプ番号とNVSEタイプ番号は、モバイルIP登録拡張機能のために定義された番号付けスペースから取得されます[1]。
IANA has assigned new Foreign Agent Error Codes, ERROR-FA-1 and ERROR-FA-2 taken from the numbering space defined for Mobile IP Foreign Agent error codes [1]. IANA has also assigned new Home Agent Error Codes, ERROR-HA-1 and ERROR-HA-2 taken from the numbering space defined for Mobile IP Home Agent error codes [1].
IANAは、モバイルIP外部エージェントエラーコード[1]用に定義された番号付けスペースから取得した新しい外部エージェントエラーコード、エラーFA-1、およびエラーFA-2を割り当てました。IANAは、モバイルIPホームエージェントエラーコード[1]用に定義された番号付けスペースから取得した新しいホームエージェントエラーコード、エラーHA-1、およびエラーHA-2も割り当てました。
This document assumes that the Mobile IP messages are authenticated using a method defined by the Mobile IP protocol. This document does not impose any additional requirements on Mobile IP messages from a security point of view. So this is not expected to be a security issue.
このドキュメントは、モバイルIPプロトコルによって定義されたメソッドを使用してモバイルIPメッセージが認証されることを前提としています。このドキュメントでは、セキュリティの観点からモバイルIPメッセージに追加の要件を課しません。したがって、これはセキュリティの問題になるとは予想されていません。
The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for their useful discussions.
著者は、TR45.4 WG、TR45.6 WG、Basavaraj Patil、Phil Roberts、Jouni Malinen、Patrice Calhounの有用な議論に感謝します。
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[2] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[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] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[4] モンテネグロ、G。、「モバイルIPの逆トンネル」、RFC 2344、1998年5月。
[5] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[5] モンテネグロ、G。およびV.グプタ、「モバイルIPのSun's Skip Firewalversal」、RFC 2356、1998年6月。
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Gopal Dommety Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: gdommety@cisco.com
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Kent Leung Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: kleung@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。