[要約] RFC 4283は、Mobile IPv6（MIPv6）におけるモバイルノード識別子オプションに関する仕様です。このRFCの目的は、MIPv6においてモバイルノードを一意に識別するためのオプションを提供することです。
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)
モバイル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).
Copyright（c）The Internet Society（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）、International Mobile Station Identifier（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]、International Mobile Station 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（認証、承認、および会計）インフラストラクチャを使用した認証と承認または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.
このオプションは、[RFC3775]で指定されているように、Internet Key Exchange（IKE）/IPSECがバインディングの更新または拘束力のある承認を保護するために使用されない場合に使用する必要があります。通常、認証オプション[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].
キーワードは「必要」、「必要」、「必要」、「「shill」」、「suff」、 "not" of "、" becommented "、" 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）を識別できます。2つの例は、ネットワークアクセス識別子（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.
MN-NAIモビリティオプションは、セクション3で定義されているモバイルノード識別子オプションの一般的な形式を使用します。このオプションは、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モビリティオプションは、form 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には、モバイルノードを識別するための1つのメカニズム、ホームアドレスオプション[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で説明されているモバイルノード識別子オプションは、ユーザーの家庭所属を明らかにしているため、攻撃者がユーザーの身元を決定したり、攻撃者が特定の被害者をターゲットにしたり、ユーザー名スペースのさらなる調査を支援するのに役立ちます。
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 IPSECを使用してホームエージェントとの通信を保護する場合など、パケット全体を暗号化します[RFC3776]。
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]と比較して、このドキュメントのプライバシーの脆弱性のウィンドウが減少することに注意する必要があります。さらに、このドキュメントは、動的なホームアドレスを使用できるようにするソリューションの一部です。これはプライバシーの改善でもあり、ホームエージェントと特派員ノードとの通信の両方に影響し、どちらもホームアドレスに伝える必要があります。
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 Patilに感謝したいと思います。セキュリティ上の考慮事項と文書の他のさまざまな側面に関するレビューと提案をしてくれたJari Arkkoに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Johnson、D.、Perkins、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. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、2004年6月、RFC 3776。
[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] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6の認証プロトコル」、RFC 4285、2005年11月。
Authors' Addresses
著者のアドレス
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 US
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 US
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd.テキサス州リチャードソン75082 US
Phone: +1 972-685-0574 EMail: mkhalil@nortel.com Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
電話：1 972-685-0574メール：mkhalil@nortel.com Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd.テキサス州リチャードソン75082 US
Phone: +1 972-684-4732
EMail: haseebak@nortel.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury、MA 01876 US
Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。