RFC5142 日本語訳
5142 Mobility Header Home Agent Switch Message. B. Haley, V.Devarapalli, H. Deng, J. Kempf. January 2008. (Format: TXT=27460 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Haley
Request for Comments: 5142 Hewlett-Packard
Category: Standards Track V. Devarapalli
Azaire Networks
H. Deng
China Mobile
J. Kempf
DoCoMo USA Labs
January 2008
コメントを求めるワーキンググループB.ヘイリー要求をネットワークでつないでください: 5142年のヒューレット・パッカードカテゴリ: J.ケンフDoCoMo米国研究室2008年1月のモバイルの中国の標準化過程V.Devarapalli AzaireネットワークH.?
Mobility Header Home Agent Switch Message
移動性ヘッダーホームエージェントスイッチメッセージ
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent.
このドキュメントは新しいホームのエージェントを取得するべきであるとモバイルノードに合図するのにホームのエージェントとモバイルノードの間で使用できる新しいMobility Headerメッセージタイプを指定します。
Haley, et al. Standards Track [Page 1] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[1ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Scenarios .......................................................3
3.1. Overloaded .................................................3
3.2. Load Balancing .............................................3
3.3. Maintenance ................................................3
3.4. Functional Load Balancing ..................................3
3.5. Home Agent Renumbering .....................................4
4. Home Agent Switch Message .......................................4
5. Home Agent Operation ............................................6
5.1. Sending Home Agent Switch Messages .........................6
5.2. Retransmissions ............................................7
5.3. Mobile Node Errors .........................................7
6. Mobile Node Operation ...........................................8
6.1. Receiving Home Agent Switch Messages .......................8
6.2. Selecting a Home Agent .....................................9
7. Operational Considerations ......................................9
8. Protocol Constants .............................................10
9. IANA Considerations ............................................10
10. Security Considerations .......................................10
11. References ....................................................11
11.1. Normative References .....................................11
11.2. Informative References ...................................11
Acknowledgments ...................................................11
1. 序論…2 2. 用語…3 3. シナリオ…3 3.1. 積みすぎられます…3 3.2. ロードバランシング…3 3.3. メインテナンス…3 3.4. 機能負担量バランスをとること…3 3.5. ホームエージェントの番号を付け替えること…4 4. ホームエージェントスイッチメッセージ…4 5. ホームエージェント操作…6 5.1. ホームのエージェントを送って、メッセージを切り換えてください…6 5.2. Retransmissions…7 5.3. モバイルノード誤り…7 6. モバイルノード手術…8 6.1. ホームのエージェントを受けて、メッセージを切り換えてください…8 6.2. ホームのエージェントを選びます…9 7. 操作上の問題…9 8. 定数について議定書の中で述べてください…10 9. IANA問題…10 10. セキュリティ問題…10 11. 参照…11 11.1. 標準の参照…11 11.2. 有益な参照…11の承認…11
1. Introduction
1. 序論
RFC 3775 [RFC3775] contains no provision to allow a home agent to inform a mobile node that it needs to stop acting as the home agent for the mobile node. For example, a home agent may wish to handoff some of its mobile nodes to another home agent because it has become overloaded or it is going offline.
RFC3775[RFC3775]はホームのエージェントが、モバイルノードのためのホームのエージェントとして務めるのを止めるのが必要であることをモバイルノードに知らせるのを許容する支給を全く含んでいません。 例えば、ホームのエージェントは、積みすぎられるようになったか、またはオフラインで行く予定であるので、移管に別のホームのエージェントへのいくつかのモバイルノードを願うかもしれません。
This protocol describes a signaling message, called the Home Agent Switch message, that can be used to send a handoff notification between a home agent and mobile node.
このプロトコルはホームのエージェントとモバイルノードの間に移管通知を送るのに使用できるホームエージェントSwitchメッセージと呼ばれるシグナリングメッセージについて説明します。
The Home Agent Switch message does not attempt to solve all general problems related to changing the home agent of a mobile node. In particular, this protocol does not attempt to solve:
ホームエージェントSwitchメッセージは、モバイルノードのホームのエージェントを変えることにおける関連するすべての一般的問題を解決するのを試みません。 特に、このプロトコルは、以下を解決するのを試みません。
o The case where the Home Address of a mobile node must change in
order to switch to a new home agent. This operation should be
avoided using this message.
o モバイルノードのホームAddressが新しいホームのエージェントに切り替わるように変化しなければならないケース。 この操作は、このメッセージを使用することで避けられるべきです。
Haley, et al. Standards Track [Page 2] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[2ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
o Determining when a home agent should actively move mobile nodes
to another home agent. This decision should be made by a
backend protocol, for example, as described in [hareliability].
o ホームのエージェントがいつ活発にモバイルノードを別のホームのエージェントに動かすべきであるかを決定します。 バックエンドプロトコルは例えば、[hareliability]で説明されるようにこの決定をするべきです。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Scenarios
3. シナリオ
Here are some example scenarios where a home agent signaling message would be useful.
ここに、ホームエージェントシグナリングメッセージが役に立ついくつかの例のシナリオがあります。
3.1. Overloaded
3.1. 積みすぎられます。
There are a number of reasons a home agent might be considered overloaded. One might be that it is at, or near, its limit on the number of home bindings it is willing to accept. Another is that it has reached a pre-determined level of system resource usage -- memory, cpu cycles, etc. In either case, it would be desirable for a home agent to reduce the number of home bindings before a failure occurs.
ホームのエージェントが積みすぎられると考えられるかもしれない多くの理由があります。 1つは限界において、または、ほぼそれが受け入れても構わないと思っているホーム結合の数におけるその限界でそれがあるということであるかもしれません。 別のものは予定されたレベルのシステム資源用法に達したということです--メモリ、cpuサイクルなど どちらかの場合では、ホームのエージェントが失敗が起こる前のホーム結合の数を減少させるのは、望ましいでしょう。
3.2. Load Balancing
3.2. ロードバランシング
A home agent might know of other home agents that are not as heavily loaded as itself, learned through some other mechanism outside the scope of this document. An operator may wish to try and balance this load so that a failure would disrupt a smaller percentage of mobile nodes.
ホームのエージェントはそれ自体として同じくらい大いに積み込まれない他のホームのエージェントを知るかもしれません、このドキュメントの範囲の外のある他のメカニズムを通して学習されて。 オペレータがこの負荷のバランスをとってみたがっているかもしれないので、失敗は、よりわずかな百分率のモバイルノードを混乱させるでしょう。
3.3. Maintenance
3.3. メインテナンス
Most operators do periodic maintenance in order to maintain reliability. If a home agent is being shutdown for maintenance, it would be desirable to inform mobile nodes so they do not lose mobility service.
ほとんどのオペレータが、信頼性を維持するために定期メンテナンスをします。 ホームのエージェントがメインテナンスのための閉鎖であるなら、モバイルノードを知らせるのは望ましいでしょう、したがって、それらが移動性サービスを失いません。
3.4. Functional Load Balancing
3.4. 機能負担量バランスをとること
A Mobile IPv6 home agent provides mobile nodes with two basic services. It acts as a rendezvous server where correspondent nodes can find the current care-of address for the mobile node, and as an overlay router to tunnel traffic to/from the mobile node at its current care-of address.
モバイルIPv6ホームのエージェントは2つの基本サービスをモバイルノードに提供します。 それが通信員ノードが電流を見つけることができるランデブーサーバとして機能する、注意、-、モバイルノードのために扱って、トンネルを堀るオーバレイルータモバイルノードからの/に取引する、電流、注意、-、アドレス
Haley, et al. Standards Track [Page 3] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[3ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
A mobility service provider could have two sets of home agents to handle the two functions. The rendezvous function could be handled by a machine specialized for high-speed transaction processing, while the overlay router function could be handled by a machine with high data throughput.
移動性サービスプロバイダーは2つの機能を扱う2セットのホームのエージェントを持つことができました。 ランデブー機能は高速トランザクション処理のために専門にされたマシンによって扱われるかもしれません、オーバレイルータ機能が高いデータスループットがあるマシンによって扱われるかもしれませんが。
A mobile node would start on the rendezvous server home agent and stay there if it does route optimization. However, if the original home agent detects that the mobile node is not doing route optimization, but instead reverse-tunneling traffic, it could redirect the mobile node to a home agent with better data throughput.
経路最適化をするなら、モバイルノードは、ランデブーサーバホームのエージェントを始めて、そこに滞在するでしょう。 しかしながら、オリジナルのホームのエージェントがそれを検出するならモバイルノードが経路最適化をするのではなく、代わりに逆トンネリングトラフィックである、それは、より良いデータ効率でモバイルノードをホームのエージェントに転送するかもしれません。
3.5. Home Agent Renumbering
3.5. ホームエージェントの番号を付け替えること
Periodically, a mobility service provider may want to shut-down home agent services at a set of IPv6 addresses and bring service back up at a new set of addresses. Note that this may not involve anything as complex as IPv6 network renumbering [RFC4192]; it may just involve changing the addresses of the home agents. With a signaling message, the service provider could inform mobile nodes to look for a new home agent.
移動性サービスプロバイダーは、IPv6アドレスのセットでホームエージェントサービスを止めて、定期的に、新しいアドレスでサービスを持って来て戻したがっているかもしれません。 これがIPv6が番号を付け替えること[RFC4192]をネットワークでつなぐのと何も同じくらい複雑なものにかかわらないかもしれないことに注意してください。 それは、ホームのエージェントのアドレスを変えることをただ伴うかもしれません。 シグナリングメッセージで、サービスプロバイダーは、新しいホームのエージェントを探すためにモバイルノードを知らせることができました。
4. Home Agent Switch Message
4. ホームエージェントスイッチメッセージ
The Home Agent Switch message is used by the home agent to signal to the mobile node that it needs to stop acting as the home agent for the mobile node, and that it should acquire a new home agent. Home Agent Switch messages are sent as described in Section 5.
ホームエージェントSwitchメッセージは、モバイルノードのためのホームのエージェントとして務めるのを止めるのが必要であり、新しいホームのエージェントを取得するべきであるとモバイルノードに合図するのにホームのエージェントによって使用されます。 セクション5で説明されるようにホームエージェントSwitchメッセージを送ります。
The message described below follows the Mobility Header format specified in Section 6.1 of [RFC3775]:
以下で説明されたメッセージは[RFC3775]のセクション6.1で指定されたMobility Header形式に続きます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量プロト| ヘッダーレン| MHはタイプします。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . メッセージデータ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haley, et al. Standards Track [Page 4] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[4ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
The Home Agent Switch Message uses the MH Type value (12). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
ホームのエージェントSwitch MessageはMH Type値(12)を使用します。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of Addresses | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Mobility Options .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# アドレスについて| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +… ホームエージェントアドレス… + +| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +… 移動性オプション… + +| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# of Addresses
# アドレスについて
An 8-bit unsigned integer indicating the number of IPv6 home agent
addresses in the message. If set to zero, the mobile node MUST
perform home agent discovery.
メッセージのIPv6ホームエージェントアドレスの数を示す8ビットの符号のない整数。 ゼロに設定されるなら、モバイルノードはホームエージェント発見を実行しなければなりません。
Reserved
予約されます。
An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された8ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Home Agent Addresses
ホームエージェントアドレス
A list of alternate home agent addresses for the mobile node. The
number of addresses present in the list is indicated by the "# of
Addresses" field in the Home Agent Switch message.
モバイルノードのための代替のホームエージェントアドレスのリスト。 「リストの現在のアドレスの数が示される、」 #アドレスでは、」 ホームのエージェントSwitchの分野が通信します。
Haley, et al. Standards Track [Page 5] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[5ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
Mobility Options
移動性オプション
A Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options MUST follow the format specified in
Section 6.2 of [RFC3775]. The receiver MUST ignore and skip any
options that it does not understand.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さのVariable-長さの分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 定義されたオプションのコード化と形式は[RFC3775]のセクション6.2で指定された形式に続かなければなりません。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。
The Binding Refresh Advice mobility option defined in Section
6.2.4 of [RFC3775] is valid for the Home Agent Switch message.
ホームエージェントSwitchメッセージに、.4セクション6.2[RFC3775]で定義されたBinding Refresh Advice移動性オプションは有効です。
If no home agent addresses and no options are present in this message, no padding is necessary and the Header Len field in the Mobility Header will be set to zero.
ホームエージェントアドレスがなくてどんなオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Mobility HeaderのHeaderレン分野はゼロに設定されるでしょう。
5. Home Agent Operation
5. ホームエージェント操作
5.1. Sending Home Agent Switch Messages
5.1. 送付ホームエージェントスイッチメッセージ
When sending a Home Agent Switch message, the sending node constructs the packet as it would any other Mobility Header, except:
いかなる他のMobility Header、それは送るでしょう、したがって、ホームエージェントSwitchメッセージ、送付ノード構造物にパケットを送るときには、除いてください:
o The MH Type field MUST be set to (12).
o MH Type分野を(12)に設定しなければなりません。
o If alternative home agent addresses are known, the sending home
agent SHOULD include them in the list of suggested alternate
home agents. The home agent addresses field should be
constructed as described in Section 10.5.1 of [RFC3775], which
will randomize addresses of the same preference in the list.
o 代替のホームエージェントアドレスが知られているなら、送付ホームのエージェントSHOULDは提案された代替のホームのエージェントのリストにそれらを含んでいます。 アドレスがさばくホームのエージェントは.1セクション10.5[RFC3775](リストにおける同じ好みのアドレスをランダマイズする)で説明されるように組み立てられるべきです。
o The "# of Addresses" field MUST be filled-in corresponding to
the number of home agent addresses included in the message. If
no addresses are present, the field MUST be set to zero,
forcing the mobile node to perform home agent discovery by some
other means.
o 」 分野がそうしなければならないアドレスの#、は、メッセージにエージェントアドレスを含んで、ホームの数に対応しながら、いっぱいにされています。 どんなアドレスも存在していないなら、ゼロに分野を設定しなければなりません、モバイルノードにある他の手段でホームエージェント発見を実行させて。
o If the home agent is able to continue offering services to the
mobile node for some period of time, it MAY include a Binding
Refresh Advice mobility option indicating the time (in units of
4 seconds) until the binding will be deleted.
o ホームのエージェントが、いつかの期間の間、モバイルノードに対するサービスを提供し続けることができるなら、それは結合が削除されるまで時間(4秒の単位の)を示すBinding Refresh Advice移動性オプションを含むかもしれません。
The Home Agent Switch message MUST use the home agent to mobile node IPsec ESP (Encapsulating Security Payload) authentication SA (Security Association) for integrity protection.
ホームエージェントSwitchメッセージは保全保護にモバイルノードIPsec超能力(Securityが有効搭載量であるとカプセル化する)認証SA(セキュリティAssociation)のホームのエージェントを使用しなければなりません。
Haley, et al. Standards Track [Page 6] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[6ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
A home agent SHOULD send a Home Agent Switch message when a known period of unavailability is pending so the mobile node has sufficient time to find another suitable home agent.
知られている期間の使用不能が未定であるときにモバイルノードが別の適当なホームのエージェントを見つけることができるくらいの時間を過して、SHOULDがホームエージェントSwitchメッセージを送るホームのエージェント。
The sending node does not need to be the current home agent for the mobile node, for example as described in [hareliability], but it MUST have a security association with the mobile node so the message is not rejected. In this case, the Home Agent Switch message SHOULD only contain the address of the home agent sending the message in the Home Agent Addresses field, which implies that the mobile node should switch to using the sender as its new home agent.
送付ノードは、例えば、[hareliability]で説明されるようにモバイルノードのための現在のホームのエージェントである必要がありませんが、それにはモバイルノードとのセキュリティ協会がなければならないので、メッセージは拒絶されません。 この場合、ホームエージェントSwitchメッセージSHOULDはモバイルノードが新しいホームのエージェントとして送付者を使用するのに切り替わるはずであるのを含意するホームエージェントAddresses分野でメッセージを送るホームのエージェントのアドレスを含むだけです。
5.2. Retransmissions
5.2. Retransmissions
If the home agent does not receive a response from the mobile node -- either a Binding Update message to delete its home binding if it is the current home agent, or a Binding Update message to create a home binding if it is not the current home agent -- then it SHOULD retransmit the message until a response is received. The initial value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT.
ホームのエージェントがその時モバイルノード(ホームを削除するそれが現在のホームのエージェントであるなら付くBinding Updateメッセージ、または家庭を作るそれが現在のホームのエージェントでないなら付くBinding Updateメッセージ)からの応答を受けない、それ、応答が受け取られているまで、SHOULDはメッセージを再送します。 再送信タイマーのための初期の値はINITIAL-HA-SWITCH-TIMEOUTです。
The retransmissions by the home agent MUST use an exponential back- off mechanism, in which the timeout period is doubled upon each retransmission, until either the home agent gets a response from the mobile node to delete its binding, or the timeout period reaches the value MAX-HA-SWITCH-TIMEOUT. The home agent MAY continue to send these messages at this slower rate indefinitely.
ホームのエージェントによる「再-トランスミッション」は指数の逆オフメカニズムを使用しなければなりません、ホームのエージェントが結合を削除するためにモバイルノードから返事をもらうか、またはタイムアウト時間が値のマックス-HA-SWITCH-TIMEOUTに達するまで。(そこでは、タイムアウト時間が各「再-トランスミッション」で倍にされます)。 ホームのエージェントは、このより遅いレートでこれらのメッセージを無期限に送り続けるかもしれません。
If the home agent included a Binding Refresh Advice mobility option, then it SHOULD delay any retransmissions until at least one half of the time period has expired, or INITIAL-HA-SWITCH-TIMEOUT, whichever value is less.
ホームであるなら、エージェントはBinding Refresh Advice移動性オプションを入れて、次に、それは何か少なくとも期間の半分までの「再-トランスミッション」が吐き出したSHOULD遅れです、または、INITIAL-HA-SWITCH-TIMEOUT、どの値が、より少ないですか?
5.3. Mobile Node Errors
5.3. モバイルノード誤り
If a mobile node does not understand how to process a Home Agent Switch message, it will send a Binding Error message as described in Section 6.1.
モバイルノードがホームエージェントSwitchメッセージを処理する方法を理解していないと、それはセクション6.1で説明されるようにBinding Errorメッセージを送るでしょう。
If a mobile node is unreachable, in other words, it still has a home binding with the home agent after reaching the timeout period of MAX- HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions about its status.
モバイルノードが手が届かないなら、言い換えれば、まだホームをマックスHA-SWITCH-TIMEOUTのタイムアウト時間に達した後にホームのエージェントと共に拘束力があるようにしています、SHOULD NOTが状態に関するどんな結論も作るホームのエージェント。
In either case, the home agent SHOULD attempt to continue providing services until the lifetime of the binding expires.
どちらの場合ではも、ホームのエージェントSHOULDは、結合の寿命が期限が切れるまでサービスを提供し続けているのを試みます。
Haley, et al. Standards Track [Page 7] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[7ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
Attempts by the mobile node to extend the binding lifetime with a Binding Update message SHOULD be rejected, and a Binding Acknowledgement SHOULD be returned with status value 129 (Administratively prohibited) as specified in Section 6.1.8 of [RFC3775].
モバイルノードで、Binding UpdateメッセージSHOULDを拒絶して、指定されるとしての状態値129(行政上禁止されています)が.8セクション6.1[RFC3775]にある状態でBinding Acknowledgement SHOULDを返していて拘束力がある生涯を広げるのを試みます。
6. Mobile Node Operation
6. モバイルノード手術
6.1. Receiving Home Agent Switch Messages
6.1. ホームエージェントスイッチメッセージを受け取ります。
Upon receiving a Home Agent Switch message, the Mobility Header MUST be verified as specified in [RFC3775], specifically:
ホームエージェントSwitchメッセージ、Mobility Headerがそうしなければならない受信のときに、[RFC3775]で明確に指定されるように、確かめられてください:
o The Checksum, MH type, Payload Proto, and Header Len fields
MUST meet the requirements of Section 9.2 of [RFC3775].
o Checksum、MHタイプ、有効搭載量プロト、およびHeaderレン分野は[RFC3775]のセクション9.2に関する必要条件を満たさなければなりません。
o The packet MUST be covered by the home agent to mobile node
IPsec ESP authentication SA for integrity protection.
o 保全保護のためのモバイルノードIPsec超能力認証SAのホームのエージェントでパケットをカバーしていなければなりません。
If the packet is dropped due to the above tests, the receiving node MUST follow the processing rules as Section 9.2 of [RFC3775] defines. For example, it MUST send a Binding Error message with the Status field set to 2 (unrecognized MH Type value) if it does not support the message type.
パケットが上のテストのため下げられるなら、受信ノードは[RFC3775]のセクション9.2としての規則が定義する処理に続かなければなりません。 例えば、メッセージがタイプであるとサポートしないなら、それは2(認識されていないMH Type値)にStatus分野セットがあるBinding Errorメッセージを送らなければなりません。
Upon receipt of a Home Agent Switch message, the mobile node MUST stop using its current home agent for services and MUST delete its home binding by sending a Binding Update message as described in Section 11.7.1 of [RFC3775]. This acts as an acknowledgement of the Home Agent Switch message. Alternately, if the sender of the message is not the current home agent, sending a Binding Update message to create a home binding will act as an acknowledgement of the Home Agent Switch message. Retransmissions of Binding Update messages MUST use the procedures described in Section 11.8 of [RFC3775].
ホームエージェントSwitchメッセージを受け取り次第、モバイルノードは、.1セクション11.7[RFC3775]で説明されるようにサービスに現在のホームのエージェントを使用するのを止めなければならなくて、Binding Updateメッセージを送ることによって固まるホームを削除しなければなりません。 これはホームエージェントSwitchメッセージの承認として機能します。 交互に、メッセージ送信者が現在のホームのエージェントでないなら、拘束力があった状態でホームを作成するBinding Updateメッセージを送るのはホームエージェントSwitchメッセージの承認として機能するでしょう。 Binding UpdateメッセージのRetransmissionsは[RFC3775]のセクション11.8で説明された手順を用いなければなりません。
If a Binding Refresh Advice mobility option is present, the mobile node MAY delay the deletion of its home binding and continue to use its current home agent until the calculated time period has expired.
Binding Refresh Advice移動性オプションが存在しているなら、モバイルノードは、ホーム結合の削除を遅らせて、計算された期間が期限が切れるまで現在のホームのエージェントを使用し続けるかもしれません。
If the Home Agent Switch message contains a list of alternate home agent addresses, the mobile node SHOULD select a new home agent as described in Section 6.2, and establish the necessary IPsec security associations with the new home agent by whatever means required as part of the mobile node/home agent bootstrapping protocol for the home agent's mobility service provider. If no alternate home agent addresses are included in the list, the mobile node MUST first perform home agent discovery.
ホームエージェントSwitchメッセージが代替のホームエージェントアドレスのリストを含んでいるなら、モバイルノードSHOULDは手段がホームのエージェントの移動性サービスプロバイダーのためにモバイルノード/ホームエージェントブートストラップ法プロトコルの一部として必要としたことなら何でもセクション6.2で説明されるように新しいホームのエージェントを選んで、新しいホームのエージェントとの必要なIPsecセキュリティ仲間を設立します。 どんな代替のホームエージェントアドレスもリストに含まれていないなら、モバイルノードは最初に、ホームエージェント発見を実行しなければなりません。
Haley, et al. Standards Track [Page 8] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[8ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
6.2. Selecting a Home Agent
6.2. ホームのエージェントを選びます。
In most cases, the home agent addresses in the Home Agent Switch message will be of other home agents on the home link of the mobile node (the computed prefix is the same). In this case, the mobile node SHOULD select a new home agent from the addresses as they are ordered in the list. If the first address in the list is unable to provide service, then the subsequent addresses in the list should be tried in-order.
多くの場合、モバイルノードのホームのリンクの上に他のホームのエージェントにはホームエージェントSwitchメッセージのホームエージェントアドレスがあるでしょう(計算された接頭語は同じです)。 この場合、それらがリストで注文されるようにモバイルノードSHOULDはアドレスから新しいホームのエージェントを選びます。 リストにおける最初のアドレスがサービスを提供できないなら、リストのその後のアドレスはオーダーで試みられるべきです。
In the case that the home agent addresses in the Home Agent Switch message are not all home agents on the home link of the mobile node (the computed prefix is different), the mobile node SHOULD select one with its home network prefix first, if available, followed by home agents with other prefixes. Choosing a home agent with a different prefix might require a change of the home address for the mobile node, which could cause a loss of connectivity for any connections using the current home address.
ホームエージェントSwitchメッセージのホームエージェントアドレスが皆、モバイルノードのホームのリンクの上のホームのエージェント(計算された接頭語は異なっています)でなく利用可能であるなら、ホームネットワーク接頭語があるモバイルノードSHOULD選んだものは最初に、他の接頭語と共にホームのエージェントで続きました。 異なった接頭語でホームのエージェントを選ぶのはどんな接続のためにも現在のホームアドレスを使用することで接続性の損失をもたらすことができるだろうモバイルノードのためのホームアドレスの変化を必要とするかもしれません。
7. Operational Considerations
7. 操作上の問題
This document does not specify how an operator might use the Home Agent Switch message in its network. However, the following requirements are placed on its usage:
このドキュメントはオペレータがネットワークにどうホームエージェントSwitchメッセージを使用するかもしれないかを指定しません。 しかしながら、以下の要件は用法に置かれます:
o The use of this message needs to take into account possible
signaling overhead, congestion, load from the mechanism itself,
and the resulting registration to another home agent. A home
agent may provide service for thousands, if not millions, of
mobile nodes. Careless application of the Home Agent Switch
message may cause the new home agent, or some other parts of
the network, to suffer. As a result, it is REQUIRED that
applications of this message either employ a feedback loop
between resources of the new home agent and the sending of
additional Home Agent Switch messages, or apply a maximum rate
at which mobile nodes can be informed of the switch that is far
below the designated capacity of new registrations that the set
of home agents can process. If no other information is
available, this maximum rate should default to MAX-HA-SWITCH-
TRANSMIT-RATE.
o このメッセージの使用は、可能なシグナリングオーバーヘッドを考慮に入れる必要があります、混雑、メカニズム自体、および結果として起こる登録から別のホームのエージェントまでの負荷。 ホームのエージェントはモバイルノードの数千(数百万でなくても)のためのサービスを提供するかもしれません。 ホームエージェントSwitchメッセージの不注意なアプリケーションが新しいホームのエージェント、またはネットワークのある他の部分を引き起こすかもしれない、受けるために。 その結果、このメッセージのアプリケーションが新しいホームのエージェントのリソースと追加ホームエージェントSwitchメッセージの発信の間のフィードバックループを使うか、または遠くに新しい登録証明書の指定された容量より下であるにはあるスイッチについてホームのエージェントのセットが処理されることができるとモバイルノードを知らすことができる最高率を当てはまるのが、REQUIREDです。 他のどんな情報も利用可能でないなら、この最高率はマックス-HA-SWITCH- TRANSMIT-RATEをデフォルトとするべきです。
o In general, switching the home agent of a mobile node should
only be done when absolutely necessary, since it might cause a
service disruption if the switch to a new home agent fails, the
new home agent is itself under an overload condition, or the
network connection of the new home agent is congested.
o 絶対に必要です、新しいホームのエージェントへのスイッチが失敗するならサービスの崩壊を引き起こすかもしれないので新しいホームのエージェントがそれ自体で過負荷条件でいるか、または新しいホームのエージェントのネットワーク接続が混雑しているときだけ、一般に、モバイルノードのホームのエージェントは切り換えられるべきです。
Haley, et al. Standards Track [Page 9] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[9ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
Similarly, the path characteristics via the new home agent may
be different, which may cause temporary difficulties for end-
to-end transport layer operation.
同様に、新しいホームのエージェントを通した経路特性は異なっているかもしれません(終わりまでの終わりのトランスポート層操作のために一時的な困難を引き起こすかもしれません)。
o If this message is being used for load-balancing between a set
of home agents, they should all be configured with the same set
of prefixes so a home agent switch does not require a change of
the home address for a mobile node. That operation is NOT
RECOMMENDED and should be avoided.
o このメッセージが1セットのホームのエージェントの間の負荷分散に使用されているなら、彼らが皆、同じセットの接頭語によって構成されるべきであるので、ホームエージェントスイッチはモバイルノードのためのホームアドレスの変化を必要としません。 その操作は、NOT RECOMMENDEDであり、避けられるべきです。
8. Protocol Constants
8. プロトコル定数
INITIAL-HA-SWITCH-TIMEOUT 5 seconds MAX-HA-SWITCH-TIMEOUT 20 seconds MAX-HA-SWITCH-TRANSMIT-RATE 1 per second
1秒あたりINITIAL-HA-SWITCH-TIMEOUT5秒マックス-HA-SWITCH-TIMEOUT20秒マックス-HA-SWITCH-TRANSMIT-RATE1
9. IANA Considerations
9. IANA問題
IANA has assigned a new Mobility Header type for the following new message described in Section 4:
IANAはセクション4で説明された以下の新しいメッセージのために新しいMobility Headerにタイプを選任しました:
(12) Home Agent Switch message
(12) ホームエージェントSwitchメッセージ
10. Security Considerations
10. セキュリティ問題
As with other messages in [RFC3775], the Home Agent Switch message MUST use the home agent to mobile node ESP encryption SA for confidentiality protection, and MUST use the home agent to mobile node ESP authentication SA for integrity protection.
他のメッセージは[RFC3775]にある場合、ホームエージェントSwitchメッセージは、秘密性保護にモバイルノード超能力暗号化SAにホームのエージェントを使用しなければならなくて、保全保護にモバイルノード超能力認証SAにホームのエージェントを使用しなければなりません。
The Home Agent Switch message MAY use the IPsec ESP SA in place for Binding Updates and Acknowledgements, as specified in Section 5.1 of [RFC3775], in order to reduce the number of configured security associations. This also gives the message authenticity protection.
ホームエージェントSwitchメッセージはBinding UpdatesとAcknowledgementsに適所でIPsec ESP SAを使用するかもしれません、[RFC3775]のセクション5.1で指定されるように、構成されたセキュリティ協会の数を減少させるために。 また、これはメッセージ信憑性保護を与えます。
Some operators may not want to reveal the list of home agents to on- path listeners. In such a case, the Home Agent Switch message should use the home agent to mobile node IPsec ESP encryption SA for confidentiality protection.
何人かのオペレータがホームのエージェントのリストを明らかにしたがっていないかもしれない、オンである、経路リスナー。 このような場合には、ホームエージェントSwitchメッセージは秘密性保護にモバイルノードIPsec超能力暗号化SAのホームのエージェントを使用するべきです。
Haley, et al. Standards Track [Page 10] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[10ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
11.2. Informative References
11.2. 有益な参照
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC
4192, September 2005.
[RFC4192] ベイカー、F.、リア、E.、およびR.Droms、「国旗制定記念日なしでIPv6ネットワークに番号を付け替えさせるための手順」、RFC4192(2005年9月)。
[hareliability] Wakikawa, R., Ed., "Home Agent Reliability Protocol",
Work in Progress, November 2007.
[hareliability] Wakikawa、R.、エド、「ホームエージェント信頼性のプロトコル」、処理中の作業、11月2007
Acknowledgments
承認
We would like to thank the authors of a number of previous documents that contributed content to this RFC:
このRFCに内容を寄付した前の多くのドキュメントの作者に感謝申し上げます:
o Ryuji Wakikawa, Pascal Thubert, and Vijay Devarapalli,
"Inter Home Agents Protocol Specification", March 2006.
o 龍治Wakikawa、パスカルThubertとビジェイDevarapalli、「間のホームエージェントプロトコル仕様」、2006年3月。
o Hui Deng, Brian Haley, Xiaodong Duan, Rong Zhang, and Kai Zhang,
"Load Balance for Distributed Home Agents in Mobile IPv6",
October 2004.
o ホイ・?、ブライアン・ヘイリー、シャオドンDuan(ロン・チャン、およびカイ・チャン)は「モバイルIPv6"、2004年10月に分配されたホームのエージェントのためにバランスをロードします」。
o James Kempf, "Extension to RFC 3775 for Alerting the Mobile Node
to Home Agent Unavailability", October 2005.
o ジェームス・ケンフ、「ホームエージェント使用不能へのモバイルノードを警告するためのRFC3775への拡大」、2005年10月。
o Brian Haley and Sri Gundavelli, "Mobility Header Signaling
Message", September 2007.
o ブライアン・ヘイリーと様のGundavelli、「移動性ヘッダーシグナリングメッセージ」、2007年9月。
Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni Korhonen, and Wolfgang Fritsche for their review and feedback.
また、それらのレビューとフィードバックをキリアン・ウェニガー、Jixingリュウ、Alexandruペトレスク、Jouni Korhonen、およびウォルフギャング・フリッチェをありがとうございます。
Haley, et al. Standards Track [Page 11] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[11ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
Author's Addresses
作者のアドレス
Brian Haley Hewlett-Packard Company 110 Spitbrook Road Nashua, NH 03062, USA EMail: brian.haley@hp.com
ブライアンヘイリーヒューレット・パッカード社110のSpitbrook Roadナッシュア、ニューハンプシャー 03062、米国はメールされます: brian.haley@hp.com
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA EMail: vijay.devarapalli@azairenet.com
ビジェイDevarapalli Azaireは3121年のジェイ通りカリフォルニア95054サンタクララ(米国)EMailをネットワークでつなぎます: vijay.devarapalli@azairenet.com
James Kempf DoCoMo USA Labs 181 Metro Drive Suite 300 San Jose, CA 95110 USA EMail: kempf@docomolabs-usa.com
ジェームスケンフDoCoMo米国研究室181地下鉄ドライブSuite300カリフォルニア95110サンノゼ(米国)はメールされます: kempf@docomolabs-usa.com
Hui Deng China Mobile 53A, Xibianmennei Ave. Xuanwu District Beijing 100053 China EMail: denghui@chinamobile.com
ホイ・中国の?のモバイル53A、Xibianmennei Ave。 Xuanwu地区北京100053中国メール: denghui@chinamobile.com
Haley, et al. Standards Track [Page 12] RFC 5142 Home Agent Switch Message January 2008
ヘイリー、他 標準化過程[12ページ]RFC5142はエージェントスイッチメッセージ2008年1月に家へ帰ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Haley, et al. Standards Track [Page 13]
ヘイリー、他 標準化過程[13ページ]
一覧
スポンサーリンク
