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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 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. 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]の展開は、モバイルアクセスゲートウェイ（MAG）機能の恩恵を受けるダイナミックPMIPv6ドメインへの取り付け、モバイルノードのローカルモビリティアンカー（LMA）（MN）を発見することができます。ダイナミックディスカバリ機能の目的は、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）がドメインネームシステム（DNS）ルックアップに続いて、ネットワークアクセス認証の間、AAAインフラストラクチャから取得されます。
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をDNSルックアップに続いてネットワーク接続の際に下位層から受信したMNのアイデンティティから誘導されます。
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は別のMAGからのハンドオーバを実行すると、新しいMAGは古いMAGを使用していたのと同じLMAを使用する必要があります。これは、セッションの継続のために必要とされます。新しいMAGにおけるLMAの検出メカニズムは古いMAGによって使用されたのと同じ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.
このセクションでは、（例えば、[RFC5779]に記載されているように）AAAインフラストラクチャに接続するMAGを必要とLMA発見ソリューションを提示します。 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のパラメータのブートストラップは、MAGにAAAインフラストラクチャを介してポリシープロファイルのダウンロード（[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交換の成功の認証と認可の一部を終了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は、LMAのFQDNの代わりにIPアドレスを受信することです。 MAGは、LMAのIPアドレス（複数可）にFQDNを解決するために、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ドメイン内正確に一つの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アドレスは、リモートポリシーストアに更新する必要があります。それは新しい移動性セッションのためのMAGからの最初のPBUを受信すると例えば、LMAは、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のIDを取得します。 MAGは、（いくつかの事前に設定フォーマッティングルールに基づいて）一般的なLMA FQDNを構築するためのアイデンティティに埋め込まれた情報を使用して、DNSを使用してLMA IPアドレスを解決するために進むことができます。明らかに、MNのIDが一意にMNのためのLMAをホスティングして操作するエンティティを識別するために使用できる情報を埋め込む必要があります。そのようなMN IDの例としては、国際移動加入者識別（IMSI）とグローバル一意の一時的なユーザ機器アイデンティティ（GUTI）[3GPP.23.003]です。これらのMNのアイデンティティを一意のサブスクリプションが属する誰にオペレータを特定できる情報が含まれています。
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]のための「下層」であるような下位レイヤシグナリングの従来例であってもよいです。それが話をしたい応答者のアイデンティティ（すなわち、この場合はLMA）のかを指定するのIKEv2イニシエータ（この場合はすなわち、MN）で使用されているレスポンダ（IDR）ペイロード、 - のIKEv2は、IKEv2の識別を持っています。そして、ここで応答者のIDは、FQDNまたは（IPアドレスまたはFQDNをすることができIKEv2の識別ペイロードなど）LMAのIPアドレスである可能性があります。別の既存の例は、3GPP無線ネットワーク・アクセス・シグナリングに使用され、FQDNを運ぶことができるアクセスポイント名情報要素（IE APN）3GPP.24.008]です。しかし、一般的に、これはMNもLMA情報の発信元であることを意味します。以下のようなLMAの情報内容は、MNは、任意のLMAの機能と情報を関連付けない意味、MNに透明にすることができます。
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アドレスを解決するために進むことができます。そのようなサービスまたは外部ネットワーク名の一例は、特定のサービスまたは外部ネットワークへのアクセスを提供するオペレータの情報が含まれているアクセスポイント名（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を使用する必要がありますに接続されていることをすべてのMAGに接続します。 PMIPv6ドメインごとに1つだけLMAがあれば、何も問題はありません。 MAGとの間で利用可能なコンテキスト転送メカニズムがある場合、新しいMAGは古いMAGからLMA情報を知っています。そのような機構は、[RFC5949]に記載されています。 MN関連コンテキストがのMAG間で転送されていない場合は、新しいMAGに現在のLMA情報をお届けするための仕組みが必要です。
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アドレス（複数可）に解決されるかどうかを事前知識がありません。しかし、（例えばオペレータ間のローミングコンソーシアム協定など）の展開と展開関連の規制に応じて、状況はこの絶望的ではないかもしれません。例えば、MAGは、LMA-特定FQDNを合成することができるかもしれない（例えば、MNのアイデンティティまたはいくつかの他のサービス固有のパラメータのうち）。代替的に、MAGは、決定論的（MAGは、例えば、[SRVを介してLMAのFQDNのグループを学習したと仮定のLMAのプールから同じLMAを割り当てアルゴリズムへの入力として、（例えば）MN IDを使用することができRFC2782]クエリ）。これらのアプローチは、DNSは常にMAGに同じLMAアドレスを返すことを保証します。
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サーバ）に格納されています。初期アタッチメントは[RFC5779]を完了した後、LMA情報は、LMAによってポリシーストアに搬送されます。典型的には、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に接続する場合は、セクション2.1で説明したように、その後、AAAサーバは、認証と承認手続きの一環として、新しいMAGに既存のLMAの情報を提供します。
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発見のためのいくつかのソリューションのアプローチを議論しました。すべての議論溶液のアプローチは、実際には、ベースのPMIPv6仕様[RFC5213]は必要としないという追加機能やインフラストラクチャのサポートを必要とします。
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節でのソリューションは、MAGのいずれかLMA IPアドレスまたはFQDN LMAに提供することができるAAAインフラストラクチャの存在に依存しています。 AAA相互作用およびDNSの使用に関するシステム - アーキテクチャ固有の詳細が存在することができるが、動的LMA発見はaccess-と技術に依存しない方法で実施し、異種環境にわたって同じように動作することができます。したがって、AAAベースのLMAディスカバリソリューションを使用することは、このドキュメントで推奨されています。また、第4のガイダンス、[RFC1958]の段落4.1以下、のFQDNの使用は、AAAベースLMA発見ソリューションのコンテキストで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で詳細に説明されています。 MAGとLMAが同じPMIPv6ドメインに属しているので、[RFC5026]に記載されたリスクは、本書では大幅に緩和されます。 MAGクエリも同じPMIPv6ドメインの一部であるDNSサーバ。 MAGは、偽のDNSサーバからの偽のLMAのIPアドレスを取得した場合でも、さらに害はMAG以来防止され、LMAは、PMIPv6のシグナリングメッセージを交換する前に互いを認証する必要があります。 [RFC5213]はPMIPv6のシグナリングメッセージを保護するために互いに設定IPsecセキュリティアソシエーションを認証するMAGとLMAとの間のIKEv2の使用を指定します。
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インフラストラクチャは、一つ以上のAAAブローカーおよび/またはAAAプロキシを介してMAGとAAAサーバとの間のLMA-ディスカバリ関連情報を搬送するために使用することができます。この場合、MAGツーAAAサーバ通信は、中間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.
作者はこのドキュメントの彼らのコメント、広範な議論、および提案のためのジュリアンLaganier、クリスチャン・フォークト、隆次Wakikawa、フランク夏、ベーチェットSarikaya、チャーリー・パーキンス、秦呉、ヤリArkko、およびXiangsong崔に感謝したいと思います。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 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 TS 24.302 V10.2.0 2010年12月 "非3GPPアクセスネットワークを介して3GPP進化型パケットコア（EPC）へのアクセス"。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、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]ケント、S.、 "IPカプセル化セキュリティペイロード（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.、エド。、ケンプ、J.、およびV. Devarapalli、エド。、 "分割シナリオにおけるモバイル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.、ニルソン、U.、およびV. Devarapalli、 "モバイル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.、編、Bournelle、J.、チョードリ、K.、Muhanna、A.、およびU.マイヤー。 "直径プロキシモバイルIPv6：ダイアメータサーバとモバイル・アクセス・ゲートウェイとローカル・モビリティ・アンカー相互作用"、 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]横田、H.、チョードリ、K.、Koodli、R.、パティル、B.、およびF.夏、 "プロキシモバイル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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
Authors' Addresses
著者のアドレス
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FIN-02600 Espoo Finland
Jouni Korhonen、ノキアシーメンスネットワークスLinnoitustie 6 FIN-02600エスポー、フィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com
Vijay Devarapalli Vasona Networks
彼はdevarapalliネットワークを運転しました
EMail: dvijay@gmail.com
メールアドレス：dvijay@gmail.com