RFC3543 日本語訳
3543 Registration Revocation in Mobile IPv4. S. Glass, M. Chandra. August 2003. (Format: TXT=81805 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Glass
Request for Comments: 3543 Sun Microsystems
Category: Standards Track M. Chandra
Cisco Systems
August 2003
コメントを求めるワーキンググループS.ガラス要求をネットワークでつないでください: 3543年のサン・マイクロシステムズカテゴリ: 標準化過程M.チャンドラシスコシステムズ2003年8月
Registration Revocation in Mobile IPv4
モバイルIPv4の登録取消し
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding.
このドキュメントは可動のノードに対するモバイルIPサービスを提供するのにかかわる移動性エージェントがこの登録の終了の同じ可動のノードに対するモバイルIPサービスを提供するもう片方の移動性エージェントに通知できるモバイルIPv4 Registration Revocationメカニズムを定義します。 また、メカニズムもまた、結合の終了の共同見つけられた可動のノードに通知する家のエージェントは使用可能です。 そのうえ、メカニズムは、承認されるためにこの通知に備えます。 モバイル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
1. 序論と適用性. . . . . . . . . . . . . . . . 2 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 登録取消し拡大とメッセージ。 . . . . . . . 4 3.1. 登録取消しサポートの広告を出します。 . . . . . . 5 3.2. 取消しサポート拡大. . . . . . . . . . . . . . 6 3.3。 登録取消しメッセージ。 . . . . . . . . . . . . 8 3.4. 登録取消し承認メッセージ. . . . . 11 3.5。 保護を再演してください。 . . . . . . . . . . . . . . . . . . . 14 4. 登録取消し概観. . . . . . . . . . . . . . . 15 4.1。 モバイルノード通知. . . . . . . . . . . . . . . . 15 4.2。 登録取消しメカニズム--エージェント通知. 17 4.2.1。 取消しサポート. . . . . . . . . 17を交渉します。
Glass & Chandra Standards Track [Page 1] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[1ページ]RFC3543登録取消し
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
4.2.2. 登録を取り消すホームドメイン。 . . . . . . 19 4.2.2.1. ホームエージェント責任。 . . . . . 19 4.2.2.2. 外国エージェント責任. . . . 20 4.2.2.3。 ''共同見つけられたモバイルノード責任. . . . . . . . . . . 20 4.2.3を指示してください。 .1に登録. . . . . 21 4.2.3を取り消す外国ドメイン 外国エージェント責任. . . . 21 4.2.3.2。 ホームエージェント責任。 . . . . . 22 4.2.4. モバイルノードDeregisteringは登録. . . . 23 4.3です。 取消しにおけるモバイルIP登録ビットは処理されます。 . 23 4.3.1. 使用. . . . . . . . . . . . . . . 23 4.3で噛み付かれた'R'.2。 Use(可動のノードの共同場所を見つける).235における'D'Bit。 エラーコード。 . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 24 6.1. エージェント広告. . . . . . . . . . . . . . . . . . 24 6.2。 取消しメッセージ。 . . . . . . . . . . . . . . . . . . 25 7. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 27 7.1. 新しいメッセージタイプ。 . . . . . . . . . . . . . . . . . . . 27 7.2. 新しい拡張子は.277.3を評価します。 新しいエラーコード。 . . . . . . . . . . . . . . . . . . . . 27 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1。 標準(数字の参照)の.278.2。 情報です(アルファベット順参照)。 . . . . . . . . 28 新しさに関する例が使用中に通信させる付録A。 . . . . . . . . 29 A.1。 登録フェーズ. . . . . . . . . . . . . 29A.2。 取消しのフェーズ. . . . . . . . . . . . . . 29付録Bの異種のアドレス、および受信機問題. . . . 30承認。 . . . . . . . . . . . . . . . . . . . . . . . . . 32人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 32の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 33
1. Introduction and Applicability
1. 序論と適用性
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で、移動性結合の終了について別の移動性エージェント(または、共同見つけられた可動の'ダイレクトな'ノード)に通知できます)。 もう取消し通知を受け取らない移動性エージェントは登録が取り消された可動のノードに対するサービスを提供しなければなりません。 モバイルIPv4プロトコル[1]によって既に定義されたシグナル伝達機構は結合の取消しの可動のノードを知らせる方法として投機されています。
Glass & Chandra Standards Track [Page 2] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[2ページ]RFC3543登録取消し
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]で説明された方法を置き換えません、これらのメカニズムの目的が基本的に異なっているとき。 Deregistrationメッセージは可動のノードによって使用されて、例えば移動している後部を家のサブネットに持っていることを家のエージェントに知らせますが、取消しメッセージは、移動性結合の終了に合図するのに移動性エージェントの間で使用されます。 より明確に、ここで定義された取消しメッセージは反登録メッセージが既にこのために十分であるときに彼らの登録を終えている共同見つけられた可動の'ダイレクトな'ノードによる使用のためのそうではありません。 しかしながら、共同見つけられた可動の'ダイレクトな'ノードは、家のドメインから必要にサービスの再交渉の引き金となるのが、役に立つメカニズムであるので、取消しメッセージを処理したがっているかもしれません。
Glass & Chandra Standards Track [Page 3] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[3ページ]RFC3543登録取消し
2. Terminology
2. 用語
It is assumed that the reader is familiar with the terminology used in [1]. In addition, the following terms are defined:
読者が[1]で使用される用語に詳しいと思われます。 さらに、次の用語は定義されます:
'Direct' Co-located Mobile Node
共同見つけられたモバイル'ダイレクトな'ノード
A mobile node registering directly with its home agent, with the
'D' bit set in its registration request, and NOT registering
through a foreign agent.
直接'D'ビットをもっている家のエージェントとともに記名する可動のノードは登録ではなく、外国人のエージェントを通したその登録要求にセットしました。
Mobile IP Resources
モバイルIPリソース
Various functional elements allocated by a mobility agent to
support a Mobile IP binding, e.g., memory.
モバイルIP結合、例えばメモリを支持するために移動性エージェントによって割り当てられた様々な機能要素。
Mobile IP Services
モバイルIPサービス
Various responsibilities of a mobility agent in supporting a
mobile node as defined in [1], e.g., encapsulation of packets
addressed to a mobile node by a home agent, decapsulation of these
packets by a foreign agent for delivery to a mobile node, etc.
[1]、例えば、家のエージェントによる可動のノードに記述されたパケットのカプセル化可動のノードへの配送などのための外国人のエージェントによるこれらのパケットの被膜剥離術で定義されるように可動のノードをサポートすることにおける移動性エージェントの様々な責任
Mobility Agent
移動性エージェント
The home agent or foreign agent as specified in [1].
指定されるとしての[1]の家のエージェントか外国人のエージェント。
Revocation
取消し
Premature termination of a mobility binding.
移動性結合の未完熟終了。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[3])で説明されるように本書では解釈されることであるべきです。
3. Registration Revocation Extensions and Messages
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 エージェントが彼らの取消しメッセージのサポートの広告を出すように、エージェントAdvertisement拡張子での旗は予約されました。
Glass & Chandra Standards Track [Page 4] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[4ページ]RFC3543登録取消し
- 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でカバーされています。
3.1. Advertising Registration Revocation Support
3.1. 広告登録取消しサポート
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]で説明されたMobilityエージェントAdvertisement拡張子への変更で彼らの登録取消しのサポートの広告を出すことができます。 エージェントのRegistration Revocationのサポートを示すために'X'ビットを導入します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T|U|X| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 登録生涯|R|B|H|F|M|G|r|T|U|X| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上、Care、-、Addresses| | ... |
X The mobility agent supports Registration Revocation
移動性エージェントのXはRegistration Revocationを支持します。
A foreign agent that sets the 'X' bit in an agent advertisement extension MUST support registration revocation messages on that link, specifically the Revocation Support Extension (section 3.2.), Revocation Messages (section 3.3.), and Revocation Acknowledgment
'X'ビットをエージェント広告拡大にはめ込む外国人のエージェントは明確にそのリンク、Revocation Support Extension(セクション3.2)、Revocation Messages(セクション3.3)、およびRevocation Acknowledgmentに関する登録取消しメッセージを支持しなければなりません。
Glass & Chandra Standards Track [Page 5] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[5ページ]RFC3543登録取消し
(section 3.4.). It is not required that all agents advertising on the same link support registration revocation, nor is it required that an agent advertise this support on all of its links.
(セクション3.4。) 同じリンクにおけるすべてのエージェント広告が登録取消しを支持するのが必要ではありません、または、エージェントがリンクのすべてにこのサポートの広告を出すのが必要ですか?
Note that using this information, a mobile node can select a foreign agent that supports Registration Revocation. Should a mobile node not understand this bit, it simply ignores it as per [1].
この情報を使用して、可動のノードがRegistration Revocationを支持する外国人のエージェントを選ぶことができることに注意してください。 それは、可動のノードがこのビットを理解しているはずがないのを単に[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'ビットの使用がエージェント広告で他のメッセージに変化も少し与えない例えば、Challenge-応答[2]などのように。
3.2. Revocation Support Extension
3.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取消しサポート拡大を登録要求か登録回答に付けなければなりません。 通常、これは、外国人のエージェントか家のエージェントのどちらかです。 しかしながら、また、共同見つけられた可動の'ダイレクトな'ノードは登録要求における取消しサポート拡大を含むかもしれません。 共同見つけられていない可動のノードは登録にRevocation Support Extensionを含んではいけません。
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'ビットの広告を出す外国人のエージェントは取消しサポート拡大を転送された登録要求に付けなければなりません。 取消し拡大SHOULD NOTを含まない登録要求を受け取る家のエージェントは関連登録回答における取消しサポート拡大を入れます。
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]で与えられているType長さ価値のExtension Formatに基づいていて、以下の通り定義されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | タイプ| 長さ|I| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 137
137をタイプしてください。
Glass & Chandra Standards Track [Page 6] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[6ページ]RFC3543登録取消し
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.
長さのLength(現在のバイトで表現される6)。 NOTはTypeとLength分野を含んでいます。(セクション1.9の[1])によると。 より多くのビットが将来必要であるなら、これは、より長い拡大の長さを考慮します。
Timestamp
Current 4-byte timestamp of the mobility agent or
'direct' co-located mobile node. This is used to
identify the ordering of registrations as they are
forwarded, how they relate to the sending of any
revocation messages, and to identify the approximate
offset between the clocks of the mobility agents
providing support for this binding, or between a 'direct'
co-located mobile node and its home agent.
移動性エージェントか共同見つけられた可動の'ダイレクトな'ノードのタイムスタンプの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'に'I'Bit Thisビットが、'私'の取消しメッセージで噛み付かれた使用を支持するのを示すように設定されます。(セクション3.3。)
When sent by a foreign agent in a registration request:
登録で外国人のエージェントによって送られたら、以下を要求してください。
If set to 1, the FA is willing to have the home agent use
the 'I' bit in the revocation process to determine
whether the mobile node should be informed of the
revocation or not.
1に設定されるなら、FAは、家のエージェントに可動のノードは取消しにおいて知識があるべきであるかどうか決定するのに取消しの過程で'私'ビットを使用させても構わないと思っています。
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':
どの'私'での取消し拡大に対応して家のエージェントによって送られるかと、ビットは'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に設定されるなら、家のエージェントは、可動のノードは知識があるべきであるかどうかを外国人のエージェントに示すのに取消しの過程で'私'ビットを使用するのに同意します。
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に設定されると、家のエージェントは、取消しの過程で噛み付かれて、その結果、可動のノードを知らせることに関して外国人のエージェントのデフォルトの振舞いに屈しながら、'私'を使用しないでしょう。
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で説明されるように取消しの可動のノードを知らせることです。
Glass & Chandra Standards Track [Page 7] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[7ページ]RFC3543登録取消し
Reserved
Reserved for future use. MUST be set to 0 on sending,
MUST be ignored on receiving.
今後の使用のための予約されたReserved。 発信での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.
登録要求、または登録回答に現れるとき、外国家の認証拡大、移動住宅認証拡大、またはいかなる他の同等なメカニズム[1]でもモバイルIP取消しサポート拡大を保護しなければなりません、例えば、AAAの[A]、[B]、または恐らくIPsecを通して。 拡大であるなら、これらの登録メッセージのどちらかに現れるのは保護されません、[1]によって説明される適切な行動(セクション3.8 .2.1セクション3.7 .3 .1。) 取らなければなりません。
Support of the 'I' bit is OPTIONAL. If a mobility agent does not support the specified functionality, it MUST set the 'I' bit to zero. Note that the home agent setting the 'I' bit to '1' in response to a revocation extension from the foreign agent in which the 'I' bit was set to '0' is undefined, and SHOULD NOT be done.
'私'ビットのサポートはOPTIONALです。 移動性エージェントが指定された機能性を支持しないなら、それは'私'ビットをゼロに設定しなければなりません。 '私'ビットが'0'へのセットが未定義であるということであった外国人のエージェントからの取消し拡大に対応して'私'ビットを'1'に設定する家のエージェント、およびSHOULD NOTが完了していることに注意してください。
'I' bit support has been negotiated when both agents have set the 'I' bit to '1' in their revocation support extensions.
両方のエージェントが彼らの取消しサポート拡大で'I'ビットを'1'に設定したとき、'I'噛み付いているサポートは交渉されました。
It is important to note that this extension is skippable (i.e., if the receiving mobility agent does not understand this extension, it MUST skip it, and continue processing the remainder of the registration request).
この拡大がskippableであることに注意するのは重要です(すなわち、受信移動性エージェントがこの拡大を理解していないなら、それは、それをスキップして、登録要求の残りを処理し続けなければなりません)。
3.3. Registration Revocation Messages
3.3. 登録取消しメッセージ
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).
ソースAddress In、登録取消し、ともに記名されたアドレスを発行する家のエージェントのケース、注意、-、家のエージェント(すなわち、アドレスは、このホームアドレスが拘束力があると認識した)のものとしてのアドレス。
In the case of the foreign agent issuing the
registration revocation, the address
registered with the home agent as the care-of
address.
登録取消しを発行する外国人のエージェントの場合では、アドレスが家のエージェントとともに記名した、注意、-、アドレス
Glass & Chandra Standards Track [Page 8] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[8ページ]RFC3543登録取消し
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.
目的地Address Inは登録取消しを発行する家のエージェントのケース、この結合(すなわち、この結合のために成功を示す最後の登録回答の送付先アドレス)を求める最後に承認された登録要求のソースアドレスです。
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
ソースPort変数
Destination Port 434
仕向港434
The UDP header is followed by the Mobile IP fields shown below:
以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |A|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revocation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
| Authenticator...
+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。|A|I| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームドメインアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 外国ドメインアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 取消し識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-+-+-+-+-+- | 固有識別文字… +-+-+-+-+-+-+-+-+-+-+-+-+-
Type 7
7をタイプしてください。
Reserved MUST be sent as 0, ignored when received.
予約されて、受け取ると無視する0として送らなければなりません。
A Agent bit ('direction' bit).
エージェントは('指示'ビット)に噛み付きました。
This bit identifies the role of the agent sending the
revocation, that is the 'direction' of the revocation
message. This is useful for detecting reflection
このビットはすなわち、取消しを送るエージェントの役割、取消しメッセージの'指示'を特定します。 これは反射を検出することの役に立ちます。
Glass & Chandra Standards Track [Page 9] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[9ページ]RFC3543登録取消し
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.
I Informは噛み付きました。
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.
このビットが'私'がサポートに噛み付かなかったなら'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'への可動のノードSHOULD NOTが取消しについて知らされたか、または'私'の使用に噛み付いたからであるセットは同意されませんでした。
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'.
共同位置している可動の'ダイレクトな'ノードと、このビットが本質的には無関係であるという取消しメッセージ、しかし、SHOULDを送る、'1'に設定されてください。
When sent by the foreign agent:
外国人のエージェントによって送られると:
Set to '0' to indicate that the foreign agent is using
foreign domain policy as to whether or not the mobile
node should be informed of the revocation, or because 'I'
bit support was not agreed upon.
'0'にセットして、可動のノードは取消しにおいて知識があるべきであるかどうかに関して外国人のエージェントが外国ドメイン方針を使用しているか、または'私'が噛み付いたのでサポートが同意されなかったのを示してください。
Set to '1' to ask the home agent if the mobile node
should be informed of the revocation.
'1'にセットして、可動のノードは取消しにおいて知識があるべきであるかどうか家のエージェントに尋ねてください。
Reserved
MUST be sent as 0, ignored when received.
予約されて、受け取ると無視する0として送らなければなりません。
Home Address
The home IP address of the mobile node whose registration
is being revoked.
家のIPが記述する登録が取り消されている可動のノードのホームAddress。
Glass & Chandra Standards Track [Page 10] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[10ページ]RFC3543登録取消し
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の外国Domain Addressは、どの結合が取り消されているかを特定するために外国にドメインを記述します。 これは以下の1つです: (i) 外国人のエージェントIPアドレス、または(ii)が共同見つけることにされるのである、注意、-、アドレス。
Home Domain Address
The IP address of the home agent to identify which
binding is being revoked.
IPが記述するどの結合を特定するか家のエージェントのホームDomain Addressは取り消されています。
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.
反射攻撃に対する取消しIdentifier Protects。 取消しのエージェントはそれと同じ時計を追い出すと取消し拡大でタイムスタンプに記入するのに使用されている現在の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]をアップデートして、すなわち、エージェントが同じ結合のために1秒あたり1つ以上の登録メッセージを送ってはいけないことに注意してください。
An example of the use of revocation messages is given in Appendix A.
取消しメッセージの使用に関する例はAppendix Aで出されます。
3.4. Registration Revocation Acknowledgment Message
3.4. 登録取消し承認メッセージ
A revocation acknowledgment message is sent by mobility agents or 'direct' co-located mobile nodes to indicate the successful receipt of a revocation message.
移動性エージェントか共同見つけられた可動の'ダイレクトな'ノードで取消し承認メッセージを送って、取消しメッセージのうまくいっている領収書を示します。
Glass & Chandra Standards Track [Page 11] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[11ページ]RFC3543登録取消し
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.
この登録取消し承認メッセージが発生している受信された登録取消しメッセージの送付先アドレスからのソースAddress Copied。
Destination Address Copied from the source address of the
received registration revocation message for
which this registration revocation
acknowledgment message is being generated.
この登録取消し承認メッセージが発生している受信された登録取消しメッセージのソースアドレスからの目的地Address Copied。
UDP fields:
UDP分野:
Source Port 434 (copied from the destination port of the
revocation message).
ソースPort434(取消しメッセージの仕向港から、コピーされます)。
Destination Port Copied from the source port of the revocation
message.
取消しメッセージのソース港からの目的地Port Copied。
The UDP header is followed by the Mobile IP fields shown below:
以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revocation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
| Authenticator...
+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。|I| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 取消し識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-+-+-+-+-+- | 固有識別文字… +-+-+-+-+-+-+-+-+-+-+-+-+-
Type 15
15をタイプしてください。
Reserved
MUST be sent as 0, ignored when received.
予約されて、受け取ると無視する0として送らなければなりません。
I Inform bit.
I Informは噛み付きました。
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
それが取消しメッセージの'1'に設定されなかったなら、取消し承認メッセージの'1'に'私'ビットを設定してはいけません。 エージェントが'I'ビットが'1'に設定されますが、取消しが存在を通信させる取消し承認メッセージを受け取るなら
Glass & Chandra Standards Track [Page 12] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[12ページ]RFC3543登録取消し
acknowledged had the 'I' bit set to '0', the 'I' bit in
the revocation acknowledgment message MUST be ignored.
'私'ビットが'0'にセットしたなら承認されて、取消し承認メッセージの'私'ビットを無視しなければなりません。
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.
ホームアドレスがこの承認が送られる取消しメッセージを回避したホームAddress。
Revocation Identifier
Copied from the Revocation Identifier of the revocation
message for which this acknowledgment is being sent. See
Section 3.5.
この承認が送られる取消しメッセージのRevocation Identifierからの取消しIdentifier Copied。 セクション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)は同意しなければなりません。
Glass & Chandra Standards Track [Page 13] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[13ページ]RFC3543登録取消し
An example of the use of Revocation Acknowledgment Messages is given in Appendix A.
Revocation Acknowledgment Messagesの使用に関する例はAppendix Aで出されます。
3.5. Replay Protection
3.5. 反復操作による保護
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.
再生によってよく保護されているので、すべてのRevocation MessagesとRevocation Acknowledgment Messagesを認証しなければなりません。 しかしながら、それらが行われるオーダーは実現まで達しています。
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ビットのタイムスタンプへの登録取消しメッセージのRevocation Identifier分野を設定します。
- 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'ビット、およびRevocation Identifierの値をチェックしなければなりません。 また、受信エージェントは、メッセージがそれが特定された結合と関連して送った取消しメッセージの反映でないことをチェックしなければなりません。 'A'ビットとIdentifier分野が、このパケットが再生であることを含意するなら、静かに取消しメッセージを捨てなければなりません。
- 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.
- 取消し承認メッセージを築き上げるとき、承認しているエージェント(または、共同見つけられた可動の'ダイレクトな'ノード)は取消し承認メッセージのホームAddressとRevocation IdentifierにホームAddressとRevocation Identifier分野の値を取消しメッセージを回避します。 これは、取消しのエージェントが対応する取消しメッセージにこの取消し承認に合うことができるようにそうです。
Glass & Chandra Standards Track [Page 14] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[14ページ]RFC3543登録取消し
- 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.
- 有効な取消し承認を受けると、取消しのエージェントは、それが承認しているエージェントに送った対応する取消しメッセージからそれらの分野を合わせるのを確実にするためにホームAddressとIdentifier分野をチェックしなければなりません。 そうでなければ、静かにこの取消し承認メッセージを捨てなければなりません。
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.
エージェントがその対応するエージェントによって送られたすべての識別子を覚えている必要はなくてIdentifier分野の正当性をチェックするのが、入って来る取消しメッセージのIdentifierが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.
以下に注意してください。 可動のノードが異なった家のエージェントがいるいろいろな時間において異なった外国人のエージェントがいるいろいろな時間に登録するのが、可能であるように、異なったエージェントの上の時計が連動するという保証が全くないのでIdentifier分野が異なったエージェントからのメッセージでユニークであることが必要でないのは重要です。 例えば、可動のノードで同時の結合が複数の外国人のエージェントと共にいて、取消しメッセージが「同時」そのようなエージェントの外国人のより多くのひとりによって受け取られるなら、これらの外国人のエージェントのひとりからの取消しメッセージがたまたまいずれのものに合っているIdentifier分野か他のすべての外国人のエージェントを含むのは、可能です。 これは無視されるこれらの取消しメッセージのいずれももたらしてはいけません。
4. Registration Revocation Overview
4. 登録取消し概観
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.
登録Revocationは2つの異なった断片から成ります: トンネル終点と、外国人のエージェントと可動のノードの間のシグナル伝達機構の間のシグナル伝達機構。 共同見つけられた可動の'ダイレクトな'ノードは家のエージェントから取消しメッセージに受信して、応じるために取消し拡大と取消し承認を実行するかもしれなくて、[1]で定義された反-登録メッセージがこのために十分であるので、しかしながら、共同見つけられた可動の'ダイレクトな'ノードは取消しメッセージを送ってはいけません。
For further discussion on security issues related to registration revocation, refer to Section 6.
登録取消しに関連する安全保障問題のさらなる議論について、セクション6を参照してください。
4.1. Mobile Node Notification
4.1. モバイルノード通知
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]からのエージェント広告における、一連番号の整備士の簡潔な概観を与えるので、外国人のエージェントが結合がもう活発でないことを可動のノードに'含意する'メカニズムは明確に理解されています。
Glass & Chandra Standards Track [Page 15] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[15ページ]RFC3543登録取消し
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の一連番号から始まって、それぞれのその後のエージェント広告がある一連番号を[単調に]増加します。 可動のノードが一連番号スペースがエージェントが最大値を超えて一連番号カウンタを増加するときリセットされたものから単にくたくたになった外国人のエージェントを見分けることができるように、それは0[1]に回転することの代わりに256に一連番号を設定します。 このように、可動のノードはその時、ロールとしてのリセットを間違う並んでいる256の広告を逃さなければならないでしょう。そのうえ、可動のノードが、3つの標識を逃したと信じているとき、この外国人のエージェントのためのエントリーが信じるべきであるような方法におけるセットがタイムアウトであるべきであり、可動のノードがそこに登録されるなら、寿命は中にエージェント広告を含んで、それはエージェント懇願[1]を送るべきです。 しかしながら、エージェントがどうにかリセットされると、0の一連番号で広告を出し始めるでしょう、そして、可動のノードは、この外国人のエージェントが結合を失ったと推定できます、そして、可動のノードSHOULDはこの外国人のエージェントを通してまだモバイルIPサービスを得ているのを確実にするために再登録します。
Leveraging this mechanism, a foreign agent may consciously notify all mobile nodes currently bound to it that it has "reset" all of their bindings, even if the agent itself has not been reset, by simply [re]setting the sequence number of the next agent advertisement to 0. Moreover, a foreign agent may inform all mobile nodes currently bound to it that they should re-register with a different foreign agent by simultaneously setting the 'B' bit in the advertisement to 1, indicating this foreign agent is busy and is not accepting new registrations [1]. In these situations, any mobile node in compliance with [1] will presume this foreign agent has lost its binding, and must re-register if they wish to re-establish Mobile IP functionality with their home subnet.
このメカニズムに投機して、外国人のエージェントは、エージェント自身がリセットされていなくても次のエージェント広告の一連番号を0に設定しながら単に[re]で彼らの結合のすべてを「リセットしたこと」を意識して現在それに縛られているすべての可動のノードに通知するかもしれません。 そのうえ、外国人のエージェントは、同時までに'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
結合がもう存在しないのをどんな登録された可動のノードにも示すために、可動のノードが登録されている外国人のエージェントは一連番号があるエージェント広告が可動のノード[1]、[D]への0に設定するユニキャストがそうするかもしれません。 そのうえ、そのような外国人のエージェントが、結合が取り消されて、可動のノードが、それで登録を更新するのを試みるはずがないのを可動のノードに示したいなら、外国人のエージェントは、また、それが忙しいのを示して、これらのエージェント広告における1に'B'ビットを設定するかもしれなくて、新しい登録証明書[1]を受け入れていません。 [1]による対応することのすべての可動のノードが、これが、エージェントが忙しいことを意味するのを理解して、すぐにそれらの外国エージェントキャッシュで別のエージェントに再登録するのを試みるか、または追加隊員を請うかもしれません。 後者の場合では、外国人のエージェントは、任意に可動のノードの結合が取り消されたと思い出すことができます、そして、1に設定されて、同様に、請求して、すなわち、'B'と共に噛み付かれるのにこたえてください。 もっとも、外国人のエージェントがセットしていそうにないので'B'に噛み付いたことに注意されるべきです。
Glass & Chandra Standards Track [Page 16] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[16ページ]RFC3543登録取消し
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].
'B'ビットのないこのエージェントのマルチキャストエージェント広告が設定されるのを聞くとき、broadcastedエージェント広告(全体のリンクに発信する)における1まで、取り消された可動のノードは、それとともに記名するのを[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]で現在リンクで使用中のどんな方法に加えて説明されるように可動のノードへのユニキャストを送らなければならないエージェントAdvertisementsは攻撃します。
4.2. Registration Revocation Mechanism - Agent Notification
4.2. 登録取消しメカニズム--エージェント通知
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.
現在リンクの上に登録取消しを支持している外国人のエージェントはリンクする転送されるエージェントAdvertisement Extensionsに'X'ビットをはめ込まなければなりません。 これで、Registration Revocationサービスを必要とする可動のノードはサポートの広告を出すそれらの外国人のエージェントとともに記名することができます。
4.2.1. Negotiation of Revocation Support
4.2.1. 取消しサポートの交渉
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では、定義される)をそれに追加しなければなりません。 この家のエージェントからの対応する登録回答が取消しサポート拡大を含んでいないなら、外国人のエージェントSHOULDは、家のエージェントが登録取消しを理解しなくしたがっていませんし、また参加したがっていないと仮定します。 外国人のエージェントにとって、これが容認できないなら、それは例えば、「行政上禁止された」との登録を否定するかもしれません。 この場合セキュリティ協会が存在するところに登録要求と登録回答の両方が[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
家のエージェントはことになりたがっていて外国ドメインと取消しメッセージを交換できます、それには登録要求をリレーした外国人のエージェントとの既存のセキュリティ仲間がいなければならないという、それは取消しサポート拡大を追加しなければなりません。
Glass & Chandra Standards Track [Page 17] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[17ページ]RFC3543登録取消し
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.
登録回答。 外国人のエージェントからの登録要求が取消しサポート拡大を含まなかったなら、家のエージェントSHOULDは、外国人のエージェントが登録取消しを理解しなくしたがっていませんし、また特にこの結合のために参加したがっていないと仮定します。 家のエージェントにとって、これが容認できないなら、それは例えば、「行政上禁止された」との登録を否定するかもしれません。 家のエージェントは登録回答における取消しサポート拡大を入れるかもしれません。
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.
非colocatedされた可動のノードが取消しサポート拡大を登録要求に挿入してはいけないことに注意してください。 外国人のエージェントがそのような登録要求を受け取るなら、それは、静かにそれを捨てなければならなくて、プロトコル誤りとしてそれを登録するかもしれません。
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.
取消し拡大における'私'ビットは、結合が終えられることを可動のノードに知らせるという決定が家のエージェントに任せるかどうかを示すのに使用されます。 この機能性は、外国人のエージェントによって提供されて、家のエージェントによって受け入れられます。 より正確に、'私'ビットが1に設定される登録要求に付けられた取消し拡大を送ることによって、外国人のエージェントは、登録が家のエージェントまで終えられることをこの可動のノードに知らせるという決定が残っているかもしれないのを家のエージェントに示しています。 (ドメイン方針がどんな登録の生涯も変化するかもしれないと認められるので、「5月」という用語はここで使用されます。) 家のエージェントが、'私'ビットを1に設定することによってこれをしたがっていると認めることができますか、またはそれが'私'ビットを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.
両側がうまくいっている登録交換の間取消しサポート拡大を含んでいるとき、結合のために取消しサポートが交渉されると考えられます。
Glass & Chandra Standards Track [Page 18] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[18ページ]RFC3543登録取消し
4.2.2. Home Domain Revoking/Releasing a Registration
4.2.2. 登録を取り消すか、またはリリースするホームドメイン
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.
以下のセクションは各当事者が家のドメインが登録を取り消しているとき取消しサポート拡大で交渉された機能性に依存する責任を詳しく述べます。
4.2.2.1. Home Agent Responsibilities
4.2.2.1. ホームエージェント責任
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.
取消しメッセージを外国人のエージェントに送って、登録手続で'私'ビットの使用を交渉したとき、家のエージェントが、外国人のエージェントに取消しの可動のノードを知らせて欲しいなら、家のエージェントは'私'ビットを1に設定しなければなりません。 逆に、家のエージェントが可動のノードに通知して欲しくないなら、それは'私'ビットを0に設定しなければなりません。 可動のノードが異なった外国人のエージェントとともに記名したのを知って、外国人のエージェントが通知を試みる必要は全くないようにまた、家のエージェントが'私'ビットを'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.で定義されるようにIdentifier分野を設定しなければならなくて、セクション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つ以上の取消しを送ってはいけません。
Glass & Chandra Standards Track [Page 19] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[19ページ]RFC3543登録取消し
- the time between retransmissions SHOULD fall-back in analogy with
the registration guidelines in [1], namely exponential backoff,
and
- そしてすなわち、[1]、指数のbackoffの登録ガイドラインへの類推におけるretransmissions SHOULD後退の間の時間。
- the home agent MUST NOT retransmit revocation messages beyond the
normal life of the binding identified by the revocation message.
- 家のエージェントは取消しメッセージによって特定された結合の普通の生活を超えて取消しメッセージを再送してはいけません。
4.2.2.2. Foreign Agent Responsibilities
4.2.2.2. 外国エージェント責任
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'ビット、および識別子分野が再演されるのをチェックしなければなりません。 また、外国人のエージェントはホームのエージェントによって取消しメッセージ、すなわち、モバイルノードアドレスによって特定されたアドレスで情報を使用することでリリースされると説明された結合を特定しなければなりません、外国ドメインアドレス、ホームドメインアドレス、取消しメッセージのタイムスタンプ、および最後に受け入れられた登録メッセージのタイムスタンプもと同様に。 既存の登録証明書だけに、取消しが有効であるので、登録に関するタイムスタンプは取消しメッセージに先行しなければなりません(それらのタイムスタンプの両方が同じホームのエージェントによって設定されたことに注意してください)。 結合の場所を見つけると、外国人のエージェントは、それを取り消さなければならなくて、取消しメッセージのソースアドレスに取消し承認を送って応じなければなりません。 '私'ビットが交渉されたなら、外国人のエージェントは取消しメッセージと行為でそれに従って、噛み付いた'私'の値をチェックしなければなりません。
If notifying the mobile node by the methods described in Section 4.1., the foreign agent MUST set the 'I' bit to '1' in the revocation acknowledgment to be sent to the home agent, or if not notifying the mobile node, the foreign agent MUST set the 'I' bit to '0'.
セクション4.1.で説明されたメソッドでモバイルノードに通知するなら、外国人のエージェントがホームのエージェントに送られる取消し承認で'私'ビットを'1'に設定しなければなりませんか、またはそうでなければ、モバイルノードに通知して、外国人のエージェントは'私'ビットを'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.によって説明されるようにホームAddressとIdentifier分野を取消し承認メッセージにはめ込んで、取消し承認を生成して、指定されるとしての有効な固有識別文字がセクション3.3にある状態で、それを保護しなければなりません。
4.2.2.3. 'Direct' co-located mobile node Responsibilities
4.2.2.3. 共同見つけられたモバイル'ダイレクトな'ノードResponsibilities
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
取消しメッセージを受け取ると、共同見つけられたモバイル'ダイレクトな'ノードは、固有識別文字を有効にして、再生への取消しメッセージで指定されたホームアドレスと識別子をチェックしなければなりません。 パケットが認証を通過して、識別子が、この取消しが新しいのを明らかにするなら、モバイルノードは、取消しメッセージに含まれた情報がホームを特定することを確かめなければなりません。
Glass & Chandra Standards Track [Page 20] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[20ページ]RFC3543登録取消し
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.
それが現在の結合を持っているエージェント、この結合が正しくノードとどんな外国ドメインもそれを扱うこのモバイルを特定するのは現在、使用されています。 モバイルノードがそのような結合を特定できるなら、モバイルノードSHOULDは最初に、取消しメッセージのIPソースアドレスに送らなければならない取消し承認メッセージを生成します。 モバイルノードは、次に、それがこのホームのエージェントに使用しているどんな逆のトンネルカプセル化[C]も終えて、結合が取り消されたと考えて、前の結合に関連しているいかなる他のリソースも開けるかもしれません。
4.2.3. Foreign Domain Revoking/Releasing a Registration
4.2.3. 登録を取り消すか、またはリリースする外国ドメイン
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'ビットがエージェントの広告に設定されたので)を通して登録する共同見つけられたモバイルノードの取消しサポートがサポートされないことに注意してください。 詳細に関して.1にセクション4.3を見てください。
4.2.3.1. Foreign Agent Responsibilities
4.2.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.
'私'ビットの使用が交渉されて、最後のうまくいっている登録交換以来モバイルノードを知らせる外国ドメイン方針が変化していないなら、外国人のエージェントはこのとき、取消しのどんなモバイルノードも知らせてはいけません。 代わりに、外国人のエージェントは取消しメッセージの'1'に'私'ビットを設定しなければなりません、その結果、それが作用しているモバイルノードに通知するべきであるかどうかを示すのに取消し承認に'私'ビットを使用するようにホームのエージェントに頼みます。 外国ドメインに関する方針が最新のうまくいっている登録以来変化していて、外国人のエージェントがもう'私'ビットを使用できないならモバイルノードに通知しないことであったなら、外国人のエージェントは、'私'ビットを'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:
外国人のエージェントが妥当な時間以内に取消し承認メッセージを受け取らないなら、それは取消しメッセージを再送しなければなりません。 どれくらい長い間、外国人のエージェントが、再送するのを待つか、そして、メッセージが何回再送されるかが以下の仕様で制限されるだけです:
Glass & Chandra Standards Track [Page 21] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[21ページ]RFC3543登録取消し
- 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秒あたり1つ以上の取消しを送ってはいけません。
- SHOULD set its retransmissions to fall-back in analogy with the
registration guidelines in [1], namely exponential backoff, and
- そしてSHOULDがすなわち、[1]、指数のbackoffの登録ガイドラインへの類推における後退に「再-トランスミッション」を設定する。
- MUST NOT retransmit revocation messages beyond the normal life of
the binding identified by the revocation message.
- 取消しメッセージによって特定された結合の普通の生活を超えて取消しメッセージを再送してはいけません。
4.2.3.2. Home Agent Responsibilities
4.2.3.2. ホームエージェント責任
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'.
'私'ビットの使用が交渉されて、'私'ビットが取消しメッセージの'1'に設定されるなら、ホームのエージェントは、それが、モバイルノードにこの結合の取消しにおいて知識があって欲しいかどうか決めるべきです。 モバイルノードに知識があって欲しいなら、それは'1'への取消し承認メッセージに'私'ビットをはめ込まなければなりません。 モバイルノードに知識があって欲しくないなら、それは'私'ビットを'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.によって説明されるホームAddress、およびRevocation Identifier分野を設定して、指定されるとしての有効な固有識別文字がセクション3.3にある状態で、取消し承認メッセージを保護しなければなりません。
Glass & Chandra Standards Track [Page 22] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[22ページ]RFC3543登録取消し
4.2.4. Mobile Node Deregistering a Registration
4.2.4. モバイルノードDeregisteringは登録です。
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].
直接ホームのエージェント(共同見つけられたモバイル'ダイレクトな'ノード)に登録されたいか、外国人のエージェントを通して登録して、またはそれ自身の結合を終えたがっていることにかかわらずモバイルノードがホームのエージェントに登録されるケース、モバイルノードが取消しメッセージを送ってはいけなくて、唯一のSHOULDが単に「反-レジスタ」である、適切な介護、-、アドレス、[1]によって説明されるホームのエージェントと共に。
4.3. Mobile IP Registration Bits in the Revocation Process
4.3. 取消しプロセスのモバイルIP登録ビット
Several of the bits used in the registration process need special consideration when using the revocation mechanism.
取消しメカニズムを使用するとき、登録手続で使用されるビットの数個が特別の配慮を必要とします。
4.3.1. The 'R' Bit in Use
4.3.1. 使用中である'R'ビット
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'ビットの広告を出す外国人のエージェントは、外国人のエージェントとともに記名するようあらゆるモバイルノード、共同見つけられている(そうでなければ、だれの登録は外国人のエージェントを無視するだろうか)ものにさえ要求します。) しかしながら、この場合、外国人のエージェントSHOULDは共同見つけられたファッションで登録しているモバイルノードから「行政上禁止されている」として登録要求を否定します。 外国人のエージェントがセクション4.3.2に概説された理由のため共同見つけられたモバイルノードの製本を取り消すことができないということである理由。
How the foreign agent and/or foreign domain enforce the 'R' bit is beyond the scope of this document.
外国人のエージェント、そして/または、外国ドメインがどう'R'ビットを実施するかはこのドキュメントの範囲を超えています。
4.3.2. The 'D' bit in Use
4.3.2. Useの'D'ビット
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
登録は、ホームのエージェントによって受け取られると'D'ビットがどこに設定されるか、そして、どれが外国人のエージェント(例えば、'R'ビットの広告による)を通してリレーされるかが登録要求のソースアドレスとして理論的に外国エージェントアドレスを含むべきであるよう要求します。 ホームのエージェントが、この登録要求のソースアドレスが共同見つけられるのと同じでないと結論を下すかもしれない、注意、-、アドレスは、外国人のエージェントでは、登録要求に含んでいて、したがって、アドレスである傾向があります。 しかしながら、以来、事実上、このIPソースアドレスがそうであることを保証する方法が全くありません。
Glass & Chandra Standards Track [Page 23] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[23ページ]RFC3543登録取消し
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.
モバイルノードを調整する外国人のエージェントのアドレス、この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サービスをそれに提供しているエージェントです。 これは、否定を阻むためのものです。-サービスでは、ホームのエージェントと共にセキュリティ協会を持って、共同見つけられたモバイルノードとホームのエージェントの間の経路にいる外国人のエージェントによるモバイルノードの上で攻撃してください。
5. Error Codes
5. エラーコード
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サービスが中止されるという通知であるので、どんな新しいエラーコードもありません。
6. Security Considerations
6. セキュリティ問題
There are two potential vulnerabilities, one in the agent advertisement mechanism, and one related to unauthorized revocation messages.
2つの潜在的脆弱性、エージェント広告メカニズムの1、および権限のない取消しメッセージに関連するのがあります。
6.1. Agent Advertisements
6.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]で定義されるエージェント広告がリンクの上に住んでいる他のマシンによって偽造されるかもしれないからです。 これで、そのようなノードが、モバイルノードが、登録がリセット一連番号でモバイルノードのリンクローカルアドレスに広告をunicastingするか、またはそれをサブネットに放送することによって取り消されたと信じているようにだますのが可能になります、その結果、彼らのすべての登録証明書が失われたと信じているのに特定の外国人のエージェントに登録されたすべてのモバイルノードをだまします。
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
そのようなルータ通知を保証するために、このワーキンググループと他のもの(例えば、IPsec)にはいくらかの仕事がありました、ソリューションは全くこの公表時点で、常套手段となっていませんが。 ここで、[1]への厳しい固守、明確にTTLが1歳でない1歳でないそれらに従わない少しのエージェント広告も作成者がそれを確実にするべきである彼らの最小限の分裂における潜在的の、そして、モバイルのノードにもたらすのが同じリンクアドレス(存在しているとき)から発するサービス問題の可能な否定を回避するのを助けるために
Glass & Chandra Standards Track [Page 24] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[24ページ]RFC3543登録取消し
other agent advertisements supposedly from the same agent, or even that of the last successful registration reply, be silently discarded.
捨てられて、推定上同じエージェントからの他のエージェント広告、または最後のうまくいっている登録回答のものさえ静かにそうです。
6.2. Revocation Messages
6.2. 取消しメッセージ
As registration revocation, when performed, terminates Mobile IP services being provided to the mobile node, it is crucial that all security and replay protection mechanisms be verified before a mobility agent believes that the other agent has revoked a binding. Messages which are sent link-local (e.g., between mobile node and foreign agent) MAY also be secured by methods outlined in [1], namely the use of mobile-foreign authenticators, but these have no direct relation to registration revocation.
実行されると登録取消しがモバイルノードに提供されるモバイルIPサービスを終えるので、移動性エージェントが、もう片方のエージェントが結合を取り消したと信じる前にすべてのセキュリティと反復操作による保護メカニズムが確かめられるのは、重要です。 また、すなわち、[1]に概説されたメソッド、モバイル外国の固有識別文字の使用でリンク地方で(例えば、モバイルノードと外国人のエージェントの間の)送られるメッセージを保証するかもしれませんが、これらには、登録取消しとのどんなダイレクト関係もありません。
RFC 3344 [1] defines a security mechanism that MUST be used between home agents and mobile nodes, and MAY used between home agents and foreign agents, namely the use of authenticators. All foreign and home agents MUST support protection of revocation messages via the foreign-home authenticators defined in [1]. They MAY implement other mechanisms of equal or greater strength; if such mechanisms are known to be available to both parties, they MAY be used instead.
RFC3344[1]はホームのエージェントとモバイルノードの間で使用しなければならないセキュリティー対策、およびホームのエージェントと外国人のエージェントの間で使用される5月、すなわち、固有識別文字の使用を定義します。 すべての外国とホームのエージェントが[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
「悪意がある反射鏡」の場合では、中央の男性は、取消しメッセージを得て、後で次に、それを創始者に返します。 ホームと外国ドメインとのセキュリティ協会がパケットのUDP部分のコンテンツを保護するだけである(単一)の共有秘密キーにかかわるセキュリティ協会を使用する、([1])によって再生なしで定義されるのとホーム同じくらい外国の固有識別文字
Glass & Chandra Standards Track [Page 25] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[25ページ]RFC3543登録取消し
protection, the sender of the packet will also believe the revocation message to be authentic.
また、保護、パケットの送付者は、取消しメッセージが正統であると信じるでしょう。
The replay protection mechanism used by the revocation messages defined by this document is designed to protect against both of these active attacks. As a benefit, by using a 32-bit timestamp it can be more quickly determined if revocation messages are replays, though the reader is advised to use caution in this approach. An agent which receives an authenticated revocation message can compare the Identifier field to that of a previously received revocation message, and if the timestamp in the new message is found to have been generated after that of the time-stamp in the last revocation message received, it can immediately be determined as not being a replay. Note however that since datagrams are not guaranteed to arrive in order, it should not be presumed that because the values contained in an Identifier field are timestamps that they will necessarily be increasing with each successive revocation message received. Should an implementor decide to base his replay detection mechanism on increasing timestamps, and therefore increasing Identifier values, a suitable time window should be defined in which revocation messages can be received. At worst, ignoring any revocation message should result in the retransmission of another revocation message, this time with timestamp later than the last one received.
このドキュメントによって定義された取消しメッセージによって使用される反復操作による保護メカニズムは、これらの活発な攻撃の両方から守るように設計されています。 利益として、32ビットのタイムスタンプを使用することによって、取消しメッセージが再生であるなら、よりはやく決定できます、読者がこのアプローチに警告を使用するようにアドバイスされますが。 認証された取消しメッセージを受け取るエージェントは以前に受信された取消しメッセージのものとIdentifier分野を比較できます、そして、新しいメッセージのタイムスタンプが最後の取消しメッセージのタイムスタンプのものが受信された後に生成されたのがわかっているなら、すぐに、断固とするのが、再生でないということであるかもしれません。 しかしながら、データグラムが整然とした状態で到着するように保証されないのでIdentifier分野に保管されていた値がそれぞれの連続した取消しに従ってそれらが必ず増強するタイムスタンプであるのでメッセージが受信されたと推定されるべきでないことに注意してください。 作成者が、彼の再生検出メカニズムをタイムスタンプを増加させて、したがって、増加するIdentifierを値、適当なタイムウィンドウがそうするべきである増加させるのに基礎づけると決めるなら、どの取消しメッセージを受け取ることができるかに、定義されてください。 最悪の場合は、どんな取消しメッセージも無視すると、別の取消しメッセージ(最後のものが受信されたより遅いタイムスタンプがある今回)の「再-トランスミッション」はもたらされるべきです。
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]はこのシナリオに対する十分な保護を提供します。
Glass & Chandra Standards Track [Page 26] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[26ページ]RFC3543登録取消し
7. IANA Considerations
7. IANA問題
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.
このドキュメントは同じモバイルノードに提供されるサービスに特定のホームと外国人のエージェントの間の追加セットのメッセージ、またはモバイルノードの部分集合を定義します。 この仕様に基づく正しいinteroperationを確実にするために、IANAは2つの新しいメッセージタイプ、およびただ一つの新しい拡大のためにモバイルIP数のスペースで値を予約しました。
7.1. New Message Types
7.1. 新しいメッセージタイプ
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).
登録取消し: 7は、新しいモバイルIPコントロールメッセージであり、使用UDPが434を移植するのをタイプします。 モバイルIPのRegistration Request(=1をタイプする)、およびモバイルIP Registration Replyと同じ数のスペースからこの値を取りました(=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).
登録取消し承認: 15は、新しいモバイルIPコントロールメッセージであり、使用UDPが434を移植するのをタイプします。 モバイルIPのRegistration Request(=1をタイプする)、およびモバイルIP Registration Replyと同じ数のスペースからこの値を取りました(=3をタイプしてください)。
7.2. New Extension Values
7.2. 新しい拡大値
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.
取消しサポート拡大: Registration Request、またはRegistration Replyに追加された新しいモバイルIP Extension。 割り当てられた値は137です。 Extension数のスペースからこの拡大を得ます。 それはRFC3344で定義されるように'skippable'(128--255)範囲にあるに違いありません。
7.3. New Error Codes
7.3. 新しいエラーコード
There are no new Mobile IP error codes introduced by this document.
このドキュメントによって紹介されたどんな新しいモバイルIPエラーコードもありません。
8. References
8. 参照
8.1. Normative References (Numerical)
8.1. 引用規格(数字)です。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[1] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[2] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC 3012, November 2000.
[2] パーキンスとC.とP.カルフーン、「モバイルIPv4挑戦/応答拡大」、RFC3012、2000年11月。
[3] Bradner, S., "Key Words for us in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsの私たちにとって、主要なワーズ」、BCP14、RFC2119、1997年3月。
Glass & Chandra Standards Track [Page 27] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[27ページ]RFC3543登録取消し
8.2. Informational References (Alphabetical)
8.2. 情報の参照(アルファベット順)です。
[A] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements", RFC
2977, October 2000.
[A] S.、ヒラー、T.、ジェイコブズ、S.、C.パーキンス、および「モバイルIP認証、承認、および会計要件」とガラスで覆ってください、RFC2977、2000年10月。
[B] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil,
B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham,
S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B.,
Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and
E. Jaques, "Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
[B] Aboba、B.、カルフーン、P.はS.とヒラーとT.とマッキャンとP.とShiinoとH.とウォルシュとP.とゾルンとG.とDommetyとG.とパーキンスとC.とパティルとB.とミットンとD.とマニングとS.と用務員とM.とチェンとX.とSivalinghamとS.とハミードとA.とムンソンとM.とジェイコブズとS.とリムとB.とヒルシュマンとB.とシューとR.とクーとH.とLipfordとM.とキャンベルとE.とシューとY.と馬場とS.とE.ジャキュース、「ネットワークアクセスのためにAAAプロトコルを評価する評価基準」とガラスで覆います、RFC2989、2000年11月。
[C] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001.
[C] モンテネグロ、G.、エドRFC3024、「モバイルIPのためにTunnelingを逆にして、改訂され」て、2001年1月。
[D] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[D] デアリング、S.、エド、「ICMPルータ発見メッセージ」、RFC1256、9月1991日
[E] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
[E] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
Glass & Chandra Standards Track [Page 28] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[28ページ]RFC3543登録取消し
Appendix A: An Example of the Revocation Messages in Use
付録A: 使用中の取消しメッセージに関する例
For clarity, the following example is meant to illustrate the use of the new messages in the registration phase, and the revocation phase. In this example, a foreign agent and home agent will negotiate revocation during the registration phase. During the revocation phase, the foreign agent will revoke the binding of a mobile node.
明快において、以下の例は登録フェーズ、および取消しフェーズにおける新しいメッセージの使用を例証することになっています。 この例では、外国人のエージェントとホームのエージェントは登録段階の間、取消しを交渉するでしょう。 取消し段階の間、外国人のエージェントはモバイルノードの製本を取り消すでしょう。
A.1. The Registration Phase
A.1。 登録フェーズ
Consider a foreign agent that supports registration revocation, and has a security association with a home agent to which it is forwarding a registration request. The foreign agent will include the revocation support extension after the mobile-home authenticator. Assume that the foreign agent supports the use of the 'I' bit, and is willing to let the home agent decide if the mobile node should be informed of the revocation of its registration. Thus, the foreign agent will set the 'I' bit to '1'. The foreign agent will append a foreign-home authenticator to the registration request.
それが登録要求を転送しているホームのエージェントと共に登録が取消しであるとサポートして、セキュリティ協会を持っている外国人のエージェントを考えてください。 外国人のエージェントは移動住宅固有識別文字の後に取消しサポート拡大を入れるでしょう。 外国人のエージェントが、'私'ビットの使用をサポートして、モバイルノードは登録の取消しにおいて知識があるべきであるかどうかホームのエージェントに決めさせても構わないと思っていると仮定してください。 したがって、外国人のエージェントは'私'ビットを'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.
取消し拡大を含む登録要求を受け取ると、ホームのエージェントは登録回答における取消しサポート拡大を入れるでしょう。 '私'が取消し拡大で'1'まで噛み付いて、ホームのエージェントが'私'の使用をサポートする外国エージェントセットに噛み付いたので、ホームのエージェントは'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.
モバイルノードがイベントで通知されて、この登録は取り消されます、すなわち、ホームのエージェントが'私'ビットをリターン取消し拡大にはめ込んだのでことであるなら、認証された登録回答を受け取ると、外国人のエージェントは、取消しサポート拡大をチェックして、ホームのエージェントが決めたいことに注意するでしょう。
A.2. The Revocation Phase
A.2。 取消しフェーズ
The foreign agent revokes a mobile node's binding, and generates a revocation message to be sent to the mobile node's home agent. Since the 'I' bit was negotiated in the revocation extensions, and the foreign agent is still willing to let the home agent indicate whether this mobile node should be informed about the revocation, it will set the 'I' bit to '1' in the revocation message. The foreign agent also makes sure the 'A' bit is set to '0'.
外国人のエージェントは、モバイルノードの結合を取り消して、モバイルノードのホームのエージェントに送られるべき取消しメッセージを生成します。 '私'ビットが取消し拡大で交渉されて、外国人のエージェントが、このモバイルノードは取消しに関して知識があるべきであるかどうかをホームのエージェントに示させても構わないとまだ思っているので、それは取消しメッセージの'1'に'私'ビットを設定するでしょう。 また、外国人のエージェントは''ビットは'0に設定されること'を確かにします。
The foreign agent will also place the address of the mobile node whose registration it wishes to revoke in the home address field, the address that the mobile node registered as the care-of address in the foreign domain field, and the address registered as the home agent in
また、外国人のエージェントはそれがホームアドレス分野で登録を取り消したがっている可動のノードのアドレスを置くでしょう、可動のノードが登録したアドレス、注意、-、中に外国ドメイン分野、および家のエージェントとして中に示されたアドレスを記述してください。
Glass & Chandra Standards Track [Page 29] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[29ページ]RFC3543登録取消し
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ビットのタイムスタンプにRevocation Identifierを設定して、外国家の固有識別文字を追加するでしょう。
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'ビットとIdentifierが、この取消しが再生でないことを示すのを確実にするためにチェックするでしょう。 そして、家のエージェントは、登録が取り消されている可動のノードの場所を見つけるのに可動のノードホームアドレス、外国ドメインアドレス、および家のドメインアドレスを使用します。
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.
有効な登録取消しメッセージを処理すると、家のエージェントは取消し承認メッセージを発生させます。 '私'ビットが取消しメッセージの'1'に設定されて、家のエージェントが、特定された可動のノードに取消しにおいて知識があって欲しいので、それは'1'への取消し承認に'私'ビットをはめ込むでしょう。 そして、家のエージェントはホームアドレスとRevocation Identifier分野を取消し承認にコピーします。 家のエージェントは家の外国の固有識別文字で取消し承認を保護します。
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.
有効な取消し承認(固有識別文字とIdentifier分野はそこで許容できる)を受けると、外国人のエージェントは'私'ビットの状態をチェックします。 '私'ビットが'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つ以上の異種のアドレス空間に領域を位相的につなげたということであるなら、問題は全く見通されません。 オーダーでは、可動のノードが首尾よくそうしたのは家のエージェントとともに記名しました、とそれが現在付けられるネットワーク(外国人のエージェント)に家のエージェントの発送可能アドレスを前提としたに違いありません。 逆に、注意、-、また、可動のノードによって使用されるアドレスは持っている登録回答において、整然としている家のエージェントにとって重要であるのが、位相的に、受け取られていて開始されたトンネルであるということであるに違いありません。 そして、次に、定義上家のエージェントアドレス、注意、-、アドレス、それぞれが重要であるに違いなく、アドレスはこの可動のノードの文脈でユニークな組を両方のエージェントに形成しなければなりません。
Glass & Chandra Standards Track [Page 30] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[30ページ]RFC3543登録取消し
Another way of understanding this is that the tunnel endpoints are in some way connected, and hence each are unique as far as the other end is concerned. The address at the other end of the tunnel, in combination with the address of the mobile node, must therefore form a unique pair that can be identified by the agent receiving the registration revocation message.
これを理解する別の方法はトンネル終点が接続された何らかの方法であって、もう一方の端に関する限り、したがって、それぞれユニークであるということです。 したがって、可動のノードのアドレスと組み合わせたトンネルのもう一方の端のアドレスは登録取消しメッセージを受け取るエージェントが特定できるユニークな組を形成しなければなりません。
As an example, consider a mobile node who's home address lies in disparate address space A behind its home agent. In the following diagram, [*] indicates an interface of the entity in which it appears.
例と、家のエージェントの後ろで異種のアドレス空間Aにおいてホームアドレス偽りである可動のノードを考えてください。 以下のダイヤグラムで、[*]はそれが現れる実体のインタフェースを示します。
MN[a]-----[c]FA[b]=====((()))=====[b]HA[a]-----[a]CN
ミネソタ[a]-----[c] ファ[b]=====((()))=====[b]、ハ、[a]-----[a] CN
Address Some topologically Address
Space C connected network Space A
Someを記述してください、位相的に、Address Space CはネットワークSpace Aを接続しました。
We presume a binding for MN exists, and hence a tunnel between FA[b]
and HA[b] exists. Then, since the address assigned to MN[a] MUST be
unique in address space A, the pair {FA[b],MN[a]} is guaranteed to be
unique in the binding table of HA, and the pair {HA[b],MN[a]} is
guaranteed to be unique in the foreign agent's visitor list.
私たちは、ミネソタとの結合が存在すると推定します、そして、したがって、FA[b]とHA[b]の間のトンネルは存在しています。 次に、ミネソタ[a]に配属されたアドレスがアドレス空間Aでユニークであるに違いないので、FA[b]、組ミネソタ[a]はHAの拘束力があるテーブルで特有になるように保証されます、そして、HA[b]、組ミネソタ[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]から登録取消しメッセージと外国家の固有識別文字をミネソタ[a]に受け取る家のエージェントは反登録されるユニークな可動のノードアドレスを決定できます。 逆に、HA[b]から登録取消しメッセージと家の外国の固有識別文字をミネソタ[a]に受け取る外国人のエージェントは反登録される正確な可動のノードアドレスを決定できます。 外国人のエージェントがこの理由家のドメイン分野で設定していた状態で登録取消しメッセージを受け取る、ゼロが記述する、静かにそれを捨てなければなりません。 これはプライベート・アドレスを重ね合わせる場合で混乱を防ぐためのものです。 複数の可動のノードが同じくらいを通して登録される、注意、-、アドレスと同じ(異種的か個人的)のホームアドレスを一致して使用する家のドメイン分野に現れる家のエージェントアドレスは外国人のエージェントがこれらの可動のノードの違いについて明察できる唯一の方法です。
Glass & Chandra Standards Track [Page 31] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[31ページ]RFC3543登録取消し
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.
作者は、Bhalla、ケントレオン、および概念への彼らの貢献のためのAlpeshパテルが、草稿subbarao-mobileipリソース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.
また、作者は結局Revocation Extensionへのタイムスタンプの添加に導く再生メカニズム、および安全上の配慮についての彼の議論のためのピートマッキャン、および初期の再生メカニズムに関する問題を指摘するためのアフマドMuhannaに感謝したがっています。
The authors would also like to acknowledge Henrik Levkowetz for his detailed review of the document, and Michael Thomas for his review of the replay mechanism described herein.
また、作者は彼のドキュメントの詳細なレビューのためのHenrik Levkowetz、および彼のここに説明された再生メカニズムのレビューのためのマイケル・トーマスを承認したがっています。
Authors' Addresses
作者のアドレス
Steven M. Glass Solaris Network Technologies Sun Microsystems 1 Network Drive Burlington, MA. 01801
サン・マイクロシステムズ1がネットワークでつなぐスティーブンM.ガラスSolarisネットワーク技術はバーリントン、MAを運転します。 01801
Phone: +1.781.442.0000 Fax: +1.781.442.1706 EMail: steven.glass@sun.com
以下に電話をしてください。 +1.781 .442.0000Fax: +1.781 .442 .1706 メール: steven.glass@sun.com
Madhavi W. Chandra IOS Technologies Division Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709
7025年の事業部シスコシステムズキットクリーク道路リサーチトライアングル公園、Madhavi W.チャンドラIOS Technologies NC 27709
Phone: +1.919.392.8387 EMail: mchandra@cisco.com
以下に電話をしてください。 +1.919 .392 .8387 メール: mchandra@cisco.com
Glass & Chandra Standards Track [Page 32] RFC 3543 Registration Revocation in Mobile IPv4 August 2003
モバイルIPv4 August 2003のガラスとチャンドラ標準化過程[32ページ]RFC3543登録取消し
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Glass & Chandra Standards Track [Page 33]
ガラスとチャンドラ標準化過程[33ページ]
一覧
スポンサーリンク
