[要約] RFC 2794は、IPv4のためのMobile IP Network Access Identifier拡張に関するものであり、モバイルネットワークへのアクセス識別子の機能を拡張することを目的としています。
Network Working Group P. Calhoun
Request for Comments: 2794 Sun Microsystems Laboratories
Updates: 2290 C. Perkins
Category: Standards Track Nokia Research Center
March 2000
Mobile IP Network Access Identifier Extension for IPv4
IPv4のモバイル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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.
AAAサーバーは現在、インターネット内で使用されており、ダイヤルアップコンピューターに認証と承認サービスを提供しています。このようなサービスは、ノードがAAAサーバーを使用して外部ドメインに接続しようとしている場合、モバイルIPを使用するモバイルノードにとって等しく価値がある可能性があります。AAAサーバーは本日、ネットワークアクセス識別子（NAI）を使用してクライアントを識別します。私たちの提案は、モバイルIP登録要求とともにNAIを含めることにより、モバイルノードが自分自身を識別する方法を定義しています。このメモは、このオプションのモバイルノードのホームアドレスフィールドをゼロにすることにより、IPCPのモバイル-IPV4構成オプションを指定するRFC 2290も更新します。
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI) [1]. This document specifies the Mobile Node NAI extension to the Mobile IP Registration Request [7] message from the mobile node.
AAAサーバーは現在、インターネット内で使用されており、ダイヤルアップコンピューターに認証と承認サービスを提供しています。このようなサービスは、ノードがAAAサーバーを使用して外部ドメインに接続しようとしている場合、モバイルIPを使用するモバイルノードにとって等しく価値がある可能性があります。AAAサーバーは本日、ネットワークアクセス識別子（NAI）[1]を使用してクライアントを識別します。このドキュメントは、モバイルノードからのモバイルIP登録要求[7]へのモバイルノードNAI拡張機能を指定します。
Since the NAI is typically used to uniquely identify the mobile node, the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without even having a home address. A message containing the Mobile Node NAI extension MAY set the Home Address field to zero (0) in the Registration Request, to request that a home address be assigned.
NAIは通常、モバイルノードを一意に識別するために使用されるため、モバイルノードのホームアドレスは、その機能を提供するために必ずしも必要ではありません。したがって、モバイルノードが自らを認証し、自宅の住所さえ持たずに外国ドメインへの接続を許可される可能性があります。モバイルノードNAI拡張機能を含むメッセージは、登録リクエストでホームアドレスフィールドをゼロ（0）に設定して、ホームアドレスを割り当てることを要求する場合があります。
The "Mobile-IPv4 Configuration" option to IPCP has been specified in RFC 2290 [8] for proper interaction between a mobile node and a peer, through which the mobile node connects to the network using PPP. According to that specification the Mobile Node's Home Address field of the option MUST not be zero. However, in the context of this memo which allows a mobile node to be identified by its NAI and to obtain an address after the PPP phase of connection establishment, the Home Address field is allowed to be zero while maintaining all other aspects of RFC 2290. Interpretation of various scenarios from RFC 2290 is given in section 4.
IPCPへの「モバイル-IPV4構成」オプションは、モバイルノードとピアとの間の適切な相互作用のためにRFC 2290 [8]で指定されており、モバイルノードがPPPを使用してネットワークに接続します。その仕様によれば、オプションのモバイルノードのホームアドレスフィールドはゼロではありません。ただし、このメモのコンテキストでは、NAIによってモバイルノードを識別し、接続確立のPPPフェーズの後に住所を取得できるようにするため、RFC 2290の他のすべての側面を維持しながら、ホームアドレスフィールドはゼロになります。RFC 2290からのさまざまなシナリオの解釈は、セクション4に記載されています。
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 [3].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[3]に記載されているように解釈される。
The Mobile Node NAI extension, shown in figure 1, contains the user name following the format defined in [1]. When it is present in the Registration Request, the Home Address field MAY be set to zero (0). The Mobile Node NAI extension MUST appear in the Registration Request before both the Mobile-Home Authentication extension and Mobile-Foreign Authentication extension, if present.
図1に示すモバイルノードNAI拡張機能には、[1]で定義されている形式に続くユーザー名が含まれています。登録リクエストに存在する場合、ホームアドレスフィールドはゼロ（0）に設定できます。モバイルノードNAI拡張機能は、存在する場合は、モバイルホーム認証拡張機能とモバイル外定認証拡張機能の両方を前に登録要求に表示する必要があります。
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 | MN-NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Mobile Node NAI Extension
図1：モバイルノードNAI拡張機能
Type 131 (skippable) [7]
タイプ131（スキップ可能）[7]
Length The length in bytes of the MN-NAI field
長さMN-NAIフィールドのバイトの長さ
MN-NAI A string in the NAI format defined in [1].
MN-NAI [1]で定義されているNAI形式の文字列。
If Home Address is zero in the Registration Request, the foreign agent MUST use the NAI instead in its pending registration request records, along with the Identification field as usual. If the foreign agent cannot manage pending registration request records in this way, it MUST return a Registration Reply with Code indicating NONZERO_HOMEADDR_REQD (see section 5).
登録要求でホームアドレスがゼロの場合、外国人エージェントは、通常どおり識別フィールドとともに、保留中の登録要求レコードで代わりにNAIを使用する必要があります。外国人エージェントがこのように保留中の登録要求レコードを管理できない場合、non zero_homeaddr_reqdを示すコードで登録返信を返す必要があります（セクション5を参照）。
If the mobile node includes the Mobile Node NAI extension in its Registration Request, then the Registration Reply from the home agent MUST include the Mobile Node NAI extension. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_NAI (see section 5). The Registration Reply MUST include a nonzero Home Agent address and mobile node's Home Address. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 5).
モバイルノードに登録リクエストにモバイルノードNAI拡張機能が含まれている場合、ホームエージェントからの登録返信には、モバイルノードNAI拡張機能を含める必要があります。そうでない場合、外国人エージェントは登録返信をモバイルノードに送信し、コードをMissing_Naiの値に変更する必要があります（セクション5を参照）。登録返信には、ゼロ以外のホームエージェントアドレスとモバイルノードのホームアドレスを含める必要があります。そうでない場合、外国人エージェントは登録返信をモバイルノードに送信し、それぞれコードをMissing_home_agentまたはMissing_homeaddrに変更する必要があります（セクション5を参照）。
In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile Node's Home Address field may be zero. In this section, we specify the action to be taken in that case, when the mobile node is using the Mobile Node NAI extension in the Mobile IP Registration Request. Whether or not the IP Address Configuration Option contains a nonzero IP address, the mobile node will subsequently attempt to obtain a home address from the Mobile IP Registration Reply.
IPCP [8]へのモバイル-IPV4構成オプションでは、モバイルノードのホームアドレスフィールドがゼロになる可能性があります。このセクションでは、モバイルノードがモバイルIP登録リクエストでモバイルノードNAI拡張機能を使用している場合、その場合に実行するアクションを指定します。IPアドレス構成オプションにゼロ以外のIPアドレスが含まれているかどうかにかかわらず、モバイルノードはモバイルIP登録返信からホームアドレスを取得しようとします。
If the IP Address Configuration Option to IPCP has IP address equal to zero, the PPP peer is expected to allocate and assign a co-located care-of address to the Mobile Node. If, on the other hand, the IP Address Configuration Option to IPCP has a nonzero IP address, the PPP peer is expected to assign that address to the Mobile Node as its co-located care-of address.
IPCPへのIPアドレス構成オプションのIPアドレスがゼロに等しい場合、PPPピアはモバイルノードにコロアケアのケアのケアを割り当てて割り当てることが期待されます。一方、IPCPへのIPアドレス構成オプションにゼロ以外のIPアドレスがある場合、PPPピアは、そのアドレスを共同配置されたケアオブアドレスとしてモバイルノードに割り当てることが期待されます。
Finally, if the IP Address Configuration Option is left out of the IPCP Configure-Request, then no co-located care of address is assigned during IPCP. The mobile node will acquire a co-located care of address during a later stage of configuration or will use an FA-located care-of address.
最後に、IPCP Configure-RequestからIPアドレス構成オプションが除外されている場合、IPCP中に住所のコロアティングケアは割り当てられません。モバイルノードは、構成の後期段階で共同配置された住所のケアを取得するか、FA-Located Care of Addressを使用します。
Each entry in the following table contains the name and value for the Code [7] to be returned in a Registration Reply, and the section in which the error Code is first mentioned in this specification.
次の表の各エントリには、登録返信で返されるコード[7]の名前と値、およびこの仕様でエラーコードが最初に言及されているセクションが含まれています。
Error Name Value Section of Document
---------------------- ----- -------------------
NONZERO_HOMEADDR_REQD 96 3
MISSING_NAI 97 3
MISSING_HOME_AGENT 98 3
MISSING_HOMEADDR 99 3
The Mobile Node NAI extension defined in Section 2 is a Mobile IP registration extension as defined in RFC 2002 [7] and extended in RFC 2356 [6]. IANA should assign a value of 131 for this purpose.
セクション2で定義されているモバイルノードNAI拡張機能は、RFC 2002 [7]で定義され、RFC 2356 [6]で拡張されたモバイルIP登録拡張拡張機能です。IANAは、この目的のために131の値を割り当てる必要があります。
The Code values defined in Section 5 are error codes as defined in RFC 2002 and extended in RFC 2344 [5] and RFC 2356 [6]. They correspond to error values conventionally associated with rejection by the foreign agent (i.e., values from the range 64-127). IANA should record the values as defined in Section 5.
セクション5で定義されているコード値は、RFC 2002で定義され、RFC 2344 [5]およびRFC 2356 [6]で拡張されたエラーコードです。それらは、外国のエージェントによる拒絶に従来関連するエラー値（つまり、範囲64-127の値）に対応しています。IANAは、セクション5で定義されている値を記録する必要があります。
Mobile IP registration messages are authenticated, and the authentication verified by the recipient. This proposal does not prohibit the mobile node from sending its NAI in the clear over the network, but that is not expected to be a security issue.
モバイルIP登録メッセージは認証され、認証は受信者によって検証されます。この提案は、モバイルノードがNAIをネットワーク上にクリアに送信することを禁止するものではありませんが、それはセキュリティの問題であるとは予想されていません。
Supporting NAI-based registrations for Mobile IPv6 [4] is outside the scope of this document. This section contains some ideas how Stateless Address Autoconfiguration [9] and DHCPv6 [2] might be extended to support NAI-based Mobile IPv6 registrations.
モバイルIPv6 [4]のNAIベースの登録をサポートすることは、このドキュメントの範囲外です。このセクションには、STATLESTERESアドレスアドレスAutoconfiguration [9]およびDHCPV6 [2]が、NAIベースのモバイルIPv6登録をサポートするために拡張される方法が含まれています。
For mobile nodes using IPv6, there are no commonly deployed mechanisms by which a mobile node may present its credentials, such as exist today with IPv4. Nevertheless, a mobile node using IPv6 mobility may wish to specify the domain in which their credentials may be checked, by using a NAI just as this specification proposes for IPv4. In the case of IPv6, however, there is no foreign agent in place to manage the connectivity of the mobile node, and thus to manage the verification of the credentials offered by the mobile node. To identify the HDAF (see appendix A) that has the expected relationship with the mobile node, the NAI would have to be forwarded to a local AAA by the local agent involved with configuring the care-of address of the mobile node.
IPv6を使用したモバイルノードの場合、モバイルノードがIPv4に存在するような資格情報を提示する一般的な展開メカニズムはありません。それにもかかわらず、IPv6モビリティを使用したモバイルノードは、この仕様がIPv4に提案するようにNAIを使用して、資格情報をチェックするドメインを指定することをお勧めします。ただし、IPv6の場合、モバイルノードの接続性を管理するための外国人エージェントはありません。したがって、モバイルノードが提供する資格情報の検証を管理します。モバイルノードと予想される関係を持つHDAF（付録Aを参照）を特定するには、NAIをモバイルノードのケアアドレスの構成に関与するローカルエージェントによってローカルAAAに転送する必要があります。
This agent can either be a router sending out Router Advertisements [9], or a DHCPv6 server. In the former case, the router could signal its ability to handle the NAI by attaching some yet to be defined option to the Router Advertisement. In the latter case, for managed links, the mobile node could include a yet to be defined NAI extension in its DHCP Solicitation message. Such an NAI extension and appropriate authentication would also be required on the subsequent DHCP Request sent by the mobile node to the DHCP Server selected on the basis of received DHCP Advertisements. Once a care-of address on the foreign network has been obtained, the mobile node can use regular MIPv6 [4].
このエージェントは、ルーター広告[9]を送信するルーターまたはDHCPV6サーバーのいずれかです。前者の場合、ルーターは、ルーター広告にまだ定義されているオプションを添付することにより、NAIを処理する能力を信号することができます。後者の場合、管理されたリンクの場合、モバイルノードには、DHCP勧誘メッセージにまだ定義されていないNAI拡張機能を含めることができます。このようなNAI拡張機能と適切な認証は、受信したDHCP広告に基づいて選択されたDHCPサーバーにモバイルノードから送信された後続のDHCP要求にも必要です。外部ネットワーク上の住所のケアが取得されると、モバイルノードは通常のMIPV6を使用できます[4]。
The authors would like to thank Gabriel Montenegro and Vipul Gupta for their useful discussions. Thanks to Basaravaj Patil and Pete McCann for text describing actions to be taken when the home address is zero but the mobile node wishes to use the Mobile-IPv4 Configuration Option to IPCP defined in RFC 2290.
著者は、Gabriel MontenegroとVipul Guptaの有用な議論に感謝したいと思います。Basaravaj PatilとPete McCannのおかげで、ホームアドレスがゼロであるが、モバイルノードがRFC 2290で定義されたIPCPにモバイル-IPV4構成オプションを使用したい場合に実行するアクションを説明するテキストについては、
References
参考文献
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[1] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[2] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress.
[2] Bound、J。およびC. Perkins、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、進行中の作業。
[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] Johnson, D. and C. Perkins "Mobility Support in IPv6", Work in Progress.
[4] Johnson、D。およびC. Perkins「IPv6のモビリティサポート」は、進行中の作業です。
[5] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[5] モンテネグロ、G。、「モバイルIPの逆トンネル」、RFC 2344、1998年5月。
[6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[6] モンテネグロ、G。およびV.グプタ、「モバイルIPのSun's Skip Firewalversal」、RFC 2356、1998年6月。
[7] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[7] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[8] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[8] Solomon、J。およびS. Glass、「PPP IPCPのモバイル-IPV4構成オプション」、RFC 2290、1998年2月。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[9] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
A. Home Domain Allocation Function (HDAF)
A.ホームドメイン割り当て関数（HDAF）
This appendix introduces a new function named the Home Domain Allocation Function (HDAF) that can dynamically assign a Home Address to the mobile node.
この付録では、モバイルノードにホームアドレスを動的に割り当てることができるホームドメイン割り当て関数（HDAF）という名前の新しい関数を紹介します。
Figure 2 illustrates the Home HDAF, which receives messages from foreign agents (e.g., FA) and assigns a Home Address within the Home Domain. The HDAF does not perform any Mobile IP processing on the Registration Request, but simply forwards the request to a Home Agent (HA) within the network that is able to handle the request.
図2は、外国人エージェント（FAなど）からメッセージを受信し、ホームドメイン内のホームアドレスを割り当てるホームHDAFを示しています。HDAFは、登録リクエストでモバイルIP処理を実行しませんが、リクエストを処理できるネットワーク内のホームエージェント（HA）にリクエストを転送するだけです。
+------+
| |
+---+ HA-1 |
+------+ +------+ +------+ | | |
| | | | | | | +------+
| MN |-------| FA |-------| HDAF +---+ ...
| | | | | | | +------+
+------+ +------+ +------+ | | |
+---+ HA-n |
| |
+------+
Figure 2: Home Domain Allocator Function (HDAF)
図2：ホームドメインアロケーター機能（HDAF）
Upon receipt of the Registration Request from the mobile node (MN), FA extracts the NAI and finds the domain name associated with it. FA then finds the HDAF that handles requests for the mobile node's domain. The discovery protocol is outside of the scope of this specification. As an example, however, FA might delegate the duty of finding a HDAF to a local AAA server. The local AAA server may also assist FA in the process of verifying the credentials of the mobile node, using protocols not specified in this document.
モバイルノード（MN）からの登録要求を受信すると、FAはNAIを抽出し、それに関連付けられたドメイン名を見つけます。FAは、モバイルノードのドメインのリクエストを処理するHDAFを見つけます。ディスカバリープロトコルは、この仕様の範囲外です。ただし、例として、FAは、HDAFをローカルAAAサーバーに見つける義務を委任する場合があります。ローカルAAAサーバーは、このドキュメントで指定されていないプロトコルを使用して、モバイルノードの資格情報を確認するプロセスでFAを支援する場合があります。
Addresses
アドレス
The working group can be contacted via the current chairs:
ワーキンググループは、現在の椅子から連絡できます。
Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving, TX 75039 USA
Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving、TX 75039 USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
フィルロバーツモトローラ1501ウェストシュアードライブアーリントンハイツ、イリノイ60004 USA
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Questions about this memo can be directed to:
このメモに関する質問は、次のように向けることができます。
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Pat R. Calhoun Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
PAT R. Calhoun Sun Systems Laboratories 15 Network Circle Menlo Park、California 94025 USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。