[要約] RFC 5846は、IPv6モビリティのためのバインディングの取り消しに関する規格であり、モビリティ管理者がモビリティセッションを終了させるための手段を提供します。目的は、モビリティセッションのセキュリティと効率を向上させることです。
Internet Engineering Task Force (IETF) A. Muhanna
Request for Comments: 5846 M. Khalil
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Gundavelli
K. Chowdhury
Cisco
P. Yegani
Juniper Networks
June 2010
Binding Revocation for IPv6 Mobility
IPv6モビリティのバインディング取り消し
Abstract
概要
This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries.
このドキュメントでは、モバイルノードのモビリティセッションと関連するリソースを終了するための拘束力のある取り消しメカニズムを定義します。このメカニズムは、ベースモバイルIPv6とプロキシモバイルIPv6などの拡張機能の両方で使用できます。このメカニズムにより、取り消し手順を開始するモビリティエンティティが、ピア、複数、またはすべての指定されたバインディングキャッシュエントリのいずれかを終了するようにピアを要求することができます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5846.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5846で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5
3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6
3.3. Multiple Care-of Addresses (MCoA) Use Case . . . . . . . . 7
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8
3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation . . 9
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10
4. Binding Revocation Messages over IPv4 Transport Network . . . 10
5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11
5.1. Binding Revocation Indication Message . . . . . . . . . . 13
5.2. Binding Revocation Acknowledgement Message . . . . . . . . 16
6. Binding Revocation Process Operation . . . . . . . . . . . . . 18
6.1. Sending Binding Revocation Message . . . . . . . . . . . . 18
6.1.1. Sending Binding Revocation Indication . . . . . . . . 18
6.1.2. Sending Binding Revocation Acknowledgement . . . . . . 19
6.2. Receiving Binding Revocation Message . . . . . . . . . . . 20
6.2.1. Receiving Binding Revocation Indication . . . . . . . 20
6.2.2. Receiving Binding Revocation Acknowledgement . . . . . 21
6.3. Retransmission of Binding Revocation Indication . . . . . 22
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 23
8.1. Sending Binding Revocation Indication . . . . . . . . . . 23
8.2. Receiving Binding Revocation Indication . . . . . . . . . 27
9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 29
9.1. Receiving Binding Revocation Indication . . . . . . . . . 29
9.2. Sending Binding Revocation Indication . . . . . . . . . . 31
10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 32
11. Protocol Configuration Variables . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . . 38
In the case of Mobile IPv6 and for administrative reasons, sometimes it becomes necessary to inform the mobile node that its registration has been revoked and the mobile node is no longer able to receive IP mobility service for its Home Address. A similar Mobile IPv4 registration revocation mechanism [RFC3543] has been specified by the IETF for providing a revocation mechanism for sessions that were established using Mobile IPv4 registration [RFC3344].
モバイルIPv6の場合および管理上の理由により、登録が取り消され、モバイルノードが自宅の住所のIPモビリティサービスを受け取ることができなくなったことをモバイルノードに通知する必要がある場合があります。同様のモバイルIPv4登録取消メカニズム[RFC3543]は、モバイルIPv4登録[RFC3344]を使用して確立されたセッションの取り消しメカニズムを提供するために、IETFによって指定されています。
This document specifies a binding revocation mechanism that can be used to revoke a mobile node's mobility session(s). The same mechanism can be used to revoke bindings created using Mobile IPv6 [RFC3775] or any of its extensions, e.g., Proxy Mobile IPv6 [RFC5213]. The proposed revocation mechanism uses a new Mobility Header (MH) type 16 for revocation signaling that is applicable to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any two IP mobility entities. As an example, this mechanism allows a local mobility anchor (LMA), involved in providing IP mobility services to a mobile node, to notify the mobile access gateway (MAG) of the termination of that mobile node binding registration. In another example, a mobile access gateway can use this mechanism to notify its local mobility anchor peer with a bulk termination of all or a subset of proxy mobile IPv6 (PMIPv6) bindings that are registered with the local mobility anchor and currently being served by the mobile access gateway. Any mobility entity is allowed to revoke only the registration of those mobile node(s) mobility sessions that are currently registered with it.
このドキュメントは、モバイルノードのモビリティセッションを取り消すために使用できる拘束力のある取り消しメカニズムを指定します。同じメカニズムを使用して、モバイルIPv6 [RFC3775]またはその拡張機能、例えばプロキシモバイルIPv6 [RFC5213]を使用して作成されたバインディングを取り消すことができます。提案された取り消しメカニズムは、モバイルIPv6 [RFC3775]およびプロキシモバイルIPv6 [RFC5213]に適用される取り消しシグナリングに、新しいモビリティヘッダー（MH）タイプ16を使用し、2つのIPモビリティエンティティで使用できます。例として、このメカニズムにより、モバイルノードにIPモビリティサービスの提供に関与するローカルモビリティアンカー（LMA）が可能になり、モバイルノードバインディング登録の終了をモバイルアクセスゲートウェイ（MAG）に通知できます。別の例では、モバイルアクセスゲートウェイはこのメカニズムを使用して、ローカルモビリティIPv6（PMIPV6）バインディングのすべてまたはサブセットのバルク終了でローカルモビリティアンカーピアを通知することができます。モバイルアクセスゲートウェイ。モビリティエンティティは、現在登録されているモバイルノード（S）モビリティセッションの登録のみを取り消すことができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
All the general mobility related terminology and abbreviations are to be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844] specifications. The following terms are used in this specification.
すべての一般的なモビリティ関連の用語と略語は、モバイルIPv6 [RFC3775]、プロキシモバイルIPv6 [RFC5213]、およびProxyモバイルIPv6 [RFC5844]仕様のIPv4サポートで定義されていると解釈されます。この仕様では、次の用語が使用されています。
Initiator
イニシエータ
The mobility node that initiates the binding revocation procedure by sending a Binding Revocation Indication message to its peer, e.g., home agent, local mobility anchor, or mobile access gateway.
ホームエージェント、ローカルモビリティアンカー、モバイルアクセスゲートウェイなど、ピアにバインディング取り消し表示メッセージを送信することにより、バインディング取消手順を開始するモビリティノード。
Responder
対応者
The mobility node that receives the Binding Revocation Indication message and responds with a Binding Revocation Acknowledgement message, e.g., mobile node, mobile access gateway, or local mobility anchor.
バインディング取り消し表示メッセージを受信し、バインディング装備確認メッセージ、モバイルノード、モバイルアクセスゲートウェイ、ローカルモビリティアンカーで応答するモビリティノード。
This specification specifies a generic binding revocation mechanism where a mobility node can communicate to the mobile node or another mobility node the identity of the mobile node registration binding that is being terminated. In the case when this mechanism is used for bulk termination or multiple bindings, the identities of these bindings are communicated to the mobile node or mobility node using the same generic mechanism. The following subsections present the protocol overview and applicable use cases.
この仕様は、モビリティノードがモバイルノードまたは別のモビリティノードに通信できる一般的なバインディング取り消しメカニズムを指定します。このメカニズムがバルク終了または複数のバインディングに使用される場合、これらのバインディングのアイデンティティは、同じ汎用メカニズムを使用してモバイルノードまたはモビリティノードに通信されます。次のサブセクションは、プロトコルの概要と適用可能なユースケースを示しています。
In the case of Mobile IPv6, if the home network decides to terminate the service of the mobile node, the home agent sends a Binding Revocation Indication (BRI) message to the mobile node. The home agent includes the home address (HoA) of the mobile node in the Type 2 routing header as specified in [RFC3775] to indicate the impacted mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555], the home agent may include the IPv4 Home Address option with the home IPv4 address assigned by the mobile node. Additionally, if the mobile node registered multiple care-of addresses [RFC5648], the home agent includes the Binding Identifier (BID) option(s) in the Binding Revocation Indication message to identify which binding is being revoked. When the mobile node receives a Binding Revocation Indication message with its HoA included in the Type 2 routing header, the mobile node responds by sending a Binding Revocation Acknowledgement (BRA) message.
モバイルIPv6の場合、ホームネットワークがモバイルノードのサービスを終了することを決定した場合、ホームエージェントはモバイルノードに拘束力のある取り消し表示（BRI）メッセージを送信します。ホームエージェントには、[RFC3775]で指定されているタイプ2ルーティングヘッダーのモバイルノードのホームアドレス（HOA）が含まれており、影響を受けたモバイルノード結合を示します。デュアルスタックモバイルIPv6（DSMIPV6）[RFC5555]の場合、ホームエージェントには、モバイルノードによって割り当てられたHome IPv4アドレスを備えたIPv4ホームアドレスオプションを含めることができます。さらに、モバイルノードが複数のケアオブアドレス[RFC5648]を登録した場合、ホームエージェントには、バインディングの取り消し表示メッセージにバインディング識別子（BID）オプションが含まれ、どのバインディングが取り消されているかを特定します。モバイルノードが、タイプ2ルーティングヘッダーにHOAを含むバインディング取り消し表示メッセージを受信すると、モバイルノードは、バインディング装備確認（BRA）メッセージを送信することで応答します。
Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation procedure can be initiated by the local mobility anchor by sending a Binding Revocation Indication message to communicate the termination of a mobile node registration binding to the mobile access gateway. In this case, the local mobility anchor includes the mobile node Home Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option
同様に、プロキシモバイルIPv6 [RFC5213]の場合、モバイルノード登録のバインディングバインディングの終了を伝達するためのバインディング取り消し表示メッセージを送信することにより、ローカルモビリティアンカーによって取り消し手順を開始できます。この場合、ローカルモビリティアンカーには、モバイルノードホームネットワークプレフィックス（MN-HNP）オプション[RFC5213]とMN-IDオプションが含まれています
[RFC4283] to indicate to the mobility access gateway the identity of the PMIPv6 binding that needs to be terminated. When the mobile access gateway receives the Binding Revocation Indication message, the mobile access gateway responds to the local mobility anchor by sending a Binding Revocation Acknowledgement message.
[RFC4283]モビリティアクセスゲートウェイに示すために、終了する必要があるPMIPV6結合のIDを示す。Mobile Access GatewayがBinding Rococation Indiclageメッセージを受信すると、モバイルアクセスゲートウェイは、バインディング装備の確認メッセージを送信することにより、ローカルモビリティアンカーに応答します。
On the other hand, the mobile access gateway usually sends a de-registration message by sending a Proxy Binding Update with a lifetime of zero to indicate to the local mobility anchor of the termination of the PMIPv6 mobile node binding registration. In this case, the mobile access gateway includes the MN-HNP option, the MN-ID option, and all other required mobility options as per [RFC5213] in order for the local mobility anchor to identify the mobile node PMIPv6 binding. Additionally, in the case when the mobile access gateway communicates a bulk termination of PMIPv6 mobility sessions, the mobile access gateway sends a Binding Revocation Indication message with the Global (G) bit set and includes the mobile access gateway identity in the MN-ID option, see Section 9.2 and Section 8.2. When the local mobility anchor receives such a Binding Revocation Indication message, it ensures that the mobile access gateway is authorized to send such a bulk termination message, see Section 13, and then processes the Binding Revocation Indication message accordingly. If the local mobility anchor processes the Binding Revocation Indication message successfully, the local mobility anchor responds to the mobile access gateway by sending Binding Revocation Acknowledgement message.
一方、モバイルアクセスゲートウェイは、通常、ゼロの寿命のプロキシバインディングアップデートを送信して、PMIPv6モバイルノードバインディング登録の終了のローカルモビリティアンカーを示すことにより、登録解除メッセージを送信します。この場合、モバイルアクセスゲートウェイには、MN-HNPオプション、MN-IDオプション、および[RFC5213]に従って、モバイルノードPMIPv6バインディングを識別するために、[RFC5213]に従って他のすべての必要なモビリティオプションが含まれています。さらに、モバイルアクセスゲートウェイがPMIPv6モビリティセッションのバルク終了を通知する場合、モバイルアクセスゲートウェイは、グローバル（g）ビットセットでバインディング装備表示メッセージを送信し、MN-IDオプションにモバイルアクセスゲートウェイアイデンティティを含む、セクション9.2およびセクション8.2を参照してください。ローカルモビリティアンカーがこのようなバインディング取り消し表示メッセージを受信すると、モバイルアクセスゲートウェイがこのようなバルク終了メッセージを送信することを許可され、セクション13を参照してから、それに応じてバインディング取消度表示メッセージを処理します。ローカルモビリティアンカーがバインディング取消度表示メッセージを正常に処理する場合、ローカルモビリティアンカーは、バインディング撤回の確認メッセージを送信することにより、モバイルアクセスゲートウェイに応答します。
In any of the above cases, the initiator of the binding revocation procedure, e.g., home agent, local mobility anchor, or mobile access gateway, uses the Revocation Trigger field in the Binding Revocation Indication message to indicate to the receiving node the reason for initiating the revocation procedure.
上記のいずれかのケースでは、バインディング取消手順の開始因子、たとえばホームエージェント、ローカルモビリティアンカー、またはモバイルアクセスゲートウェイは、バインディングトリガーフィールドをバインディング取り消し表示メッセージに使用して、受信ノードに開始の理由を示すために使用します。取り消し手順。
The binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 session(s) when the home agent needs to inform the mobile node that its binding registration has been revoked, e.g., for an administrative reason. This mechanism enables the user or the mobile node to react to the revocation, e.g., reinstate its interrupted Mobile IPv6 services.
バインディング取り消しメカニズムは、モバイルエージェントがモバイルノードにバインディング登録が取り消されたことを通知する必要がある場合、モバイルIPv6およびDSMIPV6セッションに適用できます。このメカニズムにより、ユーザーまたはモバイルノードが取り消しに反応することを可能にします。たとえば、中断されたモバイルIPv6サービスを回復します。
In this case, the home agent sends a Binding Revocation Indication message to indicate to the mobile node that its current mobile IPv6 (MIPv6) binding has been revoked and it is no longer able to receive IP mobility service. The home agent includes the HoA in a Type 2 routing header as used in [RFC3775] and sets the Revocation Trigger field to a proper value, e.g., Administrative Reason. In the case of a DSMIPv6 session, the home agent may additionally include the mobile-node-assigned IPv4 Home Address in the IPv4 Home Address option. When the mobile node receives the Binding Revocation Indication message, it sends a Binding Revocation Acknowledgement message to the home agent. Figure 1 illustrates the message sequencing when a home agent revokes a mobile node binding registration.
この場合、ホームエージェントは、現在のモバイルIPv6（MIPV6）バインディングが取り消され、IPモビリティサービスを受け取ることができなくなったことをモバイルノードに示すために、バインディング取り消し表示メッセージを送信します。ホームエージェントには、[RFC3775]で使用されているタイプ2ルーティングヘッダーのHOAが含まれ、取り消しトリガーフィールドを適切な値、たとえば管理上の理由に設定します。DSMIPV6セッションの場合、ホームエージェントは、IPv4ホームアドレスオプションにモバイルノードに割り当てられたIPv4ホームアドレスをさらに含めることができます。モバイルノードがバインディングの取り消し表示メッセージを受信すると、ホームエージェントに拘束力のある取り消し謝辞メッセージが送信されます。図1は、ホームエージェントがモバイルノードバインディング登録を取り消したときのメッセージシーケンスを示しています。
MN HA
| |
| HoA in Type 2 Routing Hdr |
|<<<------------... + ...-----------------|
| BRI [seq.#, Revocation Trigger] |
| |
| |
| BRA (HoA in Dest. Option)[seq.#, Status] |
|---------------------------------------->>>|
| |
| |
Figure 1: Home Agent Revokes a Mobile Node Binding Registration
図1：ホームエージェントはモバイルノードバインディング登録を取り消す
In the case of multiple care-of address registrations [RFC5648], the home agent maintains a different binding for each care-of address and home address pair. These bindings are also indexed and identified during the mobile node registration using a BID mobility option. The HA may revoke one or multiple bindings for the same mobile node home address.
複数のアドレス登録[RFC5648]の場合、ホームエージェントは、各住所とホームアドレスペアごとに異なるバインディングを維持しています。これらのバインディングは、モバイルノード登録中に入札モビリティオプションを使用してインデックスおよび識別されます。HAは、同じモバイルノードホームアドレスの1つまたは複数のバインディングを取り消す場合があります。
If the home agent revokes a single binding for a mobile node with multiple care-of address registrations, the home agent sends a Binding Revocation Indication message to the mobile node with the corresponding BID option included. If more than one of the mobile node registered care-of addresses needs to be revoked, the home agent includes all the corresponding BID options in the same Binding Revocation Indication message. Figure 2 illustrates the message flow when the home agent revokes two registered care-of addresses for the same mobile node in a single Binding Revocation Indication message.
ホームエージェントが複数のアドレス登録を備えたモバイルノードの単一のバインディングを取り消す場合、ホームエージェントは、対応するBIDオプションを含むバインディング取り消し表示メッセージをモバイルノードに送信します。モバイルノードの複数の登録されたケアオブアドレスを取り消す必要がある場合、ホームエージェントには、同じ拘束力のある取り消し表示に対応するすべての入札オプションが含まれています。図2は、ホームエージェントが同じモバイルノードの2つの登録されたケアオブアドレスを単一のバインディング取り消し表示メッセージで取り外したときのメッセージフローを示しています。
HA Binding Cache
================
MN-BID1 [CoA1+HoA]
MN HA MN-BID2 [CoA2+HoA]
| | MN-BID3 [CoA3+HoA]
| | MN-BID4 [CoA4+HoA]
| HoA in Type 2 Routing Hdr |
|<<<<-------------- + ---------------------|
| BRI [seq.#, R. Trigger, BID1, BID4] |
| |
| |
| BRA (HoA in Dest. Option) [seq.#, Status] |
|---------------------------------------->>>>|
| |
| |
Figure 2: Home Agent Revokes MN's Specific Care-of Address Bindings
図2：ホームエージェントはMNの特定のケアオブアドレスバインディングを取り消す
Additionally, the home agent may revoke all of the mobile node registered bindings by sending a BRI message without including any BID options while the HoA is included in the Type 2 routing header. Figure 1 illustrates the message flow when the home agent revokes all registered care-of address bindings for a mobile node in a single Binding Revocation Indication message.
さらに、ホームエージェントは、HOAがタイプ2ルーティングヘッダーに含まれている間に入札オプションを含めることなくBRIメッセージを送信することにより、すべてのモバイルノード登録バインディングを取り消すことができます。図1は、ホームエージェントが1つのバインディング取り消し表示メッセージでモバイルノードのすべての登録されたアドレスのケアバインディングを取り消すときのメッセージフローを示しています。
Since the mobile node does not participate in the mobility mechanism in the case of PMIPv6, there are many scenarios where the Binding Revocation mechanism is needed to clean resources and make sure that the mobility entities, i.e., mobile access gateway and local mobility anchor, are always synchronized with respect to the status of the existing PMIPv6 bindings. The binding revocation mechanism is generic enough that it can be used for all Proxy Mobile IPv6 scenarios that follow the [RFC5213] and [RFC5844] specifications.
MobileノードはPMIPv6の場合のモビリティメカニズムに参加していないため、リソースをクリーンし、モビリティエンティティ、つまりモバイルアクセスゲートウェイとローカルモビリティアンカーが確認するためにバインディング取消メカニズムが必要な多くのシナリオがあります。既存のPMIPV6バインディングのステータスに関して常に同期してください。結合取消メカニズムは、[RFC5213]および[RFC5844]仕様に従うすべてのプロキシモバイルIPv6シナリオに使用できるほど十分に一般的です。
When the mobile access gateway receives a Binding Revocation Indication message as in Section 9.1, the mobile access gateway sends a Binding Revocation Acknowledgement message to the local mobility anchor following the rules described in Section 6.1.2. Similarly, if the local mobility anchor receives a Binding Revocation Indication message, the local mobility anchor responds to the mobile access gateway by sending a Binding Revocation Acknowledgement message.
セクション9.1のように、モバイルアクセスゲートウェイがバインディングの取り消し表示メッセージを受信すると、モバイルアクセスゲートウェイは、セクション6.1.2で説明されているルールに従って、ローカルモビリティアンカーにバインディング取り消し承認メッセージを送信します。同様に、ローカルモビリティアンカーがバインディング取消し表示メッセージを受信した場合、ローカルモビリティアンカーは、バインディング装備の確認メッセージを送信することにより、モバイルアクセスゲートウェイに応答します。
The local mobility anchor may send a Binding Revocation Indication message with the appropriate revocation trigger value to the mobile access gateway that hosts a specific PMIPv6 binding to indicate that the mobile node binding has been terminated and the mobile access gateway can clean up the applicable resources. When the mobile access gateway receives a Binding Revocation Indication message, the mobile access gateway identifies the respective binding and it sends a Binding Revocation Acknowledgement message to the local mobility anchor. In this case, the mobile access gateway could terminate the IPv6 or IPv4 mobility session on the access link and notify the mobile node as in Section 9.1.
ローカルモビリティアンカーは、適切な取り消しトリガー値を備えたバインディングゴートコケーション表示メッセージを送信して、特定のPMIPV6バインディングをホストするモバイルアクセスゲートウェイに送信して、モバイルノードバインディングが終了し、モバイルアクセスゲートウェイが該当するリソースをクリーンアップできることを示します。モバイルアクセスゲートウェイがバインディングの取り消し表示メッセージを受信すると、モバイルアクセスゲートウェイはそれぞれのバインディングを識別し、ローカルモビリティアンカーにバインディング取り消し承認メッセージを送信します。この場合、モバイルアクセスゲートウェイは、アクセスリンクのIPv6またはIPv4モビリティセッションを終了し、セクション9.1のようにモバイルノードに通知することができます。
As an example, Figure 3, illustrates the message sequence for revoking a mobile node binding at the source mobile access gateway during the mobile node inter-MAG handover. During the inter-MAG handover, the mobile node moves from the source MAG to the target MAG. The target MAG sends a Proxy Binding Update with the new care-of address to the local mobility anchor to update the mobile node's point of attachment. Since the mobile node binding at the local mobility anchor points to the source MAG and upon receiving the Proxy Binding Update from the target MAG, the local mobility anchor updates the MN Binding Cache entry (BCE) and sends a Proxy Binding Acknowledgement to the target MAG. The local mobility anchor can send a Binding Revocation Indication message with the appropriate revocation trigger value, e.g., inter-MAG handover - different Access Types, to the source MAG in order to clean up the applicable resources reserved for the specified mobile node binding. The source mobile access gateway acknowledges the Binding Revocation Indication message by sending a Binding Revocation Acknowledgement message to indicate the success or failure of the termination of the mobile node's binding.
例として、図3は、モバイルノード間のハンドオーバー中にソースモバイルアクセスゲートウェイでモバイルノードバインディングを取り消すためのメッセージシーケンスを示しています。MAG間のハンドオーバー中、モバイルノードはソースマグからターゲットマグに移動します。ターゲットMAGは、モバイルノードの添付ファイルのポイントを更新するために、ローカルモビリティアンカーに新しいケアオブアドレスを含むプロキシバインディングアップデートを送信します。ローカルモビリティアンカーでのモバイルノードバインディングは、ソースMAGを指し、ターゲットマグからプロキシバインディングアップデートを受信すると、ローカルモビリティアンカーがMNバインディングキャッシュエントリ（BCE）を更新し、ターゲットMAGにプロキシバインディングの確認を送信します。。ローカルモビリティアンカーは、指定されたモバイルノードバインディング用に予約されている該当するリソースをクリーンアップするために、適切な取り消しトリガー値、たとえばMAG Inter -Mag Handover-異なるアクセスタイプを使用して、バインディング取消度表示メッセージを送信できます。Source Mobile Access Gatewayは、モバイルノードのバインディングの終了の成功または失敗を示すために、バインディングの取り消し確認メッセージを送信することにより、バインディングの取り消し表示メッセージを認めます。
The process identified above can also be used by the local mobility anchor in scenarios other than the inter-MAG handover with the proper revocation trigger value to indicate to the peer mobile access gateway that a specific PMIPv6 binding or bindings have been revoked.
上記で特定されたプロセスは、適切な取り消しトリガー値を備えたマグ間ハンドオーバー以外のシナリオでローカルモビリティアンカーでも使用して、特定のPMIPV6バインディングまたはバインディングが取り消されたことをピアモバイルアクセスゲートウェイに示すこともできます。
oldMAG newMAG LMA
| | |
| | PBU |
| |--------------------------->|
| | PBU triggers
| | BRI Msg to oldMAG
| | |
| | PBA |
| |<---------------------------|
| | |
| | |
| BRI [seq.#, R. Trigger, P bit, NAI] |
|<-----------------------------------------|
| | |
| | |
| | |
| | |
| BRA [seq.#, Status, P bit] |
|----------------------------------------->|
| | |
| | |
Figure 3: LMA Revokes an MN Registration During Inter-MAG Handover
図3：LMAは、MAG間ハンドオーバー中にMN登録を取り消す
In addition, the local mobility anchor can send a Binding Revocation Indication message to indicate that all bindings that are hosted by the peer mobile access gateway and registered with the local mobility anchor are being revoked by setting the Global (G) bit as described in Section 8.1.
さらに、ローカルモビリティアンカーは、ピアモバイルアクセスゲートウェイによってホストされ、ローカルモビリティアンカーに登録されているすべてのバインディングが、セクションで説明されているようにグローバル（g）ビットを設定することにより取り消されていることを示すために、バインド取消し表示メッセージを送信できます。8.1。
The mobile access gateway sends a BRI message with the Global (G) bit set and the Revocation Trigger field set to "Per-Peer Policy" to indicate that all mobility bindings that are registered at the local mobility anchor and attached to the mobile access gateway are being revoked as in Section 9.2. When the local mobility anchor receives this Binding Revocation Indication message from the specified mobile access gateway, the local mobility anchor first checks if the mobile access gateway is authorized to use global revocations, then it responds with the appropriate status code by sending a Binding Revocation Acknowledgement message as in Section 6.1.2.
モバイルアクセスゲートウェイは、グローバル（g）ビットセットとregocationトリガーフィールドを「ピアごとのポリシー」に設定してBRIメッセージを送信して、ローカルモビリティアンカーに登録され、モバイルアクセスゲートウェイに接続されているすべてのモビリティバインディングを示します。セクション9.2のように取り消されています。ローカルモビリティアンカーが指定されたモバイルアクセスゲートウェイからこのバインディング取り消し表示メッセージを受信すると、ローカルモビリティアンカーが最初にモバイルアクセスゲートウェイがグローバルな撤退を使用することを許可されているかどうかを確認すると、バインディングの取り消し承認を送信して適切なステータスコードで応答します。セクション6.1.2のようなメッセージ。
In some deployments, the network between the mobile access gateway and the local mobility anchor may only support IPv4 transport. Another case is when a mobile node that supports client mobile IPv6 roams to an access network where only IPv4 addressing and transport is supported. In this case, the mobile node is required to register an IPv4 home address with its home agent using a mobile IPv6 Binding Update message.
一部の展開では、モバイルアクセスゲートウェイとローカルモビリティアンカーの間のネットワークは、IPv4トランスポートのみをサポートする場合があります。別のケースは、クライアントモバイルIPv6をサポートするモバイルノードが、IPv4アドレス指定と輸送のみがサポートされているアクセスネットワークにローミングする場合です。この場合、モバイルノードは、モバイルIPv6バインディングアップデートメッセージを使用して、IPv4ホームアドレスをホームエージェントに登録する必要があります。
If the Proxy Binding Update and Proxy Binding Acknowledgement messages or the Binding Update and Binding Acknowledgement messages are sent using UDP encapsulation [RFC5844] [RFC5555], then the Binding Revocation Messages are sent using the same UDP encapsulation. The same UDP source and destination port numbers and IPv4 addresses used for exchanging the Proxy Binding Update and Proxy Binding Acknowledgement or the Binding Update and Binding Acknowledgement messages MUST be used when transporting Binding Revocation Messages over IPv4 using UDP encapsulation. For example, the source UDP port number, the destination UDP port number, the source IPv4 address, and the destination IPv4 address of the Binding Revocation Indication message are set to the destination UDP port number, the source UDP port number, destination IPv4 address, and source IPv4 address of the latest received and successfully processed Proxy Binding Update or Binding Update message, respectively. For more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see [RFC5844] and [RFC5555], respectively.
プロキシバインディングの更新およびプロキシバインディングの確認メッセージまたはバインディングアップデートおよびバインディングアップデートメッセージがUDPカプセル化[RFC5844] [RFC5555]を使用して送信される場合、同じUDPカプセル化を使用してバインディング取り消しメッセージが送信されます。UDPカプセル化を使用してIPv4を介してバインディング取消メッセージを輸送する際には、プロキシバインディングの更新およびプロキシバインディングの確認またはバインディングアップデートとバインディングの更新メッセージを交換するために使用される同じUDPソースと宛先ポート番号とIPv4アドレスを使用する必要があります。たとえば、ソースUDPポート番号、宛先UDPポート番号、ソースIPv4アドレス、およびバインディング装備表示メッセージの宛先IPv4アドレスは、宛先UDPポート番号、ソースUDPポート番号、宛先IPv4アドレスに設定されています。最新の受信および正常に処理されたプロキシバインディングアップデートまたはバインディングアップデートメッセージのソースIPv4アドレス。IPv4を介したトンネルプロキシモバイルIPv6およびモバイルIPv6シグナル伝達メッセージの詳細については、それぞれ[RFC5844]と[RFC5555]を参照してください。
This section defines the Binding Revocation Message format using an MH Type 16 as illustrated in Figure 4. The value in the Binding Revocation Type field defines whether the Binding Revocation Message is a Binding Revocation Indication or Binding Revocation Acknowledgement. If the Binding Revocation Type field is set to 1, the Binding Revocation Message is a Binding Revocation Indication as in Section 5.1. However, if the value is 2, it is a Binding Revocation Acknowledgement message as in Section 5.2.
このセクションでは、図4に示すように、MHタイプ16を使用してバインディング取り消しメッセージ形式を定義します。バインディング取消型タイプフィールドの値は、バインディング取消しメッセージがバインディング取消しの表示または結合取消しの確認であるかどうかを定義します。結合取消型フィールドが1に設定されている場合、結合取消メッセージはセクション5.1のように拘束力のある取り消し表示です。ただし、値が2の場合、セクション5.2のように拘束力のある取り消し承認メッセージです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | B.R. Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Binding Revocation Message Data .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Revocation Message
図4：バインディング取消メッセージ
Payload Proto
ペイロードプロト
8-bit selector. See [RFC3775] for more details.
8ビットセレクター。詳細については、[RFC3775]を参照してください。
Header Len
ヘッダーレン
8-bit unsigned integer. Representing the length of the Mobility Header in units of 8 octets, excluding the first 8 octets. See [RFC3775] for more details.
8ビットの符号なし整数。最初の8オクテットを除く、8オクテットのユニットでのモビリティヘッダーの長さを表します。詳細については、[RFC3775]を参照してください。
MH Type
MHタイプ
16, which identifies the mobility message as a Binding Revocation Message.
16、モビリティメッセージをバインディング取消メッセージとして識別します。
Reserved
予約済み
8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
将来の使用のために予約されている8ビットフィールド。値は、送信者によってゼロに初期化され、受信機が無視する必要があります。
Checksum
チェックサム
16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated as described in [RFC3775].
16ビットの符号なし整数。このフィールドには、モビリティヘッダーのチェックサムが含まれています。チェックサムは、[RFC3775]で説明されているように計算されます。
Binding Revocation Type
バインディングの取り消しタイプ
8-bit unsigned integer. It defines the type of the Binding Revocation Message. It can be assigned one of the following values:
8ビットの符号なし整数。バインディング取消メッセージのタイプを定義します。次の値のいずれかを割り当てることができます。
0 Reserved
0予約
1 Binding Revocation Indication
1結合取消度表示
2 Binding Revocation Acknowledgement
2拘束力のある取り消し承認
All other values are unassigned
他のすべての値は割り当てられていません
Binding Revocation Message Data
バインディング取消メッセージデータ
The Binding Revocation Message Data follows the Binding Revocation Message format that is defined in this document for the specified value in the Binding Revocation Type field. In this document, it is either a Binding Revocation Indication as in Section 5.1 or Binding Revocation Acknowledgement as in Section 5.2.
バインディング取り消しメッセージデータは、バインディングされた取り消しタイプフィールドの指定された値について、このドキュメントで定義されているバインディング取り消しメッセージ形式に従います。このドキュメントでは、セクション5.1のように拘束力のある取り消し表示またはセクション5.2のような拘束力のある取り消し承認です。
The Binding Revocation Indication (BRI) message is a Binding Revocation Message that has an MH type 16 and a Binding Revocation Type value of 1. It is used by the initiator to inform the responder of the identity of a specific binding or bindings for which IP mobility service are being revoked. Binding Revocation Indication message is sent as described in Sections 7, 8.1, and 9.2.
バインディング取り消し表示（BRI）メッセージは、MHタイプ16と1のバインディング装置タイプ値を持つバインディング取消しメッセージです。イニシエーターは、IP IPの特定のバインディングまたはバインディングのアイデンティティをレスポンダーに通知するために使用されます。モビリティサービスが取り消されています。セクション7、8.1、および9.2で説明されているように、バインディングの取り消し表示メッセージが送信されます。
When the value 1 is indicated in the Binding Revocation Type field of the Binding Revocation Message, the format of the Binding Revocation Message Data follows the Binding Revocation Indication message as in Figure 5
値1がバインディング取り消しメッセージのバインディング取り消しタイプフィールドに示されている場合、図5のように、バインディング取消メッセージデータの形式はバインディング取消し表示メッセージに従います。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 1 | R. Trigger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Revocation Indication Message
図5：バインディング取り消し表示メッセージ
Revocation Trigger
取り消しトリガー
8-bit unsigned integer indicating the event that triggered the initiator to send the BRI message. The Per-MN Revocation Trigger values are less than 128. The Per-MN Revocation Trigger is used when the BRI message intends to revoke one or more bindings for the same mobile node. The Global Revocation Trigger values are greater than 128 and less than 250 and used in the BRI message when the Global (G) bit is set for global revocation. The values 250-255 are reserved for testing purposes only. The following Revocation Trigger values are currently defined:
8ビットの署名されていない整数は、イニシエーターにBRIメッセージの送信をトリガーしたイベントを示しています。MN Rococationトリガー値は128未満です。BRIメッセージが同じモバイルノードの1つ以上のバインディングを取り消す予定の場合、MNあたりの取り消しトリガーが使用されます。Global Regocation Trigger値は128を超え、250未満であり、Global（G）ビットがGlobal Regocationに設定されている場合にBRIメッセージで使用されます。値250-255は、テスト目的でのみ予約されています。現在、次の取り消しトリガー値が定義されています。
Per-MN Revocation Trigger Values: 0 Unspecified 1 Administrative Reason 2 Inter-MAG Handover - same Access Type 3 Inter-MAG Handover - different Access Type 4 Inter-MAG Handover - Unknown 5 User-Initiated Session(s) Termination 6 Access Network Session(s) Termination 7 Possible Out-of-Sync BCE State
PER-MN ROGATOCER TRIGGER値：0不特定1管理理由2マグ間ハンドオーバー - 同じアクセスタイプ3インターマグハンドオーバー - 異なるアクセスタイプ4ハンドオーバー - 不明5ユーザー開始セッション6アクセスネットワークセッション（s）終了7可能性のあるBCE状態の可能性
Global Revocation Trigger Values: 128 Per-Peer Policy 129 Revoking Mobility Node Local Policy
グローバルな取り消しトリガー値：128ピアごとのポリシー129モビリティノードローカルポリシーの取り消し
Reserved Revocation Trigger Values: 250-255 Reserved For Testing Purposes only All other values are Reserved
予約された取り消しトリガー値：250-255テスト用に予約されている他のすべての値のみが予約されています
Sequence Number
シーケンス番号
A 16-bit unsigned integer used by the initiator to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. This sequence number could be a random number. At any time, implementations MUST ensure there is no collision between the sequence numbers of all outstanding Binding Revocation Indication Messages.
この拘束力のある取り消しの表示で、返されたバインディング取り消し承認と一致するためにイニシエーターが使用する16ビットの署名整数。このシーケンス番号は乱数である可能性があります。いつでも、実装は、すべての未解決のバインディング取り消し表示メッセージのシーケンス番号の間に衝突がないことを確認する必要があります。
Proxy Binding (P)
プロキシバインディング（P）
The Proxy Binding (P) bit is set by the initiator to indicate that the revoked binding(s) is a PMIPv6 binding.
プロキシ結合（P）ビットは、取り消されたバインディングがPMIPv6結合であることを示すために、イニシエーターによって設定されます。
IPv4 HoA Binding Only (V)
IPv4HOAバインディングのみ（V）
The IPv4 HoA Binding Only (V) bit is set by the initiator, home agent, or local mobility anchor to indicate to the receiving mobility entity the termination of the IPv4 Home Address binding only as in Sections 7 and 8.1.
IPv4HOAバインディングのみ（v）ビットは、イニシエーター、ホームエージェント、またはローカルモビリティアンカーによって設定され、受信モビリティエンティティにセクション7および8.1のようにIPv4ホームアドレスの終了を示すことを示します。
Global (G)
グローバル（g）
The Global (G) bit is set by the initiator, LMA or MAG, to indicate the termination of all Per-Peer mobility Bindings or Multiple Bindings that share a common identifier(s) and are served by the initiator and responder as in Sections 8.1 and 9.2.
グローバル（g）ビットは、イニシエーターであるLMAまたはMAGによって設定され、一般的な識別子を共有するすべてのピアあたりのモビリティバインディングまたは複数のバインディングの終了を示し、セクション8.1のようにイニシエーターとレスポンダーによって提供されます。および9.2。
Reserved
予約済み
These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
これらのフィールドは未使用です。送信者はゼロに初期化する必要があり、受信機は無視する必要があります。
Mobility Options
モビリティオプション
A 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. This document does not define any new mobility option. The receiver MUST ignore and skip any options that it does not understand. These mobility options are used by the responder to identify the specific binding or bindings that the initiator is requesting be revoked.
完全なモビリティヘッダーが長さ8オクターの整数倍であるような長さの可変長いフィールド。このフィールドには、ゼロ以上のTLVエンコードモビリティオプションが含まれています。このドキュメントは、新しいモビリティオプションを定義しません。レシーバーは、理解できないオプションを無視してスキップする必要があります。これらのモビリティオプションは、レスポンダーが使用して、イニシエーターが取り消される特定のバインディングまたはバインディングを特定します。
The following options are valid in a Binding Revocation Indication:
次のオプションは、拘束力のある取り消し表示で有効です。
o Home Network Prefix option [RFC5213]. This option MAY be used only when the (P) bit is set. This option MUST be present when the BRI is used to revoke a single Proxy MIPv6 Binding Cache entry.
o ホームネットワークプレフィックスオプション[RFC5213]。このオプションは、（p）ビットが設定されている場合にのみ使用できます。このオプションは、BRIを使用して単一のプロキシMIPV6結合キャッシュエントリを取り消す場合に存在する必要があります。
o Mobile Node Identifier option [RFC4283]. This option MUST be present when the (P) bit is set. Additionally, if the Global (G) bit is set by the mobile access gateway, this option MUST carry the MAG identity. In this specification, only the Mobile Node Identifier option with subtype 1 is required and other subtypes are currently not supported.
o モバイルノード識別子オプション[RFC4283]。このオプションは、（p）ビットが設定されている場合に存在する必要があります。さらに、グローバル（g）ビットがモバイルアクセスゲートウェイによって設定されている場合、このオプションはMAG IDを運ぶ必要があります。この仕様では、サブタイプ1を持つモバイルノード識別子オプションのみが必要であり、その他のサブタイプは現在サポートされていません。
o Binding Identifier mobility option [RFC5648]. This option MUST be present if the initiator requests to terminate one binding of a multiple care-of address bindings for the same mobile node. The initiator may include more than one of the BID mobility options.
o 結合識別子モビリティオプション[RFC5648]。イニシエーターが同じモバイルノードの複数のアドレスケアバインディングの1つのバインディングを終了するように要求する場合、このオプションが存在する必要があります。イニシエーターには、入札モビリティオプションの複数が含まれる場合があります。
o IPv4 Home Address option, which contains the mobile node home IPv4 address [RFC5555]. This option MUST only be included when the IPv4 HoA Binding only (V) bit is set and the (P) bit is cleared.
o モバイルノードホームIPv4アドレス[RFC5555]を含むIPv4ホームアドレスオプション。このオプションは、（v）ビットのみが設定され、（p）ビットがクリアされている場合にのみ含める必要があります。
o IPv4 Home Address Request option, which contains the mobile node proxy home IPv4 address [RFC5844]. This option MUST only be included when the IPv4 HoA Binding only (V) and the (P) bits are set.
o IPv4ホームアドレスリクエストオプション。モバイルノードプロキシホームIPv4アドレス[RFC5844]が含まれています。このオプションは、IPv4HOAバインディングのみ（v）と（P）ビットが設定されている場合にのみ含める必要があります。
o Alternate Care-of Address mobility option [RFC3775]. According to [RFC5213], the mobile access gateway is allowed to include this option in the Proxy Binding Update to indicate the proxy care-of address of the mobile node mobility session. This option MAY be included to indicate the proxy care-of address of the mobile node's binding that is being revoked. In the case when the Global (G) bit is set, this option identifies all mobility bindings that share the same proxy care-of address.
o 代替ケアオブアドレスモビリティオプション[RFC3775]。[RFC5213]によると、モバイルアクセスゲートウェイは、モバイルノードモビリティセッションのプロキシケアオブアドレスを示すために、プロキシバインディングアップデートにこのオプションを含めることができます。このオプションは、取り消されているモバイルノードのバインディングのプロキシケアアドレスを示すために含まれる場合があります。グローバル（g）ビットが設定されている場合、このオプションは、同じプロキシケアオブアドレスを共有するすべてのモビリティバインディングを識別します。
If no mobility options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1.
このメッセージにモビリティオプションが存在しない場合、4オクテットのパディングが必要であり、バインディング取消メッセージのヘッダーレンフィールドは1に設定されます。
The Binding Revocation Acknowledgement (BRA) message is a Binding Revocation Message that has an MH type 16 and a Binding Revocation Type value of 2. It is used to acknowledge the receipt of a Binding Revocation Indication message described in Section 5.1. This packet is sent as described in Section 6.1.2.
Binding Rococation Aumponedcement（BRA）メッセージは、MHタイプ16と2のバインディング取り消しタイプ値を持つバインディング取り消しメッセージです。これは、セクション5.1で説明されている拘束力のある取り消し表示メッセージの受信を確認するために使用されます。このパケットは、セクション6.1.2で説明されているように送信されます。
When the value 2 is indicated in the Binding Revocation Type field of the Binding Revocation Message, the format of the Binding Revocation Message Data follows the Binding Revocation Acknowledgement message as in Figure 6.
値2がバインディング取消メッセージのバインディング取り消しタイプフィールドに示されている場合、図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 2 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Revocation Acknowledgement Message
図6：バインディング取り消し承認メッセージ
Status 8-bit unsigned integer indicating the result of processing the Binding Revocation Indication message by the responder. Values of the Status field less than 128 indicate that the Binding Revocation Indication was processed successfully by the responder. Values greater than or equal to 128 indicate that the Binding Revocation Indication was rejected by the responder. The following Status values are currently defined:
ステータス8ビットの署名されていない整数は、応答者によるバインディング取り消し表示メッセージを処理した結果を示しています。128未満のステータスフィールドの値は、バインディングの取り消し表示がレスポンダーによって正常に処理されたことを示しています。128以上の値は、拘束力のある取り消し表示がレスポンダーによって拒否されたことを示しています。現在、次のステータス値が定義されています。
0 success 1 partial success 128 Binding Does NOT Exist 129 IPv4 Home Address Option Required 130 Global Revocation NOT Authorized 131 Revoked Mobile Nodes Identity Required 132 Revocation Failed - MN is Attached 133 Revocation Trigger NOT Supported 134 Revocation Function NOT Supported 135 Proxy Binding Revocation NOT Supported
0成功1部分成功128拘束は存在しません
Sequence Number
シーケンス番号
The sequence number in the Binding Revocation Acknowledgement is copied from the Sequence Number field in the Binding Revocation Indication. It is used by the initiator, e.g., HA, LMA, MAG, in matching this Binding Revocation Acknowledgement with the outstanding Binding Revocation Indication.
バインディング取り消し謝辞のシーケンス番号は、バインディング取消度表示のシーケンス番号フィールドからコピーされます。これは、イニシエーター、たとえば、HA、LMA、MAG、この結合取消しの承認と未払いの結合取消し表示に一致する際に使用されます。
Proxy Binding (P)
プロキシバインディング（P）
The Proxy Binding (P) bit is set if the (P) bit is set in the corresponding Binding Revocation Indication message.
プロキシバインディング（p）ビットは、対応するバインディング取消度表示メッセージに（p）ビットが設定されている場合に設定されます。
IPv4 HoA Binding Only (V)
IPv4HOAバインディングのみ（V）
The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in the corresponding Binding Revocation Indication message.
（v）ビットが対応するバインディング取り消し表示メッセージに設定されている場合、（v）ビットのみが設定されます。
Global (G)
グローバル（g）
The Global (G) bit is set if the (G) bit is set in the corresponding Binding Revocation Indication message.
（g）ビットが対応するバインディング取り消し表示メッセージに設定されている場合、グローバル（g）ビットが設定されます。
Reserved
予約済み
These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
これらのフィールドは未使用です。送信者はゼロに初期化する必要があり、受信機は無視する必要があります。
Mobility Options
モビリティオプション
A 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. In the case when the Status field is set to success, no mobility option is required. The mobility option(s) is usually used to communicate information of the bindings that failed the revocation procedure.
完全なモビリティヘッダーが長さ8オクターの整数倍であるような長さの可変長いフィールド。このフィールドには、ゼロ以上のTLVエンコードモビリティオプションが含まれています。ステータスフィールドが成功に設定されている場合、モビリティオプションは必要ありません。モビリティオプションは通常、取り消し手順に失敗したバインディングの情報を伝えるために使用されます。
The following mobility options are valid in a Binding Revocation Acknowledgement:
次のモビリティオプションは、拘束力のある取り消し承認で有効です。
o Home Network Prefix option [RFC5213]. This option MAY be included only when the (P) bit is set.
o ホームネットワークプレフィックスオプション[RFC5213]。このオプションは、（p）ビットが設定されている場合にのみ含まれます。
o Mobile Node Identifier Option [RFC4283]. This option MAY be included when the (P) bit is set. This option SHOULD be included if the Home Network Prefix option is included.
o モバイルノード識別子オプション[RFC4283]。このオプションは、（p）ビットが設定されている場合に含まれる場合があります。ホームネットワークプレフィックスオプションが含まれている場合は、このオプションを含める必要があります。
o Binding Identifier mobility option [RFC5648]. The responder MAY include this option to indicate the specific BID that failed the revocation procedure.
o 結合識別子モビリティオプション[RFC5648]。レスポンダーには、取り消し手順に失敗した特定の入札を示すために、このオプションを含めることができます。
If no options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1.
このメッセージにオプションが存在しない場合、4オクテットのパディングが必要であり、バインディング取消メッセージのヘッダーレンフィールドは1に設定されます。
The following subsections describe the details of the generic binding revocation process as used by the different mobility entities.
以下のサブセクションでは、さまざまなモビリティエンティティで使用されている汎用結合取消しプロセスの詳細について説明しています。
When sending a Binding Revocation message, the initiator constructs the packet as it would do with any other Mobility Header with the exception of setting the MH Type field to 16.
バインディング取り消しメッセージを送信するとき、イニシエーターは、MHタイプフィールドを16に設定することを除き、他のモビリティヘッダーと同じようにパケットを構築します。
The Binding Revocation Message MUST be protected using the same underlying security association, e.g., IPsec, that is being used between the two peers to protect the mobile node's Mobile IPv6 and its extensions binding registration signaling. If IPsec is not used as the underlying security mechanism to protect the binding registration signaling, the used underlying security mechanism MUST provide protection against all identified security threats as described under "Security Considerations" in [RFC3775] and [RFC5213].
拘束力のある取り消しメッセージは、モバイルノードのモバイルIPv6とその拡張バインディング登録シグナリングを保護するために2人のピア間で使用されている同じ基礎となるセキュリティ協会、たとえばIPSECを使用して保護する必要があります。IPSECが拘束力のある登録信号を保護するための基礎となるセキュリティメカニズムとして使用されていない場合、使用される基礎となるセキュリティメカニズムは、[RFC3775]および[RFC5213]の「セキュリティ上の考慮事項」で説明されているように、特定されたすべてのセキュリティ脅威に対する保護を提供する必要があります。
The initiator MUST construct the Binding Revocation Message Data following the format of the Binding Revocation Indication message as described in Section 5.1 and the following:
イニシエーターは、セクション5.1および以下で説明されているように、バインディング取り消し表示メッセージの形式に従って、バインディング取り消しメッセージデータを構築する必要があります。
o The initiator MUST set the Sequence Number field to a valid sequence number for Binding Revocation. Since sending a Binding Revocation Indication message is not done on a regular basis, a 16-bit Sequence Number field is large enough to allow the initiator to match the Binding Revocation Acknowledgement to the associated Binding Revocation Indication using the Sequence Number field only.
o イニシエーターは、バインディングの取り消しのためにシーケンス番号フィールドを有効なシーケンス番号に設定する必要があります。バインディング取り消し表示メッセージの送信メッセージは定期的に行われていないため、16ビットシーケンス番号フィールドは、シーケンス番号フィールドのみを使用して、関連するバインディング取り消し表示に結合取消しの確認と一致させるのに十分な大きさです。
o If the initiator is revoking a binding that was created using proxy MIPv6 registration, the initiator MUST set the Proxy Binding (P) bit.
o イニシエーターがプロキシMIPV6登録を使用して作成されたバインディングを取り消している場合、イニシエーターはプロキシバインディング（P）ビットを設定する必要があります。
o If the initiator is sending the Binding Revocation Indication message to revoke multiple mobility sessions, the initiator MUST set the Global (G) bit. In this case, the initiator MUST set the Revocation Trigger field to a valid value from the list of Global Revocation Triggers.
o イニシエーターが複数のモビリティセッションを取り消すためにバインディング取り消し表示メッセージを送信している場合、イニシエーターはグローバル（g）ビットを設定する必要があります。この場合、イニシエーターは、Global Recocation Triggerのリストから取り消しトリガーフィールドを有効な値に設定する必要があります。
o If the initiator is sending the Binding Revocation Indication message with the Global (G) bit cleared, the initiator MUST set the Revocation Trigger field to a valid value from the list of Per-MN Revocation Triggers.
o イニシエーターがグローバル（g）ビットがクリアされたバインディング取り消し表示メッセージを送信している場合、イニシエーターは、MN失効トリガーのリストから「取り消しトリガー」フィールドを有効な値に設定する必要があります。
o If the initiator is sending the Binding Revocation Indication message to indicate the revocation of the mobile node IPv4 HoA Binding Only, the initiator MUST set the (V) bit. In this case, the initiator MUST include either the IPv4 Home Address option or the IPv4 Home Address Request option in the BRI to identify the IPv4 HoA that is being revoked.
o イニシエーターがバインディングの取り消し表示メッセージを送信して、モバイルノードIPv4HOAバインディングのみの取り消しを示す場合、イニシエーターは（v）ビットを設定する必要があります。この場合、イニシエーターには、BRIのIPv4ホームアドレスオプションまたはIPv4ホームアドレスリクエストオプションのいずれかを含める必要があります。
The responder MUST send a Binding Revocation Acknowledgement message to indicate the receipt and the status of processing of the corresponding Binding Revocation Indication message as follows:
応答者は、拘束力のある取り消し謝辞メッセージを送信して、次のように、対応する拘束力のある取り消し表示メッセージの領収書と処理のステータスを示す必要があります。
o Whenever the Binding Revocation Indication is discarded, e.g., as described in Section 6.2, a Binding Revocation Acknowledgement MUST NOT be sent. Otherwise, the treatment depends on the following rules.
o 拘束力のある取り消し表示が破棄される場合、たとえば、セクション6.2で説明されているように、拘束力のある取り消し承認を送信してはなりません。それ以外の場合、治療は次のルールに依存します。
o If the responder accepts the Binding Revocation Indication message, the responder MUST send a successful Binding Revocation Acknowledgement with an appropriate status code.
o Responderがバインディングの取り消し表示メッセージを受け入れる場合、Responderは適切なステータスコードを使用してバインディングの取り消し承認を成功させる必要があります。
o If the responder rejects the Binding Revocation Indication message, the responder MUST send a Binding Revocation Acknowledgement with an appropriate failure status code.
o 応答者が拘束力のある取り消し表示メッセージを拒否した場合、応答者は適切な障害ステータスコードを使用して拘束力のある取り消し承認を送信する必要があります。
If the Source Address field of the IPv6 header that carried the Binding Revocation Indication message does not contain a unicast address, the Binding Revocation Indication packet MUST be silently discarded.
バインディング取り消し表示メッセージを伝えたIPv6ヘッダーのソースアドレスフィールドにユニキャストアドレスが含まれていない場合、バインディング取消度表示パケットは静かに破棄する必要があります。
When the responder acknowledges the received Binding Revocation Indication message, the responder MUST construct the Binding Revocation Message Data following the format of the Binding Revocation Acknowledgement message as described in Section 5.2 and the following: o The responder MUST set the Sequence Number field by copying the value from the Sequence Number field of the received Binding Revocation Indication.
対応者が受信した拘束力のある取り消し表示メッセージを認める場合、レスポンダーは、セクション5.2で説明されているように、拘束力のある取り消し謝辞メッセージの形式に従ってバインディング取消メッセージデータを構築する必要があります。受信したバインディング取り消し表示のシーケンス番号フィールドからの値。
o The responder MUST set the Status field to a valid value that reflects the status of the processing of the received Binding Revocation Indication message.
o 応答者は、受信した拘束力のある取り消し表示メッセージの処理のステータスを反映する有効な値にステータスフィールドを設定する必要があります。
o If the (P) bit is set in the received Binding Revocation Indication, the responder MUST set the (P) bit in the Binding Revocation Acknowledgement.
o （p）ビットが受信された拘束力のある取り消し表示に設定されている場合、レスポンダーはバインディング取消しの確認に（p）ビットを設定する必要があります。
o If the Global (G) bit is set in the received Binding Revocation Indication, the responder MUST set the Global (G) bit in the Binding Revocation Acknowledgement.
o Global（g）ビットが受信した拘束力のある取り消し表示に設定されている場合、Responderはバインディング取消確認にグローバル（g）ビットを設定する必要があります。
o If the IPv4 HoA Binding Only (V) bit is set in the received Binding Revocation Indication, the responder MUST set the (V) bit in the Binding Revocation Acknowledgement.
o IPv4HOAバインディングのみが（v）ビットが受信されたバインディングの取り消し表示に設定されている場合、レスポンダーはバインディングの取り消し承認で（v）ビットを設定する必要があります。
o The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received Binding Revocation Indication.
o Binding Binding Rococation AumponedcementのIPv6パケットの宛先IPアドレスは、受信したバインディング取り消し表示のソースIPアドレスに設定されています。
When receiving a Binding Revocation Message, the responder MUST verify the Mobility Header as described in Section 9.2. of [RFC3775]. If the packet is dropped due to failing any of the Mobility Header test checks, the responder MUST follow the processing rules as in Section 9.2 of [RFC3775]. If the responder does not support the Binding Revocation Indication message and does not recognize the MH type 16, it sends a Binding Error message with the Status field set to 2 as described in [RFC3775].
拘束力のある取り消しメッセージを受信する場合、レスポンダーはセクション9.2で説明されているようにモビリティヘッダーを検証する必要があります。[RFC3775]。モビリティヘッダーテストチェックの失敗によりパケットがドロップされた場合、応答者は[RFC3775]のセクション9.2のように処理ルールに従う必要があります。レスポンダーがバインディング取り消し表示メッセージをサポートせず、MHタイプ16を認識しない場合、[RFC3775]で説明されているように、ステータスフィールドを2に設定して結合エラーメッセージを送信します。
Upon receiving a packet carrying a Binding Revocation Message, BRI or BRA, the receiving mobility entity MUST verify that the packet was received protected by the security association that is being used to protect the binding registration and Binding Revocation signaling between the two peers, e.g., an IPsec Security Association (SA).
拘束力のある取り消しメッセージであるBRIまたはBRAを運ぶパケットを受信すると、受信モビリティエンティティは、2人のピア間の拘束力のある登録と拘束力のある失効シグナルを保護するために使用されているセキュリティ協会によってパケットが保護されていることを確認する必要があります。IPSECセキュリティ協会（SA）。
When the responder receives a packet carrying a Binding Revocation Indication message that was successfully processed as in Section 6.2, the responder, in addition, processes the message as follows: o The responder MUST validate that the Binding Revocation Indication is formatted as in Section 5.1.
レスポンダーがセクション6.2のように正常に処理されたバインディング取り消し表示メッセージを運ぶパケットを受信すると、レスポンダーは次のようにメッセージを処理します。Oレスポンダーは、セクション5.1のようにバインディングの取り消し兆候がフォーマットされていることを検証する必要があります。
o If the Revocation Trigger field is set to a value that the responder does not support, the responder SHOULD reject the Binding Revocation Indication message using status code "Revocation Trigger NOT Supported".
o 取り消しトリガーフィールドがレスポンダーがサポートしていない値に設定されている場合、レスポンダーはステータスコードを使用してバインディング取消度表示メッセージを拒否する必要があります。
o If the Revocation Trigger value is NOT allowed with the Binding Revocation Indication message intent, e.g., the Global (G) bit is set and the Revocation Trigger field value is Per-MN-specific, the responder SHOULD reject the Binding Revocation Indication message using status code "Revocation Function NOT Supported".
o 拘束力のある取り消し表示メッセージの意図では取り消しトリガー値が許可されていない場合、たとえばグローバル（g）ビットが設定され、取り消しトリガーフィールド値がPer-MN固有のものである場合、レスポンダーはステータスを使用したバインディング取消度表示メッセージを拒否する必要があります。コード「削除関数はサポートされていません」。
o If the responder failed to identify the mobile node(s) bindings as identified in the Binding Revocation Indication message, the responder MUST reject the BRI using status code "Binding Does NOT Exist".
o Responderが、バインディングの取り消し表示メッセージで識別されているように、モバイルノードのバインディングを識別できなかった場合、Responderはステータスコード「バインディングは存在しない」を使用してBRIを拒否する必要があります。
When the initiator receives a packet carrying a Binding Revocation Acknowledgement message that was successfully processed as in Section 6.2, the initiator, in addition, processes the message and examines the Status field as follows:
イニシエーターが、セクション6.2のように正常に処理されたバインディング取り消し承認メッセージを運ぶパケットを受信すると、イニシエーターはメッセージを処理し、次のようにステータスフィールドを調べます。
o The initiator MUST validate that the sequence number in the Sequence Number field matches the sequence number of an outstanding Binding Revocation Indication that was sent by the initiator. If the sequence number does not match a sequence number of any of the outstanding Binding Revocation Indication messages, the initiator MUST silently discard the message but MAY log the event.
o イニシエーターは、シーケンス番号フィールドのシーケンス番号が、イニシエーターによって送信された未解決のバインディング取り消し表示のシーケンス番号と一致することを検証する必要があります。シーケンス番号が、未解決のバインディング取り消し表示メッセージのシーケンス番号と一致しない場合、イニシエーターはメッセージを静かに破棄する必要がありますが、イベントを記録する場合があります。
o If the Status field indicates that the Binding Revocation Indication was processed successfully, the initiator MUST delete the current timer and the mobile node(s) binding(s) and all associated resources.
o ステータスフィールドが、バインディングの取り消し表示が正常に処理されたことを示した場合、イニシエーターは現在のタイマーとモバイルノードバインディング（S）およびすべての関連リソースを削除する必要があります。
o If the Status field indicates any value other than success, the initiator SHOULD examine any mobility options included in the Binding Revocation Acknowledgement. In this case, it is based on the initiator local policy how to handle the mobile node binding. The initiator MAY log the appropriate event to reflect the received status.
o ステータスフィールドが成功以外の値を示している場合、イニシエーターは、拘束力のある取り消し承認に含まれるモビリティオプションを調べる必要があります。この場合、それはイニシエーターのローカルポリシーに基づいており、モバイルノードバインディングを処理する方法です。イニシエーターは、受信したステータスを反映するために適切なイベントを記録する場合があります。
If the initiator does not receive a Binding Revocation Acknowledgement in response to the outstanding Binding Revocation Indication before the InitMINDelayBRIs timer expires, the initiator, e.g., LMA, SHOULD retransmit the same BRI message up to the BRIMaxRetriesNumber as defined in Section 11.
イニシエーターが、initmindelaybrisタイマーが期限切れになる前に未解決の結合取消し表示に応じて拘束力のある取り消し承認を受け取らない場合、イニシエーター、例えば、LMAは、セクション11で定義されているように同じBRIメッセージをBrimaxretriesNumberに再送信する必要があります。
The retransmissions by the initiator MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the initiator receives a response or the timeout period reaches the value MAX_BRACK_TIMEOUT. The initiator MAY continue to send these messages at this slower rate up to the BRIMaxRetriesNumber.
イニシエーターによる再送信は、イニシエーターが応答を受信するか、タイムアウト期間が値max_brack_timeoutに達するまで、各再送信時にタイムアウト期間が2倍になる指数バックオフプロセスを使用する必要があります。イニシエーターは、これらのメッセージをこの遅い速度でbrimaxretriesNumberまで送信し続けることができます。
If the initiator does not receive a Binding Revocation Acknowledgement message after the BRIMaxRetriesNumber of retransmits have been sent, the initiator SHOULD clean up all resources associated with this mobile node binding. The initiator may log the event.
InitiatorがBrimaxRetriesNumberの再送信の数が送信された後にバインディング取り消し謝辞メッセージを受け取らない場合、イニシエーターはこのモバイルノードバインディングに関連付けられたすべてのリソースをクリーンアップする必要があります。イニシエーターがイベントを記録する場合があります。
To terminate a mobile node registration and its current binding with the home agent, the home agent sends a packet to the mobile node containing a Binding Revocation Indication, with the packet constructed as follows:
モバイルノード登録とホームエージェントとの現在のバインディングを終了するために、ホームエージェントは、パケットを次のように構築して、拘束力のある取り消し表示を含むモバイルノードにパケットを送信します。
o The Revocation Trigger field MUST be set to indicate to the mobile node the reason for revoking its IP mobility binding with the home agent. The Revocation Trigger may be used by the mobile node to take further steps if necessary.
o 取り消しトリガーフィールドは、ホームエージェントとのIPモビリティバインディングを取り消す理由をモバイルノードに示すように設定する必要があります。取り消しトリガーは、モバイルノードによって使用され、必要に応じてさらなる手順を実行できます。
o The Binding Revocation Indication MUST be sent using a Type 2 routing header that contains the mobile node's registered IPv6 home address for the binding being revoked.
o バインディングの取り消し表示は、取り消されているバインディングのためにモバイルノードの登録IPv6ホームアドレスを含むタイプ2ルーティングヘッダーを使用して送信する必要があります。
o The care-of address for the binding MUST be used as the destination address in the packet's IPv6 header.
o バインディングのケアアドレスは、パケットのIPv6ヘッダーの宛先アドレスとして使用する必要があります。
o If the home agent needs to only revoke the mobile node's IPv4 home address binding, the home agent MUST set the IPv4 HoA Binding Only (V) bit and MUST include the mobile node's registered IPv4 home address that is being revoked in the IPv4 Home Address option.
o ホームエージェントがモバイルノードのIPv4ホームアドレスバインディングのみを取り消す必要がある場合、ホームエージェントはIPv4HOAバインディングのみ（V）ビットを設定する必要があり、IPv4ホームアドレスオプションで取り消されているモバイルノードの登録IPv4ホームアドレスを含める必要があります。
When the home agent sends a Binding Revocation Indication to the mobile node, the home agent sets a flag in the mobile node BCE to indicate that revocation is in progress and starts the InitMINDelayBRIs timer. The home agent maintains the mobile node BCE in this state until it receives a Binding Revocation Acknowledgement or retransmits the Binding Revocation Indication message as described in Section 6.3.
ホームエージェントがモバイルノードに拘束力のある取り消し表示を送信すると、ホームエージェントはモバイルノードBCEにフラグを設定して、取り消しが進行中であることを示し、initmindelaybrisタイマーを開始します。ホームエージェントは、セクション6.3で説明されているように、拘束力のある取り消し承認を受け取るか、バインディング取り消し表示メッセージを再送信するまで、この状態のモバイルノードBCEを維持します。
In a race condition case, the home agent may receive a Binding Update from the mobile node while the mobile node's BCE has the revocation in progress flag set, the home agent SHOULD handle this case based on the reason for sending the Binding Revocation Indication message and its local policy. In this case, if the home agent accepts the Binding Update, it needs to update the mobile node BCE accordingly, e.g., removing the revocation in progress flag.
レース状態の場合、ホームエージェントはモバイルノードからバインディングアップデートを受信する場合がありますが、モバイルノードのBCEには進行状況フラグが取り消されます。ホームエージェントは、バインディングの取り消し表示メッセージを送信する理由に基づいてこのケースを処理する必要があります。そのローカルポリシー。この場合、ホームエージェントがバインディングアップデートを受け入れる場合、それに応じてモバイルノードBCEを更新する必要があります。
When the home agent needs to revoke one or more of a mobile node bindings that were created using multiple care-of address registrations as in [RFC5648], the home agent MUST include all the related BID mobility options that identify these bindings in the Binding Revocation Indication message. In the case when the home agent needs to revoke all of the mobile node bindings, the home agent SHOULD NOT include any of the BID mobility options.
ホームエージェントが[RFC5648]のように複数のアドレス登録を使用して作成されたモバイルノードバインディングの1つ以上を取り消す必要がある場合、ホームエージェントには、バインディングの取り消しでこれらのバインディングを識別するすべての関連する入札モビリティオプションを含める必要があります。表示メッセージ。ホームエージェントがすべてのモバイルノードバインディングを取り消す必要がある場合、ホームエージェントに入札モビリティオプションを含めるべきではありません。
When the home agent receives a packet carrying a valid Binding Revocation Acknowledgement message, the home agent follows Section 6.2 in processing this message.
ホームエージェントが有効なバインディング取り消し確認メッセージを運ぶパケットを受信すると、ホームエージェントはこのメッセージの処理においてセクション6.2に従います。
To terminate a mobile node PMIPv6 registration and its current binding with the local mobility anchor, the local mobility anchor sends a packet to the mobile access gateway containing a Binding Revocation Indication message following the procedure in Section 6.1 and the following rules:
モバイルノードPMIPV6登録とローカルモビリティアンカーとの現在のバインディングを終了するために、ローカルモビリティアンカーは、セクション6.1および次のルールの手順に従ってバインディング取消度表示メッセージを含むモバイルアクセスゲートウェイにパケットを送信します。
o The Proxy Binding (P) bit MUST be set to indicate that the binding being revoked is a PMIPv6 binding.
o プロキシ結合（P）ビットは、取り消されているバインディングがPMIPv6結合であることを示すように設定する必要があります。
o The Revocation Trigger field MUST be set to indicate to the mobile access gateway the reason for removing the specified mobile node PMIPv6 binding at the local mobility anchor. The Revocation Trigger may be used by the mobile access gateway to learn the mobile node's latest movement.
o 取り消しトリガーフィールドは、ローカルモビリティアンカーで指定されたモバイルノードPMIPV6バインディングを削除する理由をモバイルアクセスゲートウェイに示すように設定する必要があります。Mobile Access Gatewayは、モバイルノードの最新動きを学習するために、モバイルアクセスゲートウェイによって使用される場合があります。
o The packet MUST contain the Mobile Node Identifier (MN-ID) option, which contains the mobile node's Network Access Identifier (NAI) that was used in the Proxy Binding Update during the mobile node registration.
o パケットには、モバイルノード登録中にプロキシバインディングアップデートで使用されたモバイルノードのネットワークアクセス識別子（NAI）を含むモバイルノード識別子（MN-ID）オプションを含める必要があります。
o If the Mobile Node Identifier (MN-ID) is registered in more than one of the mobile node's BCEs and the local mobility anchor does NOT need to revoke all of the mobile node's bindings, the Binding Revocation Indication message MUST contain another identifier to uniquely identify the mobile node binding(s) that is being revoked, e.g., at least one Home Network Prefix option that contains the mobile node's registered Home Network Prefix (HNP) for the binding being revoked.
o モバイルノード識別子（MN-ID）がモバイルノードのBCEを複数以上登録し、ローカルモビリティアンカーがモバイルノードのすべてのバインディングを取り消す必要がない場合、バインディング取消度表示メッセージには別の識別子が含まれている必要があります。取り消されているモバイルノードバインディング（s）は、たとえば、モバイルノードの登録ホームネットワークプレフィックス（HNP）を含む少なくとも1つのホームネットワークプレフィックスオプションを取り消すことができます。
o In the case of revoking all Per-Peer bindings, the local mobility anchor MUST set the Global (G) bit and the Revocation Trigger MUST contain the value "Per-Peer Policy" to request the mobile access gateway to remove all Per-Peer bindings that are registered with the local mobility anchor and this mobile access gateway.
o すべてのピアごとのバインディングを取り消す場合、ローカルモビリティアンカーはグローバル（g）ビットを設定する必要があり、取り消しトリガーには、モバイルアクセスゲートウェイを要求して、すべてのピアごとのバインディングを削除するために「ピアごとのポリシー」を要求する必要があります。ローカルモビリティアンカーとこのモバイルアクセスゲートウェイに登録されています。
o The proxy care-of address for the binding MUST be used as the destination address in the packet's IPv6 header. However, in the case when IPsec is used to protect the Proxy MIPv6 signaling as specified in [RFC5213], the destination address MUST be set to the mag_address that is being used for keying the IPsec SA. If the mag_address is different than the mobile node proxy care-of address, the Alternate Care-of Address option MUST be included and MUST contain the mobile node proxy care-of address.
o バインディングのプロキシケアアドレスは、パケットのIPv6ヘッダーの宛先アドレスとして使用する必要があります。ただし、[RFC5213]で指定されているプロキシMIPV6シグナル伝達を保護するためにIPSECを使用する場合、宛先アドレスは、IPSEC SAのキーに使用されているMAG_ADDRESSに設定する必要があります。mag_addressがモバイルノードプロキシケアオブアドレスと異なる場合、代替のケアオブアドレスオプションを含める必要があり、モバイルノードプロキシケアオブアドレスを含める必要があります。
The local mobility anchor MAY delete the mobile node(s) IP tunnel immediately after sending the initial Binding Revocation Indication and before receiving the Binding Revocation Acknowledgement message.
ローカルモビリティアンカーは、最初のバインディング取り消し表示を送信した直後にモバイルノード（s）IPトンネルを削除し、バインディング取消確認メッセージを受信する前に削除できます。
When the local mobility anchor sends a Binding Revocation Indication to the mobile access gateway to remove a specific binding, the local mobility anchor sets a flag in the mobile node proxy BCE to indicate that revocation is in progress and starts the InitMINDelayBRIs timer. The local mobility anchor SHOULD maintain the mobile node proxy BCE in this state until it receives a Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. In the case when the local mobility anchor sets the Revocation Trigger field to a value that indicates inter-MAG handover, the local mobility anchor MAY switch the mobile node IP tunnel to the target mobile access gateway before sending the Binding Revocation Indication to the source mobile access gateway.
ローカルモビリティアンカーがモバイルアクセスゲートウェイにバインディングの取り消し表示を送信して特定のバインディングを削除すると、ローカルモビリティアンカーはモバイルノードプロキシBCEにフラグを設定して、取り消しが進行中であることを示し、initmindelaybrisタイマーを開始します。ローカルモビリティアンカーは、拘束力のある取り消し承認を受けるか、brimaxretransmitnumberに到達するまで、この状態でモバイルノードプロキシBCEを維持する必要があります。ローカルモビリティアンカーが取り消しトリガーフィールドをMAG間のハンドオーバーを示す値に設定する場合、ローカルモビリティアンカーは、バインディングの取り消し表示をソースモバイルに送信する前に、モバイルノードIPトンネルをターゲットモバイルアクセスゲートウェイに切り替えることができますアクセスゲートウェイ。
In a race condition case, the local mobility anchor may receive a Proxy Binding Update from the mobile access gateway while the mobile node's proxy BCE has the revocation in progress flag set. The local mobility anchor should handle this case based on the reason for sending the Binding Revocation Indication message and its local policy. In this case, if the local mobility anchor accepts the Proxy Binding Update, it needs to update the mobile node proxy BCE accordingly, e.g., removing the revocation in progress flag.
レース状態の場合、ローカルモビリティアンカーはモバイルアクセスゲートウェイからプロキシバインディングアップデートを受け取る場合がありますが、モバイルノードのプロキシBCEには進行状況フラグが取り消されます。ローカルモビリティアンカーは、拘束力のある取り消し表示メッセージとそのローカルポリシーを送信する理由に基づいて、このケースを処理する必要があります。この場合、ローカルモビリティアンカーがプロキシバインディングアップデートを受け入れる場合、それに応じてモバイルノードプロキシBCEを更新する必要があります。
When the local mobility anchor needs to revoke all the mobile node proxy BCEs that are registered with the local mobility anchor and the mobile access gateway peer, it MUST set the Global (G) bit and set the value of the Revocation Trigger field to "Per-Peer Policy". In this case, the local mobility anchor MUST NOT include any mobility options in this Binding Revocation Indication message.
ローカルモビリティアンカーが、ローカルモビリティアンカーとモバイルアクセスゲートウェイピアに登録されているすべてのモバイルノードプロキシBCEを取り消す必要がある場合、Gollove（g）ビットを設定し、「Per」ごとに登場トリガーフィールドの値を「」に設定する必要があります。 - ピアポリシー」。この場合、ローカルモビリティアンカーには、このバインディング取り消し表示メッセージにモビリティオプションを含めてはなりません。
When the local mobility anchor needs to revoke all mobile nodes proxy BCEs that belong to a specific realm and are registered with the local mobility anchor and the mobile access gateway peer, the local mobility anchor MUST set the Global (G) bit and set the value of the Revocation Trigger field to "Revoking Mobility Node Local Policy". In this case, the local mobility anchor MUST include a mobility option in the Binding Revocation Indication that is shared among all the impacted mobile nodes BCEs, e.g., the mobile node identifier option, MN-ID option, with a subtype value of 1. In this case, the NAI value in the MN-ID MUST follow the format where the content after the "@" character defines the realm that is shared amongst all of the impacted mobile nodes proxy BCEs. As an example: @example.com identifies all mobile nodes whose MN-ID value contains "example.com" as the realm, e.g., "1234abdelta@example.com", "axxxyzd@example.com", and "abcdefg.xyz123@example.com", but not "1234abdelta@foo.example.com".
ローカルモビリティアンカーが特定の領域に属し、ローカルモビリティアンカーとモバイルアクセスゲートウェイピアに登録されているすべてのモバイルノードプロキシBCEを取り消す必要がある場合、ローカルモビリティアンカーはグローバル（g）を設定し、値を設定する必要があります。「モビリティノードローカルポリシーの取り消し」への取り消しトリガーフィールドの。この場合、ローカルモビリティアンカーには、影響を受けたすべてのモバイルノードBCE、例えばモバイルノード識別子オプション、MN-IDオプション、サブタイプの値が1の1で共有されるバインディング取り消し表示にモビリティオプションを含める必要があります。この場合、MN-IDのNAI値は、「@」文字の後のコンテンツが、影響を受けたすべてのモバイルノードプロキシBCEの間で共有されるレルムを定義する形式に従う必要があります。例として：@example.comは、MN-ID値が「Example.com」を領域として含むすべてのモバイルノードを識別します。@example.com "ですが、「1234abdelta@foo.example.com」ではありません。
When the local mobility anchor needs to revoke a subgroup of the mobile nodes proxy BCEs that belong to a specific realm and are registered with the local mobility anchor and the mobile access gateway, the local mobility anchor MUST set the Global (G) bit and set the value of the Revocation Trigger field to "Revoking Mobility Node Local Policy". In this case, the local mobility anchor MUST include an additional mobility option to the mobile node identifier option (MN-ID) option, with a subtype value of 1. In other words, the impacted mobile node BCEs are those that have an MN-ID with a realm as specified above and, e.g., are assigned the same proxy care-of address as the one included in the Alternate Care-of Address mobility option.
ローカルモビリティアンカーが、特定の領域に属し、ローカルモビリティアンカーとモバイルアクセスゲートウェイに登録されているモバイルノードプロキシBCEのサブグループを取り消す必要がある場合、ローカルモビリティアンカーはグローバル（g）とセットを設定する必要があります「モビリティノードローカルポリシーを取り消す」への取り消しトリガーフィールドの価値。この場合、ローカルモビリティアンカーには、サブタイプ値が1のモバイルノード識別子オプション（MN-ID）オプションに追加のモビリティオプションを含める必要があります。つまり、影響を受けたモバイルノードBCEはMN-を持つものです。上記で指定された領域を持つID、たとえば、代替ケアオブアドレスモビリティオプションに含まれるものと同じプロキシケアオブアドレスが割り当てられます。
When the mobile node is registered with multiple Home Network Prefixes for the same proxy care-of address, the local mobility anchor SHOULD include an HNP option for each registered HNP in the Binding Revocation Indication. Alternatively, it MAY include only the mobile node identifier (MN-ID) option with the mobile node NAI included to indicate to the mobile access gateway to remove all bindings of the specified mobile node NAI in the MN-ID option.
モバイルノードが同じプロキシケアオブアドレスに対して複数のホームネットワークプレフィックスに登録されている場合、ローカルモビリティアンカーには、バインディング取消度表示に登録された各HNPのHNPオプションを含める必要があります。または、MN-IDオプションで指定されたモバイルノードNAIのすべてのバインディングを削除するために、モバイルアクセスゲートウェイを示すために含まれているモバイルノードNAIを備えたモバイルノード識別子（MN-ID）オプションのみを含めることができます。
According to the Proxy Mobile IPv6 specification [RFC5213], if the local mobility anchor receives a Proxy Binding Update message from a new mobile access gateway for extending the binding lifetime of the only BCE of this mobile node with the Handoff Indicator value set to "Handoff state unknown (4)", the local mobility anchor waits a period of MaxDelayBeforeNewBCEAssign to receive a de-registration message from the previous mobile access gateway before updating the mobile node's BCE with the new point of attachment. If a de-registration message is not received, the local mobility anchor considers the received Proxy Binding Update message as a request for a new BCE and if processed successfully, the local mobility anchor assigns a different HNP for the new BCE.
プロキシモバイルIPv6仕様[RFC5213]によると、ローカルモビリティアンカーが新しいモバイルアクセスゲートウェイからプロキシバインディングアップデートメッセージを受信して、ハンドオフインジケーター値を「ハンドオフ」に設定して、このモバイルノードの唯一のBCEのバインディングライフタイムを「state unknown（4） "、ローカルモビリティアンカーは、Maxdelaybeforenewbceassignの期間を待って、モバイルノードのBCEを新しい添付ポイントで更新する前に、以前のモバイルアクセスゲートウェイから登録解除メッセージを受信します。登録解除メッセージが受信されない場合、ローカルモビリティアンカーは、受信したプロキシバインディングアップデートメッセージを新しいBCEのリクエストと見なし、処理された場合、ローカルモビリティアンカーは新しいBCEに異なるHNPを割り当てます。
This document updates the local mobility anchor's behavior in this case. If the local mobility anchor supports the binding revocation mechanism as described in this document, it SHOULD proactively send a Binding Revocation Indication message to the previous mobile access gateway instead of waiting for a de-registration from the previous mobile access gateway. In the Binding Revocation Indication message, the Revocation Trigger MUST be set to "Inter-MAG Handover - Unknown".
このドキュメントは、この場合のローカルモビリティアンカーの動作を更新します。ローカルモビリティアンカーがこのドキュメントで説明されているように結合取消メカニズムをサポートしている場合、以前のモバイルアクセスゲートウェイからの登録を待つのではなく、以前のモバイルアクセスゲートウェイにバインディング取り消し表示メッセージを積極的に送信する必要があります。拘束力のある取り消し表示メッセージでは、取り消しトリガーは「間隔のハンドオーバー - 不明」に設定する必要があります。
If the local mobility anchor sent a Binding Revocation Indication message with the Revocation Trigger field set to "Inter-MAG Handover - Unknown" and while waiting for a response, Binding Revocation Acknowledgement, the following are possible conditions that the local mobility anchor MUST handle as specified below:
ローカルモビリティアンカーが、「インターマグハンドオーバー - 不明」に設定された取り消しトリガーフィールドを使用して、バインディング取消度表示メッセージを送信し、拘束力のある取り消しの確認を待っている間、以下はローカルモビリティアンカーが処理する必要がある可能性のある条件です。以下に指定されています：
o If the local mobility anchor receives a successful Binding Revocation Acknowledgement message or a de-registration message from the previous mobile access gateway, the local mobility anchor MUST update the mobile node BCE as if it received a de-registration message as described in [RFC5213].
o ローカルモビリティアンカーが、以前のモバイルアクセスゲートウェイから成功したバインディング取り消し承認メッセージまたは登録解除メッセージを受信した場合、ローカルモビリティアンカーは、[RFC5213]で説明されている登録解除メッセージを受信したかのようにモバイルノードBCEを更新する必要があります。。
o If the local mobility anchor receives a Binding Revocation Acknowledgement message with the Status field set to "Revocation Failed - MN is Attached", the local mobility anchor SHOULD update the mobile node BCE as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expired by creating a new BCE as described in [RFC5213].
o ローカルモビリティアンカーが、「失敗に失敗する-MNが添付されている」に設定されたステータスフィールドを使用してバインディング取り消し承認メッセージを受信した場合、ローカルモビリティアンカーは、MaxDelaybeforenewBceasSignの前に登録を受け取らないかのようにモバイルノードBCEを更新する必要があります。[RFC5213]で説明されているように、新しいBCEを作成することにより期限切れになりました。
o If the local mobility anchor did not receive a Binding Revocation Acknowledgement message or a de-registration Proxy Binding Update from the previous mobile access gateway after it exhausted all of the Binding Revocation Indication message retransmissions as described in Section 6.3, the local mobility anchor SHOULD update the mobile node's BCE as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expired by creating a new BCE as described in [RFC5213]. Note that the local mobility anchor SHOULD use the recommended number of retransmissions for the Binding Revocation Indication message as described in Section 11 to avoid delaying the creation of a new Binding Cache entry for too long, if the mobile node is actually attaching to the new MAG with a different interface.
o ローカルモビリティアンカーが、セクション6.3で説明されているように、すべてのバインディング取り消し表示メッセージ再送信を使い果たした後、以前のモバイルアクセスゲートウェイからバインディング取り消し承認メッセージまたは以前のモバイルアクセスゲートウェイからの登録解除プロキシバインディングアップデートを受け取らなかった場合、ローカルモビリティアンカーは更新する必要があります。[RFC5213]に記載されているように、新しいBCEを作成することにより期限切れになったMaxDelaybeForenewBCEASSIGNタイマーの前に、モバイルノードのBCEは登録を受け取らなかったかのように。ローカルモビリティアンカーは、モバイルノードが実際に新しいMAGに接続している場合、新しいバインディングキャッシュエントリの作成を遅らせないように、セクション11で説明したように、バインディング取り消し表示メッセージに推奨される数の再送信数を使用する必要があることに注意してください。別のインターフェイスを使用して。
When the mobile node is registered with an IPv4 proxy home address in addition to the Home Network Prefix where both of the IPv4 proxy HoA (pHoA) and HNP are bound to the same proxy CoA (pCoA), the local mobility anchor MAY revoke the mobile node IPv4 proxy HoA binding to the current mobile node proxy CoA while maintaining the mobile node binding of the HNP to its current pCoA as part of the mobile node BCE. In this case, if the local mobility anchor decides to revoke the mobile node IPv4 proxy HoA only, it MUST send a Binding Revocation Indication message following the procedure in Section 6.1 and the following rules:
モバイルノードがIPv4プロキシHOA（PHOA）とHNPの両方が同じプロキシCOA（PCOA）にバインドされるホームネットワークプレフィックスに加えて、IPv4プロキシホームアドレスに登録されている場合、ローカルモビリティアンカーがモバイルを取り消す場合がありますNode IPv4 Proxy HOAは、モバイルノードBCEの一部としてHNPのモバイルノードバインディングを現在のPCOAに維持しながら、現在のモバイルノードプロキシCOAにバインドしています。この場合、ローカルモビリティアンカーがモバイルノードIPv4プロキシHOAのみを取り消すことを決定した場合、セクション6.1および次のルールの手順に従って、拘束力のある取り消し表示メッセージを送信する必要があります。
o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to indicate that only the IPv4 home address binding is being revoked.
o IPv4 HOAバインディングのみ（V）ビットをBRIに設定して、IPv4ホームアドレスバインディングのみが取り消されていることを示す必要があります。
o The IPv4 Home Address Request option MUST be included with the mobile node's registered proxy home IPv4 address that is being released in addition to the MN-ID option.
o IPv4ホームアドレスリクエストオプションは、MN-IDオプションに加えてリリースされているモバイルノードの登録プロキシHome IPv4アドレスに含める必要があります。
o The mobile node Home Network Prefix option MUST NOT be included.
o モバイルノードホームネットワークプレフィックスオプションを含めてはなりません。
o The Revocation Trigger field MUST be set to an appropriate value, e.g., "User Initiated Session(s) Termination".
o 取り消しトリガーフィールドは、「ユーザー開始セッションの終了」など、適切な値に設定する必要があります。
When the local mobility anchor receives a packet carrying a Binding Revocation Indication that was successfully processed as in Section 6.2, the local mobility anchor processes the message as follows:
ローカルモビリティアンカーが、セクション6.2のように正常に処理された結合取消し兆候を運ぶパケットを受信すると、ローカルモビリティアンカーは次のようにメッセージを処理します。
o If the (P) bit is set, the local mobility anchor MUST validate that all impacted bindings have the proxy binding flag set.
o （P）ビットが設定されている場合、ローカルモビリティアンカーは、衝撃を受けたすべてのバインディングにプロキシバインディングフラグが設定されていることを検証する必要があります。
o If the Global (G) bit is set and the Revocation Trigger field value is "Per-Peer Policy", the LMA MUST validate that the Proxy (P) bit is set and the MN-ID option is present with the mobile access gateway identity included. In addition, the local mobility anchor MUST verify that the identified mobile access gateway as per the value in the MN-ID option is authorized to use the global revocation with revocation trigger value "Per-Peer Policy", see Section 13. If the local mobility anchor processes the Global Binding Revocation Indication message successfully, it MUST accept the Binding Revocation Indication message using the status code "success".
o グローバル（g）ビットが設定されており、取り消しトリガーフィールド値が「ピアごとのポリシー」である場合、LMAはプロキシ（P）ビットが設定され、MN-IDオプションがモバイルアクセスゲートウェイIDとともに存在することを検証する必要があります含まれています。さらに、ローカルモビリティアンカーは、MN-IDオプションの値に従って識別されたモバイルアクセスゲートウェイが、「ピアごとのポリシー」という撤回トリガー値でグローバルな失効を使用することを許可されていることを確認する必要があります。セクション13を参照してください。モビリティアンカーグローバルバインディング取り消し表示メッセージを正常に処理すると、ステータスコード「成功」を使用してバインディング取り消し表示メッセージを受け入れる必要があります。
o If the mobile access gateway is not authorized to use the Per-Peer Global revocation feature or the received Binding Revocation Indication message has the Global (G) bit set and the Revocation Trigger field is set to "Per-Peer Policy", but the MN-ID option is not included, the local mobility anchor MUST reject the Binding Revocation Indication message using status code "Global Revocation NOT Authorized".
o モバイルアクセスゲートウェイがピアごとのグローバル取り消し機能を使用することを許可されていない場合、または受信したバインディングの取り消し表示メッセージにはグローバル（g）ビットセットがあり、取り消しトリガーフィールドは「ピアごとのポリシー」に設定されていますが、MNはMNに設定されています。-idオプションは含まれていません。ローカルモビリティアンカーは、ステータスコードを使用して「グローバル失効」を使用して、拘束力のある取り消し表示メッセージを拒否する必要があります。
o If the Global (G) bit is set and the Revocation Trigger value is "Per-Peer Policy", and only the mobile node identifier (MN-ID) option is included, the local mobility anchor MUST revoke all mobile node bindings for which the proxy CoA is the one used as the source of the IPv6 packet that carried the Binding Revocation Indication. However, if the Alternate Care-of Address option is included in addition to the mobile node identifier option, the local mobility anchor MUST revoke all mobile node bindings whose proxy care-of address matches the care-of address in the Alternate Care-of Address option. After the local mobility anchor successfully processes the Binding Revocation Indication message and identifies all impacted mobile nodes bindings, it MUST accept the Binding Revocation Indication message using the status code "success".
o グローバル（g）ビットが設定されており、取り消しトリガー値が「ピアごとのポリシー」であり、モバイルノード識別子（MN-ID）オプションのみが含まれている場合、ローカルモビリティアンカーはすべてのモバイルノードバインディングを取り消す必要があります。プロキシCOAは、バインディングの取り消し指示を掲載したIPv6パケットのソースとして使用されるものです。ただし、モバイルノード識別子オプションに加えて代替ケアオブアドレスオプションが含まれている場合、ローカルモビリティアンカーは、代替ケアオブアドレスのアドレスのケアと一致するすべてのモバイルノードバインディングを取り消す必要があります。オプション。ローカルモビリティアンカーがバインディング取消し表示メッセージを正常に処理し、影響を受けたすべてのモバイルノードバインディングを識別した後、ステータスコード「成功」を使用してバインディング取消度表示メッセージを受け入れる必要があります。
o If the local mobility anchor accepted the Binding Revocation Indication message but one or more of the bindings identified in the received Binding Revocation Indication message has already been released, the local mobility anchor MUST accept the message and it MAY set the Status field to "partial success" and include the mobile node identifier (MN-ID) or the Home Network Prefix option to identify the binding(s) that failed the revocation procedure.
o ローカルモビリティアンカーがバインディング取り消し表示メッセージを受け入れたが、受信したバインディング取り消し表示メッセージで識別されたバインディングの1つ以上がすでにリリースされている場合、ローカルモビリティアンカーはメッセージを受け入れ、ステータスフィールドを「部分的な成功」に設定する必要があります。「モバイルノード識別子（MN-ID）またはホームネットワークプレフィックスオプションを含めて、取り消し手順に失敗したバインディングを識別します。
o If the Global (G) bit is not set, the local mobility anchor uses the included mobility options to identify the impacted mobile node binding as follows:
o グローバル（g）ビットが設定されていない場合、ローカルモビリティアンカーは含まれているモビリティオプションを使用して、次のように影響を受けたモバイルノードバインディングを識別します。
1. If only the mobile node identifier (MN-ID) option is included, the local mobility anchor MUST accept the message and revoke all bindings for this mobile node that use the specified mobile node NAI including the IPv4 Home Address binding(s) if present.
1. モバイルノード識別子（MN-ID）オプションのみが含まれている場合、ローカルモビリティアンカーはメッセージを受け入れ、存在する場合はIPv4ホームアドレスバインディングを含む指定されたモバイルノードNAIを使用するこのモバイルノードのすべてのバインディングを取り消す必要があります。
2. If the mobile node identifier (MN-ID) and one Home Network Prefix option are included, the local mobility anchor MUST accept the message and only remove the specified mobile node proxy binding.
2. モバイルノード識別子（MN-ID）と1つのホームネットワークプレフィックスオプションが含まれている場合、ローカルモビリティアンカーはメッセージを受け入れ、指定されたモバイルノードプロキシバインディングのみを削除する必要があります。
3. If the mobile node identifier (MN-ID) option and more than one Home Network Prefix options are included, the local mobility anchor MUST accept the message and remove all bindings that are referenced by these Home Network Prefixes for the specified mobile node NAI.
3. モバイルノード識別子（MN-ID）オプションと複数のホームネットワークプレフィックスオプションが含まれている場合、ローカルモビリティアンカーはメッセージを受け入れ、指定されたモバイルノードNAIのこれらのホームネットワークプレフィックスによって参照されるすべてのバインディングを削除する必要があります。
4. If the IPv4 HoA binding Only (V) bit is set and the mobile node identifier (MN-ID) option and the IPv4 Home Address Request option are included, the local mobility anchor MUST accept the message and remove only the IPv4 HoA address binding to the mobile node current proxy care-of address.
4. IPv4HOAバインディングのみ（v）ビットが設定され、モバイルノード識別子（MN-ID）オプションとIPv4ホームアドレスリクエストオプションが含まれている場合、ローカルモビリティアンカーはメッセージを受け入れ、IPv4HOAアドレスのみを削除する必要があります。モバイルノード電流プロキシケアオブアドレス。
The Revocation Trigger field value in the received Binding Revocation Indication could be used by the local mobility anchor to log an event or update some local parameters that track the state of the peer mobile access gateway.
受信した拘束力のある取り消し表示の取り消しトリガーフィールド値は、ローカルモビリティアンカーによって使用されて、イベントを記録するか、ピアモバイルアクセスゲートウェイの状態を追跡するローカルパラメーターを更新できます。
After the local mobility anchor accepts or rejects a Binding Revocation Indication message, the local mobility anchor MUST follow Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement message to the mobile access gateway.
ローカルモビリティアンカーが拘束力のある取り消し表示メッセージを受け入れるか拒否した後、ローカルモビリティアンカーはセクション6.1および6.1.2に従って、モバイルアクセスゲートウェイに拘束力のある取り消し承認メッセージを送信する必要があります。
When the mobile access gateway receives a packet carrying a Binding Revocation Indication that was successfully processed as in Section 6.2, the mobile access gateway processes the message as follows:
モバイルアクセスゲートウェイが、セクション6.2のように正常に処理されたバインディングの取り消し表示を運ぶパケットを受信すると、モバイルアクセスゲートウェイは次のようにメッセージを処理します。
o If the Global (G) bit is set and the Revocation Trigger field value is "Per-Peer Policy", the mobile access gateway MUST validate that the Proxy (P) bit is set and no mobility options are included in the message. If the mobile access gateway processes the Global Binding Revocation Indication message successfully, it MUST accept the Binding Revocation Indication message using the status code "success".
o グローバル（g）ビットが設定されており、取り消しトリガーフィールド値が「ピアごとのポリシー」の場合、モバイルアクセスゲートウェイはプロキシ（P）ビットが設定されており、モビリティオプションがメッセージに含まれていないことを検証する必要があります。モバイルアクセスゲートウェイがグローバルバインディングの取り消し表示メッセージを正常に処理する場合、ステータスコード「成功」を使用してバインディング取り消し表示メッセージを受け入れる必要があります。
o If the Global (G) bit is set and the Revocation Trigger field value is "Revoking Mobility Node Local Policy", the mobile access gateway MUST validate that the Proxy (P) bit is set and at least the MN-ID option with the subtype value of 1 is included in the Binding Revocation Indication and it is formatted as described is Section 8.1. If the mobile access gateway processes this Global Binding Revocation Indication message successfully, it MUST accept the message using the status code "success".
o グローバル（g）ビットが設定されており、取り消しトリガーフィールド値が「モビリティノードローカルポリシーを取り消す」場合、モバイルアクセスゲートウェイはプロキシ（P）ビットが設定され、少なくともサブタイプのMN-IDオプションが設定されていることを検証する必要があります1の値は、拘束力のある取り消し表示に含まれており、説明されているようにフォーマットされています。モバイルアクセスゲートウェイがこのグローバルバインディングの取り消し表示メッセージを正常に処理する場合、ステータスコード「成功」を使用してメッセージを受け入れる必要があります。
o If the Global (G) bit is set and the Revocation Trigger field value is "Revoking Mobility Node Local Policy", and no mobility options are included in the Binding Revocation Indication message or the mobile access gateway is not able to identify the impacted mobile nodes bindings based on the included mobility options, the mobile access gateway MUST treat this as an error scenario. In this case, the mobile access gateway MUST reject the Binding Revocation Indication message using status code "Revoked Mobile Nodes Identity Required".
o グローバル（g）ビットが設定されており、取り消しトリガーフィールド値が「モビリティノードローカルポリシーを取り消している」場合、モビリティオプションがバインディング取消し表示メッセージに含まれていない場合、またはモバイルアクセスゲートウェイが影響を受けたモバイルノードを識別できない場合含まれているモビリティオプションに基づいて、モバイルアクセスゲートウェイはこれをエラーシナリオとして扱う必要があります。この場合、モバイルアクセスゲートウェイは、ステータスコードを使用してバインディング取り消し表示メッセージを拒否する必要があります。
o If the Revocation Trigger field value in the received Binding Revocation Indication message indicates inter-MAG handover, e.g., Inter-MAG Handover - Unknown, the mobile access gateway uses the mobility option(s) included in the Binding Revocation Indication message to identify the mobile node binding. The mobile access gateway SHOULD ensure that the mobile node is no longer attached to the mobile access gateway before accepting the BRI message using status code "success". However, if the mobile access gateway verified that the mobile node is still directly attached, the mobile access gateway MUST reject the BRI using status code "Revocation failed - MN is Attached".
o 受信したバインディングの取り消し表示メッセージの取り消しトリガーフィールド値は、マグ間のハンドオーバー、例えばマグ間ハンドオーバー - 不明である場合、モバイルアクセスゲートウェイは、バインディング取消度表示メッセージに含まれるモビリティオプションを使用してモバイルを識別しますノードバインディング。モバイルアクセスゲートウェイは、ステータスコード「成功」を使用してBRIメッセージを受け入れる前に、モバイルノードがモバイルアクセスゲートウェイに接続されなくなったことを確認する必要があります。ただし、モバイルアクセスゲートウェイがモバイルノードがまだ直接添付されていることを確認した場合、モバイルアクセスゲートウェイは、ステータスコードを使用してBRIを拒否する必要があります。
o If the IPv4 HoA Binding Only (V) bit is set, the mobile access gateway uses the MN-ID option to identify the mobile node binding entry in the Binding Update List (BUL). The mobile access gateway MUST verify that the IPv4 address included in the IPv4 Home Address Request option in the received Binding Revocation Indication is the same as the IPv4 proxy HoA that is assigned to the mobile node. After the mobile access gateway successfully validates the received IPv4 home address as the mobile node IPv4 HoA, it MUST consider this as an indication to ONLY release the mobile node IPv4 proxy HoA binding to the mobile node current proxy CoA. Consequently, it MUST continue to maintain the mobile node IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 proxy HoA binding to the MN pCoA. If the mobile access gateway processed the BRI successfully, the mobile access gateway MUST accept the BRI using status code "success". On the other hand, if the mobile access gateway is able to identify the mobile node binding using the MN-ID but failed to identify the received IPv4 proxy HoA, the mobile access gateway MUST reject the BRI using status code "Binding Does NOT Exist".
o IPv4HOAバインディングのみ（v）ビットが設定されている場合、モバイルアクセスゲートウェイはMN-IDオプションを使用して、バインディングアップデートリスト（BUL）のモバイルノードバインディングエントリを識別します。Mobile Access Gatewayは、受信した拘束力のある取り消し表示のIPv4ホームアドレス要求オプションに含まれるIPv4アドレスが、モバイルノードに割り当てられたIPv4プロキシHOAと同じであることを確認する必要があります。モバイルアクセスゲートウェイが受信したIPv4ホームアドレスがモバイルノードIPv4HOAとして正常に検証された後、これをモバイルノードIPv4プロキシHOAのみをモバイルノード電流プロキシCOAにリリースすることのみを示すことを考慮する必要があります。したがって、モバイルノードIPv6プロキシHOAまたはHNPが現在のモバイルノードプロキシCOAにバインディングされ、MN PCOAに関連付けられているMN IPv4プロキシHOAに関連するすべてのリソースをリリースし、MN PCOAにバインディングするすべてのリソースを維持し続ける必要があります。。モバイルアクセスゲートウェイがBRIを正常に処理した場合、モバイルアクセスゲートウェイはステータスコード「成功」を使用してBRIを受け入れる必要があります。一方、モバイルアクセスゲートウェイがMN-IDを使用してモバイルノードバインディングを識別できるが、受信したIPv4プロキシHOAを識別できなかった場合、モバイルアクセスゲートウェイはステータスコードを使用してBRIを拒否する必要があります。。
o If the mobile access gateway accepts the Binding Revocation Indication message but one or more of the bindings identified in the received Binding Revocation Indication message has already been released before processing the Binding Revocation Indication, the mobile access gateway MUST accept the Binding Revocation Indication message. In this case, the mobile access gateway MAY set the Status field to "partial success" and include the mobile node identifier (MN-ID) or the Home Network Prefix option to identify the binding(s) that failed to be removed as part of the revocation procedure.
o モバイルアクセスゲートウェイがバインディング取り消し表示メッセージを受け入れますが、バインディングの取り消し表示を処理する前に、受信されたバインディング取り消し表示メッセージで識別された1つ以上のバインディングがすでにリリースされている場合、モバイルアクセスゲートウェイはバインディング取消度表示メッセージを受け入れる必要があります。この場合、モバイルアクセスゲートウェイは、ステータスフィールドを「部分的な成功」に設定し、モバイルノード識別子（MN-ID）またはホームネットワークプレフィックスオプションを含めることができます。取り消し手順。
The Revocation Trigger field value in the received Binding Revocation Indication could be used by the mobile access gateway to define what actions the mobile access gateway could do to inform the mobile node that its IP connectivity to the current HNP has been terminated, e.g., if the Revocation Trigger field is set to "Administrative Reason", the mobile access gateway may terminate the IPv6 or IPv4 mobility session on the access link and notify the mobile node. The specific details and considerations on how the mobile access gateway terminates IPv6 or IPv4 mobility session on the access link and notifies the mobile node can be found in [RFC5213] and [RFC5844].
Mobile Access Gatewayで、受信したバインディングの取り消し表示の取り消しトリガーフィールド値を使用して、モバイルアクセスゲートウェイがモバイルノードに現在のHNPへのIP接続が終了したことを通知するためにできるアクションを定義できます。取り消しトリガーフィールドは「管理上の理由」に設定されており、モバイルアクセスゲートウェイは、アクセスリンクのIPv6またはIPv4モビリティセッションを終了し、モバイルノードに通知する場合があります。モバイルアクセスゲートウェイがアクセスリンクでIPv6またはIPv4モビリティセッションを終了し、モバイルノードに通知する方法に関する特定の詳細と考慮事項は、[RFC5213]および[RFC5844]にあります。
After the mobile access gateway accepts or rejects a Binding Revocation Indication message, the mobile access gateway MUST follow Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement message to the local mobility anchor.
モバイルアクセスゲートウェイが拘束力のある取り消し表示メッセージを受け入れるか拒否した後、モバイルアクセスゲートウェイはセクション6.1および6.1.2に従って、ローカルモビリティアンカーにバインディング取り消し確認メッセージを送信する必要があります。
The mobile access gateway could send a Binding Revocation Indication message to indicate the termination of multiple mobile node bindings, e.g., when using the global revocation with the Global (G) bit set. In this case, when an event occurs that requires the mobile access gateway to inform the local mobility anchor peer to terminate all mobile node bindings that are registered at the local mobility anchor and the mobile access gateway, the mobile access gateway sends a Binding Revocation Indication message following the procedure in Section 6.1 and the following:
モバイルアクセスゲートウェイは、グローバル（g）ビットセットでグローバルな取り消しを使用する場合、複数のモバイルノードバインディングの終了を示すために、バインディングの取り消し表示メッセージを送信できます。この場合、モバイルアクセスゲートウェイを必要とするイベントが発生した場合、ローカルモビリティアンカーピアにローカルモビリティアンカーとモバイルアクセスゲートウェイで登録されているすべてのモバイルノードバインディングを終了するように通知するために、モバイルアクセスゲートウェイは拘束力のある取り消し兆候を送信しますセクション6.1の手順に続くメッセージおよび以下：
o The Proxy Binding (P) bit MUST be set to indicate that the binding(s) being revoked is a PMIPv6 binding.
o プロキシ結合（P）ビットは、取り消されるバインディングがPMIPv6結合であることを示すように設定する必要があります。
o The Global (G) bit MUST be set and the Revocation Trigger MUST contain a value of "Per-Peer Policy" in the Binding Revocation Indication to request the local mobility anchor to remove all Per-Peer bindings that are registered with the local mobility anchor and the mobile access gateway. In this case, the MN-ID option MUST be included in the Binding Revocation Indication and contain the mobile access gateway identity. In addition, the mobile access gateway MAY include the Alternate Care-of Address option. If included, the Alternate Care-of Address option MUST contain the proxy care-of address the bindings that are being impacted by this Binding Revocation Indication message.
o グローバル（g）ビットを設定する必要があり、取り消しトリガーには、ローカルモビリティアンカーに登録されているすべてのピアごとのバインディングを削除するためにローカルモビリティアンカーに要求するために、拘束力のある取り消し表示に「ピアごとのポリシー」の値を含める必要がありますモバイルアクセスゲートウェイ。この場合、MN-IDオプションをバインディング取り消し表示に含め、モバイルアクセスゲートウェイのIDを含める必要があります。さらに、モバイルアクセスゲートウェイには、代替ケアオブアドレスオプションが含まれる場合があります。含まれている場合、代替ケアオブアドレスオプションには、この拘束力のある取り消し表示メッセージによって影響を受けているバインディングにプロキシケアオブアドレスが含まれている必要があります。
o The mobile access gateway address MAY be used as the source address in the packet's IPv6 header.
o モバイルアクセスゲートウェイアドレスは、パケットのIPv6ヘッダーのソースアドレスとして使用できます。
As described in Section 6.3, the mobile access gateway SHOULD retransmit the Binding Revocation Indication to the local mobility anchor until it receives a matching Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile access gateway MAY delete the mobile node IP tunnels immediately after sending the Binding Revocation Indication and before receiving a Binding Revocation Acknowledgement message from the LMA.
セクション6.3で説明されているように、モバイルアクセスゲートウェイは、一致するバインディングの取り消し謝辞を受け取るか、brimaxretransmitNumberに到達するまで、ローカルモビリティアンカーへの結合取消し表示を再送信する必要があります。モバイルアクセスゲートウェイは、バインディングの取り消し表示を送信した直後にモバイルノードIPトンネルを削除し、LMAからバインディング取り消し承認メッセージを受信する前に削除する場合があります。
In response to a Binding Revocation Indication message, if the mobile access gateway receives a packet carrying a Binding Revocation Acknowledgement that was successfully processed as in Section 6.2 and the Status field indicates "Global Revocation NOT Authorized", the mobile access gateway is not authorized to participate in a Per-Peer Global Revocation. The mobile access gateway SHOULD NOT retry sending a Binding Revocation Indication with the Global (G) bit set and the Revocation Trigger field value set to "Per-Peer Policy" to the same local mobility agent. The mobile access gateway should raise an alarm or log an event to indicate this rejection.
拘束力のある取り消し表示メッセージに応答して、モバイルアクセスゲートウェイがセクション6.2のように成功裏に処理されたバインディング取り消し承認を運ぶパケットを受信し、ステータスフィールドは「グローバルな失効が許可されていない」ことを示している場合、モバイルアクセスゲートウェイはピアごとのグローバルな取り消しに参加します。モバイルアクセスゲートウェイは、グローバル（g）ビットセットと撤回トリガーフィールド値を同じローカルモビリティエージェントに「ピアごとのポリシー」にトリガーする拘束力のある取り消し表示を送信しないでください。モバイルアクセスゲートウェイは、この拒絶を示すためにアラームを上げたり、イベントをログにしたりする必要があります。
Upon receiving a packet carrying a Binding Revocation Indication, the mobile node MUST validate the packet according to Section 6.2 and the following tests:
バインディングの取り消し表示を担当するパケットを受信すると、モバイルノードはセクション6.2および次のテストに従ってパケットを検証する必要があります。
o The mobile node MUST verify that the IP address in the Type 2 routing header is its Home Address and that its Binding Update List contains an entry for that Home Address. If one of the tests fails, the mobile node SHOULD silently discard the received Binding Revocation Indication message.
o モバイルノードは、タイプ2ルーティングヘッダーのIPアドレスがホームアドレスであり、そのバインディングアップデートリストにそのホームアドレスのエントリが含まれていることを確認する必要があります。テストの1つが失敗した場合、モバイルノードは受信したバインディングの取り消し表示メッセージを静かに破棄する必要があります。
o If mobile node Binding Update List contains an entry for the IP address in the Type 2 routing header of the received Binding Revocation Indication packet, the mobile node MUST accept the BRI message using status code "success".
o モバイルノードバインディングアップデートリストに、受信したバインディング装備表示パケットのタイプ2ルーティングヘッダーのIPアドレスのエントリが含まれている場合、モバイルノードはステータスコード「成功」を使用してBRIメッセージを受け入れる必要があります。
o If the IPv4 HoA Binding Only (V) bit is set in the received BRI message, the mobile node MUST verify that there is an IPv4 Home Address option in the received Binding Revocation Indication and the IPv4 address included in the IPv4 Home Address option is the same as its IPv4 HoA that is assigned to the mobile node. If this verification is successful, the mobile node MUST consider this Binding Revocation Indication as an indication to ONLY release the mobile node IPv4 HoA binding to its current care-of address. Consequently, the mobile node MUST continue to maintain its IPv6 HoA binding to the current CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 HoA binding. In this case, the mobile node MUST accept the Binding Revocation Indication message using status code "success". On the other hand, if the IPv4 Home Address Option was NOT included in the received BRI with the (V) bit is set, the MN MUST reject the BRI message with status code "IPv4 Home Address Option Required". Additionally, if the IPv4 HoA received in the IPv4 Home Address Option is NOT the one assigned to the mobile node, the mobile node SHOULD reject the Binding Revocation Indication with status code "Binding Does NOT Exist".
o IPv4HOAバインディングのみ（v）ビットが受信したBRIメッセージに設定されている場合、モバイルノードは、受信したバインディング取り消し表示にIPv4ホームアドレスオプションがあることを確認する必要があり、IPv4ホームアドレスオプションに含まれるIPv4アドレスはモバイルノードに割り当てられているIPv4HOAと同じです。この検証が成功した場合、モバイルノードは、このバインディングの取り消し兆候を、モバイルノードIPv4HOAの現在のケアのケアにのみリリースすることのみを示すことと見なす必要があります。その結果、モバイルノードは、BULエントリのモバイルノードバインディングの一部として現在のCOAへのIPv6 HOAバインディングを維持し続け、MN IPv4HOAバインディングに関連するすべてのリソースをリリースする必要があります。この場合、モバイルノードは、ステータスコード「成功」を使用して、バインディング取り消し表示メッセージを受け入れる必要があります。一方、IPv4ホームアドレスオプションが（V）ビットが設定された受信BRIに含まれていない場合、MNはステータスコード「IPv4ホームアドレスオプションが必要」でBRIメッセージを拒否する必要があります。さらに、IPv4ホームアドレスオプションで受信したIPv4HOAがモバイルノードに割り当てられたオプションではない場合、モバイルノードはステータスコード「バインディングは存在しない」でバインディングの取り消し表示を拒否する必要があります。
o The mobile node MUST verify that the (P) bit in the Binding Revocation Indication is NOT set. If the (P) bit is set, the mobile node MUST reject the Binding Revocation Indication using status code "Proxy Binding Revocation NOT Supported".
o モバイルノードは、バインディングの取り消し表示の（p）ビットが設定されていないことを確認する必要があります。（p）ビットが設定されている場合、モバイルノードは、「サポートされていないプロキシバインディング取消」というステータスコードを使用して、バインディングの取り消し表示を拒否する必要があります。
o If the mobile node has registered multiple care-of addresses with its home agent, the mobile node MUST verify which binding is being revoked by examining the content of the Binding Revocation Indication message. If the mobile node received a Binding Revocation Indication with one or more BID options and its home address is included in the Type 2 routing header, the mobile node MUST consider all of the care-of addresses bindings, identified in the BID options, with this home address as being revoked. In this case, if the BRI validation is successful, the mobile node MUST accept the Binding Revocation Indication message with status code "success".
o モバイルノードがホームエージェントに複数のケアアドレスを登録している場合、モバイルノードは、バインディング取消し表示メッセージの内容を調べることにより、どのバインディングが取り消されているかを確認する必要があります。モバイルノードが1つ以上の入札オプションを使用したバインディングリコーク表示を受け取り、そのホームアドレスがタイプ2ルーティングヘッダーに含まれている場合、モバイルノードは、これとともに入札オプションで識別されるすべてのケアアドレスバインディングを考慮する必要があります。取り消されているホームアドレス。この場合、BRIの検証が成功した場合、モバイルノードは、ステータスコード「成功」を使用したバインディング取り消し表示メッセージを受け入れる必要があります。
o If the mobile node has multiple care-of address bindings with its home agent and received a Binding Revocation Indication, without any BID option included and its home address was included in the Type 2 routing header, the mobile node MUST consider all of its registered care-of address bindings with this home address as being revoked. If the mobile node validates the BRI successfully, the mobile node MUST accept the Binding Revocation Indication message with status code "success".
o モバイルノードには、ホームエージェントと複数の住所ケアバインディングがあり、入札オプションが含まれていない拘束力のある取り消し表示を受け、ホームアドレスがタイプ2ルーティングヘッダーに含まれている場合、モバイルノードは登録ケアのすべてを考慮する必要があります。-ofこの自宅の住所が取り消されているように、バインディングのアドレス。モバイルノードがBRIを正常に検証した場合、モバイルノードはステータスコード「成功」を使用したバインディング取り消し表示メッセージを受け入れる必要があります。
If the mobile node accepts or rejects the Binding Revocation Indication message, the mobile node MUST follow Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement message to the home agent. Note that anytime the MN does not send a Binding Revocation Acknowledgement to a BRI, the initiator is likely to retransmit the BRI at least one time. This causes additional load on the initiator who sends the retransmissions, as well as on the MN that will receive and process them.
モバイルノードがバインディングの取り消し表示メッセージを受け入れるか拒否した場合、モバイルノードはセクション6.1および6.1.2に従って、ホームエージェントにバインディング取り消し謝辞メッセージを送信する必要があります。MNがBRIに拘束力のある取り消し承認を送信しない場合は、イニシエーターがBRIを少なくとも1回再送信する可能性が高いことに注意してください。これにより、再送信を送信するイニシエーターと、それらを受信および処理するMNに追加の負荷が発生します。
The Revocation Trigger field value in the received Binding Revocation Indication could be used by the mobile node to define what action the mobile node could do to be able to register again and receive its IP mobility service, e.g., contacting its home operator.
受信した拘束力のある取り消し表示の取り消しトリガーフィールド値は、モバイルノードによって使用されて、モバイルノードが再び登録してIPモビリティサービスを受け取ることができるアクションを定義できます。
Any mobility entity that is allowed to invoke the binding revocation procedure by sending a Binding Revocation Indication message SHOULD allow the following variables to be configured.
拘束力のある取り消し表示メッセージを送信して拘束力のある取り消し手順を呼び出すことが許可されているモビリティエンティティは、次の変数を構成できるようにする必要があります。
BRI Maximum Number of Retries (BRIMaxRetriesNumber)
BRIの最大回収数（brimaxretriesNumber）
This variable specifies the maximum Number of times a mobility entity can retransmit a Binding Revocation Indication message before receiving a Binding Revocation Acknowledgement message. The default value for this parameter is 1.
この変数は、拘束力のある取り消し承認メッセージを受信する前に、モビリティエンティティが拘束力のある取り消し表示メッセージを再送信できる最大回数を指定します。このパラメーターのデフォルト値は1です。
Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
BRIメッセージ間の最初の最小遅延（initmindelaybris）
This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but is not to be configured to less than 0.5 seconds.
この変数は、Mobility EntityがBRIメッセージを再送信する前に、数秒で初期遅延タイムアウトを指定します。デフォルトは1秒ですが、0.5秒未満に構成されていません。
Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)
最大ブラジャータイムアウト（max_brack_timeout）
This variable specifies the maximum delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 2 seconds.
この変数は、Mobility EntityがBRIメッセージを再送信する前に、数秒で最大遅延タイムアウトを指定します。デフォルトは2秒です。
This specification defines a new Binding Revocation Message using a new Mobility Header Type 16, as described in Section 5. The new Mobility Header type value needs to be assigned from the same numbering space as allocated for the other Mobility Header types registry.
この仕様では、セクション5で説明されているように、新しいモビリティヘッダータイプ16を使用した新しいバインディング取り消しメッセージを定義します。新しいモビリティヘッダータイプ値は、他のモビリティヘッダータイプレジストリに割り当てられたのと同じ番号付けスペースから割り当てる必要があります。
This document also creates a new registry "Binding Revocation Type" that indicates the type of the binding revocation message. The current binding revocation message types are described in Sections 5.1 and 5.2, and are the following:
また、このドキュメントでは、バインディング取消メッセージのタイプを示す新しいレジストリ「バインディング取り消しタイプ」も作成します。現在のバインディングの取り消しメッセージタイプは、セクション5.1および5.2で説明されており、次のとおりです。
0 Reserved 1 Binding Revocation Indication 2 Binding Revocation Acknowledgement All other values are unassigned
0予約済み1バインディング取り消し表示
Future values of the Binding Revocation Type can be allocated using Standards Action or IESG Approval [RFC5226].
拘束力のある取り消しタイプの将来の値は、標準アクションまたはIESG承認[RFC5226]を使用して割り当てることができます。
In addition, this document also creates a second new registry for the Revocation Trigger that indicates the reason behind sending the Binding Revocation Indication message. The current Revocation Trigger values are described in Section 5.1, and are the following:
さらに、このドキュメントでは、拘束力のある取り消し表示メッセージの送信の背後にある理由を示す取り消しトリガーの2番目の新しいレジストリも作成されます。現在の取り消しトリガー値はセクション5.1で説明されており、次のとおりです。
Per-MN Revocation Trigger Values: 0 Unspecified 1 Administrative Reason 2 Inter-MAG Handover - same Access Type 3 Inter-MAG Handover - different Access Type 4 Inter-MAG Handover - Unknown 5 User-Initiated Session(s) Termination 6 Access Network Session(s) Termination 7 Possible Out-of-Sync BCE State
PER-MN ROGATOCER TRIGGER値：0不特定1管理理由2マグ間ハンドオーバー - 同じアクセスタイプ3インターマグハンドオーバー - 異なるアクセスタイプ4ハンドオーバー - 不明5ユーザー開始セッション6アクセスネットワークセッション（s）終了7可能性のあるBCE状態の可能性
Global Revocation Trigger Values: 128 Per-Peer Policy 129 Revoking Mobility Node Local Policy
グローバルな取り消しトリガー値：128ピアごとのポリシー129モビリティノードローカルポリシーの取り消し
Reserved Revocation Trigger Values: 250-255 Reserved For Testing Purposes only All other values are Unassigned
予約された取り消しトリガー値：250-255テスト用に予約されている他のすべての値のみが割り当てられていません
Future values of the Revocation Trigger can be allocated using Standards Action or IESG Approval [RFC5226].
取り消しトリガーの将来の値は、標準アクションまたはIESG承認[RFC5226]を使用して割り当てることができます。
Furthermore, this document creates a third new registry "Binding Revocation Acknowledgement Status Codes". The current values are described in Section 5.2, and are the following:
さらに、このドキュメントでは、3番目の新しいレジストリ「拘束力のある取り消し確認ステータスコード」を作成します。現在の値はセクション5.2で説明されており、次のとおりです。
0 success 1 partial success 128 Binding Does NOT Exist 129 IPv4 Home Address Option Required 130 Global Revocation NOT Authorized 131 Revoked Mobile Nodes Identity Required 132 Revocation Failed - MN is Attached 133 Revocation Trigger NOT Supported 134 Revocation Function NOT Supported 135 Proxy Binding Revocation NOT Supported
0成功1部分成功128拘束は存在しません
Future values of the Status field can be allocated using Standards Action or IESG Approval [RFC5226].
ステータスフィールドの将来の値は、標準アクションまたはIESG承認[RFC5226]を使用して割り当てることができます。
All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval.
「予約済み」とラベル付けされたすべてのフィールドは、標準訴訟またはIESGの承認を通じてのみ割り当てられます。
This specification allows the mobility node that initiates the binding revocation procedure to revoke a mobility session(s) that is currently registered with it. It is NOT allowed for any mobility node to revoke a mobile node mobility session that is not registered with this mobility node.
この仕様により、現在登録されているモビリティセッションを取り消すために、バインディング取消手順を開始するモビリティノードが可能になります。モビリティノードは、このモビリティノードに登録されていないモバイルノードモビリティセッションを取り消すことはできません。
The binding revocation protocol described in this specification uses the same security association between the mobile node and the home agent or the mobile access gateway and the local mobility anchor that is being used to exchange the MIPv6 or PMIPv6 Binding Update and Binding Acknowledgement signaling. If IPsec is used, the traffic selectors associated with the Security Policy Database (SPD) entry protecting the Binding Update and Binding Acknowledgement MUST be extended to include Binding Revocation Message MH type 16. Extending the traffic selectors of the SPD entry in order to reuse the SA protecting the Binding Update and Binding Acknowledgement (instead of creating new ones) ensures that those SAs will be up and running when the revoking entity needs to send a binding revocation signaling message.
この仕様で説明されているバインディング取り消しプロトコルは、モバイルノードとホームエージェントまたはモバイルアクセスゲートウェイとの間の同じセキュリティアソシエーションと、MIPV6またはPMIPV6の結合更新とバインディングの確認シグナルを交換するために使用されているローカルモビリティアンカーを使用します。IPSECを使用する場合、セキュリティポリシーデータベース（SPD）エントリに関連付けられたトラフィックセレクターは、バインディングアップデートとバインディングの確認を保護する必要があります。SAは、バインディングアップデートと拘束力のある承認を保護することで（新しいものを作成する代わりに）、拘束力のある取り消しシグナリングメッセージを送信する必要がある場合に、それらのSASが稼働することを保証します。
On the other hand, if IPsec is not used as the underlying security mechanism to protect the Mobile IPv6 and its extensions binding registration signaling, the used underlying security mechanism MUST provide protection against all identified security threats as described under "Security Considerations" in [RFC3775] and [RFC5213].
一方、IPSECがモバイルIPv6とその拡張バインディング登録シグナリングを保護するための基礎となるセキュリティメカニズムとして使用されていない場合、使用される基礎となるセキュリティメカニズムは、[RFC3775の「セキュリティに関する考慮事項」に記載されているすべての識別されたセキュリティ脅威に対する保護を提供する必要があります。]および[RFC5213]。
Since some mobility entities, e.g., local mobility anchor and mobile access gateway, are allowed to send and receive Binding Revocation Indications and Binding Revocation Acknowledgements for different cases, when IPsec is used to secure signaling between the local mobility anchor and mobile access gateway, it prevents any of them from processing a Binding Revocation Message that was not constructed by an authorized party.
一部のモビリティエンティティ、たとえばローカルモビリティアンカーやモバイルアクセスゲートウェイは、IPSECを使用してローカルモビリティアンカーとモバイルアクセスゲートウェイの間の信号を確保するために使用される場合、さまざまなケースの拘束力のある取消しの適応と拘束力のある取り消し謝辞を送信および受信することが許可されているため、それらのいずれかが、承認された当事者によって構築されていない拘束力のある取り消しメッセージを処理することを防ぎます。
The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways. Therefore, the mobile access gateway that is authorized to create or manipulate the mobile node proxy BCE is also authorized to revoke such mobile node registration by sending a de-registration with lifetime of zero.
プロキシモバイルIPv6 [RFC5213]では、ローカルモビリティアンカーが、プロキシバインディングの作成と操作を特別に認定されたモバイルアクセスゲートウェイに制限する必要があります。したがって、モバイルノードプロキシBCEを作成または操作することが許可されているモバイルアクセスゲートウェイは、ゼロの寿命のある登録を送信することにより、このようなモバイルノード登録を取り消すことも許可されています。
However, since bulk termination using Binding Revocation Indication with the Global (G) bit set and the Revocation Trigger field set to "Per-Peer Policy" impacts all mobility sessions that are registered with the mobile access gateway and its local mobility anchor peer, the local mobility anchor MUST be locally configurable to authorize such specific functionality. Additional mechanisms, such as a policy store or Authentication, Authorization, and Accounting (AAA) may be employed, but these are outside the scope of this specification.
ただし、グローバル（g）ビットセットと「ポリシーあたりポリシー」に設定された取り消しトリガーフィールドを使用したバインディング取り消し表示を使用したバルク終了は、モバイルアクセスゲートウェイとそのローカルモビリティアンカーピアに登録されているすべてのモビリティセッションに影響を与えます。ローカルモビリティアンカーは、このような特定の機能を承認するためにローカルで構成できる必要があります。ポリシーストアや認証、承認、会計（AAA）などの追加のメカニズムが採用される場合がありますが、これらはこの仕様の範囲外です。
The authors would like to thank Ryuji Wakikawa, Bruno Mongazon-Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay Devarapalli, and Joel Hortelius for their review and comments of this document and all colleagues who have supported the advancement of this effort.
著者は、この文書のレビューとコメントについて、この努力の進歩を支持してくれたすべての同僚のレビューとコメントについて、ワキカワ、ブルーノ・モンガゾン・カザベット、ドマゴジ・プレムク、アルノー・エバラード、パトリック・エバラード、ヴィジェイ・デヴァラパリ、ジョエル・ホルテリウスに感謝したいと思います。
Also, we would like to thank Jari Arkko, Ben Campbell, Pasi Eronen, Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel, and Robert Sparks for their reviews of this document as part of the IESG review process.
また、IESGレビュープロセスの一部としてこの文書のレビューについて、Jari Arkko、Ben Campbell、Pasi Eronen、Ralph Droms、Alexey Melnikov、Tim Polk、Adrian Farrel、Robert Sparksに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPV6）のモバイルノード識別子オプション」、RFC 4283、2005年11月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R。およびS. Gundavelli、「Proxy Mobile IPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648] Wakikawa、R.、Devarapalli、V.、Tsirtsis、G.、Ernst、T。、およびK. Nagami、「複数のケアアドレス登録」、RFC 5648、2009年10月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555] Soliman、H。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543] Glass、S。およびM. Chandra、「モバイルIPv4の登録取り消し」、RFC 3543、2003年8月。
Authors' Addresses
著者のアドレス
Ahmad Muhanna Ericsson, Inc. 2201 Lakeside Blvd. Richardson, TX 75082 USA
Ahmad Muhanna Ericsson、Inc。2201 Lakeside Blvd.テキサス州リチャードソン75082 USA
EMail: ahmad.muhanna@ericsson.com
Mohamed Khalil Ericsson, Inc. 6300 Legacy Dr. Plano, TX 75024 USA
Mohamed Khalil Ericsson、Inc。6300 Legacy Dr. Plano、TX 75024 USA
EMail: mohamed.khalil@ericsson.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com
Kuntal Chowdhury Cisco 30 International Place Tewksbury, MA 01876 USA
Kuntal Chowdhury Cisco 30 International Place Tewksbury、MA 01876 USA
EMail: kchowdhu@cisco.com
Parviz Yegani Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
Parviz Yegani Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089 USA
EMail: pyegani@juniper.net