[要約] 要約：RFC 5419は、モバイルIPv6（MIPv6）において認証データサブオプションが必要な理由を説明しています。 目的：このRFCの目的は、MIPv6における認証データサブオプションの重要性を強調し、モバイルネットワークのセキュリティを向上させることです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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は、モバイルノード（MN）がホームエージェント（HA）との登録を認証および実行できるようにする一連の信号メッセージを定義します。モバイルノードとホームエージェントの間のこれらの認証シグナリングメッセージは、MNとHAの間に確立されたIPSECセキュリティ協会（SA）によって保護されます。MIP6ワーキンググループは、MNとHAの間で交換されるシグナルメッセージ内で運ばれるモバイルIPv4の認証オプションと同様に、認証オプションを使用して、バインディングアップデート（BU）およびバインディング確認（BACK）メッセージを保護するメカニズムを指定しています。結合を確立する。このドキュメントは、特定の環境でのモバイル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で結合キャッシュを作成する前に、MNのHAへの認証のために、モバイルノード（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はこの問題を解決します。ただし、認証プロトコルの必要性に関する議論の時点で、「IKEV2と改訂されたIPSECアーキテクチャによるモバイルIPv6操作」[RFC4877]はまだ進行中の作業であり、その結果、代替ソリューションが必要でした。
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-HOT（ホームテストINIT/ホームテスト）、COTI-COT（テストのケア/ケアオブテスト）、およびMNとCNの間のBUバックメッセージを含むルート最適化シグナリングメッセージ。HOTIおよびHOTシグナル伝達メッセージは、MNのHAを介してルーティングされます。
o Mobile prefix solicitation and advertisements between the MN and HA.
o MNとHAの間のモバイルプレフィックスの勧誘と広告。
o Home agent discovery by MNs.
o MNSによるホームエージェントディスカバリー。
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.
1. Cellular NetworksにMIPV6を展開するオペレーターは、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.
3. 多くの展開において、認証資格情報はすでに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を割り当てることによって行われます。特にHAが訪問されたネットワークにある場合、動的に割り当てられたホームエージェントとIPSEC SASを必要とすることは頭上です。
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の間のシグナリングメッセージが安全なリンクレイヤーを超えている場合があります。下層は、メッセージの微細なセキュリティとセキュリティを提供するため、MIPV6メッセージに対してIPSECも同じことを行う必要性は存在しません。
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].
このような特性を持つネットワークの1つの例は、3GPP2 [3GPP2 X.S0011-002-D]仕様で定義されているコード分割多重アクセス（CDMA）ネットワークです。IEEE 802.16Eに基づくモバイルWIMAX（マイクロ波アクセスの世界的な相互運用性）は、ネットワークアーキテクチャでもMIPv6の使用を指定しており、シグナル伝達のデフォルトセキュリティは認証プロトコル[RFC4285]です。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.
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操作を指定しました。以下は、IPv6に基づいてモビリティサービスを展開するときに既存のCDMAネットワークが対処しなければならない展開制約です。
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.
o
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
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
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-BOOTSTAPPING」[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の認証プロトコル」[RFC4285]と「MIPV6のMN識別子オプション」[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.
以前のMIPV6展開モデルは、手動で構成されているか、IKEを使用して確立されているIPSEC SAを必要としますが、3GPP2またはWIMAXネットワークの展開モデルとの相乗効果はありません。しかし、この問題は、IKEV2を使用したIPSEC SAの確立を可能にするRFC 4877の公開で緩和されており、3GPP2およびWimaxネットワークでのMNの認証を担当するバックエンドAAAインフラストラクチャとも統合することができます。
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.
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.
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.
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].
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 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].
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ネットワークのMNSの大規模なサブセットには、IKE機能がありません。その結果、MN-HA IPSEC SAをセットアップするためのRFC 3776の使用は選択肢ではありません。また、IPSEC SAを確立する前に、IKEにはいくつかのトランザクションが必要であることに注意する必要があります。[RFC4877]は、IKEV2を使用してMNとHAの間にIPSEC SAの確立を指定します。展開中のすべてのMNSが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のもう1つの欠点は、IKEが半径ベースのAAAバックエンドとあまり統合されていないことです。オペレーターはAAAインフラストラクチャに依存して購読者を提供し、AAA-Homeでプロファイル、キーなどを定義するため、CDMA2000ネットワークでのAAAの使用から逃れることはできません。IKEV2はこの問題に対処します。ただし、タイムラインの観点からは、「IKEV2および改訂されたIPSECアーキテクチャによるモバイルIPv6操作」[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.
要約すると、RFCS 3775および3776で指定されているように、MNとHAの間にIPSEC SAの存在を義務付けたモバイルIPv6展開のモデルは硬すぎ、CDMA2000に基づいてネットワークを構築するオペレーターの要件を満たしていませんでした[3GPP2X.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].
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とHome 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)
(2) The PDSN (Packet Data Serving Node) sends a Mobile IP challenge to the MN on the PPP link (RFC 3012).
(2)
(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)
(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)
(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（Home AAA）に転送できます。
(6) AAA authenticates the CHAP-challenge/response and returns "success" if authentication succeeds.
(6) AAAは、Chap-Challenge/Responseを認証し、認証が成功した場合に「成功」を返します。
(7) The PDSN forwards the Registration Request (RRQ) to the HA.
(7) PDSNは、登録要求（RRQ）をHAに転送します。
(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)
(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は訪問者エントリを作成し、RRPをMNに転送します。
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とHome AAAサーバーの間の共有キーです。
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認証が実行されます。これは、F-AAAにアクセス要求を送信することにより、PDSN/AR（アクセスルーター）によって認証されます（および必要に応じてH-AAAに）。オプションで、MNはホームネットワークからブートストラップ情報を取得します（PDSNを介して、PDSNはAccess Acceptでこの情報を受信します）。ブートストラップ情報には、ホームアドレスとホームエージェントの割り当てが含まれます。MNは、Stateless DHCPV6 [RFC3736]を使用して、PDSNからブートストラップ情報を取得します。
(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は、ステップ1で割り当てられたホームアドレス（HOA）を使用し始めます。ステップ1でHOAが割り当てられていない場合、MNはステップ1で受信したプレフィックス情報に基づいてIPv6グローバルユニキャストアドレスを生成します（自動構成）。
(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 AUTHオプションが含まれています。
(4) The HA extracts the NAI, authenticator, etc. from the BU and sends an Access Request to the Home RADIUS server.
(4) HAは、NAI、AuthenticatorなどをBUから抽出し、Home 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) Home Radius Serverは、ユーザーを認証および承認し、認証と承認が成功することを示すHAにRADIUSアクセスを送り返します。
(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]で指定されているように、プロキシNeighbor Salicitationを使用して、MNの自宅住所（Global）でプロキシ重複アドレス検出（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) プロキシパパが成功していると仮定すると、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は、MNをトリガーして、Access認証の一部としてCHAP認証を実行し、PPPリンクを持ち上げます。
(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（Home 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をブートストラップするためにHOAおよびHA IPアドレスをPDSNに送信する場合があります（詳細をスキップ）。
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
(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)
(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)
(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共有の秘密とタイムスタンプに基づいてセッションキーを計算し、Access Accept（3GPP2定義のVSA）で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]の認証プロトコルごとに拘束力とセキュリティアソシエーションを作成します。この協会のキーは、アクセス受け入れから取得され、セッションキーと呼ばれます。HAは、5の固定SPIをこのSAと関連付け、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認証オプションがあり、セッションキーを使用して認証されています。このオプションには、SPIが5に設定されています。
(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が送信したBUのタイムスタンプとMN-AAAがキーを共有したセッションキーと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からMobileIPv6への移行は、同じネットワークアーキテクチャ、特に同じ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 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).
(1) RFC 3775で指定されたルート最適化機能には、MNとHAの間の安全なトランスポート（IPSEC/ESP（セキュリティペイロードのカプセル化）モード）が必要です。認証プロトコル[RFC4285]がMNとHAの間のMIPV6シグナル伝達を保護する手段として使用される場合、MNとHA間のシグナルのセキュリティが他の手段で保証できる場合を除き、ルート最適化をオフにする必要があります（そのような3GPP2ネットワークの場合のリンク層セキュリティとして）。
(2) The MIPv6 protocol is responsible for the security of the signaling messages as opposed to relying on IPsec for providing the security.
(2)
(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)
- Authenticating signaling messages other than BU/BAck between the MN and HA, such as ICMPv6, MLD, and DHCPv6.
- ICMPv6、MLD、DHCPV6など、MNとHAの間のBU/バック以外の信号メッセージを認証するメッセージ。
- 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.
つまり、認証オプションは、HAがスプーフィングされたソースIPアドレスおよび/または変更されたコンテンツを備えた逆張りのパケットを受け取ることができる環境での適用性が限られていることを意味します。
(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.
(4) [RFC4285]で説明されているように、認証オプションは、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)
(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シグナリングメッセージが認証プロトコルを使用して保護される場合、そのような暗号化機能は、基礎となるリンクレイヤーによって有効にする必要があります。認証プロトコル[RFC4285]が使用されると、MIPV6シグナル伝達メッセージがスヌーピング/スニッフィングの影響を受けやすいことに注意してください。ルート最適化メッセージはMNとHAの間で確保する必要があり、これは認証プロトコルでは不可能です。ただし、[RFC4285]の認証プロトコルの現在の仕様では、ルートの最適化はサポートされていません。
Security issues with RFC 4285 are specifically:
RFC 4285のセキュリティ問題は特に次のとおりです。
1. Key length. This is being addressed in [AUTH-PRO].
1. キー長。これは[auth-pro]で対処されています。
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.
展開用の厳格なモデルにより、プロトコルは学術演習のみに制限されます。ワーキンググループが業界のニーズと展開シナリオを考慮し、それに応じてそれらに対処することが非常に重要です。
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 Patel、AC Mahendra、Kuntal Chowdhury、Vijay Devarapalliの意見と議論に感謝したいと思います。Jari ArkkoはIDをレビューし、貴重なフィードバックを提供しました。Thomas Nartenは貴重なレビューを提供し、このドキュメントのテキストを大幅に改善しました。3GPP2へのIETF連絡役としての彼の役割において、Thomas NartenはIETFが3GPP2要件を理解することを保証しました。Vidya Narayananは、セキュリティ局の観点から文書をレビューし、組み込まれた入力を提供しました。
[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月。
[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.
[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。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[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/specs/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] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6の認証プロトコル」、2008年7月の作業。
[BOOT] Chowdhury, K. and A. Yegin, "MIP6- Bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[Boot] Chowdhury、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.、Simpson、W。、およびH. Soliman、「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] Perkins、C。およびP. Calhoun、「認証、認可、および会計（AAA）モバイルIPv4の登録キー」、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] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイル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. Dupont、「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.、Kempf、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 Patil Nokia 6021 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nokia.com
Gopal Dommety Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Gopal Dommety Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: gdommety@cisco.com