[要約] RFC 3543は、Mobile IPv4における登録の取り消しに関する要件を定義しています。このRFCの目的は、モバイルノードの登録情報を効果的に取り消すための手順とプロトコルを提供することです。
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
モバイル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.
Copyright（c）The Internet Society（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サービスを提供するモビリティエージェントが、この登録の終了の同じモバイルノードにモバイル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.
1. モバイルIPリソースのタイムリーなリリース。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.
3. モバイルIPバインディングに提供された/必要なサービスに関して、ドメインポリシーの変更の以前の採用。たとえば、ホームドメインには逆トンネル[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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" 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 |
| ... |
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 (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.
エージェント広告拡張機能に「X」ビットを設定する外国人エージェントは、そのリンク、特に取り消しサポート拡張（セクション3.2。）、取り消しメッセージ（セクション3.3。）、および取り消し承認（セクション3.4（セクション3.3。）の登録装備メッセージをサポートする必要があります。）。同じリンクをサポートするすべてのエージェントが登録の取り消しをサポートすることは必須ではなく、エージェントがそのすべてのリンクでこのサポートを宣伝することも必須ではありません。
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 Rococationサポート拡張は、登録の取り消しのサポートを示しているため、取り消しメッセージを受信したいエンティティによる登録リクエストまたは登録返信に添付する必要があります。通常、これは外国人エージェントかホームエージェントのいずれかです。ただし、「直接」の共同配置されたモバイルノードには、登録リクエストに取り消しサポート拡張機能も含まれる場合があります。共同住宅ではないモバイルノードには、登録に取り消しサポート拡張機能を含めてはなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 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.
タイプ137の長さの長さ（現在6）。タイプと長さのフィールドは含まれていません（[1]のセクション1.9。に従って）。これにより、将来的にはより多くのビットが必要な場合、より長い延長長が可能になります。
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.
Mobility Agentまたは「直接」の共同配置されたモバイルノードのTimestame Current 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.)
「私」ビットこのビットは、モビリティエージェントによって「1」に設定されています。
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 Recocation Support拡張機能は、外国在宅認証拡張機能、モバイルホーム認証拡張機能、またはその他の同等のメカニズム[1]によって保護されなければなりません[1]。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」に設定されている外国人エージェントからの取り消し延長に応じて、「i」ビットを「1」に設定するホームエージェントは、未定義であり、行うべきではないことに注意してください。
'I' bit support has been negotiated when both agents have set the 'I' bit to '1' in their revocation support extensions.
「I」ビットサポートは、両方のエージェントが「I」ビットを「I」ビットを「1」にサポート拡張に設定したときに交渉されました。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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.
「I」ビットサポートが登録プロセスで渡された取り消し拡張メッセージで交渉されない限り、このビットを「1」に設定してはなりません。そうしないと、結果は予測不可能です。
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.
「0」に設定して、モバイルノードに取り消しを通知してはならないこと、または「I」ビットの使用が合意されていないためです。
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」に設定して、外国人エージェントがモバイルノードに取り消しを通知する必要があるかどうかについて、または「i」ビットサポートが合意されていないために外部ドメインポリシーを使用していることを示します。
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アドレスをアドレスして、どのバインディングが取り消されているかを特定します。これは、次のいずれかです。（i）外国人エージェントのIPアドレス、または（ii）共同配置されたケアオブアドレス。
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]で指定されたレート制限に取り消しメッセージを含めることにより[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...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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.
「i」ビットは、取り消しメッセージで「1」に設定されていない限り、取り消し承認メッセージで「1」に設定する必要はありません。エージェントが「I」ビットが「1」に設定されているが、承認されている 『I 'ビットが「0」に設定されている「I」ビットが「i」ビットが取り消しに設定されている撤回承認メッセージを受信した場合謝辞メッセージは無視する必要があります。
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:
リプレイ保護は、ホームアドレスフィールドと併せて、登録撤回メッセージに単一の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.
- 取り消しエージェントは、エージェントタイプに「A」ビットを設定し、登録識別子フィールドを登録識別子フィールドを、同じ時計から有効な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.
- 認証された取り消しメッセージを受信すると、受信エージェント（または「ダイレクト」コロケティングモバイルノード）は、「a」ビットの値と取り消し識別子をチェックして、この失効メッセージが古い取り消しのリプレイではないことを確認する必要があります。同じエージェントから受信したメッセージ。また、受信エージェントは、メッセージが特定されたバインディングに関連して送信した取り消しメッセージの反映ではないことを確認する必要があります。「a」ビットと識別子フィールドがこのパケットがリプレイであることを暗示する場合、取り消しメッセージは静かに破棄する必要があります。
- 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.
注：モバイルノードが異なるホームエージェントと異なる時間に登録し、異なる外国人エージェントとの異なる時期に登録することは可能であるため、識別子フィールドが異なるエージェントからのメッセージで一意であることは必須ではないことが重要です。さまざまなエージェントの時計が同期されるという保証ではありません。たとえば、モバイルノードに複数の外国人エージェントと同時にバインディングがあり、「同時に」そのような外国人エージェントが複数の「同時に」受信された場合、これらの外国人エージェントからの取り消しメッセージには、発生する識別子フィールドが含まれる可能性があります。他の外国人エージェントのいずれかまたはすべてのものを一致させる。これにより、これらの取り消しメッセージのいずれかが無視されてはなりません。
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つの異なる部分で構成されています。「ダイレクト」共同配置されたモバイルノードは、ホームエージェントから取り消しメッセージを受信して応答するために取り消し拡張と取り消し承認を実装する場合がありますが、「直接」の共同配置されたモバイルノードは、削除メッセージをde-として送信してはなりません。[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.
このメカニズムを活用して、外国人エージェントは、エージェント自体がリセットされていなくても、次のシーケンス番号を設定するだけで、エージェント自体がリセットされていなくても、すべてのバインディングを「リセット」していることを現在拘束されているすべてのモバイルノードに意識的に通知する場合があります。エージェントの広告。さらに、外国人エージェントは、広告の「B」ビットを1に同時に設定することにより、現在バインドされているすべてのモバイルノードに、別の外国人エージェントと再登録する必要があることを通知する場合があります。新しい登録を受け入れていません[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に設定されたシーケンス番号を使用してエージェント広告をユニカストする場合があります。さらに、そのような外国人エージェントがモバイルノードにそのバインディングが取り消され、モバイルノードが登録を更新しようとしないことをモバイルノードに示したい場合、外国人エージェントは「B」ビットを1インチに設定することもできます。これらのエージェント広告は、それが忙しく、新しい登録を受け入れていないことを示しています[1]。[1]に準拠したすべてのモバイルノードは、これがエージェントが忙しいことを意味することを理解し、すぐに外国人エージェントキャッシュの別のエージェントと再登録しようとするか、追加のエージェントを求めることができます。後者の場合、外国人エージェントはオプションでモバイルノードのバインディングが取り消されたことを覚えていて、同じように勧誘に応答します。つまり、「B」ビットが1に設定されています。エージェントは、放送されたエージェント広告（リンク全体に送信される）で「B」ビットを1に1に設定しない可能性があります。このエージェントのマルチキャストエージェント広告を「B」ビットセットなしで聞いたときに、モバイルノードが取り消されたモバイルノードは、[re]登録します。これが発生した場合、外国ドメインポリシーに応じて、外国のエージェントは、適切なエラーコード（「管理上禁止」など）でモバイルノードを単純に拒否できます。この時点で、モバイルノードは、[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.
現在、リンクで登録の取り消しをサポートしている外国人エージェントは、そのリンクに送信されるエージェント広告拡張機能に「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に設定されている登録要求に添付された取り消し延長を送信することにより、外国人エージェントはホームエージェントに、登録が終了したことをこのモバイルノードに通知する決定を残す可能性があることを示していますホームエージェントまで。（「5月」という用語は、登録の存続期間中にドメインポリシーが変更される可能性があることが認識されるため、ここで使用されます）。ホームエージェントは、「I」ビットを1に設定することでこれを行うことを希望することを認めることができます。または、登録返信に表示される取り消し拡張機能で、「I」ビットを0に設定してもそうしないことを示すことができます。
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.
ホームエージェントとして、「A」ビットを「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」ビットの使用が登録プロセスで交渉された場合、ホームエージェントが外国人エージェントに「I」ビットを1に設定する必要があります。取り消しのモバイルノードに通知します。逆に、ホームエージェントがモバイルノードに通知を望まない場合、「I」ビットを0に設定する必要があります。ホームエージェントは、モバイルノードが登録されていることを知っているため、「I」ビットを「0」に設定できることに注意してください。異なる外国のエージェントがあるので、外国人が通知を試みる必要はありません。
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).
- ホームエージェントが取り消しメッセージを再送信しようとするたびに、取り消し識別子のタイムスタンプの値を、この外国人エージェントに送信された取り消し拡張でタイムスタンプを生成するために使用される同じ時計からの現在の値で更新する必要があります。これは、撤回識別子を使用して導出されたフィールドを必然的に更新することを意味することに注意してください（たとえば、家庭外認証器など）。
- the home agent MUST NOT send more than one revocation per second for a particular binding,
- ホームエージェントは、特定のバインディングのために1秒あたり1秒以上の取り消しを送信してはなりません。
- the time between retransmissions SHOULD fall-back in analogy with the registration guidelines in [1], namely exponential backoff, and
- 再送信の間の時間は、[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で定義されているように、認証器、「A」ビット、および識別子フィールドがリプレイに対する識別子フィールドを確認する必要があります。また、外国人エージェントは、ホームエージェントによって記述されたバインディングを、取り消しメッセージの情報、つまりモバイルノードアドレス、外部ドメインアドレス、ホームドメインアドレス、およびタイムスタンプで識別するアドレスを使用してリリースされていると特定する必要があります。取り消しメッセージ、および最後に受け入れられた登録メッセージのタイムスタンプ。取り消しは既存の登録に対してのみ有効であるため、登録のタイムスタンプは取り消しメッセージの前になければなりません（これらのタイムスタンプは両方とも同じホームエージェントによって設定されたことに注意してください）。バインディングを見つけると、外国人エージェントはそれを取り消さなければならず、取り消しメッセージのソースアドレスに送信された取り消し承認で応答する必要があります。「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で説明されている方法でモバイルノードに通知する場合、外国人エージェントは、「I」ビットを取り消し承認で「i」ビットをホームエージェントに送信するか、モバイルノードに通知しない場合、外国人に通知する必要があります。エージェントは「I」ビットを「0」に設定する必要があります。
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ソースアドレスに送信する必要があるRecocation Auncementメッセージを生成する必要があります。モバイルノードは、このホームエージェントに使用している逆トンネルのカプセル化[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」に「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.
取り消しメッセージがこのバインディングを提供する外国人エージェントから来ていることを示すために、「A」ビットを「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,
- 特定のバインディングのために1秒あたり複数の失効を送ってはなりません。
- SHOULD set its retransmissions to fall-back in analogy with the registration guidelines in [1], namely exponential backoff, and
- [1]の登録ガイドライン、すなわち指数関数的なバックオフとの類似性で再送信を設定する必要があります。
- 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.
登録の取り消しメッセージを受信すると、ホームエージェントは「A」ビットと識別子フィールドと認証者を確認する必要があります。パケットが許容される場合、ホームエージェントは、外国人エージェントによって識別されたバインディングを、取り消しメッセージの情報、つまりホームアドレス、外国ドメインアドレス、およびホームドメインアドレスフィールドによって識別されるアドレスを使用してリリースされていると特定する必要があります。取消しは既存の登録に対してのみ有効であるため、登録のタイムスタンプは取り消しメッセージの前に行わなければなりません（これらのタイムスタンプは両方とも同じ外国人エージェントによって設定されたことに注意してください）。このバインディングはもはやアクティブではないため、ホームエージェントは以前のバインディングに関連するリソースを解放し、すべてのモバイル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」ビットを取り消し承認メッセージに設定する必要があります。モバイルノードが通知されたくない場合は、「I」ビットを「0」に設定する必要があります。
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.
登録プロセスで使用されるいくつかのBITは、取り消しメカニズムを使用する際に特別な考慮事項が必要です。
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ソースアドレスが実際にモバイルノードにサービスを提供する外国人エージェントのアドレスであることを保証する方法がないため、このIPソースアドレスからの取り消しメッセージを受け入れると、男性によるサービス拒否攻撃につながる可能性があります。 - モバイルノード上の中で。
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.
2つの潜在的な脆弱性があります。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など）には、このようなルーター広告を確保するための作業がありましたが、この出版物の時点では、一般的な慣行はありませんでした。ここで可能なサービス拒否の問題を回避するために、中断の可能性を最小限に抑えるために、モバイルノードの実装者は、[1]、特にTTLが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サービスを終了しますが、モビリティエージェントが他のエージェントが拘束力を取り消したと考える前に、すべてのセキュリティとリプレイの保護メカニズムを検証することが重要です。Link-Local（モバイルノードと外部エージェントなど）が送信されるメッセージは、[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".
とはいえ、家と外国人のエージェントとの間の中間の男によって「飛行中」にキャプチャされたメッセージを使用するアクティブな攻撃には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".
「悪意のあるリピーター」の場合、中間者が取り消しメッセージをキャプチャし、後で同じ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 protection, the sender of the packet will also believe the revocation message to be authentic.
「悪意のあるリフレクター」の場合、中間者が取り消しメッセージをキャプチャし、その後、後でオリジネーターに戻します。ホームドメインと外国のドメイン間のセキュリティ協会が、パケットのUDP部分の内容のみを保護する（単一の）共有秘密を含むセキュリティ協会を使用している場合（[1]、[1]で定義されたホームフレイン認証機など）、リプレイ保護なしで、パケットの送信者は、取り消しメッセージが本物であるとも信じています。
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).
登録の取り消し：UDPポート434、タイプ7を使用した新しいモバイルIPコントロールメッセージ。この値は、モバイルIP登録リクエスト（Type = 1）、およびモバイルIP登録返信（Type = 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).
登録の取り消し承認：UDPポート434、タイプ15を使用した新しいモバイルIPコントロールメッセージ。この値は、モバイルIP登録要求（Type = 1）、およびモバイルIP登録返信（Type = 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で定義されているように、「スキップ可能」（128-255）範囲にある必要があります。
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] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[2] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[2] Perkins、C。およびP. Calhoun、「モバイル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] Bradner、S。、「RFCSの私たちの要件レベルを示すためのキーワード」、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] Glass、S.、Hiller、T.、Jacobs、S。and C. Perkins、「モバイル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.、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。、およびE. Jaques、「ネットワークのAAAプロトコルを評価するための基準アクセス」、RFC 2989、2000年11月。
[C] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[C] Montenegro、G.、ed。、「モバイルIPの逆トンネル、改訂」、RFC 3024、2001年1月。
[D] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[D] Deering、S.、ed。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[E] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[E] Calhoun、P。およびC. Perkins、「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.
明確にするために、次の例は、登録段階での新しいメッセージの使用と取り消しフェーズを説明するためのものです。この例では、外国人エージェントとホームエージェントが登録段階で失効を交渉します。取り消し段階では、外国人エージェントはモバイルノードのバインディングを取り消します。
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」ビットの使用をサポートし、ホームエージェントにモバイルノードに登録の取り消しを通知するかどうかを喜んで決定させると仮定します。したがって、外国人エージェントは「I」ビットを「1」に設定します。外国人エージェントは、登録要求に外国家の認証者を追加します。
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」ビットの使用をサポートするため、ホームエージェントは登録延長で「I」ビットを '1に設定します。'。さらに、ホームエージェントは、登録リクエストにホームフレイン認証者を追加します。
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.
認証された登録返信を受信すると、外国人エージェントは取り消しサポート拡張機能を確認し、ホームエージェントがこの登録が取り消された場合、つまりホームエージェントが「i」を設定するため、モバイルノードに通知するかどうかを決定する必要があることに注意してください。'return itcocation Extensionのビット。
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」に設定します取り消しメッセージ。また、外国人エージェントは、「A」ビットが「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.
上記の取り消しメッセージを受信すると、ホームエージェントは外国ドメインアドレスとして識別されたアドレスを使用してセキュリティ協会を識別し、取り消しメッセージを認証します。メッセージを認証した後、ホームエージェントは「A」ビットと識別子がこの取り消しがリプレイではないことを確認することを確認します。ホームエージェントは、モバイルノードホームアドレス、外国ドメインアドレス、およびホームドメインアドレスを使用して、登録が取り消されているモバイルノードを見つけます。
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」ビットは取り消しメッセージで「1」に設定されており、ホームエージェントは識別されたモバイルノードに取り消しを通知することを望んでいるため、「I」ビットを取り消し承認で「1」に設定します。ホームエージェントは、ホームアドレスと取り消し識別子フィールドを取り消し承認にコピーします。ホームエージェントは、Home-Deforegin Authenticatorによる取り消し承認を保護します。
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.
例として、自宅の住所が異なる住所空間にあるモバイルノードを考えてみてください。次の図では、[*]が表示されるエンティティのインターフェイスを示します。
MN[a]-----[c]FA[b]=====((()))=====[b]HA[a]-----[a]CN
Address Some topologically Address Space C connected network Space A
いくつかのトポロジカルに対処するスペースC接続されたネットワークスペース
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.
Mnの結合が存在すると仮定しているため、Fa [B]とHa [B]の間にトンネルが存在すると推測されます。次に、mn [a]に割り当てられたアドレスはアドレス空間Aで一意でなければならないため、ペア{fa [b]、mn [a]}はhaの結合表で一意であることが保証され、ペア{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 [b]からMN [A]の登録取り消しメッセージと外国在宅認証者を受け取るホームエージェントは、登録されている一意のモバイルノードアドレスを決定できます。逆に、HA [B]からMN [A]の登録装備メッセージを受け取っている外国人エージェントと、登録されている正確なモバイルノードアドレスを決定することができます。このため、外国人エージェントがゼロアドレスに設定されたホームドメインフィールドを使用して登録撤回メッセージを受信した場合、静かに破棄する必要があります。これは、私的住所が重複する場合の混乱を防ぐためです。複数のモバイルノードが同じアドレスを介して登録され、偶然にも同じ（異なる/プライベート）ホームアドレスを使用して偶然に登録されている場合、ホームドメインフィールドに表示されるホームエージェントアドレスは、外国人エージェントがこれらのモバイル間の違いを識別できる唯一の方法ですノード。
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.
著者は、Rajesh Bhalla、Kent Leung、およびAlpesh Patelに、Subbarao-Mobileip-Resource-00.txtのドラフトで詳述されている概念への貢献について、「モバイルIPのリソースをリリースする」という概念に感謝します。また、このドキュメントに含まれる承認メカニズムが導き出されました。
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.
著者はまた、リプレイメカニズムとセキュリティ上の懸念に関する彼の議論について、ピート・マッキャンと、初期リプレイメカニズムの問題を指摘してくれたアフマド・ムハンナにも感謝したいと思います。
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.
著者はまた、本書に記載されているリプレイメカニズムのレビューについては、ドキュメントの詳細なレビューについてヘンリック・レフコウェッツを認めたいと考えています。
Authors' Addresses
著者のアドレス
Steven M. Glass Solaris Network Technologies Sun Microsystems 1 Network Drive Burlington, MA. 01801
Steven M. Glass Solaris Network Technologies Sun Microsystems 1ネットワークドライブバーリントン、マサチューセッツ州。01801
Phone: +1.781.442.0000
Fax: +1.781.442.1706
EMail: steven.glass@sun.com
Madhavi W. Chandra IOS Technologies Division Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709
Madhavi W. Chandra IOS Technologies Division Cisco Systems 7025 Kit Creek Road Research Triangle Park、NC 27709
Phone: +1.919.392.8387
EMail: mchandra@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。