[要約] RFC 5142は、モビリティヘッダーホームエージェントスイッチメッセージに関する仕様です。このRFCの目的は、モバイルノードがホームエージェントを切り替える際の手順とメッセージフォーマットを定義することです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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.
このドキュメントは、ホームエージェントとモバイルノードの間で使用できる新しいモビリティヘッダーメッセージタイプを指定して、新しいホームエージェントを取得することをモバイルノードに信号します。
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
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.
RFC 3775 [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.
このプロトコルは、ホームエージェントとモバイルノードの間にハンドオフ通知を送信するために使用できるホームエージェントスイッチメッセージと呼ばれるシグナルメッセージを記述します。
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:
ホームエージェントスイッチメッセージは、モバイルノードのホームエージェントの変更に関連するすべての一般的な問題を解決しようとしません。特に、このプロトコルは解決しようとはしません。
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 モバイルノードのホームアドレスが新しいホームエージェントに切り替えるために変更する必要がある場合。この操作は、このメッセージを使用して回避する必要があります。
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]で説明されているように、バックエンドプロトコルによって行われるべきです。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Here are some example scenarios where a home agent signaling message would be useful.
ホームエージェントのシグナリングメッセージが役立つシナリオの例を次に示します。
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つは、それが受け入れたいと思う家のバインディングの数の制限にある、または近くにあるということかもしれません。もう1つは、メモリ、CPUサイクルなどの事前に決定されたレベルのシステムリソースの使用に達したことです。どちらの場合も、障害が発生する前にホームエージェントがホームバインディングの数を減らすことが望ましいことです。
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.
ホームエージェントは、このドキュメントの範囲外の他のメカニズムを通じて学んだ他のホームエージェントを知っているかもしれません。オペレーターは、障害がモバイルノードの割合が少なくなるように、この負荷のバランスをとることをお勧めします。
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.
ほとんどのオペレーターは、信頼性を維持するために定期的なメンテナンスを行います。ホームエージェントがメンテナンスのためにシャットダウンされている場合、モビリティサービスを失わないようにモバイルノードに通知することが望ましいでしょう。
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つの基本サービスを備えたモバイルノードを提供します。これは、特派員ノードがモバイルノードの現在のケアアドレスを見つけることができるランデブーサーバーとして機能し、現在のケアのケアでモバイルノードに出入りするトラフィックをトンネルするためのオーバーレイルーターとして機能します。
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.
モバイルノードは、Rendezvous Server Home Agentで開始し、ルート最適化を行う場合はそこにとどまります。ただし、元のホームエージェントがモバイルノードがルートの最適化を行っていないことを検出した場合、代わりにトラフィックを逆転させると、モバイルノードをより良いデータスループットでホームエージェントにリダイレクトする可能性があります。
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.
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.
ホームエージェントスイッチメッセージは、ホームエージェントがモバイルノードのモバイルノードの動作を停止する必要があること、および新しいホームエージェントを取得する必要があることをモバイルノードに信号するために使用されます。ホームエージェントスイッチメッセージは、セクション5で説明されているように送信されます。
The message described below follows the Mobility Header format specified in Section 6.1 of [RFC3775]:
以下に説明するメッセージは、[RFC3775]のセクション6.1で指定されているモビリティヘッダー形式に従います。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
ホームエージェントスイッチメッセージは、MHタイプ値（12）を使用します。この値がMHタイプフィールドに示されている場合、モビリティヘッダーのメッセージデータフィールドの形式は次のとおりです。
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 .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# 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.
モバイルノードの代替ホームエージェントアドレスのリスト。リストに存在するアドレスの数は、ホームエージェントスイッチメッセージの「アドレスの＃」フィールドで示されています。
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.
完全なモビリティヘッダーが長さ8オクターの整数倍であるような長さの可変長いフィールド。このフィールドには、ゼロ以上の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.
[RFC3775]のセクション6.2.4で定義されているバインディングリフレッシュアドバイスモビリティオプションは、ホームエージェントスイッチメッセージに有効です。
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.
ホームエージェントがこのメッセージに存在しない場合、このメッセージにオプションが存在しない場合、パディングは必要ありません。モビリティヘッダーのヘッダーレンフィールドはゼロに設定されます。
When sending a Home Agent Switch message, the sending node constructs the packet as it would any other Mobility Header, except:
ホームエージェントスイッチメッセージを送信するとき、送信ノードは、他のモビリティヘッダーと同様にパケットを構築します。
o The MH Type field MUST be set to (12).
o MHタイプフィールドは（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 代替ホームエージェントアドレスが既知である場合、送信ホームエージェントには、提案された代替ホームエージェントのリストにそれらを含める必要があります。ホームエージェントのアドレスフィールドは、[RFC3775]のセクション10.5.1で説明されているように構築する必要があります。
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秒単位単位）ことを示すバインディングリフレッシュアドバイスモビリティオプションが含まれる場合があります。
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.
ホームエージェントスイッチメッセージは、ホームエージェントを使用して、整合性保護のためにモバイルノードIPSEC ESP（セキュリティペイロードをカプセル化）認証SA（セキュリティ協会）に使用する必要があります。
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.
ホームエージェントは、既知の利用不能期間が保留されている場合、ホームエージェントスイッチメッセージを送信する必要があります。そうすれば、モバイルノードが別の適切なホームエージェントを見つけるのに十分な時間があります。
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]で説明されているように、モバイルノードの現在のホームエージェントである必要はありませんが、メッセージが拒否されないため、モバイルノードとセキュリティ関連が必要です。この場合、ホームエージェントスイッチメッセージには、ホームエージェントアドレスのフィールドにメッセージを送信するホームエージェントのアドレスのみを含める必要があります。これは、モバイルノードが新しいホームエージェントとして送信者の使用に切り替える必要があることを意味します。
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.
ホームエージェントがモバイルノードから応答を受け取らない場合 - 現在のホームエージェントである場合はホームバインディングを削除するためのバインディングアップデートメッセージ、または現在のホームではない場合はホームバインディングを作成するバインディングアップデートメッセージのいずれかエージェント - それから、応答が受信されるまでメッセージを再送信する必要があります。再送信タイマーの初期値は、初期HAスイッチタイムアウトです。
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.
ホームエージェントによる再送信は、ホームエージェントがモバイルノードから応答を取得してバインディングを削除するか、タイムアウト期間が値に達するまで、各再送信時にタイムアウト期間を2倍にする指数バックオフメカニズムを使用する必要があります。Max-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.
ホームエージェントにバインディングリフレッシュアドバイスモビリティオプションが含まれている場合、少なくとも半分の期間が期限切れになるまで再送信を遅らせる必要があります。
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.
モバイルノードがホームエージェントスイッチメッセージの処理方法を理解していない場合、セクション6.1で説明されているように、バインディングエラーメッセージが送信されます。
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.
言い換えれば、モバイルノードが到達不可能である場合、Max-Ha-Switch-Timeoutのタイムアウト期間に到達した後、ホームエージェントとのホームバインディングがあります。ホームエージェントは、そのステータスについて結論を出すべきではありません。
In either case, the home agent SHOULD attempt to continue providing services until the lifetime of the binding expires.
どちらの場合でも、ホームエージェントは、バインディングの寿命が切れるまでサービスの提供を継続しようとする必要があります。
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].
バインディングアップデートメッセージでバインディング寿命を延長するためのモバイルノードによる試みは拒否されるべきであり、[RFC3775]のセクション6.1.8で指定されているように、ステータス値129（管理上禁止）でバインディングの承認を返す必要があります。
Upon receiving a Home Agent Switch message, the Mobility Header MUST be verified as specified in [RFC3775], specifically:
ホームエージェントスイッチメッセージを受信すると、モビリティヘッダーは[RFC3775]で指定されているように検証する必要があります。
o The Checksum, MH type, Payload Proto, and Header Len fields MUST meet the requirements of Section 9.2 of [RFC3775].
o チェックサム、MHタイプ、ペイロードプロト、およびヘッダーLENフィールドは、[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 ESP認証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タイプ値）に設定してバインディングエラーメッセージを送信する必要があります。
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].
ホームエージェントスイッチメッセージを受信すると、モバイルノードはサービス用の現在のホームエージェントの使用を停止する必要があり、[RFC3775]のセクション11.7.1で説明されているように、バインディングアップデートメッセージを送信してホームバインディングを削除する必要があります。これは、ホームエージェントスイッチメッセージの承認として機能します。あるいは、メッセージの送信者が現在のホームエージェントではない場合、バインディングアップデートメッセージを送信してホームバインディングを作成すると、ホームエージェントスイッチメッセージの承認として機能します。バインディングアップデートメッセージの再送信は、[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.
バインディングリフレッシュアドバイスモビリティオプションが存在する場合、モバイルノードはホームバインディングの削除を遅らせ、計算期間が切れるまで現在のホームエージェントを使用し続ける可能性があります。
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.
ホームエージェントスイッチメッセージに代替ホームエージェントアドレスのリストが含まれている場合、モバイルノードはセクション6.2で説明されているように新しいホームエージェントを選択し、必要な手段によって必要なIPSECセキュリティ関連を新しいホームエージェントと確立する必要があります。ホームエージェントのモビリティサービスプロバイダー向けのモバイルノード/ホームエージェントブートストラッププロトコル。代替ホームエージェントアドレスがリストに含まれていない場合、モバイルノードは最初にホームエージェントの発見を実行する必要があります。
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.
ほとんどの場合、ホームエージェントのスイッチメッセージのホームエージェントアドレスは、モバイルノードのホームリンク上の他のホームエージェントのものです（計算されたプレフィックスは同じです）。この場合、モバイルノードは、リストに注文されたアドレスから新しいホームエージェントを選択する必要があります。リストの最初のアドレスがサービスを提供できない場合、リスト内の後続のアドレスを注文してみる必要があります。
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.
ホームエージェントがホームエージェントスイッチメッセージにアドレス指定する場合、モバイルノードのホームリンクのすべてのホームエージェントではない場合（計算されたプレフィックスは異なります）、モバイルノードはホームネットワークのプレフィックスを使用して最初に選択する必要があります。、他のプレフィックスを備えたホームエージェントが続きます。別のプレフィックスを持つホームエージェントを選択するには、モバイルノードのホームアドレスの変更が必要になる場合があります。これにより、現在のホームアドレスを使用して接続の接続が失われる可能性があります。
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:
このドキュメントでは、オペレーターがネットワーク内のホームエージェントスイッチメッセージを使用する方法を指定していません。ただし、次の要件が使用されています。
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 このメッセージの使用は、頭上のシグナリングの可能性、混雑、メカニズム自体からの負荷、および結果として生じる別のホームエージェントへの登録を考慮する必要があります。ホームエージェントは、数百万のモバイルノードではないにしても数千のサービスを提供する場合があります。ホームエージェントスイッチメッセージの不注意な適用により、新しいホームエージェント、またはネットワークの他の部分が苦しむ可能性があります。その結果、このメッセージのアプリケーションは、新しいホームエージェントのリソースと追加のホームエージェントスイッチメッセージの送信との間のフィードバックループを使用するか、モバイルノードにスイッチを通知できる最大レートを適用する必要があります。ホームエージェントのセットが処理できる新しい登録の指定容量をはるかに下回っています。他の情報が利用できない場合、この最大レートはデフォルトでMax-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 一般に、モバイルノードのホームエージェントの切り替えは、新しいホームエージェントへの切り替えが失敗した場合、新しいホームエージェント自体が過負荷状態、またはネットワークの状態である場合にサービスの混乱を引き起こす可能性があるため、絶対に必要な場合にのみ実行する必要があります。新しいホームエージェントの接続は混雑しています。
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 このメッセージがホームエージェントのセット間で負荷分散に使用されている場合、それらはすべて同じプレフィックスセットで構成する必要があるため、ホームエージェントスイッチはモバイルノードのホームアドレスの変更を必要としません。その操作は推奨されず、避けるべきです。
INITIAL-HA-SWITCH-TIMEOUT 5 seconds
MAX-HA-SWITCH-TIMEOUT 20 seconds
MAX-HA-SWITCH-TRANSMIT-RATE 1 per second
IANA has assigned a new Mobility Header type for the following new message described in Section 4:
IANAは、セクション4で説明されている次の新しいメッセージに新しいモビリティヘッダータイプを割り当てました。
(12) Home Agent Switch message
（12）ホームエージェントスイッチメッセージ
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]の他のメッセージと同様に、ホームエージェントスイッチメッセージは、秘密保護のためにホームエージェントをモバイルノードESP暗号化SAに使用する必要があり、整合性保護のためにモバイルノードESP認証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.
ホームエージェントスイッチメッセージは、構成されたセキュリティ関連の数を減らすために、[RFC3775]のセクション5.1で指定されているように、バインディングの更新と承認のためにIPSEC ESP SAを使用する場合があります。これにより、メッセージの信頼性保護も与えられます。
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.
一部のオペレーターは、ホームエージェントのリストをパスオンパスリスナーに公開したくない場合があります。このような場合、ホームエージェントスイッチメッセージは、機密性保護のためにホームエージェントをモバイルノードIPSEC ESP暗号化SAに使用する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192] Baker、F.、Lear、E。、およびR. Droms、「フラグデーなしでIPv6ネットワークを変更するための手順」、RFC 4192、2005年9月。
[hareliability] Wakikawa, R., Ed., "Home Agent Reliability Protocol", Work in Progress, November 2007.
[Hareliability] Wakikawa、R.、ed。、「Home Agent Reliability Protocol」、Work in Progress、2007年11月。
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 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 Hui Deng、Brian Haley、Xiaodong Duan、Rong Zhang、およびKai Zhang、2004年10月、モバイルIPv6の分散型ホームエージェントの負荷バランス」。
o James Kempf, "Extension to RFC 3775 for Alerting the Mobile Node to Home Agent Unavailability", October 2005.
o James Kempf、「モバイルノードをホームエージェントにアレールして、利用不可能性を告げるためのRFC 3775への拡張」、2005年10月。
o Brian Haley and Sri Gundavelli, "Mobility Header Signaling Message", September 2007.
o 2007年9月、ブライアン・ヘイリーとスリ・ガンダヴェリ、「モビリティヘッダーシグナル伝達メッセージ」。
Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni Korhonen, and Wolfgang Fritsche for their review and feedback.
Kilian Weniger、Jixing Liu、Alexandru Petrescu、Jouni Korhonen、Wolfgang Fritscheのレビューとフィードバックにも感謝します。
Author's Addresses
著者のアドレス
Brian Haley Hewlett-Packard Company 110 Spitbrook Road Nashua, NH 03062, USA EMail: brian.haley@hp.com
ブライアンヘイリーヒューレットパッカードカンパニー110スピットブルックロードナシュア、ニューハンプシャー州03062、米国メール：brian.haley@hp.com
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA EMail: vijay.devarapalli@azairenet.com
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara、CA 95054 USAメール：vijay.devarapalli@azairenet.com
James Kempf DoCoMo USA Labs 181 Metro Drive Suite 300 San Jose, CA 95110 USA EMail: kempf@docomolabs-usa.com
James Kempf Docomo USA Labs 181 Metro Drive Suite 300 San Jose、CA 95110 USAメール：kempf@docomolabs-usa.com
Hui Deng China Mobile 53A, Xibianmennei Ave. Xuanwu District Beijing 100053 China EMail: denghui@chinamobile.com
Hui Deng China Mobile 53a、Xibianmennei Ave. Xuanwu District Beijing 100053 China Email：denghui@chinamobile.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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への情報をお問い合わせください。