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
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.
著作権（C）インターネット協会（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は通常、一意のモバイルノードを識別するために使用されているので、モバイルノードのホームアドレスは、その機能を提供することは必ずしも必要ではありません。したがって、モバイルノードが自身を認証することが可能であり、さらにホームアドレスを持たず、外部ドメインへの接続を許可します。 （0）登録要求に、ホームアドレスが割り当てられることを要求するためにゼロにホームアドレスフィールドを設定することができ、モバイルノードNAI拡張を含むメッセージ。
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の構成」オプションは、モバイルノードは、PPPを使用してネットワークに接続し、それを通してモバイルノードとピアとの間の適切な相互作用のために[8] RFC 2290に指定されています。その仕様によると、オプションのモバイルノードのホームアドレスフィールドはゼロにすることはできません。 RFC 2290のすべての他の側面を維持しながら、しかし、モバイルノードは、そのNAIによって識別されると、接続確立のPPPフェーズ後のアドレスを取得することができ、このメモの文脈において、ホームアドレスフィールドがゼロであることが許されます。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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]
[7] 131（スキップ可能）を入力
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を使用しなければなりません。外国人のエージェントは、このように登録要求レコードを保留管理することができない場合、それはNONZERO_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を参照）にコードを変更し、モバイルノードに登録応答を送るべきです。登録応答は、ゼロ以外ホームエージェントアドレスとモバイルノードのホームアドレスを含まなければなりません。そうでない場合、外部エージェントは、（セクション5を参照）は、それぞれ、値MISSING_HOME_AGENTまたはMISSING_HOMEADDRにコードを変更し、モバイルノードへの登録応答を送信すべきです。
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へのモバイルIPv4の設定オプションでは、[8]、モバイルノードのホームアドレスフィールドはゼロであってもよいです。モバイルノードは、モバイル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
IPCPのIPアドレス構成オプションがゼロに等しいIPアドレスを持っている場合、PPPピアはモバイルノードに同一位置気付アドレスを割り当て、割り当てることが期待されます。一方、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アドレスを持っている、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.
IPアドレスの設定オプションは、IPCP設定要求の外に残っている場合は最後に、その後、アドレスのない同じ場所に配置ケアは、IPCP中に割り当てられていません。モバイルノードは、構成の後の段階の間にアドレスの同一位置のケアを取得するか、FA-位置気付アドレスを使用します。
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.
RFC 2002で定義されるように、セクション2で定義されたモバイルノードNAI拡張はモバイルIP登録の拡張である[7]及びRFC 2356に延び[6]。 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からの値）。第5節で定義されているIANAは値を記録する必要があります。
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.
[4]モバイルIPv6のためのNAIに基づく登録をサポートすることは、この文書の範囲外です。このセクションでは、自動設定は、[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.
著者は彼らの有益な議論のためのガブリエルモンテネグロとビパル・グプタに感謝したいと思います。ホームアドレスはゼロですが、モバイルノードは、RFC 2290で定義されたIPCPするモバイルIPv4の設定オプションを使用したいときにアクションを記述するテキストのBasaravajパティルとピートマッキャンのおかげで取られます。
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]結合した、J.およびC.パーキンスを、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、ProgressのWork。
[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] Johnson, D. and C. Perkins "Mobility Support in IPv6", Work in Progress.
[4]ジョンソン、D.およびC.パーキンス「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のための日のSKIPファイアウォール越え"、RFC 2356、1998年6月。
[7] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[7]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[8] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[8]ソロモン、J.及びS.ガラス、 "PPP IPCPのためのモバイルIPv4の設定オプション"、RFC 2290、1998年2月。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[9]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、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は、ローカルAAAサーバにHDAFを見つけるの義務を委任することがあります。ローカル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パティルノキア・コーポレーション6000接続のドライブM / S M8-540アービング、TX 75039 USA
Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com
電話：+1 972-894-6709ファックス：+1 972-894-5349電子メール：Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
フィル・ロバーツモトローラ1501西シュアードライブアーリントンハイツ、IL 60004 USA
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
電話：+1 847-632-3148電子メール：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
電話：+ 1-650 625-2986ファックス：+1 650 625-2502 Eメール：charliep@iprg.nokia.com
Pat R. Calhoun Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
パットR.カルフーンSun Microsystemsの研究所15ネットワークサークルメンロパーク、カリフォルニア94025 USA
Phone: +1 650-786-7733 Fax: +1 650-786-6445 EMail: pcalhoun@eng.sun.com
電話：+1 650-786-7733ファックス：+1 650-786-6445電子メール：pcalhoun@eng.sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。