Network Working Group S. Glass
Request for Comments: 3543 Sun Microsystems
Category: Standards Track M. Chandra
Cisco Systems
August 2003
Registration Revocation in Mobile IPv4
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding.
この文書では、モバイルノードにモバイルIPサービスを提供する際に関与するモビリティエージェントは、この登録の終了の同じモバイルノードにモバイルIPサービスを提供する他のモビリティエージェントに通知することができるモバイルIPv4登録失効メカニズムを定義します。機構は、そのも同様結合の終了の同一位置の移動ノードに通知するために、ホームエージェントによって使用可能です。また、機構が認められるには、この通知を提供します。既にモバイルIPv4プロトコルによって定義されたシグナリングメカニズムは、その結合の取消しのモバイルノードに通知する手段として活用されます。
Table of Contents
目次
1. Introduction and Applicability . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registration Revocation Extensions and Messages. . . . . . . . 4
3.1. Advertising Registration Revocation Support. . . . . . . 5
3.2. Revocation Support Extension . . . . . . . . . . . . . . 6
3.3. Registration Revocation Message. . . . . . . . . . . . . 8
3.4. Registration Revocation Acknowledgment Message . . . . . 11
3.5. Replay Protection. . . . . . . . . . . . . . . . . . . . 14
4. Registration Revocation Overview . . . . . . . . . . . . . . . 15
4.1. Mobile Node Notification . . . . . . . . . . . . . . . . 15
4.2. Registration Revocation Mechanism - Agent Notification . 17
4.2.1. Negotiating Revocation Support . . . . . . . . . 17
4.2.2. Home Domain Revoking a Registration. . . . . . . 19
4.2.2.1. Home Agent Responsibilities. . . . . . 19
4.2.2.2. Foreign Agent Responsibilities . . . . 20
4.2.2.3. 'Direct' Co-located Mobile Node
Responsibilities . . . . . . . . . . . 20
4.2.3. Foreign Domain Revoking a Registration . . . . . 21
4.2.3.1. Foreign Agent Responsibilities . . . . 21
4.2.3.2. Home Agent Responsibilities. . . . . . 22
4.2.4. Mobile Node Deregistering a Registration . . . . 23
4.3. Mobile IP Registration Bits in the Revocation Process. . 23
4.3.1. The 'R' Bit in Use . . . . . . . . . . . . . . . 23
4.3.2. The 'D' Bit in Use (co-located mobile nodes) . . 23
5. Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
6.1. Agent Advertisements . . . . . . . . . . . . . . . . . . 24
6.2. Revocation Messages. . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27
7.1. New Message Types. . . . . . . . . . . . . . . . . . . . 27
7.2. New Extension Values . . . . . . . . . . . . . . . . . . 27
7.3. New Error Codes. . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative (Numerical References) . . . . . . . . . . . . 27
8.2. Informational (Alphabetical References). . . . . . . . . 28
Appendix A An Example of the New Messages in Use. . . . . . . . . 29
A.1. The Registration Phase . . . . . . . . . . . . . 29
A.2. The Revocation Phase . . . . . . . . . . . . . . 29
Appendix B Disparate Address, and Receiver Considerations . . . . 30
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 33
Mobile IP [1] defines registration of a mobile node's location to provide connectivity between the mobile node and its home domain, facilitating communication between mobile nodes and any correspondent node. At any time, either the home or foreign agent may wish to cease servicing a mobile node, or for administrative reasons may no longer be required to service a mobile node.
モバイルIP [1]モバイルノードと任意の通信相手ノードとの間の通信を容易にする、モバイルノードとそのホームドメインとの間の接続を提供するモバイル・ノードの位置の登録を規定します。任意の時点で、家庭や外国人のエージェントのどちらかは、モバイルノードにサービスを提供し、または管理上の理由で、もはやモバイルノードにサービスを提供するために必要としないことも中止することを望むかもしれません。
This document defines a general registration revocation mechanism for Mobile IPv4, whereby a mobility agent can notify another mobility agent (or a 'direct' co-located mobile node) of the termination of mobility bindings. A mobility agent that receives a revocation notification no longer has to provide services to the mobile node whose registration has been revoked. A signaling mechanism already defined by the Mobile IPv4 protocol [1] is leveraged as a way to inform a mobile node of the revocation of its binding.
この文書では、モビリティエージェントは、モビリティバインディングの終了の他のモビリティエージェント（または「直接」コロケートモバイルノード）を通知することができるモバイルIPv4のための一般的な登録取消機構を定義します。もはや失効通知を受けたモビリティエージェントは、その登録失効しているモバイルノードにサービスを提供しなければなりません。既にモバイルIPv4プロトコルによって定義されたシグナリング機構[1]はその結合の取消しのモバイルノードに通知する手段として活用されます。
The registration revocation protocol provides the following advantages:
登録取り消しプロトコルは、以下の利点を提供します。
1. Timely release of Mobile IP resources. Resources being consumed to provide Mobile IP services for a mobile node that has stopped receiving Mobile IP services by one agent, can be reclaimed by the other agent in a more timely fashion than if it had to wait for the binding to expire. This also applies to the case in which a mobile node roams away from a foreign agent to another foreign agent. Notification to the previous foreign agent would allow it to reclaim resources.
モバイルIPリソースの1.タイムリーなリリース。リソースを1つのエージェントがモバイルIPサービスを受けて停止したモバイルノードのためのモバイルIPサービスを提供するために消費され、それが期限切れに結合するために待たなければならなかった場合よりも、よりタイムリーに他のエージェントによって再利用することができます。これはまた、モバイルノードが他のフォーリンエージェントに外部エージェントから離れてローミングする場合にも適用されます。前の外国人のエージェントへの通知は、それが資源を再利用することができるようになります。
2. Accurate accounting. This has a favorable impact on resolving accounting issues with respect to the length of mobility bindings in both domains, as the actual end of the registration is relayed.
2.正確な会計処理。これは、登録の実際の端部が中継されるように、両方のドメイン内モビリティバインディングの長さに対する課金の問題を解決する上で有利な影響を有します。
3. Earlier adoption of domain policy changes with regards to services offered/required of a Mobile IP binding. For example, the home domain may now require reverse tunnels [C], yet there are existing bindings that do not use them. Without a revocation mechanism, new services can only be put in place or removed as bindings are re-registered.
モバイルIPバインディングの必要/提供するサービスに関して持つドメインポリシーの変更3.早期適用。例えば、ホームドメインは現在、逆方向トンネル[C]を必要とするかもしれない、まだ利用していない既存のバインディングがあります。取り消し機構がなければ、新しいサービスが唯一の場所に置くか、またはバインディングが再登録されているように除去することができます。
4. Timely notification to a mobile node that it is no longer receiving mobility services, thereby significantly shortening any 'black-hole' periods to facilitate a more robust recovery.
それはもはや著しくより堅牢な回復を容易にするために、任意の「ブラックホール」の期間を短くする、モビリティサービスを受けているモバイルノードに4.適時通知。
The revocation protocol is an active, yet unobtrusive mechanism allowing more timely communication between the three Mobile IP entities in the various administrative domains. Since many mobile nodes may not understand the concept of revocation, care has been taken to ensure backwards compatibility with [1].
失効プロトコルは、様々な管理ドメインにおける3つのモバイルIPエンティティ間のよりタイムリーな通信を可能にするアクティブ、まだ控えめな機構です。多くのモバイルノードが取消の概念を理解していない可能性があるので、注意がとの下位互換性を確保するために取られている[1]。
The registration revocation protocol does not replace the methods described in [1] for Mobile IP deregistration, as the purpose of these mechanisms is fundamentally different. Deregistration messages are used by a mobile node to inform its home agent that it has e.g., roamed back to its home subnet, whereas revocation messages are used between mobility agents to signal the termination of mobility bindings. More specifically, the revocation message defined here is NOT for use by 'direct' co-located mobile nodes that are terminating their registration as deregistration messages are already sufficient for this purpose. A 'direct' co-located mobile node, however, may wish to process revocation messages as it is a useful mechanism to trigger the re-negotiation of required services from the home domain.
これらの機構の目的は根本的に異なるように登録失効プロトコルは、モバイルIP登録解除のために[1]に記載された方法に代わるものではありません。登録解除メッセージは、失効メッセージは、モビリティバインディングの終了を通知するモビリティエージェントの間で使用されている一方、それは、例えば、バックそのホームサブネットにローミングしている自身のホームエージェントに通知するためにモバイルノードによって使用されています。具体的には、ここで定義された失効メッセージが登録抹消メッセージは、すでにこの目的のために十分であるとして、その登録を終了している「直接」共同設置モバイルノードが使用するためではありません。 「直接」共同設置、移動ノードは、しかし、ホームドメインから必要なサービスの再交渉をトリガーするのに便利なメカニズムであるとして、失効メッセージを処理することを望むかもしれません。
It is assumed that the reader is familiar with the terminology used in [1]. In addition, the following terms are defined:
読者が[1]で使用される専門用語に精通しているものとします。また、以下の用語が定義されています。
'Direct' Co-located Mobile Node
「直接」共同設置のモバイルノード
A mobile node registering directly with its home agent, with the 'D' bit set in its registration request, and NOT registering through a foreign agent.
「D」とのホームエージェントに直接登録するモバイルノードは、その登録要求に設定され、外国人のエージェントを通して登録しないビット。
Mobile IP Resources
モバイルIPリソース
Various functional elements allocated by a mobility agent to support a Mobile IP binding, e.g., memory.
モバイルIPバインディング、例えば、メモリをサポートするためのモビリティエージェントによって割り当てられた様々な機能要素。
Mobile IP Services
モバイルIPサービス
Various responsibilities of a mobility agent in supporting a mobile node as defined in [1], e.g., encapsulation of packets addressed to a mobile node by a home agent, decapsulation of these packets by a foreign agent for delivery to a mobile node, etc.
[1]は、例えば、パケットのカプセル化は、モバイルノードに配信するために外部エージェントによってこれらのパケットのデカプセル化などのホーム・エージェントによってモバイルノード宛てで定義されるようにモバイルノードをサポートするモビリティエージェントの様々な責務
Mobility Agent
モビリティエージェント
The home agent or foreign agent as specified in [1].
で指定されたホームエージェントまたは外部エージェント[1]。
Revocation
撤回
Premature termination of a mobility binding.
モビリティ結合の早期終了。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますBCP 14、RFC 2119に記載されているように、[3]に解釈されます。
Registration revocation in Mobile IPv4 is accomplished via the following:
モバイルIPv4での登録の取り消しは、以下を介して達成されます。
- Advertising Registration Revocation Support (Section 3.1.):
- 広告登録失効サポート（3.1節）：
o A flag in the Agent Advertisement extension has been reserved for agents to advertise their support of revocation messages.
Oエージェント広告拡張のフラグが失効メッセージの支援を宣伝するための薬剤のために予約されています。
- Revocation Support Extension (Section 3.2.):
- 失効サポート拡張（3.2節）：
o This extension is appended to a registration request or registration reply by a mobility agent to indicate its support of registration revocation.
Oこの拡張は、登録取り消しのサポートを示すために、モビリティエージェントによって登録要求又は登録応答に付加されます。
o This extension is appended to a registration request by a 'direct' co-located mobile node to indicate its understanding of revocation messages.
Oこの拡張は、失効メッセージのその理解を示すために、「直接」コロケートモバイルノードによって登録要求に付加されています。
- Registration Revocation Message (Section 3.3.):
- 登録失効メッセージ（3.3節）：
o A message sent by a mobility agent to inform another mobility agent, or a 'direct' co-located mobile node, that it has revoked the binding of a mobile node.
Oモビリティエージェントによって送信されたメッセージは、それがモバイルノードの結合取り消されたことを、他のモビリティエージェント、または「直接」共同位置する移動ノードに通知します。
- Registration Revocation Acknowledgment Message (Section 3.4.):
- 登録失効確認応答メッセージ（3.4節）：
o A message sent by mobility agents or 'direct' co-located mobile nodes to indicate the receipt of a revocation message.
取消メッセージの受信を示すために、モビリティエージェントまたは「直接」コロケートモバイルノードによって送信されたメッセージO。
Security considerations related to the above messages and extensions are covered in Section 6.
上記のメッセージや拡張に関連するセキュリティ上の考慮事項は、セクション6で覆われています。
Mobility agents can advertise their support of registration revocation with a modification to the Mobility Agent Advertisement extension described in [1]. An 'X' bit is introduced to indicate an agent's support for Registration Revocation.
モビリティエージェントは、[1]で説明したモビリティエージェント広告の拡張子に変更して、登録失効の支援を宣伝することができます。 「X」ビットは、登録失効のためのエージェントのサポートを示すために導入されます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Lifetime |R|B|H|F|M|G|r|T|U|X| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... |
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ|シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |登録の有効期間| R | B | H | F | M | G | R | T | U | X |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ゼロ個以上の気付アドレス| | ... |
X The mobility agent supports Registration Revocation
Xモビリティエージェントは、登録失効をサポートしています
A foreign agent that sets the 'X' bit in an agent advertisement extension MUST support registration revocation messages on that link, specifically the Revocation Support Extension (section 3.2.), Revocation Messages (section 3.3.), and Revocation Acknowledgment
エージェント広告拡張に「X」ビットをセットし、外部エージェントは、そのリンク上の登録取り消しメッセージ、具体的に失効サポート拡張（セクション3.2）、失効メッセージ（セクション3.3）、および失効確認応答をサポートしなければなりません
(section 3.4.). It is not required that all agents advertising on the same link support registration revocation, nor is it required that an agent advertise this support on all of its links.
（セクション3.4）。すべてのエージェントが同じリンク支持登録取消に広告している必要はない、またそれは、エージェントがそのリンクのすべてにこのサポートを宣伝することが必要とされます。
Note that using this information, a mobile node can select a foreign agent that supports Registration Revocation. Should a mobile node not understand this bit, it simply ignores it as per [1].
この情報を使用して、モバイルノードが登録失効をサポートしています外国人のエージェントを選択できることに注意してください。移動ノードがこのビットを理解するべきではない、それは単に通り、それを無視する[1]。
As a bit in the agent advertisement, use of the 'X' bit has no impact on other messages, such as e.g., Challenge-Response [2].
エージェント広告のビットとして、「X」ビットの使用は、例えば、チャレンジレスポンスなどの他のメッセージ、[2]に影響を及ぼしません。
The Mobile IP revocation support extension indicates support of registration revocation, and so MUST be attached to a registration request or registration reply by any entity that wants to receive revocation messages. Normally, this is either a foreign agent, or a home agent. However a 'direct' co-located mobile node MAY also include a revocation support extension in its registration request. A mobile node which is not co-located MUST NOT include a Revocation Support Extension in its registration.
モバイルIP失効サポート拡張は、登録取り消しのサポートを示しており、その失効メッセージを受信したい任意のエンティティによって登録要求または登録応答に接続する必要があります。通常、これは外国人のエージェント、またはホームエージェントのいずれかです。しかし「ダイレクト」共同位置する移動ノードは、その登録要求で失効サポート拡張を含むかもしれません。その登録に失効サポート拡張を含んではいけません同じ場所に配置されていないモバイルノード。
A foreign agent advertising the 'X' bit on the link on which the registration request was received, and that has a security relationship with the home agent identified in the same registration request, MUST attach a revocation support extension to the forwarded registration request. A home agent that receives a registration request that does not contain a revocation extension SHOULD NOT include a revocation support extension in the associated registration reply.
外国人のエージェント登録要求を受信したリンク上の「X」ビットを宣伝し、それは同じ登録要求に識別されるホーム・エージェントとの安全保障関係を持っているが、転送された登録要求に失効サポート拡張を添付しなければなりません。失効拡張が含まれていない登録要求を受信したホームエージェントは、関連する登録回答で失効サポート拡張を含めるべきではありません。
The format of the revocation support extension is based on the Type-Length-Value Extension Format given in [1] and is defined as follows:
失効サポート拡張のフォーマットは、で与えられたタイプレングス値の拡張形式に基づいている[1]以下のように定義されます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - |タイプ|長さ| I |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - |タイムスタンプ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -
Type 137
タイプ137
Length Length (in bytes, currently 6). Does NOT include Type and Length fields (in accordance with section 1.9. of [1]). This allows for a longer extension length should more bits be required in the future.
長さの長さ（バイト単位で、現在6）。 （セクション1.9に従って、[1]の）タイプと長さフィールドを含んでいません。これは、長い延長長さを可能にし、より多くのビットは、将来的に必要とされるべきです。
Timestamp Current 4-byte timestamp of the mobility agent or 'direct' co-located mobile node. This is used to identify the ordering of registrations as they are forwarded, how they relate to the sending of any revocation messages, and to identify the approximate offset between the clocks of the mobility agents providing support for this binding, or between a 'direct' co-located mobile node and its home agent.
モビリティエージェントまたは「直接」共同設置、移動ノードのタイムスタンプ現在の4バイトのタイムスタンプ。これは、彼らがどの失効メッセージの送信、およびこのバインディングのサポートを提供するモビリティエージェントのクロック間、または「直接」の間のオフセット近似値を識別するためにどのように関連するか、それらが転送されるよう、登録の順序を識別するために使用されますモバイルノードとそのホームエージェント共同設置。
'I' Bit This bit is set to '1' by a mobility agent to indicate it supports the use of the 'I' bit in revocation messages (section 3.3.)
「I」ビットこのビットは、それが取消しメッセージの「I」ビットの使用サポートを示すために、モビリティエージェントが「1」に設定されている（セクション3.3）。
When sent by a foreign agent in a registration request:
登録要求に外国人のエージェントによって送信された場合：
If set to 1, the FA is willing to have the home agent use the 'I' bit in the revocation process to determine whether the mobile node should be informed of the revocation or not.
1に設定した場合、FAは、ホームエージェントは、モバイルノードが取消しの通知をすべきかどうかを判断するために失効過程で「I」ビットを使用していても構わないと思っています。
If set to 0, indicates to the home agent that the foreign agent will follow its own policy with regards to informing the mobile node in the event of a revocation.
0に設定すると、外国人のエージェントが失効した場合に、モバイルノードに通知に関して独自のポリシーに従いますホームエージェントに示します。
When sent by a home agent in response to a revocation extension in which the 'I' bit was set to '1':
「I」ビットが「1」に設定した失効拡張に応じて、ホームエージェントによって送信された場合：
If set to 1, the home agent agrees to use the 'I' bit in the revocation process to indicate to the foreign agent whether or not the mobile node should be informed.
1に設定した場合、ホームエージェントは、モバイルノードに通知する必要があるかどうかを外部エージェントに示すために、取り消しプロセスに「I」ビットを使用することに同意します。
If set to 0, the home agent will not use the 'I' bit in the revocation process, thereby yielding to the foreign agent's default behavior with regard to informing the mobile node.
0に設定すると、ホームエージェントは、これにより、モバイルノードに通知に関して、外国人のエージェントのデフォルトの動作にもたらす、失効プロセスの「I」ビットを使用しません。
To preserve the robustness of the protocol, the recommended default behavior for a foreign agent is to inform the mobile node of its revocation as described in Section 4.1.
プロトコルの堅牢性を維持するために、外国人のエージェントのための推奨されるデフォルトの動作は、4.1節で説明したように、その取消しのモバイルノードに通知することです。
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on receiving.
予約済み将来の使用のために予約されています。送信時に0に設定しなければならなくて、受信時に無視しなければなりません。
When appearing in a registration request, or registration reply, the Mobile IP revocation support extension MUST be protected either by a foreign-home authentication extension, a mobile-home authentication extension, or any other equivalent mechanism [1], e.g., via AAA [A], [B], or perhaps IPsec. If the extension appearing in either of these registration messages is NOT protected, the appropriate action as described by [1] (Sections 3.8.2.1. and Sections 3.7.3.1.) MUST be taken.
登録要求、または登録応答に現れるときに、モバイルIP失効サポート拡張は、外国ホーム認証拡張のいずれかによって、モバイル・ホーム認証拡張、または他の同等の機構を保護しなければならない[1]、例えば、AAAを介して[ A]、[B]、またはおそらくのIPsec。 [1]で説明したように、これらの登録メッセージのいずれかに現れる延長は、適切な動作を保護されていない場合（セクション3.8.2.1。およびセクション3.7.3.1。）注意しなければなりません。
Support of the 'I' bit is OPTIONAL. If a mobility agent does not support the specified functionality, it MUST set the 'I' bit to zero. Note that the home agent setting the 'I' bit to '1' in response to a revocation extension from the foreign agent in which the 'I' bit was set to '0' is undefined, and SHOULD NOT be done.
「I」ビットのサポートはオプションです。モビリティエージェントは、指定された機能をサポートしていない場合、それはゼロに「I」ビットを設定しなければなりません。 「I」ビットが「0」に設定された外国人のエージェントからの失効拡張に応じて「1」から「I」ビットを設定するホームエージェントは未定義であり、行われるべきではないことに注意してください。
'I' bit support has been negotiated when both agents have set the 'I' bit to '1' in their revocation support extensions.
「I」ビットのサポートは、両方のエージェントが自分の失効サポート拡張で「1」を「I」ビットを設定しているときに交渉されています。
It is important to note that this extension is skippable (i.e., if the receiving mobility agent does not understand this extension, it MUST skip it, and continue processing the remainder of the registration request).
この拡張機能は、（受信モビリティエージェントは、この拡張機能を理解していない場合、すなわち、それはそれをスキップし、登録要求の残りの部分の処理を継続しなければならない）スキップ可能であることに注意することが重要です。
A revocation message is sent by a mobility agent to inform another mobility agent, or a 'direct' co-located mobile node, that it is revoking the binding of a mobile node.
取り消しメッセージは、それがモバイルノードのバインディングを取消していることを、別のモビリティエージェント、または「直接」共位置する移動ノードに通知するモビリティエージェントによって送信されます。
IP Fields:
IPフィールド：
Source Address In the case of the home agent issuing the registration revocation, the address registered with the care-of address as that of the home agent (that is the address identified as the home address of this binding).
登録取消し、気付アドレス、ホームエージェントのものとして登録されたアドレスを発行し、ホームエージェントの場合は送信元アドレス（つまり、このバインディングのホームアドレスとして特定のアドレスです）。
In the case of the foreign agent issuing the
registration revocation, the address
registered with the home agent as the care-of
address.
Destination Address In the case of the home agent issuing the registration revocation, the source address of the last approved registration request for this binding, i.e., the destination address of the last registration reply indicating success for this binding.
登録取消し、この結合、すなわち、この結合のための成功を示す最後の登録応答の宛先アドレスの最後の承認登録要求の送信元アドレスを発行し、ホームエージェントの場合宛先アドレス。
In the case of the foreign agent issuing the
registration revocation, the address
registered as that of the home agent by the
mobile node whose registration is being
revoked.
UDP Fields:
UDPフィールド：
Source Port variable
送信元ポート変数
Destination Port 434
宛先ポート434
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダは、以下に示すモバイルIPフィールドが続きます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved |A|I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Domain Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Domain Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Revocation Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|予約| A | I |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ホームアドレス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ホームドメインアドレス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |外国ドメインアドレス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |失効識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |拡張子... + - + - + - + - + - + - + - + - + - + - + - + - + - |オーセン... + - + - + - + - + - + - + - + - + - + - + - + - + -
Type 7
タイプ7
Reserved MUST be sent as 0, ignored when received.
予約は受信時に無視され、0として送らなければなりません。
A Agent bit ('direction' bit).
エージェントビット（「」方向ビット）。
This bit identifies the role of the agent sending the
revocation, that is the 'direction' of the revocation
message. This is useful for detecting reflection attacks, particularly when symmetric keying is being
used.
Set to '0' if the revoking agent is servicing this binding as a foreign agent.
取り消しエージェントが、これは外国人のエージェントとして結合整備されている場合「0」に設定してください。
Set to '1' if the revoking agent is servicing this binding as a home agent.
取り消しエージェントが、これはホームエージェントとして結合整備されている場合、「1」に設定してください。
I Inform bit.
私は少しを通知します。
This bit MUST NOT be set to '1' unless 'I' bit support
was negotiated in the revocation extension messages
passed in the registration process, otherwise the results
can be unpredictable.
When sent by the home agent to a foreign agent:
外国人のエージェントにホームエージェントによって送信された場合：
Set to '0' to request that the mobile node SHOULD NOT be informed of the revocation, or because the use of the 'I' bit was not agreed upon.
モバイルノードが取消しの通知をすべきではないか「I」ビットの使用が合意されていなかったのでことを要求するために「0」に設定してください。
Set to '1' to request that the mobile node be informed of the revocation.
モバイルノードが取消しの通知をすることを要求するために「1」に設定してください。
When sending a revocation message to a 'direct' co-located mobile node, this bit is essentially irrelevant, but SHOULD be set to '1'.
「直接」共同設置移動ノードに取消メッセージを送信するとき、このビットは、本質的に無関係であるが、「1」に設定されるべきです。
When sent by the foreign agent:
外国人のエージェントによって送信された場合：
Set to '0' to indicate that the foreign agent is using foreign domain policy as to whether or not the mobile node should be informed of the revocation, or because 'I' bit support was not agreed upon.
外国人のエージェントは、モバイルノードが取消しの通知をする必要があるか否かの外部ドメインポリシーを使用して、または「私は」ビット・サポートが合意されていなかったためであることを示すために「0」に設定してください。
Set to '1' to ask the home agent if the mobile node should be informed of the revocation.
モバイルノードが取消しの通知をしなければならない場合は、ホームエージェントに依頼する「1」に設定してください。
Reserved MUST be sent as 0, ignored when received.
予約は受信時に無視され、0として送らなければなりません。
Home Address The home IP address of the mobile node whose registration is being revoked.
ホームは、登録取り消しされているモバイルノードのホームIPアドレス。
Foreign Domain Address The relevant IP address in the foreign domain to identify which binding is being revoked. This is one of the following: (i) the foreign agent's IP address, or (ii) the co-located care-of address.
外部ドメインが取り消されているバインディングを識別するために、外部ドメイン内の関連するIPアドレス。 （ⅰ）外国人のエージェントのIPアドレス、または（ⅱ）共存気付アドレス：これは、次のいずれかです。
Home Domain Address The IP address of the home agent to identify which binding is being revoked.
ホーム・ドメインは、失効されているバインディングを識別するために、ホームエージェントのIPアドレス。
Revocation Identifier Protects against replay attacks. The revoking agent MUST insert its current 4-byte timestamp running off the same clock as it is using to fill in the timestamp in its revocation extensions. See section 3.5.
失効識別子は、リプレイ攻撃から保護します。取り消し・エージェントは、その失効の拡張機能で、タイムスタンプを埋めるために使用されるのと同じクロックをオフに実行している現在の4バイトのタイムスタンプを挿入しなければなりません。セクション3.5を参照してください。
A registration revocation message MUST be protected by either a valid authenticator as specified in [1], namely a home-foreign authenticator, if the communication is between home and foreign agents, or a mobile-home authenticator if the communication is being sent from a home agent to a 'direct' co-located mobile node, or another security mechanism at least as secure, and agreed upon by the home and foreign domains, e.g., IPsec. If any agent, or 'direct' co-located mobile node, receives a registration revocation message that does not contain a valid authenticator, and is not adequately protected, the revocation message MUST be ignored, and silently discarded.
登録取消メッセージは、通信がから送信されている場合、通信は、ホームとフォーリンエージェント、またはモバイル・ホーム・オーセンティケータとの間にある場合は、[1]、すなわち家庭外国オーセンティケータで指定されるように、有効な認証者のいずれかによって保護されなければなりませんホーム「直接」共同設置、移動ノード、または他のセキュリティ・メカニズム、少なくともとして、セキュアにエージェント、家庭および外部ドメイン、例えば、IPsecのことで合意しました。いずれの薬剤、または「直接」共同設置、移動ノードは、有効なオーセンティケータが含まれていない登録取消しメッセージを受信し、適切に保護されていない場合は、失効メッセージは無視され、静かに捨てなければなりません。
A revocation message MUST NOT be sent for any registration that has expired, and MAY only be sent prior to the expiration of a mobile node's registration. Note, however, due to the nature of datagram delivery, this does not guarantee these messages will arrive before the natural expiration of any binding.
失効メッセージの有効期限が切れているすべての登録のために送ってはいけません、とだけ前に移動ノードの登録の有効期限に送ってもよいです。データグラムの配信の性質のために、これは、これらのメッセージは、任意の結合の自然の満了前に到着することを保証しません、しかし、注意してください。
An agent MUST NOT send more than one revocation message or registration message per second for the same binding. Note that this updates [1] by including revocation messages in the rate limit specified in [1], i.e., that an agent MUST NOT send more than one registration message per second for the same binding.
エージェントは、同じ結合のために毎秒つ以上の失効メッセージまたは登録メッセージを送ってはいけません。なおで指定されたレート制限に取消しメッセージを含むことにより、このアップデート[1] [1]、即ち、薬剤が同じ結合のために毎秒複数登録メッセージを送ってはならないこと。
An example of the use of revocation messages is given in Appendix A.
失効メッセージの使用例は、付録Aに記載されています
A revocation acknowledgment message is sent by mobility agents or 'direct' co-located mobile nodes to indicate the successful receipt of a revocation message.
取消確認メッセージを無効化メッセージの受信成功を示すためにモビリティエージェントまたは「直接」コロケートモバイルノードによって送信されます。
IP fields:
IPフィールド：
Source Address Copied from the destination address of the received registration revocation message for which this registration revocation acknowledgment message is being generated.
送信元アドレスは、この登録取消し承認メッセージが生成されている受信した登録取消しメッセージの宛先アドレスからコピーされます。
Destination Address Copied from the source address of the received registration revocation message for which this registration revocation acknowledgment message is being generated.
この登録取消し確認メッセージが生成されているため、受信した登録取消しメッセージのソースアドレスからコピー先アドレス。
UDP fields:
UDPフィールド：
Source Port 434 (copied from the destination port of the revocation message).
（失効メッセージの宛先ポートからコピー）送信元ポート434。
Destination Port Copied from the source port of the revocation message.
宛先ポートは、失効メッセージの送信元ポートからコピーされます。
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダは、以下に示すモバイルIPフィールドが続きます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Revocation Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|予約| I |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ホームアドレス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |失効識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |拡張子... + - + - + - + - + - + - + - + - + - + - + - + - + - |オーセン... + - + - + - + - + - + - + - + - + - + - + - + - + -
Type 15
タイプ15
Reserved MUST be sent as 0, ignored when received.
予約は受信時に無視され、0として送らなければなりません。
I Inform bit.
私は少しを通知します。
The 'I' bit MUST NOT be set to '1' in the revocation
acknowledgment messages unless it was set to '1' in the
revocation message. If an agent receives a revocation
acknowledgment message in which the 'I' bit is set to
'1', but for which the revocation message being acknowledged had the 'I' bit set to '0', the 'I' bit in
the revocation acknowledgment message MUST be ignored.
When sent by the home agent:
ホームエージェントによって送信された場合：
Set to '1' by the home agent to request the foreign agent inform the mobile node of the revocation.
失効のモバイルノードに通知する外国人のエージェントを要求するために、ホームエージェントによって「1」に設定してください。
Set to '0' by the home agent to request the foreign agent not inform the mobile node of the revocation.
失効のモバイルノードに通知していない外国人のエージェントを要求するために、ホームエージェントによって「0」に設定してください。
When sent by a foreign agent:
外国人のエージェントによって送信された場合：
Set to '1' to indicate to the home agent that the mobile node was informed.
「1」に設定し、モバイルノードが通知されたホームエージェントに指示します。
Set to '0' to indicate to the home agent that the foreign agent used local policy to determine whether or not the mobile node should be informed. For purposes of protocol robustness, it is highly recommended that such a default be set for the foreign agent to inform the mobile node of the revocation.
外国人のエージェントは、モバイルノードに通知する必要があるかどうかを判断するために、ローカルポリシーを使用したホームエージェントに示すために、「0」に設定してください。プロトコルの堅牢性の目的のために、高度なデフォルトは取消しのモバイルノードに通知するために外国人のエージェントに設定することをお勧めします。
Reserved MUST be sent as 0, ignored when received.
予約は受信時に無視され、0として送らなければなりません。
Home Address The home address copied from the revocation message for which this acknowledgment is being sent.
ホームは、この確認応答が送信されている失効メッセージからコピーされたホームアドレス。
Revocation Identifier Copied from the Revocation Identifier of the revocation message for which this acknowledgment is being sent. See Section 3.5.
失効識別子は、この確認応答が送信されている失効メッセージの失効識別子からコピー。 3.5節を参照してください。
A registration revocation acknowledgment message MUST be sent in response to a valid and authenticated registration revocation message.
登録取消し承認メッセージが有効で、認証登録取消しメッセージに応答して送らなければなりません。
A registration acknowledgment message MUST be protected by either a valid authenticator as specified in [1], namely a home-foreign authenticator if the communication is between home and foreign agents, or a mobile-home authenticator if the communication is between home agent and 'direct' co-located mobile node, or another security mechanism at least as secure and agreed upon by the home and foreign domains, e.g., IPsec.
登録確認メッセージは、通信がホームとフォーリンエージェント、またはモバイル・ホーム・オーセンティケータの間にある場合、通信は、ホームエージェントと 'の間にある場合、[1]、すなわち家庭外国オーセンティケータで指定されるように、有効な認証者のいずれかによって保護されなければなりません直接」同じ場所に配置、移動ノード、または少なくともなどの安全な別のセキュリティメカニズムと家と外国のドメイン、例えば、IPsecのことで合意しました。
An example of the use of Revocation Acknowledgment Messages is given in Appendix A.
失効確認応答メッセージの使用例は、付録Aに記載されています
As registration revocation messages are designed to terminate service for a mobile node, or multiple mobile nodes simultaneously, replay protection is crucial to prevent denial of service attacks by "malicious repeaters" - those who store datagrams with the intent of replaying them at a later time, or by "malicious reflectors" - those who reflect packets back at their original source (both a form of "active" attack). See Section 6. for a discussion of these security considerations.
登録失効メッセージは、移動ノード、または同時に複数のモバイルノードのためのサービスを終了するように設計されているので、再生保護は「悪質なリピーター」により、サービス拒否攻撃を防ぐために非常に重要である - 後でそれを再生することを意図してデータグラムを格納した者は、元のソース（「アクティブ」攻撃の形態の両方）でパケットをバック反映人 - 、または「悪意のある反射」によって。これらのセキュリティ上の考慮事項の説明については、6章を参照してください。
All Revocation Messages and Revocation Acknowledgment Messages MUST be authenticated as well be replay-protected. The order in which they are done, however, is up to implementation.
すべての失効メッセージおよび失効確認応答メッセージは、リプレイで保護するだけでなく、認証されなければなりません。それらが行われる順序は、しかし、実装に任されています。
Replay protection is handled with a simple timestamp mechanism, using a single 32-bit identifier field in the registration revocation message, in conjunction with the home address field, to associate any revocation acknowledgment messages with its revocation messages. To do this:
リプレイ保護は、その失効メッセージで任意の失効確認応答メッセージを関連付けるために、ホーム・アドレス・フィールドに関連して、登録取消メッセージに1つの32ビットの識別子フィールドを使用して、単純なタイムスタンプ機構で処理されます。これをする：
- The revoking agent sets the 'A' bit to its agent-type, and the Revocation Identifier field in the registration revocation message to a valid 32-bit timestamp from the same clock it is using to set the timestamp field of its revocation extensions included in registration messages.
- 取り消し剤は、含まれ、その失効拡張のタイムスタンプフィールドを設定するために使用されるのと同じクロックから有効な32ビットのタイムスタンプに登録取消メッセージにその剤型に「」ビット、および失効識別子フィールドを設定します登録メッセージインチ
- Upon receipt of an authenticated revocation message, the receiving agent (or 'direct' co-located mobile node) MUST check the value of the 'A' bit, and Revocation Identifier to make sure this revocation message is not a replay of an old revocation message received from the same agent. The receiving agent MUST also check that the message is not a reflection of a revocation message it sent in relation to the identified binding. If the 'A' bit and Identifier field imply this packet is a replay, the revocation message MUST be silently discarded.
- 認証された取消しメッセージ、受信エージェント（または「直接」コロケートモバイルノード）を受信すると、この取消メッセージが古いのリプレイではないであることを確認するために「」ビット、および失効識別子の値をチェックしなければなりません失効メッセージは同じエージェントから受け取りました。受信エージェントは、メッセージは、それが同定された結合に関連して送信された取消メッセージの反映ではないことをチェックしなければなりません。 「」ビットと識別子フィールドは、このパケットがリプレイである暗示する場合、取消メッセージは静かに捨てなければなりません。
- When building a revocation acknowledgment message, the acknowledging agent (or 'direct' co-located mobile node) copies the values of the Home Address and Revocation Identifier fields from the revocation message into the Home Address and the Revocation Identifier of the revocation acknowledgment message. This is so the revoking agent can match this revocation acknowledgment to its corresponding revocation message.
- 取消承認メッセージ、肯定応答エージェント（または「直接」コロケートモバイルノード）のホームアドレスと取消承認メッセージの失効識別子にコピー取消メッセージからホームアドレスの値と、失効識別子フィールドを作成する場合。取り消し剤は、その対応する失効メッセージにこの失効確認を一致させることができるようです。
- Upon receiving a valid revocation acknowledgment, the revoking agent MUST check the Home Address and Identifier fields to make sure they match those fields from a corresponding revocation message it sent to the acknowledging agent. If not, this revocation acknowledgment message MUST be silently discarded.
- 有効な失効確認を受信すると、取り消しエージェントが、彼らはそれを認めてエージェントに送信され、対応する失効メッセージからそれらのフィールドと一致していることを確認するためにホームアドレスと識別子フィールドをチェックしなければなりません。ない場合は、この失効確認応答メッセージは静かに捨てなければなりません。
Note that since the Identifier in an incoming revocation message is a 32-bit timestamp, it is possible for an agent to check the validity of the Identifier fields without having to remember all identifiers sent by that corresponding agent.
着信取消メッセージ内の識別子は、32ビットのタイムスタンプであるので、エージェントがその対応するエージェントによって送信された全ての識別子を記憶することなく、識別子フィールドの妥当性を確認するために、それが可能であることに留意されたいです。
Note: as it is possible for a mobile node to register at different times with different home agents, and at different times with different foreign agents, it is crucial that it not be required that the Identifier fields be unique in messages from different agents as there is no guarantee that clocks on different agents will be synchronized. For example, if a mobile node has simultaneous bindings with multiple foreign agents, and if revocation messages are received by more than one such foreign agent "simultaneously", it is possible the revocation message from one of these foreign agents may contain Identifier fields that happen to match those of any or all the other foreign agents. This MUST NOT result in any of these revocation messages being ignored.
モバイルノードが異なるホームエージェントと異なる時間に登録することが可能であるとして、そして異なる外国人のエージェントと異なる時間に、識別子フィールドがなどが異なるエージェントからのメッセージに一意であることを要求されないことが重要です。注意してください異なる薬剤のクロックが同期されます保証するものではありません。例えば、モバイルノードは、複数の外部エージェントとの同時バインディングを有する場合、および失効メッセージは、「同時に」は、2つ以上のそのような外部エージェントによって受信された場合、それが起こる識別子フィールドを含むことができるこれらの外部エージェントのいずれかから失効メッセージは可能ですいずれかまたは全ての他の外国のエージェントのものと一致します。これは無視され、これらの失効メッセージのいずれかが生じてはなりません。
Registration Revocation consists of two distinct pieces: a signaling mechanism between tunnel endpoints, and a signaling mechanism between foreign agent and mobile node. A 'direct' co-located mobile node MAY implement revocation extensions and revocation acknowledgment in order to receive and respond to revocation messages from its home agent, however, a 'direct' co-located mobile node MUST NOT send a revocation message as de-registration messages defined in [1] are sufficient for this purpose.
トンネルエンドポイント間のシグナリング機構と、外部エージェントとモバイルノードとの間のシグナリング機構：登録取消しは、2つの別個の片から構成されています。 「直接」共同設置、移動ノードが受信し、そのホームエージェントからのメッセージを失効に対応するために失効拡張および失効確認を実装するかもしれない、しかし、「直接」共同設置、移動ノードは、デよう失効メッセージを送ってはいけません[1]で定義された登録メッセージは、この目的のために十分です。
For further discussion on security issues related to registration revocation, refer to Section 6.
登録取消しに関連するセキュリティ問題に関するさらなる議論については、第6章を参照してください。
A mechanism which provides a foreign agent a way to actively notify a mobile node that its binding has been reset already exists in [1], though it has been overlooked for this purpose.
外部エージェントに積極的に結合モバイルノードに通知する方法を提供するメカニズムは、この目的のために見過ごされているが既に[1]に存在するリセットされています。
A brief overview of the mechanics of the sequence number in agent advertisement from [1] is given so that the mechanism by which the foreign agent 'implies' to the mobile node that its binding is no longer active is clearly understood.
外部エージェントは、その結合モバイルノードに「意味」する機構がもはやアクティブであるように[1]が与えられていないからエージェント広告内のシーケンス番号の仕組みの概要を明確に理解されています。
When a foreign agent begins sending agent advertisements, it starts with a sequence number of 0, and [monotonically] increments the sequence number with each subsequent agent advertisement. In order for a mobile node to be able to distinguish between a foreign agent that has simply exhausted the sequence number space from one which has been reset, when the agent increments the sequence number counter past its maximum value, it sets the sequence number to 256 instead of rolling to 0 [1]. In this way, a mobile node would have to miss, at that time, 256 advertisements in a row to mistake a reset as a roll-over. Moreover, the lifetimes contained within an agent advertisement should be set in such a way that when a mobile node believes it has missed 3 beacons, the entry for this foreign agent should time out, and if the mobile node is registered there, it should send an agent solicitation [1]. If, however, an agent is somehow reset, it will begin advertising with a sequence number of 0, and the mobile node can presume this foreign agent has lost its binding, and the mobile node SHOULD re-register to make sure it is still obtaining Mobile IP services through this foreign agent.
外部エージェントは、エージェントアドバタイズメントの送信を開始するとき、それは0のシーケンス番号で始まり、[単調に各後続のエージェント広告とシーケンス番号をインクリメントします。モバイルノードは、単にエージェントがその最大値過去のシーケンス番号カウンタをインクリメントリセットされたもの、からシーケンス番号空間を使い果たした外部エージェントを区別することができるようにするために、それは256にシーケンス番号を設定します代わりに0に圧延の[1]。このように、モバイルノードは、ロールオーバーのようにリセットを間違え、その時点で、行の256社の広告を逃すしなければなりません。また、エージェント広告内に含まれる寿命は、モバイルノードは、それが3つのビーコンを逃したと考えていたときに、この外国人のエージェントのエントリがタイムアウトすべきであるように設定する必要があり、モバイルノードがあっ登録されている場合、それが送信する必要がありますエージェント要請[1]。しかし、エージェントが何らかの形でリセットされた場合、それは0のシーケンス番号で広告を開始し、この外国人のエージェントを推定することができ、モバイルノードはそのバインディング失ってしまった、モバイルノードは、それがまだ取得されていることを確認するために再登録する必要がありますこの外国人のエージェントを介してモバイルIPサービスを提供します。
Leveraging this mechanism, a foreign agent may consciously notify all mobile nodes currently bound to it that it has "reset" all of their bindings, even if the agent itself has not been reset, by simply [re]setting the sequence number of the next agent advertisement to 0. Moreover, a foreign agent may inform all mobile nodes currently bound to it that they should re-register with a different foreign agent by simultaneously setting the 'B' bit in the advertisement to 1, indicating this foreign agent is busy and is not accepting new registrations [1]. In these situations, any mobile node in compliance with [1] will presume this foreign agent has lost its binding, and must re-register if they wish to re-establish Mobile IP functionality with their home subnet.
このメカニズムを活用して、外国人のエージェントは意識単ににより、薬剤自体がリセットされていなくても、それはそのバインディングの全てを「リセット」したことを、現在それにバインドされたすべてのモバイルノードに通知することができる[再]次のシーケンス番号を設定します0にエージェント広告はまた、外部エージェントは、現在、それらは同時に、この外国人のエージェントがビジーであることを示す、1広告に「B」ビットを設定することにより、別の外部エージェントに再登録する必要があること、それにバインドされたすべてのモバイルノードに通知することができますそして、[1]新規登録を受け付けていません。このような状況では、[1]この外国人のエージェントを推定しますに準拠した任意のモバイルノードはそのバインディング失っている、と彼らは彼らのホームサブネットとモバイルIP機能を再確立したい場合は、再登録する必要があります。
To indicate to any registered mobile node that its binding no longer exists, the foreign agent with which the mobile node is registered may unicast an agent advertisement with the sequence number set to 0 to the mobile node [1], [D]. Moreover, if such a foreign agent wishes to indicate to the mobile node that its binding has been revoked, and that the mobile node should not attempt to renew its registration with it, the foreign agent MAY also set the 'B' bit to 1 in these agent advertisements, indicating it is busy, and is not accepting new registrations [1]. All mobile nodes compliant with [1] will understand that this means the agent is busy, and MAY either immediately attempt to re-register with another agent in their foreign agent cache, or MAY solicit for additional agents. In the latter case, a foreign agent can optionally remember the mobile node's binding was revoked, and respond to the solicit in the same way, namely with the 'B' bit set to 1. It should be noted, though, that since the foreign agent is likely to not be setting the 'B' bit to 1 in its broadcasted agent advertisements (sent to the entire link), the revoked mobile node, upon hearing this agent's multicast agent advertisement without the 'B' bit set, may attempt to [re]register with it. If this happens, depending on foreign domain policy, the foreign agent can simply deny the mobile node with an appropriate error code (e.g., "administratively prohibited"). At this time, a mobile node can use foreign agent fallback to attempt to register with a different foreign agent as described in [1].
それが存在もはや結合しない任意の登録されたモバイルノードに示すために、モバイルノードが登録されている外部エージェントは、移動ノード[1]、[D]は0に設定されたシーケンス番号にエージェント広告をユニキャストしてもよいです。そのような外部エージェントは、移動ノードがそれとの登録を更新しようとしないことを、そのが取り消された結合モバイルノードに指示することを望む場合、およびさらに、外部エージェントはまた、1「B」ビットを設定することができますこれらのエージェントの広告は、それがビジー状態であることを示す、新たな登録を受け付けていません[1]。準拠したすべてのモバイルノードは、[1]これは、エージェントがビジー状態である、とのいずれかすぐにその外国人のエージェントのキャッシュに別のエージェントに再登録しようとしたり、追加のエージェントの勧誘できることを意味することを理解するであろう。後者の場合、外部エージェントは、必要に応じて、モバイルノードのが取り消された結合を思い出すことができ、そして、しかし、すなわちなお、1に設定ビット「B」で、同じように要請に応えること外国以来エージェントは（全体のリンクに送信される）、その放送エージェントアドバタイズ1に「B」ビットを設定できない可能性がある、取り消されたモバイルノードは、「B」ビットが設定されていないこのエージェントのマルチキャストエージェント広告を聞いて、しようと試みることができますそれに登録[再]。これは外部ドメインのポリシーに応じて、発生した場合、外部エージェントは、単に適切なエラーコード（例えば、「管理上禁止」）を持つモバイルノードを拒否することができます。この時、移動ノード[1]に記載のように、異なる外部エージェントに登録しようとする外部エージェントフォールバックを使用することができます。
Mobile nodes which understand the revocation mechanism described by this document may understand that a unicast agent advertisement with the sequence number reset to 0 could indicate a revocation, and may attempt to re-register with the same foreign agent, or register with a different foreign agent, or co-locate.
このドキュメントによって記述さ失効メカニズムを理解するモバイルノードは、シーケンス番号を持つユニキャストエージェント広告が失効している可能性が0にリセットすることを理解することができ、同じ外部エージェントに再登録することを試みることができる、または異なる外部エージェントに登録します、または共見つけます。
Agent Advertisements unicast to a mobile node MUST be sent as described in [1] in addition to any methods currently in use on the link to make them secure or authenticatable to protect from denial-of-service attacks.
[1]に記載されているように、モバイルノードにエージェント広告ユニキャストは、サービス拒否攻撃から保護するためにそれらが安全又は認証可能にするためにリンク上で現在使用されている任意の方法に加えて送信されなければなりません。
A foreign agent that is currently supporting registration revocation on a link MUST set the 'X' bit in its Agent Advertisement Extensions being sent on that link. This allows mobile nodes requiring Registration Revocation services to register with those foreign agents advertising its support.
現在、リンク上で登録の失効をサポートしている外国人のエージェントは、そのリンク上で送信されているそのエージェント広告Extensionsの「X」ビットを設定しなければなりません。これは、そのサポートを広告するそれらの外国人のエージェントに登録する登録失効サービスを必要とする移動ノードを可能にします。
During the registration process, if the foreign agent wishes to participate in revocation messages with the home domain, it MUST have an existing security association with the home agent identified in the registration request, and append a revocation support extension (defined in Section 3.2.) to it. If the corresponding registration reply from this home agent does not contain a revocation support extension, the foreign agent SHOULD assume the home agent does not understand registration revocation, or is unwilling to participate. If this is unacceptable to the foreign agent, it MAY deny the registration with e.g., "Administratively Prohibited". Note that in this case, where a security association exists, as specified in [1], both registration request and registration reply MUST still contain home-foreign authenticators.
外国人のエージェントがホームドメインに失効メッセージに参加を希望する場合は、登録プロセスの間に、それは登録要求で識別されるホーム・エージェントとの既存のセキュリティアソシエーションを持っている、と失効サポート拡張付加する必要があります（セクション3.2で定義されています。）それに。このホームエージェントから対応する登録回答は失効サポート拡張が含まれていない場合は、外国人のエージェントは、ホームエージェントは、登録取り消しを理解しないと仮定し、または参加に消極的であるべきです。これは外国人のエージェントに受け入れられない場合、それは例えば、「管理上禁止」への登録を拒否することができます。で指定されたセキュリティアソシエーションが、存在する。この場合、[1]、登録要求および登録応答の両方がまだホーム外国オーセンティケータを含まなければならないことに留意されたいです。
If a home agent wishes to be able to exchange revocation messages with the foreign domain, it MUST have an existing security association with the foreign agent who relayed the registration request, and it MUST append a revocation support extension to the registration reply. If the registration request from a foreign agent did not contain a revocation support extension, the home agent SHOULD assume the foreign agent does not understand registration revocation, or is unwilling to participate specifically for this binding. If this is unacceptable to the home agent, it MAY deny the registration with e.g., "Administratively Prohibited". The home agent MAY include a revocation support extension in the registration reply.
ホームエージェントは、外部ドメインに失効メッセージを交換できるようにしたい場合は、登録要求を中継する外国人のエージェントとの既存のセキュリティアソシエーションを持たなければならない、そしてそれは登録応答に失効サポート拡張を追加しなければなりません。外国人のエージェントからの登録要求が失効サポート拡張が含まれていなかった場合は、ホームエージェントは、外部エージェントは、登録取り消しを理解しないと仮定し、またはこの結合のために特別に参加することが不本意であるべきです。これは、ホームエージェントに受け入れられない場合、それは例えば、「管理上禁止」への登録を拒否することができます。ホームエージェントは登録応答で失効サポート拡張を含むかもしれません。
If a 'direct' co-located mobile node wishes to be informed of a released binding by its home agent, it MUST insert a revocation support extension into the registration request. If this is acceptable to the home agent, it MUST include a revocation support extension in its registration reply. Note that if this is not acceptable, the home agent MAY deny the registration, or it MAY simply not include a revocation support extension in its registration reply indicating to the mobile node that it will not participate in revocation for this binding. A home agent which receives a registration request from a 'direct' co-located mobile node which does not contain a revocation support extension MAY deny the registration with e.g., "Administratively Prohibited" and also MAY or MAY NOT include a revocation support extension in the registration reply.
「直接」共同設置、移動ノードがホームエージェントによって解放結合を知らせることを希望する場合は、登録要求に失効サポート拡張を挿入しなければなりません。これは、ホームエージェントに受け入れられるならば、それはその登録応答で失効サポート拡張を含まなければなりません。これが受け入れられない場合は、ホームエージェントは登録を拒否することができる、またはそれは単にそれがこの結合のための取消しに参加しないモバイルノードに指示するその登録応答で失効サポート拡張を含まなくてもよいことに注意してください。失効サポート拡張が含まれていません「直接」同じ場所に配置、移動ノードからの登録要求を受信したホームエージェントは例えば、「管理上禁止」への登録を拒否してもしたりで失効サポート拡張を含んでも含まなくてもよいです登録応答。
Note that a non-colocated mobile node MUST NOT insert a revocation support extension into its registration request. If a foreign agent receives such a registration request, it MUST silently discard it, and MAY log it as a protocol error.
非共存モバイルノードが登録要求に失効サポート拡張を挿入してはならないことに注意してください。外国人のエージェントは、このような登録要求を受信した場合、それは静かにそれを捨てなければなりませんし、プロトコルエラーとしてログインすることができます。
The 'I' bit in the revocation extension is used to indicate whether or not the decision to inform the mobile node that its binding is terminated will be left to the home agent. This functionality is offered by the foreign agent, and accepted by the home agent. More precisely, by sending a revocation extension attached to a registration request in which the 'I' bit is set to 1, the foreign agent is indicating to the home agent that it MAY leave the decision to inform this mobile node that its registration is terminated up to the home agent. (The term "MAY" is used here because it is recognized that domain policy may change during the lifetime of any registration). The home agent can acknowledge that it wishes to do this by setting the 'I' bit to 1, or it can indicate it will not do so by setting the 'I' bit to 0, in the revocation extension appearing in the registration reply.
失効拡張の「I」ビットは、そのバインディングが終了したモバイルノードに通知するという決定は、ホームエージェントに残されるかどうかを示すために使用されています。この機能は、外国人のエージェントによって提供され、ホームエージェントによって受け入れられています。より正確には、「I」ビットが1にセットされ、外国人のエージェントは、その登録が終了し、このモバイルノードに通知するために決定を残すことができることを、ホームエージェントに指示された登録要求に添付失効拡張を送信することにより、ホームエージェントまで。 （ドメインポリシーはどの登録の存続期間中に変更される可能性があることを認識されているため、この用語は、ここで使用される「MAY」）。ホームエージェントは、それが1に「I」ビットを設定することにより、これを行うために望んでいることを認めることができ、またはそれは登録応答に登場失効拡張では、0に「I」ビットを設定することにより、そうではないだろう示すことができます。
Revocation support is considered to be negotiated for a binding when both sides have included a revocation support extension during a successful registration exchange.
失効のサポートは、両側が正常に登録交換の際に失効サポート拡張が含まれているとき、結合のために交渉していると考えられます。
The following section details the responsibilities of each party depending on the functionality negotiated in the revocation support extensions when the home domain is revoking a registration.
次のセクションでは、ホームドメインが登録を取り消しされたときに失効サポート拡張で交渉機能に応じて、各当事者の責任を詳述します。
In the case where a home agent is revoking a mobile node's binding, and revocation support has been negotiated, the home agent MUST notify the foreign domain address it is terminating the tunnel entry point by sending a revocation message. Note that the foreign domain address can either be the foreign agent care-of address, or the co-located care-of address of a 'direct' co-located mobile node.
ホームエージェントが交渉されたモバイルノードのバインディング、および失効サポートを取り消した場合には、ホーム・エージェントは、それが取消しメッセージを送信することによって、トンネルエントリポイントを終了して外部ドメインアドレスを通知しなければなりません。外部ドメインのアドレスをアドレスフォーリンエージェントのケア-、または同じ場所に配置ケア-の「直接」共同設置、移動ノードのアドレスのいずれかとすることができることに注意してください。
As a home agent, it MUST set the 'A' bit to '1', indicating this packet is coming from the home agent servicing this binding.
ホームエージェントとして、このパケットは、この結合にサービスを提供するホームエージェントから来て示し、「1」に「」ビットを設定しなければなりません。
When a revocation message is being sent to a foreign agent, and the use of the 'I' bit was negotiated in the registration process, the home agent MUST set the 'I' bit to 1 if the home agent would like the foreign agent to inform the mobile node of the revocation. Conversely, if the home agent does not want the mobile node notified, it MUST set the 'I' bit to 0. Note that the home agent could also set the 'I' bit to '0' because it knows the mobile node has registered with a different foreign agent, and so there is no need for the foreign agent to attempt a notification.
失効メッセージは、登録プロセスで交渉された外国人のエージェント、および「I」ビットの使用に送信された場合、ホームエージェントは、外部エージェントへの希望の場合は、ホームエージェントは1に「I」ビットを設定しなければなりません失効のモバイルノードに通知します。ホームエージェントは、モバイルノードに通知したくない場合は逆に、それは、モバイルノードが登録されている知っているので、ホームエージェントはまた、「0」を「I」ビットを設定することができることを0に注意することは「I」ビットを設定しなければなりません別の外国人のエージェントと、そのための通知を試みる外国人のエージェントは必要ありません。
The home agent MUST set the Identifier field as defined in Section 3.5., and MUST include a valid authenticator as specified in Section 3.3.
ホームエージェントは、セクション3.5で定義されている。識別子フィールドを設定しなければなりませんし、3.3節で指定された有効な認証システムを含まなければなりません。
If the home agent does not receive a revocation acknowledgment message within a reasonable amount of time, it MUST retransmit the revocation message. How long the home agent waits to retransmit, and how many times the message is retransmitted is limited by the requirement that:
ホームエージェントは、妥当な時間内失効確認メッセージを受信しない場合、失効メッセージを再送しなければなりません。どのくらいのホームエージェントは、再送信するために待機し、何回メッセージがその要件によって制限されて再送されています。
- every time the home agent is about to retransmit the revocation message, it MUST update the value of the timestamp in the revocation identifier with a current value from the same clock used to generate the timestamps in the revocation extensions sent to this foreign agent. Note that this also necessarily means updating any fields derived using the revocation identifier (e.g., a home-foreign authenticator).
- ホームエージェントがRevocationメッセージを再送信しようとするたびに、それはこの外国人のエージェントに送信された失効拡張のタイムスタンプを生成するのに使用されるのと同じクロックからの電流値に失効識別子のタイムスタンプの値を更新する必要があります。これも必ずしも失効識別子（例えば、ホーム外国オーセンティケータ）を用いて誘導される任意のフィールドを更新することを意味することに留意されたいです。
- the home agent MUST NOT send more than one revocation per second for a particular binding,
- ホームエージェントは、特定の結合のために毎秒つ以上の失効を送ってはいけません
- the time between retransmissions SHOULD fall-back in analogy with the registration guidelines in [1], namely exponential backoff, and
- 再送信の間の時間は、フォールバックをSHOULD同様に[1]、即ち、指数バックオフの登録ガイドラインと、そして
- the home agent MUST NOT retransmit revocation messages beyond the normal life of the binding identified by the revocation message.
- ホームエージェントは取消しメッセージによって同定された結合の普通の生活を超えて失効メッセージを再送してはなりません。
Upon receiving a registration revocation message, the foreign agent MUST check that the validity of the authenticator, the 'A' bit, and the identifier field against replay as defined by Section 3.5. The foreign agent MUST also identify the binding described by the home agent as being released using the information in the revocation message, namely the addresses identified by the mobile node address, the foreign domain address, the home domain address, as well as the timestamp in the revocation message, and also the timestamp in the last accepted registration message; revocations are only valid for existing registrations, and so the timestamp of a registration MUST precede the revocation message (note that both of those timestamps were set by the same home agent). Upon locating the binding, the foreign agent MUST revoke it, and MUST respond with a revocation acknowledgment sent to the source address of the revocation message. If the 'I' bit was negotiated, the foreign agent MUST check the value of the 'I' bit in the revocation message and act accordingly.
登録取消メッセージを受信すると、外部エージェントは、認証の有効性、リプレイに対する「」ビット、および識別子フィールドは、セクション3.5で定義されているよういることを確認しなければなりません。外部エージェントはまた、バインディング取消メッセージは、モバイルノードのアドレスによって識別される、すなわちアドレス、外国ドメインアドレス、ホームドメインアドレス、ならびににおけるタイムスタンプの情報を使用して放出されるように、ホームエージェントによって記述を識別しなければなりませんまた、失効メッセージ、そして最後に受け入れ登録メッセージのタイムスタンプ。取り消しは、既存の登録のためにのみ有効であるので、失効メッセージに先行しなければなりません登録のタイムスタンプは、（それらのタイムスタンプの両方が同じホームエージェントによって設定されたことに注意してください）。結合の位置を特定する際に、フォーリンエージェントはそれを取り消す必要があり、失効メッセージの送信元アドレスに送信された失効確認応答で応答しなければなりません。 「I」ビットが交渉された場合は、外国人のエージェントは取消しメッセージの「I」ビットの値をチェックし、それに従って行動しなければなりません。
If notifying the mobile node by the methods described in Section 4.1., the foreign agent MUST set the 'I' bit to '1' in the revocation acknowledgment to be sent to the home agent, or if not notifying the mobile node, the foreign agent MUST set the 'I' bit to '0'.
4.1節で説明した方法により、モバイルノードに通知する場合は、外国人のエージェントが外国、ホームエージェントに送信する失効確認中「1」を「I」ビット、またはそうでない場合は、モバイルノードに通知を設定しなければなりませんエージェントは「0」を「I」ビットを設定しなければなりません。
The foreign agent may discontinue all Mobile IP services by the former binding at this time, and free up any resources that were being used by it.
外国人のエージェントは、この時点で旧結合することによって、すべてのモバイルIPサービスを中止し、それによって使用されていたすべてのリソースを解放します。
The foreign agent MUST then generate a revocation acknowledgment, setting the Home Address and Identifier field in the revocation acknowledgment message as described by Section 3.5., and protect it with a valid authenticator as specified in Section 3.3.
外国人のエージェントはその後。3.5節で述べたよう失効確認メッセージでホームアドレスと識別子フィールドを設定、失効確認応答を生成し、3.3節で指定されている有効な認証システムとそれを保護する必要があります。
Upon receiving a revocation message, the 'direct' co-located mobile node MUST validate the authenticator, and check the home address and identifier specified in the revocation message for replay. If the packet passes authentication, and the identifier reveals this revocation to be new, the mobile node MUST verify that the information contained in the revocation messages identifies the home agent with which it has a current binding, that this binding identifies correctly this mobile node and any foreign domain address it is currently using. If the mobile node is able to identify such a binding, the mobile node SHOULD first generate a revocation acknowledgment message which MUST be sent to the IP source address of the revocation message. The mobile node may then terminate any reverse tunnel encapsulation [C] it is using to this home agent, and consider its binding revoked, and free up any other resources associated with the former binding.
取消しメッセージを受信すると、「直接」コロケートモバイルノードは、認証を検証し、そして再生のための失効メッセージで指定されたホームアドレスと識別子をチェックしなければなりません。パケットが認証をパスし、識別子が新しいことをこの取り消しを明らかにしている場合、モバイルノードは、失効メッセージに含まれる情報は、それが現在のバインディングを持っていると、ホームエージェントを識別していることを確認し、それを正しくこのバインディングを識別し、この移動ノードとしなければなりませんそれが現在使用しているすべての外部ドメインのアドレス。モバイルノードは、バインディングを識別することが可能である場合、移動ノードは最初取消メッセージのIPソースアドレスに送信されなければならない取消確認メッセージを生成する必要があります。モバイルノードは、それが、このホームエージェントに使用し、その結合が失効検討し、前者の結合に関連する任意の他のリソースを解放している任意の逆トンネルカプセル化[C]を終了することができます。
The following section details the responsibilities of each party depending on the functionality negotiated in the revocation support extensions when the foreign domain is revoking a registration. Note that revocation support for a co-located mobile node registering via a foreign agent (because the 'R' bit was set in the agent's advertisement) is not supported. See Section 4.3.1. for details.
次のセクションでは、外部ドメインが登録を取り消しされたときに失効サポート拡張で交渉機能に応じて、各当事者の責任を詳述します。サポートされていません（「R」ビットは、エージェントの広告で設定されたため）外国人のエージェントを経由して登録する共同設置、移動ノードのためにその失効サポートを注意してください。 4.3.1項を参照してください。詳細については。
If the use of the 'I' bit was negotiated, and the foreign domain policy of informing the mobile node has not changed since the last successful registration exchange, the foreign agent MUST NOT inform any mobile node of its revocation at this time. Instead, the foreign agent MUST set the 'I' bit to '1' in the revocation message, thereby asking the home agent to use the 'I' bit in the revocation acknowledgment to indicate if it should notify the effected mobile nodes. If the policy on the foreign domain was to not notify the mobile node, or if it has changed since the most recent successful registration, and the foreign agent is no longer able to use the 'I' bit, the foreign agent MUST set the 'I' bit to '0', and follow the policies of the foreign domain with regard to notifying the mobile node.
「I」ビットの使用が交渉し、モバイルノードに通知する外部ドメインポリシーが最後に正常に登録交換から変更されていない場合は、外国人のエージェントは、この時点でその取消しの任意のモバイルノードに通知してはなりません。代わりに、外国人のエージェントは「I」ビットを設定しなければなりません「1」に失効メッセージで、それによってもたらさモバイルノードに通知する必要があるかどうかを示すために失効確認に「I」ビットを使用するために、ホームエージェントを尋ねます。外部ドメイン上の政策は、モバイルノードに通知していないことだった、またはそれが成功した最新の登録以来変わっていない、と外国人のエージェントは、もはや「I」ビットを使用することができる場合、外国人のエージェントは 'を設定しなければならない場合I 『0」にビット』、およびモバイルノードに通知に関して外部ドメインのポリシーに従ってください。
Note that the 'A' bit MUST be set to '0' to indicate that the revocation message is coming from the foreign agent servicing this binding.
「」ビットが取消しメッセージがこの結合にサービスを提供外部エージェントから来ていることを示すために「0」に設定しなければならないことに留意されたいです。
Before transmitting the revocation message, the foreign agent MUST set the revocation identifier as described by section 3.5., and MUST include an authenticator as described by section 3.3.
取り消しメッセージを送信する前に、外部エージェントは、セクション3.5。によって記載されているように失効識別子を設定しなければなりません、セクション3.3により記載されたように、オーセンティケータを含まなければなりません。
If the foreign agent does not receive a revocation acknowledgment message within a reasonable amount of time, it MUST retransmit the revocation message. How long the foreign agent waits to retransmit, and how many times the message is retransmitted is only limited by the following specifications:
外国人のエージェントが妥当な時間内失効確認メッセージを受信しない場合、失効メッセージを再送しなければなりません。どのくらいの外国人のエージェントは、再送信するために待機し、何回メッセージのみが次の仕様によって制限されて再送されています。
- every time the foreign agent is about to retransmit the revocation message, it MUST update the value of the timestamp in the revocation identifier with a current value from the same clock used to generate the timestamps in the revocation extensions sent to this home agent. Note that this also necessarily means updating any fields derived using the revocation identifier (e.g., a home-foreign authenticator).
- 外国人のエージェントは取消しメッセージを再送しようとするたびに、それはこのホームエージェントに送信された失効拡張のタイムスタンプを生成するのに使用されるのと同じクロックからの電流値に失効識別子のタイムスタンプの値を更新する必要があります。これも必ずしも失効識別子（例えば、ホーム外国オーセンティケータ）を用いて誘導される任意のフィールドを更新することを意味することに留意されたいです。
- MUST NOT send more than one revocation per second for a particular binding,
- 、特定の結合のために毎秒つ以上の失効を送ってはいけません
- SHOULD set its retransmissions to fall-back in analogy with the registration guidelines in [1], namely exponential backoff, and
- フォールバックと同様に、[1]、即ち、指数バックオフの登録ガイドラインにその再送を設定して、SHOULD
- MUST NOT retransmit revocation messages beyond the normal life of the binding identified by the revocation message.
- 取消しメッセージによって同定された結合の普通の生活を超えて失効メッセージを再送してはなりません。
Upon receiving a registration revocation message, the home agent MUST check the 'A' bit, and identifier field, as well as the authenticator. If the packet is acceptable, the home agent MUST locate the binding identified by the foreign agent as being released using the information in the revocation message, namely the addresses identified by the home address, the foreign domain address and the home domain address fields. As revocations are only valid for existing registrations, the timestamp of a registration MUST precede the revocation message (note that both of those timestamps were set by the same foreign agent). Since this binding is no longer active, the home agent can free up any resources associated with the former binding and discontinue all Mobile IP services for it.
登録取消しメッセージを受信すると、ホームエージェントは、「」ビット、および識別子フィールドと同様に、オーセンティケータをチェックしなければなりません。パケットが許容される場合は、ホームエージェントがRevocationメッセージ内の情報を使用してリリースされたものとして外国人のエージェントによって同定された結合見つける必要があり、すなわちホームアドレス、外国ドメインアドレスとホームドメインのアドレスフィールドで識別されるアドレス。取り消しは、既存の登録のためにのみ有効であるとして、登録のタイムスタンプは失効メッセージを（それらのタイムスタンプの両方が同じ外国人のエージェントによって設定されたことに注意してください）先行しなければなりません。この結合は、もはや有効ではありませんので、ホームエージェントは、以前のバインディングに関連付けられているすべてのリソースを解放し、それのためにすべてのモバイルIPサービスを中止することができます。
Upon processing a valid registration revocation message, the home agent MUST send a revocation acknowledgment to the IP source address of the registration revocation message.
有効な登録取消しメッセージを処理すると、ホームエージェントは、登録失効メッセージの送信元IPアドレスに失効確認を送らなければなりません。
If use of the 'I' bit was negotiated, and the 'I' bit is set to '1' in the revocation message, the home agent should decide if it wants the mobile node informed of the revocation of this binding. If it does want the mobile node informed, it MUST set the 'I' bit in the revocation acknowledgment message to '1'. If it does not want the mobile node informed, it MUST set the 'I' bit to '0'.
「I」ビットの使用が交渉された、と「I」ビットが取消しメッセージの中で「1」に設定されている場合は、この結合の取消しの通知をモバイルノードを望んでいる場合は、ホームエージェントが決定する必要があります。それは、モバイルノードに通知したいんなら、それは「1」に失効確認メッセージの「I」ビットを設定しなければなりません。それは、モバイルノードに通知したくない場合は、それが「0」に「I」ビットを設定しなければなりません。
The home agent MUST set the Home Address, and Revocation Identifier fields as described by Section 3.5., and protect the revocation acknowledgment message with a valid authenticator as specified in Section 3.3.
ホームエージェントはホームアドレスを設定し、失効識別子フィールドを3.5節で説明したよう。、および3.3節に指定されている有効な認証システムで失効確認メッセージを保護する必要があります。
The cases where a mobile node is registered with its home agent, whether it is registered directly with its home agent ('direct' co-located mobile node), or registered via a foreign agent, and wishes to terminate its own binding, the mobile node MUST NOT send a revocation message, but SHOULD simply deregister the appropriate care-of address with its home agent as described by [1].
モバイルノードは、それがそのホームエージェント（「直接」コロケートモバイルノード）に直接登録し、又は外部エージェントを介して登録されているか、そのホームエージェントに登録し、自身のバインディング、移動を停止することを希望する場合ノードは、失効メッセージを送ってはいけませんが、[1]で説明したように、単純にそのホームエージェントに適切な気付アドレスの登録を解除すべきです。
Several of the bits used in the registration process need special consideration when using the revocation mechanism.
失効メカニズムを使用する場合、登録プロセス中に使用されるビットのいくつかは、特別な配慮を必要とします。
If the foreign agent wishes to be able to revoke a mobile node's registration, it MUST set the 'R' bit in its agent advertisements. (A foreign agent advertising the 'R' bit requests every mobile node, even one that is co-located (and whose registration would otherwise by-pass the foreign agent), to register with the foreign agent.) However, in this case, the foreign agent SHOULD deny a registration request as "Administratively Prohibited" from a mobile node that is registering in a co-located fashion. The reason being that the foreign agent will not be able to revoke the binding of a co-located mobile node due to reasons outlined in Section 4.3.2.
外国人のエージェントは、モバイルノードの登録を取り消すことができるようしたい場合は、そのエージェントの広告に「R」ビットを設定しなければなりません。 （外部エージェントは、外部エージェントに登録するすべてのモバイルノード、同一場所に配置されている一つでも（およびその登録その他）外部エージェントをバイパスあろうが、「R」ビット要求をアドバタイズ。）しかし、この場合、外国人のエージェントは、同じ場所に配置形式で登録されたモバイルノードから「管理上禁止」として登録要求を拒否すべきです。その理由は、外部エージェントが原因のセクション4.3.2に概説理由に共位置する移動ノードの結合を取り消すことができないことです。
How the foreign agent and/or foreign domain enforce the 'R' bit is beyond the scope of this document.
どのように外国人のエージェントおよび/または外部ドメインは「R」ビットを強制し、この文書の範囲を超えています。
A mobile node registering directly with its home agent in a co-located fashion with the 'D' bit set in its registration request is supported in registration revocation. However, support for a co-located mobile node (with the 'D' bit set in its registration request) registering via a foreign agent is not supported for the following reasons.
その登録要求に設定された「D」ビットと同じ場所に配置やり方でそのホームエージェントに直接登録するモバイルノードは、登録取り消しでサポートされています。しかし、（その登録要求に設定「D」ビットと）同一位置の移動ノードがフォーリンエージェントを介して登録するためのサポートは、次の理由によりサポートされていません。
Registration requests where the 'D' bit is set, and which are relayed through a foreign agent (e.g., due to the advertising of the 'R' bit) should theoretically contain the foreign agent address as the source address of the registration request when received by the home agent. A home agent may conclude that the source address of this registration request is not the same as the co-located care-of address contained in the registration request, and is therefore likely to be the address of the foreign agent. However, since there is no way to guarantee that this IP source address is in fact an address of the foreign agent servicing the mobile node, accepting a revocation message from this IP source address may lead to a denial-of-service attack by a man-in-the-middle on the mobile node.
受信されたときに「D」ビットが設定され、登録要求は、理論的には、登録要求の送信元アドレスとして外部エージェントアドレスを含まなければならない（これは「R」ビットの広告に、例えば）外部エージェントを介して中継されますホームエージェントによる。ホームエージェントは、この登録要求の送信元アドレスが同じ場所に配置気付けアドレス登録要求に含まれていると同じではありませんので、外国人のエージェントのアドレスである可能性が高いことを結論付けることができます。しかし、このIP送信元アドレスは、人によってDoS攻撃につながる可能性があり、このIPソースアドレスから失効メッセージを受け入れ、移動ノードにサービスを提供する外部エージェントのアドレスは、実際にあることを保証する方法はありませんので、 -in-中央モバイルノードに。
Moreover, there is currently no method for the foreign agent servicing the mobile node to identify itself to the home agent during the Mobile IP registration phase. Even if a foreign agent could identify itself, the co-located mobile node would also need to authorize that this foreign agent is indeed the agent that is providing it the Mobile IP services. This is to thwart a denial-of-service attack on the mobile node by a foreign agent that has a security association with the home agent, and is on the path between the co-located mobile node and the home agent.
また、モバイルIP登録フェーズの間にホームエージェントに自分自身を識別するために、モバイルノードにサービスを提供する外部エージェントのための方法は現在存在しません。外国人のエージェントが自身を識別できたとしても、同じ場所に配置モバイルノードは、この外国人のエージェントが実際にそれをモバイルIPサービスを提供している薬剤であることを認証する必要があります。これは、ホームエージェントとのセキュリティアソシエーションを持っている外国人のエージェントによって、モバイルノード上のサービス拒否攻撃を阻止するためのものであり、共同設置、移動ノードとホームエージェント間のパス上にあります。
As the intent of a registration revocation message is not a request to discontinue services, but is a notification that Mobile IP services are discontinued, there are no new error codes.
登録取消しメッセージの意図は、サービスを中止するための要求ではなく、モバイルIPサービスが廃止された通知であるため、新しいエラー・コードはありません。
There are two potential vulnerabilities, one in the agent advertisement mechanism, and one related to unauthorized revocation messages.
二つの潜在的な脆弱性、エージェント広告メカニズムの1、および不正失効メッセージに関連する1つがあります。
Although the mechanisms defined by this document do not introduce this problem, it has been recognized that agent advertisements as defined in [1] subject mobile nodes to a denial-of-service potential. This is because the agent advertisement as defined in [1] may be spoofed by other machines residing on the link. This makes it possible for such nodes to trick the mobile node into believing its registration has been revoked either by unicasting an advertisement with a reset sequence number to the link-local address of the mobile node, or by broadcasting it to the subnet, thereby tricking all mobile nodes registered with a particular foreign agent into believing all their registrations have been lost.
このドキュメントによって定義されたメカニズムは、この問題を導入していないが、エージェント広告がサービス拒否電位に[1]被験者モバイルノードで定義されていることが認識されています。 [1]で定義されるようにエージェント広告がリンク上に存在する他のマシンによって偽装される可能性があるためです。これによりだまし、それが可能このようなノードは、その登録は、移動ノードのリンクローカルアドレスにリセットシーケンス番号と広告をユニキャストすることにより、またはサブネットへのブロードキャストのいずれかによって取り消された信じるようにモバイルノードをだますようになりすべての登録を信じるように、特定の外部エージェントに登録されたすべてのモバイルノードが失われています。
There has been some work in this working group and others (e.g., IPsec) to secure such router advertisements, though at the time of this publication, no solutions have become common practice. To help circumvent possible denial of service issues here, bringing their potential for disruption to a minimum, mobile node implementors should ensure that any agent advertisement which doesn't conform to a strict adherence to [1], specifically those whose TTL is not 1, or which do not emanate from the same link-address (when present) as other agent advertisements supposedly from the same agent, or even that of the last successful registration reply, be silently discarded.
この出版物の時点で、何の解決策が一般的になっていないものの、このワーキンググループなどでいくつかの作業が行われている（例えば、IPsec）は、そのようなルータアドバタイズメントを確保します。最小の中断のためのそれらの可能性をもたらし、ここでサービスの問題の可能性のある拒否を回避を助けるために、モバイルノードの実装は、そのTTL 1ない[1]、具体的にそれらを厳守に適合しない任意のエージェント広告を保証すべきです他のエージェントが同じエージェント、あるいはその最後の正常な登録応答のからおそらく広告などの（存在する場合）、または同じリンクアドレスから発するしない、静かに捨てられます。
As registration revocation, when performed, terminates Mobile IP services being provided to the mobile node, it is crucial that all security and replay protection mechanisms be verified before a mobility agent believes that the other agent has revoked a binding. Messages which are sent link-local (e.g., between mobile node and foreign agent) MAY also be secured by methods outlined in [1], namely the use of mobile-foreign authenticators, but these have no direct relation to registration revocation.
登録取消しとして、行ったときに、モバイルノードに提供されるモバイルIPサービスを終了し、モビリティエージェントが他のエージェントが結合を取り消されたことを信じて前に、すべてのセキュリティおよびリプレイ保護メカニズムを検証することが重要です。 （モバイルノードと外部エージェントとの間で、例えば）リンクローカル送信されるメッセージは、移動外国オーセンティケータの[1]、即ち使用中で概説される方法によって固定されてもよいが、これらは、登録取消とは直接関係がありません。
RFC 3344 [1] defines a security mechanism that MUST be used between home agents and mobile nodes, and MAY used between home agents and foreign agents, namely the use of authenticators. All foreign and home agents MUST support protection of revocation messages via the foreign-home authenticators defined in [1]. They MAY implement other mechanisms of equal or greater strength; if such mechanisms are known to be available to both parties, they MAY be used instead.
RFC 3344 [1]ホームエージェントとモバイルノードの間で使用されなければならないセキュリティ・メカニズムを定義し、ホームエージェントと外部エージェント、オーセンティケータのすなわち使用の間使用されてもよいです。すべての外国人とホームエージェントは、[1]で定義された外国ホーム認証者を経由して失効メッセージの保護をサポートしなければなりません。これらは同等以上の強度の他のメカニズムを実装するかもしれません。そのようなメカニズムは、両当事者に利用可能であることが知られている場合は、彼らが代わりに使用されるかもしれません。
Revocation messages are at least as secure as registration messages passed between home and foreign agents and containing home-foreign authenticators as defined in [1]. Thus, there are no new security threats introduced by the revocation mechanism other than those present in [1] with respect to the compromise of the shared secret which is used to generate the home-foreign authenticators.
失効メッセージは、[1]で定義されるように登録メッセージがホームとフォーリンエージェントとホーム外国の固有識別を含む間で渡されると少なくとも同じ安全です。このように、家庭の外国認証トークンを生成するために使用される共有秘密の妥協点に関しては、[1]に存在するもの以外の取り消し機構により導入された新しいセキュリティ上の脅威はありません。
That said, there are two types of active attacks which use messages captured "in flight" by a man-in-the-middle between the home and foreign agents - "malicious repeaters" and "malicious reflectors".
「悪質なリピータ」と「悪質なリフレクター」 - それは家と外国人のエージェントとの間のman-in-the-middleで「飛行中に」撮影したメッセージを使用して、アクティブな攻撃の2種類がある、と述べました。
In the case of a "malicious repeater", a man-in-the-middle captures a revocation message, then replays it to the same IP destination address at a later time. Presuming the authenticator of the original packet was deemed valid, without replay protection, the home-foreign authenticator of the replayed packet will (again) pass authentication. Note that since datagrams are not guaranteed to arrive unduplicated, a replay may occur by "design".
「悪質なリピーター」の場合は、のman-in-the-middleが失効メッセージを取り込み、その後、後で同じIP宛先アドレスにそれを再生します。元のパケットの認証システムを仮定すると、再生保護なしで、リプレイパケットのホーム外国オーセンティケータは（再び）の認証を通過し、有効と判断されました。データグラムが重複しない到着することが保証されていないため、再生は「デザイン」によって発生する可能性があることに注意してください。
In the case of a "malicious reflector," a man-in-the-middle captures a revocation message, then returns it to its originator at a later time. If the security association between home and foreign domains uses a security association involving a (single) shared secret which only protects the contents of the UDP portion of the packet (such as home-foreign authenticators as defined by [1]), without replay
「悪意のあるリフレクタ」のman-in-the-middleが失効メッセージを捕捉した場合に、その後の時間にその発信元に戻します。家庭と外国のドメイン間のセキュリティアソシエーションは、リプレイすることなく、（[1]で定義されるような家庭外来オーセンティケータとして）のみパケットのUDP部の内容を保護（単一の）共有秘密キーを含むセキュリティアソシエーションを使用している場合
protection, the sender of the packet will also believe the revocation message to be authentic.
保護は、パケットの送信者はまた、失効メッセージが本物であることを信じています。
The replay protection mechanism used by the revocation messages defined by this document is designed to protect against both of these active attacks. As a benefit, by using a 32-bit timestamp it can be more quickly determined if revocation messages are replays, though the reader is advised to use caution in this approach. An agent which receives an authenticated revocation message can compare the Identifier field to that of a previously received revocation message, and if the timestamp in the new message is found to have been generated after that of the time-stamp in the last revocation message received, it can immediately be determined as not being a replay. Note however that since datagrams are not guaranteed to arrive in order, it should not be presumed that because the values contained in an Identifier field are timestamps that they will necessarily be increasing with each successive revocation message received. Should an implementor decide to base his replay detection mechanism on increasing timestamps, and therefore increasing Identifier values, a suitable time window should be defined in which revocation messages can be received. At worst, ignoring any revocation message should result in the retransmission of another revocation message, this time with timestamp later than the last one received.
この文書で定義された失効メッセージで使用されるリプレイ保護メカニズムは、これらのアクティブな攻撃の両方から保護するために設計されています。読者は、このアプローチには注意を使用することが推奨されるが失効メッセージは、リプレイする場合の利点として、32ビットのタイムスタンプを使用して、より迅速に決定することができます。認証された失効メッセージを受信したエージェントが、以前に取り消しメッセージを受信し、新しいメッセージにタイムスタンプが受信された最後の失効メッセージのタイムスタンプの後に生成されたことが発見された場合のそれに識別子フィールドを比較することができそれはすぐにリプレイではないと判断することができます。データグラムを順番に到着することが保証されていないので、識別子フィールドに含まれる値は、それらが必ずしも各連続取消メッセージに増加するタイムスタンプがあるため、受信したと推測されるべきではないことに注意してください。実装は、タイムスタンプを増加、従って識別子の値を増加させる上で彼のリプレイ検出機構を基に決定する必要があり、適切な時間窓は、失効メッセージを受信することができる定義されるべきです。最悪の場合、任意の失効メッセージを無視することは、後に受け取った最後のものよりもタイムスタンプを持つ別の失効メッセージ、今回の再送信を生じるはずです。
Note that any registration request or reply can be replayed. With the exchanging of time-stamps by agents in revocation extensions, an agent should have a belief that such messages have been delivered in a timely manner. For purposes of registration revocation, the timeliness of a registration packet is simply based on the granularity of each registration. Since [1] provides a replay mechanism for the home agent to use, it has a way to tell if the registration request being presented to it is new. The foreign agent, however, has no such mechanism in place with the mobile node. Foreign agents are advised to continue to consider registrations 'outstanding' until the associated registration reply is returned from the home agent before using the information in any of its visitor entries. Even so, this leaves the foreign agent open to a potential denial of service attack in which registration requests and replies are replayed by multiple nodes. When this happens, the foreign agent could be lead to believe such registrations are active, but with old information, which can have adverse effects on them, as well as to the ability of that agent to successfully use the procedures outlined in this document. Sufficient protection against this scenario is offered by the challenge-response mechanism [2] by which a foreign agent generates a live challenge to a mobile node for the purposes of making sure, among other things, that the registration request is not a replay.
任意の登録要求や応答が再生できることに注意してください。失効拡張でエージェントによってタイムスタンプの交換では、エージェントは、このようなメッセージがタイムリーに配信されたという信念を持っている必要があります。登録取消しの目的のために、登録パケットの適時性は、単に各登録の粒度に基づいています。 [1]を使用するには、ホームエージェントのための再生メカニズムを提供するので、それに提示されている登録要求が新規であれば、それは伝える方法があります。外部エージェントは、しかし、モバイル・ノードとの代わりに、そのような機構を有していません。外国人のエージェントは、関連する登録応答は、その訪問者のエントリのいずれかで情報を使用する前に、ホームエージェントから返されるまでの登録「卓越した」を検討して継続することをお勧めします。そうであっても、これは、登録要求と応答が複数のノードで再生されているサービス攻撃の可能性否定にオープン外国人のエージェントを残します。この場合、外部エージェントは、このような登録が有効ですが、それらの上だけでなく、正常にこの文書で説明する手順を使用するには、そのエージェントの能力に悪影響を与えることができ、古い情報、と信じるように導くことができました。このシナリオに対して十分な保護が外国人のエージェントは登録要求がリプレイではないこと、とりわけ、確認することを目的として、モバイルノードへのライブチャレンジを生成[2]これによりチャレンジレスポンスメカニズムによって提供されています。
This document defines an additional set of messages between the home and foreign agent specific to the services being provided to the same mobile node, or sub-set of mobile nodes. To ensure correct interoperation based on this specification, IANA has reserved values in the Mobile IP number space for two new message types, and a single new extension.
この文書では、同一のモバイルノードまたはモバイルノードのサブセットに提供される家庭やサービスに固有の外部エージェント間のメッセージの追加のセットを定義します。この仕様に基づいて正しい相互運用を保証するために、IANAは、2つの新しいメッセージタイプのモバイルIP番号空間内の値、および単一の新しい拡張を予約しました。
The following message types are introduced by this specification:
次のメッセージタイプは、この仕様で導入されています。
Registration Revocation: A new Mobile IP control message, using UDP port 434, type 7. This value has been taken from the same number space as Mobile IP Registration Request (Type = 1), and Mobile IP Registration Reply (Type = 3).
登録失効：新しいモバイルIP制御メッセージ、UDPポート434を使用して、タイプ7この値は、モバイルIP登録要求（タイプ= 1）、およびモバイルIP登録応答（タイプ= 3）と同じ数の空間から取られています。
Registration Revocation Acknowledgment: A new Mobile IP control message, using UDP port 434, type 15. This value has been taken from the same number space as Mobile IP Registration Request (Type = 1), and Mobile IP Registration Reply (Type = 3).
登録取消し確認応答：新しいモバイルIP制御メッセージ、UDPポート434を使用して、タイプ15は、この値は、モバイルIP登録要求（タイプ= 1）と同じ数の空間から採取し、モバイルIP登録応答（タイプ= 3）されています。
The following extensions are introduced by this specification:
次の拡張子はこの仕様で導入されています。
Revocation Support Extension: A new Mobile IP Extension, appended to a Registration Request, or Registration Reply. The value assigned is 137. This extension is derived from the Extension number space. It MUST be in the 'skippable' (128 - 255) range as defined in RFC 3344.
失効サポート拡張：新しいモバイルIP拡張、登録要求、または登録応答に追加。割り当てられた値は、この拡張は、内線番号空間から派生している137です。 RFC 3344で定義されている範囲 - これは「スキップ可能」（255 128）でなければなりません。
There are no new Mobile IP error codes introduced by this document.
このドキュメントで紹介し新たなモバイルIPエラー・コードはありません。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[2] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[2]パーキンス、C.およびP.カルフーン、 "モバイルIPv4チャレンジ/レスポンス拡張機能"、RFC 3012、2000年11月。
[3] Bradner, S., "Key Words for us in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーの、S.、 "要件レベルを示すためのRFCでの私たちのためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[A] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[A]ガラス、S.、ヒラー、T.、ジェイコブス、S.およびC.パーキンス、 "モバイルIP認証、認可、およびアカウンティング要件"、RFC 2977、2000年10月。
[B] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
[B] Aboba、B.、カルフーン、P.、ガラス、S.、ヒラー、T.、マッキャン、P.、椎野、H.、ウォルシュ、P.、ゾルン、G.、Dommety、G.、パーキンス、 C.、パティル、B.、ミットン、D.、マニング、S.、Beadles、M.、チェン、X.、Sivalingham、S.、ハミード、A.、マンソン、M.、ジェイコブス、S.、リム、 B.、ハーシュマン、B.、スー、R.、クー、H.、Lipford、M.、キャンベル、E.、徐、Y.、馬場、S.及びE.・ジャック、「ネットワークのAAAプロトコルを評価するための基準アクセス」、RFC 2989、2000年11月。
[C] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[C]モンテネグロ、G.編、 "モバイルIPのためのリバーストンネリング、改訂版"、RFC 3024、2001年1月。
[D] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[D]デアリング、S.、エド。、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[E] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[E]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
Appendix A: An Example of the Revocation Messages in Use
付録A：使用中の失効メッセージの例
For clarity, the following example is meant to illustrate the use of the new messages in the registration phase, and the revocation phase. In this example, a foreign agent and home agent will negotiate revocation during the registration phase. During the revocation phase, the foreign agent will revoke the binding of a mobile node.
明確にするために、以下の例では、登録フェーズにおける新しいメッセージの使用、および失効相を説明するためのものです。この例では、外国人のエージェントとホームエージェントは、登録フェーズの間に失効をネゴシエートします。失効フェーズ中に、外部エージェントは、移動ノードの結合を取り消します。
A.1. The Registration Phase
A.1。登録フェーズ
Consider a foreign agent that supports registration revocation, and has a security association with a home agent to which it is forwarding a registration request. The foreign agent will include the revocation support extension after the mobile-home authenticator. Assume that the foreign agent supports the use of the 'I' bit, and is willing to let the home agent decide if the mobile node should be informed of the revocation of its registration. Thus, the foreign agent will set the 'I' bit to '1'. The foreign agent will append a foreign-home authenticator to the registration request.
登録の取り消しをサポートしています外国人のエージェントを検討し、それが登録要求を転送されているホームエージェントとのセキュリティアソシエーションを持っています。外国人のエージェントは、モバイル・ホーム認証後に失効サポート拡張が含まれます。外国人のエージェントは「I」ビットの使用をサポートし、モバイルノードは、その登録の取消しの通知をしなければならない場合は、ホームエージェントが決めさせて喜んでであると仮定する。このように、外国人のエージェントは「1」を「I」ビットをセットします。外国人のエージェントは、登録要求に外国ホーム認証を追加します。
Upon receiving the registration request containing a revocation extension, the home agent will include a revocation support extension in the registration reply. Since the foreign agent set the 'I' bit to '1' in its revocation extension, and the home agent supports the use of the 'I' bit, the home agent will set the 'I' bit in its registration extension to '1'. Additionally, the home agent will append a home-foreign authenticator to the registration request.
失効拡張を含む登録要求を受信すると、ホームエージェントは登録応答で失効サポート拡張が含まれます。外国人のエージェントは、その失効拡張の「I」ビットを「1」に設定され、ホームエージェントは、「I」ビットの使用をサポートしているので、ホームエージェントは、1」にその登録延長の「I」ビットをセットします」。また、ホームエージェントは、登録要求に家庭外国オーセンティケータを追加します。
Upon receiving the authenticated registration reply, the foreign agent will check the revocation support extension and note that the home agent wants to decide if the mobile node should be notified in the event this registration is revoked, i.e., since the home agent set the 'I' bit in the return revocation extension.
ホームエージェントは、「私を設定するので、認証登録応答を受信すると、外部エージェントは、失効サポート拡張をチェックし、ホームエージェントは、モバイルノードが、この登録が取り消された場合に通知すべきかどうかを決定するために望んでいることに注意してください、すなわちうリターン失効拡張の「ビット。
A.2. The Revocation Phase
A.2。失効フェーズ
The foreign agent revokes a mobile node's binding, and generates a revocation message to be sent to the mobile node's home agent. Since the 'I' bit was negotiated in the revocation extensions, and the foreign agent is still willing to let the home agent indicate whether this mobile node should be informed about the revocation, it will set the 'I' bit to '1' in the revocation message. The foreign agent also makes sure the 'A' bit is set to '0'.
外国人のエージェントは、モバイルノードのバインディングを取り消し、およびモバイルノードのホームエージェントに送信する失効メッセージを生成します。 「I」ビットが失効拡張で交渉され、外国人のエージェントがまだホームエージェントは、このモバイルノードが取消しについて通知する必要があるかどうかを示す聞かせて喜んでいるされて以来、それは「I」ビットに「1」で設定します失効メッセージ。外国人のエージェントは「」ビットが「0」に設定されているを確認します。
The foreign agent will also place the address of the mobile node whose registration it wishes to revoke in the home address field, the address that the mobile node registered as the care-of address in the foreign domain field, and the address registered as the home agent in the home domain address field. The foreign agent will set the Revocation Identifier to the current 32-bit timestamp, and append the foreign-home authenticator.
外国人のエージェントは登録それはホームアドレス欄に取り消しを希望するモバイルノードのアドレス、モバイルノードが外部ドメインフィールドのアドレスのケア-、および自宅として登録アドレスとして登録されているアドレスを配置しますホームドメインのアドレスフィールドにエージェント。外国人のエージェントは、現在の32ビットのタイムスタンプに失効識別子を設定し、外国ホーム認証を追加します。
Upon receiving the above revocation message, the home agent uses the address identified as the foreign domain address to identify the security association, and authenticate the revocation message. After authenticating the message, the home agent will check to make sure the 'A' bit and Identifier indicate that this revocation is not a replay. The home agent then uses the mobile node home address, foreign domain address, and home domain address to locate the mobile node whose registration is being revoked.
上記の取消メッセージを受信すると、ホームエージェントは、セキュリティアソシエーションを特定し、失効メッセージを認証するために外部ドメインのアドレスとして特定のアドレスを使用しています。メッセージを認証した後、ホームエージェントは、「」ビットと識別子は、この失効がリプレイではないことを示していることを確認するチェックします。ホームエージェントは、その登録取り消されているモバイルノードの位置を特定するために、モバイルノードのホームアドレス、外国ドメインアドレス、およびホームドメインのアドレスを使用しています。
Upon processing a valid registration revocation message, the home agent generates a revocation acknowledgment message. Since the 'I' bit was set to '1' in the revocation message and the home agent wishes for the identified mobile node to be informed of the revocation, it will set the 'I' bit in the revocation acknowledgment to '1'. The home agent then copies the home address and the Revocation Identifier field into the revocation acknowledgement. The home agent protects the revocation acknowledgment with a home-foreign authenticator.
有効な登録取消しメッセージを処理すると、ホームエージェントは、失効確認メッセージを生成します。 「I」ビットが取消しの通知をすることがRevocationメッセージで「1」に設定し、ホームエージェントが識別された移動ノードのために望んでいたので、それが「1」に失効確認に「I」ビットをセットします。ホームエージェントは、コピー失効確認に自宅の住所と失効識別子フィールドを。ホームエージェントは、ホーム外国オーセンティケータで失効確認を保護します。
Upon receiving a valid revocation acknowledgment (in which the authenticator and Identifier fields are acceptable), the foreign agent checks the state of the 'I' bit. Since the 'I' bit is set to '1', the foreign agent will notify the mobile node of the revocation.
有効な失効確認を（オーセンティケータと識別子フィールドが許容されている）を受信すると、外部エージェントは、「I」ビットの状態をチェックします。 「I」ビットが「1」に設定されているので、外部エージェントは、取消しのモバイルノードに通知します。
Appendix B: Disparate Address, and Receiver Considerations
付録B：異種住所、およびレシーバの考慮事項
Since the registration revocation message comes from a source address that is topologically routable from the interface receiving the datagram, the agents, by definition, are topologically connected (if this were not the case, the initial registration mechanism would have failed). If either are the ultimate hop from this topologically connected region to one or more disparate address spaces, no problems are foreseen. In order for the mobile node to have successfully registered with its home agent, it MUST have provided to the network (foreign agent) to which it is currently attached a routable address of its home agent. Conversely, the care-of address being used by the mobile node must also be topologically significant to the home agent in order for the registration reply to have been received, and the tunnel initiated. By definition, then, the home agent address and the care-of address must each be significant, and either address must form a unique pair in the context of this mobile node to both agents.
登録取消メッセージは、定義により、データグラム、薬剤を、受信インタフェースから位相的にルーティング可能なソースアドレスから来ているので、位相的に接続されている（これが当てはまらなかった場合、初期登録メカニズムが失敗しました）。どちらかが1つの以上の異なるアドレス空間に、この位相幾何学的に連結領域から究極のホップであれば、何の問題が予見されていません。正常そのホームエージェントに登録している移動ノードためには、それが現在そのホームエージェントのルーティング可能なアドレスに接続されているネットワーク（フォーリンエージェント）に提供されている必要があります。逆に、気付アドレスは登録応答を受信したとのためにもためにホームエージェントにトポロジー的に有意でなければならないモバイルノードによって使用され、トンネルが開始します。定義によると、その後、ホームエージェントアドレス及び気付アドレスは、各重要である必要があり、どちらかのアドレスは、両方の薬剤には、このモバイルノードのコンテキスト内でユニークなペアを形成しなければなりません。
Another way of understanding this is that the tunnel endpoints are in some way connected, and hence each are unique as far as the other end is concerned. The address at the other end of the tunnel, in combination with the address of the mobile node, must therefore form a unique pair that can be identified by the agent receiving the registration revocation message.
これを理解する別の方法は、トンネルエンドポイントが接続され、いくつかの方法であり、したがって各限り他端が懸念されるように固有であることです。トンネルの他端のアドレスは、モバイルノードのアドレスとの組み合わせで、従って、登録取消メッセージを受信したエージェントによって同定することができるユニークなペアを形成しなければなりません。
As an example, consider a mobile node who's home address lies in disparate address space A behind its home agent. In the following diagram, [*] indicates an interface of the entity in which it appears.
例として、ホームアドレスのモバイルノードがそのホームエージェントの背後にある本質的に異なるアドレス空間Aにあることを検討してください。次の図では、[*]が表示されるエンティティのインタフェースを示しています。
MN[a]-----[c]FA[b]=====((()))=====[b]HA[a]-----[a]CN
Address Some topologically Address
Space C connected network Space A
We presume a binding for MN exists, and hence a tunnel between FA[b] and HA[b] exists. Then, since the address assigned to MN[a] MUST be unique in address space A, the pair {FA[b],MN[a]} is guaranteed to be unique in the binding table of HA, and the pair {HA[b],MN[a]} is guaranteed to be unique in the foreign agent's visitor list.
我々は、[B]が存在するFAとの間のトンネル[B]及びHA MNが存在するために結合、ひいては推定します。その後、MNに割り当てられたアドレスは[A]のアドレス空間A内で一意でなければならないので、一対{FA [B]は、MN [A]} HAのバインディングテーブルに一意であることが保証され、かつ一対{HA [ B]、MNは、[A]}外部エージェントの訪問者リストに一意であることが保証されます。
As a result, a home agent receiving a registration revocation message and foreign-home authenticator for MN[a] from FA[b] is able to determine the unique mobile node address being deregistered. Conversely a foreign agent receiving a registration revocation message and home-foreign authenticator for MN[a] from HA[b] is able to determine the exact mobile node address being deregistered. For this reason, if a foreign agent receives a registration revocation message with the home domain field set to the zero address it MUST be silently discarded. This is to prevent confusion in the case of overlapping private addresses; when multiple mobile nodes are registered via the same care-of address and coincidentally using the same (disparate/private) home address, the home agent address appearing in the home domain field is the only way a foreign agent can discern the difference between these mobile nodes.
FAの結果、MNの登録取消メッセージ及び外国ホーム認証を受けたホームエージェント[A]と[B]が登録解除される一意のモバイルノードのアドレスを決定することができます。反対にHAからMNの登録取消メッセージとホーム外国のオーセンティケータを受ける外部エージェント[A]は[B]登録解除され、正確な移動ノードのアドレスを決定することができます。このため、外国人のエージェントが、それは静かに捨てなければなりませんゼロアドレスに設定ホームドメインフィールドでの登録取消しメッセージを受信した場合。これはプライベートアドレスが重複した場合の混乱を防ぐためです。複数のモバイルノードが同じ気付アドレスを使用して登録し、偶然同じ（プライベート/異種の）ホーム・アドレスを使用している場合は、ホームドメインフィールドに表示されるホーム・エージェント・アドレスは、外国人のエージェントがこれらのモバイルの違いを見分けることができる唯一の方法でありますノード。
Acknowledgments
謝辞
The authors would like to thank Rajesh Bhalla, Kent Leung, and Alpesh Patel for their contributions to the concepts detailed in draft-subbarao-mobileip-resource-00.txt, "Releasing Resources in Mobile IP," from which the revocation support extension, and the acknowledgment mechanism contained in this document were derived.
著者は、「モバイルIPにおけるリソースを解放」、ドラフトsubbarao-モバイルIPリソース-00.txtに詳述された概念に彼らの貢献のためにラジェッシュBhalla、ケントレオン、およびAlpeshパテルに感謝しているから、失効サポート拡張、この文書に含まれる確認応答メカニズムが得られました。
The authors would also like to thank Pete McCann for his discussions on replay mechanisms, and security concerns, and Ahmad Muhanna for pointing out a problem with the initial replay mechanism, which eventually lead to the addition of a time stamp to the Revocation Extension.
著者らはまた、最終的に失効拡張へのタイムスタンプの追加につながる初期再生機構の問題を指摘するためにリプレイ・メカニズム、およびセキュリティ上の懸念、とアフマドMuhannaの彼の議論のためのピートマッキャンに感謝したいと思います。
The authors would also like to acknowledge Henrik Levkowetz for his detailed review of the document, and Michael Thomas for his review of the replay mechanism described herein.
著者はまた、本明細書に記載の再生メカニズムの彼のレビューのために文書の彼の詳細なレビューのためのヘンリクLevkowetz、そしてマイケル・トーマスを認めるしたいと思います。
Authors' Addresses
著者のアドレス
Steven M. Glass Solaris Network Technologies Sun Microsystems 1 Network Drive Burlington, MA. 01801
スティーブンM.グラスSolarisネットワークテクノロジーズSun Microsystemsの1ネットワークドライブバーリントン、MA。 01801
Phone: +1.781.442.0000 Fax: +1.781.442.1706 EMail: steven.glass@sun.com
電話：+1.781.442.0000ファックス：+1.781.442.1706電子メール：steven.glass@sun.com
Madhavi W. Chandra IOS Technologies Division Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709
マダビW.チャンドラIOS技術部門シスコシステムズ7025キットクリーク道路リサーチトライアングルパーク、NC 27709
Phone: +1.919.392.8387 EMail: mchandra@cisco.com
電話：+1.919.392.8387電子メール：mchandra@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。