[要約] RFC 8818は、モバイルネットワークにおける分散型の移動アンカリングに関する標準化を提供します。このRFCの目的は、モバイルデバイスの移動中に通信のセッションを維持し、ネットワークの負荷を分散させることです。
Internet Engineering Task Force (IETF) H. Chan, Ed.
Request for Comments: 8818 CIHE
Category: Informational X. Wei
ISSN: 2070-1721 Huawei Technologies
J. Lee
Sejong University
S. Jeon
Sungkyunkwan University
CJ. Bernardos, Ed.
UC3M
October 2020
Distributed Mobility Anchoring
分散モビリティ固定
Abstract
概要
This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.
この文書は、IPモビリティサポートを提供するためのさまざまな構成および機能に関して、分散モビリティ固定を定義しています。ネットワークのニーズに応じて、ネットワークベースまたはホストベースのモビリティサポートの両方の分散モビリティ固定機能を使用してネットワークを構成することができます。分散型モビリティ固定環境では、IPプレフィックスアンカーの中ミッドセッション切り替えに複数のアンカーがあります。モバイルノードが新しいネットワークに移動すると、新しいフローを開始するか、IPセッションの継続性を必要としないフローを処理するには、新しいネットワークに固定された新しいIPプレフィックスから設定されたIPアドレスを使用してフローを開始または再起動することができます。フローがネットワークの変更を克服する必要がある場合、IPアドレスのモビリティを有効にするために使用できるソリューションがあります。この文書は、IPモビリティのニーズに応じて、さまざまなアンカーアプローチ、およびこのIPアドレスモビリティがネットワークによってどのように処理されるかについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are 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/rfc8818.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8818で入手できます。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions and Terminology
3. Distributed Mobility Anchoring
3.1. Configurations for Different Networks
3.1.1. Network-Based DMM
3.1.2. Client-Based DMM
4. IP Mobility Handling in Distributed Anchoring Environments:
Mobility Support Only When Needed
4.1. Nomadic Case
4.2. Mobility Case with Traffic Redirection
4.3. Mobility Case with Anchor Relocation
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
A key requirement in distributed mobility management (DMM) [RFC7333] is to enable traffic to avoid traversing a single mobility anchor far from an optimal route. This document defines different configurations, functional operations, and parameters for distributed mobility anchoring and explains how to use them to avoid unnecessarily long routes when a mobile node moves.
Distributed Mobility Management（DMM）[RFC7333]の重要な要件は、トラフィックを最適なルートから遠く離れて通過させないようにすることです。このドキュメントは、分散モビリティ固定のためのさまざまな構成、機能操作、およびパラメータを定義し、モバイルノードが移動したときに不必要に長いルートを回避するためにそれらの使用方法を説明します。
Other distributed mobility management documents already address source address selection [RFC8653] and control-plane and data-plane signaling [FPC-DMM-PROTOCOL]. A number of distributed mobility solutions have also been proposed, for example, in [DMM-DMA], [RFC8885], [DMM-WIFI], [DMM-ENHANCED-ANCHORING], and [STATELESS-UPLANE-VEPC].
他の分散モビリティ管理文書はすでにアドレスaddressソースアドレス選択[RFC8653]と制御プレーンとデータプレーンシグナリング[FPC-DMM-Protocol]。例えば、[DMM - DMA]、[RFC8885]、[DMM - WiFi]、[DMM - Enhanced-Ancharing]、および[Stateless-Uplane-Vepc]、および[Stateless-uplane-vepc]など、さまざまな分散モビリティソリューションも提案されています。
Distributed mobility anchoring employs multiple anchors in the data plane. In general, control-plane functions may be separated from data-plane functions and be centralized but may also be co-located with the data-plane functions at the distributed anchors. Different configurations of distributed mobility anchoring are described in Section 3.1.
分散モビリティ固定はデータプレーン内に複数のアンカーを使用します。一般に、制御面関数はデータ平面関数から分離され、集中化されてもよいが、分散アンカーでデータプレーン機能と同じ配置されてもよい。分散モビリティ固定の異なる構成はセクション3.1で説明されています。
As a Mobile Node (MN) attaches to an access router and establishes a link between them, a /64 IPv6 prefix anchored to the router may be assigned to the link for exclusive use by the MN [RFC6459]. The MN may then configure a global IPv6 address from this prefix and use it as the source IP address in a flow to communicate with its Correspondent Node (CN). When there are multiple mobility anchors assigned to the same MN, an address selection for a given flow is first required before the flow is initiated. Using an anchor in an MN's network of attachment has the advantage that the packets can simply be forwarded according to the forwarding table. However, after the flow has been initiated, the MN may later move to another network that assigns a new mobility anchor to the MN. Since the new anchor is located in a different network, the MN's assigned prefix does not belong to the network where the MN is currently attached.
モバイルノード（MN）がアクセスルータに接続されてそれらの間のリンクを確立し、ルータに固定されたA / 64 IPv6プレフィックスは、MN [RFC6459]による排他的使用のためのリンクに割り当てることができる。その後、MNはこの接頭辞からグローバルIPv6アドレスを構成し、それをSOURCE IPアドレスとして使用して、そのコレスポンデントノード（CN）と通信する。同じMNに割り当てられた複数のモビリティアンカーがある場合、フローが開始される前に所与のフローに対するアドレス選択が最初に必要とされる。MNの添付ファイルのネットワークでアンカーを使用することは、パケットが単に転送テーブルに従って転送されることができるという利点を有する。しかしながら、フローが開始された後、MNは後で新しいモビリティアンカーをMNに割り当てる別のネットワークに移動することができる。新しいアンカーは異なるネットワークにあるので、MNの割り当てられたプレフィックスはMNが現在接続されているネットワークに属していません。
When the MN wants to continue using its assigned prefix to complete ongoing data sessions after it has moved to a new network, the network needs to provide support for the MN's IP address and session continuity, since routing packets to the MN through the new network deviates from applying default routes. The IP session continuity needs of a flow (application) determine how the IP address used by this flow has to be anchored. If the ongoing IP flow can cope with an IP prefix/address change, the flow can be reinitiated with a new IP address anchored in the new network. On the other hand, if the ongoing IP flow cannot cope with such change, mobility support is needed. A network supporting a mix of flows both requiring and not requiring IP mobility support will need to distinguish these flows.
MNが割り当てられたプレフィックスを使用して新しいネットワークに移動した後に進行中のデータセッションを完了したい場合、ネットワークは新しいネットワークを介してMNを介してMNにルーティングするため、MNのIPアドレスとセッションの継続性をサポートする必要があります。デフォルトルートの適用から。フロー（アプリケーション）のIPセッション継続ニーズは、このフローによって使用されるIPアドレスをどのように固定しなければならないかを決定します。進行中のIPフローがIPプレフィックス/アドレスの変更に対処できる場合は、新しいネットワークに固定されている新しいIPアドレスでフローを再起動できます。一方、進行中のIPフローがそのような変更に対処できない場合、モビリティサポートが必要です。IP Mobility Supportを必要としていないフローの組み合わせをサポートするネットワークは、これらのフローを区別する必要があります。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 (MIPv6) base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) specification [RFC5213], the Mobility Terminology document [RFC3753], and the DMM Current Practices and Gap Analysis document [RFC7429]. These include terms such as Mobile Node (MN), Correspondent Node (CN), Home Agent (HA), Home Address (HoA), Care-of-Address (CoA), Local Mobility Anchor (LMA), and Mobile Access Gateway (MAG).
この文書で使用されているすべての一般的なモビリティ関連の用語とその頭字語は、モバイルIPv6（MIPv6）基本仕様[RFC6275]、プロキシモービルIPv6（PMIPv6）仕様[RFC5213]、MOBC5213 [RFC3753]で定義されています。]、およびDMMの電流慣行とギャップ解析文書[RFC7429]。これらには、モバイルノード（MN）、コレスポンションノード（CN）、ホームエージェント（HA）、ホームアドレス（HOA）、ケアアドレス（COA）、ローカルモビリティアンカー（LMA）、およびモバイルアクセスゲートウェイなどの用語が含まれます。マグ）。
In addition, this document uses the following terms and definitions:
さらに、この文書では次の用語と定義を使用しています。
IP session continuity: The ability to maintain an ongoing transport interaction by keeping the same local endpoint IP address throughout the lifetime of the IP socket despite the mobile host changing its point of attachment within the IP network topology. The IP address of the host may change after closing the IP socket and before opening a new one, but that does not jeopardize the ability of applications using these IP sockets to work flawlessly. Session continuity is essential for mobile hosts to maintain ongoing flows without any interruption [RFC8653].
IPセッションの継続性：モバイルホストがIPネットワークトポロジ内の添付ファイルを変更するにもかかわらず、同じローカルエンドポイントIPアドレスをIPソケットの有効期間にわたって保持することによって、継続的なトランスポートインタラクションを維持する機能。ホストのIPアドレスは、IPソケットを閉じて新しいものを開く前に変更されることがありますが、これらのIPソケットを使用してアプリケーションが完全に機能する機能を危険にさらさない場合があります。セッションの継続性は、モバイルホストが中断のないフローを維持するために不可欠です[RFC8653]。
Higher-layer session continuity: The ability to maintain an ongoing transport- or higher-layer (e.g., application) interaction by keeping the session identifiers throughout the lifetime of the session despite the mobile host changing its point of attachment within the IP network topology. This can be achieved by using mechanisms at the transport or higher layers.
より高い層のセッションの継続性：MobileホストがIPネットワークトポロジ内の添付要点を変更するにもかかわらず、セッション識別子をセッションの有効期間にわたって保持することによって、進行中のトランスポートまたは上位層（例えば、アプリケーション）の対話を維持する機能。これは、輸送または上位層でメカニズムを使用することによって達成することができる。
IP address reachability: The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent sessions, even in the absence of any session. The IP address may be published in a long-term registry (e.g., DNS) and is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP addresses [RFC8653].
IPアドレス到達可能性：長期間同じIPアドレスを維持する機能。セッションがない場合でも、IPアドレスは独立したセッション間で同じままです。IPアドレスは、長期レジストリ（例えば、DNS）に公開されてもよく、着信（例えば、TCP）接続を提供するために利用可能にされる。IPアドレスの到達可能性は、モバイルホストに特定/公開IPアドレスを使用することが不可欠です[RFC8653]。
IP mobility: The combination of IP address reachability and session continuity.
IPモビリティ：IPアドレス到達可能性とセッションの継続性の組み合わせ。
Anchoring (of an IP prefix/address): An IP prefix (i.e., Home Network Prefix (HNP)) or address (i.e., HoA) assigned for use by an MN is topologically anchored to an anchor node when the anchor node is able to advertise a route into the routing infrastructure for the assigned IP prefix. The traffic using the assigned IP address/prefix must traverse the anchor node. We can refer to the function performed by the IP anchor node as anchoring, which is a data-plane function.
アンカリング（IPプレフィックス/アドレスの）：Anchorノードができるようにできるようにすることができるときに、MNによる使用が割り当てられたIPプレフィックス（IE、ホームネットワークプレフィックス（HNP））またはアドレス（すなわち、HOA）がトポロジでアンカーノードに固定される。割り当てられたIPプレフィックスのルーティングインフラストラクチャへのルートをアドバタイズします。割り当てられたIPアドレス/プレフィックスを使用したトラフィックは、アンカーノードをトラバースする必要があります。IPアンカーノードが実行する機能を、データプレーン機能である固定として参照できます。
Location Management (LM) function: A control-plane function that keeps and manages the network location information of an MN. The location information may be a binding of the advertised IP address/prefix (e.g., HoA or HNP) to the IP routing address of the MN or of a node that can forward packets destined to the MN.
位置管理（LM）機能MNのネットワーク位置情報を保持して管理する制御プレーン機能。位置情報は、送信されたIPアドレス/プレフィックス（例えば、HOAまたはHNP）のバインディングであり得る.MNまたはMN宛てのパケットを転送することができるノードまたはノードのIPルーティングアドレスにすることができる。
When the MN is a Mobile Router (MR), the location information will also include the Mobile Network Prefix (MNP), which is the aggregate IP prefix delegated to the MR to assign IP prefixes for use by the Mobile Network Nodes (MNNs) in the mobile network.
MNがモバイルルータ（MR）である場合、位置情報にはモバイルネットワークプレフィックス（MNP）が含まれます。これは、MRに委任して、モバイルネットワークノード（MNNS）で使用するためのIPプレフィックスを割り当てるためのMRに委任されている集計IPプレフィックスです。モバイルネットワーク
In a client-server protocol model, secure (i.e., authenticated and authorized) location query and update messages may be exchanged between a Location Management client (LMc) and a Location Management server (LMs), where the location information can be updated or queried from the LMc. Optionally, there may be a Location Management proxy (LMp) between LMc and LMs.
クライアント - サーバプロトコルモデルでは、安全な（すなわち、認証および許可された）ロケーションクエリおよび更新メッセージは、位置情報管理クライアント（LMC）と位置管理サーバ（LMS）との間で交換され、そこで位置情報を更新または照会することができる。LMCから。必要に応じて、LMCとLMSの間にロケーション管理プロキシ（LMP）があります。
With separation of control plane and data plane, the LM function is in the control plane. It may be a logical function at the control-plane node, control-plane anchor, or mobility controller.
制御面とデータ面の分離により、LM関数は制御面内にある。それは、制御面ノード、制御プレーンアンカー、またはモビリティコントローラの論理関数であり得る。
It may be distributed or centralized.
分散または集中化されている可能性があります。
Forwarding Management (FM) function: Packet interception and forwarding to/from the IP address/prefix assigned for use by the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination.
転送管理（FM）関数：インターネットワークの位置情報に基づいて、インターネットワークの位置情報に基づいて、パケットの転送方法を知っている他のネットワーク要素のどちらかに基づいて、MNが使用するために割り当てられたIPアドレス/プレフィックスへのパケット遮断と転送彼らの目的地へ。
This function may be used to achieve traffic indirection. With separation of control plane and data plane, the FM function may split into an FM function in the data plane (FM-DP) and an FM function in the control plane (FM-CP).
この機能はトラフィック間接を達成するために使用されてもよい。制御面とデータプレーンの分離により、FM関数はデータプレーン（FM - DP）内のFM関数と制御プレーン（FM - CP）内のFM関数に分割することができる。
FM-DP may be distributed with distributed mobility management. It may be a function in a data-plane anchor or data-plane node.
FM-DPは分散型モビリティ管理で分散させることができます。データプレーンアンカーまたはデータプレーンノード内の関数でもよい。
FM-CP may be distributed or centralized. It may be a function in a control-plane node, control-plane anchor, or mobility controller.
FM-CPは分散または集中化されています。それは、制御面ノード、制御プレーンアンカー、またはモビリティコントローラ内の関数であり得る。
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 a mobile node, and those sessions may be anchored on the same or different Home-CPA's. 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のモビリティセッションをホストします。モバイルノードのための複数のモビリティセッションがある可能性があり、それらのセッションは同じまたは異なる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 address/prefix(es). The Home-DPA is chosen by the Home-CPA on a session basis. The Home-DPA is in the forwarding path for all the mobile node's IP traffic.
ホームデータプレーンアンカー（Home-DPAまたはH-DPA）：HOME-DPAは、MNのIPアドレス/プレフィックスのトポロジーアンカーです。HOME-DPAは、セッションベースでホームCPAによって選択されます。HOME-DPAは、すべてのモバイルノードのIPトラフィックの転送パスにあります。
Access Control-Plane Node (Access-CPN or A-CPN): The Access-CPN is responsible for interfacing with the mobile node's Home-CPA and with the Access-DPN. The Access-CPN has a protocol interface to the Home-CPA.
アクセス制御プレーンノード（ACCESS-CPNまたはA-CPN）：ACCESS-CPNは、モバイルノードのホーム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 mobile node is attached. This function is not hosted on a Layer 2 bridging device such as an eNode(B) or Access Point.
アクセスデータプレーンノード（ACCESS-DPNまたはA-DPN）：ACCESS-DPN関数は、モバイルノードが接続されているファーストホップルータでホストされています。この関数は、eノード（B）やアクセスポイントなどのレイヤ2ブリッジングデバイスではホストされていません。
We next describe some configurations with multiple distributed anchors. To cover the widest possible spectrum of scenarios, we consider architectures in which the control and data planes are separated. We analyze where LM and FM functions, which are specific sub-functions involved in mobility management, can be placed when looking at the different scenarios with distributed anchors.
次に、複数の分散アンカーを持ついくつかの構成について説明します。可能な限り広いシナリオのスペクトルをカバーするために、制御とデータプレーンが分離されているアーキテクチャを検討します。Mobility Managementに含まれる特定のサブ機能であるLMおよびFM機能がある場所を分析し、分散アンカーを含むさまざまなシナリオを見ているときに配置できます。
Figure 1 shows a general scenario for network-based distributed mobility management.
図1は、ネットワークベースの分散モビリティ管理のための一般的なシナリオを示しています。
The main characteristics of a network-based DMM solution are:
ネットワークベースのDMMソリューションの主な特性は次のとおりです。
* There are multiple data-plane anchors, each with an FM-DP function.
* FM-DP機能を持つ複数のデータプレーンアンカーがあります。
* The control plane may either be distributed (not shown in the figure) or centralized (as shown in the figure).
* 制御面は、分散されていても集中化されていてもよい（図に示すように）。
* The Control-Plane Anchor (CPA) and the Data Plane Anchor (DPA) may or may not be co-located. If the CPA is co-located with the distributed DPAs, then there are multiple co-located CPA-DPA instances (not shown in the figure).
* 制御面アンカー（CPA）およびデータプレーンアンカー（DPA）は、同じ場所に配置されていてもいなくてもよい。CPAが分散型DPASと同じ場所にある場合は、複数の同じCO-PROUND CPA-DPAインスタンス（図には示されていません）があります。
* An IP prefix/address IP1 (anchored to the DPA with IP address IPa1) is assigned for use to an MN. The MN uses this IP1 address to communicate with CNs (not shown in the figure).
* IPプレフィックス/アドレスIP1（IPアドレスIPA1を含むDPAに固定されている）は、MNに使用するために割り当てられます。MNはこのIP1アドレスを使用してCNSと通信します（図には示されていません）。
* The location management (LM) function may be co-located or split (as shown in the figure) into a separate server (LMs) and a client (LMc). In this case, the LMs may be centralized whereas the LMc may be distributed or centralized.
* 位置管理（LM）関数は、（図に示すように）別のサーバ（LMS）とクライアント（LMC）に（図に示すように）共同場所または分割されていてもよい。この場合、LMSは集中化されてもよく、LMCは分散されても集中化されてもよい。
____________ Network
___/ \___________
/ +-----+ \___
( |LMs | Control- \
/ +-.---+ plane \
/ +--------.---+ functions \
( |CPA: . | in the )
( |FM-CP, LMc | network )
( +------------+ \
/ . . \
( . . )
( . . )
( . . \
\ +------------+ +------------+Distributed )
( |DPA(IPa1): | |DPA(IPa2): |DPAs )
( |anchors IP1 | |anchors IP2 | _/
\ |FM-DP | |FM-DP | etc. /
\ +------------+ +------------+ /
\___ Data-plane _____/
\______ functions /
\__________________/
+------------+
|MN(IP1) | Mobile node attached
|flow(IP1,..)| to the network
+------------+
Figure 1: Network-Based DMM Configuration
図1：ネットワークベースのDMM構成
Figure 2 shows a general scenario for client-based distributed mobility management. In this configuration, the mobile node performs Control-Plane Node (CPN) and Data-Plane Node (DPN) mobility functions, namely the forwarding management and location management (client) roles.
図2は、クライアントベースの分散モビリティ管理のための一般的なシナリオを示しています。この構成では、モバイルノードは、制御プレーンノード（CPN）およびデータプレーンノード（DPN）モビリティ関数、すなわち転送管理および位置管理（クライアント）の役割を実行する。
+-----+
|LMs |
+-.---+
+--------.---+
|CPA: . |
|FM-CP, LMp |
+------------+
. .
. .
. .
. .
+------------+ +------------+ Distributed
|DPA(IPa1): | |DPA(IPa2): | DPAs
|anchors IP1 | |anchors IP2 |
|FM-DP | |FM-DP | etc.
+------------+ +------------+
+------------+
|MN(IP1) |Mobile node
|flow(IP1,..)|using IP1
|FM, LMc |anchored to
+------------+DPA(IPa1)
Figure 2: Client-Based DMM Configuration
図2：クライアントベースのDMM構成
4. IP Mobility Handling in Distributed Anchoring Environments: Mobility Support Only When Needed
4. 分散固定環境におけるIPモビリティ処理：Mobilityサポートが必要な場合にのみ
IP mobility support may be provided only when needed instead of being provided by default. Three cases can be considered:
IPモビリティサポートは、デフォルトで提供されるのではなく、必要な場合にのみ提供されます。3つのケースが考慮されます。
* Nomadic case: No address continuity is required. The IP address used by the MN changes after a movement and traffic using the old address is disrupted. If session continuity is required, then it needs to be provided by a solution running at Layer 4 or above.
* 遊牧民の場合：アドレスの継続性が必要ありません。MNによって使用されるIPアドレスは、移動後、古いアドレスを使用してトラフィックが中断された後に変わります。セッションの継続性が必要な場合は、レイヤ4以上で実行されているソリューションによって提供される必要があります。
* Mobility case with traffic redirection: Address continuity is required. When the MN moves, the previous anchor still anchors the traffic using the old IP address and forwards it to the new MN's location. The MN obtains a new IP address anchored to the new location and preferably uses it for new communications established while connected at the new location.
* トラフィックリダイレクトのモビリティケース：アドレスの継続性が必要です。MNが移動すると、以前のアンカーは依然として古いIPアドレスを使用してトラフィックをアンカーし、それを新しいMNの場所に転送します。MNは新しい場所に固定された新しいIPアドレスを取得し、新しい場所で接続されている間に確立された新しい通信に使用するのが好ましい。
* Mobility case with anchor relocation: Address continuity is required. In this case, the route followed by the traffic is optimized by using some means for traffic indirection to deviate from default routes.
* アンカー再配置のモビリティケース：アドレスの継続性が必要です。この場合、トラフィックが続くルートは、トラフィック間接がデフォルトのルートから逸脱するためにいくつかの手段を使用することによって最適化されます。
A straightforward choice of mobility anchoring is the following: the MN chooses, as a source IP address for packets belonging to an IP flow, an address allocated by the network the MN is attached to when the flow was initiated. As such, traffic belonging to this flow traverses the MN's mobility anchor [DMM-DMA] [RFC8885].
Mobility Anchoringの簡単な選択肢は、次のとおりです.Mnは、IPフローに属するパケットの送信元IPアドレスとして、ネットワークによって割り当てられたアドレスをフローが開始されたときに接続されているアドレスを選択します。そのため、このフローに属するトラフィックは、MNのモビリティアンカー[DMM-DMA] [RFC8885]を横切る。
The IP prefix/address at the MN's side of a flow may be anchored to the Access Router (AR) to which the MN is attached. For example, when an MN attaches to a network (Net1) or moves to a new network (Net2), an IP prefix from the attached network is assigned to the MN's interface. In addition to configuring new link-local addresses, the MN configures from this prefix an IP address that is typically a dynamic IP address (meaning that this address is only used while the MN is attached to this access router, so the IP address configured by the MN dynamically changes when attaching to a different access network). It then uses this IP address when a flow is initiated. Packets from this flow addressed to the MN are simply forwarded according to the forwarding table.
フローのMN側のIPプレフィックス/アドレスは、MNが接続されているアクセスルータ（AR）に固定されてもよい。たとえば、MNがネットワーク（Net1）に接続されるか、または新しいネットワーク（Net2）に移動すると、接続されているネットワークからのIPプレフィックスがMNのインターフェイスに割り当てられます。新しいリンクローカルアドレスの設定に加えて、MNはこの接頭辞から、通常は動的IPアドレスであるIPアドレス（このアドレスがこのアクセスルータに接続されている間にのみ使用されるため、次のように構成されていることを意味します。Mnは別のアクセスネットワークに接続すると動的に変わります。フローが開始されたら、このIPアドレスを使用します。このフローからのパケットMnにアドレス指定されたパケットは、転送テーブルに従って単純に転送されます。
There may be multiple IP prefixes/addresses that an MN can select when initiating a flow. They may be from the same access network or different access networks. The network may advertise these prefixes with cost options [PREFIX-COST] so that the mobile node may choose the one with the least cost. In addition, the IP prefixes/addresses provided by the network may be of different types regarding whether mobility support is supported [RFC8653]. An MN will need to choose which IP prefix/address to use for each flow according to whether or not it needs IP mobility support, for example, using the mechanisms described in [RFC8653].
フローを開始するときにMNが選択できる複数のIPプレフィックス/アドレスがあるかもしれません。それらは、同じアクセスネットワークまたは異なるアクセスネットワークからのものであり得る。ネットワークは、コストオプション[プレフィックスコスト]でこれらのプレフィックスをアドバタイズすることができ、モバイルノードが最も少ないコストで1つを選択することができる。さらに、ネットワークによって提供されるIPプレフィックス/アドレスは、モビリティサポートがサポートされているかどうかに関して異なるタイプであり得る[RFC8653]。MNは、[RFC8653]に記載されているメカニズムを使用して、IPモビリティサポートが必要かどうかに応じて、各フローに対して使用するIPプレフィックス/アドレスを使用する必要があります。
When IP mobility support is not needed for a flow, the LM and FM functions are not utilized so that the configurations in Section 3.1 are simplified as shown in Figure 3.
IPモビリティサポートがフローに必要でない場合、LMおよびFM関数は使用されず、セクション3.1の構成は図3に示すように単純化されます。
Net1 Net2
Net1 Net2
+---------------+ +---------------+
|AR1 | AR is changed |AR2 |
+---------------+ -------> +---------------+
|CPA: | |CPA: |
|---------------| |---------------|
|DPA(IPa1): | |DPA(IPa2): |
|anchors IP1 | |anchors IP2 |
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2) |
.flow(IP1,...) . =======> |flow(IP2,...) |
+...............+ +---------------+
Figure 3: Changing to a New IP Address/Prefix
図3：新しいIPアドレスへの変更/プレフィックス
When there is no need to provide IP mobility to a flow, the flow may use a new IP address acquired from a new network as the MN moves to the new network.
IPモビリティをフローに提供する必要がない場合、フローは新しいネットワークに移動するにつれて新しいネットワークから取得された新しいIPアドレスを使用することができる。
Regardless of whether or not IP mobility is needed, if the flow has not terminated before the MN moves to a new network, the flow may subsequently restart using the new IP address assigned from the new network.
IPモビリティが必要かどうかにかかわらず、MNが新しいネットワークに移動する前にフローが終了していない場合、その後、新しいネットワークから割り当てられた新しいIPアドレスを使用してフローは再起動することがあります。
When IP session continuity is needed, even if an application flow is ongoing as the MN moves, it may still be desirable for the application flow to change to using the new IP prefix configured in the new network. The application flow may then be closed at the IP level and then be restarted using a new IP address configured in the new network. Such a change in the IP address used by the application flow may be enabled using a higher-layer mobility support that is not in the scope of this document.
IPセッションの継続性が必要な場合は、MNが移動するにつれてアプリケーションフローが進行中であっても、アプリケーションフローが新しいネットワークで設定されている新しいIPプレフィックスを使用するには依然として望ましい場合があります。その後、アプリケーションフローはIPレベルで閉じられてから、新しいネットワークで設定されている新しいIPアドレスを使用して再起動されます。アプリケーションフローによって使用されるIPアドレスのそのような変更は、この文書の範囲内にはない上位層のモビリティサポートを使用して有効にされてもよい。
In Figure 3, a flow initiated while the MN was using the IP prefix IP1, anchored to a previous access router AR1 in network Net1, has terminated before the MN moves to a new network Net2. After moving to Net2, the MN uses the new IP prefix IP2, anchored to a new access router AR2 in network Net2, to start a new flow. Packets may then be forwarded without requiring IP-layer mobility support.
図3では、ネットワークNet1内の前のアクセスルータAR1に固定されたIPプレフィックスIP1を使用している間に、MNがIPプレフィックスIP1を使用している間に開始されたフローは、MNが新しいネットワークNET2に移動する前に終了しました。NET2に移動した後、MNはNew IPプレフィックスIP2を使用し、ネットワークNet2の新しいアクセスルータAR2に固定して新しいフローを開始します。その後、IP層モビリティサポートを必要とせずにパケットを転送することができます。
An example call flow is outlined in Figure 4. An MN attaches to AR1, which sends a router advertisement (RA) including information about the prefix assigned to the MN, from which the MN configures an IP address (IP1). This address is used for new communications, for example, with a correspondent node (CN). If the MN moves to a new network and attaches to AR2, the process is repeated (the MN obtains a new IP address, IP2, from AR2). Since the IP address (IP1) configured at the previously visited network is not valid at the current attachment point, any existing flows have to be reestablished using IP2.
コールフローの例を図4に概説します.MnはAR1に添付されています。これは、MNに割り当てられているプレフィックスに関する情報を含むルータアドバタイズメント（RA）を送信します。そこからMNはIPアドレス（IP1）を構成します。このアドレスは、例えば、コレスポンデントノード（CN）を使用して、新しい通信に使用されます。MNが新しいネットワークに移動してAR2に添付されている場合、プロセスは繰り返されます（MnはAR2から新しいIPアドレスIP2を取得します）。以前に訪問されたネットワークで構成されているIPアドレス（IP1）は現在の添付ポイントでは無効であるため、IP2を使用して既存のフローを再確立する必要があります。
Note that in these scenarios, if there is no mobility support provided by Layer 4 or above, application traffic would stop.
これらのシナリオでは、レイヤ4以上で提供されるモビリティサポートがない場合、アプリケーショントラフィックは停止します。
MN AR1 AR2 CN
|MN attaches to AR1: | | |
|acquires MN-ID and profile | |
|--RS---------------->| | |
| | | |
|<----------RA(IP1)---| | |
| | | |
Assigned prefix IP1 | | |
IP1 address configuration | |
| | | |
|<-Flow(IP1,IPcn,...)-+------------------------------------------>|
| | | |
|MN detaches from AR1 | | |
|MN attaches to AR2 | | |
| | | |
|--RS------------------------------>| |
| | | |
|<--------------RA(IP2)-------------| |
| | | |
Assigned prefix IP2 | | |
IP2 address configuration | |
| | | |
|<-new Flow(IP2,IPcn,...)-----------+---------------------------->|
| | | |
Figure 4: Restarting a Flow with New IP Prefix/Address
図4：新しいIPプレフィックス/アドレスを使用したフローの再起動
When IP mobility is needed for a flow, the LM and FM functions in Section 3.1 are utilized. There are two possible cases: (i) the mobility anchor remains playing that role and forwards traffic to a new locator in the new network, and (ii) the mobility anchor (data-plane function) is changed but binds the MN's transferred IP address/ prefix. The latter enables optimized routes but requires some data-plane node that enforces traffic indirection. We focus on the first case in this section. The second case is addressed in Section 4.3.
フローにIPモビリティが必要な場合は、セクション3.1のLM機能とFM機能が利用されます。2つの可能なケースがあります。（i）新しいネットワーク内の新しいロケータにトラフィックを再生し、その役割を再生し続け、（ii）モビリティアンカー（データプレーン機能）が変更されますが、MNの転送されたIPアドレスをバインドします。/プレフィックス。後者は最適化されたルートを有効にしますが、トラフィック間の間接を強制するデータプレーンノードを必要とします。このセクションの最初のケースに焦点を当てています。2番目のケースはセクション4.3でアドレス指定されています。
Mobility support can be provided by using mobility management methods, such as the approaches surveyed in the following academic papers: [IEEE-DISTRIBUTED-MOBILITY], [PMIP-DMA], and [DMM-MOBILE-INTERNET]. After moving, a certain MN's traffic flow may continue using the IP prefix from the prior network of attachment. Yet, some time later, the application generating this traffic flow may be closed. If the application is started again, the new flow may not need to use the prior network's IP address to avoid having to invoke IP mobility support. This may be the case where a dynamic IP prefix/address, rather than a permanent one, is used. Packets belonging to this flow may then use the new IP prefix (the one allocated in the network where the flow is being initiated). Routing is again kept simpler without employing IP mobility and will remain so as long as the MN, which is now in the new network, does not move again to another network.
モビリティサポートは、次の学術論文で調査されたアプローチなどのモビリティ管理方法を使用して提供することができます。[IEEE分散型モビリティ]、[PMIP-DMA]、[DMMモバイルインターネット]。移動後、特定のMNのトラフィックフローは、添付ファイルの先行ネットワークからIPプレフィックスを使用し続けることがあります。それでも、後でこのトラフィックフローを生成するアプリケーションは閉じることができます。アプリケーションが再度開始されると、新しいフローはIP Mobilityサポートを呼び出す必要がないように、以前のネットワークのIPアドレスを使用する必要がないかもしれません。これは、永続的なものではなく動的IPプレフィックス/アドレスが使用されている場合であり得る。このフローに属するパケットは、新しいIPプレフィックス（フローが開始されているネットワークに割り当てられているもの）を使用することができます。IPモビリティを採用せずにルーティングは再びより簡単に保たれ、現在新しいネットワークにあるMNが別のネットワークに再び移動しない限り、そのままになります。
An example call flow in this case is outlined in Figure 5. In this example, the AR1 plays the role of the FM-DP entity and redirects the traffic (e.g., using an IP tunnel) to AR2.
この場合のコールフローの例は図5に概説されています。この例では、AR1はFM-DPエンティティの役割を再生し、トラフィック（たとえばIPトンネルを使用）にリダイレクトします。
MN AR1 AR2 CN
|MN attaches to AR1: | | |
|acquires MN-ID and profile | |
|--RS---------------->| | |
| | | |
|<----------RA(IP1)---| | |
| | | |
Assigned prefix IP1 | | |
IP1 address configuration | |
| | | |
|<-Flow(IP1,IPcn,...)-+------------------------------------------>|
| | | |
|MN detaches from AR1 | | |
|MN attaches to AR2 | | |
| | | |
|--RS------------------------------>| |
(some IP mobility support solution)
|<--------------RA(IP2,IP1)---------| |
| | | |
| +<-Flow(IP1,IPcn,...)---------------------->|
| +<===========>+ |
|<-Flow(IP1,IPcn,...)-------------->+ |
| | | |
Assigned prefix IP2 | | |
IP2 address configuration | |
| | | |
Flow(IP1,IPcn) terminates | |
| | | |
|<-new Flow(IP2,IPcn,...)-----------+---------------------------->|
| | | |
Figure 5: Flow Using IP Prefix from Home Network after MN has Moved
図5：MNが移動した後にホームネットワークからIPプレフィックスを使用したフロー
Another solution could be to place an FM-DP entity closer to the CN network to perform traffic steering to deviate from default routes (which will bring the packet to AR1 per default routing). The LM and FM functions are implemented as shown in Figure 6.
もう1つの解決策は、FM-DPエンティティをCNネットワークに近づけることで、デフォルトのルートから逸脱するためのトラフィックステアリング（デフォルトのルーティングごとにパケットをAR1にします）。図6に示すように、LM関数とFM関数は実装されています。
Net1 Net2
Net1 Net2
+---------------+ +---------------+
|AR1 | |AR2 |
+---------------+ +---------------+
|CPA: | |CPA: |
| | |LM:IP1 at IPa1 |
|---------------| IP1 (anchored to Net1) |---------------|
|DPA(IPa1): | is redirected to Net2 |DPA(IPa2): |
|anchors IP1 | =======> |anchors IP2 |
|FM:IP1 via IPa2| |FM:IP1 via IPa1|
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) |
. . |flow(IP2,...) |
+...............+ +---------------+
Figure 6: Anchor Redirection
図6：アンカーリダイレクト
Multiple instances of DPAs (at access routers), which are providing IP prefixes to the MNs, are needed to provide distributed mobility anchoring in an appropriate configuration such as those described in Figure 1 (Section 3.1.1) for network-based distributed mobility or in Figure 2 (Section 3.1.2) for client-based distributed mobility.
MNSにIPプレフィックスを提供しているDPAの複数のインスタンス（アクセスルータ）は、ネットワークベースの分散モビリティについて、図1（セクション3.1.1）に記載されているような適切な構成で分散モビリティの固定を提供するために必要です。クライアントベースの分散モビリティの図2（セクション3.1.2）。
We focus next on the case where the mobility anchor (data-plane function) is changed but binds the MN's transferred IP address/ prefix. This enables optimized routes but requires some data-plane node that enforces traffic indirection.
Mobility Anchor（データプレーン機能）が変更されているが、MNの転送されたIPアドレス/プレフィックスにバインドされている場合について次に焦点を当てます。これにより、最適化されたルートが可能になりますが、トラフィックの間接が強制されるデータプレーンノードが必要です。
IP mobility is invoked to enable IP session continuity for an ongoing flow as the MN moves to a new network. The anchoring of the IP address of the flow is in the home network of the flow (i.e., different from the current network of attachment). A centralized mobility management mechanism may employ indirection from the anchor in the home network to the current network of attachment. Yet, it may be difficult to avoid using an unnecessarily long route (when the route between the MN and the CN via the anchor in the home network is significantly longer than the direct route between them). An alternative is to move the IP prefix/address anchoring to the new network.
IP Mobilityは、MNが新しいネットワークに移動すると、進行中のフローに対してIPセッションの継続性を有効にするために呼び出されます。フローのIPアドレスの固定は、フローのホームネットワーク（すなわち、現在の添付ファイルネットワークとは異なる）にある。集中型モビリティ管理メカニズムは、ホームネットワーク内のアンカーから現在の添付ファイルのネットワークへの間接的なものを使用することができる。それでも、不必要に長い経路を使用することを回避することは困難であり得る（ホームネットワーク内のアンカーを介したCN間の経路がそれらの間の直接経路よりもかなり長い場合）。代わりに、IPプレフィックス/アドレス固定を新しいネットワークに移動することです。
The IP prefix/address anchoring may move without changing the IP prefix/address of the flow. The LM function in Figure 1 of Section 3.1.1 is implemented as shown in Figure 7.
IPプレフィックス/アドレス固定は、フローのIPプレフィックス/アドレスを変更せずに移動することがあります。セクション3.1.1の図1のLM機能は、図7に示すように実装されています。
Net1 Net2
Net1 Net2
+---------------+ +---------------+
|AR1 | |AR2 |
+---------------+ +---------------+
|CPA: | |CPA: |
|LM:IP1 at IPa1 | |LM:IP1 at IPa2 |
| changes to | | |
| IP1 at IPa2 | | |
|---------------| |---------------|
|DPA(IPa1): | IP1 anchoring effectively moved |DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1|
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
Figure 7: Anchor Relocation
図7：アンカー再配置
As an MN with an ongoing session moves to a new network, the flow may preserve IP session continuity by moving the anchoring of the original IP prefix/address of the flow to the new network.
進行中のセッションを有するMNが新しいネットワークに移動するにつれて、フローは、フローの元のIPプレフィックス/アドレスのアンカリングを新しいネットワークに移動させることによってIPセッションの継続性を維持することができる。
One way to accomplish such a move is to use a centralized routing protocol, but such a solution may present some scalability concerns and its applicability is typically limited to small networks. One example of this type of solution is described in [BGP-ATN-IPS]. When an MN associates with an anchor, the anchor injects the MN's prefix into the global routing system. If the MN moves to a new anchor, the old anchor withdraws the /64 and the new anchor injects it instead.
そのような移動を達成するための1つの方法は集中ルーティングプロトコルを使用することであるが、そのような解決策はいくつかのスケーラビリティに関する懸念を提示することがあり、その適用性は通常小さなネットワークに限定され得る。この種の溶液の一例を[BGP - ATN - IPS]に記載されている。MNがアンカーと関連付けると、アンカーはMNの接頭辞をグローバルルーティングシステムに注入します。MNが新しいアンカーに移動すると、古いアンカーは/ 64を引き出すと、代わりに新しいアンカーが注入されます。
As stated in [RFC7333], "a DMM solution MUST support any security protocols and mechanisms needed to secure the network and to make continuous security improvements". It "MUST NOT introduce new security risks".
[RFC7333]に記載されているように、DMMソリューションは、ネットワークを保護し、連続的なセキュリティ改善を行うために必要なセキュリティプロトコルとメカニズムをサポートしなければなりません。「新しいセキュリティリスクを紹介してはいけません」。
There are different potential deployment models of a DMM solution. The present document has presented three different scenarios for distributed anchoring: (i) nomadic case, (ii) mobility case with traffic redirection, and (iii) mobility case with anchor relocation. Each of these cases has different security requirements, and the actual security mechanisms depend on the specifics of each solution/ scenario.
DMMソリューションの潜在的な展開モデルが異なります。本文書は、分散固定のための3つの異なるシナリオを提示した：（i）遊牧民の場合、（ii）トラフィックリダイレクトを有するモビリティの場合、および（iii）アンカー再配置のモビリティケース。これらの各ケースには異なるセキュリティ要件があり、実際のセキュリティメカニズムは各ソリューション/シナリオの詳細によって異なります。
As general rules, for the first distributed anchoring scenario (nomadic case), no additional security consideration is needed, as this does not involve any additional mechanism at Layer 3. If session connectivity is required, the Layer 4 or above solution used to provide it MUST also provide the required authentication and security.
一般的な規則として、最初の分散固定シナリオ（遊牧民の場合）は、レイヤ3で追加のメカニズムを含まないので、追加のセキュリティ検討は必要ありません。セッション接続が必要な場合は、レイヤ4または上記のソリューションを提供しています。必要な認証とセキュリティも提供する必要があります。
The second and third distributed anchoring scenarios (mobility case) involve mobility signaling among the mobile node and the control-plane and data-plane anchors. The control-plane messages exchanged between these entities MUST be protected using end-to-end security associations with data-integrity and data-origination capabilities. IPsec [RFC8221] Encapsulating Security Payload (ESP) in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Internet Key Exchange Protocol Version 2 (IKEv2) [RFC8247] SHOULD be used to set up security associations between the data-plane and control-plane anchors. Note that in scenarios in which traffic indirection mechanisms are used to relocate an anchor, authentication and authorization mechanisms MUST be used.
第2および第3の分散固定シナリオ（モビリティケース）は、モバイルノードと制御面とデータプレーンアンカーとの間のモビリティシグナリングを含む。これらのエンティティ間で交換されるコントロールプレーンメッセージは、データ整合性とデータ発信機能を備えたエンドツーエンドのセキュリティアソシエーションを使用して保護する必要があります。IPSec [RFC8221]トランスポートモードでセキュリティペイロードをカプセル化するシグナリングメッセージの保護には、トランスポートモードでのキャプセル化モードを使用してください。インターネットキー交換プロトコルバージョン2（IKEv2）[RFC8247]データプレーンと制御プレーンアンカー間のセキュリティアソシエーションを設定するために使用する必要があります。トラフィック間接メカニズムがアンカーを移転するために使用されるシナリオでは、認証および許可メカニズムを使用する必要があります。
Control-plane functionality MUST apply authorization checks to any commands or updates that are made by the control-plane protocol.
コントロールプレーン機能は、コントロールプレーンプロトコルによって行われた任意のコマンドまたは更新に許可チェックを適用する必要があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>。
[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, <https://www.rfc-editor.org/info/rfc3753>.
[RFC3753] MAY、J.、ED。2004年6月、<https://www.rfc-editor.org/info/rfc3753、<https://ww.rfc-editor.org/info/rfc3753>。
[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>。
[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>。
[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>。
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.
[RFC8221] Wouters、P.、Migaute、D.、Mattsson、J.、NIR、Y.、およびT.Kivinen、Cryptographicアルゴリズムの実装要件とセキュリティペイロード（ESP）と認証ヘッダー（AH）） "、RFC 8221、DOI 10.17487 / RFC8221、2017年10月、<https://www.rfc-editor.org/info/rfc8221>。
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, <https://www.rfc-editor.org/info/rfc8247>.
[RFC8247] NIR、Y.、Kivinen、T.、Wouters、P.、およびD. MIGAULT、「インターネット鍵交換プロトコル版2（IKEV2）」、RFC 8247、DOI 10.17487 / RFC82472017年9月、<https：//www.rfc-editor.org/info/rfc8247>。
[BGP-ATN-IPS] Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. Moreno, "A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network", Work in Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-06, 30 June 2020, <https://tools.ietf.org/html/draft-ietf-rtgwg-atn-bgp-06>.
[BGP-ATN-IPS] Templin、F.、Saccone、G.、Dawra、G.、Lindem、A.およびV. Moreno、「航空電気通信ネットワークのための単純なBGPベースのモバイルルーティングシステム」進捗状況、インターネットドラフト、ドラフト-IETF-RTGWG-ATN-BGP-06,2020、<https：//tools.ietf.org/html/draft-ietf-rtgwg-atn-bgp-06>。
[DMM-DMA] Seite, P., Bertin, P., and J. Lee, "Distributed Mobility Anchoring", Work in Progress, Internet-Draft, draft-seite-dmm-dma-07, 6 February 2014, <https://tools.ietf.org/html/draft-seite-dmm-dma-07>.
[DMM-DMA] Seate、P.、Bertin、P.、J.Lee、「分散型モビリティ固定」、進行中の作業、インターネットドラフト、ドラフトSEET-DMM-DMA-07,2014、<HTTPS：//tools.ietf.org/html/draft-seite-dmm-dma-07>。
[DMM-ENHANCED-ANCHORING] Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in Distributed Mobility Management", Work in Progress, Internet-Draft, draft-yhkim-dmm-enhanced-anchoring-05, 8 July 2016, <https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-05>.
[DMM強化固定]キム、Y.およびS.ジョン、「分散モビリティ管理におけるモビリティアンケリングの強化」、進行中の作業、インターネットドラフト、ドラフト - YHKIM-DMM強化停止-05,7月8日、<https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-chancoring-05>。
[DMM-MOBILE-INTERNET] Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues", Journal of Communications, Vol. 6, No. 1, February 2011.
[DMM-Mobile-Internet] Chan、H.、Yokota、H.、XIE、J.、Seite、P.、D. Liu、「モバイルインターネットにおける分散・動的モビリティ管理：現在のアプローチと問題」、ofコミュニケーション、vol。6、No. 1、2011年2月。
[DMM-WIFI] Sarikaya, B. and L. Li, "Distributed Mobility Management Protocol for WiFi Users in Fixed Network", Work in Progress, Internet-Draft, draft-sarikaya-dmm-for-wifi-05, 30 October 2017, <https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-05>.
[DMM-WiFi] SARIKAYA、B.およびL. L. L. L. L. L. L. L. L. L. L. L. Li、Internet-Sarikaya-DMM-for-WiFi-05,2017、<https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-05>。
[FPC-DMM-PROTOCOL] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Moses, D., and C. Perkins, "Protocol for Forwarding Policy Configuration (FPC) in DMM", Work in Progress, Internet-Draft, draft-ietf-dmm-fpc-cpdp-14, 22 September 2020, <https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-14>.
[FPC-DMM-Protocol]松島、S、Bertz、L.、Liebsch、M.、Gundavelli、S.、Moses、D.、およびC.Perkins、「DMMにおけるポリシー構成（FPC）の転送プロトコル」進行中の作業、インターネットドラフト、ドラフト - IETF-DMM-FPC-CPDP-14,22 <https：//tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-14>。
[IEEE-DISTRIBUTED-MOBILITY] Lee, J., Bonnin, J., Seite, P., and H. A. Chan, "Distributed IP mobility management from the perspective of the IETF: motivations, requirements, approaches, comparison, and challenges", IEEE Wireless Communications, vol. 20, no. 5, pp. 159-168, October 2013.
[IEEE分散型モビリティ] Lee、J.、Bonnin、J.、Seite、P.、およびHAちゃん、「IETFの観点からの分散IP Mobility Management：動機、要件、アプローチ、比較、および課題」、IEEE無線通信、Vol。20、いいえ。5、pp.159-168、2013年10月。
[PMIP-DMA] Chan, H., "Proxy mobile IP with distributed mobility anchors", IEEE Globecom Workshops Miami, FL, 2010, pp. 16-20, December 2010.
[PMIP-DMA]チャン、H。、「分散モビリティアンカー付きプロキシモバイルIP」、IEEE Globecomワークショップマイアミ、FL、2010、PP。16-20、2010年12月。
[PREFIX-COST] McCann, P. and J. Kaippallimalil, "Communicating Prefix Cost to Mobile Nodes", Work in Progress, Internet-Draft, draft-mccann-dmm-prefixcost-03, 11 April 2016, <https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-03>.
[プレフィックス - 費用] McCann、P.およびJ.KaippallimalIL、「モバイルノードへのコミュニケーションの接頭辞のコスト」、進行中の作業、インターネットドラフト、ドラフト - MCCANN-DMM-PrefixCost-03,11 4月11日、<https：//tools.ietf.org/html/draft-mccan-dmm-prefixcost-03>。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC6459] Korhonen、J.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G.、K.Iisakkila、「3世代パートナーシッププロジェクト（3GPP）進化パケットシステム（3GPP）のIPv6eps） "、RFC 6459、DOI 10.17487 / RFC6459、2012年1月、<https：//www.rfc-editor.org/info/rfc6459>。
[RFC8653] Yegin, A., Moses, D., and S. Jeon, "On-Demand Mobility Management", RFC 8653, DOI 10.17487/RFC8653, October 2019, <https://www.rfc-editor.org/info/rfc8653>.
[RFC8653] Yegin、A.、Moses、D.、S. Jeon、「オンデマンドモビリティマネジメント」、RFC 8653、DOI 10.17487 / RFC8653、2019年10月、<https：//www.rfc-editor.org/情報/ RFC8653>。
[RFC8885] Bernardos, CJ., de la Oliva, A., Giust, F., Zúñiga, JC., and A. Mourad, "Proxy Mobile IPv6 Extensions for Distributed Mobility Management", RFC 8885, DOI 10.17487/RFC8885, October 2020, <https://www.rfc-editor.org/info/rfc8885>.
[RFC8885] Bernardos、CJ、CJ、De La Oliva、A.、Giust、F.、Zúñiga、JC、およびA. Mourad、「分散モビリティ管理のためのプロキシモバイルIPv6拡張」、RFC 8885、DOI 10.17487 / RFC8885、10月2020、<https：//www.rfc-editor.org/info/rfc8885>。
[STATELESS-UPLANE-VEPC] Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", Work in Progress, Internet-Draft, draft-matsushima-stateless-uplane-vepc-06, 21 March 2016, <https://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-06>.
[ステートレス - uplane-vepc]松島、S.およびR.脇川、「仮想化EPCのためのステートレスユーザープレーンアーキテクチャ」、進行中の作業、インターネットドラフト、松島ステートレス - Uplane-Vepc-06、2016年3月21日、<https：//tools.ietf.org/html/draft-matsushima-statesless-uplane-vepc-06>。
Acknowledgements
謝辞
The work of Jong-Hyouk Lee was supported by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2020-2015-0-00403) supervised by the IITP (Institute for Information & communications Technology Planning & Evaluation).
Jong-Hyouk Leeの働きは、IITP（Institute Technology Research Center）支援プログラム（ITP-2020-2015-0-0-0403）の下で、IITP（Institute）の監督（ITP-2020-2015-0-0-00403）の下でのMSIT（ICT省）に支えられました。情報＆コミュニケーションテクノロジーの計画と評価のため。
Contributors
貢献者
Alexandre Petrescu and Fred Templin had contributed to earlier draft versions of this document regarding distributed anchoring for hierarchical networks and for network mobility, although these extensions were removed to keep the document within reasonable length.
Alexandre PetrescuおよびFred Templinは、階層ネットワークの分散固定およびネットワークモビリティに関するこの文書の旧草案に貢献していました。
This document has benefited from other work on mobility support in SDN networks, on providing mobility support only when needed, and on mobility support in enterprise networks. These works have been referenced. While some of these authors have taken the work to jointly write this document, others have contributed at least indirectly by writing these works. The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli.
この文書は、SDNネットワークでのモビリティサポートの他の作業、必要に応じてモビリティサポート、およびエンタープライズネットワークでのモビリティサポートについての他の作業から恩恵を受けています。これらの作品は参照されています。これらの作家の中には、この文書を共同で書いて作業を行っていますが、これらの作品を書くことで少なくとも間接的に貢献してきました。後者には、Philippe Bertin、Dapeng Liu、松島悟、Pierrick Seite、Jouni Korhonen、Sri Gundavelliがあります。
For completeness, some terminology from draft-ietf-dmm-deployment-models-04 has been incorporated into this document.
完全性のために、draft-ietf-dmm-deployment-models-04からのいくつかの用語がこの文書に組み込まれています。
Valuable comments have been received from John Kaippallimalil, ChunShan Xiong, Dapeng Liu, Fred Templin, Paul Kyzivat, Joseph Salowey, Yoshifumi Nishida, Carlos Pignataro, Mirja Kuehlewind, Eric Vyncke, Qin Wu, Warren Kumari, Benjamin Kaduk, Roman Danyliw, and Barry Leiba. Dirk von Hugo, Byju Pularikkal, and Pierrick Seite have generously provided careful review with helpful corrections and suggestions. Marco Liebsch and Lyle Bertz also performed very detailed and helpful reviews of this document.
John Kaippallimal、Chunshan Xiong、Dapeng Liu、Fred Templin、Joseph Salowey、Joseph Salowey、Carlos Pignataro、Mirja Kuehlewind、Qin Wu、Roman Danyliw、Barry、Benjamin KaDuk、Carja Kuehlewind、Carlos Pignataro、Carlos Pignataro、Carlos Pignataro、Carlos Pignataro、Carlos Pignataroライバ。Dirk Von Hugo、Byju Pulaikkal、およびPierrick Seiteは、有用な修正や提案を用いて厳選されたレビューを備えています。Marco LiebschとLyle Bertzもこの文書の非常に詳細で有用なレビューを行った。
Authors' Addresses
著者の住所
H. Anthony Chan (editor) Caritas Institute of Higher Education 2 Chui Ling Lane, Tseung Kwan O N.T. Hong Kong
H. Anthony Chan（編集）カリタス高等教育研究所2 Chui Ling Lane、Tseung Kwan O N.T.香港
Email: h.a.chan@ieee.org
Xinpeng Wei Huawei Technologies Xin-Xi Rd. No. 3, Haidian District Beijing, 100095 China
Xinpeng Wei Huawei Technologies Xin-Xi RD。第3号、Haidian District Beijing、100095年中国
Email: weixinpeng@huawei.com
Jong-Hyouk Lee Sejong University 209, Neungdong-ro, Gwangjin-gu Seoul 05006 Republic of Korea
Jong-Hyouk Lee Sejong University 209、Neungdong-ro、Gwangjin-Guソウル05006韓国共和国
Email: jonghyouk@sejong.ac.kr
Seil Jeon Sungkyunkwan University 2066 Seobu-ro, Jangan-gu Suwon, Gyeonggi-do Republic of Korea
Seil Jeon Sungkyunkwan University 2066韓国京畿道Jangan-Gu Suwon、Seobu-Ro
Email: seiljeon.ietf@gmail.com
Carlos J. Bernardos (editor) 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、マドリードスペイン
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/