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
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
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
家庭代理可能被认为超载的原因有很多。一种可能是，它已经达到或接近它愿意接受的家庭绑定数量的极限。另一个原因是，它已经达到了预先确定的系统资源使用水平——内存、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.
home agent可能知道其他home agent的负载没有它自己那么重，这是通过本文档范围之外的其他机制了解到的。运营商可能希望尝试平衡此负载，以便故障会中断较小比例的移动节点。
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归属代理为移动节点提供两种基本服务。它充当会合服务器，通信节点可在其中找到移动节点的当前转交地址，并充当覆盖路由器，以隧道方式在移动节点当前转交地址处进出移动节点的流量。
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.
移动服务提供商可以有两组家庭代理来处理这两项功能。集合功能可以由专门用于高速事务处理的机器处理，而覆盖路由器功能可以由具有高数据吞吐量的机器处理。
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.
移动节点将在会合服务器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.
移动服务提供商可能会定期关闭一组IPv6地址处的归属代理服务，并在一组新地址处恢复服务。注意，这可能不涉及IPv6网络重新编号[RFC4192]这样复杂的事情；这可能只涉及更改家庭代理的地址。通过信令消息，服务提供商可以通知移动节点寻找新的归属代理。
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
一个8位无符号整数，指示消息中IPv6归属代理地址的数量。如果设置为零，移动节点必须执行归属代理发现。
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.
移动节点的备用归属代理地址列表。列表中的地址数由归属代理交换机消息中的“#of addresses”（地址数）字段表示。
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.
如果此消息中不存在归属代理地址和选项，则无需填充，并且移动报头中的报头Len字段将设置为零。
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 必须根据消息中包含的归属代理地址数填写“#of Addresses”字段。如果不存在地址，则必须将该字段设置为零，从而强制移动节点通过其他方式执行归属代理发现。
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.
如果归属代理未收到来自移动节点的响应（如果它是当前归属代理，则为删除其归属绑定的绑定更新消息，如果它不是当前归属代理，则为创建归属绑定的绑定更新消息），则它应重新传输该消息，直到收到响应为止。重传计时器的初始值为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.
归属代理的重传必须使用指数退避机制，其中超时时间在每次重传时加倍，直到归属代理从移动节点获得删除其绑定的响应，或者超时时间达到值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.
如果归属代理包括绑定刷新建议移动选项，那么它应该延迟任何重新传输，直到至少一半的时间段过期，或者初始HA-SWITCH-TIMEOUT，以较小的值为准。
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
初始-HA-SWITCH-超时5秒最大-HA-SWITCH-超时20秒最大-HA-SWITCH-传输速率每秒1
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 37752004年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 41922005年9月。
[hareliability] Wakikawa, R., Ed., "Home Agent Reliability Protocol", Work in Progress, November 2007.
[hareliability]Wakikawa，R.，Ed.，“归属代理可靠性协议”，正在进行的工作，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 Wakikawa Ryuji、Pascal Thubert和Vijay 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 邓辉，布莱恩·海利，段晓东，张荣和张凯，“移动IPv6中分布式家庭代理的负载平衡”，2004年10月。
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 Brian Haley和Sri Gundavelli，“移动头信令消息”，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
Brian Haley Hewlett-Packard Company美国新罕布什尔州纳舒亚市斯皮布鲁克路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美国电子邮件：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美国实验室181 Metro Drive Suite 300加利福尼亚州圣何塞95110美国电子邮件：kempf@docomolabs-美国网
Hui Deng China Mobile 53A, Xibianmennei Ave. Xuanwu District Beijing 100053 China EMail: denghui@chinamobile.com
惠登中国移动北京市宣武区西边门内大街53A邮编：100053中国电子邮件：denghui@chinamobile.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.