Network Working Group M. Kulkarni
Request for Comments: 4433 A. Patel
Category: Standards Track K. Leung
Cisco Systems Inc.
March 2006
Network Working Group M. Kulkarni
Request for Comments: 4433 A. Patel
Category: Standards Track K. Leung
Cisco Systems Inc.
March 2006
Mobile IPv4 Dynamic Home Agent (HA) Assignment
移动IPv4动态归属代理（HA）分配
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection.
移动IPv4（RFC 3344）使用归属代理（HA）来锚定漫游移动节点（MN）的会话。本文提出了一种用于动态归属代理分配和HA重定向的消息传递机制。目标是提供一种机制，为移动IP会话分配最佳HA，同时允许任何合适的HA选择方法。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Terminology ........................................3
3. Problem Statement ...............................................5
3.1. Scope ......................................................5
3.2. Dynamic Home Agent Discovery in Mobile IPv4 ................5
3.3. NAI Usage and Dynamic HA Assignment ........................6
3.4. Dynamic HA Extension .......................................6
3.4.1. Requested HA Extension ..............................7
3.4.2. Redirected HA Extension .............................7
4. Messaging Mechanism for Dynamic HA Assignment/Redirection .......7
4.1. Messaging for Dynamic HA Assignment ........................7
4.1.1. Example with Message Flow Diagram ...................8
4.2. Messaging for HA Redirection ..............................10
4.2.1. Example with Message Flow Diagram ..................12
5. Mobility Agent Considerations ..................................14
5.1. Mobile Node Considerations ................................14
5.1.1. MN Using FA CoA ....................................14
5.1.2. MN Using Co-Located CoA ............................15
5.1.3. Refreshing Assigned HA Address on Mobile Node ......16
5.2. Foreign Agent Considerations ..............................16
5.3. Home Agent Considerations .................................17
5.3.1. Assigned Home Agent Considerations .................17
6. Requested Home Agent Selection .................................19
7. Error Values ...................................................20
8. IANA Considerations ............................................20
9. Security Considerations ........................................20
10. Backward-Compatibility Considerations .........................21
11. Acknowledgements ..............................................23
12. Normative References ..........................................23
1. Introduction ....................................................3
2. Requirements Terminology ........................................3
3. Problem Statement ...............................................5
3.1. Scope ......................................................5
3.2. Dynamic Home Agent Discovery in Mobile IPv4 ................5
3.3. NAI Usage and Dynamic HA Assignment ........................6
3.4. Dynamic HA Extension .......................................6
3.4.1. Requested HA Extension ..............................7
3.4.2. Redirected HA Extension .............................7
4. Messaging Mechanism for Dynamic HA Assignment/Redirection .......7
4.1. Messaging for Dynamic HA Assignment ........................7
4.1.1. Example with Message Flow Diagram ...................8
4.2. Messaging for HA Redirection ..............................10
4.2.1. Example with Message Flow Diagram ..................12
5. Mobility Agent Considerations ..................................14
5.1. Mobile Node Considerations ................................14
5.1.1. MN Using FA CoA ....................................14
5.1.2. MN Using Co-Located CoA ............................15
5.1.3. Refreshing Assigned HA Address on Mobile Node ......16
5.2. Foreign Agent Considerations ..............................16
5.3. Home Agent Considerations .................................17
5.3.1. Assigned Home Agent Considerations .................17
6. Requested Home Agent Selection .................................19
7. Error Values ...................................................20
8. IANA Considerations ............................................20
9. Security Considerations ........................................20
10. Backward-Compatibility Considerations .........................21
11. Acknowledgements ..............................................23
12. Normative References ..........................................23
This document adds to the Mobile IP protocol [1], by proposing a messaging mechanism for dynamic home agent assignment and home agent redirection during initial registration. The goal is to assign an optimal HA for a Mobile IP session. The mobile node MUST use the Network Access Identifier (NAI) extension [2] when requesting a dynamically assigned HA.
本文档通过在初始注册期间为动态归属代理分配和归属代理重定向提出消息传递机制，对移动IP协议[1]进行了补充。目标是为移动IP会话分配最佳HA。当请求动态分配的HA时，移动节点必须使用网络访问标识符（NAI）扩展[2]。
The MN requests a dynamically assigned HA by setting the HA field in the initial Registration Request to ALL-ZERO-ONE-ADDR (defined in Section 2). If the request is accepted, the HA sends a successful Registration Reply containing the HA's own address. The requested HA can suggest an alternate HA and if so, the Registration Reply is rejected with a new error code REDIRECT-HA-REQ and the alternate HA address is specified in a new extension (Redirected HA Extension).
MN通过将初始注册请求中的HA字段设置为ALL-ZERO-ONE-ADDR（在第2节中定义），请求动态分配的HA。如果请求被接受，医管局将发送包含医管局自己地址的成功注册回复。请求的HA可以建议一个备用HA，如果是，注册回复将被拒绝，并显示一个新的错误代码REDIRECT-HA-REQ，备用HA地址将在一个新扩展（重定向的HA扩展）中指定。
This document also defines a new Requested HA Extension for use in Registration Requests when the HA field is set to ALL-ZERO-ONE-ADDR. The Requested HA address is a hint to the network about the MN's preferred HA.
本文档还定义了一个新的请求的HA扩展，当HA字段设置为ALL-ZERO-ONE-ADDR时，用于注册请求。请求的HA地址是对网络的关于MN首选HA的提示。
The messaging mechanism is defined in this document so that the MN can request and receive a dynamic HA address in Mobile IP messages. However, the mechanism by which the network selects an HA for assignment to the MN is outside the scope of this document. For example, the selection may be made by any network node that receives the Registration Request (or information about the Registration Request), such as a Foreign Agent, AAA server, or home agent. The node that selects the HA may select one based on a number of criteria, including but not limited to HA load-balancing, geographical proximity, administrative policy, etc.
本文档中定义了消息传递机制，以便MN可以在移动IP消息中请求和接收动态HA地址。然而，网络选择HA以分配给MN的机制不在本文档的范围内。例如，可以由接收注册请求（或关于注册请求的信息）的任何网络节点进行选择，例如外部代理、AAA服务器或归属代理。选择HA的节点可以基于多个标准选择一个，包括但不限于HA负载平衡、地理邻近性、管理策略等。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
The Mobile-IP-related terminology described in RFC 3344 [1] is used in this document. In addition, the following terms are used:
本文件使用RFC 3344[1]中描述的移动IP相关术语。此外，还使用了以下术语：
ALL-ZERO-ONE-ADDR: IP address 0.0.0.0 or 255.255.255.255. An address of 255.255.255.255 indicates a preference for an HA in the home domain. An address of 0.0.0.0 indicates no preference for home vs. visited domain.
全零一地址：IP地址0.0.0.0或255.255.255.255。地址255.255.255.255表示首选主域中的HA。地址为0.0.0.0表示不偏好家庭域或访问域。
Requested HA: Destination IP address of home agent that the Registration Request is sent to. Must be a unicast IP address. This address can be obtained as described in Section 6.
请求的HA：注册请求发送到的归属代理的目标IP地址。必须是单播IP地址。如第6节所述，可获得该地址。
Note that this specification defines a new "Requested HA Extension" in Section 3.4, which is different from the term "Requested HA".
请注意，本规范在第3.4节中定义了一个新的“请求的HA扩展”，它与术语“请求的HA”不同。
Assigned HA: The HA that accepts an MN's Registration Request and returns a successful Registration Reply.
分配HA：接受MN注册请求并返回成功注册回复的HA。
Redirected HA: If the registration is rejected with error code REDIRECT-HA-REQ, the HA being referred to is specified in a new extension (Redirected HA Extension).
重定向HA：如果注册被拒绝，错误代码为REDIRECT-HA-REQ，则在新扩展（重定向HA扩展）中指定所引用的HA。
AAA server: Authentication, Authorization, and Accounting Server.
AAA服务器：身份验证、授权和记帐服务器。
DNS: Domain Name System.
域名系统。
DHCP: Dynamic Host Configuration Protocol.
DHCP：动态主机配置协议。
MN: Mobile node as defined in Mobile IPv4 [1].
在IPv4中定义为移动节点[MN:1]。
HA: Home agent as defined in Mobile IPv4 [1].
HA:移动IPv4[1]中定义的归属代理。
FA: Foreign Agent as defined in Mobile IPv4 [1].
FA：移动IPv4[1]中定义的外部代理。
CoA: Care-of Address.
CoA：转交地址。
CCoA: Co-located Care-of Address.
CCoA：共同托管地址。
MN HoA: Mobile node's home address.
MN HoA：移动节点的主地址。
NAI: Network Access Identifier [2].
NAI：网络访问标识符[2]。
Src IP: Source IP address of the packet.
Src IP：数据包的源IP地址。
Dest IP: Destination IP address of the packet.
Dest IP：数据包的目标IP地址。
RRQ: Registration Request.
注册请求。
The Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of identifying an MN by the NAI and enabling dynamic home address assignment. When the home address is dynamically assigned, it is desirable to discover the home agent dynamically or inform the MN about an optimal HA to use for a multitude of reasons, such as:
IPv4[2]的移动IPv4 NAI扩展引入了通过NAI识别MN并启用动态家庭地址分配的概念。当动态地分配归属地址时，出于多种原因，期望动态地发现归属代理或通知MN要使用的最佳HA，例如：
- If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. In such a case, the MN will be anchored to its distant home agent, resulting in tunneled traffic traveling a long distance between home agent and the mobile node. When a Mobile IP session initiates, if the mobile node can be assigned a home agent that is close to the mobile node it can drastically reduce the latency between the home agent and mobile node.
- 如果所访问的网络和移动节点的家庭网络之间的距离大，则这些注册的信令延迟可能长。在这种情况下，MN将锚定到其远程归属代理，导致在归属代理和移动节点之间长距离移动的隧道通信。当移动IP会话发起时，如果可以向移动节点分配靠近移动节点的归属代理，则可以显著减少归属代理和移动节点之间的延迟。
- In a large-scale Mobile IP deployment, it is cumbersome to provision MNs with multiple HA addresses.
- 在大规模移动IP部署中，为MN提供多个HA地址非常麻烦。
- It is desirable to achieve some form of load balancing between multiple HAs in the network. Dynamic HA assignment and/or HA redirection lets the network select the optimal HA from among a set of HAs and thus achieve load balancing among a group of HAs.
- 希望在网络中的多个HA之间实现某种形式的负载平衡。动态HA分配和/或HA重定向允许网络从一组HA中选择最佳HA，从而在一组HA中实现负载平衡。
- Local administrative policies.
- 地方行政政策。
This specification does not address the problem of distributing a security association between the MN and HA, and it can either be statically preconfigured or dynamically distributed using other mechanisms [7].
本规范没有解决在MN和HA之间分发安全关联的问题，它可以静态预配置，也可以使用其他机制动态分发[7]。
The document introduces the terms Requested/Assigned/Redirected HA (Section 6). The discovery of candidate HA addresses for insertion into the Redirected HA Extension can be accomplished through various means that are network and/or deployment specific and hence are outside the scope of this specification.
本文件介绍了请求/分配/重定向HA的术语（第6节）。用于插入重定向HA扩展的候选HA地址的发现可以通过各种特定于网络和/或部署的方式完成，因此不在本规范的范围内。
The MN MAY request dynamic HA assignment when it is not aware of any HA address and even when it is aware of at least one HA address.
当MN不知道任何HA地址时，甚至当MN知道至少一个HA地址时，MN可以请求动态HA分配。
Mobile IPv4 [1] specifies the mechanism for discovering the mobile node's home agent using subnet-directed broadcast IP address in the home agent field of the Registration Request. This mechanism was
移动IPv4[1]指定使用注册请求的“归属代理”字段中的子网定向广播IP地址查找移动节点的归属代理的机制。这一机制是有效的
designed for mobile nodes with a static home address and subnet prefix, anchored on fixed home network. However, using subnet-directed broadcast as the destination IP address of the Registration Request, it is unlikely that the Registration Request will reach the home subnet because routers will drop these packets by default. See CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks [3].
设计用于固定家庭网络上固定的具有静态家庭地址和子网前缀的移动节点。但是，使用子网定向广播作为注册请求的目标IP地址，注册请求不太可能到达主子网，因为默认情况下路由器会丢弃这些数据包。参见CERT Advisory CA-1998-01 Smurf IP拒绝服务攻击[3]。
The Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of identifying an MN by the NAI and enabling dynamic home address assignment. This document requires that while using dynamic HA assignment, MN MUST use the NAI and obtain a home address. MN can still suggest a static home address in the Registration Request, but must take the address in the Registration Reply as the home address for the session. This is compatible with the procedures documented in the NAI specification [2].
IPv4[2]的移动IPv4 NAI扩展引入了通过NAI识别MN并启用动态家庭地址分配的概念。本文件要求在使用动态HA分配时，MN必须使用NAI并获得家庭地址。MN仍然可以在注册请求中建议静态家庭地址，但必须将注册回复中的地址作为会话的家庭地址。这与NAI规范[2]中记录的程序兼容。
The Dynamic HA Extension, shown in Figure 1, contains the address of the HA. This is a generic extension and can be used in Registration Request and Reply messages. It is a skippable extension.
图1所示的动态HA扩展包含HA的地址。这是一个通用扩展，可用于注册请求和回复消息。它是一个可跳过的扩展。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Dynamic HA Address Extension
图1：动态HA地址扩展
Type DYNAMIC-HA-ADDRESS (skippable) 139 is the type, which specifies the dynamic HA address.
Type DYNAMIC-HA-ADDRESS（可跳过）139是指定动态HA地址的类型。
Subtype Defines the use of this extension as: subtype 1 = Requested HA Extension 2 = Redirected HA Extension
子类型将此扩展的使用定义为：子类型1=请求的HA扩展2=重定向的HA扩展
Length Indicates the length of the extension not including the type, subtype, and length fields. Length is always 4 bytes.
长度表示扩展名的长度，不包括类型、子类型和长度字段。长度始终为4字节。
HA-Address Address of the home agent.
房委会地址的家庭代理。
The Requested HA Extension is a Dynamic HA Extension of subtype 1.
请求的HA扩展是子类型1的动态HA扩展。
The MN may include the Requested HA Extension in the Registration Request as a hint to the network where it wishes to be anchored.
MN可以在注册请求中包括所请求的HA扩展，作为对其希望锚定的网络的提示。
This extension contains the address of the HA. A valid unicast IP address MUST be used as HA address in this extension.
此扩展包含医管局的地址。必须将有效的单播IP地址用作此扩展中的HA地址。
In absence of an FA, the Registration Request is forwarded to this HA. In presence of an FA, the FA MUST forward the Registration Request to the HA address in this extension.
在没有FA的情况下，注册请求将转发给该医管局。在FA在场的情况下，FA必须将注册请求转发到此扩展中的HA地址。
The Redirected HA Extension is a Dynamic HA Extension of subtype 2.
重定向的HA扩展是子类型2的动态HA扩展。
The Redirected HA Extension contains the address of the HA where the MN should attempt the next registration. The HA receiving a Registration Request can suggest an alternate HA and, if so, the Registration Reply is sent with a new error code REDIRECT-HA-REQ and the alternate HA address is specified in this extension.
重定向的HA扩展包含MN应尝试下一次注册的HA地址。收到注册请求的HA可以建议一个备用HA，如果是，注册回复将与一个新的错误代码REDIRECT-HA-REQ一起发送，并在此扩展中指定备用HA地址。
The Redirected HA Extension MUST be included in Registration Reply when the reply code is REDIRECT-HA-REQ.
当回复代码为REDIRECT-HA-REQ时，重定向的HA扩展必须包含在注册回复中。
This specification presents two alternatives for home agent assignment:
本规范为归属代理分配提供了两种备选方案：
(a) Dynamic HA assignment (described in Section 4.1) and (b) HA redirection (described in Section 4.2).
(a) 动态HA分配（见第4.1节）和（b）HA重定向（见第4.2节）。
The following sequence of events occurs when the MN requests dynamic home agent assignment:
当MN请求动态归属代理分配时，会发生以下事件序列：
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. If the MN is aware of a desired HA address, it can add that address in the Requested HA Extension in the Registration Request. If the HA does not support the Requested HA Extension, see step 2 below.
1. MN将注册请求中的归属代理地址字段设置为ALL-ZERO-ONE-ADDR。如果MN知道所需的HA地址，它可以将该地址添加到注册请求中请求的HA扩展中。如果HA不支持请求的HA扩展，请参阅下面的步骤2。
2. This step is applicable, in lieu of step 1, for an MN that is aware of the HA address and desires dynamic HA assignment. Also, the MN follows this (when aware of a HA address) when it discovers a legacy FA in the path or if the known HA does not support the Requested HA Extension (see Section 10).
2. 该步骤代替步骤1，适用于知道HA地址并希望动态HA分配的MN。此外，当MN在路径中发现遗留FA或者如果已知HA不支持请求的HA扩展（参见第10节）时，MN遵循这一点（当知道HA地址时）。
The MN sets the Home Agent address field in the Registration Request to the HA address (instead of setting it to ALL-ZERO-ONE-ADDR). The MN also adds the same HA address in the Requested HA Extension in the Registration Request.
MN将注册请求中的Home Agent address字段设置为HA地址（而不是将其设置为ALL-ZERO-ONE-ADDR）。MN还在注册请求中请求的HA扩展中添加相同的HA地址。
3. The MN (if using co-located CoA and registering directly with the HA) or the FA (if the MN is registering via the FA) sends the Registration Request to the "Requested HA". If the Requested HA Extension is present, Requested HA is specified in the "HA Address" of this extension.
3. MN（如果使用同一地点的CoA并直接向HA注册）或FA（如果MN通过FA注册）向“请求的HA”发送注册请求。如果存在请求的HA扩展，则在该扩展的“HA地址”中指定请求的HA。
Per Section 10, in case of a legacy FA, legacy FA forwards the Registration Request to the address in the HA field of the request (thus, MN uses step 2 above in case of legacy FA instead of step 1).
根据第10节，在遗留FA的情况下，遗留FA将注册请求转发到请求的HA字段中的地址（因此，MN在遗留FA的情况下使用上面的步骤2，而不是步骤1）。
4. The "Requested HA" is the home agent that processes the Registration Request in accordance with Mobile IPv4 [1] and as per the specification in this document. It creates mobility binding for a successful Registration Request. It also sends a Registration Reply to the MN.
4. “请求的HA”是根据移动IPv4[1]和本文档中的规范处理注册请求的归属代理。它为成功的注册请求创建移动绑定。它还向MN发送注册回复。
5. The MN obtains an "Assigned HA" address from the HA field in the successful Registration Reply and uses it for the remainder of the session. (Note that the "Assigned HA" will be the same as the "Requested HA".)
5. MN从成功注册回复中的HA字段获得“分配的HA”地址，并在会话的剩余时间使用该地址。（请注意，“分配的HA”将与“请求的HA”相同。）
6. Subsequent Registration Request messages for renewal are sent to the Assigned HA.
6. 后续续订的注册请求消息将发送给分配的HA。
Section 5.3.1 describes the Assigned HA in detail. Some ideas on how to select the Requested HA are briefly covered in Section 6.
第5.3.1节详细描述了分配的HA。第6节简要介绍了有关如何选择所需医管局的一些想法。
Detailed explanation of this alternative is best described with the help of a message flow diagram and description.
最好借助消息流图和描述来详细说明此备选方案。
Figure 2 shows one specific example of a mobile node using an FA-located Care-of Address (FA CoA) and FA understands the Requested HA Extension per this specification.
图2显示了移动节点使用FA定位的转交地址（FA CoA）的一个具体示例，FA根据本规范理解请求的HA扩展。
Other scenarios such as when the mobile node uses a co-located care of address and presence of a legacy HA or FA are not described below, but the behavior is similar.
下面不描述其他场景，例如当移动节点使用共同定位的转交地址和遗留HA或FA的存在时，但是行为类似。
MN FA Requested/Assigned HA
| 1 | |
|------------>| 2 |
| |--------------->|
| | |
| | |
| | 3 |
| 4 |<---------------|
|<------------| |
| | |
| | 5 |
|----------------------------->|
| | |
MN FA Requested/Assigned HA
| 1 | |
|------------>| 2 |
| |--------------->|
| | |
| | |
| | 3 |
| 4 |<---------------|
|<------------| |
| | |
| | 5 |
|----------------------------->|
| | |
Figure 2: Example Message Flow for Dynamic HA Assignment
图2：动态HA分配的示例消息流
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. Since the MN is using FA CoA in this example, it sends the Registration Request to the FA. The Registration Request is formatted as follows:
1. MN将注册请求中的归属代理地址字段设置为ALL-ZERO-ONE-ADDR。因为MN在本例中使用FA CoA，所以它向FA发送注册请求。注册请求的格式如下：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
If the MN is aware of a desired HA address, it can add that address in the Requested HA Extension in Registration Request as a hint. That extension is not shown above.
如果MN知道所需的HA地址，它可以在注册请求中的请求HA扩展中添加该地址作为提示。上面没有显示该扩展。
2. The FA sends the Registration Request to the Requested HA. If the Requested HA Extension is present, Requested HA is the HA address in this extension. If the Requested HA Extension is not present, the FA determines the Requested HA through means outside the scope of this specification. The Registration Request is formatted as follows:
2. FA向请求的HA发送注册请求。如果存在请求的HA扩展，则请求的HA是此扩展中的HA地址。如果请求的HA扩展不存在，FA将通过本规范范围之外的方式确定请求的HA。注册请求的格式如下：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
(If MN includes the Requested HA Extension, the FA copies that extension. The FA then forwards the Registration Request, along with the Requested HA Extension, to the HA address specified in Requested HA Extension.)
（如果MN包括请求的HA扩展，FA将复制该扩展。然后FA将注册请求连同请求的HA扩展转发到请求的HA扩展中指定的HA地址。）
3. The HA processes the Registration Request in accordance with Mobile IPv4 [1] and the messaging defined in this document. The HA creates mobility binding for successful request and becomes the Assigned HA. The HA then sends a Registration Reply to the FA, which is formatted as follows:
3. HA根据移动IPv4[1]和本文档中定义的消息传递处理注册请求。HA为成功请求创建移动绑定，并成为分配的HA。然后，医管局向FA发送注册回复，其格式如下：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | the RRQ | | | |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | the RRQ | | | |
+-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
4. FA将注册回复转发给MN，如下所示：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+
5. The MN obtains the Assigned HA address from the HA field in the successful Registration Reply and uses it for the remainder of the session. The MN sends subsequent Re-Registration or De-Registration Requests for the remainder session directly to the Assigned HA. The Home Agent address field in this Registration Request is set to ALL-ZERO-ONE-ADDR. Note that the Assigned HA is the same as the Requested HA.
5. MN从成功注册回复中的HA字段获得分配的HA地址，并在会话的剩余时间使用该地址。MN将剩余会话的后续重新注册或取消注册请求直接发送给分配的HA。此注册请求中的归属代理地址字段设置为ALL-ZERO-ONE-ADDR。请注意，分配的HA与请求的HA相同。
This section describes the events that occur when the Requested HA does not accept the Registration Request and redirects the mobile node to another HA (aka Redirected HA) instead. This behavior is not exhibited by a legacy HA and so is not referred in the description below. In presence of a legacy FA, please refer to Section 4.1 for the specific field in the Registration Request.
本节描述当请求的HA不接受注册请求并将移动节点重定向到另一个HA（也称为重定向HA）时发生的事件。此行为未由遗留HA展示，因此在下面的描述中未提及。如果存在遗留FA，请参考第4.1节了解注册请求中的特定字段。
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR.
1. MN将注册请求中的归属代理地址字段设置为ALL-ZERO-ONE-ADDR。
2. The MN (if using co-located CoA and registering directly with the HA) or FA (if the MN is registering via the FA) sends the Registration Request to the "Requested HA". If the MN is aware of an HA address, it can add that address in the Requested HA Extension in the Registration Request.
2. MN（如果使用同一地点的CoA并直接向HA注册）或FA（如果MN通过FA注册）将注册请求发送给“请求的HA”。如果MN知道HA地址，它可以将该地址添加到注册请求中请求的HA扩展中。
3. When the HA receives the Registration Request, if the HA field is set to ALL-ZERO-ONE-ADDR, the HA may reject the request with Reply code REDIRECT-HA-REQ and suggest an alternate HA.
3. 当HA收到注册请求时，如果HA字段设置为ALL-ZERO-ONE-ADDR，HA可能会使用回复代码REDIRECT-HA-REQ拒绝该请求，并建议替代HA。
The HA may reject the request for a number of reasons, which are outside the scope of this specification. If the HA rejects the Request, the HA field in the Reply is set to this HA's address. The IP address of the HA that is the target of the redirection is specified in Redirected HA Extension. The presence of this extension is mandatory when the reply code is set to REDIRECT-HA-REQ. HA sends the Reply to the FA/MN.
医管局可能会基于一些不在本规范范围内的原因拒绝该请求。如果HA拒绝请求，则回复中的HA字段将设置为该HA的地址。重定向的HA扩展中指定了作为重定向目标的HA的IP地址。当应答代码设置为REDIRECT-HA-REQ时，必须存在此扩展。HA向FA/MN发送回复。
4. FA sends the Reply to the MN.
4. FA将应答发送给MN。
5. If the error code is set to REDIRECT-HA-REQ, the MN obtains the HA address from Redirected HA Extension. The MN then sends a Registration Request to Redirected HA. The MN may choose to add Requested HA Extension in this new Registration Request. If a registration loop occurs (the case when the Redirected HA is an HA that had already directed the MN to register elsewhere), then the MN stops sending any further Registration Request and provides an indication that the loop event was detected. The number of consecutive Redirected HAs remembered by the MN for loop detection is an implementation parameter.
5. 如果错误代码设置为REDIRECT-HA-REQ，则MN从重定向的HA扩展获取HA地址。然后，MN向重定向的HA发送注册请求。MN可以选择在这个新的注册请求中添加请求的HA扩展。如果发生注册循环（当重定向的HA是已经指示MN在别处注册的HA时），则MN停止发送任何进一步的注册请求，并提供检测到循环事件的指示。MN为循环检测记住的连续重定向的数量是一个实现参数。
Figure 3 shows one specific example of a mobile node using FA-located Care-of Address, where the FA is not a legacy FA.
图3显示了使用FA定位的转交地址的移动节点的一个具体示例，其中FA不是遗留FA。
MN FA Requested HA Redirected HA
| 1 | | |
|------------>| 2 | |
| |--------------->| |
| | | |
| | | |
| | 3 | |
| 4 |<---------------| |
|<------------| | |
| | | |
| | 5 | |
|--------------------------------------------->|
| | | |
MN FA Requested HA Redirected HA
| 1 | | |
|------------>| 2 | |
| |--------------->| |
| | | |
| | | |
| | 3 | |
| 4 |<---------------| |
|<------------| | |
| | | |
| | 5 | |
|--------------------------------------------->|
| | | |
Figure 3: Example Message Flow for HA Redirection
图3：HA重定向的示例消息流
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. Since the MN is using FA CoA in this example, it sends the Registration Request to the FA. The Registration Request is formatted as follows:
1. MN将注册请求中的归属代理地址字段设置为ALL-ZERO-ONE-ADDR。因为MN在本例中使用FA CoA，所以它向FA发送注册请求。注册请求的格式如下：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
If the MN is aware of an HA address, it can add that address in the Requested HA Extension in the Registration Request as a hint. That extension is not shown above.
如果MN知道HA地址，它可以将该地址添加到注册请求中请求的HA扩展中作为提示。上面没有显示该扩展。
2. The FA sends the Registration Request to the Requested HA. If Requested HA Extension is present, Requested HA is the HA address in this extension. If the Requested HA Extension is not present, the FA determines the Requested HA through means outside the scope of this specification. The Registration Request is formatted as follows:
2. FA向请求的HA发送注册请求。如果存在请求的HA扩展，则请求的HA是此扩展中的HA地址。如果请求的HA扩展不存在，FA将通过本规范范围之外的方式确定请求的HA。注册请求的格式如下：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
3. The HA processes the Registration Request in accordance with Mobile IPv4 [1] and the messaging defined in this specification. If the registration is successful, but local configuration/administrative policy, etc., directs the HA to refer the MN to another HA, the HA rejects the request with error code REDIRECT-HA-REQ. The HA fills in the address of the Redirected HA in the Redirected HA Extension. The HA then sends Registration Reply reject to the FA, which is formatted as follows:
3. HA根据移动IPv4[1]和本规范中定义的消息传递处理注册请求。如果注册成功，但本地配置/管理策略等指示HA将MN提交给另一个HA，HA将拒绝请求，错误代码为REDIRECT-HA-REQ。HA在重定向HA扩展中填写重定向HA的地址。然后，HA向FA发送注册回复拒绝，其格式如下：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| | Src IP of | | HA |FA CoA |
| HA | the RRQ | | | |
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| | Src IP of | | HA |FA CoA |
| HA | the RRQ | | | |
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
4. FA将注册回复转发给MN，如下所示：
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | HA |FA CoA/|
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | HA |FA CoA/|
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
5. If the MN can authenticate the Reply, the MN extracts the HA address from the Redirected HA Extension. The MN then sends a Registration Request to the Redirected HA, unless it has already received a redirection response from that HA while processing the Registration Request. The MN may choose to add Requested HA Extension in this new Registration Request.
5. 如果MN可以验证回复，MN将从重定向的HA扩展中提取HA地址。MN然后向重定向的HA发送注册请求，除非它在处理注册请求时已经收到来自该HA的重定向响应。MN可以选择在这个新的注册请求中添加请求的HA扩展。
The following sections describe the behavior of each mobility agent in detail.
以下各节详细描述了每个移动代理的行为。
The mobile node MUST use the NAI extension for home address assignment when using the messaging mechanism in this document. Since MN uses the NAI extension, the Home Address field is set to 0.0.0.0.
当使用本文档中的消息传递机制时，移动节点必须使用NAI扩展来分配家庭地址。由于MN使用NAI扩展，所以Home Address字段设置为0.0.0.0。
While dynamic HA assignment is in progress and the MN has not successfully anchored at a home agent, the MN MUST set the Home Agent field in the Registration Request to an ALL-ZERO-ONE-ADDR, which is either 255.255.255.255 or 0.0.0.0.
当动态HA分配正在进行且MN未成功锚定在归属代理上时，MN必须将注册请求中的归属代理字段设置为全零一地址，即255.255.255.255或0.0.0.0。
The Registration Request MUST be protected by a valid authenticator as specified in Mobile IPv4 [1] or Mobile IPv4 Challenge/Response Extensions [5]. Configuring security associations is deployment specific and hence outside the scope of this specification. The security associations between an MN and an individual HA may also be dynamically derived during the dynamic HA assignment, based on a shared secret between MN and AAA infrastructure [7].
注册请求必须由移动IPv4[1]或移动IPv4质询/响应扩展[5]中指定的有效身份验证程序保护。配置安全关联是特定于部署的，因此不在本规范的范围内。基于MN和AAA基础设施之间的共享秘密，MN和单个HA之间的安全关联也可以在动态HA分配期间动态导出[7]。
The mobile node MUST maintain the remaining Mobile IP session with the Assigned HA.
移动节点必须与分配的HA保持剩余的移动IP会话。
As mentioned in the Security Considerations (Section 9), there is a possibility of more than one HA creating a mobility binding entry for a given MN, if a rogue node in the middle captures the Registration Request and forwards it to other home agents. The MN can mitigate such condition by using a short lifetime (e.g., 5 seconds) in the Registration Request with the Home Agent field set to ALL-ZERO-ONE-ADDR.
如安全考虑（第9节）中提到的，如果中间的流氓节点捕获注册请求并将其转发到其他归属代理，则存在多于一个HA为给定的MN创建迁移绑定条目的可能性。MN可以通过在注册请求中使用短生存期（例如，5秒）来缓解这种情况，并且将归属代理字段设置为ALL-ZERO-ONE-ADDR。
The following sections describe MN behavior in FA CoA mode and co-located CoA mode.
以下章节描述了FA CoA模式和共位CoA模式下的MN行为。
When a mobile node initiates a Mobile IP session requesting dynamic HA assignment, it MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. The destination IP address of the Registration Request is the FA. The FA will determine the Requested HA and forward the Registration Request to the Requested HA. Registration Request processing takes place on the Requested HA as per the specification in this document.
当移动节点发起请求动态HA分配的移动IP会话时，它必须将注册请求中的归属代理地址字段设置为ALL-ZERO-ONE-ADDR。注册请求的目标IP地址是FA。FA将确定请求的HA，并将注册请求转发给请求的HA。根据本文档中的规范，注册请求处理在请求的HA上进行。
The Registration Request MUST be appropriately authenticated for the HA to validate the Request.
注册请求必须经过适当的身份验证，以便HA验证该请求。
If a successful Registration Reply is received, the MN obtains the Assigned HA from the HA field of Reply. The Assigned HA address will be the same as the Requested HA Extension, if it was included in the Registration Request by the MN.
如果接收到成功的注册回复，则MN从回复的HA字段获得分配的HA。如果MN将分配的HA地址包括在注册请求中，则分配的HA地址将与请求的HA扩展相同。
If a Registration Reply is received with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on HA address in HA field of Reply and attempt Registration with the HA address specified in the Redirected HA Extension. The MN MUST put the Redirected HA address as the Requested HA Extension of the new Registration Request.
如果收到带有代码REDIRECT-HA-REQ的注册回复，MN必须根据回复的HA字段中的HA地址对回复进行身份验证，并尝试使用重定向的HA扩展中指定的HA地址进行注册。MN必须将重定向的HA地址作为新注册请求的请求HA扩展。
In some cases, for the first Registration Request the MN may want to hint to the network to be anchored at a specific HA. The MN SHOULD put that address in the HA address of the Requested HA Extension.
在某些情况下，对于第一个注册请求，MN可能希望提示网络锚定在特定HA。MN应将该地址放入请求的HA扩展的HA地址中。
An MN in co-located CoA mode requesting dynamic HA assignment MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. The destination IP address of the Registration Request is the Requested HA. Some ideas on how to select a Requested HA are briefly covered in Section 6.
请求动态HA分配的位于同一位置的CoA模式中的MN必须将注册请求中的home agent address字段设置为ALL-ZERO-ONE-ADDR。注册请求的目标IP地址是请求的HA。第6节简要介绍了有关如何选择所需医管局的一些想法。
If a successful Reply is received, the MN obtains the Assigned HA address from the successful Registration Reply. The Assigned HA will be the same as Requested HA to which the Registration Request was sent. The MN MUST cache the Assigned HA address for the length of the Mobile IP session. The mobile node then MUST use this previously cached Assigned HA address as the home agent address in subsequent Re-Registration and De-Registration Request(s). This will make sure that for the duration of the Mobile IP session, the mobile node will always be anchored to the assigned home agent with which it was initially registered.
如果接收到成功的回复，则MN从成功的注册回复中获得分配的HA地址。分配的HA将与向其发送注册请求的请求HA相同。MN必须在移动IP会话的长度内缓存分配的HA地址。然后，移动节点必须在随后的重新注册和取消注册请求中使用该先前缓存的分配HA地址作为归属代理地址。这将确保在移动IP会话期间，移动节点将始终锚定到其最初注册的分配的归属代理。
If a Registration Reply is received with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on HA address in HA field of Reply and attempt Registration with the HA address specified in the Redirected HA Extension. The MN MUST put the Redirected HA in the Requested HA Extension of the new Registration Request.
如果收到带有代码REDIRECT-HA-REQ的注册回复，MN必须根据回复的HA字段中的HA地址对回复进行身份验证，并尝试使用重定向的HA扩展中指定的HA地址进行注册。MN必须将重定向的HA放入新注册请求的请求HA扩展中。
In some cases, for the first Registration Request MN may want to hint to the network to be anchored at a specific HA and the MN SHOULD put that address in the HA address of the Requested HA Extension.
在某些情况下，对于第一个注册请求，MN可能希望提示网络锚定在特定HA上，并且MN应该将该地址放在请求的HA扩展的HA地址中。
While requesting dynamic HA assignment and registering directly with an HA, the Requested HA Extension MUST be included and MUST contain the address of the HA to which the Registration Request is sent. When using co-located CoA but registering via a legacy FA, the HA field in the Registration Request may be set to Requested HA.
当请求动态HA分配并直接向HA注册时，必须包括请求的HA扩展，并且必须包含注册请求发送到的HA的地址。当使用同一位置的CoA但通过传统FA进行注册时，注册请求中的HA字段可设置为请求的HA。
If the Registration Request contains the Requested HA Extension, the HA address in that extension MUST match the destination IP of the Request.
如果注册请求包含请求的HA扩展，则该扩展中的HA地址必须与请求的目标IP匹配。
When the Mobile IP session terminates, the mobile node MAY clear the Assigned HA address cached as the home agent address. It MAY request a new HA address for the new Mobile IP session by not including the Requested HA Extension. The advantage of this approach is that the mobile node will be always anchored to an optimal home agent from where it initiated the Mobile IP session.
当移动IP会话终止时，移动节点可以清除缓存为归属代理地址的分配HA地址。它可以通过不包括所请求的HA扩展来为新的移动IP会话请求新的HA地址。这种方法的优点是，移动节点将始终锚定到它发起移动IP会话的最佳归属代理。
Alternately, the MN may save the Assigned HA address and use it in the Requested HA Extension along with ALL-ZERO-ONE-ADDR HA address in Registration Request for a new Mobile IP session.
或者，MN可以保存分配的HA地址，并将其与新移动IP会话的注册请求中的全零一地址HA地址一起用于请求的HA扩展中。
When the mobile node is using an FA CoA, it always registers via the FA. When the MN is using a co-located CoA, it may register through an FA or it may register directly with an HA, unless the R bit is set in the FA's agent advertisement, in which case it always registers through the FA.
当移动节点使用FA-CoA时，它总是通过FA注册。当MN使用同一位置的CoA时，它可以通过FA注册，也可以直接向HA注册，除非在FA的代理广告中设置了R位，在这种情况下，它总是通过FA注册。
When the FA receives a Registration Request with HA address field set to ALL-ZERO-ONE-ADDR that doesn't contain the Requested HA Extension, the FA obtains the Requested HA address to forward the Registration Request using means outside the scope of this specification. Some ideas on how to select a Requested HA are briefly covered in Section 6.
当FA收到HA地址字段设置为ALL-ZERO-ONE-ADDR且不包含请求的HA扩展的注册请求时，FA获得请求的HA地址，以使用本规范范围外的方式转发注册请求。第6节简要介绍了有关如何选择所需医管局的一些想法。
If the FA cannot obtain the Requested HA to which to forward a Registration Request from the MN, it MUST reject request with error code NONZERO-HA-REQD.
如果FA无法获得从MN转发注册请求的请求HA，则必须拒绝错误代码为NONZERO-HA-REQD的请求。
If the MN has included the Requested HA Extension, the FA MUST forward the Registration Request to the address in this extension. If the HA address in this extension is not a routable unicast address, the FA MUST reject the request with error code NONZERO-HA-REQD.
如果MN包含请求的HA扩展，FA必须将注册请求转发到此扩展中的地址。如果此扩展中的HA地址不是可路由单播地址，FA必须拒绝错误代码为NONZERO-HA-REQD的请求。
If the Registration Request contains the Requested HA Extension, the FA uses that address as the destination for the relayed Registration Request.
如果注册请求包含请求的HA扩展，FA将该地址用作中继注册请求的目的地。
Backward-compatibility issues related to the mobility agents are addressed in Section 10.
第10节讨论了与移动代理相关的向后兼容性问题。
A home agent can process an incoming Registration Request in one of the following two ways:
归属代理可以通过以下两种方式之一处理传入的注册请求：
1. The MN or FA sends the Registration Request to the Requested HA. The term Requested HA has meaning in the context of a Registration Request message. When the Requested HA successfully processes the Registration Request and creates a binding and sends a Reply with its address, it becomes the Assigned HA. The term Assigned HA is meaningful in the context of a Registration Reply message.
1. MN或FA向请求的HA发送注册请求。术语“请求HA”在注册请求消息的上下文中具有含义。当被请求的HA成功处理注册请求并创建绑定并发送带有其地址的回复时，它将成为分配的HA。术语分配HA在注册回复消息的上下文中是有意义的。
2. A home agent receiving a Registration Request with HA field set to ALL-ZERO-ONE-ADDR MAY reject the request even if successfully authenticated and suggest an alternate HA address in Reply. In such a case, the HA puts its own address in HA field of Reply and sets the Reply code to REDIRECT-HA-REQ and adds the Redirected HA Extension.
2. 接收HA字段设置为ALL-ZERO-ONE-ADDR的注册请求的归属代理可以拒绝该请求，即使已成功地进行了身份验证，并在答复中建议备用HA地址。在这种情况下，HA将自己的地址放在应答的HA字段中，并将应答代码设置为REDIRECT-HA-REQ，并添加重定向的HA扩展。
If the Registration Request contains the Requested HA Extension, the HA address in that extension must match the destination IP of the Request. If it does not match, the Requested HA MUST reject the Registration Request with error code 136.
如果注册请求包含请求的HA扩展，则该扩展中的HA地址必须与请求的目标IP匹配。如果不匹配，请求的HA必须拒绝注册请求，错误代码为136。
The HA that processes the incoming Registration Request fully in accordance with Mobile IPv4 [1] and this specification becomes the Assigned HA. The Registration Request terminates at the Assigned HA.
完全按照移动IPv4[1]和本规范处理传入注册请求的HA成为分配的HA。注册请求在分配的HA处终止。
The Assigned HA creates one mobility binding per MN and sends the Registration Reply to the MN by copying its address in the Home Agent field and as the source IP address of the Reply.
分配的HA为每个MN创建一个移动绑定，并通过在Home Agent字段中复制注册应答的地址并将其作为应答的源IP地址发送给MN。
The following table summarizes the behavior of the Assigned HA, based on the value of the destination IP address and Home Agent field of the Registration Request.
下表根据注册请求的目标IP地址和归属代理字段的值总结了分配的HA的行为。
Dest IP Addr HA field Processing at Assigned HA
------------ ------------ ----------------------------------
Dest IP Addr HA field Processing at Assigned HA
------------ ------------ ----------------------------------
Unicast non-unicast Mobile IPv4 [1]: There is no change in handling for this case from (Must be Mobile IPv4. It is mentioned here equal to the for reference only. HA receiving HA denies the registration with the RRQ) error code 136 and sets HA field to its own IP address in the reply as per Section 3.8.3.2 in [1].
单播非单播移动IPv4[1]：此案例的处理没有变化，错误代码为136（必须是移动IPv4。此处提及的错误代码等同于仅供参考。HA接收HA拒绝注册RRQ），并根据[1]中的第3.8.3.2节在回复中将HA字段设置为其自己的IP地址。
ALL-ZERO- New Behavior: Accept the RRQ as per ONE-ADDR this specification. Authenticate the RRQ and create mobility binding if the HA is acting as Assigned HA. Set HA field to its own IP address in the Registration Reply.
全零-新行为：根据本规范的ONE-ADDR接受RRQ。如果HA充当分配的HA，则验证RRQ并创建移动性绑定。在注册回复中将HA字段设置为其自己的IP地址。
OR
或
New Behavior: If authentication is successful, reject RRQ with a new error code REDIRECT-HA-REQ. HA puts its address in HA address field of Reject. HA suggests an alternate HA to use in the new Redirected HA Extension.
新行为：如果身份验证成功，则使用新的错误代码REDIRECT-HA-REQ拒绝RRQ。HA将其地址放入拒绝的HA地址字段中。HA建议在新的重定向HA扩展中使用替代HA。
Table 1: Registration Request Handling at Assigned HA
表1：指定医管局的注册申请处理
As per the messaging proposed here, the mobile node (or the foreign agent) sends the Registration Request to the Requested HA address, which is a unicast address. Therefore, this document does not specify any new behavior for the case where the HA receives a subnet directed broadcast Registration Request as specified in Section 3.8.2.1 of the Mobile IPv4 specification [1]. Although the Home Agent field in the Registration Request is not a unicast address, the destination IP address is a unicast address. This avoids the problem associated with subnet-directed broadcast destination IP address that may result in multiple HAs responding. Thus, there is no need to deny the registration as stated in Mobile IPv4 [1] Section 3.8.3.2.
根据这里提出的消息传递，移动节点（或外部代理）将注册请求发送到请求的HA地址，该HA地址是单播地址。因此，本文件未针对HA收到移动IPv4规范[1]第3.8.2.1节规定的子网定向广播注册请求的情况规定任何新行为。尽管注册请求中的归属代理字段不是单播地址，但目标IP地址是单播地址。这避免了与子网定向广播目标IP地址相关的问题，该问题可能导致多个HA响应。因此，无需拒绝移动IPv4[1]第3.8.3.2节中所述的注册。
When the destination IP address is a unicast address and the Home Agent field is ALL-ZERO-ONE-ADDR, the HA accepts/denies registration and sets the HA field to its own IP address in the reply (i.e., the registration is not rejected with error code 136).
当目标IP地址为单播地址且归属代理字段为ALL-ZERO-ONE-ADDR时，HA接受/拒绝注册，并在回复中将HA字段设置为其自己的IP地址（即，注册未被拒绝，错误代码为136）。
The HA can reject the request with the error code REDIRECT-HA-REQ and suggest an alternate HA. This redirection can be used for load balancing, geographical proximity based on Care-of Address, or other reasons. The HA puts its own address in the HA field of the Registration Reply message and puts the address of the redirected HA in the Redirected HA Extension. If the HA accepts the Request, it sets the HA field in the Registration Reply to its own address.
HA可以使用错误代码REDIRECT-HA-REQ拒绝请求，并建议替代HA。此重定向可用于负载平衡、基于转交地址的地理邻近性或其他原因。HA将自己的地址放在注册回复消息的HA字段中，并将重定向HA的地址放在重定向HA扩展中。如果医管局接受请求，它会将注册回复中的HA字段设置为自己的地址。
The Requested HA always performs standard validity checks on the Registration Request. If there is any error, the Registration Request is rejected with error codes specified in Mobile IPv4 [1].
被请求的HA始终对注册请求执行标准有效性检查。如果有任何错误，注册请求将被拒绝，并显示移动IPv4[1]中指定的错误代码。
When dynamic HA assignment is requested, the MN (or FA in the case of registration via FA) sends the Registration Request to the Requested HA. This address MUST be a unicast IP address. If the MN has included a Requested HA Extension in the Registration Request, the HA address in this extension is the Requested HA.
当请求动态HA分配时，MN（或在通过FA注册的情况下为FA）向请求的HA发送注册请求。此地址必须是单播IP地址。如果MN在注册请求中包含请求的HA扩展，则此扩展中的HA地址就是请求的HA。
Some examples of methods by which the MN or the FA may select the Requested HA are briefly described below:
MN或FA可选择所请求HA的方法的一些示例简要描述如下：
DHCP:
DHCP：
The MN performs DHCP to obtain an IP address on the visited network. The Requested HA is learned from the DHCP Mobile IP Home Agent Option 68 [4]. The MN sends the Registration Request directly to this HA and receives the Assigned HA to be used for the remainder of the Mobile IP session.
MN执行DHCP以获取访问网络上的IP地址。请求的HA从DHCP移动IP归属代理选项68中学习[4]。MN直接向该HA发送注册请求，并接收分配的HA以用于剩余的移动IP会话。
AAA:
AAA：
MN performs challenge/response [5] with the FA. The FA retrieves the Requested HA from the AAA server and forwards the Registration Request directly to this HA. The Assigned HA sends a Registration Reply to the FA, which relays it to the MN. MN uses the Assigned HA for the remainder of the Mobile IP session.
MN与FA执行质询/响应[5]。FA从AAA服务器检索请求的HA，并将注册请求直接转发到此HA。分配的HA向FA发送注册回复，FA将其转发给MN。MN在剩余的移动IP会话中使用分配的HA。
DNS:
域名系统：
In this case, the hostname of the HA is configured on the MN or obtained by some other means, e.g., using a service location protocol. The MN performs DNS lookup on the HA hostname. The DNS infrastructure provides a resource record with information to identify the optimal HA to the MN. The MN sends a Registration Request directly to the HA and receives the Assigned HA to be used for the remainder of the Mobile IP session.
在这种情况下，HA的主机名在MN上配置或通过一些其他方式获得，例如使用服务位置协议。MN对HA主机名执行DNS查找。DNS基础设施提供了一个资源记录，其中包含识别MN的最佳HA的信息。MN直接向HA发送注册请求，并接收分配的HA以用于剩余的移动IP会话。
Static configuration:
静态配置：
The HA address is statically configured on the MN. The MN sends the Registration Request to the configured address. The Requested HA may then redirect the MN to a Redirected HA.
HA地址是在MN上静态配置的。MN将注册请求发送到配置的地址。然后，所请求的HA可以将MN重定向到重定向的HA。
Each entry in the following table contains the name and value for the error code to be returned in a Registration Reply. It also includes the section in which the error code is first mentioned in this document.
下表中的每个条目都包含要在注册回复中返回的错误代码的名称和值。它还包括本文档中首次提到错误代码的部分。
Error Name Value Section Description
--------------- ----- ------- -----------------------------
NONZERO-HA-REQD 90 5.2 Non-zero HA address required
in Registration Request.
REDIRECT-HA-REQ 143 5.3 Re-register with redirected HA.
Error Name Value Section Description
--------------- ----- ------- -----------------------------
NONZERO-HA-REQD 90 5.2 Non-zero HA address required
in Registration Request.
REDIRECT-HA-REQ 143 5.3 Re-register with redirected HA.
The code value NONZERO-HA-REQD is a Mobile IP response code [1] taken from the range of values associated with rejection by the foreign agent (i.e., value in the range 64-127).
代码值NONZERO-HA-REQD是一个移动IP响应代码[1]，取自与外部代理拒绝相关的值范围（即，范围64-127中的值）。
The code value REDIRECT-HA-REQ is a Mobile IP response code [1] taken from the range of values associated with rejection by the home agent (i.e., value in the range 128-192).
代码值REDIRECT-HA-REQ是从与归属代理拒绝相关联的值的范围（即，范围128-192中的值）中获取的移动IP响应代码[1]。
The Dynamic HA Extension is assigned from the range of values associated with skippable extensions at the home agent (i.e., value in the range 128-255).
动态HA扩展是从与归属代理处的可跳过扩展相关联的值的范围（即，范围128-255中的值）分配的。
IANA has recorded the values as defined in Sections 7 and 3.4.
IANA已记录了第7节和第3.4节中定义的数值。
This specification assumes that a security configuration has been preconfigured between the MN and the HA or is configured along with the initial Registration Request/Registration Reply as per [7].
本规范假设已在MN和HA之间预先配置了安全配置，或者根据[7]随初始注册请求/注册回复一起配置了安全配置。
There is a possibility of more than one HA creating a mobility binding entry for a given MN, if a man in the middle captures the Registration Request with the HA field set to ALL-ZERO-ONE-ADDR and forwards it to other HAs. This scenario assumes that the rogue node can find out the addresses of the HAs that are able to authenticate the Registration Request. It also assumes that the rogue node has the capability to store, duplicate, and send packets to the other HAs
如果一个中间的人捕获了HA字段设置为全零一ADDR并将其转发给其他FAN的注册请求，则有可能不止一个HA创建给定的MN的移动绑定条目。此场景假设恶意节点可以找到能够验证注册请求的HA的地址。它还假设流氓节点能够存储、复制数据包，并将数据包发送给其他节点
within the limited time of the replay window. Otherwise, these HAs will reject the Registration Requests anyway. In addition, this type of attack is only possible when the Requested HA Extension is not included in the registration message. The mobile node can minimize the duration of this condition by using a short lifetime (e.g., 5 seconds) in the Registration Request.
在重播窗口的限定时间内。否则，这些HAs将拒绝注册请求。此外，只有当请求的HA扩展未包含在注册消息中时，才可能发生这种类型的攻击。移动节点可以通过在注册请求中使用较短的生存期（例如，5秒）来最小化该状况的持续时间。
This specification does not change the security model established in Mobile IPv4 [1]. Mobile nodes are often connected to the network via wireless links, which may be more prone to passive eavesdropping or replay attacks. Such an attack might lead to bogus registrations or redirection of traffic or denial of service.
此规范不会更改移动IPv4[1]中建立的安全模型。移动节点通常通过无线链路连接到网络，这可能更容易受到被动窃听或重放攻击。此类攻击可能导致虚假注册、流量重定向或拒绝服务。
As per the messaging in this document, the Assigned Home Agent will process the incoming Registration Request as per Mobile IPv4 [1]. Hence the Assigned Home Agent will have the same security concerns as those of the home agent in Mobile IPv4 [1]. They are addressed in Section 5, "Security Considerations", of Mobile IPv4 [1].
根据本文档中的消息，分配的归属代理将根据移动IPv4[1]处理传入的注册请求。因此，分配的归属代理将具有与移动IPv4中的归属代理相同的安全问题[1]。移动IPv4[1]的第5节“安全注意事项”中介绍了这些问题。
The Registration Request and Registration Reply messages are protected by a valid authenticator as specified in Mobile IPv4 [1]. Configuring security associations is a deployment-specific issue and is covered by other Mobile IP specifications. There can be many ways of configuring security associations, but this specification does not require any specific way.
注册请求和注册回复消息由移动IPv4[1]中指定的有效身份验证程序保护。配置安全关联是一个特定于部署的问题，其他移动IP规范也涵盖了这一问题。可以通过多种方式配置安全关联，但本规范不需要任何特定方式。
An example is where the security association between an MN and an individual HA (Requested or Assigned) is dynamically derived during the registration process based on a shared secret between MN and AAA infrastructure, as defined in [7]. The Registration Request is protected with MN-AAA Authentication Extension, and Registration Reply is protected with MN-HA Authentication Extension. Because the security association is shared between MN and AAA, any dynamically assigned HA in the local domain can proxy authenticate the MN using AAA as per [7].
例如，MN和单个HA（请求或分配）之间的安全关联在注册过程中根据MN和AAA基础设施之间的共享秘密动态导出，如[7]中所定义。注册请求由MN-AAA认证扩展保护，注册回复由MN-HA认证扩展保护。由于安全关联在MN和AAA之间共享，因此本地域中任何动态分配的HA都可以根据[7]使用AAA代理对MN进行身份验证。
The Assigned Home Agent authenticates each Registration Request from the mobile node as specified in Mobile IPv4 [1] and/or RFC 3012. The MN also authenticates the Registration Reply from the Assigned HA; thus, the existing trust model in Mobile IPv4 [1] is maintained.
分配的归属代理按照移动IPv4[1]和/或RFC 3012中的规定对来自移动节点的每个注册请求进行认证。MN还认证来自分配的HA的注册回复；因此，移动IPv4[1]中的现有信任模型得以维护。
In this section, we examine concerns that may arise when using this specification in a mixed environment where some nodes implement the specification and others do not. In each of the examples below, we consider the case where one node is a "legacy" node, which does not implement the specification in the context of other nodes that do.
当我们在本节中使用混合节点时，我们可能会在本节中检查一些节点，而其他节点可能不会在本节中使用混合节点。在下面的每个示例中，我们考虑一个节点是“遗留”节点的情况，该节点不在其他节点的上下文中实现该规范。
Legacy Home Agent:
遗留主代理：
Legacy home agents may reject the Registration Request with error code 136 because the Home Agent field is not a unicast address. However, some legacy HA implementations may coincidentally process the Registration Request in accordance with this document, when the HA field in Registration Request is set to ALL-ZERO-ONE-ADDR.
传统归属代理可以拒绝带有错误代码136的注册请求，因为归属代理字段不是单播地址。然而，当注册请求中的HA字段设置为ALL-ZERO-ONE-ADDR时，一些遗留HA实现可能会根据本文档同时处理注册请求。
Legacy Foreign Agent:
遗留外国代理：
Legacy foreign agents may forward a Registration Request with home agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP address to ALL-ZERO-ONE-ADDR. This will result in the packet being dropped or incidentally handled by a next-hop HA, adjacent to the FA. The MN may not be aware of the dropped Registration Request and may probably retry registration, thereby increasing the delay in registration.
通过将目标IP地址设置为ALL-ZERO-ONE-ADDR，旧版外部代理可以转发注册请求，其中home agent字段设置为ALL-ZERO-ONE-ADDR。这将导致数据包被丢弃，或者由邻近FA的下一跳HA处理。MN可能不知道丢弃的注册请求，并且可能重试注册，从而增加注册延迟。
To reduce the delay in registration, the MN should take the following steps:
为减少注册延迟，MN应采取以下步骤：
1. The MN should send the Registration Request as specified in this specification. In other words, the MN should set the Home Agent field in the Registration Request to ALL-ZERO-ONE-ADDR and also add the Requested HA Extension.
1. MN应按照本规范的规定发送注册请求。换句话说，MN应该将注册请求中的Home Agent字段设置为ALL-ZERO-ONE-ADDR，并添加请求的HA扩展。
2. If the MN does not receive a Registration Reply within some time and/or after sending a few Registration Requests, it can assume that the Registration Request(s) has been dropped, either by a legacy FA or an incorrect HA. In addition, if the registration is denied with error code 70 (poorly formed Request), the MN can assume that the legacy FA cannot process this message. In either case, the MN should fall back to a recovery mechanism. The MN should quickly send a new Registration Request as mentioned in Section 4.1 step 2. This step will ensure that a legacy FA will forward the Registration Request to the home agent thereby making dynamic HA assignment possible.
2. 如果MN在一段时间内和/或在发送几个注册请求之后没有收到注册回复，则它可以假设注册请求已被遗留FA或不正确的HA丢弃。此外，如果注册被拒绝，错误代码为70（格式错误的请求），MN可以假定传统FA无法处理该消息。在任何一种情况下，MN都应该回到恢复机制。MN应快速发送第4.1节第2步中提到的新注册请求。此步骤将确保遗留FA将注册请求转发给归属代理，从而使动态HA分配成为可能。
Legacy Mobile Node:
传统移动节点：
An MN that sends a Registration Request to an FA that can do dynamic HA assignment, but does not set the HA field to ALL-ZERO-ONE-ADDR will continue to be registered with its statically configured HA, exactly according to RFC 3344.
向可以执行动态HA分配但未将HA字段设置为ALL-ZERO-ONE-ADDR的FA发送注册请求的MN将继续使用其静态配置的HA进行注册，这完全符合RFC 3344。
The authors would like to thank Pete McCann for thorough review, suggestions on security considerations, and definition of ALL-ZERO-ONE-ADDR. Thanks to Kuntal Chowdhury for extensive review and comments on this document. Also thanks to Henrik Levkowetz for detailed reviews and suggestions. Thomas Narten highlighted issues for legacy FA considerations. Thanks to Ahmad Muhanna for pointing out scenario of multiple bindings on HAs, documented in the Security Considerations section.
作者要感谢Pete McCann的透彻审查、关于安全考虑的建议以及ALL-ZERO-ONE-ADDR的定义。感谢Kuntal Chowdhury对本文件的广泛审查和评论。还要感谢Henrik Levkowetz的详细评论和建议。Thomas Narten强调了遗留FA考虑的问题。感谢Ahmad Muhanna指出了HAs上多个绑定的场景，记录在安全注意事项部分。
The authors would like to thank Mike Andrews, Madhavi Chandra, and Yoshi Tsuda for their review and suggestions.
作者要感谢Mike Andrews、Madhavi Chandra和Yoshi Tsuda的评论和建议。
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1] Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[2] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[2] Calhoun，P.和C.Perkins，“IPv4移动IP网络访问标识符扩展”，RFC 27942000年3月。
[3] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[3] Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 26441999年8月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[5] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[5] Perkins，C.和P.Calhoun，“移动IPv4挑战/响应扩展”，RFC3012，2000年11月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[7] Perkins，C.和P.Calhoun，“移动IPv4的身份验证、授权和计费（AAA）注册密钥”，RFC 3957，2005年3月。
Authors' Addresses
作者地址
Milind Kulkarni Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
Milind Kulkarni思科系统公司，美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
Phone: +1 408-527-8382
EMail: mkulkarn@cisco.com
Phone: +1 408-527-8382
EMail: mkulkarn@cisco.com
Alpesh Patel Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
阿尔佩什·帕特尔·思科系统公司，美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
Kent Leung Cisco Systems Inc.美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。