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
Mobile Node Identifier Option for Mobile 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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の）は、バインディングの作成および管理に関連するすべてのメッセージにモバイルノード、コレスポンデントノード、及びホーム・エージェントによって使用される新しいモビリティヘッダを定義します。モバイルIPv6ノードは、デフォルトのホームIPアドレス以外のIDを使用して自分自身を識別するための機能が必要です。識別子のいくつかの例は、ネットワークアクセス識別子（NAI）、完全修飾ドメイン名（FQDN）、国際移動局識別子（IMSI）、およびモバイル加入者番号（MSISDN）が含まれます。この文書では、モビリティヘッダを含むメッセージで自分自身を識別するために、モバイルIPv6エンティティによって使用できる新しいモビリティ・オプションを定義します。
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
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アドレスを使用して、モビリティエンティティを識別する。モビリティエンティティが他の識別子（例えば、ネットワークアクセス識別子（NAI）[RFC4282]、国際移動局識別子（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)
既存のAAA（認証、許可、およびアカウンティング）インフラストラクチャまたはHLR / AUC（ホームロケーションレジスタ/認証センター）経由を使用してOの認証および承認
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]で指定された確認応答を結合するために使用されていない場合は、このオプションを使用する必要があります。これは、通常、認証オプション[RFC4285]で使用されています。しかし、このオプションは独立して使用することができます。例えば、識別子は、会計および課金サービスを提供することができます。
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"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります[RFC2119]に記載されているように解釈されます。
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.
モバイルノード識別子オプションは、モビリティヘッダを含むモバイルIPv6定義メッセージで運ばれる新しいオプションのデータフィールドです。識別子の種々の形態は、モバイルノード（MN）を識別するために使用することができます。二つの例は、特定のアプリケーションへのネットワークアクセス識別子（NAI）[RFC4282]及び不透明な識別子は適用可能です。オプションでサブタイプフィールドは、識別子の特定のタイプを定義します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
MN-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:
サブタイプ：
Subtype field defines the specific type of identifier included in the Identifier field.
サブタイプフィールドが識別子フィールドに含まれる識別子の特定のタイプを定義します。
Identifier:
識別：
A variable length identifier of type, as specified by the Subtype field of this option.
このオプションのサブタイプフィールドによって指定されたタイプの可変長識別子。
This option does not have any alignment requirements.
このオプションは、任意のアライメント要件はありません。
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.
セクション3で定義されたこのオプションは、MN-NAI移動性オプションは、モバイルノードを識別するために使用される1のサブタイプ値を使用するようにMN-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.
MN-NAI移動性オプションは、user @ realmの形式[RFC4282]の識別子を使用しています。このオプションでは、この仕様を実装するエンティティによって実装されなければなりません。
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.
次のようにMN識別子オプションの場所は：存在する場合、このオプションは、モビリティヘッダを含むメッセージ内の任意の認証関連のオプションの前に現れなければなりません。
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はすでにモバイルノードを識別するための一つのメカニズムが含まれている、ホームアドレスオプション[RFC3775]。その結果、この文書で定義された新しいオプションの脆弱性は、すでにモバイルIPv6のために存在しているものと同様です。具体的には、永久的な、安定した識別子の使用は、異なる位置を通って移動することができる特定のデバイスまたはユーザを追跡すること、ユーザのプライバシーを侵害することができます。
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節で説明したモバイルノード識別子オプションは、ユーザーの自宅の所属を明らかにしているので、それは、ユーザーのIDを決定する際に、攻撃者を支援する特定の犠牲者をターゲットに攻撃者を助ける、またはさらに、ユーザー名スペースのプロービングするのを助けることができます。
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].
、ホームエージェント[RFC3776]との通信を保護するためにIPsecを使用したときのように、パケット全体を暗号化するO。
o Using an authentication mechanism that enables the use of privacy NAIs [RFC4282] or temporary, changing "pseudonyms" as identifiers.
プライバシーのNAI [RFC4282]または識別子として一時的に、変化する「仮名」の使用を可能にする認証メカニズムを使用して、O。
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]に比べて減少していることに留意すべきです。また、この文書は、動的ホームアドレスを使用できるようにするソリューションの一部です。これは、同様にプライバシーの改善であり、それは、ホームエージェントとホームアドレスを告げする必要があり、どちらも対応ノードとの通信の両方に影響を与えます。
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は、MN-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は、モバイルノード識別子オプションのサブタイプフィールドに新しい名前空間を作成しました。次のように現在割り当てられている値は次のとおりです。
NAI (defined in [RFC4282]).
NAI（[RFC4282]で定義されます）。
New values for this namespace can be allocated using Standards Action [RFC2434].
この名前空間のための新しい値は、標準化アクション[RFC2434]を使用して割り当てることができます。
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に感謝と提案。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[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を使用する"、RFC 3776、2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, November 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年11月。
[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.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、RFC 4285、2005年11月。
Authors' Addresses
著者のアドレス
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Alpeshパテルシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 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
ケント・レオンシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 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
モハメド・カリルNortel Networksの2221レイクサイドブルバードリチャードソン、TX 75082米国
Phone: +1 972-685-0574 EMail: mkhalil@nortel.com
電話：+1 972-685-0574電子メール：mkhalil@nortel.com
Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
ハシーブアクタールNortel Networksの2221レイクサイドブルバードリチャードソン、TX 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チョードリースタレントネットワークス30・インターナショナル・プレイステュークスベリー、マサチューセッツ州01876米国
Phone: +1 214 550 1416 EMail: kchowdhury@starentnetworks.com
電話：+1 214 550 1416 Eメール：kchowdhury@starentnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、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機能のための基金は現在、インターネット協会によって提供されます。