[要約] RFC 7156は、Proxy Mobile IPv6 Localized RoutingのためのDiameterサポートに関する規格です。このRFCの目的は、モバイルネットワークにおけるIPv6ローカライズルーティングのためのDiameterプロトコルの拡張を提供することです。
Internet Engineering Task Force (IETF) G. Zorn
Request for Comments: 7156 Network Zen
Category: Standards Track Q. Wu
ISSN: 2070-1721 Huawei
J. Korhonen
Broadcom
April 2014
Diameter Support for Proxy Mobile IPv6 Localized Routing
プロキシモバイルIPv6ローカライズドルーティングのDiameterサポート
Abstract
概要
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.
プロキシモバイルIPv6では、モバイルノード（MN）から接続されたモバイルアクセスゲートウェイ（MAG）によって受信されたパケットは、通常、ルーティングのためにローカルモビリティアンカー（LMA）にトンネリングされます。 「ローカライズされたルーティング」という用語は、LMAを使用せずに、MNのMAGとその対応ノード（CN）のMAGの間でパケットを直接ルーティングする方法を指します。プロキシモバイルIPv6展開では、セッションの承認を要求することにより、プロキシモバイルIPv6ドメイン内の2つのMAG間のローカライズされたルーティングセッションの確立を制御することが望ましい場合があります。このドキュメントでは、Diameterプロトコルを使用してこれを実現する方法を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7156.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7156で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Attribute Value Pair Used in This Document . . . . . . . . . 4
4.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 5
4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 5
4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 5
4.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 5
5. Example Signaling Flows for Localized Routing Service
Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobile Access Gateway (MAG) to optimize media delivery by locally routing packets from a Mobile Node (MN) to a Correspondent Node (CN) that is locally attached to an access link connected to the same Mobile Access Gateway, avoiding tunneling them to the Mobile Node's Local Mobility Anchor (LMA). This is referred to as "local routing" in RFC 5213 [RFC5213]. However, this mechanism is not applicable to the typical scenarios in which the MN and CN are connected to different MAGs and are registered to the same LMA or different LMAs. [RFC6279] takes those typical scenarios into account and defines the problem statement for PMIPv6 localized routing. Based on the scenarios A11, A12, and A21 described in [RFC6279], [RFC6705] specifies the PMIPv6 localized routing protocol that is used to establish a localized routing path between two Mobile Access Gateways in a PMIPv6 domain.
プロキシモバイルIPv6（PMIPv6）[RFC5213]を使用すると、モバイルアクセスゲートウェイ（MAG）は、モバイルノード（MN）から対応するノード（CN）にローカルに接続されたアクセスリンクに接続されているアクセスリンクにパケットをローカルにルーティングすることにより、メディア配信を最適化できます。同じモバイルアクセスゲートウェイ。モバイルノードのローカルモビリティアンカー（LMA）へのトンネルを回避します。これは、RFC 5213 [RFC5213]では「ローカルルーティング」と呼ばれています。ただし、このメカニズムは、MNとCNが異なるMAGに接続され、同じLMAまたは異なるLMAに登録される一般的なシナリオには適用されません。 [RFC6279]は、これらの典型的なシナリオを考慮に入れ、PMIPv6ローカライズドルーティングの問題ステートメントを定義しています。 [RFC6279]で説明されているシナリオA11、A12、およびA21に基づいて、[RFC6705]は、PMIPv6ドメインの2つのモバイルアクセスゲートウェイ間にローカライズされたルーティングパスを確立するために使用されるPMIPv6ローカライズされたルーティングプロトコルを指定します。
This document describes Authentication, Authorization, and Accounting (AAA) support using Diameter [RFC6733] for the authorization procedure between the PMIPv6 mobility entities (MAG or LMA) and a AAA server within a Proxy Mobile IPv6 domain for localized routing in the scenarios A11, A12, and A21 described in [RFC6279].
このドキュメントでは、Diameter [RFC6733]を使用した認証、承認、およびアカウンティング（AAA）のサポートについて説明します。シナリオA11でローカライズされたルーティングのために、プロキシモバイルIPv6ドメイン内のPMIPv6モビリティエンティティ（MAGまたはLMA）とAAAサーバーの間の承認手順について説明します。 [RFC6279]で説明されているA12、およびA21。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document addresses how to provide authorization information to the Mobile Node's MAG or LMA to enable localized routing and resolve the destination MN's MAG by means of interaction between the LMA and the AAA server. Figure 1 shows the reference architecture for Localized Routing Service Authorization. This reference architecture assumes that
このドキュメントでは、モバイルノードのMAGまたはLMAに認証情報を提供して、ローカライズされたルーティングを有効にし、LMAとAAAサーバー間の相互作用によって宛先MNのMAGを解決する方法について説明します。図1は、ローカライズされたルーティングサービス承認のリファレンスアーキテクチャを示しています。このリファレンスアーキテクチャでは、
o If the MN and CN belong to different LMAs, the MN and CN should share the same MAG (i.e., scenario A12 described in [RFC6279]), e.g., MN1 and CN2 in Figure 1 are attached to MAG1 and belong to LMA1 and LMA2, respectively. Note that LMA1 and LMA2 in Figure 1 are in the same provider domain (as described in [RFC6279]).
o MNとCNが異なるLMAに属している場合、MNとCNは同じMAGを共有する必要があります（つまり、[RFC6279]で説明されているシナリオA12）。たとえば、図1のMN1とCN2はMAG1に接続され、LMA1とLMA2に属しています。それぞれ。図1のLMA1とLMA2は同じプロバイダードメインにあることに注意してください（[RFC6279]で説明されています）。
o If the MN and CN are attached to different MAGs, the MN and CN should belong to the same LMA (i.e., scenario A21 described in [RFC6279]); for example, MN1 and CN3 in Figure 1 are attached to MAG1 and MAG3, respectively, but belong to LMA1.
o MNとCNが異なるMAGに接続されている場合、MNとCNは同じLMAに属している必要があります（つまり、[RFC6279]で説明されているシナリオA21）。たとえば、図1のMN1とCN3は、それぞれMAG1とMAG3に接続されていますが、LMA1に属しています。
o The MN and CN may belong to the same LMA and may be attached to the same MAG (i.e., scenario A11 described in [RFC6279]), e.g., MN1 and CN1 in Figure 1 are both attached to the MAG1 and belong to LMA1.
o MNとCNは同じLMAに属していても、同じMAGに接続されていてもかまいません（[RFC6279]で説明されているシナリオA11）。たとえば、図1のMN1とCN1はどちらもMAG1に接続されており、LMA1に属しています。
o The MAG and LMA support Diameter client functionality.
o MAGおよびLMAは、Diameterクライアント機能をサポートしています。
+---------+
+---------------------->| AAA & |
| +------>| Policy |
| | | Profile |
| Diameter +---------+
| |
| +--V-+ +----+
| +------->|LMA1| |LMA2|
| | +---++ +----+
| | | | |
Diameter | | +-------+---------
| | | | |
| PMIP | | \\
| | // // \\
| | // // \\
| | // // \\
| | | | |
| +---->+---------------+ +----+
| | MAG1 | |MAG3|
+-------->+---------------+ +----+
: : : :
+---+ +---+ +---+ +---+
|MN1| |CN1| |CN2| |CN3|
+---+ +---+ +---+ +---+
Figure 1: Localized Routing Service Authorization Reference Architecture
図1：ローカライズされたルーティングサービス承認のリファレンスアーキテクチャ
The interaction of the MAG and LMA with the AAA server according to the extension specified in this document is used to authorize the localized routing service.
このドキュメントで指定されている拡張子に基づくMAGおよびLMAとAAAサーバーの相互作用は、ローカライズされたルーティングサービスを承認するために使用されます。
This section describes Attribute Value Pairs (AVPs) and AVP values defined by this specification or reused from existing specifications in a PMIPv6-specific way.
このセクションでは、この仕様で定義された、または既存の仕様からPMIPv6固有の方法で再利用された属性値ペア（AVP）とAVP値について説明します。
The User-Name AVP (AVP Code 1) is defined in [RFC6733], Section 8.14. This AVP is used to carry the Mobile Node identifier (MN-Identifier) [RFC5213] in the Diameter AA-Request message [RFC7155] sent to the AAA server. The MN-Identifier is defined in PMIPv6 [RFC5213].
ユーザー名AVP（AVPコード1）は、[RFC6733]のセクション8.14で定義されています。このAVPは、AAAサーバーに送信されるDiameter AA-Requestメッセージ[RFC7155]でモバイルノード識別子（MN-Identifier）[RFC5213]を伝送するために使用されます。 MN-IdentifierはPMIPv6 [RFC5213]で定義されています。
The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in
[RFC5779], Section 5.2. This AVP is used to carry the Mobile Node's
IPv4 home address (IPv4-MN-HoA) in the Diameter AA-Request message
[RFC7155] sent to the AAA server. The IPv4-MN-HoA is defined in
[RFC5844].
The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779], Section 5.3. This AVP is used to carry the Mobile Node's home network prefix (MN-HNP) in the Diameter AA-Request [RFC7155] sent to the AAA server.
MIP6-Home-Link-Prefix AVP（AVPコード125）は、[RFC5779]のセクション5.3で定義されています。このAVPは、AAAサーバーに送信されるDiameter AA-Request [RFC7155]でモバイルノードのホームネットワークプレフィックス（MN-HNP）を伝送するために使用されます。
The MIP6-Feature-Vector AVP is defined in [RFC5447] and contains a 64-bit flags field used to indicate supported capabilities to the AAA server. This document allocates a new capability flag bit according to the IANA rules in RFC 5447 [RFC5447].
MIP6-Feature-Vector AVPは[RFC5447]で定義されており、サポートされている機能をAAAサーバーに示すために使用される64ビットのフラグフィールドが含まれています。このドキュメントは、RFC 5447 [RFC5447]のIANA規則に従って新しい機能フラグビットを割り当てます。
INTER_MAG_ROUTING_SUPPORTED (0x0002000000000000)
INTER_MAG_ROUTING_SUPPORTED（0x0002000000000000）
When set, this flag indicates support or authorization of Direct routing of IP packets between MNs anchored to different MAGs without involving any LMA.
このフラグが設定されている場合、LMAを使用せずに、異なるMAGにアンカーされたMN間のIPパケットの直接ルーティングのサポートまたは許可を示します。
During the network access authentication and authorization procedure [RFC5779], this flag is set by the MAG or LMA in the MIP6-Feature-Vector AVP included in the request to indicate to the home AAA server (HAAA) that inter-MAG direct routing may be provided to the mobile node identified by the User-Name AVP. By setting the INTER_MAG_ROUTING_SUPPORTED flag in the response, the HAAA indicates to the MAG or LMA that direct routing of IP packets between this mobile node and another node anchored to a different MAG is authorized. The MAG and the LMA set also the INTER_MAG_ROUTING_SUPPORTED flag of the MIP6-Feature-Vector AVP in AA-R sent to the HAAA for requesting authorization of inter-MAG direct routing between the mobile nodes identified in the request by two distinct instances of the User-Name AVP. If this bit is set in the returned MIP6-Feature-Vector AVP, the HAAA authorizes direct routing of packets between MNs anchored to different MAGs. When the INTER_MAG_ROUTING_SUPPORTED flag is cleared, either in request or response, it indicates that the procedures related to authorization of localized routing between MNs anchored to different MAGs is not supported or not authorized. MAG and LMA compliant to this specification MUST support this policy feature on a per-MN and per-subscription basis.
ネットワークアクセス認証および許可手順[RFC5779]の実行中、このフラグは、リクエストに含まれるMIP6-Feature-Vector AVPのMAGまたはLMAによって設定され、MAG間直接ルーティングが可能であることをホームAAAサーバー（HAAA）に示します。 User-Name AVPによって識別されるモバイルノードに提供されます。応答にINTER_MAG_ROUTING_SUPPORTEDフラグを設定することにより、HAAAはMAGまたはLMAに対して、このモバイルノードと別のMAGにアンカーされた別のノードとの間のIPパケットの直接ルーティングが許可されることを示します。 MAGとLMAは、ユーザーの2つの異なるインスタンスによる要求で識別されたモバイルノード間のMAG間直接ルーティングの承認を要求するために、HAAAに送信されるAA-RのMIP6-Feature-Vector AVPのINTER_MAG_ROUTING_SUPPORTEDフラグも設定します-名前AVP。返されたMIP6-Feature-Vector AVPでこのビットが設定されている場合、HAAAは、異なるMAGにアンカーされたMN間のパケットの直接ルーティングを許可します。リクエストまたはレスポンスでINTER_MAG_ROUTING_SUPPORTEDフラグがクリアされている場合、異なるMAGにアンカーされたMN間のローカライズされたルーティングの承認に関連する手順がサポートされていないか、承認されていないことを示します。この仕様に準拠するMAGおよびLMAは、MNごとおよびサブスクリプションごとにこのポリシー機能をサポートする必要があります。
Localized Routing Service Authorization can happen during the network access authentication procedure [RFC5779] before localized routing is initialized. In this case, the preauthorized pairs of LMA / prefix sets can be downloaded to Proxy Mobile IPv6 entities during the procedure from [RFC5779]. Localized routing can be initiated once the destination of a received packet matches one or more of the prefixes received during the procedure from [RFC5779].
ローカライズされたルーティングサービスの承認は、ローカライズされたルーティングが初期化される前のネットワークアクセス認証手順[RFC5779]で発生する可能性があります。この場合、事前承認されたLMA /プレフィックスセットのペアは、[RFC5779]からの手順中にプロキシモバイルIPv6エンティティにダウンロードできます。受信したパケットの宛先が、[RFC5779]からの手順中に受信した1つ以上のプレフィックスと一致すると、ローカライズされたルーティングを開始できます。
Figure 2 shows an example scenario in which MAG1 acts as a Diameter client, processing the data packet from MN1 to MN2 and requesting authorization of localized routing (i.e., MAG-Initiated LR authorization). In this example scenario, MN1 and MN2 are attached to the same MAG and anchored to the different LMAs (i.e., scenario A12 described in [RFC6279]). In this case, MAG1 knows that MN2 belongs to a different LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA1 and LMA2). In order to set up a localized routing path with MAG2, MAG1 acts as Diameter client and sends an AA-Request message to the AAA server. The message contains an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set, two instances of the User-Name AVP [RFC6733] containing the identifiers of MN1 and MN2. In addition, the message may contain either:
図2は、MAG1がDiameterクライアントとして機能し、MN1からMN2へのデータパケットを処理し、ローカライズされたルーティングの承認（つまり、MAGで開始されるLR承認）を要求するシナリオの例を示しています。このシナリオ例では、MN1とMN2は同じMAGに接続され、異なるLMAにアンカーされています（つまり、[RFC6279]で説明されているシナリオA12）。この場合、MAG1はMN2が別のLMAに属していることを認識しています（これは、MN1とMN2に対応するバインディングキャッシュエントリを検索し、LMA1とLMA2のアドレスを比較することで判断できます）。 MAG2でローカライズされたルーティングパスを設定するために、MAG1はDiameterクライアントとして機能し、AAリクエストメッセージをAAAサーバーに送信します。メッセージには、LOCAL_MAG_ROUTING_SUPPORTEDビット（[RFC5779]、セクション5.5）が設定されたMIP6-Feature-Vector（MFV）AVP [RFC5447]のインスタンス、MN1およびMN2。さらに、メッセージには次のいずれかが含まれる場合があります。
- an instance of the MIP6-Home-Link-Prefix AVP [RFC5779] carrying the MN1's IPv4 address;
- MN1のIPv4アドレスを運ぶMIP6-Home-Link-Prefix AVP [RFC5779]のインスタンス。
- an instance of the PMIP6-IPv4-Home-Address AVP [RFC5779] carrying the MN1's home network prefix (MN-HNP).
- MN1のホームネットワークプレフィックス（MN-HNP）を伝送するPMIP6-IPv4-Home-Address AVP [RFC5779]のインスタンス。
The AAA server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the AAA server responds with a AAA message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set indicating that direct routing of IP packets between MNs anchored to the same MAG is authorized. MAG1 then knows that the localized routing between MN1 and MN2 is allowed. Then, MAG1 sends the Request messages respectively to LMA1 and LMA2. The request message is the Localized Routing Initialization (LRI) message in Figure 2 and belongs to the Initial phase of the localized routing. LMA1 and LMA2 respond to MAG1 using the Localized Routing Acknowledge message (LRA in Figure 2) in accordance with [RFC6705].
AAAサーバーは、MN1とMN2がローカライズされたルーティングの使用を許可されているかどうかをチェックすることにより、ローカライズされたルーティングサービスを承認します。その場合、AAAサーバーは、MIP6-Feature-Vector（MFV）AVP [RFC5447]のインスタンスをカプセル化するAAAメッセージで応答し、MN間のIPパケットの直接ルーティングを示すLOCAL_MAG_ROUTING_SUPPORTEDビット（[RFC5779]、セクション5.5）を設定します同じMAGへのアンカーが許可されます。 MAG1は、MN1とMN2の間のローカライズされたルーティングが許可されていることを認識します。次に、MAG1は要求メッセージをそれぞれLMA1とLMA2に送信します。要求メッセージは、図2のLocalized Routing Initialization（LRI）メッセージであり、ローカライズされたルーティングの初期フェーズに属します。 LMA1とLMA2は、[RFC6705]に従って、Localized Routing Acknowledgeメッセージ（図2のLRA）を使用してMAG1に応答します。
In case of LRA_WAIT_TIME expiration [RFC6705], MAG1 should ask for authorization of localized routing again according to the procedure described above before the LRI is retransmitted up to a maximum of LRI_RETRIES.
LRA_WAIT_TIMEの有効期限[RFC6705]の場合、MAG1は、LRIが最大LRI_RETRIESまで再送信される前に、上記の手順に従ってローカライズされたルーティングの承認を再度要求する必要があります。
+---+ +---+ +----+ +----+ +---+ +----+
|MN2| |MN1| |MAG1| |LMA1| |AAA| |LMA2|
+-|-+ +-+-+ +-+--+ +-+--+ +-+-+ +-+--+
| | Anchored | | |
o-----------------------------------------------o
| | Anchored | | |
| o------------------o | |
| Data[MN1->MN2] | | |
| |------->| | | |
| | | AA-Request(MFV, MN1,MN2) |
| | |--------------------> | |
| | | AA-Answer(MFV) | |
| | |<-------------------- | |
| | | LRI | | |
| | |-------->| | |
| | | | LRI | |
| | |----------------------------->|
| | | LRA | | |
| | |<--------| | |
| | | | LRA | |
| | |<-----------------------------|
Figure 2: MAG-Initiated Localized Routing Authorization in A12
図2：A12でのMAGによって開始されるローカライズされたルーティング許可
Figure 3 shows the second example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to a different MAG and anchored to the same LMA (i.e., A21 described in [RFC6279]), LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of the LMA corresponding to MN1 and LMA corresponding to MN2). In contrast with the signaling flow shown in Figure 2, it is LMA1 instead of MAG1 that initiates the setup of the localized routing path.
図3は、LMA1がDiameterクライアントとして機能し、MN2からMN1へのデータパケットを処理し、ローカライズされたルーティングの承認を要求する2番目のシナリオ例を示しています。このシナリオでは、MN1とMN2は異なるMAGに接続され、同じLMA（[RFC6279]で説明されているA21）にアンカーされています。LMAは、MN1とMN2が同じLMAに属していることを認識しています（これは、 MN1およびMN2に対応するキャッシュエントリをバインドし、MN1に対応するLMAとMN2に対応するLMAのアドレスを比較します。図2に示すシグナリングフローとは対照的に、ローカライズされたルーティングパスのセットアップを開始するのは、MAG1ではなくLMA1です。
The Diameter client in LMA1 sends an AA-Request message to the AAA server. The message contains an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported and two instances of the User-Name AVP [RFC6733] containing identifiers of MN1 and MN2. The AAA server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the AAA server responds with an AA-Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating that direct routing of IP packets between MNs anchored to different MAGs is authorized. LMA1 then knows the localized routing is allowed. In a successful case, LMA1 responds to MAG1 in accordance with [RFC6705].
LMA1のDiameterクライアントは、AA-RequestメッセージをAAAサーバーに送信します。メッセージには、異なるMAGにアンカーされたMN間のIPパケットの直接ルーティングがサポートされ、ユーザー名の2つのインスタンスがサポートされていることを示すINTER_MAG_ROUTING_SUPPORTEDビット（セクション4.5）が設定されたMIP6-Feature-Vector（MFV）AVP [RFC5447]のインスタンスが含まれますMN1およびMN2の識別子を含むAVP [RFC6733]。 AAAサーバーは、MN1とMN2がローカライズされたルーティングの使用を許可されているかどうかをチェックすることにより、ローカライズされたルーティングサービスを承認します。その場合、AAAサーバーは、MIP6-Feature-Vector（MFV）AVP [RFC5447]のインスタンスをカプセル化するAA-Answerメッセージで応答し、INTER_MAG_ROUTING_SUPPORTEDビット（セクション4.5）を設定して、MN間のIPパケットの直接ルーティングがアンカーされていることを示します。異なるMAGが許可されます。 LMA1は、ローカライズされたルーティングが許可されていることを認識します。成功した場合、LMA1は[RFC6705]に従ってMAG1に応答します。
In the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask for authorization of localized routing again according to the procedure described above before the LRI is retransmitted up to a maximum of LRI_RETRIES.
LRA_WAIT_TIMEの有効期限[RFC6705]の場合、LMA1は、LRIが最大LRI_RETRIESまで再送信される前に、上記の手順に従ってローカライズされたルーティングの承認を再度要求する必要があります。
+---+ +----+ +----+ +---+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+
| | | Anchored | |
| Anchored o-------------------+--------o
o--------+-------o Data[MN2->MN1] | |
| | |<----- | | |
| | |AA-Request(MFV,MN1,MN2) |
| | |--------->| | |
| | |AA-Answer(MFV) | |
| | LRI |<---------| | |
| |<------| LRI | |
| | LRA |------------------>| |
| |------>| LRA | |
| | |<------------------| |
Figure 3: LMA-Initiated Localized Routing Authorization in A21
図3：A21でLMAが開始したローカライズされたルーティング許可
Figure 4 shows another example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to the same MAG and anchored to the same LMA (i.e., A11 described in [RFC6279]), the LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA corresponding to MN1 and LMA corresponding to MN2).
図4は、LMA1がDiameterクライアントとして機能し、MN2からMN1へのデータパケットを処理し、ローカライズされたルーティングの承認を要求する別のシナリオ例を示しています。このシナリオでは、MN1とMN2は同じMAGに接続され、同じLMA（[RFC6279]で説明されているA11）にアンカーされています。LMAは、MN1とMN2が同じLMAに属していることを認識しています（これは、 MN1とMN2に対応するバインディングキャッシュエントリ、およびMN1に対応するLMAとMN2に対応するLMAのアドレスの比較。
The Diameter client in LMA1 sends an AA-Request message to the AAA server. The message contains an instance of the MIP6-Feature-Vector AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit set and two instances of the User-Name AVP [RFC6733] containing the identifiers MN1 and MN2. The AAA server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the AAA server responds with an AA-Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set indicating that direct routing of IP packets between MNs anchored to the same MAG is authorized. LMA1 then knows the localized routing is allowed and responds to MAG1 for localized routing in accordance with [RFC6705].
LMA1のDiameterクライアントは、AA-RequestメッセージをAAAサーバーに送信します。メッセージには、LOCAL_MAG_ROUTING_SUPPORTEDビットが設定されたMIP6-Feature-Vector AVP [RFC5447]のインスタンスと、識別子MN1およびMN2を含むユーザー名AVP [RFC6733]の2つのインスタンスが含まれます。 AAAサーバーは、MN1とMN2がローカライズされたルーティングの使用を許可されているかどうかをチェックすることにより、ローカライズされたルーティングサービスを承認します。その場合、AAAサーバーはMIP6-Feature-Vector（MFV）AVP [RFC5447]のインスタンスをカプセル化したAA-Answerメッセージで応答し、IPパケットの直接ルーティングを示すLOCAL_MAG_ROUTING_SUPPORTEDビット（[RFC5779]、セクション5.5）を設定します同じMAGにアンカーされたMN間が許可されます。 LMA1はローカライズされたルーティングが許可されていることを認識し、[RFC6705]に従ってローカライズされたルーティングのためにMAG1に応答します。
In the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask for authorization of localized routing again according to the procedure described above before the LRI is retransmitted up to a maximum of LRI_RETRIES.
LRA_WAIT_TIMEの有効期限[RFC6705]の場合、LMA1は、LRIが最大LRI_RETRIESまで再送信される前に、上記の手順に従ってローカライズされたルーティングの承認を再度要求する必要があります。
+---+ +---+ +----+ +----+ +---+
|MN2| |MN1| |MAG1| |LMA1| |AAA|
+-+-+ +-+-+ +-+--+ +-+--+ +-|-+
| | Anchored | |
o-----------------------o |
| | Anchored | |
| o--------+-------o Data[MN2->MN1]
| | | |<----- |
| | | |AA-Request(MFV,MN1,MN2)
| | | |--------->|
| | | |AA-Answer(MFV)
| | | LRI |<---------|
| | |<------| |
| | | LRA | |
| | |------>| |
Figure 4: LMA-Initiated Localized Routing Authorization in A11
図4：A11でLMAによって開始されたローカライズされたルーティング許可
The security considerations for the Diameter Network Access Server Requirements (NASREQ) [RFC7155] and Diameter Proxy Mobile IPv6 [RFC5779] applications are also applicable to this document.
Diameterネットワークアクセスサーバー要件（NASREQ）[RFC7155]およびDiameterプロキシモバイルIPv6 [RFC5779]アプリケーションのセキュリティに関する考慮事項も、このドキュメントに適用されます。
The service authorization solicited by the MAG or the LMA relies upon the existing trust relationship between the MAG/LMA and the AAA server.
MAGまたはLMAによって要求されたサービス許可は、MAG / LMAとAAAサーバー間の既存の信頼関係に依存します。
An authorized MAG could, in principle, track the movement of any participating mobile nodes at the level of the MAG to which they are anchored. If such a MAG were compromised, or under the control of a bad actor, then such tracking could represent a privacy breach for the set of tracked mobile nodes. In such a case, the traffic pattern from the compromised MAG might be notable, so monitoring for, e.g., excessive queries from MAGs, might be worthwhile.
認可されたMAGは、原則として、参加しているモバイルノードがアンカーされているMAGのレベルで、そのモバイルノードの動きを追跡できます。そのようなMAGが危険にさらされた場合、または悪いアクターの制御下にある場合、そのような追跡は、追跡されたモバイルノードのセットのプライバシー侵害を表す可能性があります。そのような場合、侵害されたMAGからのトラフィックパターンが顕著になる可能性があるため、MAGからの過剰なクエリなどを監視することは価値があります。
This specification defines a new value in the "Mobility Capability Registry" [RFC5447] for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (see Section 4.4).
この仕様は、MIP6-Feature-Vector AVP：INTER_MAG_ROUTING_SUPPORTED（セクション4.4を参照）で使用するための「モビリティ機能レジストリ」[RFC5447]の新しい値を定義します。
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document.
Paulo Loureiro、Jinwei Xia、Yungui Wangはすべて、このドキュメントの初期バージョンに貢献しました。
The authors would like to thank Lionel Morand, Marco Liebsch, Carlos Jesus Bernardos Cano, Dan Romascanu, Elwyn Davies, Basavaraj Patil, Ralph Droms, Stephen Farrel, Robert Sparks, Benoit Claise, and Abhay Roy for their valuable comments and suggestions on this document.
著者は、この文書に関する貴重なコメントと提案をしてくれたLionel Morand、Marco Liebsch、Carlos Jesus Bernardos Cano、Dan Romascanu、Elwyn Davies、Basavaraj Patil、Ralph Droms、Stephen Farrel、Robert Sparks、Benoit Claise、Abhay Royに感謝します。 。
[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月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Leunji、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile Ipp 1」、Rfak 2、2009年8月。
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
[RFC5447] Korhonen、J.、Bournelle、J.、Tschofenig、H.、Perkins、C。、およびK. Chowdhury、「Diameter Mobile IPv6：Support for Network Access Server to Diameter Server Interaction」、RFC 5447、2009年2月。
[RFC5779] Korhonen, J., 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.、Chowdhury、K.、Muhanna、A。、およびU. Meyer、「Diameter Proxy Mobile IPv6：Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server」、RFC 5779、 2010年2月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012.
[RFC6705]クリシュナン、S.、Koodli、R.、Loureiro、P.、Wu、Q。、およびA. Dutta、「プロキシモバイルIPv6のローカライズされたルーティング」、RFC 6705、2012年9月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameter Base Protocol」、RFC 6733、2012年10月。
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, April 2014.
[RFC7155] Zorn、G。、編、「Diameterネットワークアクセスサーバーアプリケーション」、RFC 7155、2014年4月。
[RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011.
[RFC6279] Liebsch、M.、Jeong、S。、およびQ. Wu、「Proxy Mobile IPv6（PMIPv6）Localized Routing Problem Statement」、RFC 6279、2011年6月。
Authors' Addresses
著者のアドレス
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na、Bangkok 10260 Thailand
Phone: +66 (0) 87-040-4617
EMail: glenzorn@gmail.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQはテクノロジー株式会社です。101ソフトウェアアベニュー、Y U塗装区NaN京、江蘇210012中国
Phone: +86-25-56623633
EMail: bill.wu@huawei.com
Jouni Korhonen Broadcom Porkkalankatu 24 FIN-00180 Helsinki Finland
Jouni Korhonen Broadcom Porkkalankatu 24 FIN-00180ヘルシンキフィンランド
EMail: jouni.nospam@gmail.com