[要約] RFC 8191は、Proxy Mobile IPv6（PMIPv6）におけるホームネットワークプレフィックスの再番号付けに関する規格です。このRFCの目的は、PMIPv6ネットワークでのホームネットワークプレフィックスの再番号付け手順を定義することです。
Internet Engineering Task Force (IETF) Z. Yan
Request for Comments: 8191 CNNIC
Category: Standards Track J. Lee
ISSN: 2070-1721 Sangmyung University
X. Lee
CNNIC
August 2017
Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)
プロキシモバイルIPv6（PMIPv6）でのホームネットワークプレフィックスの再番号付け
Abstract
概要
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.
基本的なプロキシモバイルIPv6（PMIPv6）仕様では、モバイルノード（MN）の初期接続時にホームネットワークプレフィックス（HNP）が割り当てられ、MNはHNPを使用してホームアドレス（HoA）を構成します。 MNの移動中、HNPは変化せず、HoAに関連する継続的な通信を維持します。ただし、現在のPMIPv6仕様では、HNPの再番号付けが発生した場合の関連操作は指定されていません（たとえば、サービスプロバイダーやサイトトポロジの変更が原因で）。このドキュメントでは、PMIPv6仕様のオプションの拡張として、HNP再番号付けをサポートするソリューションが提案されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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 http://www.rfc-editor.org/info/rfc8191.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8191で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 4
4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 6
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
At the time of writing, network managers prefer Provider-Independent (PI) addressing for IPv6 to attempt to minimize the need for future possible renumbering. However, a widespread use of PI addresses will cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It is thus desirable to develop tools and practices that make IPv6 renumbering a simpler process to reduce demand for IPv6 PI space [RFC6879]. In this document, we aim to support HNP renumbering when the HNP in PMIPv6 [RFC5213] is not a PI prefix.
これを書いている時点では、ネットワーク管理者はIPv6のプロバイダーに依存しない（PI）アドレッシングを優先して、将来の可能な再番号付けの必要性を最小限に抑えようとしています。ただし、PIアドレスを広く使用すると、ボーダーゲートウェイプロトコル（BGP）スケーリングの問題が発生します[RFC7010]。したがって、IPv6の再番号付けをより単純なプロセスにしてIPv6 PIスペースの需要を減らすツールと手法を開発することが望ましい[RFC6879]。このドキュメントでは、PMIPv6 [RFC5213]のHNPがPIプレフィックスでない場合に、HNPの再番号付けをサポートすることを目指しています。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
There are a number of reasons why HNP renumbering support in PMIPv6 is useful, and some scenarios are identified below:
PMIPv6でのHNP再番号付けのサポートが役立つ理由はいくつかあり、いくつかのシナリオを以下に示します。
Scenario 1: the HNP set used by a PMIPv6 service provider is assigned by a different Internet Service Provider (ISP), and then HNP renumbering MAY occur if the PMIPv6 service provider switches to a different ISP.
シナリオ1：PMIPv6サービスプロバイダーによって使用されるHNPセットが別のインターネットサービスプロバイダー（ISP）によって割り当てられ、PMIPv6サービスプロバイダーが別のISPに切り替わると、HNP再番号付けが行われる場合があります。
Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed by the same PMIPv6 service provider, and then each LMA MAY serve for a specific HNP set. In this case, the HNP of an MN MAY change if the serving LMA is changed to another LMA that does not inherit the assigned HNP set [RFC6463].
シナリオ2：複数のローカルモビリティアンカー（LMA）が同じPMIPv6サービスプロバイダーによって展開される場合があり、各LMAが特定のHNPセットにサービスを提供する場合があります（MAY）。この場合、割り当てられたHNPセット[RFC6463]を継承しない別のLMAにサービングLMAが変更されると、MNのHNPが変更される場合があります。
Scenario 3: PMIPv6 HNP renumbering MAY be caused by the rebuilding of the network architecture as the companies split, merge, grow, relocate, or reorganize. For example, the PMIPv6 service provider MAY reorganize its network topology.
シナリオ3：PMIPv6 HNPの再番号付けは、企業の分割、統合、拡大、再配置、または再編成に伴うネットワークアーキテクチャの再構築によって発生する可能性があります。たとえば、PMIPv6サービスプロバイダーは、ネットワークトポロジを再編成する場合があります。
In Scenario 1, we assume that only the HNP is renumbered, while the serving LMA remains unchanged; this is the basic scenario considered in this document. In Scenarios 2 and 3, more complex situations MAY result; for example, HNP renumbering MAY occur due to the switchover of a serving LMA.
シナリオ1では、サービングLMAは変更されないまま、HNPのみが再番号付けされると想定しています。これは、このドキュメントで検討されている基本的なシナリオです。シナリオ2と3では、より複雑な状況が発生する可能性があります。たとえば、サービングLMAのスイッチオーバーが原因で、HNPの再番号付けが発生する場合があります。
In the Mobile IPv6 (MIPv6) protocol, when an HNP changes, the Home Agent (HA) will actively notify its MN about the new prefix, and then the renumbering of the Home Network Address (HoA) can be well supported [RFC6275]. In basic PMIPv6, the PMIPv6 binding is triggered by a Mobile Access Gateway (MAG), which detects the attachment of the MN. A scheme is also needed for the LMA to immediately initiate the PMIPv6 binding state refreshment during the HNP renumbering process. Although this issue is also mentioned in Section 6.12 of [RFC5213], the related solution has not been specified.
モバイルIPv6（MIPv6）プロトコルでは、HNPが変更されると、ホームエージェント（HA）がそのMNに新しいプレフィックスについてアクティブに通知し、ホームネットワークアドレス（HoA）の再番号付けを適切にサポートできます[RFC6275]。基本的なPMIPv6では、PMIPv6バインディングは、MNの接続を検出するモバイルアクセスゲートウェイ（MAG）によってトリガーされます。 LMAがHNP再番号付けプロセス中にPMIPv6バインディング状態の更新をすぐに開始するためのスキームも必要です。この問題は[RFC5213]のセクション6.12にも記載されていますが、関連するソリューションは指定されていません。
When HNP renumbering happens in PMIPv6, the LMA MUST notify the MAG about the new HNP, and then the MAG MUST announce the new HNP to the attached MN accordingly. Also, the LMA and the MAG MUST update the routing states for the HNP and the related addresses. To support this procedure, [RFC7077] can be adopted; it specifies an asynchronous update from the LMA to the MAG about specific session parameters. This document considers the following two cases:
HIPvリナンバリングがPMIPv6で発生した場合、LMAは新しいHNPについてMAGに通知する必要があり、MAGはそれに応じて接続されたMNに新しいHNPを通知する必要があります。また、LMAとMAGは、HNPと関連アドレスのルーティング状態を更新する必要があります。この手順をサポートするために、[RFC7077]を採用できます。特定のセッションパラメータに関するLMAからMAGへの非同期更新を指定します。このドキュメントでは、次の2つのケースについて検討します。
(1) HNP is renumbered under the same LMA
（1）HNPは同じLMAで再番号付けされます
In this case, the LMA remains unchanged as in Scenarios 1 and 3. The steps are shown in Figure 1.
この場合、LMAはシナリオ1および3と同様に変更されません。手順を図1に示します。
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
| | Allocate new HNP
| | |
| |<------------- UPN ---|
| | |
| | |
| | |
|<-----RA/DHCP --------| |
| | |
Address configuration | |
| | |
| Update binding & routing states |
| | |
| |--- UPA ------------->|
| | |
| | Update binding & routing states
| | |
Figure 1: Signaling Call Flow for HNP Renumbering
図1：HNP再番号付けのシグナリングコールフロー
o When a PMIPv6 service provider renumbers the HNP set under the same LMA, the serving LMA SHOULD initiate the HNP renumbering operation. The LMA allocates a new HNP for the related MN.
o PMIPv6サービスプロバイダーが同じLMAの下で設定されたHNPを再番号付けする場合、サービングLMAはHNP再番号付け操作を開始する必要があります（SHOULD）。 LMAは、関連するMNに新しいHNPを割り当てます。
o The LMA sends the Update Notification (UPN) message to the MAG to update the HNP information. If the Dynamic Host Configuration Protocol (DHCP) is used to allocate the address, the DHCP infrastructure MUST also be notified about the new HNP.
o LMAは、更新通知（UPN）メッセージをMAGに送信して、HNP情報を更新します。動的ホスト構成プロトコル（DHCP）を使用してアドレスを割り当てる場合は、DHCPインフラストラクチャにも新しいHNPについて通知する必要があります。
o Once the MAG receives this UPN message, it recognizes that the related MN has the new HNP. Then, the MAG MUST notify the MN about the new HNP with a Router Advertisement (RA) message or allocate a new address within the new HNP through a DHCP procedure.
o MAGはこのUPNメッセージを受信すると、関連するMNに新しいHNPがあることを認識します。次に、MAGはルーター通知（RA）メッセージで新しいHNPについてMNに通知するか、DHCP手順を通じて新しいHNP内に新しいアドレスを割り当てる必要があります。
o After the MN obtains the HNP information through the RA message, it deletes the old HoA and configures a new HoA with the newly allocated HNP.
o MNはRAメッセージを通じてHNP情報を取得した後、古いHoAを削除し、新しく割り当てられたHNPを使用して新しいHoAを構成します。
o When the new HNP is announced or the new address is configured to the MN successfully, the MAG MUST update the related binding and routing states. Then, the MAG sends back the Update Notification Acknowledgement (UPA) message to the LMA for the notification of successful update of the HNP, related binding state, and routing state. Then, the LMA updates the routing and binding information corresponding to the MN in order to replace the old HNP with the new one.
o 新しいHNPがアナウンスされるか、新しいアドレスがMNに正常に設定されると、MAGは関連するバインディングおよびルーティング状態を更新する必要があります。次に、MAGは、HNP、関連するバインディング状態、およびルーティング状態が正常に更新されたことを通知するために、Update Notification Acknowledgement（UPA）メッセージをLMAに送り返します。次に、LMAは、MNに対応するルーティングおよびバインディング情報を更新して、古いHNPを新しいものに置き換えます。
(2) HNP renumbering is caused by the LMA switchover
（2）HNPの再番号付けはLMAスイッチオーバーが原因で発生します
Since the HNP is assigned by the LMA, HNP renumbering MAY be caused by the LMA switchover, as in Scenarios 2 and 3.
HNPはLMAによって割り当てられるため、シナリオ2および3のように、LMAの切り替えによってHNPの再番号付けが発生する場合があります。
The LMA information is the basic configuration information of the MAG. When the LMA changes, the related profile SHOULD be updated by the service provider. In this way, the MAG initiates the binding registration to the MN's new LMA as specified in [RFC5213]. When HNP renumbering is caused in this case, the new HNP information is sent by the LMA during the new binding procedure. Accordingly, the MAG withdraws the old HNP of the MN and announces the new HNP to the MN, similar to the case when the HNP is renumbered under the same LMA.
LMA情報は、MAGの基本構成情報です。 LMAが変更された場合、関連するプロファイルはサービスプロバイダーによって更新される必要があります（SHOULD）。このようにして、MAGは[RFC5213]で指定されているように、MNの新しいLMAへのバインディング登録を開始します。この場合にHNP再番号付けが発生すると、新しいバインディング手順中にLMAによって新しいHNP情報が送信されます。したがって、MAGはMNの古いHNPを取り消し、新しいHNPをMNにアナウンスします。これは、同じLMAでHNPの番号が付け直される場合と同様です。
HNP renumbering MAY cause the disconnection of the ongoing communications of the MN. Basically, there are two modes to manage the session connectivity during HNP renumbering.
HNPの再番号付けにより、MNの進行中の通信が切断される場合があります。基本的に、HNP再番号付け中にセッション接続を管理する2つのモードがあります。
(1) Soft mode
（1）ソフトモード
The LMA will temporarily maintain the state of the old HNP during the HNP renumbering (after the UPA reception) in order to redirect the packets to the MN before the MN reconnects the ongoing session and notifies the Correspondent Node (CN) about its new HoA. This mode is aiming to reduce packet loss during HNP renumbering, but the binding state corresponding to the old HNP SHOULD be marked, for example, as transient binding [RFC6058]. Also, the LMA MUST stop broadcasting the routing information about the old HNP if the old HNP is no longer anchored at this LMA.
LMAは、（UPA受信後の）HNP再番号付け中に古いHNPの状態を一時的に維持し、MNが進行中のセッションに再接続してコルレスポンデントノード（CN）に新しいHoAについて通知する前に、パケットをMNにリダイレクトします。このモードは、HNP再番号付け中のパケット損失を減らすことを目的としていますが、古いHNPに対応するバインディング状態は、たとえば一時的なバインディング[RFC6058]としてマークする必要があります（SHOULD）。また、古いHNPがこのLMAにアンカーされなくなった場合、LMAは古いHNPに関するルーティング情報のブロードキャストを停止する必要があります。
(2) Hard mode
（2）ハードモード
If HNP renumbering happens with the switchover of the LMA, hard mode is RECOMMENDED to keep the protocol simple. In this mode, the LMA deletes the binding state of the old HNP after it receives the UPA message from the MAG, and the LMA silently discards the packets destined to the old HNP.
LMAのスイッチオーバーでHNP再番号付けが行われる場合、プロトコルを単純に保つためにハードモードが推奨されます。このモードでは、LMAはMAGからUPAメッセージを受信した後、古いHNPのバインディング状態を削除し、LMAは古いHNP宛てのパケットをサイレントに破棄します。
(1) UPN message
（1）UPNメッセージ
In the UPN message sent from the LMA to the MAG, the notification reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP Option [RFC5213] containing the new HNP and the Mobile Node Identifier Option [RFC4283] (which identifies the MN) are contained as Mobility Options of UPN. The order of the HNP Option and Mobile Node Identifier Option in the UPN message is not mandated here.
LMAからMAGに送信されるUPNメッセージでは、通知理由は2（UPDATE-SESSION-PARAMETERS）に設定されています。また、新しいHNPを含むHNPオプション[RFC5213]およびモバイルノード識別子オプション[RFC4283]（MNを識別する）は、UPNのモビリティオプションとして含まれています。ここでは、UPNメッセージ内のHNPオプションとモバイルノード識別子オプションの順序は必須ではありません。
(2) UPA message
（2）UPAメッセージ
The MAG sends this message in order to acknowledge that it has received an UPN message with the (A) flag set and to indicate the status after processing the message. If the MAG did not successfully renumber the HNP, which is required in the UPN message, the UPA message has the Status Code set to 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS), and the subsequent operation of the LMA is PMIPv6 service provider specific.
MAGはこのメッセージを送信して、（A）フラグが設定されたUPNメッセージを受信したことを確認し、メッセージの処理後のステータスを示します。 MAGがUPNメッセージで必要なHNPの再番号付けに失敗した場合、UPAメッセージのステータスコードは128（FAILED-TO-UPDATE-SESSION-PARAMETERS）に設定されており、LMAの後続の操作はPMIPv6サービスです。プロバイダー固有。
(3) RA message
（３） ら めっさげ
When the RA message is used by the MAG to advise the new HNP, it contains two Prefix Information Options [RFC4861] [RFC4862]. In the first Prefix Information Option, the old HNP is carried, and the related Preferred Lifetime is set to 0. In the second Prefix Information Option, the new HNP is carried with the Valid Lifetime, and Preferred Lifetime set to larger than 0.
RAメッセージがMAGによって新しいHNPに通知するために使用される場合、2つのプレフィックス情報オプション[RFC4861] [RFC4862]が含まれます。最初のプレフィックス情報オプションでは、古いHNPが使用され、関連する優先ライフタイムは0に設定されます。2番目のプレフィックス情報オプションでは、新しいHNPが有効ライフタイムで使用され、優先ライフタイムは0より大きく設定されます。
(4) DHCP message
（4）DHCPメッセージ
When the DHCP is used in PMIPv6 to configure the addresses for the MN, new IPv6 address or addresses (e.g., the HoA) will be generated based on the new HNP, and the related DHCP procedure is also triggered by the reception of the UPN message [RFC3315].
PMIPv6でDHCPを使用してMNのアドレスを構成すると、新しいHNPに基づいて1つまたは複数の新しいIPv6アドレス（HoAなど）が生成され、関連するDHCP手順もUPNメッセージの受信によってトリガーされます。 [RFC3315]。
In order to maintain the reachability of the MN, the Domain Name System (DNS) resource record corresponding to this MN MAY need to be updated when the HNP of the MN changes [RFC3007]. However, this is beyond the scope of this document.
MNの到達可能性を維持するために、このMNに対応するドメインネームシステム（DNS）リソースレコードは、MNのHNPが変更されたときに更新される必要があります[RFC3007]。ただし、これはこのドキュメントの範囲を超えています。
The UPN and UPA messages in this document MUST be protected using end-to-end security association(s) offering integrity and data origin authentication as specified in [RFC5213] and [RFC7077].
このドキュメントのUPNおよびUPAメッセージは、[RFC5213]および[RFC7077]で指定されている整合性とデータ発信元認証を提供するエンドツーエンドのセキュリティアソシエーションを使用して保護する必要があります。
When HNP renumbering is triggered, a new HNP SHOULD be allocated to the MN. The LMA MUST follow the procedure of PMIPv6 to make sure that only an authorized HNP can be assigned for the MN. In this way, the LMA is ready to be the topological anchor point of the new HNP, which is for that MN's exclusive use.
HNP再番号付けがトリガーされると、新しいHNPがMNに割り当てられる必要があります（SHOULD）。 LMAは、許可されたHNPのみがMNに割り当てられるようにするために、PMIPv6の手順に従う必要があります。このようにして、LMAは、そのMN専用の新しいHNPのトポロジアンカーポイントになる準備ができています。
Per [RFC4862], if the Valid Lifetime in a Prefix Information Option is set to less than 2 hours in an unauthenticated RA, it is ignored. Thus, when the old HNP that is being deprecated is included in an RA from the MAG, the Valid Lifetime SHOULD be set to 2 hours (and the Preferred Lifetime set to 0) for an unauthenticated RA. However, if the legality of the signaling messages exchanged between MAG and MN can be guaranteed, it MAY be acceptable to also set the Valid Lifetime to 0 for an unauthenticated RA.
[RFC4862]によると、プレフィックス情報オプションの有効期間が非認証RAで2時間未満に設定されている場合、それは無視されます。したがって、廃止予定の古いHNPがMAGからのRAに含まれている場合、認証されていないRAの有効期間は2時間に設定する必要があります（および優先期間は0に設定します）。ただし、MAGとMNの間で交換されるシグナリングメッセージの合法性が保証できる場合は、認証されていないRAのValid Lifetimeを0に設定しても問題ありません。
This document does not require any 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, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <http://www.rfc-editor.org/info/rfc3007>.
[RFC3007] Wellington、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、DOI 10.17487 / RFC3007、2000年11月、<http://www.rfc-editor.org/info/rfc3007>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, <http://www.rfc-editor.org/info/rfc4283>.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPv6）のモバイルノード識別子オプション」、RFC 4283、DOI 10.17487 / RFC4283、11月2005、<http://www.rfc-editor.org/info/rfc4283>。
[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, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、DOI 10.17487 / RFC5213、August 2008、<http ：//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, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487 / RFC6275、2011年7月、<http：//www.rfc-editor。 org / info / rfc6275>。
[RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463, February 2012, <http://www.rfc-editor.org/info/rfc6463>.
[RFC6463] Korhonen、J.、Ed。、Gundavelli、S.、Yokota、H.、and X. Cui、 "Runtime Local Mobility Anchor（LMA）Assignment Support for Proxy Mobile IPv6"、RFC 6463、DOI 10.17487 / RFC6463、 2012年2月、<http://www.rfc-editor.org/info/rfc6463>。
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, DOI 10.17487/RFC7077, November 2013, <http://www.rfc-editor.org/info/rfc7077>.
[RFC7077]クリシュナン、S。、ガンダベリ、S。、リープシュ、M。、横田、H.、J。コロネン、「プロキシモバイルIPv6の更新通知」、RFC 7077、DOI 10.17487 / RFC7077、2013年11月、<http ：//www.rfc-editor.org/info/rfc7077>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient Binding for Proxy Mobile IPv6", RFC 6058, DOI 10.17487/RFC6058, March 2011, <http://www.rfc-editor.org/info/rfc6058>.
[RFC6058] Liebsch、M。、編、Muhanna、A。、およびO. Blume、「Proxy Mobile IPv6のTransient Binding」、RFC 6058、DOI 10.17487 / RFC6058、2011年3月、<http：//www.rfc- editor.org/info/rfc6058>。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, <http://www.rfc-editor.org/info/rfc6879>.
[RFC6879] Jiang、S.、Liu、B。、およびB. Carpenter、「IPv6 Enterprise Network Renumbering Scenarios、Considerations、and Methods」、RFC 6879、DOI 10.17487 / RFC6879、2013年2月、<http：//www.rfc -editor.org/info/rfc6879>。
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, DOI 10.17487/RFC7010, September 2013, <http://www.rfc-editor.org/info/rfc7010>.
[RFC7010] Liu、B.、Jiang、S.、Carpenter、B.、Venaas、S。、およびW. George、「IPv6 Site Renumbering Gap Analysis」、RFC 7010、DOI 10.17487 / RFC7010、2013年9月、<http： //www.rfc-editor.org/info/rfc7010>。
Acknowledgements
謝辞
The work of Jong-Hyouk Lee was supported by 'The Cross-Ministry Giga KOREA Project' grant from the Ministry of Science, ICT and Future Planning, Korea.
ジョン・ジョンヒョクの作品は、韓国科学情報通信・未来計画省からの「大臣間ギガ韓国プロジェクト」助成金によって支援されました。
Authors' Addresses
著者のアドレス
Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China
zh Iは、CNNIC no.4南4THストリート、Zマクロインチ北京100190中国に従ってyです。
Email: yan@cnnic.cn
Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan 31066 Republic of Korea
Jong-Hyouk Lee Sangmyung University 31、Songmyeongdae-gil、Dongnam-gu Cheonan 31066大韓民国
Email: jonghyouk@smu.ac.kr
Xiaodong Lee CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China
ξ青東李CNNIC第4南4THストリート、Zマクロインチ北京100190中国
Email: xl@cnnic.cn