[要約] RFC 8885は、分散モビリティ管理のためのProxy Mobile IPv6拡張機能に関する規格です。このRFCの目的は、モバイルネットワークにおけるノードの移動を効率的に管理するための標準化とガイドラインを提供することです。
Internet Engineering Task Force (IETF) CJ. Bernardos
Request for Comments: 8885 A. de la Oliva
Category: Experimental UC3M
ISSN: 2070-1721 F. Giust
Athonet
JC. Zúñiga
SIGFOX
A. Mourad
InterDigital
October 2020
Proxy Mobile IPv6 Extensions for Distributed Mobility Management
分散モビリティ管理のためのプロキシモバイルIPv6拡張
Abstract
概要
Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.
分散モビリティ管理ソリューションは、トラフィックが最適に配布され、中央展開されたアンカーがIPモビリティサポートを提供するために依存していないようにネットワークを設定することを可能にする。
There are many different approaches to address Distributed Mobility Management -- for example, extending network-based mobility protocols (like Proxy Mobile IPv6) or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways.
分散モビリティ管理に対処するための多くの異なるアプローチがあります - たとえば、ネットワークベースのモビリティプロトコル（Proxy Mobile IPv6など）またはクライアントベースのモビリティプロトコル（モバイルIPv6と同様に）を拡張します。この文書は前のアプローチに従い、プロキシモバイルIPv6に基づく解決策を提案し、その中でモビリティセッションが最後のIPホップルータ（Mobility AnchorおよびAccess Routerと呼ばれます）に固定されます。Mobility AnchorおよびAccess Routerは、プレフィックスごとにローカルモビリティアンカーまたはモビリティアクセスゲートウェイとして動作することもできる拡張アクセスルータです。この文書は、さまざまな分散ゲートウェイで同時固定数のいくつかの流れを効果的にサポートするために必要な拡張機能に焦点を当てています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8885.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8885で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Terminology
3. PMIPv6 DMM Extensions
3.1. Initial Registration
3.2. The CMD as PBU/PBA Relay
3.3. The CMD as MAAR Locator
3.4. The CMD as PBU/PBA Proxy
3.5. De-registration
3.6. Retransmissions and Rate Limiting
3.7. The Distributed Logical Interface (DLIF) Concept
4. Message Format
4.1. Proxy Binding Update
4.2. Proxy Binding Acknowledgement
4.3. Anchored Prefix Option
4.4. Local Prefix Option
4.5. Previous MAAR Option
4.6. Serving MAAR Option
4.7. DLIF Link-Local Address Option
4.8. DLIF Link-Layer Address Option
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
The Distributed Mobility Management (DMM) paradigm aims at minimizing the impact of currently standardized mobility management solutions, which are centralized (at least to a considerable extent) [RFC7333].
分散型モビリティ管理（DMM）パラダイムは、集中型の（少なくともかなりの範囲に）集中化されている現在（少なくともかなりの範囲）の影響を最小限に抑えることを目的としています[RFC7333]。
The two most relevant examples of current IP mobility solutions are Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 (PMIPv6) [RFC5213]. These solutions offer mobility support at the cost of handling operations at a cardinal point (i.e., the mobility anchor) and burdening it with data forwarding and control mechanisms for a large number of users. The mobility anchor is the home agent for Mobile IPv6 and the local mobility anchor for PMIPv6. As stated in [RFC7333], centralized mobility solutions are prone to several problems and limitations: longer (sub-optimal) routing paths, scalability problems, signaling overhead (and most likely a longer associated handover latency), more complex network deployment, higher vulnerability due to the existence of a potential single point of failure, and lack of granularity of the mobility management service (i.e., mobility is offered on a per-node basis because it is not possible to define finer granularity policies, for example, on a per-application basis).
現在のIPモビリティソリューションの2つの最も関連のある例は、モバイルIPv6 [RFC6275]とプロキシモービルIPv6（PMIPv6）[RFC5213]です。これらの解決策は、枢機卿の点（すなわち、モビリティアンカー）での操作コストでモビリティサポートを提供し、多数のユーザのためのデータ転送および制御メカニズムでそれを負担する。モビリティアンカーは、モバイルIPv6用のホームエージェントとPMIPv6のローカルモビリティアンカーです。 [RFC7333]に記載されているように、集中型モビリティソリューションはいくつかの問題と制限事項を実行しやすくなります。潜在的な障害点の存在、およびモビリティ管理サービスの粒度の欠如のために（すなわち、粒度のより細かい粒度ポリシーを定義することは不可能であるため、例えば、毎回モビリティ単位で提供される） - アプリケーションベース）。
The purpose of DMM is to overcome the limitations of the traditional centralized mobility management [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed bringing the mobility anchor closer to the mobile node (MN). Following this idea, the central anchor is moved to the edge of the network and is deployed in the default gateway of the MN. That is, the first elements that provide IP connectivity to a set of MNs are also the mobility managers for those MNs. In this document, we call these entities Mobility Anchors and Access Routers (MAARs).
DMMの目的は、従来の集中型モビリティ管理の制限を克服することが[RFC7333] [RFC7429];DMMソリューションの背後にある主な概念は、動いているモビリティアンカーをモバイルノード（MN）に近づくことが実際にあります。この考えに続いて、中央アンカーはネットワークの端に移動され、MNのデフォルトゲートウェイに展開されます。つまり、MNのセットにIP接続を提供する最初の要素も、それらのMNのモビリティマネージャです。このドキュメントでは、これらのエンティティMobility AnchorsとAccess Routers（Maars）と呼びます。
This document focuses on network-based DMM; hence, the starting point is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is handled by the network without the MN's involvement. But differently from PMIPv6, when the MN moves from one access network to another, the router anchoring the MN's address may change, hence requiring signaling between the anchors to retrieve the MN's previous location(s). Also, a key aspect of network-based DMM is that a prefix pool belongs exclusively to each MAAR in the sense that those prefixes are assigned by the MAAR to the MNs attached to it and are routable at that MAAR. Prefixes are assigned to MNs attached to a MAAR at that time, but remain with those MNs as mobility occurs, remaining always routable at that MAAR as well as towards the MN itself.
この文書はネットワークベースのDMMに焦点を当てています。したがって、出発点はPMIPv6を分散的に作動させています[RFC7429]。MOBILITYは、MNの関与なしにネットワークによって処理されます。しかし、PMIPv6とは異なり、Mnが1つのアクセスネットワークから別のアクセスネットワークに移動すると、MNのアドレスを固定するルータが変更され、したがって、MNの前の位置を検索するためにアンカー間のシグナリングが必要になる可能性がある。また、ネットワークベースのDMMの重要な側面は、プレフィックスプールがそれに接続されているMAARによってマーによって割り当てられ、そのMaarでルーティング可能であるという意味で、プレフィックスプールは各Maarに属していることです。その時点でMAARに接続されているMNにプレフィックスが割り当てられていますが、モビリティが発生するにつれて、そのMAARでは常にMN自体に向かってルーティング可能なままになります。
We consider partially distributed schemes, where only the data plane is distributed among access routers similar to mobile access gateways (MAGs), whereas the control plane is kept centralized towards a cardinal node (used as an information store), which is discharged from any route management and MN's data forwarding tasks.
私達は部分的に分散されたスキームを検討します。ここで、データプレーンのみがモバイルアクセスゲートウェイ（MAG）と同様にアクセスルータの間に分散されているのに対し、制御プレーンは任意のルートから放電されている枢機系ノード（情報ストアとして使用されている）に向かって集中化されています。管理とMNのデータ転送タスク
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The following terms used in this document are defined in the PMIPv6 specification [RFC5213]:
この文書で使用されている以下の用語は、PMIPv6仕様書[RFC5213]に定義されています。
BCE: Binding Cache Entry
BCE：バインディングキャッシュエントリ
LMA: Local Mobility Anchor
LMA：ローカルモビリティアンカー
MAG: Mobile Access Gateway
MAG：モバイルアクセスゲートウェイ
MN: Mobile Node
MN：モバイルノード
P-CoA: Proxy Care-of Address
P-CoA：プロキシケアアドレス
PBA: Proxy Binding Acknowledgement
PBA：プロキシバインディング承認
PBU: Proxy Binding Update
PBU：プロキシバインディングアップデート
The following terms used in this document are defined in the Mobile IPv6 (MIPv6) specification [RFC6275]:
この文書で使用されている以下の用語は、モバイルIPv6（MIPv6）仕様[RFC6275]で定義されています。
CN: Correspondent Node
CN：コレスポンデントノード
The following terms are used in this document:
このドキュメントでは、以下の用語が使用されます。
Home Control-Plane Anchor (Home-CPA or H-CPA): The Home-CPA function hosts the MN's mobility session. There can be more than one mobility session for an MN, and those sessions may be anchored on the same or different Home-CPAs. The Home-CPA will interface with the Home-DPA for managing the forwarding state.
Home Control-Plane Anchor（Home-CPAまたはH-CPA）：Home-CPA関数はMNのモビリティセッションをホストします。MNに対して複数のモビリティセッションがある可能性があり、それらのセッションは同じまたは異なるHome-CPAに固定される可能性があります。Home-CPAは、転送状態を管理するためにHome-DPAとインタフェースします。
Home Data Plane Anchor (Home-DPA or H-DPA): The Home-DPA is the topological anchor for the MN's IP addresses and/or prefixes. The Home-DPA is chosen by the Home-CPA on a session basis. The Home-DPA is in the forwarding path for all the MN's IP traffic.
ホームデータプレーンアンカー（Home-DPAまたはH-DPA）：HOME-DPAは、MNのIPアドレスおよび/またはプレフィックスのトポロジーアンカーです。HOME-DPAは、セッションベースでホームCPAによって選択されます。HOME-DPAはすべてのMNのIPトラフィックの転送パスにあります。
Access Control Plane Node (Access-CPN or A-CPN): The Access-CPN is responsible for interfacing with the MN's Home-CPA and the Access-DPN. The Access-CPN has a protocol interface to the Home-CPA.
アクセス制御プレーンノード（ACCESS-CPNまたはA-CPN）：ACCESS-CPNは、MNのホームCPAとACCESS-DPNとのインターフェイスを担当します。access-CPNには、ホームCPAへのプロトコルインターフェイスがあります。
Access Data Plane Node (Access-DPN or A-DPN): The Access-DPN function is hosted on the first-hop router where the MN is attached. This function is not hosted on a Layer 2 (L2) bridging device such as an eNode(B) or Access Point.
アクセスデータプレーンノード（ACCESS-DPNまたはA-DPN）：ACCESS-DPN機能は、MNが接続されているファーストホップルータでホストされています。この機能は、eノード（B）やアクセスポイントなどのレイヤ2（L2）ブリッジングデバイスではホストされていません。
The following terms are defined and used in this document:
この文書では、次の用語が定義され使用されています。
MAAR (Mobility Anchor and Access Router): First-hop router where the MNs attach. It also plays the role of mobility manager for the IPv6 prefixes it anchors, running the functionalities of PMIP's MAG and LMA. Depending on the prefix, it plays the role of Access-DPN, Home-DPA, and Access-CPN.
Maar（モビリティアンカーとアクセスルータ）：MNSが添付されているファーストホップルータ。また、PMIPのMAGとLMAの機能性を実行して、IPv6プレフィックスITアンカーのMobility Managerの役割も果たします。接頭辞に応じて、Access-DPN、Home-DPA、およびACCESS-CPNの役割が再生されます。
CMD (Central Mobility Database): The node that stores the BCEs allocated for the MNs in the mobility domain. It plays the role of Home-CPA.
CMD（Central Mobility Database）：モビリティドメイン内のMNSに割り当てられたBCEを格納するノード。Home-CPAの役割を果たします。
P-MAAR (Previous MAAR): When an MN moves to a new point of attachment, a new MAAR might be allocated as its anchor point for future IPv6 prefixes. The MAAR that served the MN prior to new attachment becomes the P-MAAR. It is still the anchor point for the IPv6 prefixes it had allocated to the MN in the past and serves as the Home-DPA for flows using these prefixes. There might be several P-MAARs serving an MN in cases when the MN is frequently switching points of attachment while maintaining long-lasting flows.
P-Maar（前のMaar）：MNが新しい添付ファイルに移動すると、新しいMaarが将来のIPv6プレフィックスのアンカーポイントとして割り当てられます。新しい添付ファイルの前にMNを提供したMaarはP-Maarになります。これは、過去にMNに割り当てられていたIPv6プレフィックスのアンカーポイントです。これらのプレフィックスを使用してフローのホームDPAとして機能します。Mnが頻繁に取り付けられているときにMnが頻繁にスイッチングされている場合には、長期間の流れを維持しながらMnを兼ねたP - Maarsがいくつかあるかもしれない。
S-MAAR (Serving MAAR): The MAAR to which the MN is currently attached. Depending on the prefix, it plays the role of Access-DPN, Home-DPA, and Access-CPN.
S-Maar（サービングマール）：MNが現在接続されているMaar。接頭辞に応じて、Access-DPN、Home-DPA、およびACCESS-CPNの役割が再生されます。
Anchoring MAAR: A MAAR anchoring an IPv6 prefix used by an MN.
Anchoring Maar：MAAR Anchoring MNで使用されるIPv6プレフィックス。
DLIF (Distributed Logical Interface): It is a logical interface at the IP stack of the MAAR. For each active prefix used by the MN, the S-MAAR has a DLIF configured (associated with each MAAR still anchoring flows). In this way, an S-MAAR exposes itself towards each MN as multiple routers, one as itself and one per P-MAAR.
DLIF（分散論理インタフェース）：MaarのIPスタックの論理インターフェイスです。MNによって使用されるアクティブなプレフィックスごとに、S-MaarはDLIFが構成されています（各Maarには依然として固定フローに関連付けられています）。このようにして、S-Maarはそれ自体のものとP-Maarあたり1つずつ、複数のルーターとして各MNに向かってそれ自体を露出させます。
The solution consists of decoupling the entities that participate in the data and the control planes: the data plane becomes distributed and managed by the MAARs near the edge of the network, while the control plane, besides those on the MAARs, relies on a central entity called the Central Mobility Database (CMD). In the proposed architecture, the hierarchy present in PMIPv6 between LMA and MAG is preserved but with the following substantial variations:
このソリューションは、データと制御プレーンに参加するエンティティを切り離すことからなります。データプレーンはネットワークの端の近くのマーアによって分散され管理されます。中央モビリティデータベース（CMD）と呼ばれます。提案されたアーキテクチャでは、LMAとMAGの間のPMIPv6に存在する階層は保持されますが、次の実質的なバリエーションがあります。
* The LMA is discharged from the data forwarding role; only the Binding Cache and its management operations are maintained. Hence, the LMA is renamed as "CMD", which is therefore a Home-CPA. Also, the CMD is able to send and parse both PBU and PBA messages.
* LMAはデータ転送役割から放電されます。バインディングキャッシュとその管理操作のみが維持されます。したがって、LMAは「CMD」と改名され、したがってホームCPAである。また、CMDはPBUメッセージとPBAメッセージの両方を送信および解析できます。
* The MAG is enriched with the LMA functionalities, hence the name Mobility Anchor and Access Router (MAAR). It maintains a local Binding Cache for the MNs that are attached to it, and it is able to send and parse PBU and PBA messages.
* MAGはLMA機能、したがって名前モビリティアンカーとアクセスルータ（Maar）と充実しています。それはそれに添付されているMNのためのローカルバインディングキャッシュを維持し、PBUメッセージとPBAメッセージを送信および解析することができます。
* The Binding Cache will be extended to include information regarding P-MAARs where the MN was anchored and still retains active data sessions.
* バインディングキャッシュは、MNが固定されており、依然としてアクティブなデータセッションを保持しているP-Maarsに関する情報を含むように拡張されます。
* Each MAAR has a unique set of global prefixes (which are configurable) that can be allocated by the MAAR to the MNs but must be exclusive to that MAAR, i.e., no other MAAR can allocate the same prefixes.
* 各Maarには、MAARがMNSに割り当てることができるが、そのMaarに排他的でなければならないというユニークなグローバルプレフィックスのセットがありますが、そのMaarは同じプレフィックスを割り当てることはできません。
The MAARs leverage the CMD to access and update information related to the MNs, which is stored as mobility sessions; hence, a centralized node maintains a global view of the network status. The CMD is queried whenever an MN is detected joining/leaving the mobility domain. It might be a fresh attachment, a detachment, or a handover, but as MAARs are not aware of past information related to a mobility session, they contact the CMD to retrieve the data of interest and eventually take the appropriate action. The procedure adopted for the query and the message exchange sequence might vary to optimize the update latency and/or the signaling overhead. Here, one method for the initial registration and three different approaches for updating the mobility sessions using PBUs and PBAs are presented. Each approach assigns a different role to the CMD:
MAARSは、MNSに関連する情報をアクセスして更新するためにCMDを活用します。これは、モビリティセッションとして格納されています。したがって、集中型ノードは、ネットワークステータスのグローバルビューを維持します。MNがモビリティドメインを接合/離して検出されたときはいつでもCMDが照会されます。それは新鮮な添付ファイル、分離、またはハンドオーバであるかもしれませんが、Maarsはモビリティセッションに関連する過去の情報を認識していないので、彼らは関心のあるデータを取得し、最終的に適切な行動を取得します。クエリとメッセージ交換シーケンスに採用された手順は、更新待ち時間および/またはシグナリングのオーバーヘッドを最適化するためにさまざまです。ここでは、PBUとPBAを用いてモビリティセッションを更新するための初期登録と3つの異なるアプローチの1つの方法が提示されている。各アプローチはCMDに異なる役割を割り当てます。
* The CMD is a PBU/PBA relay;
* CMDはPBU / PBAリレーです。
* The CMD is only a MAAR locator;
* CMDはMaar Locatorのみです。
* The CMD is a PBU/PBA proxy.
* CMDはPBU / PBAプロキシです。
The solution described in this document allows per-prefix anchoring decisions -- for example, to support the anchoring of some flows at a central Home-DPA (like a traditional LMA) or to enable an application to switch to the locally anchored prefix to gain route optimization, as indicated in [RFC8563]. This type of per-prefix treatment would potentially require additional extensions to the MAARs and signaling between the MAARs and the MNs to convey the per-flow anchor preference (central, distributed), which are not covered in this document.
この文書に記載されているソリューションは、プレフィックスごとの固定決定を可能にします。[RFC8563]に示されているように、ルート最適化。このタイプの接頭辞治療は、この文書ではカバーされていないフローのアンカー優先権（中央、分散）を伝達するために、MaarsとMNSの間のシグナリングおよびMNSの間のシグナリングを潜在的に必要とする可能性があります。
Note that an MN may move across different MAARs, which might result in several P-MAARs existing at a given moment of time, each of them anchoring a different prefix used by the MN.
MNは異なるMaarsを横切って移動することができ、それは所与の時間に存在するいくつかのPマーアーが存在する可能性があるので、それぞれがMnによって使用される異なる接頭辞を固定する。
Initial registration is performed when an MN attaches to a network for the first time (rather than attaching to a new network after moving from a previous one).
初期登録は、MNが初めてネットワークに接続したとき（前の1から移動した後に新しいネットワークに接続するのではなく）実行されます。
In this description (shown in Figure 1), it is assumed that:
この説明（図1に示す）では、次のように想定されています。
1. The MN is attaching to MAAR1.
1. MnはMaar1に取り付けられています。
2. The MN is authorized to attach to the network.
2. MNはネットワークに接続する権限があります。
Upon MN attachment, the following operations take place:
MNの添付ファイルに、次の操作が行われます。
1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to the MN (Pref1). It also stores this prefix (Pref1) in the locally allocated temporary BCE.
1. MAAR1は、独自のプレフィックスプールからMN（Pref1）にグローバルIPv6プレフィックスを割り当てます。ローカルに割り当てられた一時的なBCEにこのプレフィックス（Pref1）も格納されています。
2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the CMD.
2. MAAR1は、PREF1とMNのMN-IDとPBU [RFC5213]をCMDに送信します。
3. Since this is an initial registration, the CMD stores a BCE containing the MN-ID, Pref1, and MAAR1's address (as a Proxy-CoA) as the primary fields.
3. これは初期登録ですので、CMDは、MN-ID、PREF1、およびMAAR1のアドレス（プロキシ-COAとして）を含むBCEをプライマリフィールドとして格納します。
4. The CMD replies with a PBA with the usual options defined in PMIPv6 [RFC5213], meaning that the MN's registration is fresh and no past status is available.
4. CMDは、PMIPv6 [RFC5213]で定義されている通常のオプションを使用してPBAで返信します。つまり、MNの登録は新鮮で過去のステータスがありません。
5. MAAR1 stores the BCE described in (1) and unicasts a Router Advertisement (RA) to the MN with Pref1.
5. MAAR1は、（1）に記載されているBCEを記憶し、Pref1を用いてMNにルータ広告（RA）を統一する。
6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with stateless address autoconfiguration (SLAAC)).
6. MNはPREF1を使用してIPv6アドレス（IP1）を設定します（例えば、ステートレスアドレス自動設定（SLAAC））。
Note that:
ご了承ください：
1. Alternative IPv6 autoconfiguration mechanisms can also be used, though this document describes the SLAAC-based one.
1. このドキュメントではSLAACベースのものについて説明していますが、代替のIPv6自動設定メカニズムも使用できます。
2. IP1 is routable at MAAR1 in the sense that it is on the path of packets addressed to the MN.
2. IP1は、MNに対処されているパケットの経路上にあるという意味で、Maar1でルーティング可能です。
3. MAAR1 acts as a plain router for packets destined to the MN as no encapsulation or special handling takes place.
3. Maar1は、カプセル化や特別な取り扱いが行われないため、MN宛てのパケット用のプレーンルータとして機能します。
In the diagram shown in Figure 1 (and subsequent diagrams), the flow of packets is presented using '*'.
図1（および後続の図）に示す図では、パケットの流れは '*'を使用して表示されます。
+-----+ +---+ +--+
|MAAR1| |CMD| |CN|
+-----+ +---+ +*-+
| | *
MN | * +---+
attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \
| | * / | \
local BCE | * / | \
allocation | * / | \
|--- PBU -->| +---*-+-' +--+--+ `+-----+
| BCE | * | | | | |
| creation |MAAR1+------+MAAR2+-----+MAAR3|
|<-- PBA ---| | * | | | | |
local BCE | +---*-+ +-----+ +-----+
finalized | *
| | Pref1 *
| | +*-+
| | |MN|
| | +--+
Operations sequence Packet flow
オペレーションシーケンスパケットフロー
Figure 1: First Attachment to the Network
図1：ネットワークへの最初の添付ファイル
Note that the registration process does not change regardless of the CMD's modes (relay, locator, or proxy) described in the following sections. The procedure is depicted in Figure 1.
なお、以下のセクションで説明したCMDのモード（リレー、ロケータ、またはプロキシ）に関係なく、登録プロセスは変更されません。手順を図1に示す。
Upon MN mobility, if the CMD behaves as a PBU/PBA relay, the following operations take place:
MNモビリティの際、CMDがPBU / PBAリレーとして動作すると、次の操作が行われます。
1. When the MN moves from its current point of attachment and attaches to MAAR2 (now the S-MAAR), MAAR2 reserves an IPv6 prefix (Pref2), stores a temporary BCE, and sends a PBU to the CMD for registration.
1. MNが現在の添付点から移動してMAAR2（現在はS-MAAR）に接続すると、MAAR2はIPv6プレフィックス（Pref2）を留保し、一時的なBCEを格納し、登録のためにPBUをCMDに送信します。
2. Upon PBU reception and BC lookup, the CMD retrieves an already existing entry for the MN and binds the MN-ID to its former location; thus, the CMD forwards the PBU to the MAAR indicated as Proxy-CoA (MAAR1) and includes a new mobility option to communicate the S-MAAR's global address to MAAR1 (defined as the Serving MAAR option in Section 4.6). The CMD updates the P-CoA field in the BCE related to the MN with the S-MAAR's address.
2. PBU受信とBCルックアップにより、CMDはMNの既存のエントリを取得し、MN-IDを以前の場所にバインドします。したがって、CMDはPBUをProxy-CoA（Maar1）として示されているMaarに転送し、S-MaarのグローバルアドレスをMaar1に伝達するための新しいモビリティオプションを含みます（セクション4.6のサービングマーオプションとして定義）。CMDは、MNに関連するBCEのP-COAフィールドをS-Maarのアドレスで更新します。
3. Upon PBU reception, MAAR1 can install a tunnel on its side towards MAAR2 and the related routes for Pref1. Then MAAR1 replies to the CMD with a PBA (including the option mentioned before) to ensure that the new location has successfully changed. The PBA contains the prefix anchored at MAAR1 in the Home Network Prefix option.
3. PBU受信時に、MAAR1はMAAR2に向かってその側にトンネルを設置し、PREFL1の関連ルートです。その後、MAAR1は、新しい場所が正常に変更されたことを確認するために、PBA（前述のオプションを含む）でCMDに返信します。PBAには、ホームネットワークプレフィックスオプションのMAAR1に固定されたプレフィックスが含まれています。
4. The CMD, after receiving the PBA, updates the BCE and populates an instance of the P-MAAR list. The P-MAAR list is an additional field on the BCE that contains an element for each P-MAAR involved in the MN's mobility session. The list element contains the P-MAAR's global address and the prefix it has delegated. Also, the CMD sends a PBA to the new S-MAAR, which contains the previous Proxy-CoA and the prefix anchored to it embedded into a new mobility option called the Previous MAAR option (defined in Section 4.5). Then, upon PBA arrival, a bidirectional tunnel can be established between the two MAARs, and new routes are set appropriately to recover the IP flow(s) carrying Pref1.
4. CMDは、PBAを受信した後、BCEを更新し、P-Maarリストのインスタンスを入力します。P-Maarリストは、MNのモビリティセッションに関与する各P-Maarの要素を含むBCE上の追加のフィールドです。list要素には、P-Maarのグローバルアドレスが含まれており、それが委任しているプレフィックスが含まれています。また、CMDはPBAを新しいS-MAARに送信します。これには、前のProxy-CoaとPrefixが埋め込まれたプレフィックスが埋め込まれています（4.5項で定義）。そして、PBA到着時に、2つのMAAR間に双方向トンネルを確立することができ、新しい経路を適切に設定して、PREF1を搬送するIPフローを回復する。
5. Now, packets destined for Pref1 are first received by MAAR1, encapsulated into the tunnel, and forwarded to MAAR2, which finally delivers them to their destination. In the uplink, when the MN transmits packets using Pref1 as a source address, they are sent to MAAR2 (as it is the MN's new default gateway) and then tunneled to MAAR1, which routes them towards the next hop to the destination. Conversely, packets carrying Pref2 are routed by MAAR2 without any special packet handling both for the uplink and downlink.
5. さて、PREF1宛てのパケットは、まずMAAR1によって受信され、トンネルにカプセル化され、Maar2に転送され、それがついにそれらを目的地に配信します。アップリンクでは、MNがPREF1を使用して送信元アドレスを使用してパケットを送信すると、それらはMaar2（MNの新しいデフォルトゲートウェイであるため）に送信され、その後Maar1にトンネリングされ、それらを宛先への次のホップに向かってルーティングします。逆に、PREF2を運ぶパケットは、アップリンクとダウンリンクの両方に特別なパケット処理なしでMaar2によってルーティングされます。
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| |--- PBA*-->| +*--*+
| | route ---move-->|*MN*|
| | update +----+
Operations sequence Data Packet flow PBU/PBA messages with * contain a new mobility option
オペレーションシーケンスデータパケットフロー* *を持つPBU / PBAメッセージが新しいモビリティオプションを含みます
Figure 2: Scenario after a Handover, CMD as Relay
図2：ハンドオーバ後のシナリオ、CMDがリレーとして
For MN's next movements, the process is repeated, but the number of P-MAARs involved increases (according to the number of prefixes that the MN wishes to maintain). Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE, namely the P-MAAR registered as the current P-CoA (i.e., the MAAR prior to handover) plus the ones in the P-MAAR list. Those P-MAARs reply with a PBA to the CMD, which aggregates all of the PBAs into one PBA to notify the S-MAAR, which finally can establish the tunnels with the P-MAARs.
MNの次の動きの場合、プロセスは繰り返されますが、関係するP-Maarsの数が増えます（MNが維持したいプレフィックスの数に従って）。確かに、CMDが新しいS-Maarから最初のPBUを受信すると、PBUのコピーをBCEに示されているすべてのPマーア、すなわち現在のP-CoAとして登録されているP-Maar（すなわち、マーヤー）に転送します。ハンドオーバ前に）P-Maarリストの中のものこれらのP-Maarsは、PBAをCMDに返信します。これは、PBAを1つのPBAに集約してS-Maarに通知します。これは最後にP-Maarsでトンネルを確立することができます。
It should be noted that this design separates the mobility management at the prefix granularity, and it can be tuned in order to erase old mobility sessions when not required, while the MN is reachable through the latest prefix acquired. Moreover, the latency associated with the mobility update is bound to the PBA sent by the furthest P-MAAR, in terms of RTT, that takes the longest time to reach the CMD. The drawback can be mitigated by introducing a timeout at the CMD, by which, after its expiration, all the PBAs so far collected are transmitted, and the remaining are sent later upon their arrival. Note that, in this case, the S-MAAR might receive multiple PBAs from the CMD in response to a PBU. The CMD SHOULD follow the retransmissions and rate-limiting considerations described in Section 3.6, especially when aggregating and relaying PBAs.
この設計は、Phipixの粒度でモビリティ管理を分離し、必要なときに古いモビリティセッションを消去するために調整することができます。さらに、モビリティ更新に関連する待ち時間は、RTTに関して最も遠いP - MAARによって送信されたPBAにバインドされ、それはCMDに達するために最長時間をかけます。DrabeはCMDでタイムアウトを導入することによって軽減できます。これにより、その有効期限が切れた後にすべてのPBAが送信され、残りは到着時に後で送信されます。この場合、S-MaarはPBUに応答してCMDから複数のPBAを受信する可能性があることに注意してください。CMDは、特にPBAを集約して中継するときに、セクション3.6で説明されている再送信およびレート制限の考慮事項に従うべきです。
When there are multiple P-MAARs, e.g., k MAARs, a single PBU received by the CMD triggers k outgoing packets from a single incoming packet. This may lead to packet bursts originating from the CMD, albeit to different targets. Pacing mechanisms MUST be introduced to avoid bursts on the outgoing link.
複数のPマーア、例えばK Maarsがある場合、CMDによって受信された単一のPBUが1回の着信パケットからKの発信パケットをトリガします。これは、さまざまなターゲットにはあるが、CMDから発信されたパケットバーストをもたらし得る。発信リンクのバーストを回避するためにペーシングメカニズムを導入する必要があります。
The handover latency experienced in the approach shown before can be reduced if the P-MAARs are allowed to directly signal their information to the new S-MAAR. This procedure reflects what was described in Section 3.2 up to the moment the P-MAAR receives the PBU with the Serving MAAR option. At that point, a P-MAAR is aware of the new MN's location (because of the S-MAAR's address in the Serving MAAR option), and, besides sending a PBA to the CMD, it also sends a PBA to the S-MAAR, including the prefix it is anchoring. This latter PBA does not need to include new options, as the prefix is embedded in the Home Network Prefix (HNP) option and the P-MAAR's address is taken from the message's source address. The CMD is released from forwarding the PBA to the S-MAAR as the latter receives a copy directly from the P-MAAR with the necessary information to build the tunnels and set the appropriate routes. Figure 3 illustrates the new message sequence. The data forwarding is unaltered.
P-Maarsが新しいS-Maarに情報を直接送ることを許可されている場合、前に示されたアプローチで経験されたハンドオーバー待ち時間を減らすことができます。この手順は、P-MaarがサービングMaarオプションを使用してPBUを受信した瞬間までのセクション3.2で説明されているものを反映しています。その時点で、P-Maarは新しいMNの場所（サービングマールオプションのS-Maarのアドレスのため）を知っており、PBAをCMDに送信する以外に、PBAをS-Maarに送信します。それは固定です。この後者のPBAは、ホームネットワークプレフィックス（HNP）オプションに埋め込まれており、P-Maarのアドレスがメッセージの送信元アドレスから取得されるため、新しいオプションを含める必要はありません。後者がP-Maarから直接コピーを受信してトンネルを構築し、適切なルートを設定しているため、CMDはPBAをS-Maarに転送することから解放されます。図3は新しいメッセージシーケンスを示しています。データ転送は変更されません。
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--------- PBA -------->| +-----+ +-*--*+ +-----+
|--- PBA*-->| route * *
| BCE update Pref1 * *Pref2
| update | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packet flow PBU/PBA messages with * contain a new mobility option
オペレーションシーケンスデータパケットフロー* *を持つPBU / PBAメッセージが新しいモビリティオプションを含みます
Figure 3: Scenario after a Handover, CMD as Locator
図3：ハンドオーバ後のシナリオ、CMDとしてロケータとして
A further enhancement of previous solutions can be achieved when the CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of the location change. Indeed, when the CMD receives the PBU for the new registration, it is already in possession of all the information that the new S-MAAR requires to set up the tunnels and the routes. Thus, the PBA is sent to the S-MAAR immediately after a PBU is received, including the Previous MAAR option in this case. In parallel, a PBU is sent by the CMD to the P-MAARs containing the Serving MAAR option to notify them about the new MN's location so that they receive the information to establish the tunnels and routes on their side. When P-MAARs complete the update, they send a PBA to the CMD to indicate that the operation has concluded and the information is updated in all network nodes. This procedure is obtained from the first procedure rearranging the order of the messages, but the parameters communicated are the same. This scheme is depicted in Figure 4, where, again, the data forwarding is kept untouched.
CMDが位置変更のP-Maarsを通知する前に、CMDがPBAを新しいS-Maarに送信すると、以前のソリューションのさらなる強化を達成できます。確かに、CMDが新しい登録のためにPBUを受信すると、すでに新しいS-Maarがトンネルとルートを設定する必要があるすべての情報を所有しています。したがって、この場合、PBUが受信された直後にPBAがS-Maarに送信されます。この場合は前のMaarオプションを含めます。並行して、PBUは、それらがそれらがそれらを確立するための情報を受け取るためにそれらがそれらを受け取るようにそれらを受け取るようにそれらをそれらを受け取るようにそれらにそれらを受信するようにそれらをそれらに通知するためにそれらをそれらに通知するためにCMDによってCMDによって送信される。 P-Maarsがアップデートを完了すると、操作が終了したことを示すためにCMDにPBAを送信し、すべてのネットワークノードで情報が更新されます。この手順は、メッセージの順序を並べ替える最初の手順から取得されますが、通信されたパラメータは同じです。この方式は図4に示されています。ここで、データ転送は手を整えるように保持されます。
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---x--- PBA*-->| | * | | *| | |
route | route |MAAR1|______|MAAR2+-----+MAAR3|
update | update | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| | | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packet flow PBU/PBA messages with * contain a new mobility option
オペレーションシーケンスデータパケットフロー* *を持つPBU / PBAメッセージが新しいモビリティオプションを含みます
Figure 4: Scenario after a Handover, CMD as Proxy
図4：ハンドオーバ後、CMDのプロキシとしてシナリオ
The de-registration mechanism devised for PMIPv6 cannot be used as is in this solution because each MAAR handles an independent mobility session (i.e., a single prefix or a set of prefixes) for a given MN, whereas the aggregated session is stored at the CMD. Indeed, if a P-MAAR initiates a de-registration procedure because the MN is no longer present on the MAAR's access link, it removes the routing state for the prefix(es), that would be deleted by the CMD as well, hence defeating any prefix continuity attempt. The simplest approach to overcome this limitation is to deny a P-MAAR to de-register a prefix, that is, allowing only an S-MAAR to de-register the whole MN session. This can be achieved by first removing any L2 detachment event so that de-registration is triggered only when the binding lifetime expires, hence providing a guard interval for the MN to connect to a new MAAR. Then, a change in the MAAR operations is required, and at this stage, two possible solutions can be deployed:
PMIPv6のために考案された登録解除メカニズムは、このソリューションのように、各Maarは特定のMNに対して独立したモビリティセッション（すなわち単一の接頭辞またはプレフィックスのセット）を処理するのに対し、集約されたセッションはCMDに格納されるため、使用することはできません。 。実際、P-MaarがMAARのアクセスリンク上にMNが存在しなくなったため、P-Maarが登録解除手順を開始した場合は、Prefix（ES）のルーティング状態を削除します。これはCMDによっても削除されます。接頭辞の継続試行この制限を克服するための最も簡単なアプローチは、P-Maarを拒否することですが、プレフィックスを除去すること、つまりS-MaarだけがMNセッション全体を登録することを可能にします。これは、最初にL2切り離しイベントを取り除くことによって実現することができ、その結果、拘束寿命が期限切れになるときにのみ登録解除がトリガされ、したがってMNのためのガードインターバルを新しいMAARに接続するためのガードインターバルを提供することによって達成することができる。その後、Maar操作の変更が必要であり、この段階では2つの可能な解決策を展開することができます。
* A P-MAAR stops the BCE timer upon receiving a PBU from the CMD containing a "Serving MAAR" option. In this way, only the S-MAAR is allowed to de-register the mobility session, arguing that the MN definitely left the domain.
* P-Maarは、「サービングマー」オプションを含むCMDからPBUを受信したときにBCEタイマーを停止します。このようにして、S-Maarだけがモビリティセッションを復元することができ、Mnは間違いなくドメインを残したと主張します。
* P-MAARs can, upon BCE expiry, send de-registration messages to the CMD, which, instead of acknowledging the message with a 0 lifetime, sends back a PBA with a non-zero lifetime, hence renewing the session if the MN is still connected to the domain.
* P-Maarsは、有効期限が切れ、登録メッセージを送信することができます。これは、0の有効期間でメッセージを確認する代わりに、PBAをゼロ以外の寿命で送り返します。したがって、MNがまだある場合はセッションを更新します。ドメインに接続されています。
The node sending PBUs (the CMD or S-MAAR) SHOULD make use of the timeout to also deal with missing PBAs (to retransmit PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer. The retransmissions by the node MUST use an exponential backoff process in which the timeout period is doubled upon each retransmission until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT [RFC6275]. The node MAY continue to send these messages at this slower rate indefinitely. The node MUST NOT send PBU messages to a particular node more than MAX_UPDATE_RATE times within a second [RFC6275].
PBUS（CMDまたはS-MAAR）を送信するノードは、表示されているPBAS（PBUSを再送信する）にも対処するためのタイムアウトを利用する必要があります。initial_bindack_timeout [RFC6275]は、再送信タイマーを設定するために使用する必要があります。ノードによる再送信は、ノードが応答を受信するか、タイムアウト期間が値max_bindack_timeout [RFC6275]に達するまで、タイムアウト期間が2倍になるか、またはタイムアウト期間が到達するまで、タイムアウト期間が2倍になる必要があります。このノードは、これらのメッセージをこの遅いレートで無期限に送信し続けることができます。ノードは、2秒以内にPBUメッセージを特定のノードにMAX_UPDATE_RATE回数を超えて送信してはなりません[RFC6275]。
One of the main challenges of a network-based DMM solution is how to allow a MN to simultaneously send/receive traffic that is anchored at different MAARs and how to influence the MN's selection process of its source IPv6 address for a new flow without requiring special support from the MN's IP stack. This document defines the DLIF, which is a software construct in the MAAR that can easily hide the change of associated anchors from the MN.
ネットワークベースのDMMソリューションの主な課題の1つは、MNが異なるマーアに固定されているトラフィックを同時に送受信することを許可する方法と、特別なフローのMNの選択プロセスのMNの選択プロセスへの影響を必要とせずに新しいフローのMNの選択プロセスに影響を与える方法です。MNのIPスタックからのサポート。このドキュメントはDLIFを定義します。これは、MNから関連付けられているアンカーの変更を簡単に隠すことができるMaarのソフトウェア構文である。
+---------------------------------------------------+
( Operator's )
( core )
+---------------------------------------------------+
| |
+---------------+ tunnel +---------------+
| IP stack |===============| IP stack |
+---------------+ +-------+-------+
| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+
+---------------+ | | +-------+-------+ |
| phy interface | | | | phy interface | |
+---------------+ | | +---------------+ |
MAAR1 (o) (o) MAAR2 (o)
x x
x x
prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x
(o)
|
+-----+
prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+
Figure 5: DLIF: Exposing Multiple Routers (One per P-MAAR)
図5：DLIF：複数のルータを公開する（P-Maar 1つ）
The basic idea of the DLIF concept is the following: each S-MAAR exposes itself to a given MN as multiple routers, one per P-MAAR associated with the MN. Let's consider the example shown in Figure 5: MN1 initially attaches to MAAR1, configuring an IPv6 address (prefA::MN1) from a prefix locally anchored at MAAR1 (prefA::/64). At this stage, MAAR1 plays the role of both anchoring and serving MAAR and also behaves as a plain IPv6 access router. MAAR1 creates a DLIF to communicate (through a point-to-point link) with MN1, exposing itself as a (logical) router with specific MAC and IPv6 addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using the DLIF mn1mar1. As explained below, these addresses represent the "logical" identity of MAAR1 for MN1 and will "follow" the MN while roaming within the domain (note that the place where all this information is maintained and updated is out of scope of this document; potential examples are to keep it on the home subscriber server -- HSS -- or the user's profile).
DLIFの概念の基本的な考え方は次のとおりです。各S-Maarは、MNに関連付けられているP-Maarごとに1つずつ、複数のルーターとして特定のMNに公開します。図5に示す例を検討しましょう.MN1は、最初にMaar1に添付され、PrefixからのIPv6アドレス（Prefa :: MN1）をPrefixから設定します（Prefa :: / 64）。この段階で、Maar1は固定とサービングマーアの両方の役割を果たし、普通のIPv6アクセスルータとしても動作します。 MAAR1はMN1を使用して（ポイントツーポイントリンクを介して）通信するDLIFを作成し、特定のMacおよびIPv6アドレスを持つ（論理的な）ルーターとして露出させる（例：Prefa :: Maar1 / 64とFE80 :: Maar1/64） DLIF MN1MAR1を使用する。以下に説明するように、これらのアドレスはMN1のMAAR1の「論理的な」アイデンティティを表し、ドメイン内でローミングしながらMNを「従う」ことを表します（すべてのこの情報が維持され更新されている場所はこの文書の範囲外です。可能性があります。例は、Home Subscriber Server - HSS - またはユーザーのプロファイル）に保存することです。
If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in the example of Figure 5), this MAAR will create a new logical interface (mn1mar2) to expose itself to MN1, providing it with a locally anchored prefix (prefB::/64). In this case, since the MN1 has another active IPv6 address anchored at MAAR1, MAAR2 also needs to create an additional logical interface configured to resemble the one used by MAAR1 to communicate with MN1. In this example, MAAR1 is the only P-MAAR (MAAR2 is the same as S-MAAR), so only the logical interface mn1mar1 is created. However, the same process would be repeated if more P-MAARs were involved. In order to keep the prefix anchored at MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is established and the routing is modified accordingly. The PBU/PBA signaling is used to set up the bidirectional tunnel between MAAR1 and MAAR2, and it might also be used to convey the information about the prefix(es) anchored at MAAR1 and the addresses of the associated DLIF (i.e., mn1mar1) to MAAR2.
MN1がドメインの別のMaar（図5の例でMaar2）に移動して添付されている場合、このMaarは新しい論理インタフェース（MN1MAR2）を作成してMN1にそれを公開し、ローカルに固定されたプレフィックス（登録）を提供します（登場:: / 64）。この場合、MN1はMAAR1に固定された別のアクティブIPv6アドレスを有するので、MAAR2はMN1と通信するためにMaar1によって使用されるものに似た追加の論理インタフェースも作成する必要がある。この例では、Maar1はP-Maar（Maar2はS-Maarと同じ）であるため、論理インターフェイスMN1MAR1のみが作成されます。しかしながら、より多くのPマーガールが関与している場合、同じプロセスが繰り返されるであろう。 PrefixをMaar1に到達可能に停止させ続けるために、Maar1とMaar2の間のトンネルが確立され、それに応じてルーティングが修正されます。 PBU / PBAシグナリングは、MAAR1とMAAR2の間の双方向トンネルを設定するために使用され、MAAR1に固定された接頭辞に関する情報と関連DLIFのアドレス（すなわち、MN1MAR1）に関する情報を伝達するためにも使用されます。マール2。
+------------------------------------------+ +----------------------+
| MAAR1 | | MAAR2 |
|+----------------------------------------+| |+--------------------+|
||+------------------++------------------+|| ||+------------------+||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2||||
|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||
||+------------------++------------------+|| ||+------------------+||
|| MAC1 (phy if MAAR1) || || MAC2 (phy if MAAR2)||
|+----------------------------------------+| |+--------------------+|
+------------------------------------------+ +----------------------+
x x x
x x x
(o) (o) (o)
| | |
+--+--+ +--+--+ +--+--+
| MN3 | | MN2 | | MN1 |
+-----+ +-----+ +-----+
Figure 6: Distributed Logical Interface Concept
図6：分散論理インタフェースの概念
Figure 6 shows the logical interface concept in more detail. The figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 and MN3, while MAAR2 is serving MN1. Note that an S-MAAR always plays the role of anchoring MAAR for the attached (served) MNs. Each MAAR has one single physical wireless interface as depicted in this example.
図6は、論理インタフェースの概念をより詳細に示しています。この図は、2つのMaarsと3つのMNを示しています。Maar1はMN2とMN3にサービスを提供していますが、MAAR2はMN1を提供しています。S-Maarは常に接続されている（提供された）MnSのための固定Maarの役割を果たしていることに注意してください。各Maarには、この例に示すように単一の物理的無線インタフェースが1つあります。
As discussed before, each MN always "sees" multiple logical routers -- one per anchoring MAAR -- independently of its currently S-MAAR. From the point of view of the MN, these MAARs are portrayed as different routers, although the MN is physically attached to a single interface. This is achieved by the S-MAAR configuring different logical interfaces. MN1 is currently attached to MAAR2 (i.e., MAAR2 is its S-MAAR) and, therefore, it has configured an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set up a logical interface (mn1mar2) on top of its wireless physical interface (phy if MAAR2), which is used to serve MN1. This interface has a logical MAC address (LMAC6) that is different from the hardware MAC address (MAC2) of the physical interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 was attached to MAAR1 and configured a locally anchored address at that MAAR, which is still being used by MN1 in active communications. MN1 keeps "seeing" an interface connecting to MAAR1 as if it were directly connected to the two MAARs. This is achieved by the S-MAAR (MAAR2) configuring an additional DLIF, mn1mar1, which behaves as the logical interface configured by MAAR1 when MN1 was attached to it. This means that both the MAC and IPv6 addresses configured on this logical interface remain the same regardless of the physical MAAR that is serving the MN. The information required by an S-MAAR to properly configure this logical interfaces can be obtained in different ways: as part of the information conveyed in the PBA, from an external database (e.g., the HSS) or by other means. As shown in the figure, each MAAR may have several logical interfaces associated with each attached MN and always has at least one (since an S-MAAR is also an anchoring MAAR for the attached MN).
前述のように、各MNは常に複数の論理ルータ - アンカーマールごとの1つです - 現在S-Maarとは無関係です。 MNの観点から、これらのMaarsは異なるルータとして描かれていますが、Mnは単一のインタフェースに物理的に接続されています。これは、異なる論理インタフェースを設定するS-Maarによって達成されます。 MN1は現在Maar2（すなわち、Maar2がそのS - Maarである）に接続されており、したがって、Maar2のプールからIPv6アドレスを構成している（例えば、序頭:: / 64）。 MAAR2は、MN1を提供するために使用される無線物理インターフェイス（PHY IF Maar2）の上に論理インタフェース（MN1MAR2）を設定しました。このインタフェースには、Maar2の物理インターフェイスのハードウェアMACアドレス（MAC2）とは異なる論理MACアドレス（LMAC6）があります。 MO1MAR2インターフェイスを越えて、MAAR2はそのローカルに固定されたプレフィックス既成区を宣伝します:: / 64。 MAAR2に接続する前に、MN1がMAAR1に接続され、そのMAARでローカルに固定されたアドレスを設定し、これは依然としてアクティブな通信でMN1によって使用されています。 MN1 Maar1に接続するインタフェースを「Seeing」に保ち、まるで2つのMaarsに直接接続されています。これはS-Maar（Maar2）によって達成されます。これは、MN1がそれに接続されているときにMAAR1によって構成された論理インターフェイスとして機能する追加のDLIF、MN1MAR1を設定します。つまり、この論理インターフェイスに設定されているMACアドレスとIPv6アドレスの両方が、MNにサービスを提供している物理的なMAARに関係なく同じままです。この論理インタフェースを適切に構成するためにS - MAARによって必要とされる情報は、異なる方法で取得することができる.PBA内で伝達された情報の一部として、外部データベース（例えば、HSS）または他の手段によってもよい。図に示すように、各MAARは、添付された各MNに関連するいくつかの論理インタフェースを有し、常に少なくとも1つを有することがある（S - Maarは、接続されたMNのための固定MAARであるため）。
In order to enforce the use of the prefix locally anchored at the S-MAAR, the RAs sent over those logical interfaces playing the role of anchoring MAARs (different from the serving one) include a zero preferred prefix lifetime (and a non-zero valid prefix lifetime, so the prefix remains valid while being deprecated). The goal is to deprecate the prefixes delegated by these MAARs (so that they will no longer be serving the MN). Note that ongoing communications may keep on using those addresses even if they are deprecated, so this only affects the establishment of new sessions.
S-Maarでローカルに固定されたプレフィックスの使用を強制するために、固定マーアの役割を演奏する論理インタフェースを介して送信されたRASは、ゼロ優先プレフィックス寿命（およびゼロ以外の有効な有効）を含む。有効期間のプレフィックスなので、プレフィックスは非推奨中に有効なままです。目標は、これらのMaarsによって委任された接頭辞を廃止することです（彼らはもはやMNにサービスを提供しなくなるでしょう）。進行中の通信は、たとえ廃止予定であってもそれらのアドレスを使用し続けるかもしれないので、これは新しいセッションの確立に影響を与えるだけです。
The DLIF concept also enables the following use case: suppose that access to a local IP network is provided by a given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that the resources available at that network cannot be reached from outside the local network (e.g., cannot be accessed by an MN attached to MAAR2). This is similar to the local IP access scenario considered by 3GPP, where a local gateway node is selected for sessions requiring access to services provided locally (instead of going through a central gateway). The goal is to allow an MN to be able to roam while still being able to have connectivity to this local IP network. The solution adopted to support this case makes use of more specific routes, as discussed in RFC 4191 [RFC4191], when the MN moves to a MAAR different from the one providing access to the local IP network (MAAR1 in the example). These routes are advertised through the DLIF where the MAAR is providing access to the local network (MAAR1 in this example). In this way, if MN1 moves from MAAR1 to MAAR2, any active session that MN1 may have with a node on the local network connected to MAAR1 will survive via the tunnel between MAAR1 and MAAR2. Also, any potential future connection attempt to the local network will be supported even though MN1 is no longer attached to MAAR1, so long as a source address configured from MAAR1 is selected for new connections (see [RFC6724], rule 5.5).
DLIFコンセプトは、次のユースケースも有効になります。ローカルIPネットワークへのアクセスが特定のMaar（例えば、図5に示す例のMaar1）によって提供され、そのネットワークで利用可能なリソースは外部から到達できないとします。ローカルネットワーク（例えば、MAAR2に接続されているMNによってアクセスすることはできません）。これは、3GPPが検討したローカルIPアクセスシナリオと似ています。ここでは、ローカルゲートウェイノードは、ローカルに提供されるサービスへのアクセスを必要とするセッションのために選択されます（中央ゲートウェイを通過する代わりに）。目標は、このローカルIPネットワークへの接続性を持たずにMNがローミングできるようにすることです。このケースをサポートするために採用された解決策は、RFC 4191 [RFC4191]で説明したように、MNがローカルIPネットワークへのアクセスを提供するものとは異なるMAARに移動したときに、より具体的なルートを利用します（例：MAAR1）。これらの経路は、Maarがローカルネットワークへのアクセスを提供しているDLIFを介して宣伝されています（この例ではMAAR1）。このようにして、MN1がMAAR1からMAAR2に移動した場合、MN1がMAAR1に接続されているローカルネットワーク上のノードがある可能性があるアクティブセッションは、Maar1とMaar2の間のトンネルを介して生き残るでしょう。また、MAAR1から設定されている送信元アドレスが新しい接続のために選択されている限り、MAAR1にMAAR1が添付されていなくても、ローカルネットワークへの潜在的な将来の接続の試みがサポートされます（[RFC6724]、規則5.5を参照）。
This section defines extensions to the PMIPv6 [RFC5213] protocol messages.
このセクションでは、PMIPv6 [RFC5213]プロトコルメッセージへの拡張子を定義します。
A new flag (D) is included in the PBU to indicate that the PBU is coming from a MAAR or a CMD and not from a MAG. The rest of the PBU format remains the same as defined in [RFC5213].
PBUがMARやCMDから来ていることを示すために、PBUに新しいフラグ（D）が含まれている。PBUフォーマットの残りの部分は[RFC5213]で定義されていると同じままです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DMM Flag (D) The D flag is set to indicate to the receiver of the message that the PBU is from a MAAR or a CMD. When an LMA that does not support the extensions described in this document receives a message with the D flag set, the PBU in that case MUST NOT be processed by the LMA, and an error MUST be returned.
DMMフラグ（d）Dフラグは、PBUがMaarまたはCMDからのメッセージの受信側に示すように設定されています。この文書に記載されている拡張機能をサポートしていないLMAがDフラグ・セットでメッセージを受信すると、その場合のPBUはLMAによって処理されてはならず、エラーが返されなければなりません。
Mobility Options Variable-length field of such length that the complete Mobility Header is an integer that is a multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of the defined options are described in Section 6.2 of [RFC6275]. The receiving node MUST ignore and skip any options that it does not understand.
モビリティオプション完全なモビリティヘッダーが8オクテットの長さの整数である整数の長さの可変長フィールド。このフィールドには、0個以上のTLVエンコードモビリティオプションが含まれています。定義されたオプションのエンコードとフォーマットは[RFC6275]のセクション6.2で説明されています。受信ノードは、理解できないオプションを無視してスキップする必要があります。
A new flag (D) is included in the PBA to indicate that the sender supports operating as a MAAR or CMD. The rest of the PBA format remains the same as defined in [RFC5213].
送信者がMAARまたはCMDとして機能することを示すために、新しいフラグ（D）がPBAに含まれています。PBA形式の残りの部分は[RFC5213]で定義されているものと同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T|B|S|D| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DMM Flag (D) The D flag is set to indicate that the sender of the message supports operating as a MAAR or CMD. When a MAG that does not support the extensions described in this document receives a message with the D flag set, it MUST ignore the message, and an error MUST be returned.
DMMフラグ（d）Dフラグは、メッセージの送信者がMAARまたはCMDとして動作することを示すように設定されています。この文書に記載されている拡張機能をサポートしていないMAGがDフラグ・セットを使用してメッセージを受信すると、メッセージを無視し、エラーが返されなければなりません。
Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of the defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand.
モビリティオプション完全なモビリティヘッダーが8オクテットの長さの整数倍の長さの可変長フィールド。このフィールドには、0個以上のTLVエンコードモビリティオプションが含まれています。定義されたオプションのエンコードとフォーマットは[RFC6275]のセクション6.2で説明されています。Maarはそれが理解できないオプションを無視してスキップする必要があります。
A new Anchored Prefix option is defined for use with the PBU and PBA messages exchanged between MAARs and CMDs. Therefore, this option can only appear if the D bit is set in a PBU/PBA. This option is used for exchanging the MN's prefix anchored at the anchoring MAAR. There can be multiple Anchored Prefix options present in the message.
MaarsとCMDSの間で交換されたPBUメッセージとPBAメッセージとの使用には、新しいアンカープレフィックスオプションが定義されています。したがって、このオプションは、DビットがPBU / PBAに設定されている場合にのみ表示できます。このオプションは、アンチアリングマールに固定されたMNの接頭辞を交換するために使用されます。メッセージに複数の固定されたプレフィックスオプションが存在する可能性があります。
The Anchored Prefix option has an alignment requirement of 8n+4. Its format is as follows:
固定されたプレフィックスオプションには、8N 4のアライメント要件があります。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Anchored Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65
タイプ65
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18.
タイプと長さのフィールドを除く、オクテット内のオプションの長さを示す長さ8ビットの符号なし整数。このフィールドは18に設定する必要があります。
Reserved This field is unused at the time of publication. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
予約このフィールドは出版時に未使用です。値は送信者によって0に初期化されなければならず、受信者によって無視される必要があります。
Prefix Length 8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix contained in the option.
プレフィックス長さ8ビットの符号なし整数オプションに含まれるIPv6プレフィックスのビット内のプレフィックス長を示す。
Anchored Prefix A 16-octet field containing the MN's IPv6 Anchored Prefix. Only the first Prefix Length bits are valid for the Anchored Prefix option. The rest of the bits MUST be ignored.
Anchored Prefix MNのIPv6アンカープレフィックスを含む16オクテットフィールド。アンカープレフィックスオプションには、最初のプレフィックス長ビットのみが有効です。残りのビットは無視する必要があります。
A new Local Prefix option is defined for use with the PBU and PBA messages exchanged between MAARs or between a MAAR and a CMD. Therefore, this option can only appear if the D bit is set in a PBU/ PBA. This option is used for exchanging a prefix of a local network that is only reachable via the anchoring MAAR. There can be multiple Local Prefix options present in the message.
新しいローカルプレフィックスオプションは、MaarsとMaarとCMDの間で交換されたPBUメッセージとPBAメッセージとの使用に定義されています。したがって、このオプションは、DビットがPBU / PBAに設定されている場合にのみ表示できます。このオプションは、アンカーマールを介して到達可能なローカルネットワークのプレフィックスを交換するために使用されます。メッセージに複数のローカルプレフィックスオプションが存在する可能性があります。
The Local Prefix option has an alignment requirement of 8n+4. Its format is as follows:
ローカルプレフィックスオプションには、8N 4のアライメント要件があります。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 66
タイプ66
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18.
タイプと長さのフィールドを除く、オクテット内のオプションの長さを示す長さ8ビットの符号なし整数。このフィールドは18に設定する必要があります。
Reserved This field is unused at the time of publication. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
予約このフィールドは出版時に未使用です。値は送信者によって0に初期化されなければならず、受信者によって無視される必要があります。
Prefix Length 8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix contained in the option.
プレフィックス長さ8ビットの符号なし整数オプションに含まれるIPv6プレフィックスのビット内のプレフィックス長を示す。
Local Prefix A 16-octet field containing the IPv6 Local Prefix. Only the first Prefix Length bits are valid for the IPv6 Local Prefix. The rest of the bits MUST be ignored.
Local Prefix IPv6ローカルプレフィックスを含む16オクテットフィールド。IPv6ローカルプレフィックスには、最初のプレフィックス長ビットのみが有効です。残りのビットは無視する必要があります。
This new option is defined for use with the PBA messages exchanged by the CMD to a MAAR. This option is used to notify the S-MAAR about the P-MAAR's global address and the prefix anchored to it. There can be multiple Previous MAAR options present in the message.
この新しいオプションは、CMDによってMaarに交換されたPBAメッセージと共に使用するために定義されています。このオプションは、P-Maarのグローバルアドレスとそれに固定された接頭辞についてS-Maarに通知するために使用されます。メッセージに複数の前のMaarオプションが存在する可能性があります。
The Previous MAAR option has an alignment requirement of 8n+4. Its format is as follows:
前のMaarオプションには8N 4のアライメント要件があります。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Previous MAAR +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 67
タイプ67
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 34.
タイプと長さのフィールドを除く、オクテット内のオプションの長さを示す長さ8ビットの符号なし整数。このフィールドは34に設定する必要があります。
Reserved This field is unused at the time of publication. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
予約このフィールドは出版時に未使用です。値は送信者によって0に初期化されなければならず、受信者によって無視される必要があります。
Prefix Length 8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix contained in the option.
プレフィックス長さ8ビットの符号なし整数オプションに含まれるIPv6プレフィックスのビット内のプレフィックス長を示す。
Previous MAAR A 16-octet field containing the P-MAAR's IPv6 global address.
Preasion Maar P-MaarのIPv6グローバルアドレスを含む16オクテットフィールド。
Home Network Prefix A 16-octet field containing the MN's IPv6 Home Network Prefix. Only the first Prefix Length bits are valid for the MN's IPv6 Home Network Prefix. The rest of the bits MUST be ignored.
ホームネットワークプレフィックスMNのIPv6ホームネットワークプレフィックスを含む16オクテットフィールド。MNのIPv6ホームネットワークプレフィックスには、最初のプレフィックス長ビットのみが有効です。残りのビットは無視する必要があります。
This new option is defined for use with the PBU message exchanged between the CMD and a P-MAAR. This option is used to notify the P-MAAR about the current S-MAAR's global address. Its format is as follows:
この新しいオプションは、CMDとP-Maarとの間で交換されたPBUメッセージでの使用に対して定義されています。このオプションは、現在のS-MaarのグローバルアドレスについてP-Maarに通知するために使用されます。その形式は次のとおりです。
The Serving MAAR option has an alignment requirement of 8n+6. Its format is as follows:
サービングMAARオプションには8N 6のアライメント要件があります。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ S-MAAR's Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 68
タイプ68
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16.
タイプと長さのフィールドを除く、オクテット内のオプションの長さを示す長さ8ビットの符号なし整数。このフィールドは16に設定する必要があります。
Serving MAAR A 16-octet field containing the S-MAAR's IPv6 global address.
S-MaarのIPv6グローバルアドレスを含む16オクテットフィールドをMaarに提供します。
A new DLIF Link-Local Address option is defined for use with the PBA message exchanged between MAARs and between a MAAR and a CMD. This option is used for exchanging the link-local address of the DLIF to be configured on the S-MAAR so it resembles the DLIF configured on the P-MAAR.
MaarsとMaarとCMDの間で交換されるPBAメッセージと共に使用するために、新しいDLIFリンクローカルアドレスオプションが定義されています。このオプションは、P-Maarに設定されているDLIFに似たDLIFのリンクローカルアドレスをS-Maarに交換するために使用されます。
The DLIF Link-Local Address option has an alignment requirement of 8n+6. Its format is as follows:
DLIF Link-Local Addressオプションには、8N 6のアライメント要件があります。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DLIF Link-Local Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 69
タイプ69
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16.
タイプと長さのフィールドを除く、オクテット内のオプションの長さを示す長さ8ビットの符号なし整数。このフィールドは16に設定する必要があります。
DLIF Link-Local Address A 16-octet field containing the link-local address of the logical interface.
DLIFリンク - ローカルアドレス論理インタフェースのリンクローカルアドレスを含む16 OCTETフィールド。
A new DLIF Link-Layer Address option is defined for use with the PBA message exchanged between MAARs and between a MAAR and a CMD. This option is used for exchanging the link-layer address of the DLIF to be configured on the S-MAAR so it resembles the DLIF configured on the P-MAAR.
MaarsとMaarとCMDの間で交換されるPBAメッセージと共に使用するために、新しいDLIFリンク層アドレスオプションが定義されています。このオプションは、S-Maarに設定されているDLIFのリンク層アドレスを交換するために使用されます。
The format of the DLIF Link-Layer Address option is shown below. Based on the size of the address, the option MUST be aligned appropriately, as per the mobility option alignment requirements specified in [RFC6275].
DLIFリンク層アドレスオプションのフォーマットを以下に示します。アドレスのサイズに基づいて、[RFC6275]で指定されたモビリティオプションのアライメント要件に従って、オプションを適切に適切に整列させる必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ DLIF Link-Layer Address +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 70
タイプ70
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
タイプと長さのフィールドを除く、オクテット内のオプションの長さを示す長さ8ビットの符号なし整数。
Reserved This field is unused at the time of publication. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
予約このフィールドは出版時に未使用です。値は送信者によって0に初期化されなければならず、受信者によって無視される必要があります。
DLIF Link-Layer Address A variable length field containing the link-layer address of the logical interface to be configured on the S-MAAR.
DLIFリンク層アドレスS-MAARに設定される論理インタフェースのリンクレイヤアドレスを含む可変長フィールド。
The content and format of this field (including octet and bit ordering) is as specified in Section 4.6 of [RFC4861] for carrying link-layer addresses. On certain access links where the link-layer address is not used or cannot be determined, this option cannot be used.
このフィールドの内容とフォーマット（オクテットとビットの順序付けを含む）は、リンクレイヤアドレスを搬送するための[RFC4861]のセクション4.6で指定されています。リンク層アドレスが使用されていない特定のアクセスリンクまたは決定できない場合、このオプションは使用できません。
This document defines six new mobility options: Anchored Prefix, Local Prefix, Previous MAAR, Serving MAAR, DLIF Link-Local Address, and DLIF Link-Layer Address. IANA has assigned Type values for these options from the same numbering space as allocated for the other mobility options in the "Mobility Options" registry defined in http://www.iana.org/assignments/mobility-parameters.
このドキュメントは、6つの新しいモビリティオプションを定義します。アンカープレフィックス、ローカルプレフィックス、前のMaar、Maar、DLIFリンクローカルアドレス、およびDLIFリンク層アドレスを提供します。IANAは、http://www.iana.org/assignments / mobility-parametersで定義されている「モビリティオプション」レジストリの他のモビリティオプションに割り当てられているのと同じ番号付けスペースからタイプ値を割り当てました。
This document reserves a new flag (D) with a value of 0x0010 in the "Binding Update Flags" registry and a new flag (D) with a value of 0x02 in the "Binding Acknowledgment Flags" of the "Mobile IPv6 parameters" registry (http://www.iana.org/assignments/mobility-parameters).
この文書は、「モバイルIPv6パラメータ」レジストリの「バインディング確認フラグ」で、「バインディング更新フラグ」レジストリと新しいフラグ（D）の新しいフラグ（d）を、新しいフラグ（D）を予約します。http://www.iana.org/assignments/mobility-parameters）。
The protocol extensions defined in this document share the same security concerns of PMIPv6 [RFC5213]. It is recommended that the signaling messages, PBU and PBA, exchanged between the MAARs be protected using IPsec, specifically by using the established security association between them. This essentially eliminates the threats related to the impersonation of a MAAR.
このドキュメントで定義されているプロトコル拡張機能は、PMIPv6 [RFC5213]の同じセキュリティ上の関心事を共有しています。Maars間で交換されるシグナリングメッセージ、PBU、およびPBAは、特にそれらの間の確立されたセキュリティアソシエーションを使用することによって、IPSecを使用して保護されることをお勧めします。これは、マーの偽装に関連する脅威を基本的に排除します。
When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a single PBU to multiple P-MAARs. In situations with many fast handovers (e.g., with vehicular networks), multiple previous (e.g., k) MAARs may exist. In this situation, the CMD creates k outgoing packets from a single incoming packet. This bears a certain amplification risk. The CMD MUST use a pacing approach in the outgoing queue to cap the output traffic (i.e., the rate of PBUs sent) to limit this amplification risk.
CMDがPBU / PBAリレーとして機能すると、CMDは単一のPBUの複数のP-Maarsへのリレーとして機能します。多くの高速ハンドオーバ（例えば、車両用ネットワークを用いて）を有する状況では、複数の前の（例えば、k）マーガースが存在し得る。この状況では、CMDは1回の着信パケットからKの発信パケットを作成します。これは一定の増幅リスクを負います。CMDは、出力トラフィック（すなわち、送信されたPBUのレート）をキャップしてこの増幅リスクを制限するために、発信キュー内のペーシングアプローチを使用する必要があります。
When the CMD acts as a MAAR locator, mobility signaling (PBAs) is exchanged between P-MAARs and the current S-MAAR. Hence, security associations are REQUIRED to exist between the involved MAARs (in addition to the ones needed with the CMD).
CMDがMaarロケータとして機能すると、移動度シグナリング（PBA）がPマーアと現在のS-Maarとの間で交換される。したがって、セキュリティアソシエーションは、関係するMAARS（CMDに必要なものに加えて）の間に存在する必要があります。
Since de-registration is performed by timeout, measures SHOULD be implemented to minimize the risks associated with continued resource consumption (DoS attacks), e.g., imposing a limit on the number of P-MAARs associated with a given MN.
登録解除はタイムアウトによって実行されるので、継続的なリソース消費（DOS攻撃）に関連するリスクを最小限に抑えるために、例えば、所与のMNに関連するPマーアの数に限界を課すために測定されるべきである。
The CMD and the participating MAARs MUST be trusted parties authorized perform all operations relevant to their role.
CMDと参加しているマーズは信頼できる締約国である必要があります。
There are some privacy considerations to consider. While the involved parties trust each other, the signaling involves disclosing information about the previous locations visited by each MN, as well as the active prefixes they are using at a given point of time. Therefore, mechanisms MUST be in place to ensure that MAARs and CMDs do not disclose this information to other parties or use it for other ends than providing the distributed mobility support specified in this document.
考慮すべきいくつかのプライバシーに関する考慮事項があります。関与団体は互いに信頼している間、シグナリングには、各MNによって訪問された前の場所に関する情報、および特定の時点で使用されているアクティブな接頭辞に関する情報を開示することが含まれます。したがって、MaarsとCMDSがこの情報を他の当事者に開示したり、この文書で指定された分散型モビリティサポートを提供するのではなく、メカニズムが整っている必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R.およびD. Thaler、「デフォルトルータ設定およびその他のルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https：//www.rfc-editor.org/info/rfc4191>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <https://www.rfc-editor.org/info/rfc5213>.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K.、およびB. Patil、 "Proxy Mobile IPv6"、RFC 5213、DOI 10.17487 / RFC5213、2008年8月、<HTTPS//www.rfc-editor.org/info/rfc5213>。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C、Ed。、Johnson、D.、およびJ.Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487 / RFC6275、2011年7月、<https：///www.rfc-編集者。ORG / INFO / RFC6275>。
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, <https://www.rfc-editor.org/info/rfc7333>.
[RFC7333]ちゃん、H。、ED。、Liu、D.、Seite、P.、Yokota、H.、およびJ.Korhonen、「分散モビリティ管理の要件」、RFC 7333、DOI 10.17487 / RFC7333、2014年8月、<https：//www.rfc-editor.org/info/rfc7333>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[DISTRIBUTED-ANCHORING] Bernardos, C. and J. Zuniga, "PMIPv6-based distributed anchoring", Work in Progress, Internet-Draft, draft-bernardos-dmm-distributed-anchoring-09, 29 May 2017, <https://tools.ietf.org/html/draft-bernardos-dmm-distributed-anchoring-09>.
[分散固定] Bernardos、C.およびJ.Zuniga、「PMIPv6ベースの分散固定」、進行中の作業、インターネットドラフト、ドラフト - Bernardos-DMM分散アンカー-09,2017、<https：//tools.ietf.org/html/draft-bernardos-dmm-distributed-09>。
[DMM-PMIP] Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based solution for Distributed Mobility Management", Work in Progress, Internet-Draft, draft-bernardos-dmm-pmip-09, 8 September 2017, <https://tools.ietf.org/html/draft-bernardos-dmm-pmip-09>.
[DMM-PMIP] Bernardos、C.、Oliva、A.およびF.Giust、「分散モビリティ管理のためのPMIPv6ベースのソリューション」、進行中の作業、インターネットドラフト、ドラフト-DMM-PMIP-09、2017年9月8日、<https://tools.ietf.org/html/draft-bernardos-dmm-pmip-09>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、ED。、Draves、R.、Matsumoto、A.、T. Chown、「インターネットプロトコルバージョン6のデフォルトアドレス選択（IPv6）」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月<https：//www.rfc-editor.org/info/rfc6724>。
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, <https://www.rfc-editor.org/info/rfc7429>.
[RFC7429] Liu、D.、Ed。、Zuniga、Jc。、Ed。、Seite、P.、Chan、H.、およびCJ。Bernardos、「分散モビリティ管理：現在の実践とギャップ分析」、RFC 7429、DOI 10.17487 / RFC7429、2015年1月、<https：//www.rfc-editor.org/info/rfc7429>。
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, <https://www.rfc-editor.org/info/rfc8563>.
[RFC8563] Katz、D.、Ward、D.、Pallagatti、S.、Ed。、およびG. Mirsky、Ed。、「双方向転送検出（BFD）マルチポイントアクティブテール」、RFC 8563、DOI 10.17487 / RFC8563、4月2019年、<https：//www.rfc-editor.org/info/rfc8563>。
Acknowledgements
謝辞
The authors would like to thank Dirk von Hugo, John Kaippallimalil, Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja Kühlewind, Éric Vyncke, Adam Roach, Benjamin Kaduk, and Roman Danyliw for the comments on this document. The authors would also like to thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei, and Satoru Matsushima for their comments and discussion on the documents [DISTRIBUTED-ANCHORING] and [DMM-PMIP], on which the present document is based.
著者らは、Dirk Von Hugo、John Kaippallimil、Ines Robles、Joerg Ots、Carlos Pignataro、Vincent Roca、MirjaKühlewind、ÉricVyncke、Adam Roach、Benjamin Kaduk、およびこの文書のコメントのためのローマDanyylwに感謝します。著者らは、Marco Liebsch、Dirk Von Hugo、Alex Petrescu、Danebar Rahman、Danbar Rahman、Xinpeng Wei、および松島悟（Distributed-Anchoring]および[DMM-PMIP）にもあります。]、現在の文書が基づいている。
The authors would also like to thank Lyle Bertz and Danny Moses for their in-depth review of this document and their very valuable comments and suggestions.
著者らは、この文書の詳細なレビューと彼らの非常に貴重なコメントや提案のためにLyle BertzとDanny Mosesに感謝します。
Authors' Addresses
著者の住所
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 28911 Leganes Madrid Spain
Carlos J. Bernardos Universidad Carlos Iii de Madrid AV。Envideridad、30 28911 Leganes Madridスペイン
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Antonio de la Oliva Universidad Carlos III de Madrid Av. Universidad, 30 28911 Leganes Madrid Spain
Antonio de la Oliva Universidad Carlos Iii de Madrid AV。Envideridad、30 28911 Leganes Madridスペイン
Phone: +34 91624 8803
Email: aoliva@it.uc3m.es
URI: http://www.it.uc3m.es/aoliva/
Fabio Giust Athonet S.r.l. via Ca' del Luogo 6/8 36050 Bolzano Vicentino (VI) Italy
Fabio Giust Athonet S.r.L.Via Ca 'Del Luogo 6/8 36050 Bolzano Vicentino（VI）イタリア
Email: fabio.giust.research@gmail.com
Juan Carlos Zúñiga SIGFOX 425 rue Jean Rostand 31670 Labege France
Juan CarlosZúñigaSigfox 425 Rue Jean Rostand 31670 Labege France
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/
Alain Mourad InterDigital Europe
Alain Mourad Interdigital Europe
Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/