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
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などの拡張機能の両方を使用することができます。機構は、複数の1、または指定されたすべてのバインディングキャッシュエントリのいずれかを終了するピアを要求するために取り消し手順を開始モビリティエンティティを可能にします。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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]に適用可能であり、任意の2つのIPモビリティエンティティによって使用することができる撤回シグナリングのための新しいモビリティヘッダ（MH）型16を使用します。一例として、このメカニズムは、モバイルノードバインディング登録の終了のモバイル・アクセス・ゲートウェイ（MAG）を通知するために、モバイルノードにIPモビリティサービスの提供に関与するローカル・モビリティ・アンカー（LMA）を、可能にします。別の例では、モバイル・アクセス・ゲートウェイは、すべてのバルク終了またはローカル・モビリティ・アンカーに登録されている、現在によってサービス提供されるプロキシモバイル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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 [RFC5213]とIPv4サポートプロキシモバイルIPv6 [RFC5844]の仕様のために、モバイルIPv6 [RFC3775]で定義されるように解釈されるべきです。次の用語は、本明細書中で使用されています。
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]の場合には、ホームエージェントは、モバイルノードによって割り当てられたホームIPv4アドレスとIPv4のホームアドレスオプションを含むことができます。モバイルノードは、複数の気付アドレス[RFC5648]を登録した場合、さらに、ホームエージェントは、失効している結合を識別するためのバインディング取消指示メッセージにバインディング識別子（BID）オプション（複数可）を含みます。モバイルノードは、バインディング取消指示メッセージを受信すると、そのHoAをタイプ2ルーティングヘッダに含まれると、モバイルノードは、バインディング取消確認応答（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バインディングの同一性を示すことができます。モバイル・アクセス・ゲートウェイは、バインディング取消指示メッセージを受信すると、モバイル・アクセス・ゲートウェイは、バインディング取消確認メッセージを送信することによって、ローカル・モビリティ・アンカーに応答します。
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モバイルノードバインディング登録の終了のローカル・モビリティ・アンカーに示すためにゼロの寿命とプロキシバインディング更新を送信することにより、登録解除メッセージを送信します。この場合には、モバイル・アクセス・ゲートウェイは、PMIPv6バインディングモバイルノードを識別するためのローカル・モビリティ・アンカーためにMN-HNPオプション、MN-IDオプション、および[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]の場合には、ホーム・エージェントは、各アドレスとホームアドレス対気付バインディング異なる維持します。これらのバインディングはまた、BIDのモビリティオプションを使用して、モバイルノードの登録時にインデックス付けと識別されます。 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つ以上が取り消される必要がある場合は、ホームエージェントは、同じバインディング取消指示メッセージ内のすべての対応する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ルーティングヘッダに含まれている間の任意のBIDオプションを含めずBRIメッセージを送信することによって、移動ノード登録バインディングをすべて取り消すことができます。ホームエージェントは、全ての登録気付アドレスのバインディング単一バインディング取消指示メッセージ内の移動ノードのための取り消しと、図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.
モバイルノードが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へソースMAGから移動します。ターゲットMAGは、添付のモバイルノードの位置を更新するために、ローカルモビリティアンカーに新しい気付アドレスを持つプロキシバインディング更新を送信します。モバイルノードは、ソースMAGへと標的MAGからプロキシバインディング更新を受信するとローカル・モビリティ・アンカー・ポイントに結合するので、ローカル・モビリティ・アンカーは、MNバインディングキャッシュエントリ（BCE）を更新し、MAG標的へプロキシバインディング肯定応答を送信します。結合指定されたモバイルノードのために予約さ該当リソースをクリーンアップするために、ソースMAGに、異なるアクセスタイプ - ローカル・モビリティ・アンカーは、適切な失効トリガ値、例えば、インターMAGハンドオーバとバインディング取消指示メッセージを送信することができます。ソースモバイル・アクセス・ゲートウェイは、モバイルノードのバインディングの終了の成功または失敗を示すために、バインディング取消確認メッセージを送信することにより、バインディング取消指示メッセージを肯定応答します。
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結合またはバインディングが取り消されたピア・モバイル・アクセス・ゲートウェイに指示するために適切な失効トリガ値と相互MAGハンドオーバ以外の状況におけるローカル・モビリティ・アンカーによって使用することができます。
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）と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アドレスは、それぞれ、バインディング更新又は更新メッセージをバインディング。トンネリングプロキシモバイルIPv6とIPv4の上にシグナリングメッセージをモバイル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を使用してバインディング取消メッセージフォーマットを定義するバインディング取消Typeフィールドの値がバインディング取消メッセージは、バインディング取消指示またはバインディング取消確認応答であるかどうかを定義します。バインディング失効Typeフィールドが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.
バインディング取消メッセージデータは、バインディング取消Typeフィールドで指定された値は、この文書で定義されたバインディング取消メッセージフォーマットに従います。この文書では、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、IPのための特異的結合または結合の同一の応答を通知するために、イニシエータによって使用される1のバインディング取消タイプ値を有するバインディング取消メッセージでありますモビリティサービスが取り消されています。セクション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:
BRIメッセージを送信するイニシエータをトリガしたイベントを示す8ビットの符号なし整数。パー-MN失効トリガ値ごとのMN失効トリガがBRIメッセージが同一のモバイルノードのための1つまたは複数のバインディングを取消ししようとするときに使用される128未満です。グローバル取り消しトリガ値が128より大きく、250未満とグローバル（G）ビットがグローバル取り消しのために設定されている場合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
パー-MN失効トリガー値：0未指定1つの行政理由2のInter-MAGハンドオーバ - 同じアクセスタイプ3のInter-MAGハンドオーバ - 異なるアクセスタイプ4のInter-MAGハンドオーバ - 不明5ユーザー・セッション開始（S）終了
6 Access Network Session(s) Termination
7 Possible Out-of-Sync BCE State
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)
のみ結合のIPv4 HoAを（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.
のみ結合のIPv4 HoAとは（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モバイルNode Identifierオプション[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を終了させる場合、このオプションは存在しなければなりません。イニシエータは、BIDモビリティオプションのつ以上を含むことができます。
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.
モバイルノードのホームIPv4アドレス[RFC5555]を含んでいたIPv4ホームアドレスオプション、O。 IPv4のHoAをのみ（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.
モバイルノードのプロキシホームIPv4アドレス[RFC5844]を含んでいたIPv4ホームアドレス要求オプション、O。のみ（V）の結合のIPv4 HoAと（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つのオクテットが必要であり、バインディング取消メッセージのヘッダLENフィールドは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.
バインディング取消確認応答（BRA）メッセージはMHタイプ16、セクション5.1で説明バインディング取消指示メッセージの受信を確認するために使用される2のバインディング取消タイプ値を有するバインディング取消メッセージです。 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ビットの符号なし整数。 Statusフィールドの値が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
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)
のみ結合のIPv4 HoAを（V）
The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in the corresponding Binding Revocation Indication message.
（V）ビットは、対応するバインディング取消指示メッセージに設定されている場合はIPv4 HoAをバインドのみ（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でエンコードされたモビリティオプションが含まれています。 Statusフィールドが成功に設定されている場合には、何のモビリティオプションは必要ありません。モビリティオプション（複数可）は、通常、取り消し手順を失敗したバインディングの情報を通信するために使用されます。
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]。レスポンダは失効手続きを失敗した特定のBIDを指定するには、このオプションを含むかもしれません。
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つのオクテットが必要であり、バインディング取消メッセージのヘッダLENフィールドは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.
バインディング失効メッセージを送信すると、イニシエータは、それが16にMHタイプフィールドの設定を除いて、他のモビリティヘッダを行うようにパケットを構築します。
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].
バインディング取消メッセージは同じ基本セキュリティアソシエーションを使用して保護されなければならない、例えば、IPsecは、そのモバイルノードのモバイルIPv6と登録シグナリングを結合するその拡張を保護するために、2つのピア間で使用されています。 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）ビットを設定しなければなりません。この場合、イニシエータは、グローバル取り消しトリガのリストから有効な値に失効トリガーフィールドを設定しなければなりません。
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.
イニシエータのみ結合モバイルノードのIPv4のHoAの失効を示すバインディング取消指示メッセージを送信している場合は、O、開始剤は、（V）ビットを設定しなければなりません。この場合、イニシエータは、IPv4ホームアドレスオプションまたは取り消されているIPv4のHoAとを識別するために、BRIでの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.
バインディング取消指示が廃棄されるたびに、セクション6.2で説明したように、O、例えば、バインディング取消確認応答が送信されてはいけません。そうでなければ、治療は以下のルールに依存します。
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、応答者は適切なステータスコードを成功バインディング取消確認応答を送信しなければなりません。
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を受信バインディング取消指示のシーケンス番号フィールドの値です。
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.
（P）ビットが受信されたバインディング取消指示で設定されている場合は、O、レスポンダはバインディング取消確認応答に（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.
グローバル（G）ビットが受信バインディング取消指示で設定されている場合は、O、レスポンダはバインディング取消確認応答にグローバル（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.
IPv4のHoAとのみ結合（V）ビットを受信バインディング取消指示で設定されている場合は、O、レスポンダはバインディング取消確認応答に（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結合失効確認応答の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）ビットがセットされ、失効トリガフィールド値ごとの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".
レスポンダバインディング取消指示メッセージの中で識別されるモバイルノード（S）バインディングを識別するために失敗した場合はO、レスポンダは「存在しないバインディング」ステータスコードを使用して、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と同様に処理したバインディング取消確認メッセージを運ぶパケットを受信すると、イニシエータは、他に、メッセージを処理し、次のようにStatusフィールドを調べ。
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.
Statusフィールドバインディング取消指示が正常に処理されたことを示す場合、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.
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タイマが満了する前に、イニシエータが未バインディング取消指示に応答して、バインディング取消確認応答を受信しない場合、セクション11で定義されるように、開始剤は、例えば、LMAは、BRIMaxRetriesNumberに同じBRIメッセージを再送信すべきです。
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に達するまで、イニシエータによる再送は、タイムアウト期間が各再送時に倍増された指数バックオフプロセスを使用しなければなりません。イニシエータは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.
再送の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.
ホームエージェントのみ結合、移動ノードのIPv4ホームアドレスを取り消す必要がある場合、O、ホームエージェントは、IPv4 HoAをバインディングのみ（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
ホームエージェントは、モバイルノードにバインディング取消指示を送信するとき、ホーム・エージェントは、その取消しが進行中であることを示すために、モバイルノードのBCEのフラグを設定し、開始します
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.
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]のように複数の気付アドレスの登録を使用して作成されたモバイルノードのバインディングの一つ以上を取り消す必要がある場合、ホームエージェントはバインディング失効にこれらのバインディングを識別し、関連するすべてのBIDモビリティオプションを含まなければなりません指示メッセージ。ホームエージェントは、モバイルノードのバインディングのすべてを取り消す必要がある場合には、ホームエージェントは、BIDモビリティオプションのいずれかを含めるべきではありません。
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を除去するための理由を示すように設定されなければなりません。失効トリガは、モバイルノードの最新の動きを学ぶためにモバイルアクセスゲートウェイで使用することができます。
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.
モバイルノード識別子（MN-ID）をモバイルノードのBCEsの複数に登録され、ローカル・モビリティ・アンカーは、モバイルノードのバインディングをすべて取り消す必要がない場合はO、バインディング取消指示メッセージを一意に別の識別子を含まなければなりません取り消されているモバイルノードのバインディング（複数可）、例えば、結合のためのモバイルノードの登録ホームネットワークプレフィックス（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]で指定されるようにIPsecはプロキシMIPv6のシグナリングを保護するために使用される場合には、宛先アドレスは、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.
ローカル・モビリティ・アンカーは、ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイピアに登録されているすべてのモバイルノードプロキシBCEsを取り消す必要がある場合、それはグローバル（G）ビットを設定し、毎」に失効トリガフィールドの値を設定する必要があります-Peerポリシー」。この場合、ローカル・モビリティ・アンカーは、このバインディング取消指示メッセージ内の任意のモビリティオプションを含んではいけません。
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".
ローカル・モビリティ・アンカーは、特定分野に属し、ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイピアに登録されているすべてのモバイルノードプロキシBCEsを取り消す必要がある場合、ローカル・モビリティ・アンカーは、グローバル（G）ビットを設定し、値を設定する必要があります失効トリガフィールドの「取り消しモビリティノードのローカルポリシー」へ。この場合、ローカル・モビリティ・アンカーは、1.のサブタイプ値を用いて、すべての影響を受けるモバイルノードBCEs間で共有されるバインディング取消指示、例えば、モバイルノード識別子オプション、MN-IDオプションでモビリティ・オプションを含まなければなりませんこの場合、MN-IDにNAI値は、コンテンツが「@」キャラクタが影響モバイルノードプロキシBCEsのすべての間で共有される領域を定義した後フォーマットに従わなければなりません。例として：@ example.comは、そのMN-ID値がレルムとして「example.com」が含まれている全ての移動ノードを識別する、例えば、「1234abdelta@example.com」、「axxxyzd@example.com」、および「abcdefg.xyz123 @ 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.
ローカル・モビリティ・アンカーは、特定分野に属し、ローカル・モビリティ・アンカーとモバイル・アクセス・ゲートウェイに登録されているモバイルノードプロキシBCEsのサブグループを取り消す必要がある場合、ローカル・モビリティ・アンカーは、グローバル（G）ビットセットを設定しなければなりません失効トリガフィールドに「取り消しモビリティノードのローカルポリシー」の値。この場合、ローカル・モビリティ・アンカーは、モバイルノード識別子オプション（MN-ID）に追加のモビリティオプションを含まなければなりませんオプション、すなわち1のサブタイプ値を用いて、影響を受けるモバイルノードBCEsは、MN-を有するものです例えば、上記指定された領域でIDとは、代替気付アドレスモビリティオプションに含まれる1つとして同じプロキシ気付アドレスが割り当てられています。
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オプションを含めるべきです。あるいは、移動ノードNAIとの唯一のモバイルノード識別子（MN-ID）オプションを含むかもしれMN-IDオプションで指定された移動ノードNAIのすべてのバインドを削除するために、モバイル・アクセス・ゲートウェイに示すために含まれます。
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の結合寿命を延長するための新しいモバイル・アクセス・ゲートウェイからProxy Binding Updateメッセージを受信した場合未知の状態は、（4）」、ローカル・モビリティ・アンカーは、新しい接続点とモバイルノードのBCEを更新する前に、以前のモバイル・アクセス・ゲートウェイから登録解除メッセージを受信するMaxDelayBeforeNewBCEAssignの期間を待機します。登録解除メッセージが受信されない場合は、ローカル・モビリティ・アンカーは、新しいBCEのための要求として受信されたProxy Binding Updateメッセージを考慮し、正常に処理されている場合、ローカル・モビリティ・アンカーは、新しい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".
この文書では、この場合のローカル・モビリティ・アンカーの動作を更新します。ローカル・モビリティ・アンカーは、この文書で説明したようにバインディング取り消し機構をサポートしている場合、それは積極的に代わりに前のモバイルアクセスゲートウェイからの登録解除を待っているの前のモバイルアクセスゲートウェイへの結合取消指示メッセージを送信する必要があります。バインディング取消指示メッセージでは、失効トリガーは、「 - 未知のInter-MAGハンドオーバ」に設定する必要があります。
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:
失効謝辞をバインド、応答を待っている間に、次のようにローカル・モビリティ・アンカーは、として扱う必要があることも可能な条件がある - ローカル・モビリティ・アンカーは、「未知のInter-MAGハンドオーバ」に設定失効Triggerフィールドとバインディング取消指示メッセージを送信した場合以下に指定：
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、ローカル・モビリティ・アンカーは、モバイルノードのBCEを更新しなければならない[RFC5213 ]。
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].
「失効が失敗しました - MNが装着されている」ローカル・モビリティ・アンカーはStatus分野セットと結合失効確認メッセージを受信した場合、Oそれは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
セクション6.3で説明したようにローカル・モビリティ・アンカーは、バインディング取消肯定応答メッセージまたはバインディング取消指示メッセージの再送信の全てを使い果たした後、以前のモバイル・アクセス・ゲートウェイから更新をバインディング登録解除プロキシを受信しなかった場合はO、ローカル・モビリティ・アンカーはSHOULDそれは[RFC5213]で説明したように、新たなBCEを作成することにより、有効期限が切れMaxDelayBeforeNewBCEAssignタイマーの前に登録解除を受信しなかったかのように、モバイルノードのBCEを更新します。なお、ローカルモビリティ
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.
モバイルノードは、実際には別のインターフェイスで新しい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のプロキシホームアドレスで登録されている場合、ローカル・モビリティ・アンカーは、モバイルを取り消すことができますモバイルノードのBCEの一環として、現在のPCOAにHNPの結合モバイルノードを維持しながら、現在のモバイルノードプロキシのCoAに結合するノードのIPv4 HoAをプロキシ。ローカル・モビリティ・アンカーは、モバイルノードの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）ビットは、結合のみのIPv4ホームアドレスが失効されていることを示すために、BRIに設定しなければなりません。
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オプションに加えて、解放されているモバイルノードの登録プロキシホーム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.
（P）ビットが設定されている場合、O、ローカル・モビリティ・アンカーは、すべての影響を受けるバインディングがプロキシバインディングフラグが設定されていることを検証しなければなりません。
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
グローバル（G）ビットがセットされ、失効トリガフィールドの値が「ごとのピアポリシー」である場合、O、LMAは、プロキシ（P）ビットが設定され、MN-IDオプションは、モバイル・アクセス・ゲートウェイと存在していることを確認しなければなりませんアイデンティティが含まれています。また、ローカル・モビリティ・アンカーは、MN-IDオプションの値ごとのように識別モバイルアクセスゲートウェイがローカルの場合は、セクション13を参照してください、「ピアごとのポリシー」失効トリガ値を持つグローバル取り消しの使用を許可されていることを確かめなければなりませんモビリティアンカーは、グローバルを処理します
Binding Revocation Indication message successfully, it MUST accept the Binding Revocation Indication message using the status code "success".
首尾取消指示メッセージをバインド、それはステータスコード「成功」を使用してバインディング取消指示メッセージを受け入れなければなりません。
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".
モバイル・アクセス・ゲートウェイは、ピアごとのグローバル取り消し機能または受信バインディング取消指示メッセージ有するグローバル（G）を使用することが許可されていない場合、Oビットセットと失効トリガフィールドは、「ペイ・パー・ピアポリシー」に設定されているが、 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".
グローバル（G）ビットがセットされ、失効トリガ値は、「ペイ・パー・ピアポリシー」、およびのみモバイルノード識別子である場合、O（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、ローカル・モビリティ・アンカーは、メッセージを受け入れなければならないし、それは、「部分的ステータス]フィールドを設定してもよい（MAY）成功」と失効手続きを失敗したモバイルノード識別子（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:
グローバル（G）ビットが設定されていない場合、O、ローカル・モビリティ・アンカーは、以下のように結合影響モバイルノードを識別するために含まれるモビリティ・オプションを使用します。
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. IPv4のHoAが結合した場合のみ（V）ビットがセットされ、（MN-ID）オプションとIPv4ホームアドレス要求オプションが含まれているモバイルノード識別子は、ローカル・モビリティ・アンカーはメッセージを受け入れ、IPv4だけのHoAアドレスを削除する必要がありますモバイルノードの現在のプロキシ気付アドレスに結合します。
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".
グローバル（G）ビットがセットされ、失効トリガフィールドの値が「ごとのピアポリシー」である場合、O、モバイル・アクセス・ゲートウェイは、プロキシ（P）ビットが設定されるとNOモビリティオプションがメッセージに含まれていないことを確認しなければなりません。モバイルアクセスゲートウェイが正常にグローバルバインディング取消指示メッセージを処理した場合は、ステータスコード「成功」を使用してバインディング取消指示メッセージを受け入れなければなりません。
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
Oグローバル（G）ビットがセットされ、失効トリガフィールドの値は、モバイル・アクセス・ゲートウェイは、プロキシ（P）ビットが設定されていることを検証して有する少なくともMN-IDオプションをしなければならない、「取消しモビリティノードのローカルポリシー」である場合1のサブタイプ値がに含まれています
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".
失効指示を結合し、説明したように、フォーマットされることセクション8.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）ビットがセットされ、失効トリガフィールドの値が「取消し移動ノードのローカルポリシー」であり、いかなるモビリティオプションがバインディング取消指示メッセージ、またはモバイルアクセスゲートウェイに含まれていないれている場合は、影響を受けるモバイルを識別することができませんノードバインディング含まれるモビリティ・オプションに基づいて、モバイル・アクセス・ゲートウェイは、エラーシナリオとしてこれを扱う必要があります。この場合には、モバイル・アクセス・ゲートウェイは、ステータスコード「失効モバイルノードIdentity必須」を用いてバインディング取消指示メッセージを拒絶しなければなりません。
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".
受信されたバインディング取消指示メッセージに失効トリガフィールドの値は、例えば、インターMAGハンドオーバ間MAGハンドオーバーを示す場合、O - 不明、モバイル・アクセス・ゲートウェイは、モビリティオプション（複数可）を使用して識別するためのバインディング取消指示メッセージに含まれモバイルノードは、バインディング。モバイル・アクセス・ゲートウェイは、ステータス・コード「成功」を使用してBRIメッセージを受け入れる前に、モバイルノードがもはやモバイル・アクセス・ゲートウェイに接続されていることを保証するべきではありません。モバイル・アクセス・ゲートウェイは、移動ノードがまだ直接接続されていることを確認した場合しかし、モバイル・アクセス・ゲートウェイは、ステータスコードを使用して、BRIを拒絶しなければなりません「失効に失敗しました - MNが接続されています」。
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".
（V）ビットがセットされているだけのバインディングのIPv4 HoAとした場合、O、モバイル・アクセス・ゲートウェイは、バインディング更新リスト（BUL）におけるモバイルノードバインディングエントリを識別するためのMN-IDオプションを使用します。モバイル・アクセス・ゲートウェイは、IPv4アドレスを受信したバインディング取消指示でのIPv4ホームアドレス要求オプションに含まれていることを確認しなければならないモバイルノードに割り当てられたIPv4 HoAをプロキシと同じです。モバイルアクセスゲートウェイが正常にモバイルノードのIPv4 HoAを、受信したIPv4ホームアドレスを検証した後、それだけで、モバイルノードのIPv4プロキシのHoAは、移動ノードの現在のプロキシのCoAへの結合を解放する指標として、これを考慮する必要があります。したがって、モバイルノードのIPv6プロキシのHoA又はHNPがBULエントリに結合モバイルノードの一部として現在のモバイルノードプロキシのCoAとの結合を維持し続け、MN PCOAに結合するMNのIPv4プロキシのHoAに関連付けられたすべてのリソースを解放する必要があります。モバイルアクセスゲートウェイが正常に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、モバイル・アクセス・ゲートウェイは、バインディング取消指示メッセージを受け入れなければなりません。この場合には、モバイル・アクセス・ゲートウェイは、ステータスフィールドに「部分的な成功」を設定し、モバイルノード識別子（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].
受信バインディング取消指示で失効トリガフィールドの値は、モバイルアクセスゲートウェイがあれば、現在の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オプションバインディング取消指示に含まれるとモバイルアクセスゲートウェイの識別情報を含んでいなければなりません。また、モバイルアクセスゲートウェイは、代替気付アドレスオプションを含むかもしれません。含まれている場合は、代替気付アドレスオプションは、プロキシ気付アドレス、このバインディング取消指示メッセージによって影響を受けているバインディングを含まなければなりません。
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に到達するまで、モバイル・アクセス・ゲートウェイは、ローカル・モビリティ・アンカーに結合する取消指示を再送すべきです。モバイル・アクセス・ゲートウェイは、直ちにバインディング取消指示を送信した後とLMAからバインディング取消確認メッセージを受信する前に、モバイルノードのIPトンネルを削除してもよいです。
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と同様に処理し、Statusフィールドは、モバイル・アクセス・ゲートウェイがに許可されていない、「グローバル取り消しが許可されていない」を示したバインディング取消確認応答を運ぶパケットを受信した場合ピアごとのグローバル取り消しに参加しています。モバイル・アクセス・ゲートウェイは、グローバル（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アドレスが、そのホームアドレスであることとその結合更新リストは、そのホーム・アドレスのエントリが含まれていることを確認しなければなりません。テストのいずれかが失敗した場合、モバイルノードは静かに受信されたバインディング取消指示メッセージを破棄すべきです。
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".
更新リストをバインディング移動ノードが受信したバインディング取消指示パケットのタイプ2ルーティングヘッダ内のIPアドレスのエントリが含まれている場合は、O、モバイルノードは、「成功」のステータスコードを使用して、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".
IPv4のHoAをのみ（V）ビットを受信BRIメッセージに設定されている結合場合、O、モバイルノードは、IPv4ホームアドレスオプションに含まれて受信されたバインディング取消指示でのIPv4ホームアドレスオプションとIPv4アドレスがあることを確認しなければなりませんモバイルノードに割り当てられたIPv4 HoAをその同じ。この検証に成功した場合、モバイルノードは、その現在の気付アドレスに結合するモバイルノードのIPv4のHoAをリリースする指標として、このバインディング取消指示を考慮する必要があります。したがって、モバイルノードは、BULエントリに結合モバイルノードの一部として現在のCoAに結合するそのIPv6のHoAとを維持し、MNのIPv4 HoAをバインディングに関連付けられているすべてのリソースを解放し続けなければなりません。この場合、移動ノードは、ステータスコード「成功」を使用してバインディング取消指示メッセージを受け入れなければなりません。一方、IPv4のホームアドレスオプションは、受信されたBRIに含まれていなかった場合（V）ビットがセットされていると、MNは、ステータスコード「IPv4のホームアドレスオプション必須」とBRIメッセージを拒絶しなければなりません。 IPv4のHoAとは、IPv4ホームアドレスオプションで受信した場合また、モバイルノードは、「存在しないバインディング」ステータスコードでバインディング取消指示を拒否すべきであるモバイルノードに割り当てられたものではありません。
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つまたは複数のBIDオプションと共にバインディング取消指示を受信し、そのホームアドレスをタイプ2ルーティングヘッダに含まれている場合、モバイルノードは、これにBIDオプションで識別された気付アドレスのバインディングの全てを、考慮しなければなりませんホームアドレスが取り消されています。 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".
モバイルノードは、複数の気付アドレスのバインディングそのホームエージェントとを有し、バインディング取消指示を受け取った場合、任意のBIDオプションが含まれ、そのホームアドレスをタイプ2ルーティングヘッダに含まれていたことなく、O、モバイルノードは、その登録の全てを考慮しなければなりません気付アドレスバインディング取り消されているとして、このホームアドレスと。モバイルノードが正常に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
モバイルノードが受け入れるまたはバインディング取消指示メッセージを拒否した場合、モバイルノードは、ホームエージェントへの結合失効確認メッセージを送信するために、セクション6.1および6.1.2に従わなければなりません。 MNは、バインディングを送信しないよう注意してくださいいつでも
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.
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.
取り消しの移動エンティティは、BRIメッセージを再送信する前に、この変数は、秒単位の初期遅延タイムアウトを指定します。デフォルトは1秒未満、0.5秒に設定することはありません。
Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)
最大BRAの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.
取り消しの移動エンティティは、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
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
毎MN失効トリガ値：0不特定1つの管理理由2インターMAGハンドオーバ - 同じアクセスタイプ3間MAGハンドオーバ - 異なるアクセスタイプ4インターMAGハンドオーバ - 不明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
Future values of the Status field can be allocated using Standards Action or IESG Approval [RFC5226].
Statusフィールドの将来の値は、標準アクションまたは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）エントリに関連付けられたトラフィックセレクタを再利用するためにSPDエントリのトラフィックセレクタを拡張失効メッセージMHタイプ16のバインド含むように拡張されなければなりません（代わりに、新しいものを作成する）バインディング更新を保護し、確認応答を結合SAは取り消しエンティティがメッセージをシグナリングバインディング取消を送信する必要がある場合、これらのSAが稼働中であることを保証します。
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は地元の移動性アンカーとモバイルアクセスゲートウェイ間のシグナリング固定するために使用されるときには、いくつかの移動性実体、例えばので、移動性アンカーとモバイルアクセスゲートウェイのローカル、バインディング失効適応症を送受信することが許可されていると異なるケースのために失効謝辞をバインド認可の当事者によって構築されていなかったのBinding Revocationメッセージを処理することから、それらのいずれかを防ぐことができます。
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.
作者は彼らのレビューと、このドキュメントのコメントとこの努力の進歩を支えてきたすべての同僚のために隆次Wakikawa、ブルーノMongazon-Cazavet、Domagoj Premec、アルノーEbalard、パトリックStupar、ビジェイDevarapalli、とジョエルHorteliusに感謝したいと思います。
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レビュープロセスの一環として、このドキュメントの彼らのレビューのためにヤリArkko、ベン・キャンベル、パシEronen、ラルフDroms、アレクセイ・メルニコフ、ティムポーク、エードリアンファレル、そしてロバート・スパークスに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ジョンソン、D.、パーキンス、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]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイル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.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R.およびS. Gundavelli、 "プロキシモバイル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.、エルンスト、T.、およびK.永見、 "複数の気付アドレスの登録"、RFC 5648、2009年10月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマン、H.、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543]ガラス、S.とM.チャンドラ、 "モバイルIPv4における登録失効"、RFC 3543、2003年8月。
Authors' Addresses
著者のアドレス
Ahmad Muhanna Ericsson, Inc. 2201 Lakeside Blvd. Richardson, TX 75082 USA
アフマドMuhannaエリクソン社2201レイクサイドブルバードリチャードソン、TX 75082 USA
EMail: ahmad.muhanna@ericsson.com
メールアドレス：ahmad.muhanna@ericsson.com
Mohamed Khalil Ericsson, Inc. 6300 Legacy Dr. Plano, TX 75024 USA
モハメド・カリル・エリクソン社6300レガシー博士はテキサス州プラノ75024 USA
EMail: mohamed.khalil@ericsson.com
メールアドレス：mohamed.khalil@ericsson.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
スリGundavelliシスコ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: sgundave@cisco.com
メールアドレス：sgundave@cisco.com
Kuntal Chowdhury Cisco 30 International Place Tewksbury, MA 01876 USA
Kuntalチョードリーシスコ30・インターナショナル・プレイステュークスベリー、MA 01876 USA
EMail: kchowdhu@cisco.com
メールアドレス：kchowdhu@cisco.com
Parviz Yegani Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
Parvizジュニパーネットワークスの1194北マチルダアベニュー、サニーベール、CA 94089 USAを食べます
EMail: pyegani@juniper.net
メールアドレス：pyegani@juniper.net