Network Working Group B. Patil
Request for Comments: 5419 Nokia
Category: Informational G. Dommety
Cisco
January 2009
Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
認証データサブオプションは、モバイルIPv6（MIPv6の）ために必要な理由
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments.
モバイルIPv6は、認証とそのホームエージェント（HA）への登録を行うために、モバイルノード（MN）を有効にシグナリングメッセージのセットを定義します。モバイルノードとホームエージェントとの間にこれらの認証シグナリングメッセージは、MNとHAの間で確立されたIPsecセキュリティアソシエーション（SA）によって固定されています。 MIP6ワーキンググループは、MNとHAとの間で交換されるシグナリングメッセージの中で運ばモバイルIPv4における認証オプションと同様の認証オプションを使用して、バインディング更新（BU）及びバインディング確認応答（裏）メッセージを保護するメカニズムを指定しています結合を確立します。この文書では、認証オプション機構は、特定の環境でのモバイルIPv6の展開のために必要とされる理由として正当化を提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Background ......................................................3
4. Applicability Statement .........................................3
5. Justification for the Use of the Authentication Option ..........5
5.1. Motivation for Use of the Authentication Option in
CDMA2000 ...................................................5
5.2. Additional Arguments for the Use of the
Authentication Option ......................................6
6. Application of Mobile IPv6 in CDMA Networks .....................9
6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ......9
6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks .....11
6.2.1. Overview of the Mobility Operation in
IPv6-Based CDMA2000 Networks .......................11
6.2.2. Authentication and Security Details ................12
7. Limitations of the Authentication Protocol Option ..............14
8. Security Considerations ........................................16
9. Conclusion .....................................................16
10. Acknowledgements ..............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
Mobile IPv6 relies on the IPsec Security Association between the Mobile Node (MN) and the Home Agent (HA) for authentication of the MN to its HA before a binding cache can be created at the HA. An alternate mechanism that does not rely on the existence of the IPsec SA between the MN and HA for authenticating the MN is needed in certain deployment environments. Such an alternate mechanism is outlined in [RFC4285]. This document is intended to capture for archival purposes the reasoning behind the need for the authentication protocol [RFC4285]. It should be noted that the alternate solution does not imply that the IPsec-based solution will be deprecated. It simply means that in certain deployment scenarios there is a need for supporting MIPv6 without an IPsec SA between the MN and HA. So the alternate solution is in addition to the IPsec-based mechanism specified in the base RFCs, i.e., [RFC3775], [RFC3776], and [RFC4877]. It has been noted that some of the challenges of deploying MIPv6 in certain types of networks arose from dependence on the Internet Key Exchange (IKE), which did not integrate well with an Authentication, Authorization, and Accounting (AAA) backend infrastructure. IKEv2 solves this problem. However, at the time of discussion on the need for the authentication protocol, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture" [RFC4877] was still a work in progress and, as a result, an alternative solution was needed.
モバイルIPv6は、バインディングキャッシュがHAで作成することができる前に、そのHAへのMNの認証のためにモバイル・ノード（MN）とホームエージェント（HA）間のIPsecセキュリティアソシエーションに依存しています。 MNを認証するためのMNとHA間のIPsec SAの存在に依存しない代替メカニズムは、特定のデプロイメント環境で必要とされます。そのような代替の機構は、[RFC4285]に概説されています。この文書は、アーカイブの目的のために認証プロトコル[RFC4285]の必要性の背後にある理由をキャプチャすることを意図しています。代替ソリューションは、IPsecベースソリューションは廃止されることを意味するものではないことに留意すべきです。これは単に、特定の展開シナリオにMNとHA間のIPsec SAなしのMIPv6をサポートする必要があることを意味します。そう代替ソリューションは、ベースRFCで指定されたIPSecベースのメカニズム、すなわち、[RFC3775]、[RFC3776]及び[RFC4877]に追加されます。ネットワークの特定の種類でのMIPv6を展開する課題のいくつかは、認証、認可、アカウンティング（AAA）バックエンドのインフラとうまく統合されませんでした、インターネットキー交換（IKE）、への依存から生じたことが指摘されています。 IKEv2のは、この問題を解決します。しかし、認証プロトコルの必要性について議論する時に、[RFC4877]「のIKEv2および改訂のIPsecアーキテクチャとのモバイルIPv6の操作は、」結果として、代替ソリューションが必要であった、まだ進行中の作業でした。
It should be noted that some of the arguments for justifying the specification of the authentication protocol have been made redundant as a result of the specification of Mobile IPv6 operation with IKEv2 [RFC4877]. However, some of the arguments discussed in this document are still applicable and justify usage of the authentication protocol in certain deployment environments.
認証プロトコルの仕様を正当化するための引数のうちのいくつかはのIKEv2 [RFC4877]とモバイルIPv6動作の仕様の結果として、冗長化されていることに留意すべきです。しかし、この文書で説明した引数のいくつかは、まだ適用可能であり、特定のデプロイメント環境での認証プロトコルの使用を正当化します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Mobile IPv6 signaling involves several messages. These include:
モバイルIPv6シグナリングは、いくつかのメッセージが含まれます。これらは、次のとおりです。
o The Binding Update/Binding Acknowledgment between the mobile node and the home agent.
モバイルノードとホームエージェントとの間の結合を更新/バインド謝辞O。
o The route optimization signaling messages, which include the HoTI-HoT (Home Test Init/Home Test), CoTI-CoT (Care-of Test Init/ Care-of Test), and BU-BAck messages between the MN and CN. HoTI and HoT signaling messages are routed through the MN's HA.
OのHoTIホット（ホーム試験開始/ホーム試験）を含むメッセージを、シグナリング経路最適化、MNとCNの間のCoTI-のCoT（テスト気付の初期/テスト気付）、及びBUバックメッセージ。 HoTIとホットシグナリングメッセージは、MNのHAを介してルーティングされます。
o Mobile prefix solicitation and advertisements between the MN and HA.
Oモバイルプレフィックス要請とMNとHA間の広告。
o Home agent discovery by MNs.
MNによるOホームエージェント発見。
The signaling messages between the MN and HA are secured using the IPsec SA that is established between these entities. The exception to this are the messages involved in the home agent discovery process. [RFC4877] specifies the establishment of the IPsec SA using IKEv2.
MNとHA間のシグナリングメッセージは、これらのエンティティ間で確立されたIPsec SAを使用して固定されています。この例外は、ホームエージェント発見プロセスに関与するメッセージです。 [RFC4877]はのIKEv2を使用したIPsec SAの確立を指定します。
The authentication option specified in "Authentication Protocol for MIPv6" [RFC4285] provides a solution for MIPv6 deployment in environments in which an operator may not require IPsec-based security for the signaling. The reasons for an operator choosing to deploy MIPv6 without mandating IPsec-based security for signaling messages between the MN and HA could be many. Some of these are, for example:
「MIPv6のための認証プロトコル」[RFC4285]で指定された認証オプションは、オペレータがシグナリングのためのIPsecベースのセキュリティを必要としない可能性のある環境でのMIPv6の展開のためのソリューションを提供します。 MNとHAの間のシグナリングメッセージにIPsecベースのセキュリティを義務付けることなく、MIPv6のを展開することを選択オペレータの理由は、多くの可能性があります。これらのいくつかは、たとえば、以下のとおりです。
1. Operators deploying MIPv6 in cellular networks may consider IPsec and IKEv2 as adding overhead to the limited bandwidth over the air interface. The overhead here is in terms of the bytes that IPsec and IKEv2 introduce to the signaling.
セルラーネットワークでのMIPv6を展開1演算子は、エアインタフェースを介して制限された帯域幅にオーバーヘッドを追加するようにIPsecとのIKEv2を考慮することができます。ここでのオーバーヘッドは、IPsecとのIKEv2シグナリングに紹介するバイト単位です。
2. Operators may consider the number of messages between the MN and HA that are required to establish the IPsec SA as too many. The number of transactions chew into the capacity of limited bandwidth air interfaces when MIPv6 is used in such environments. It also adds additional latency to the establishment of the binding.
2.事業者は、あまりにも多くのようにIPsec SAを確立するのに必要とされるMNとHA間のメッセージの数を考慮することができます。 MIPv6のこのような環境で使用される場合、トランザクションの数が制限された帯域幅エアインターフェースの容量にかみます。また、結合の確立に追加の遅延を追加します。
3. In many deployments, authentication credentials already exist in a AAA server. These credentials are used for authenticating a user and authorizing network access. The same credentials and security parameters cannot be reused for MIPv6 security as well, if IKEv1 is used.
多くの配備で、[認証証明書は、すでにAAAサーバに存在します。これらの資格情報は、ユーザーを認証し、ネットワークへのアクセスを許可するために使用されています。 IKEv1のが使用されている場合には、同じ資格情報とセキュリティパラメータは、同様のMIPv6セキュリティのために再利用することはできません。
4. Dynamic assignment of home agents is needed in certain deployments to minimize the latency of the backhaul. This is done by allocating an HA in a visited network, for example. Requiring IPsec SAs with home agents that are dynamically assigned is an overhead, especially when the HA is in a visited network.
ホームエージェントの4動的な割り当ては、バックホールの遅延を最小限に抑えるために、特定の展開に必要とされています。これは、例えば、訪問先ネットワーク内のHAを割り当てることによって行われます。動的に割り当てられているホームエージェントとのIPsec SAを要求することはHAが訪問先ネットワークにある場合は特に、オーバーヘッドです。
5. In certain deployments, signaling messages between the MN and HA may be over secure link layers. The lower layers provide ciphering and security for the messages, and hence the need for IPsec to do the same for MIPv6 messages does not exist.
5.特定の展開では、MNとHAとの間のシグナリングメッセージは、セキュアリンク層の上であってもよいです。下位層は、メッセージのための暗号化とセキュリティを提供し、ひいてはIPsecがMIPv6のメッセージのために同じことをすることの必要性は存在しません。
One example of networks that have such characteristics are Code Division Multiple Access (CDMA) networks as defined in the 3GPP2 [3GPP2 X.S0011-002-D] specification. Mobile WiMAX (Worldwide Interoperability for Microwave Access), which is based on IEEE 802.16e, also specifies in the network architecture the use of MIPv6, with the default security for signaling being the authentication protocol [RFC4285]. The WiMAX network architecture specifications are available at [WiMAX-NWG].
3GPP2 [3GPP2 X.S0011-002-D]仕様で定義されたような特性を有するネットワークの一例は、符号分割多元接続（CDMA）ネットワークです。 IEEE802.16e基づいているモバイルWiMAX（マイクロ波アクセスのための世界的相互運用性）、また、認証プロトコル[RFC4285]であるシグナリングのためのデフォルトのセキュリティと、ネットワークアーキテクチャ内のMIPv6の使用を指定します。 WiMAXネットワークアーキテクチャ仕様は[のWiMAX-NWG]で入手可能です。
The following two sections provide the reasoning for why the authentication option-based registration process for Mobile IPv6 is needed. Section 5.1 provides key arguments for the use of the authentication option. Section 5.2 provides further explanation and additional motivations for the authentication option.
次の2つのセクションでは、モバイルIPv6の認証オプションベースの登録プロセスが必要な理由のための推論を提供しています。 5.1節では、認証オプションを使用するための重要な引数を提供します。 5.2節では、認証オプションの詳しい説明や追加の動機を提供します。
5.1. Motivation for Use of the Authentication Option in CDMA2000 Wireless Networks
5.1. CDMA2000無線ネットワークにおける認証オプションを使用するための動機
CDMA2000 networks deployed and operational today use Mobile IPv4 for IP mobility. Operators have gained a significant amount of operational experience in the process of deploying and operating these networks. 3GPP2 has specified Mobile IPv6 operation in the [3GPP2 X.S0011-002-D] specification. The following are the deployment constraints that existing CDMA networks have to deal with when deploying mobility service based on IPv6:
今日の展開と運用CDMA2000ネットワークは、IPモビリティのためのモバイルIPv4を使用します。事業者は、これらのネットワークを展開し、操作する過程で運用経験、かなりの量を得ています。 3GPP2は、[3GPP2 X.S0011-002-D]明細書にモバイルIPv6動作を指定しています。以下は、既存のCDMAネットワークがIPv6に基づいたモビリティ・サービスを展開する際に対処する必要があります展開制約であります：
o Operators intend to leverage the Mobile IPv4 deployment and operational experience by ensuring that Mobile IPv6 has a similar deployment and operating model.
O演算子は、モバイルIPv6は、同様の展開と事業モデルを持っていることを確実にすることによって、モバイルIPv4の展開と運用経験を活用していきます。
o Operators will have two parallel networks: one that offers IPv4 mobility with MIPv4 and another providing IPv6 mobility using MIPv6.
MIPv4とMIPv6のを使用して別の提供のIPv6モビリティでのIPv4モビリティを提供しています1：O演算子は、2つの平行なネットワークを持っています。
o The same backend subscriber profile database, security keys, etc. are intended to be used for both Mobile IPv4 and Mobile IPv6 service. However, from a security standpoint, the reuse of the same keys with multiple algorithms/protocols is a bad idea.
同じバックエンド加入者プロファイルデータベースOなどセキュリティキーは、モバイルIPv4とモバイルIPv6サービスの両方のために使用されることが意図されます。しかし、セキュリティの観点から、複数のアルゴリズム/プロトコルと同じキーの再利用は悪い考えです。
o The same user-configuration information, i.e., the identity and keys associated with a user, will be used for IP mobility service in IPv4 and/or IPv6 networks. The only security association that is preconfigured is a shared secret between the mobile node and the home AAA server. This is in contrast with an earlier version of the Mobile IPv6 model, which required an IPsec SA between the MN and HA. At the time of this writing, the IKEv2-based solution for establishing an IPsec SA [RFC4877] was not available. IKEv2 does enable integration with a AAA backend.
同じユーザ設定情報O、すなわち、ユーザに関連付けられたアイデンティティ及びキーは、IPv4および/またはIPv6ネットワークでIPモビリティサービスのために使用されます。事前に設定された唯一のセキュリティアソシエーションは、モバイルノードとホームAAAサーバの間の共有秘密です。これは、MNとHA間のIPsec SAを必要とモバイルIPv6モデル、以前のバージョンとは対照的です。この記事の執筆時点では、IPsecのSA [RFC4877]を確立するためのIKEv2ベースのソリューションでは利用できませんでした。 IKEv2のは、AAAのバックエンドとの統合を可能にしません。
o At the time of specifying the authentication protocol, the Mobile IPv6 specification did not support the dynamic assignment of home agent and home address. However, work done in the MIP6 working group on bootstrapping of Mobile IPv6 as specified in [RFC5026] and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT] addresses this deficiency. The mechanism defined in
O認証プロトコルを指定する時には、モバイルIPv6の仕様では、ホームエージェントとホームアドレスの動的な割り当てをサポートしていませんでした。ただし、[RFC5026]で指定されたモバイルIPv6のブートストラップのMIP6ワーキンググループで行われた作業と「統合シナリオのためのMIPv6-ブートストラップ」[BOOT]はこの欠陥に対処しています。で定義されたメカニズム
"Authentication Protocol for Mobile IPv6" [RFC4285] is capable of handling authentication even in the case of dynamic assignments (and is similar to what is used in current MIPv4 deployments).
「モバイルIPv6のための認証プロトコル」[RFC4285]はあっても、動的割り当ての場合に認証を処理することが可能である（そして現在のMIPv4の展開で使用されるものと同様です）。
Consequently, MIPv6 as specified at the time the authentication protocol was being specified, did not satisfy many of the deployment requirements. "Authentication Protocol for MIPv6" [RFC4285] along with "MN Identifier Option for MIPv6" [RFC4283] are enabling the deployment of Mobile IPv6 in a manner that is similar to what is deployed in CDMA2000 networks today. This authentication model is very similar to the one adopted by the MIP4 WG. This is explained in detail in [3GPP2 X.S0011-002-D].
その結果、MIPv6の認証プロトコルが指定されていた時刻に指定されているように、展開要件の多くを満足するものではなかったです。 「MIPv6のためのMN識別子オプション」と共に「MIPv6のための認証プロトコル」[RFC4285]、[RFC4283]は今日CDMA2000ネットワークに配備されているものと同様な方法でモバイルIPv6の導入を可能にしています。この認証モデルは、MIP4 WGによって採用されたものと非常に似ています。これは、[3GPP2 X.S0011-002-D]に詳細に説明します。
The earlier MIPv6 deployment model, which requires an IPsec SA that is either configured manually or established using IKE, does not have synergy with the deployment models of 3GPP2 or WiMAX networks. This issue has however been alleviated with the publication of RFC 4877, which enables the establishment of an IPsec SA using IKEv2 and which is also able to integrate with the backend AAA infrastructure that is responsible for the authentication of the MN in 3GPP2 and WiMAX networks.
IKEを使用して手動で設定または確立されているいずれかのIPsec SAを必要とする以前のMIPv6の展開モデルは、3GPP2又はWiMAXのネットワークの配置モデルとの相乗効果を有していません。これ問題はしかし、IKEv2のを使用したIPsec SAの確立を可能にし、また、3GPP2やWiMAXのネットワークにおけるMNの認証を担当してバックエンドのAAAインフラストラクチャと統合することが可能であるRFC 4877の公表、と軽減されました。
The use of IPsec for performing Registration with a home agent is not always an optimal solution. While it is true that IPsec is viewed as an integral part of the IPv6 stack, it is still a considerable overhead from a deployment perspective of using IPsec as the security mechanism for the signaling messages between the MN and HA. This statement is a result of experience gained from deployment of Mobile IPv4. MIPv4 does not rely on IPsec for securing the Registration signaling messages.
ホームエージェントに登録を実行するためにIPsecを使用することは、常に最適なソリューションではありません。それはIPsecがIPv6スタックの不可欠な部分として見られることは事実であるが、それはまだMNとHAの間のシグナリングメッセージのセキュリティメカニズムとしてIPsecを使用しての展開の観点からかなりのオーバーヘッドです。この文は、モバイルIPv4の展開から得た経験の結果です。 MIPv4のは、シグナリングメッセージ登録を確保するためにIPsecに依存しません。
Deployment of Mobile IPv6 on a large scale is possible only when the protocol is flexible for being adapted to various scenarios. The scenario being considered is the deployment in CDMA2000 networks or WiMAX networks. CDMA2000 networks are currently deployed in many countries today. WiMAX deployments in many countries began in 2008. The packet data network architecture of CDMA2000 [3GPP2 X.S0011-002-D] includes a MIPv4 foreign agent/home agent and a RADIUS-based AAA infrastructure for Authentication, Authorization, and Accounting purposes. The AAA infrastructure provides authentication capability in the case of Mobile IPv4.
大規模モバイルIPv6の導入は、プロトコルは、様々なシナリオに適合されているため、可撓性である場合にのみ可能です。検討されているシナリオは、CDMA2000ネットワークやWiMAXのネットワークでの展開です。 CDMA2000ネットワークは現在、今日の多くの国で展開されています。多くの国でのWiMAXの展開は、2008年に始まったCDMA2000のパケットデータネットワークアーキテクチャ[3GPP2 X.S0011-002-D]は、認証、認可、アカウンティングの目的のためのMIPv4フォーリンエージェント/ホームエージェントとRADIUSベースのAAAインフラストラクチャを含んでいます。 AAAインフラは、モバイルIPv4の場合に認証機能を提供します。
Typically, the mobile node shares a security association with the AAA-Home entity. This is the preferred mode of operation over having a shared secret between the MN and HA because the AAA-Home entity provides a central location for provisioning and administering the shared secrets for a large number of mobiles (millions). This mode of operation also makes dynamic home address and dynamic home agent assignment easier. A similar approach is needed for the deployment of Mobile IPv6 in these networks. There is no practical mechanism to use IPsec directly with the AAA infrastructure without the use of IKEv2 or some other mechanism that enables the establishment of the IPsec SA between the MN and HA.
一般的に、モバイルノードは、AAA-ホームエンティティとセキュリティアソシエーションを共有しています。これは、AAA-ホームエンティティは移動体（数百万）の多数の共有秘密をプロビジョニングおよび管理するための中央の場所を提供するため、MNとHAの間の共有秘密を有する上好ましい動作モードです。この動作モードは、動的ホームアドレスと動的ホームエージェントの割り当てが容易になります。同様のアプローチは、これらのネットワークにおけるモバイルIPv6の展開のために必要とされます。 IKEv2のまたはMNとHA間のIPsec SAの確立を可能にするいくつかの他のメカニズムを使用することなく、AAAインフラストラクチャと直接IPsecを使用する実用的なメカニズムは存在しません。
Mobile IPv6 as specified in [RFC3775] and [RFC3776] is based on a very specific model for deployment. It anticipates the mobile node's having a static home IPv6 address and a designated home agent. This is not practical in most deployment scenarios being considered. An IPsec SA is expected to be created via manual keying or established dynamically via IKE or IKEv2. These assumptions do not necessarily fit in very well for the deployment model envisioned in CDMA2000 or WiMAX networks. These limitations have however been overcome as a result of the bootstrapping specifications as per [RFC5026] and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT].
[RFC3775]と[RFC3776]で指定されるように、モバイルIPv6は、展開のための非常に特異的なモデルに基づいています。これは、モバイルノードの持つ静的自宅のIPv6アドレスと指定されたホームエージェントを見込んでいます。これは検討されているほとんどの展開シナリオで実用的ではありません。 IPsecのSAは手動キー入力を介して作成またはIKEやIKEv2を経て動的に確立されることが期待されます。これらの仮定は必ずしもCDMA2000やWiMAXのネットワークで想定される展開モデルのために非常によくでは適合しません。これらの制限は、しかし、[RFC5026]と「統合シナリオのためのMIPv6-ブートストラップ」[BOOT]あたりとしてブートストラップ仕様の結果として、克服されました。
CDMA2000 and WiMAX networks would prefer to allocate home addresses to MNs on a dynamic basis. The advantage of doing so is the fact that the HA can be assigned on a link that is close to the MN's point of attachment. While route optimization negates the benefit of having a home agent on a link close to the MN, it cannot always be guaranteed that the MN and correspondent node (CN) will use or support route optimization. There may also be instances where the operator prefers to not allow route optimization for various reasons, such as accounting aggregation or enforcing service contracts. In such cases, an HA that is close to the MN's point of attachment reduces the issues of latency, etc. of forward and reverse tunnelling of packets between the MN and HA.
CDMA2000とWiMAXネットワークを動的にするMNにホームアドレスを割り当てることを好むだろう。そうすることの利点は、HAは、添付ファイルのMNの視点に近いリンクに割り当てることができるという事実です。ルート最適化が近いMNへのリンクをホームエージェントを持つことの利点を否定するが、常にMNとコレスポンデントノード（CN）は、ルート最適化を使用するか、サポートすることを保証することはできません。また、オペレータは、このような会計上の凝集やサービス契約を強制するなど、さまざまな理由でルート最適化を許可しないことを好むのインスタンスがあるかもしれません。このような場合には、アタッチメントのMNの点に近接していHA等前方の待ち時間の問題を低減し、MNとHA間のパケットのトンネリングを逆。
CDMA2000 networks that are operational today have large numbers of subscribers who are authenticated via the AAA infrastructure. Deployment of Mobile IPv6 should leverage the existing AAA infrastructure. The security model needed in these networks is an SA between the MN and AAA-Home entity. This is the primary security association that should be used for authenticating and authorizing users to utilize MIPv6 service. This SA is then used for establishing session keys between the MN and the dynamically assigned HA for authenticating subsequent Binding Updates and Binding Acknowledgements between them. Establishing an IPsec SA between the MN and HA using AAA infrastructure was not specified for Mobile IPv6 at the time the authentication protocol was being specified. RFC 3776 explains how IKE is used for establishing the SA between the MN and HA. [RFC4877] has been published subsequently and hence the issue of establishing an IPsec SA dynamically between the MN and HA no longer exists. CDMA2000 network operators would prefer to assign home addresses to the MN on a dynamic basis -- preferably using the AAA infrastructure, which contains subscriber profile and capability information. This was not possible prior to the specification of the bootstrapping mechanism in [RFC5026].
今日動作しているCDMA2000ネットワークは、AAAインフラストラクチャを介して認証されている加入者の数が多いです。モバイルIPv6の導入は、既存のAAAインフラストラクチャを活用すべきです。これらのネットワークに必要なセキュリティモデルは、MNとAAA-ホームエンティティ間のSAです。これは、MIPv6のサービスを利用するユーザーを認証し、認証するために使用されるべき主要なセキュリティアソシエーションです。このSAは、後続のバインディングアップデートを認証し、それらの間の謝辞を結合するためのMNと動的に割り当てられたHAの間のセッション鍵を確立するために使用されます。 AAAインフラストラクチャを使用して、MNとHAとの間の確立のIPsec SAは、認証プロトコルが指定された時点で、モバイルIPv6のために指定されませんでした。 RFC 3776は、IKEはMNとHAの間でSAを確立するために使用される方法を説明します。 [RFC4877]は、動的MNとHA間のIPsec SAを確立する問題はもう存在し、その後、したがって、公表されていません。 CDMA2000ネットワークオペレータは、動的にMNにホームアドレスを割り当てることを好むだろう - 好ましくは加入者プロファイルや能力情報が含まれているAAAインフラストラクチャを使用して。これは、従来[RFC5026]におけるブートストラップ機構の指定することはできませんでした。
A large subset of MNs in CDMA2000 networks do not have IKE capability. As a result, the use of RFC 3776 for setting up the MN-HA IPsec SA is not an option. It should also be noted that IKE requires several transactions before it is able to establish the IPsec SA. [RFC4877] specifies the establishment of an IPsec SA between the MN and HA using IKEv2. It is possible that not all MNs in a deployment will support IKEv2, and hence an alternative mechanism provides the needed flexibility.
CDMA2000ネットワーク内のMNの大規模なサブセットはIKE機能を持っていません。その結果、MN-HAのIPsec SAを設定するためのRFC 3776の使用はオプションではありません。またのIPsec SAを確立することができる前に、IKEは複数のトランザクションを必要とすることに留意すべきです。 [RFC4877]はのIKEv2を使用MNとHA間のIPsec SAの確立を指定します。展開内のすべてのMNは、IKEv2のをサポートします、したがって、代替メカニズムが必要な柔軟性を提供しないことも可能です。
CDMA2000 network operators are extremely conscious in terms of the number of messages sent and received over the air interface for signaling. The overhead associated with sending/receiving a large number of signaling messages over the air interface has a direct impact on the overall capacity and cost for the operator. Optimization of the number of messages needed for using a service like Mobile IPv6 is of great concern. As a result, the use of IKE for Mobile IPv6 deployment is considered as being suboptimal in certain network architectures and deployment scenarios from the perspective of message overhead.
CDMA2000ネットワークオペレータは、シグナリングのためのエアインタフェースを介して送信し、受信したメッセージの数の点で非常に意識しています。エアインタフェースを介してシグナリングメッセージを大量に受信/送信に関連するオーバーヘッドは、オペレータのための全体的な能力とコストに直接影響します。モバイルIPv6のようなサービスを利用するために必要なメッセージの数の最適化は大きな懸念です。結果として、モバイルIPv6の導入のためのIKEの使用は、メッセージオーバーヘッドの観点から特定のネットワークアーキテクチャおよび展開シナリオに準最適であると考えられます。
Another downside of IKE for setting up the IPsec SA between the MN and HA is that IKE does not integrate very well with the RADIUS-based AAA backend. Since operators rely on the AAA infrastructure to provision subscribers as well as define profiles, keys, etc. in the AAA-Home, there is no getting away from the use of AAA in CDMA2000 networks. IKEv2 does address this problem. However, from a timeline perspective, the availability of IKEv2 specifications for "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture" [RFC4877] and its implementations did not meet the need of operators that were relying on 3GPP2 specifications. With the specification of IKEv2 and publication of RFC 4877, integration with AAA backends is no longer an issue.
MNとHA間のIPsec SAを設定するためのIKEのもう一つの欠点は、IKEは、RADIUSベースのAAAのバックエンドと非常によく統合されないということです。事業者が提供する加入者にAAAインフラストラクチャに依存しているだけでなく、AAA-ホームでなどのプロファイル、キーを定義しているので、何も離れCDMA2000ネットワークにおけるAAAの使用から取得はありません。 IKEv2のは、この問題に対処しません。しかし、タイムラインの観点から、「モバイルIPv6のIKEv2および改訂されたIPsecのアーキテクチャと運用」[RFC4877]とその実装のためのIKEv2仕様の可用性は、3GPP2仕様に頼っていた事業者のニーズを満たしていませんでした。 IKEv2の仕様とRFC 4877の出版では、AAAのバックエンドとの統合は、もはや問題ではありません。
In summary, the model of Mobile IPv6 deployment that mandated the existence of an IPsec SA between the MN and HA, as specified in RFCs 3775 and 3776, was too rigid and did not meet the requirements of operators building networks based on the CDMA2000 [3GPP2 X.S0011-002-D] specifications. To address this shortcoming, the authentication protocol [RFC4285] was specified.
要約すると、MNとHA間のIPsec SAが存在することを義務付けモバイルIPv6展開のモデルは、RFCの3775および3776に指定されている、硬すぎたとCDMA2000に基づく事業者のネットワーク構築の要件を満たしていませんでした[3GPP2 X.S0011-002-D]の仕様。この欠点に対処するために、認証プロトコル[RFC4285]は指定されました。
Sections 6.1 and 6.2 describe the IPv4- and IPv6-based mobility architectures in CDMA networks, respectively. For further details associated with the description below, please refer to Section 5, "MIP6 Operation", in the 3GPP2 specification [3GPP2 X.S0011-002-D].
セクション6.1および6.2は、それぞれ、CDMAネットワークにIPv4-およびIPv6ベースのモビリティアーキテクチャについて説明します。以下の説明に関連するさらなる詳細は、3GPP2仕様[3GPP2 X.S0011-002-D]において、第5章、「MIP6操作」を参照してください。
The figure below shows a high level view of the key network elements that play a role in providing IP mobility using Mobile IPv4.
以下の図は、モバイルIPv4を使用してIPモビリティを提供する役割を果たしている重要なネットワーク要素の高レベルの図を示しています。
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAAH| |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /FA | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 1: CDMA2000 Packet Data Network Architecture with Mobile IPv4
図1：モバイルIPv4とCDMA2000パケットデータネットワークアーキテクチャ
The CDMA mobility architecture based on MIPv4 is explained below. In this architecture, mobility is tightly integrated with the AAA infrastructure. The Mobile Node is configured with an NAI (Network Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key that is shared between the MN and the home AAA server.
MIPv4のに基づくCDMAモビリティアーキテクチャについて説明します。このアーキテクチャでは、移動度がしっかりAAAインフラストラクチャと統合されています。モバイルノードはNAI（ネットワークアクセス識別子）とMN-AAAキーで構成されています。 MN-AAAキーは、MNとホームAAAサーバの間で共有される共有鍵です。
Below is the access link setup procedure:
以下は、アクセスリンク設定手順は以下のとおりです。
(1) Bring up the PPP on the MN/PDSN (access router link). PPP authentication is skipped. Mobile IP authentication is performed via the FA (Foreign Agent).
（1）MN / PDSN（アクセスルータリンク）上でPPPを起動します。 PPP認証はスキップされます。モバイルIP認証はFA（外部エージェント）を介して行われます。
(2) The PDSN (Packet Data Serving Node) sends a Mobile IP challenge to the MN on the PPP link (RFC 3012).
（2）PDSN（パケットデータサービングノード）PPPリンク（RFC 3012）上のMNにモバイルIPチャレンジを送信します。
(3) The MN sends a MIP Registration Request (RRQ), which includes the user's NAI, challenge, and MN-AAA extension that has a challenge response, and an MN-HA extension, which is generated based on the MN-HA key.
（3）MNは、MN-HAキーに基づいて生成されたユーザのNAI、チャレンジ、およびチャレンジ応答を有するMN-AAA拡張、およびMN-HAの拡張を含むMIP登録要求（RRQ）を送信します。
(4) The PDSN extracts the MIP NAI, challenge, and the response to the challenge, from the MIP MN-AAA extension, and sends an Access Request to the F-AAA (challenge/response using MD5).
（4）PDSNはMIP MN-AAA拡張から、MIP NAI、チャレンジ、およびチャレンジに対する応答を抽出し、F-AAA（MD5を使用して、チャレンジ/レスポンス）にアクセス要求を送信します。
(5) The F-AAA (Foreign AAA) may forward it to the H-AAA (Home AAA) if needed (based on realm).
必要に応じて（5）F-AAA（外国AAA）を（領域に基づいて）H-AAA（ホームAAA）にそれを転送することができます。
(6) AAA authenticates the CHAP-challenge/response and returns "success" if authentication succeeds.
（6）AAAは、CHAPチャレンジ/レスポンスを認証し、認証が成功した場合、「成功」を返します。
(7) The PDSN forwards the Registration Request (RRQ) to the HA.
（7）PDSNはHAに登録要求（RRQ）を転送します。
(8) The HA authenticates the RRQ (MHAE (Mobile-Home Authentication Extension)). The HA may optionally authenticate with the AAA infrastructure (just like the PDSN in #4).
（8）HAはRRQ（MHAE（モバイルホーム認証拡張））を認証します。 HAは、任意に（ちょうど＃4 PDSN等）AAAインフラストラクチャを使用して認証することができます。
(9) If authentication is successful, the HA creates a binding and sends a success Registration Reply (RRP) to the PDSN.
認証が成功した場合は（9）、HAは、バインディングを作成し、PDSNに成功登録応答（RRP）を送信します。
(10) The PDSN creates a visitor entry and forwards the RRP to the MN.
（10）PDSNは、ビジターエントリを作成し、MNにRRPを転送します。
Due to the need for co-existence with MIPv4, and having the same operational model, the 3GPP2 standards body is adopting the following mobility architecture for MIPv6.
ためのMIPv4との共存の必要性、および同じ運用モデルを有することに、3GPP2標準化団体は、MIPv6のための以下のモビリティ・アーキテクチャを採用しています。
Access Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAA | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /AR | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 2: CDMA2000 Packet Data Network Architecture with Mobile IPv6
図2：モバイルIPv6とCDMA2000パケットデータネットワークアーキテクチャ
The Mobile Node is configured with an NAI (Network Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key between the MN and the home AAA server.
モバイルノードはNAI（ネットワークアクセス識別子）とMN-AAAキーで構成されています。 MN-AAAキーは、MNとホームAAAサーバ間の共有キーです。
6.2.1. Overview of the Mobility Operation in IPv6-Based CDMA2000 Networks
6.2.1. IPv6ベースのCDMA2000ネットワークにおけるモビリティの動作の概要
The following steps explain at a very generic level the operation of IP mobility in CDMA2000 networks:
次の手順は非常に一般的なレベルでのCDMA2000ネットワークにおけるIPモビリティの動作を説明します：
(1) The MN performs link-layer establishment. This includes setting up the PPP link. PPP-CHAP authentication is performed. This is authenticated by the PDSN/AR (Access Router) by sending an Access Request to the F-AAA (and to the H-AAA when/if needed). Optionally, the MN acquires bootstrap information from the Home Network (via the PDSN; the PDSN receives this information in Access Accept). The bootstrap information includes home address and home agent assignment. The MN uses stateless DHCPv6 [RFC3736] to obtain the bootstrap information from the PDSN.
（1）MNは、リンク層の確立を行います。これは、PPPリンクを設定する含まれています。 PPP-CHAP認証が行われます。これは、（必要に応じて場合/及びH-AAAへ）F-AAAへアクセス要求を送信することによってPDSN / AR（アクセスルータ）によって認証されています。必要に応じて、MNは、（PDSNを経由して、PDSNは受け入れAccessで、この情報を受けた）ホームネットワークからのブートストラップ情報を取得します。ブートストラップ情報は、ホームアドレスとホームエージェントの割り当てが含まれています。 MNはPDSNからブートストラップ情報を取得するためにステートレスDHCPv6の[RFC3736]を使用します。
(2) The MN begins to use the home address (HoA) that was assigned in step 1. If no HoA was assigned at step 1, the MN generates (auto-configures) an IPv6 global unicast address based on the prefix information received at step 1.
（2）MN無しのHoAがステップ1で割り当てられなかった場合は、ステップ1で割り当てられたホームアドレス（HoA）を使用し始め、MNは、（自動設定）で受信されたプレフィックス情報に基づいて、IPv6グローバルユニキャストアドレスを生成しますステップ1。
(3) The MN sends a Binding Update to the selected home agent. In the BU, the MN includes the NAI option, timestamp option, and MN-AAA auth option.
（3）MNは、選択したホームエージェントにバインディングアップデートを送信します。 BUでは、MNは、NAIオプション、タイムスタンプオプション、およびMN-AAAの認証オプションが含まれています。
(4) The HA extracts the NAI, authenticator, etc. from the BU and sends an Access Request to the Home RADIUS server.
（4）HAは、BUからNAI、オーセンティケータ、などを抽出し、ホームRADIUSサーバにアクセス要求を送信します。
(5) The Home RADIUS server authenticates and authorizes the user and sends back a RADIUS Access Accept to the HA indicating successful authentication and authorization.
（5）ホームRADIUSサーバが認証し、ユーザーを認証し、RADIUSアクセスが成功した認証と認可を示すHAに受け入れて送り返します。
(6) The HA performs a replay check with the ID field in the received BU. The HA also performs proxy Duplicate Address Detection (DAD) on the MN's home address (global) using proxy Neighbor Solicitation as specified in [RFC4861].
（6）HAは、受信したBUのIDフィールドと再生チェックを行います。 HAはまた、[RFC4861]で指定されたプロキシ近隣要請を使用して（グローバル）MNのホームアドレスにプロキシ重複アドレス検出（DAD）を行います。
(7) Assuming that proxy DAD is successful, the HA sends back a Binding Acknowledgment to the MN. In this BAck message, the HA includes the MN-HA mobility option, NAI mobility option, and ID mobility option.
（7）は、プロキシDADが成功したと仮定すると、HAは、MNに結合肯定応答を送り返します。このバックメッセージでは、HAは、MN-HAのモビリティオプション、NAI移動性オプション、およびIDのモビリティオプションが含まれています。
Access Link Setup, Access Authentication, and Bootstrapping:
アクセスリンクの設定、アクセス認証、およびブートストラップ：
(1) The MN brings up a PPP session. The PDSN triggers the MN to perform CHAP authentication, as part of access authentication, while bringing up the PPP link.
（1）MNは、PPPセッションが表示されます。 PDSNは、PPPリンクを立ち上げる一方で、アクセス認証の一部として、CHAP認証を実行するためにMNをトリガします。
(2) The MN is authenticated using the PPP-CHAP by the H-AAA (Home AAA), via the F-AAA (Foreign AAA).
（2）MNは、F-AAA（外国AAA）を介して、H-AAA（ホームAAA）によってPPP-CHAPを使用して認証されます。
(3) The H-AAA may optionally send the HoA and HA IP address to the PDSN for bootstrapping the MN (skipping details).
（3）H-AAAは、必要に応じて（詳細はスキップ）MNをブートストラップするためのPDSNにHoAとHA IPアドレスを送信することができます。
Mobile IPv6 Authentication:
モバイルIPv6認証：
The call flow for the initial authentication (the numbers in the parentheses correspond to the explanation below):
初期認証のためのコールフロー（括弧内の数字は、以下の説明に対応します）：
MN HA H-AAA
| BU to HA (4) | RADIUS Access-ReQ(5)
|------------------------------------>|------------------->|(6)
| (includes NAI option, MN-ID option, | |
| Mesg ID option, MN-AAA auth option) |RADIUS Access Accept|(7)
|
|<-------------------|
| | |
| HA/AAAH authenticates MN
|
| |(8)
|
| |
|
| BAck to MN (9) |
|
|<------------------------------------|--------------------|
| (including MN-ID option, | (10)
| Message ID option, |
| MN-HA auth options) | |
Figure 3: Flow Diagram for Initial Authentication
図3：フローダイアグラム初期認証のために
(4) The MN sends a Binding Update (BU) to the HA. The Binding Update is authenticated using the MN-AAA option. The authenticator in the MN-AAA option is calculated using the hash of the BU and MN-AAA shared key. It uses the HMAC_SHA1 algorithm. The Security Parameter Index (SPI) field in MN-AAA is set to 3 (as per [RFC4285]). The BU also includes the NAI and timestamp, among other details. The hash of the BU includes the 'timestamp' option and thus provides proof of liveness to prevent replay.
（4）MNは、HAにバインディング更新（BU）を送信します。バインディング更新はMN-AAAオプションを使用して認証されます。 MN-AAAオプションでオーセンティケータは、BUのハッシュを使用して計算し、MN-AAAは、キーを共有しています。これは、HMAC_SHA1アルゴリズムを使用しています。 MN-AAAのセキュリティパラメータインデックス（SPI）フィールドは、（[RFC4285]に従って）3に設定されています。 BUはまた、その他の詳細の中で、NAIおよびタイムスタンプを含みます。 BUのハッシュは、「タイムスタンプ」オプションを含み、したがって、リプレイを防止するための生存性の証拠を提供します。
(5) The HA, on receiving the BU, extracts the NAI, timestamp, and authenticator from the MN-AAA option, and generates the hash of the BU. The HA sends an Access Request to the AAA and puts this information in 3GPP2-defined VSAs (Vendor Specific Attributes). The NAI is inserted in the username option in the Access Request message. The other attributes sent are: the timestamp option, the hash of the BU (till SPI field of MN-AAA auth option), and the authentication data from the MN-AAA auth option.
（5）HAは、BUを受信すると、MN-AAAオプションからNAI、タイムスタンプ、およびオーセンティケータを抽出し、BUのハッシュを生成します。 HAは、AAAへアクセス要求を送信し、3GPP2定義のVSA（ベンダー固有属性）にこの情報を置きます。 NAIは、アクセス要求メッセージでusernameオプションで挿入されています。送信された他の属性は以下のとおりです。タイムスタンプオプション、BU（MN-AAAの認証オプションのSPIまでのフィールド）のハッシュ、およびMN-AAAの認証オプションから認証データ。
(6) AAA (RADIUS server that interprets these attributes) authenticates the MN based on the hash of the BU and the authenticator. Proceed to step 7.
（6）AAA（これらの属性を解釈し、RADIUSサーバ）は、BUと認証のハッシュに基づいて、MNを認証します。 7に進みます。
(7) AAA calculates a session key based on the MN-AAA shared secret and timestamp, and sends this to the HA in an Access Accept (in a 3GPP2-defined VSA).
（7）AAAは、MN-AAAに基づいてセッション鍵を計算秘密とタイムスタンプの共有、および（3GPP2定義VSAに）受け入れAccessでHAに送信します。
(8) The HA creates a binding and a security association per Authentication Protocol for MIPv6 [RFC4285]. The key for this association is retrieved from the Access Accept and is referred to as the session key. The HA associates a fixed SPI of 5 with this SA, and is associated with the binding for the MN. (The description of this step skips the details for timestamp processing at the HA.)
（8）HA結合およびMIPv6の[RFC4285]のための認証プロトコルあたりのセキュリティアソシエーションを作成します。この関連のキーは受け入れAccessから取得されたセッション鍵と呼ばれます。 HAは、このSAと5の固定されたSPIを関連付け、そしてMNのバインディングに関連付けられています。 （このステップの説明は、HAにおけるタイムスタンプ処理の詳細をスキップします）。
(9) The HA sends a Binding Acknowledgement (BAck) to the MN. The BAck has the MN-HA authentication option, authenticated using the session key. This option has the SPI set to 5.
（9）HAは、MNに結合確認（裏面）を送信します。バックMN-HA認証オプションがあり、セッションキーを使用して認証。このオプションは5にSPIが設定されています。
(10) On receiving a BAck, the MN calculates the session key (using the same method as AAA) and associates it with an SPI value of 5.
（10）バックを受信すると、MNは、（AAAと同様の方法を使用して）セッション鍵を計算し、5のSPI値に関連付けます。
The MN derives the session key and SA using the timestamp in the BU that the MN sent and the MN-AAA shared key. The MN uses this key to authenticate the MN-HA option in the Binding Ack. If authentication is successful, the MN creates a security association with SPI=5. This key is used to authenticate further BUs to the HA using the MN-HA auth option. Once the binding lifetime expires and the binding is deleted, the binding as well as the security association based on the integrity key is removed at the MN and HA.
MNは、MNが送信され、MN-AAAがキーを共有することをBUにタイムスタンプを使用して、セッション鍵とSAを導出します。 MNは、バインディングのAckにおけるMN-HAオプションを認証するために、このキーを使用しています。認証が成功した場合、MNは、SPI = 5とのセキュリティアソシエーションを作成します。このキーは、MN-HAの認証オプションを使用してHAに、バスを認証するために使用されます。結合ライフタイムが満了し、結合を削除すると、整合性のキーに基づいて、同様のセキュリティ・アソシエーションのような結合は、MNとHAで除去されます。
Migration from MobileIPv4 to MobileIPv6 utilizes the same network architecture and, specifically, the same AAA infrastructure. Thus, it is natural to have similar signaling in MIPv6 as in MIPv4, specifically the authentication with AAA infrastructure.
MobileIPv4からモバイルIPv6への移行は、具体的には、同一のAAAインフラストラクチャを同一のネットワークアーキテクチャを利用し。したがって、MIPv4の、AAAインフラストラクチャと特異的に認証とMIPv6のに同様のシグナルを有することは当然です。
While the authentication protocol as specified in [RFC4285] provides Mobile IPv6 [RFC3775] deployments a certain degree of flexibility, it does have a few disadvantages as well. These are:
[RFC4285]で指定されている認証プロトコルがモバイルIPv6 [RFC3775]はある程度の柔軟性をデプロイメント提供していますが、それは同様に、いくつかの欠点を持っています。これらは：
(1) The route optimization feature specified in RFC 3775 requires a secure transport (IPsec/ESP (Encapsulating Security Payload) mode) between the MN and HA. In cases where the authentication protocol [RFC4285] is used as the means for securing the MIPv6
（1）RFC 3775で指定された経路最適化機能は、MNとHAの間のセキュアなトランスポート（IPsecの/ ESP（カプセル化セキュリティペイロード）モード）が必要です。認証プロトコル[RFC4285]はMIPv6のを確保する手段として使用される場合には
signaling between the MN and HA, route optimization should be
switched off unless the security of the signaling between the MN
and HA can be guaranteed via other means (such as link-layer
security in the case of 3GPP2 networks).
(2) The MIPv6 protocol is responsible for the security of the signaling messages as opposed to relying on IPsec for providing the security.
（2）のMIPv6プロトコルは、セキュリティを提供するためにIPsecに依存するとは対照的に、シグナリングメッセージのセキュリティを担当します。
(3) In 3GPP2 networks, link-layer security mechanisms, ingress filtering at the PDSN, and various network domain security mechanisms largely ensure that reverse tunnelled packets received by the HA do not have spoofed source addresses, and that their contents have not been modified. This implies the HA can determine the specific MN that sent the packet simply by verifying the outer-source IP address matches the currently registered care-of address. Authentication of payload packets can be necessary for, e.g.:
（3）3GPP2ネットワークでは、リンク層セキュリティメカニズム、PDSNにイングレスフィルタリング、および様々なネットワークドメインのセキュリティメカニズムは、主にその逆を確実にHAによって受信されたパケットは、送信元アドレスを偽装し、その内容が変更されていないことれていないトンネル。これは、HAは、単に外側のソースIPアドレスが現在登録気付アドレスと一致して検証することによって、パケットを送信した特定のMNを決定することができますを意味します。ペイロードパケットの認証は、例えばのために必要であることができます：
- Authenticating signaling messages other than BU/BAck
between the MN and HA, such as ICMPv6, MLD, and DHCPv6.
- Enforcing access control to the network behind the HA.
- HAの背後にあるネットワークへのアクセス制御を強制。
- Accounting or other flow-specific processing performed by the HA.
- 会計又はHAによって実行される他のフロー特定処理。
This means the authentication option is of limited
applicability in environments where the HA can receive
reverse-tunneled packets with spoofed source IP addresses
and/or modified contents.
(4) As described in [RFC4285], the authentication option assumes that the MN-AAA shared key and security association are created by out-of-band mechanisms. These mechanisms are specific to specific deployment environments. IKEv2, on the other hand, supports a wide range of authentication mechanisms, such as certificates and Extensible Authentication Protocol (EAP) methods, and is independent of the access network technology being used. However, it would be possible to specify a similar authentication and key management protocol for the authentication option in the future.
[RFC4285]に記載されているように（4）、認証オプションは、MN-AAAキーとセキュリティアソシエーションがアウトオブバンドメカニズムによって作成される共有していることを前提としています。これらのメカニズムは、特定のデプロイメント環境に固有のものです。 IKEv2のは、一方で、そのような証明書および拡張認証プロトコル（EAP）メソッドなどの認証メカニズムの広い範囲をサポートし、使用されているアクセスネットワーク技術とは無関係です。しかし、将来の認証オプションについても同様の認証と鍵管理プロトコルを指定することも可能です。
(5) Sending the long-term user identity (NAI) in the clear raises privacy concerns. These concerns are addressed by access network and network domain security mechanisms in 3GPP2 networks, but do limit the applicability in networks where sniffing other users' traffic is possible.
（5）明確に長期ユーザーID（NAI）を送信すると、プライバシーの問題を提起します。これらの懸念は、3GPP2ネットワークにおけるアクセスネットワークとネットワークドメインのセキュリティメカニズムによって対処されますが、他のユーザのトラフィックが可能ですスニッフィングどこのネットワークに適用可能性を制限しません。
(6) RFC 4285 does not specify a mechanism for creating the MN-HA shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4 mechanisms defined in [RFC3957]), and thus relies on deployment-specific mechanisms not standardized in the IETF.
（6）RFC 4285には、MN-AAA SA（[RFC3957]で定義された同様のモバイルIPv4メカニズムとは異なり）からキーとSA共有、したがってに標準化されていない展開固有のメカニズムに依存しているMN-HAを作成するためのメカニズムを指定していませんIETF。
(7) The authentication option does not support negotiation of cryptographic algorithms.
（7）認証オプションは、暗号アルゴリズムのネゴシエーションをサポートしていません。
(8) The replay protection mechanisms in [RFC4285] rely on timestamps, and thus require reasonably synchronized clocks (by default, +/- 7 seconds). This assumes the MN implements, and is configured to use, some mechanism for synchronizing its clock.
（8）[RFC4285]でリプレイ保護メカニズムは、タイムスタンプに依存し、したがって、（+/- 7秒、デフォルトで）合理的に同期したクロックを必要とします。これは、MNの実装を前提とし、かつ、そのクロックを同期化するためのいくつかのメカニズムを使用するように設定されています。
When MIPv6 signaling messages use IPsec with ESP encapsulation, they are accorded privacy on the links over which the messages traverse. When MIPv6 signaling messages are secured using the authentication protocol, such ciphering capability will have to be enabled by the underlying link layers. It should be noted that the MIPv6 signaling messages are susceptible to snooping/sniffing when the authentication protocol [RFC4285] is used. Route optimization messages need to be secured between the MN and HA and this is not possible with the authentication protocol. However, route optimization is not supported in the current specification of the authentication protocol in [RFC4285].
MIPv6のシグナリングメッセージは、ESPのカプセル化とIPsecを使用すると、彼らはメッセージがトラバースれるリンク上でのプライバシーを従うされています。 MIPv6のシグナリングメッセージは認証プロトコルを使用して固定されている場合は、そのような暗号化機能は、基礎となるリンクレイヤで有効にする必要があります。 MIPv6のシグナリングメッセージは、認証プロトコル[RFC4285]を使用する場合スニッフィング/スヌーピングに感受性であることに留意すべきです。経路最適化メッセージは、MNとHAとの間に固定される必要があり、これは認証プロトコルでは不可能です。しかしながら、ルート最適化は、[RFC4285]での認証プロトコルの現在の仕様ではサポートされていません。
Security issues with RFC 4285 are specifically:
RFC 4285でのセキュリティの問題は、具体的には、次のとおりです。
2. The keys used for securing the signaling between the MN and HA are derived from a security association that exists between the MN and AAA. The MIPv6 keys, which are bootstrapped from the MN-AAA SA, are transient. Limiting the lifetime of the keys to shorter periods should be recommended.
2. MNとHAの間のシグナリングを確保するために使用されるキーは、MNとAAAとの間に存在するセキュリティアソシエーションに由来します。 MN-AAA SAからブートストラップされているMIPv6のキーは、一時的なものです。短い期間の鍵の寿命を制限することをお勧めする必要があります。
3. Location privacy is an issue in the absence of lower-layer security in the case of shared links.
3.場所のプライバシーは、共有リンクの場合は、下位層のセキュリティが存在しない場合に問題です。
Mobile IPv6 was published as a Standards Track RFC [RFC3775] in 2004. Deployment of this protocol on a large scale is in the interest of the IETF and the working group, as well as that of many people who have worked on this. A rigid model for deployment will cause the protocol to be limited to an academic exercise only. It is extremely critical that the working group consider the needs of the industry and the deployment scenarios, and address them accordingly. This document captures the reasoning behind the need for the authentication protocol, which has been published as RFC 4285. RFC 4877 has alleviated some of the issues that have been of primary concern and were motivators for the authentication protocol. However, the IETF should consider the architectures of networks such as 3GPP2 and WiMAX and their security models, and enable deployment of Mobile IPv6 without requiring IPsec.
モバイルIPv6は、大規模にこのプロトコルの2004年の展開で標準化過程RFC [RFC3775]として発行されたIETFワーキング・グループと同様に、この上で働いている多くの人々のそれの興味です。展開のための剛体モデルでは、プロトコルは、学術的な運動のみに限定されることになります。ワーキンググループは、産業界のニーズと展開シナリオを検討し、それに応じて対処することが極めて重要です。この文書では、主要懸念されて、認証プロトコルのための動機だったしている問題の一部を緩和したRFC 4285. RFC 4877として公開されている認証プロトコルの必要性の背後にある理由をキャプチャします。しかし、IETFは、3GPP2やWiMAXとそのセキュリティモデルのようなネットワークのアーキテクチャを考慮し、IPsecを必要とせず、モバイルIPv6の展開を有効にする必要があります。
The authors would like to thank Alpesh Patel, AC Mahendra, Kuntal Chowdhury, and Vijay Devarapalli for their input and discussions. Jari Arkko has reviewed the ID and provided valuable feedback. Thomas Narten has provided valuable reviews and made significant improvements to the text in this document. In his role as the IETF liaison to 3GPP2, Thomas Narten has ensured that the IETF understands the 3GPP2 requirements. Pasi Eronen, in his role as the Security AD, has reviewed and helped improve the document. Vidya Narayanan has reviewed the document from a security directorate perspective and provided input that has been incorporated.
作者は彼らの入力と議論をAlpeshパテル、ACマヘンドラ、Kuntalチョードリー、およびビジェイDevarapalliに感謝したいと思います。ヤリArkkoはIDを検討し、貴重なフィードバックを提供してきました。トーマスNarten氏は、貴重なレビューを提供し、この文書のテキストに大幅な改善を行いました。 3GPP2にIETFのリエゾンとして彼の役割では、トーマスNarten氏は、IETFは、3GPP2の要件を理解することを確実にしました。パシEronenは、セキュリティADとして彼の役割で、検討し、文書の向上に役立っています。 Vidyaナラヤナンは、セキュリティ総局の観点から文書をレビューし、組み込まれている入力を提供してきました。
[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月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[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月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6（MIPv6の）のためのモバイルノード識別子オプション"、RFC 4283、2005年11月。
[3GPP2 X.S0011-002-D] 3GPP2 X.S0011-002-D, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services", http://www.3gpp2.org/ Public_html/specs/ X.S0011-002-D_v1.0_060301.pdf, February 2006.
[3GPP2 X.S0011-002-D] 3GPP2 X.S0011-002-D、 "CDMA2000無線IPネットワーク標準：単純IPおよびモバイルIPアクセスサービス"、http://www.3gpp2.org/のpublic_html /スペック/ X .S0011-002-D_v1.0_060301.pdf、2006年2月。
[AUTH-PRO] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", Work in Progress, July 2008.
[AUTH-PRO]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、進歩、2008年7月に働いています。
[BOOT] Chowdhury, K. and A. Yegin, "MIP6- Bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[BOOT]チョードリー、K.とA. Yegin、 "統合シナリオのためのMIP6-ブートストラップ"、進歩、2008年4月の作業。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[RFC3957]パーキンス、C.とP.カルフーン、 "モバイルIPv4のための認証、許可、アカウンティング（AAA）の登録キー"、RFC 3957、2005年3月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、RFC 4285、2006年1月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、ケンプ、J.、およびV. Devarapalli、 "分割シナリオにおけるモバイルIPv6ブートストラップ"、RFC 5026、2007年10月。
[WiMAX-NWG] "WiMAX Network Architecture - WiMAX End-to-End Network Systems Architecture", May 2008, <http ://www.wimaxforum.org/documents/documents/ WiMAX_Forum_Network_Architecture_Stage_2- 3_Rel_1v1.2.zip>.
[WiMAXの-NWG] "のWiMAXネットワークアーキテクチャ - WiMAXのエンドツーエンドのネットワークシステムアーキテクチャ"、2008年5月、<のhttp：//www.wimaxforum.org/documents/documents/ WiMAX_Forum_Network_Architecture_Stage_2- 3_Rel_1v1.2.zip>。
Authors' Addresses
著者のアドレス
Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6021接続のドライブアーヴィング、TX 75039 USA
EMail: basavaraj.patil@nokia.com
メールアドレス：basavaraj.patil@nokia.com
Gopal Dommety Cisco 170 West Tasman Drive San Jose, CA 95134 USA
ゴパルDommetyシスコ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: gdommety@cisco.com
メールアドレス：gdommety@cisco.com