[要約] RFC 6097は、Proxy Mobile IPv6におけるLocal Mobility Anchor（LMA）の発見に関する仕様です。このRFCの目的は、モバイルノードがLMAを効率的に発見できるようにすることです。
Internet Engineering Task Force (IETF) J. Korhonen
Request for Comments: 6097 Nokia Siemens Networks
Category: Informational V. Devarapalli
ISSN: 2070-1721 Vasona Networks
February 2011
Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6
プロキシモバイルIPv6用のローカルモビリティアンカー（LMA）発見
Abstract
概要
Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions.
大規模なプロキシモバイルIPv6展開は、モバイルアクセスゲートウェイがプロキシモバイルIPv6ドメインに接続するモバイルノードのローカルモビリティアンカーを動的に発見できる機能から利益を得ます。動的発見機能の目的は、モバイルアクセスゲートウェイの静的構成の量を減らすことです。このドキュメントでは、いくつかの動的なローカルモビリティアンカーディスカバリーソリューションを説明しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6097.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6097で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. AAA-Based Discovery Solutions ...................................3
2.1. Receiving the LMA Address during Network Access
Authentication .............................................4
2.2. Receiving the LMA FQDN during Network Access
Authentication .............................................4
3. Discovery Solutions Based on Data from Lower Layers .............5
3.1. Constructing the LMA FQDN from a Mobile Node Identity ......5
3.2. Receiving the LMA FQDN or IP Address from Lower Layers .....5
3.3. Constructing the LMA FQDN from a Service Name ..............6
4. Handover Considerations .........................................6
5. Recommendations .................................................7
6. Security Considerations .........................................8
7. Acknowledgements ................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from a functionality where a Mobile Access Gateway (MAG) can dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node (MN) attaching to a PMIPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the MAG. Other drivers for the dynamic discovery of an LMA include LMA load balancing solutions and selecting an LMA based on desired services (i.e., allowing service-specific routing of traffic) [RFC5149]. This document describes several possible dynamic LMA discovery approaches and makes a recommendation of the preferred one.
プロキシモバイルIPv6（PMIPV6）[RFC5213]展開は、Mobile Access Gateway（MAG）がPMIPV6ドメインに付着するモバイルノード（MN）のローカルモビリティアンカー（LMA）を動的に発見できる機能から利益を得ます。動的発見機能の目的は、MAGの静的構成の量を減らすことです。LMAの動的発見のための他のドライバーには、LMA負荷分散ソリューションと、目的のサービスに基づいてLMAを選択する（つまり、トラフィックのサービス固有のルーティングを可能にする）[RFC5149]が含まれます。このドキュメントでは、いくつかの可能な動的LMA発見アプローチについて説明し、優先されたアプローチを推奨します。
The following list briefly introduces solution approaches that will be discussed in this document. The approaches discussed do not include all possible discovery mechanisms, but are limited to those considered to fit most simply into the PMIPv6 environment.
次のリストでは、このドキュメントで説明するソリューションアプローチを簡単に紹介します。議論されたアプローチには、可能なすべての発見メカニズムが含まれるわけではありませんが、PMIPv6環境に最も単純に適合すると考えられるものに限定されています。
o LMA Address is retrieved from the Authentication, Authorization, and Accounting (AAA) infrastructure during the network access authentication procedure when the MN attaches to the MAG.
o LMAアドレスは、MNがMAGに付着したときに、ネットワークアクセス認証手順中に認証、承認、および会計（AAA）インフラストラクチャから取得されます。
o LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA infrastructure during the network access authentication, followed by a Domain Name System (DNS) lookup.
o LMA完全資格のドメイン名（FQDN）は、ネットワークアクセス認証中にAAAインフラストラクチャから取得され、その後、ドメイン名システム（DNS）ルックアップが続きます。
o LMA FQDN is derived from the MN identity received from the lower layers during the network attachment, followed by a DNS lookup.
o LMA FQDNは、ネットワークアタッチメント中に下層から受信されたMN IDから派生し、DNSルックアップが続きます。
o LMA FQDN or IP address is received from the lower layers during the network attachment. The reception of an FQDN from the lower layers is followed by a DNS lookup.
o LMA FQDNまたはIPアドレスは、ネットワーク添付ファイル中に下層から受信されます。下層からのFQDNの受信の後にDNSルックアップが続きます。
o LMA FQDN is derived from the service selection indication received from lower layers during the network attachment, followed by a DNS lookup.
o LMA FQDNは、ネットワークアタッチメント中に下層から受け取ったサービス選択表示から派生し、DNSルックアップが続きます。
When an MN performs a handover from one MAG to another, the new MAG must use the same LMA that the old MAG was using. This is required for session continuity. The LMA discovery mechanism in the new MAG should be able to return the information of the same LMA that was being used by the old MAG. This document also discusses solutions for LMA discovery during a handover.
MNが1つの雑誌から別の雑誌へと引き渡すと、新しい雑誌は古い雑誌が使用していたのと同じLMAを使用する必要があります。これは、セッションの継続性に必要です。新しい雑誌のLMA発見メカニズムは、古い雑誌で使用されている同じLMAの情報を返すことができるはずです。このドキュメントでは、ハンドオーバー中のLMA発見のソリューションについても説明しています。
This section presents an LMA discovery solution that requires a MAG to be connected to an AAA infrastructure (as described in [RFC5779], for instance). The AAA infrastructure is also assumed to be aware of PMIPv6. An MN attaching to a PMIPv6 domain is typically required to provide authentication for network access and to be authorized for mobility services before the MN is allowed to send or receive any IP packets or even complete its IP level configuration.
このセクションでは、MAGをAAAインフラストラクチャに接続する必要があるLMA発見ソリューションを示します（たとえば、[RFC5779]で説明されているように）。AAAインフラストラクチャもPMIPv6を認識していると想定されています。通常、PMIPv6ドメインに接続するMNは、ネットワークアクセスに認証を提供し、MNがIPパケットを送信または受信するか、IPレベルの構成を完了する前にモビリティサービスを許可するために必要です。
The AAA-based LMA discovery solution hooks into the network access authentication and authorization process. The MAG also has the role of a Network Access Server (NAS) at this step. While the MN is attaching to the network, the PMIPv6-related parameters are bootstrapped in parallel with authentication for the network access and authorization for the mobility services. The bootstrapping of PMIPv6 parameters involves the policy profile download over the AAA infrastructure to the MAG (see Appendix A of [RFC5213]).
AAAベースのLMAディスカバリーソリューションは、ネットワークアクセス認証と認証プロセスに接続されます。MAGには、このステップでネットワークアクセスサーバー（NAS）の役割もあります。MNがネットワークに接続している間、PMIPV6関連のパラメーターは、ネットワークアクセスの認証とモビリティサービスの認証と並行してブートストラップされています。PMIPv6パラメーターのブートストラップには、AAAインフラストラクチャからMAGへのポリシープロファイルのダウンロードが含まれます（[RFC5213]の付録Aを参照）。
After the MN has been successfully authenticated for network access and authorized for the mobility service, the MAG receives the LMA IP address from the AAA server over the AAA infrastructure. The LMA IP address information would be part of the AAA message that ends the successful authentication and authorization portion of the AAA exchange.
MNがネットワークアクセスに対して正常に認証され、モビリティサービスで承認された後、MAGはAAAインフラストラクチャを介してAAAサーバーからLMA IPアドレスを受信します。LMA IPアドレス情報は、AAA Exchangeの成功した認証および承認部分を終了するAAAメッセージの一部です。
Once the MAG receives the LMA IP address, it sends a Proxy Binding Update (PBU) message for the newly authenticated and authorized MN. The MAG expects that the LMA returned by the AAA server is able to provide mobility session continuity for the MN, i.e., after a handover, the LMA would be the same one the MN already has a mobility session set up with.
MAGがLMA IPアドレスを受信すると、新しく認証され、認定されたMNに対してプロキシバインディングアップデート（PBU）メッセージが送信されます。MAGは、AAAサーバーによって返されたLMAがMNのモビリティセッションの継続性を提供できることを期待しています。つまり、ハンドオーバー後、LMAはMNがすでにモビリティセッションを設定しているのと同じです。
This solution is similar to the procedure described in Section 2.1. The difference is that the MAG receives an FQDN of the LMA instead of the IP address(es). The MAG has to query the DNS infrastructure in order to resolve the FQDN to the LMA IP address(es).
このソリューションは、セクション2.1で説明されている手順に似ています。違いは、MAGがIPアドレス（ES）の代わりにLMAのFQDNを受信することです。MAGは、FQDNをLMA IPアドレス（ES）に解決するために、DNSインフラストラクチャを照会する必要があります。
The LMA FQDN might be a generic name for a PMIPv6 domain that resolves to one or more LMAs in the PMIPv6 domain. Alternatively, the LMA FQDN might be resolved to exactly one LMA within the PMIPv6 domain. The latter approach would obviously be useful if a new target MAG, after a handover, resolved the LMA FQDN to the LMA IP address where the MN mobility session is already located.
LMA FQDNは、PMIPv6ドメインの1つ以上のLMAに分解するPMIPv6ドメインの汎用名である可能性があります。あるいは、LMA FQDNは、PMIPV6ドメイン内の1つのLMAに分解される可能性があります。後者のアプローチは、新しいターゲットMAGが、引き渡し後、MNモビリティセッションが既にあるLMA IPアドレスにLMA FQDNを解決した場合、明らかに役立ちます。
The procedures described in this section and in Section 2.1 may also be used together. For example, the AAA server might return a generic LMA FQDN during the MN's initial attachment, and once the LMA gets selected, return the LMA IP address during the subsequent attachments to other MAGs in the PMIPv6 domain. In order for this to work, the resolved and selected LMA IP address must be updated to the remote policy store. For example, the LMA could perform the policy store update using the AAA infrastructure once it receives the initial PBU from the MAG for the new mobility session.
このセクションおよびセクション2.1で説明する手順も一緒に使用できます。たとえば、AAAサーバーは、MNの初期添付ファイル中にジェネリックLMA FQDNを返す場合があり、LMAが選択されたら、PMIPv6ドメインの他のMAGへのその後のアタッチメント中にLMA IPアドレスを返します。これが機能するためには、解決および選択されたLMA IPアドレスをリモートポリシーストアに更新する必要があります。たとえば、LMAは、新しいモビリティセッションのためにMAGから最初のPBUを受信すると、AAAインフラストラクチャを使用してポリシーストアの更新を実行できます。
The following section discusses solutions where a MAG acquires information from layers below the IP layer. Based on this information, the MAG is able to determine which LMA to contact when the MN attaches to the MAG. The lower layers discussed here are not explicitly defined but include different radio access technologies and tunneling solutions such as an Internet Key Exchange version 2 (IKEv2) [RFC5996] IPsec tunnel [RFC4303].
次のセクションでは、MAGがIPレイヤーの下のレイヤーから情報を取得するソリューションについて説明します。この情報に基づいて、MAGはMNがMAGに付着したときに接触するLMAを決定することができます。ここで説明する下層層は明示的に定義されていませんが、インターネットキーエクスチェンジバージョン2（IKEV2）[RFC5996] IPSECトンネル[RFC4303]などのさまざまな無線アクセステクノロジーとトンネルソリューションが含まれています。
A MAG acquires an MN identity from lower layers. The MAG can use the information embedded in the identity to construct a generic LMA FQDN (based on some pre-configured formatting rules) and then proceed to resolve the LMA IP address(es) using the DNS. Obviously, the MN identity must embed information that can be used to uniquely identify the entity hosting and operating the LMA for the MN. Examples of such MN identities are the International Mobile Subscriber Identity (IMSI) and the Globally Unique Temporary User Equipment Identity (GUTI) [3GPP.23.003]. These MN identities contain information that can uniquely identify the operator to whom the subscription belongs.
MAGは、下層からMNアイデンティティを取得します。MAGは、アイデンティティに埋め込まれた情報を使用して、一般的なLMA FQDN（いくつかの事前に構成されたフォーマットルールに基づいて）を構築し、DNSを使用してLMA IPアドレスを解決するために進むことができます。明らかに、MNのIDは、MNのLMAをホスティングおよび操作するエンティティを一意に識別するために使用できる情報を埋め込む必要があります。このようなMN IDの例は、国際的なモバイル加入者ID（IMSI）とグローバルに一意の一時的なユーザー機器ID（GUTI）[3GPP.23.003]です。これらのMN IDには、サブスクリプションが属するオペレーターを独自に識別できる情報が含まれています。
The solution described here is similar to the solution discussed in Section 3.1. A MAG receives an LMA FQDN or an IP address from lower layers, for example, as a part of the normal lower-layer signaling when the MN attaches to the network. IKEv2 could be an existing example of such lower-layer signaling where IPsec is the "lower layer" for the MN [3GPP.24.302]. IKEv2 has an IKEv2 Identification - Responder (IDr) payload, which is used by the IKEv2 initiator (i.e., the MN in this case) to specify which of the responder's identities (i.e., the LMA in this case) it wants to talk to. And here the responder identity could be an FQDN or an IP address of the LMA (as the IKEv2 identification payload can be an IP address or an FQDN). Another existing example is the Access Point Name Information Element (APN IE) [3GPP.24.008] used in 3GPP radio network access signaling and capable of carrying an FQDN. However, in general, this means the MN is also the originator of the LMA information. The LMA information content as such can be transparent to the MN, meaning the MN does not associate the information with any LMA function.
ここで説明する解決策は、セクション3.1で説明されているソリューションに似ています。MAGは、MNがネットワークに付着する場合の通常の下層シグナル伝達の一部として、LMA FQDNまたは下層からIPアドレスを受け取ります。IKEV2は、IPSECがMN [3GPP.24.302]の「下層」であるこのような低層シグナル伝達の既存の例である可能性があります。IKEV2にはIKEV2識別 - レスポンダー（IDR）ペイロードがあります。これは、IKEV2イニシエーター（つまり、この場合のMN）が使用して、対応者のアイデンティティ（この場合はLMA）を指定します。そして、ここでは、レスポンダーのアイデンティティは、LMAのFQDNまたはIPアドレスである可能性があります（IKEV2識別ペイロードはIPアドレスまたはFQDNである可能性があるため）。別の既存の例は、3GPP無線ネットワークアクセス信号で使用され、FQDNを運ぶことができる3GPP無線ネットワークアクセスで使用されるアクセスポイント名情報要素（APN IE）[3GPP.24.008]です。ただし、一般に、これはMNがLMA情報の創始者でもあることを意味します。LMA情報のコンテンツ自体はMNに対して透過的である可能性があります。つまり、MNは情報をLMA関数に関連付けません。
Some network access technologies (including tunneling solutions) allow the MN to signal the service name that identifies a particular service or the external network it wants to access [3GPP.24.302] [RFC5996]. If the MN-originated service name also embeds the information of the entity hosting the service, or the hosting information can be derived from other information available at the same time (e.g., see Section 3.1), then the MAG can construct a generic LMA FQDN (e.g., based on some pre-defined formatting rules) providing an access to the service or the external network. The pre-defined formatting rules [3GPP.23.003] are usually agreed on among operators that belong to the same inter-operator roaming consortium or by network infrastructure vendors defining an open networking system architecture.
一部のネットワークアクセステクノロジー（トンネリングソリューションを含む）により、MNは特定のサービスまたはアクセスしたい外部ネットワークを識別するサービス名を信号することができます[3GPP.24.302] [RFC5996]。MNによって発生したサービス名がサービスをホストするエンティティの情報も埋め込んでいる場合、またはホスティング情報を同時に利用可能な他の情報から導き出すことができます（例：セクション3.1を参照）、MAGは一般的なLMA FQDNを構築できます（例えば、いくつかの定義されたフォーマットルールに基づいて）サービスまたは外部ネットワークへのアクセスを提供します。事前定義されたフォーマットルール[3GPP.23.003]は、通常、同じオペレーター間ローミングコンソーシアムに属するオペレーターまたはオープンネットワーキングシステムアーキテクチャを定義するネットワークインフラストラクチャベンダーに属するオペレーターの間で合意されています。
Once the MAG has the FQDN, it can proceed to resolve the LMA IP address(es) using the DNS. An example of such a service or external network name is the Access Point Name (APN) [3GPP.23.003] that contains the information of the operator providing the access to the given service or the external network. For example, an FQDN for an "ims" APN could be "ims.apn.epc.mnc015.mcc234.3gppnetwork.org".
MAGにFQDNがあると、DNSを使用してLMA IPアドレス（ES）を解決することができます。このようなサービスまたは外部ネットワーク名の例は、特定のサービスまたは外部ネットワークへのアクセスを提供するオペレーターの情報を含むアクセスポイント名（APN）[3GPP.23.003]です。たとえば、「IMS」APNのFQDNは「IMS.APN.EPC.MNC015.MCC234.3GPPNETWORK.ORG」である可能性があります。
Whenever an MN moves and attaches to a new MAG in a PMIPv6 domain, all the MAGs that the MN attaches to should use the same LMA. If there is only one LMA per PMIPv6 domain, then there is no issue. If there is a context transfer mechanism available between the MAGs, then the new MAG knows the LMA information from the old MAG. Such a mechanism is described in [RFC5949]. If the MN-related context is not transferred between the MAGs, then a mechanism to deliver the current LMA information to the new MAG is required.
MNが移動してPMIPv6ドメインの新しいMAGに付着するたびに、MNが付着するすべての雑誌は同じLMAを使用する必要があります。PMIPv6ドメインごとにLMAが1つしかない場合、問題はありません。雑誌間に利用可能なコンテキスト転送メカニズムがある場合、新しいMAGは古い雑誌からのLMA情報を知っています。このようなメカニズムは[RFC5949]で説明されています。MN関連のコンテキストが雑誌間で転送されない場合、現在のLMA情報を新しいMAGに送信するメカニズムが必要です。
Relying on DNS during handovers is not generally a working solution if the PMIPv6 domain has more than one LMA, unless the DNS consistently assigns a specific LMA for each given MN. In most cases described in Section 3, where the MAG derives the LMA FQDN, there is no prior knowledge whether the LMA FQDN resolves to one or more LMA IP address(es) in the PMIPv6 domain. However, depending on the deployment and deployment-related regulations (such as inter-operator roaming consortium agreements), the situation might not be this desperate. For example, a MAG might be able to synthesize an LMA-specific FQDN (e.g., out of an MN identity or some other service-specific parameters). Alternatively, the MAG could use (for example), an MN identity as an input to an algorithm that deterministically assigns the same LMA out of a pool of LMAs (assuming the MAG has, e.g., learned a group of LMA FQDNs via an SRV [RFC2782] query). These approaches would guarantee that DNS always returns the same LMA Address to the MAG.
DNSが与えられた各MNに対して一貫して特定のLMAを割り当てない限り、PMIPV6ドメインに複数のLMAを持っている場合、ハンドオーバー中にDNSに依存することは、一般に機能するソリューションではありません。ほとんどの場合、MAGがLMA FQDNを導出するセクション3で説明されている場合、LMA FQDNがPMIPv6ドメインの1つ以上のLMA IPアドレス（ES）に解決するかどうかは事前の知識がありません。ただし、展開および展開関連の規制（コンソーシアム間協定のローミングなど）の展開および展開関連の規制に応じて、この状況はこれほど必死ではないかもしれません。たとえば、MAGはLMA固有のFQDNを合成できる可能性があります（たとえば、MN IDまたはその他のサービス固有のパラメーターなど）。あるいは、MAGは（たとえば）、MN IDを使用して、アルゴリズムへの入力として使用できます。これは、LMAのプールから同じLMAを決定的に割り当てることを決定的に割り当てます（たとえば、MAGがSRVを介してLMA FQDNのグループを学習したと仮定します[rfc2782] query）。これらのアプローチは、DNSが常に同じLMAアドレスをMAGに返すことを保証します。
Once the MN completes its initial attachment to a PMIPv6 domain, the information about the LMA that is selected to serve the MN is stored in the policy store (or the AAA server). The LMA information is conveyed to the policy store by the LMA after the initial attachment is completed [RFC5779]. Typically, AAA infrastructure is used for exchanging information between the LMA and the policy store.
MNがPMIPv6ドメインへの最初のアタッチメントを完了すると、MNを提供するように選択されたLMAに関する情報は、ポリシーストア（またはAAAサーバー）に保存されます。LMA情報は、最初の添付ファイルが完了した後、LMAによってポリシーストアに伝えられます[RFC5779]。通常、AAAインフラストラクチャは、LMAとポリシーストア間の情報を交換するために使用されます。
When the MN moves and attaches to another MAG in the PMIPv6 domain, then the AAA server delivers the existing LMA information to the new MAG as part of the authentication and authorization procedure as described in Section 2.1.
MNがPMIPV6ドメインの別のMAGに移動して付着すると、AAAサーバーは、セクション2.1で説明されているように、認証および承認手順の一部として既存のLMA情報を新しいMAGに配信します。
This document discussed several solution approaches for a dynamic LMA discovery. All discussed solution approaches actually require additional functionality or infrastructure support that the base PMIPv6 specification [RFC5213] does not require.
このドキュメントでは、動的なLMA発見のためのいくつかのソリューションアプローチについて説明しました。議論されたすべてのソリューションアプローチでは、実際に追加の機能またはインフラストラクチャのサポートが必要です。
Solutions in Section 3 all depend on lower layers being able to provide information that a MAG can then use to query the DNS and discover a suitable LMA. The capabilities of the lower layers and the interactions with them are generally out of scope of the IETF, and specific to a certain system and architecture.
セクション3のソリューションはすべて、下層層に依存して、MAGがDNSを照会し、適切なLMAを発見するために使用できる情報を提供できるようにします。下層の機能とそれらとの相互作用は、一般にIETFの範囲外であり、特定のシステムとアーキテクチャに固有です。
Solutions in Section 2 depend on the existence of an AAA infrastructure, which is able to provide to a MAG either an LMA IP address or an LMA FQDN. While there can be system- and architecture-specific details regarding the AAA interactions and the use of DNS, the dynamic LMA discovery can be implemented in an access- and technology-agnostic manner, and work in the same way across heterogeneous environments. Therefore, using AAA-based LMA discovery solutions is recommended by this document. Furthermore, following the guidance in Section 4, Paragraph 4.1 of [RFC1958], the use of FQDNs should be preferred over IP addresses in the context of AAA-based LMA discovery solutions.
セクション2のソリューションは、LMA IPアドレスまたはLMA FQDNのいずれかのMAGに提供できるAAAインフラストラクチャの存在に依存しています。AAA相互作用とDNSの使用に関するシステムおよびアーキテクチャ固有の詳細がある場合がありますが、動的LMA発見はアクセスおよび技術に依存しない方法で実装でき、異種環境全体で同じ方法で機能します。したがって、このドキュメントでは、AAAベースのLMAディスカバリーソリューションを使用することをお勧めします。さらに、[RFC1958]のセクション4 4.1のガイダンスに続いて、AAAベースのLMAディスカバリーソリューションのコンテキストでは、FQDNの使用をIPアドレスよりも優先する必要があります。
The use of DNS for obtaining the IP address of a mobility agent carries certain security risks. These are explained in detail in Section 9.1 of [RFC5026]. However, the risks described in [RFC5026] are mitigated to a large extent in this document, since the MAG and the LMA belong to the same PMIPv6 domain. The DNS server that the MAG queries is also part of the same PMIPv6 domain. Even if the MAG obtains the IP address of a bogus LMA from a bogus DNS server, further harm is prevented since the MAG and the LMA should authenticate each other before exchanging PMIPv6 signaling messages. [RFC5213] specifies the use of IKEv2 between the MAG and the LMA to authenticate each other and set up IPsec security associations for protecting the PMIPv6 signaling messages.
モビリティエージェントのIPアドレスを取得するためのDNSの使用には、特定のセキュリティリスクがあります。これらについては、[RFC5026]のセクション9.1で詳しく説明しています。ただし、[RFC5026]で説明されているリスクは、MAGとLMAが同じPMIPv6ドメインに属しているため、このドキュメントでは大部分が軽減されます。MAGがクエリをクエリするDNSサーバーは、同じPMIPv6ドメインの一部でもあります。MAGが偽のDNSサーバーから偽のLMAのIPアドレスを取得したとしても、MAGとLMAはPMIPV6シグナル伝達メッセージを交換する前に互いに認証する必要があるため、さらなる害が防止されます。[RFC5213]は、MAGとLMA間のIKEV2の使用を指定して、相互に認証し、PMIPV6シグナル伝達メッセージを保護するためにIPSECセキュリティアソシエーションを設定します。
The AAA infrastructure may be used to transport the LMA-discovery-related information between the MAG and the AAA server via one or more AAA brokers and/or AAA proxies. In this case, the MAG-to-AAA-server communication relies on the security properties of the intermediate AAA brokers and AAA proxies.
AAAインフラストラクチャは、1つ以上のAAAブローカーおよび/またはAAAプロキシを介して、MAGとAAAサーバーの間でLMAディスコベリー関連の情報を輸送するために使用できます。この場合、MAG-AAA-Server通信は、中間AAAブローカーとAAAプロキシのセキュリティプロパティに依存しています。
The authors would like to thank Julien Laganier, Christian Vogt, Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu, Jari Arkko, and Xiangsong Cui for their comments, extensive discussions, and suggestions on this document.
著者は、Julien Laganier、Christian Vogt、Ryuji Wakikawa、Frank Xia、Behcet Sarikaya、Charlie Perkins、Qin Wu、Jari Arkko、Xiangsong Cuiに、この文書に関する広範な議論、提案について感謝します。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 v10.0.0, December 2010.
[3GPP.23.003] 3GPP、「番号付け、アドレス指定、識別」、3GPP TS 23.003 V10.0.0、2010年12月。
[3GPP.24.008] 3GPP, "Mobile radio interface Layer 3 specification", 3GPP TS 24.008 v10.1.0, December 2010.
[3GPP.24.008] 3GPP、「モバイル無線インターフェイスレイヤー3仕様」、3GPP TS 24.008 V10.1.0、2010年12月。
[3GPP.24.302] 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks", 3GPP TS 24.302 v10.2.0, December 2010.
[3GPP.24.302] 3GPP、「非3GPPアクセスネットワークを介して3GPP進化したパケットコア（EPC）へのアクセス」、3GPP TS 24.302 V10.2.0、2010年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、Ed。、Kempf、J。、およびV. Devarapalli、ed。、「SplitシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5149] Korhonen、J.、Nilsson、U。、およびV. Devarapalli、「Mobile IPv6のサービス選択」、RFC 5149、2008年2月。
[RFC5779] Korhonen, J., Ed., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.
[RFC5779] Korhonen、J.、ed。、Bournelle、J.、Chowdhury、K.、Muhanna、A。、およびU. Meyer、「Diameter Proxy Mobile IPv6：Mobile Access Gateway and Local Mobility Anchor octionaction with Diameter Server」RFC 5779、2010年2月。
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010.
[RFC5949] Yokota、H.、Chowdhury、K.、Koodli、R.、Patil、B。、およびF. Xia、「Proxy Mobile IPv6の高速ハンドオーバー」、RFC 5949、2010年9月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
Authors' Addresses
著者のアドレス
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FIN-02600 Espoo Finland
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Fin-02600 Espoo Finland
EMail: jouni.nospam@gmail.com
Vijay Devarapalli Vasona Networks
Vijay Devarapalli Vasonaネットワーク
EMail: dvijay@gmail.com