RFC4283 日本語訳
4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel,K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT=14653 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Patel
Request for Comments: 4283 K. Leung
Category: Standards Track Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
November 2005
コメントを求めるワーキンググループA.パテル要求をネットワークでつないでください: 4283年のK.レオンカテゴリ: K.チョードリStarentが2005年11月にネットワークでつなぐ標準化過程シスコシステムズM.カリルH.Akhtarノーテルネットワーク
Mobile Node Identifier Option for Mobile IPv6 (MIPv6)
モバイルIPv6のためのモバイルノード識別子オプション(MIPv6)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header.
モバイルIPv6(MIPv6)は結合の作成と管理に関連するすべてのメッセージングでモバイルノード、通信員ノード、およびホームのエージェントによって使用される新しいMobilityヘッダーを定義します。 モバイルIPv6ノードはデフォルトホームIPアドレス以外のアイデンティティを使用することで自分たちを特定する能力を必要とします。 識別子に関するいくつかの例がNetwork Access Identifier(NAI)、Fully Qualified Domain Name(FQDN)、国際モバイル駅のIdentifier(IMSI)、およびモバイルSubscriber Number(MSISDN)を含んでいます。 このドキュメントはモバイルIPv6実体によって使用される、移動性ヘッダーを含んでいて、メッセージで自分たちを特定できる新しい移動性オプションを定義します。
Patel, et al. Standards Track [Page 1] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[1ページ]RFC4283のモバイルノード識別子オプション
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Mobile Node Identifier Option ...................................3
3.1. MN-NAI Mobility Option .....................................4
3.2. Processing Considerations ..................................4
4. Security Considerations .........................................4
4.1. General Considerations .....................................4
4.2. MN-NAI Considerations ......................................4
5. IANA Considerations .............................................5
6. Acknowledgements ................................................5
7. Normative References ............................................5
8. Informative Reference ...........................................6
1. 序論…2 2. 用語…3 3. モバイルノード識別子オプション…3 3.1. ミネソタ-NAI移動性オプション…4 3.2. 処理問題…4 4. セキュリティ問題…4 4.1. 一般問題…4 4.2. ミネソタ-NAI問題…4 5. IANA問題…5 6. 承認…5 7. 標準の参照…5 8. 有益な参照…6
1. Introduction
1. 序論
The base specification of Mobile IPv6 [RFC3775] identifies mobility entities using an IPv6 address. It is essential to have a mechanism wherein mobility entities can be identified using other identifiers (for example, a Network Access Identifier (NAI) [RFC4282], International Mobile Station Identifier (IMSI), or an application/ deployment specific opaque identifier).
モバイルIPv6[RFC3775]に関する基礎仕様は、IPv6アドレスを使用することで移動性実体を特定します。 他の識別子(例えば、Network Access Identifier(NAI)[RFC4282]、国際モバイル駅のIdentifier(IMSI)、またはアプリケーション/展開の特定の不明瞭な識別子)を使用することで移動性実体を特定できるメカニズムを持っているのは不可欠です。
The capability to identify a mobility entity via identifiers other than the IPv6 address can be leveraged for performing various functions, for example,
例えば、様々な機能を実行するためにIPv6アドレス以外の識別子で移動性実体を特定する能力を利用することができます。
o authentication and authorization using an existing AAA
(Authentication, Authorization, and Accounting) infrastructure or
via an HLR/AuC (Home Location Register/Authentication Center)
o 既存のAAA(認証、Authorization、およびAccounting)インフラストラクチャかHLR/AuCを通した認証と承認使用(ホーム位置のレジスタ/認証センター)
o dynamic allocation of a mobility anchor point
o 移動性アンカー・ポイントの動的割当て
o dynamic allocation of a home address
o ホームアドレスの動的割当て
This document defines an option with a subtype number that denotes a specific type of identifier. One instance of subtype, the NAI, is defined in Section 3.1. It is anticipated that other identifiers will be defined for use in the mobility header in the future.
このドキュメントは特定のタイプの識別子を指示する「副-タイプ」番号でオプションを定義します。 「副-タイプ」の1つのインスタンス(NAI)がセクション3.1で定義されます。 他の識別子が将来移動性ヘッダーにおける使用のために定義されると予期されます。
This option SHOULD be used when Internet Key Exchange (IKE)/IPsec is not used for protecting binding updates or binding acknowledgements as specified in [RFC3775]. It is typically used with the authentication option [RFC4285]. But this option may be used independently. For example, the identifier can provide accounting and billing services.
これは、インターネット・キー・エクスチェンジ(IKE)/IPsecが拘束力があるアップデートを保護するのに使用されないとき、使用されるか、または[RFC3775]での指定されるとしての承認を縛りながら、SHOULDにゆだねます。 それは認証オプション[RFC4285]と共に通常使用されます。 しかし、このオプションは独自に使用されるかもしれません。 例えば、識別子は会計と支払いサービスを提供できます。
Patel, et al. Standards Track [Page 2] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[2ページ]RFC4283のモバイルノード識別子オプション
2. Terminology
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Mobile Node Identifier Option
3. モバイルノード識別子オプション
The Mobile Node Identifier option is a new optional data field that is carried in the Mobile IPv6-defined messages that includes the Mobility header. Various forms of identifiers can be used to identify a Mobile Node (MN). Two examples are a Network Access Identifier (NAI) [RFC4282] and an opaque identifier applicable to a particular application. The Subtype field in the option defines the specific type of identifier.
モバイルNode Identifierオプションは新しい任意のデータ・フィールドです、すなわち、モバイルIPv6によって定義されたメッセージで運ばれて、それがMobilityヘッダーを含んでいます。 モバイルNode(ミネソタ)を特定するのに様々なフォームに関する識別子を使用できます。 2つの例が、Network Access Identifier(NAI)[RFC4282]と特定用途に適切な不明瞭な識別子です。 オプションにおけるSubtype分野は識別子の特定のタイプを定義します。
This option can be used in mobility messages containing a mobility header. The subtype field in the option is used to interpret the specific type of identifier.
移動性ヘッダーを含んでいて、移動性メッセージでこのオプションを使用できます。 オプションにおける「副-タイプ」分野は、識別子の特定のタイプを解釈するのに使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 識別子… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type:
オプションタイプ:
MN-ID-OPTION-TYPE has been assigned value 8 by the IANA. It is
an 8-bit identifier of the type mobility option.
ミネソタID OPTION-TYPEはIANAによる割り当てられた値8です。 それはタイプ移動性オプションの8ビットの識別子です。
Option Length:
オプションの長さ:
8-bit unsigned integer, representing the length in octets of
the Subtype and Identifier fields.
8ビットの符号のない整数、Subtypeの八重奏における長さを表して、およびIdentifier分野。
Subtype:
Subtype:
Subtype field defines the specific type of identifier included
in the Identifier field.
Subtype分野はIdentifier分野に識別子を含む特定のタイプを定義します。
Identifier:
識別子:
A variable length identifier of type, as specified by the
Subtype field of this option.
このオプションのSubtype分野によって指定されるようなタイプに関する可変長識別子。
Patel, et al. Standards Track [Page 3] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[3ページ]RFC4283のモバイルノード識別子オプション
This option does not have any alignment requirements.
このオプションには、どんな整列要求もありません。
3.1. MN-NAI Mobility Option
3.1. ミネソタ-NAI移動性オプション
The MN-NAI mobility option uses the general format of the Mobile Node Identifier option as defined in Section 3. This option uses the subtype value of 1. The MN-NAI mobility option is used to identify the mobile node.
ミネソタ-NAI移動性オプションはセクション3で定義されるようにモバイルNode Identifierオプションの一般形式を使用します。 このオプションは1の「副-タイプ」値を使用します。 ミネソタ-NAI移動性オプションは、モバイルノードを特定するのに使用されます。
The MN-NAI mobility option uses an identifier of the form user@realm [RFC4282]. This option MUST be implemented by the entities implementing this specification.
ミネソタ-NAI移動性オプションはフォーム user@realm [RFC4282]に関する識別子を使用します。 この仕様を履行する実体でこのオプションを実装しなければなりません。
3.2. Processing Considerations
3.2. 処理問題
The location of the MN Identifier option is as follows: When present, this option MUST appear before any authentication-related option in a message containing a Mobility header.
ミネソタのIdentifierオプションの位置は以下の通りです: 存在しているとき、Mobilityヘッダーを含んでいて、このオプションはどんな認証関連のオプションの前にもメッセージに現れなければなりません。
4. Security Considerations
4. セキュリティ問題
4.1. General Considerations
4.1. 一般問題
Mobile IPv6 already contains one mechanism for identifying mobile nodes, the Home Address option [RFC3775]. As a result, the vulnerabilities of the new option defined in this document are similar to those that already exist for Mobile IPv6. In particular, the use of a permanent, stable identifier may compromise the privacy of the user, making it possible to track a particular device or user as it moves through different locations.
モバイルIPv6は既にモバイルノード、ホームAddressオプション[RFC3775]を特定するための1つのメカニズムを含んでいます。 その結果、本書では定義された新しいオプションの脆弱性はモバイルIPv6のために既に存在するものと同様です。 特に、永久的で、安定した識別子の使用はユーザのプライバシーに感染するかもしれません、別の場所を通って移行するとき特定のデバイスかユーザを追跡するのを可能にして。
4.2. MN-NAI Considerations
4.2. ミネソタ-NAI問題
Since the Mobile Node Identifier option described in Section 3 reveals the home affiliation of a user, it may assist an attacker in determining the identity of the user, help the attacker in targeting specific victims, or assist in further probing of the username space.
セクション3で説明されたモバイルNode Identifierオプションがユーザのホーム提携を明らかにするので、それは、ユーザのアイデンティティを決定するのに攻撃者を助けるか、攻撃者が特定の犠牲者を狙うのを手伝うか、またはさらにユーザ名スペースを調べるのを助けるかもしれません。
These vulnerabilities can be addressed through various mechanisms, such as those discussed below:
以下で議論したものなどの様々なメカニズムを通してこれらの脆弱性を扱うことができます:
o Encrypting traffic at the link layer, such that other users on the
same link do not see the identifiers. This mechanism does not
help against attackers on the rest of the path between the mobile
node and its home agent.
o 同じリンクの上の他のユーザが識別子を見ないように、トラフィックをリンクレイヤに暗号化します。 このメカニズムはモバイルノードとそのホームのエージェントの間の経路の残りのときに攻撃者に対して助けません。
o Encrypting the whole packet, such as when using IPsec to protect
the communications with the home agent [RFC3776].
o ホームのエージェント[RFC3776]とのコミュニケーションを保護するのにIPsecを使用することでいつなどの全体のパケットを暗号化するか。
Patel, et al. Standards Track [Page 4] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[4ページ]RFC4283のモバイルノード識別子オプション
o Using an authentication mechanism that enables the use of privacy
NAIs [RFC4282] or temporary, changing "pseudonyms" as identifiers.
o 識別子としてプライバシーNAIs[RFC4282]、または一時的で、変化している「匿名」の使用を可能にする認証機構を使用します。
In any case, it should be noted that as the identifier option is only needed on the first registration at the home agent and subsequent registrations can use the home address, the window of privacy vulnerability in this document is reduced as compared to [RFC3775]. In addition, this document is a part of a solution to allow dynamic home addresses to be used. This is an improvement to privacy as well, and it affects both communications with the home agent and the correspondent nodes, both of which have to be told the home address.
どのような場合でも、[RFC3775]と比べて、識別子オプションが最初の登録のときにホームのエージェントで必要であるだけであり、その後の登録証明書がホームアドレスを使用できるのに従ってプライバシー脆弱性の窓が本書では減少することに注意されるべきです。 さらに、このドキュメントはダイナミックなホームアドレスが使用されるのを許容するソリューションの一部です。 これはまた、プライバシーへの改良です、そして、それはホームのエージェントとのコミュニケーションと通信員ノードの両方に影響します。ホームアドレスはその両方に言われなければなりません。
5. IANA Considerations
5. IANA問題
The values for new mobility options must be assigned from the Mobile IPv6 [RFC3775] numbering space.
モバイルIPv6[RFC3775]付番スペースから新しい移動性オプションのための値を割り当てなければなりません。
The IANA has assigned the value 8 for the MN-ID-OPTION-TYPE.
IANAはミネソタID OPTION-TYPEのために値8を割り当てました。
In addition, IANA has created a new namespace for the subtype field of the Mobile Node Identifier option. The currently allocated values are as follows:
さらに、IANAはモバイルNode Identifierオプションの「副-タイプ」分野に新しい名前空間を作成しました。 現在割り当てられた値は以下の通りです:
NAI (defined in [RFC4282]).
NAI([RFC4282]では、定義されます)。
New values for this namespace can be allocated using Standards Action [RFC2434].
Standards Action[RFC2434]を使用することでこの名前空間のための新しい値を割り当てることができます。
6. Acknowledgements
6. 承認
The authors would like to thank Basavaraj Patil for his review and suggestions on this document. Thanks to Jari Arkko for review and suggestions regarding security considerations and various other aspects of the document.
作者はこのドキュメントの上に彼のレビューと提案についてBasavarajパティルに感謝したがっています。 セキュリティ問題に関するレビューと提案とドキュメントの他の様々な局面をヤリArkkoをありがとうございます。
7. Normative References
7. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
Patel, et al. Standards Track [Page 5] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[5ページ]RFC4283のモバイルノード識別子オプション
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec
to Protect Mobile IPv6 Signaling Between Mobile Nodes
and Home Agents", RFC 3776, June 2004.
[RFC3776] Arkko、J.、Devarapalli、V.、およびF.デュポン、「モバイルノードとホームのエージェントの間で合図するモバイルIPv6を保護するのにIPsecを使用します」、RFC3776(2004年6月)。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, November 2005.
2005年11月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
8. Informative Reference
8. 有益な参照
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, November 2005.
[RFC4285] パテルとA.とレオンとK.とカリルとM.とAkhtar、H.とK.チョードリ、「モバイルIPv6"、RFC4285、2005年11月のための認証プロトコル。」
Authors' Addresses
作者のアドレス
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Alpeshパテルシスコシステムズ170w.タスマンDriveサンノゼ、カリフォルニア95134米国
Phone: +1 408-853-9580 EMail: alpesh@cisco.com
以下に電話をしてください。 +1 408-853-9580 メールしてください: alpesh@cisco.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
ケントレオン・シスコシステムズ170w.タスマン・Driveカリフォルニア95134サンノゼ(米国)
Phone: +1 408-526-5030 EMail: kleung@cisco.com
以下に電話をしてください。 +1 408-526-5030 メールしてください: kleung@cisco.com
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
モハメドカリルノーテルは2221年の湖畔Blvd.をネットワークでつなぎます。 テキサス75082リチャードソン(米国)
Phone: +1 972-685-0574 EMail: mkhalil@nortel.com
以下に電話をしてください。 +1 972-685-0574 メールしてください: mkhalil@nortel.com
Patel, et al. Standards Track [Page 6] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[6ページ]RFC4283のモバイルノード識別子オプション
Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Haseeb Akhtarノーテルは2221年の湖畔Blvd.をネットワークでつなぎます。 テキサス75082リチャードソン(米国)
Phone: +1 972-684-4732 EMail: haseebak@nortel.com
以下に電話をしてください。 +1 972-684-4732 メールしてください: haseebak@nortel.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
KuntalチョードリStarentネットワーク30の国際Place MA01876テュークスベリー(米国)
Phone: +1 214 550 1416 EMail: kchowdhury@starentnetworks.com
以下に電話をしてください。 +1 1416年の214 550メール: kchowdhury@starentnetworks.com
Patel, et al. Standards Track [Page 7] RFC 4283 Mobile Node Identifier Option for MIPv6 November 2005
パテル、他 MIPv6 November 2005のための標準化過程[7ページ]RFC4283のモバイルノード識別子オプション
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Patel, et al. Standards Track [Page 8]
パテル、他 標準化過程[8ページ]
一覧
スポンサーリンク
