Network Working Group F. Johansson
Request for Comments: 3846 ipUnplugged
Category: Standards Track T. Johansson
Bytemobile
June 2004
Mobile IPv4 Extension for Carrying Network Access Identifiers
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes.
モバイルノードは、2つの外部ネットワーク間を移動するとき、それは再認証されなければなりません。ホームネットワークを使用して複数の認証認可およびアカウンティング（AAA）サーバおよびホームエージェント（HAS）の両方を持っている場合は、ホームAAAサーバが正常に再認証を処理するのに十分な情報を持っていないかもしれません（すなわち、同じHAが続くことを保証するために、使用されます）。この文書では、ネットワークアクセス識別子（のNAI）の形でホームAAAとHAサーバのアイデンティティを運ぶモバイルIP拡張を定義します。拡張は、ホーム・エージェントは接続点を変更するときに、ローカルAAAサーバに渡すことができるモバイルノードにそのアイデンティティ（ホームAAAサーバの）を通過することを可能にします。この拡張は、モバイルIPノード間NAIの通信を必要とする他の状況で使用することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 2
3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 3
3.1. Processing of the NAI Carrying Extension . . . . . . . . 3
4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 4
5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
When building networks one would like to be able to have redundancy. In order to achieve this, one might place multiple AAA servers in one domain. When a mobile node registers via a visited network, the authentication will be handled by one of the AAA servers in the home domain. At a later point, when the mobile node moves to another visited domain it again has to be authenticated. However, due to the redundancy offered by the AAA protocol, it can not be guaranteed that the authentication will be handled by the same AAAH server as the previous one, which can result in the new AAAH not knowing to which HA the session was assigned. This document defines a Mobile IP extension which can be used to distribute the information needed to resolve this.
ネットワークを構築する場合1は、冗長性を持ってできるようにしたいと思います。これを達成するためには、一つのドメインに複数のAAAサーバを配置することがあります。モバイルノードが訪問先ネットワーク経由で登録すると、認証がホームドメインのAAAサーバのいずれかによって処理されます。別の移動ノードの移動は、ドメインを訪問した際に、後の時点で、再度認証される必要があります。しかし、AAAプロトコルによって提供される冗長性のために、認証がどのHAセッションが割り当てられていたために知らない新しいAAAHをもたらすことが以前のものと同じAAAHサーバによって処理されることを保証することはできません。この文書では、この問題を解決するために必要な情報を配布するために使用することができ、モバイルIP拡張を定義します。
Furthermore, the only information that is normally available about the home agent in the registration request is the IP address as defined in RFC 3344 [5]. Unfortunately this may not be enough since some AAA infrastructures (such as Diameter [6]) use realm based routing; such a AAA infrastructure needs to know the FQDN identity of the home agent to be able to correctly handle the assignment of the home agent. A reverse DNS lookup would only disclose the identity of the Mobile IP interface for that HA IP address, which may or may not have a one-to-one correspondence with the home agent FQDN identity. This is a reason for the HA to also include its own identity in the registration reply. The MIP v4 extension defined in this document also has a subtype defined by which this may be done. The HA identity can then be included by the mobile node in later registration requests when changing the point of attachment.
さらに、登録要求内のホームエージェントについての通常利用可能である唯一の情報は、RFC 3344で定義されているIPアドレスがある[5]。残念ながら、これは十分ではないかもしれないので、いくつかのAAAインフラストラクチャ（例えば直径として[6]）レルムベースのルーティングを使用します。そのようなAAAインフラストラクチャは、正しくホームエージェントの割り当てを扱うことができるように、ホームエージェントのFQDNの身元を知っている必要があります。 DNSの逆引き参照のみ、またはホームエージェントFQDNのアイデンティティと1対1で対応していない可能性があり、そのHAのIPアドレス、モバイルIPインタフェースの身元を開示するでしょう。これはまた、登録応答に独自のアイデンティティを含むようにHAの理由です。この文書で定義されたMIPのV4の拡張はまた、これを行うことができることにより定義されたサブタイプを有しています。結合点を変更するときHAのアイデンティティはその後登録要求にモバイルノードによって含まれることができます。
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 BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
The Mobile IP related terminology described in RFC 3344 [5] is used in this document. In addition, the following terms are used:
RFC 3344に記載のモバイルIPに関連する用語は、[5]この文書で使用されています。また、以下の用語が使用されます。
AAAH One of several possible AAA Servers in the Home Network
ホームネットワーク内のいくつかの可能なAAAサーバのAAAH一つ
FQDN Fully Qualified Domain Name.
FQDN完全修飾ドメイン名。
Identity The identity of a node is equal to its FQDN.
アイデンティティノードのアイデンティティは、そのFQDNと同じです。
NAI Network Access Identifier [2].
NAIネットワークアクセス識別子[2]。
This section defines the NAI Carrying Extension which may be used in Mobile IP Registration Request and Reply messages, and also in Mobile IP Agent Advertisements [5]. The extension may be used by any node that wants to send identity information in the form of a NAI [4]. This document also defines some subtype numbers which identify the specific type of NAI carried in Sections 4 and 5. It is expected that other types of NAI will be defined by other documents in the future.
このセクションでは、モバイルIPエージェント広告[5]において、モバイルIP登録要求に使用され、メッセージを返信してもよく、NAI保持する拡張を定義します。拡張は、NAI [4]の形式で識別情報を送信したい任意のノードによって使用されてもよいです。また、このドキュメントは、セクション4,5 NAIの他のタイプは、将来において他の文書によって定義されることが期待されるで運ば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 | Sub-Type | NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 136 (skippable) [5].
136（スキップ可能）を入力し[5]。
Length 8-bit unsigned integer. Length of the extension, in octets, excluding the extension Type and the extension Length fields. This field MUST be set to 1 plus the total length of the NAI field.
長さ8ビットの符号なし整数。拡張タイプと拡張長フィールドを除くオクテット単位で延長の長さ、。このフィールドは、NAIフィールドの合計の長さに1を加えたに設定しなければなりません。
Sub-Type This field describes the particular type NAI which is carried in the NAI field.
サブタイプは、このフィールドはNAIのフィールドで運ばれる特定のタイプのNAIを記載しています。
NAI Contains the NAI [2] in a string format.
NAIは、文字列形式でNAI [2]を含みます。
When a mobile node or home agent adds a NAI Carrying Extension to a registration message, the extension MUST appear prior to any authentication extensions.
モバイルノードまたはホームエージェントは、登録メッセージにNAI保持する拡張を追加すると、拡張子が任意の認証拡張する前に現れなければなりません。
In the event the foreign agent adds a NAI Carrying Extension to a registration message, the extension MUST appear prior to any authentication extensions added by the FA.
外国人のエージェントが登録メッセージにNAI保持する拡張を追加する場合には、拡張子がFAで追加された認証拡張する前に現れなければなりません。
If an HA has appended a NAI Carrying Extension to a Registration Reply to an MN, and does not receive the NAI extension in subsequent Registration Request messages from the MN, the HA can assume that the MN does not understand this NAI extension. In this case, the HA SHOULD NOT append this NAI extension to further Registration Reply messages to the MN.
HAは、MNに登録応答にNAI保持する拡張を付加した、とMNからの後続の登録要求メッセージにNAI拡張を受信しない場合、HAは、MNは、このNAI拡張を理解しないと仮定することができます。この場合、HAは、MNにさらに登録応答メッセージに、このNAI拡張子を付加すべきではありません。
The HA identity uses subtype 1 of the NAI Carrying Extension. It contains the NAI of the HA in the form hostname@realm. Together the hostname and realm form the complete FQDN (hostname.realm) of the HA.
HAのアイデンティティはNAI保持する拡張のサブタイプ1を使用しています。これは、フォームのホスト名@レルムにHAのNAIが含まれています。一緒にホスト名とレルムは、HAの完全なFQDN（hostname.realm）を形成します。
A Home Agent using this extension MUST provide it in the first Registration Reply sent to a Mobile Node which is not currently registered. The extension only need to be included in subsequent Registration Replies if the same extension is included in Registration Requests received from the same Mobile Node.
この拡張機能を使用して、ホームエージェントは、現在登録されていないモバイルノードに送られた最初の登録応答でそれを提供しなければなりません。同じ拡張子が同じモバイルノードから受信した登録要求に含まれている場合にのみ、後続の登録に含める必要が拡張子が返信します。
A mobile node using this extension MUST, if it receives it in a registration reply message, provide it in every subsequent registration request when re-authentication is needed. Failure to re-authenticate, for instance because no AAAH can be reached, will result in termination of the Mobile-IP session. Upon initiation of a new session a new HA Identity NAI may be provided to the Mobile node, and the requirement above will apply to the newly received NAI.
それは登録応答メッセージでそれを受信した場合は、この拡張を使用する移動ノードは、再認証が必要とされるすべての後続の登録要求でそれを提供しなければなりません。何AAAHに到達できないので、例えば、再認証に失敗すると、モバイルIPセッションの終了になります。新しいセッションの開始時に新しいHAアイデンティティNAIは、モバイルノードに提供することができる、上記の要件は、新たに受信したNAIに適用されます。
If the mobile node requires a specific home agent and it has the NAI available it MUST provide this extension in its initial registration request.
モバイルノードが特定のホームエージェントを必要とし、それはNAIが利用できる持っている場合には、その初期登録要求にこの拡張機能を提供しなければなりません。
A foreign agent which receives the Home Agent NAI by this extension in a registration request SHOULD include the Home Agent NAI when requesting Mobile Node authentication through the AAA infrastructure if the AAA protocol used can carry the information.
AAAプロトコルは、情報を運ぶことができる使用される場合、AAAインフラストラクチャを介してモバイルノードの認証を要求するとき、登録要求においてこの拡張により、ホームエージェントNAIを受信した外部エージェントは、ホームエージェントNAIを含むべきです。
The AAAH identity uses subtype 2 of the NAI Carrying Extension. It contains the NAI of the home AAA server in the form hostname@realm. Together the hostname and realm form the complete FQDN (hostname.realm) of the home AAA server.
AAAHのアイデンティティはNAI保持する拡張のサブタイプ2を使用しています。これは、フォームのホスト名@レルムのホームAAAサーバのNAIが含まれています。一緒にホスト名とレルムは、ホームAAAサーバの完全なFQDN（hostname.realm）を形成します。
If several AAA servers exist in the Home Network, a Home Agent providing AAAH selection support according to this document MUST provide the AAAH identity in the first Registration Reply sent to the Mobile Node. The extension only needs to be included in subsequent Registration Replies if the same extension is included in Registration Requests received from the same Mobile Node.
いくつかのAAAサーバがホームネットワーク内に存在する場合は、ホームエージェントは、モバイルノードに送信された最初の登録応答でAAAHのアイデンティティを提供しなければならない、この文書によるとAAAH選択支援を提供します。同じ拡張子が同じモバイルノードから受信した登録要求に含まれている場合、後続の登録は返信に拡張子のみが含まれる必要があります。
A mobile node SHOULD save the latest AAAH Identity received in a registration reply message and SHOULD provide the AAAH Identity in every registration request sent when re-authenticating, for efficiency reasons. Failure to reach the indicated AAAH during re-authentication will result in a new AAAH Identity NAI being returned (which should then be saved and provided in subsequent registration requests). Similarly, failure to re-authenticate, for instance because no AAAH can be reached, will result in termination of the Mobile-IP session; on initiation of a new session, a new AAAH Identity NAI may be provided to the Mobile Node for re-use during later re-registrations.
モバイルノードは、最新のAAAHのアイデンティティが登録応答メッセージで受信し、効率上の理由から、再認証送られたすべての登録要求にAAAHアイデンティティを提供すべきで保存する必要があります。再認証中に示されたAAAHに到達しなかった場合は（その後、保存され、以降の登録要求で提供されるべき）新しいAAAHアイデンティティNAIが返されるになります。何AAAHに到達できないので、同様に、障害がモバイルIPセッションの終了になり、例えば、再認証します。新しいセッションの開始時に、新しいAAAHアイデンティティNAIは、後に再登録の際に再利用するためにモバイルノードに提供することができます。
A foreign agent which receives the AAAH NAI by this extension in a registration request SHOULD include the AAAH NAI provided when requesting Mobile Node authentication through the AAA infrastructure if the AAA protocol used can carry the information.
登録要求にこの拡張によりAAAH NAIを受信した外部エージェントは、AAAH NAIを含むべきで使用AAAプロトコルは、情報を運ぶことができる場合は、AAAインフラストラクチャを介してモバイルノードの認証を要求するときに提供されます。
This specification introduces new Mobile IP extensions that are used to carry mobility agent and AAA server identities, in the form of Network Access Identifiers. The Mobile IP messages that carry this extension MUST be authenticated as described in [4], unless other authentication methods have been agreed upon. Therefore, this specification does not lessen the security of Mobile IP messages.
この仕様は、ネットワークアクセス識別子の形で、モビリティエージェントとAAAサーバのアイデンティティを運ぶために使用される新しいモバイルIP拡張を紹介します。 [4]で説明されるように他の認証方法が合意されていない限り、この拡張を運ぶモバイルIPメッセージは、認証されなければなりません。したがって、この仕様は、モバイルIPメッセージのセキュリティを軽減しません。
It should be noted that the identities sent in the extensions specified herein MAY be sent in the clear over the network. However, the authors do not envision that this information would create security issues.
ここに指定された拡張子で送信されたアイデンティティがネットワーク上で平文で送信されるかもしれないことに留意すべきです。しかし、著者は、この情報はセキュリティ上の問題を作成することを想定していません。
This document defines one new mobile IP extension, and one new Mobile IP extension sub-type numbering space to be managed by IANA.
この文書は、IANAによって管理される1つの新しいモバイルIP拡張、および1つの新しいモバイルIP内線サブタイプ番号スペースを定義します。
Section 3 defines a new Mobile IP extension, the Mobile IP NAI Carrying Extension. The type number for this extension is 136. This extension introduces a new sub-type numbering space where the values
第3節では、新たなモバイルIP内線、モバイルIP NAI保持する拡張を定義します。この拡張のタイプ番号136この拡張は、ここでの値の新しいサブタイプの番号空間を導入しています
1 and 2 have been assigned in this document. Approval of new Mobile IP NAI Carrying Extension sub-type numbers is subject to Expert Review, and a specification is required [3].
1と2は、本文書に割り当てられています。新しいモバイルIP NAI保持する拡張サブタイプ番号の承認は、専門家レビューの対象であり、仕様が必要とされる[3]。
The content and format for this extension is not specific to AAA NAIs, so if in the future new NAIs are defined which do not strictly fall within the category of AAA NAIs, they may nevertheless be accommodated within the subtype numbering space defined for the NAI Carrying Extension defined in this document.
将来新しいのNAIで定義されている場合は厳密にAAAのNAIの範疇ではありませんどのように、この拡張の内容と形式は、AAAのNAIに固有のものではない、彼らはそれにもかかわらず、NAIは、キャリング用に定義されたサブタイプ番号スペース内に収容することができますこの文書で定義された拡張。
The NAI Carrying Extension should be assigned a type value from both the IANA number space for Mobile IPv4 skippable extensions and from the IANA number space for Mobile IPv4 advertisement extensions. Ideally, the numbers assigned from these two numbering spaces should have the same value.
NAI保持する拡張は、モバイルIPv4スキップ可能な拡張およびモバイルIPv4広告の拡張のためのIANA番号空間からIANA番号空間の両方からタイプ値を割り当てなければなりません。理想的には、これらの二つの番号のスペースから割り当てられた番号は、同じ値を持つ必要があります。
Thanks to the original authors of the GNAIE document, Mohamed M Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. Calhoun. The original document was removed from the MIP WG charter when no use was seen for the extension. The original ideas have been reused in this document. Also thanks to Henrik Levkowetz and Kevin Purser for valuable feedback and help when writing this document.
GNAIEドキュメントの原作者、モハメド・Mカリル、エマドQaddoura、ハシーブAkhtarさん、そしてパットR.カルフーンに感謝します。無駄を拡張するために見られなかった場合、原稿は、MIP WGチャーターから除去しました。独創的なアイデアは、この文書で再利用されています。また、貴重なフィードバックとヘルプのためのヘンリクLevkowetzとケビン・パーサーのおかげでこの文書を執筆。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[2] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[4] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[4]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[5]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[6]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
Fredrik Johansson ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN
フレドリック・ヨハンソンIpUnplugged AB Arenavagen 23ストックホルムS-121 28 SWEDEN
Phone: +46 8 725 5916 EMail: fredrik@ipunplugged.com
電話：+46 8 725 5916 Eメール：fredrik@ipunplugged.com
Tony Johansson Bytemobile Inc 2029 Stierlin Court Mountain View, CA 94043 USA
トニー・ヨハンソンバイトモバイル株式会社2029 Stierlin法廷マウンテンビュー、CA 94043 USA
Phone: +1 650 862 0523 EMail: tony.johansson@bytemobile.com
電話：+1 650 862 0523 Eメール：tony.johansson@bytemobile.com
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。