Network Working Group
Request for Comments: 4004 P. Calhoun
Category: Standards Track Cisco Systems, Inc.
T. Johansson
Bytemobile Inc
C. Perkins
Nokia Research Center
T. Hiller, Ed.
P. McCann
Lucent Technologies
August 2005
Network Working Group
Request for Comments: 4004 P. Calhoun
Category: Standards Track Cisco Systems, Inc.
T. Johansson
Bytemobile Inc
C. Perkins
Nokia Research Center
T. Hiller, Ed.
P. McCann
Lucent Technologies
August 2005
Diameter Mobile IPv4 Application
Diameter移动IPv4应用程序
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.
本文档指定了一个Diameter应用程序，该应用程序允许Diameter服务器对提供给移动节点的移动IPv4服务进行身份验证、授权和收集记帐信息。结合基本协议的域间能力，该应用程序允许移动节点接收来自国外服务提供商的服务。国外和国内代理将使用Diameter记帐消息将使用情况信息传输到Diameter服务器。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4
1.2. Mobility Security Associations. . . . . . . . . . . . . . 4
1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure of the Document . . . . . . . . . . . . . . . . 7
2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7
3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4
1.2. Mobility Security Associations. . . . . . . . . . . . . . 4
1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure of the Document . . . . . . . . . . . . . . . . 7
2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7
3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53
Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point of attachment to the Internet while maintaining its fixed home address. Packets directed to the home address are intercepted by a Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at its current point of attachment. Optionally, a Foreign Agent (FA) may be deployed at this point of attachment, which can serve as the tunnel endpoint and may also provide access control for the visited network link. In this role, the FA has to authenticate each MN that may attach to it, whether the MN is from the same or a different administrative domain. The FA has to verify that the MN is authorized to attach and use resources in the foreign domain. Also, the FA must provide information to the home administrative domain about the resources used by the MN while it is attached in the foreign domain.
移动IPv4[MOBILEIP]允许移动节点（MN）更改其连接到Internet的连接点，同时保持其固定的家庭地址。定向到归属地址的分组被归属代理（HA）截获，封装在隧道中，并在其当前连接点转发到MN。可选地，可以在该连接点部署外部代理（FA），其可以用作隧道端点，并且还可以为访问的网络链路提供访问控制。在此角色中，FA必须对可能附加到它的每个MN进行身份验证，无论该MN来自同一管理域还是不同的管理域。FA必须验证MN是否有权在外域附加和使用资源。此外，FA必须向本国管理域提供MN连接到外域时所使用资源的相关信息。
The Authentication, Authorization, and Accounting (AAA) requirements for Mobile IPv4 are described in detail in other documents [MIPREQ, CDMA2000]. This document specifies a Diameter application to meet these requirements. This application is not applicable to the Mobile IPv6 protocol.
移动IPv4的身份验证、授权和计费（AAA）要求在其他文档[MIPREQ，CDMA2000]中有详细描述。本文件规定了满足这些要求的直径应用。此应用程序不适用于移动IPv6协议。
Message formats (e.g., as in section 5.1) are specified as lists of Attribute-Value Pairs (AVPs) using the syntax as described in RFC 2234 [ABNF]. This includes the use of the "*" symbol to denote zero or more occurrences of an AVP.
使用RFC 2234[ABNF]中描述的语法，将消息格式（如第5.1节）指定为属性值对（AVP）列表。这包括使用“*”符号表示AVP的零次或多次出现。
Conventions Used in This Document
本文件中使用的公约
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
The Diameter Mobile IPv4 Application supports the HA and FA in providing Mobile IPv4 service to MNs. Both the HA and FA act as Diameter clients. The MNs interact with the HA and FA by using only Mobile IPv4 and therefore do not implement Diameter.
Diameter移动IPv4应用程序支持HA和FA向MNs提供移动IPv4服务。医管局和足总都是Diameter的客户。MNs通过仅使用移动IPv4与HA和FA交互，因此不实现Diameter。
The FA, when present, is always assumed to exist in the visited administrative domain. The HA may be statically or dynamically allocated to the MN in the home administrative domain or may be dynamically allocated to the MN in a visited administrative domain. The home domain contains a home AAA server (AAAH), and the visited domain contains a foreign AAA server (AAAF). When the MN is "at home" (present on its home network), the AAAH and AAAF may be the same.
FA（如果存在）始终假定存在于访问的管理域中。HA可以静态地或动态地分配给归属管理域中的MN，或者可以动态地分配给访问的管理域中的MN。主域包含一个主AAA服务器（AAAH），访问的域包含一个外部AAA服务器（AAAF）。当MN“在家”（存在于其家庭网络上）时，AAAH和AAAF可以是相同的。
The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a Mobility Security Association (MSA) between the MN and HA (MN-HA MSA). The MN-HA MSA is used to authenticate, by using a keyed hash-style algorithm, the Mobile IP Registration Request that is sent from the MN to the HA. It is important to authenticate Registration Requests, as they inform the HA about the MN's current Care-of-Address, which is the destination for tunneled packets from the home network. Without authentication, malicious attackers would be able to redirect packets to anywhere on the Internet. The MSA comprises an agreement on a Security Parameters Index (SPI, a 32-bit number) that will be used to refer to the MSA, an algorithm that will be used to compute keyed hashes over messages, and a shared secret key. To enable authentication of a message, the sender appends a Mobile IP Authentication Extension that contains the SPI and the result of running the keyed hash over the entire previous contents of the message. The recipient checks the Authentication Extension by looking up the MSA based on the SPI, re-computing the keyed hash, and verifying that the result is equal to the contents of the received Authentication Extension.
基本移动IPv4协议[MOBILEIP]假设MN和HA（MN-HA MSA）之间存在移动安全关联（MSA）。MN-HA MSA用于通过使用密钥散列式算法对从MN发送到HA的移动IP注册请求进行身份验证。对注册请求进行身份验证很重要，因为它们将通知HA MN的当前转交地址，该地址是来自家庭网络的隧道数据包的目的地。如果没有身份验证，恶意攻击者将能够将数据包重定向到Internet上的任何位置。MSA包括关于将用于引用MSA的安全参数索引（SPI，32位数字）的协议、将用于计算消息上的密钥散列的算法以及共享密钥。要启用消息的身份验证，发送方将附加一个移动IP身份验证扩展，该扩展包含SPI和对消息的所有先前内容运行密钥哈希的结果。接收方通过基于SPI查找MSA、重新计算密钥散列并验证结果是否等于接收到的身份验证扩展的内容来检查身份验证扩展。
The base Mobile IPv4 protocol also supports an optional MSA between the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by the FA to authenticate each Registration Request passing through it on the way to the HA. Although not critical to the operation of the base protocol, the MN-FA MSA is useful when the FA has to know the authenticity of a Registration Request; e.g., when it will be generating accounting records for a session. The MN-FA MSA may also be useful in future work related to handoff optimization.
基本移动IPv4协议还支持MN和FA之间的可选MSA（MN-FA MSA）。如果可用，FA将使用MN-FA MSA来验证在发送给HA的过程中通过MN-FA MSA的每个注册请求。尽管MN-FA MSA对基本协议的操作并不重要，但当FA必须知道注册请求的真实性时，MN-FA MSA是有用的；e、 例如，它将在何时为会话生成记帐记录。MN-FA MSA在与切换优化相关的未来工作中也可能有用。
Similarly, Mobile IPv4 supports an optional MSA between the FA and HA (FA-HA MSA). The FA-HA MSA is useful for authenticating messages between the FA and HA, such as when the HA seeks to inform the FA that it has revoked a Mobile IP registration.
类似地，移动IPv4支持FA和HA之间的可选MSA（FA-HA MSA）。FA-HA MSA可用于验证FA和HA之间的消息，例如当HA试图通知FA其已撤销移动IP注册时。
Note that configuration of MSAs that involve FAs is substantially more difficult than configuring the one between the MN and HA, because the MN and HA are often in the same administrative domain and the MN will retain the same HA for long periods of time. In contrast, the MN is likely to encounter many FAs over time and may often find itself in foreign administrative domains.
请注意，涉及FAs的MSA的配置比在MN和HA之间配置要困难得多，因为MN和HA通常位于同一管理域中，MN将长期保留相同的HA。相比之下，MN可能会随着时间的推移遇到许多FAs，并且可能经常发现自己处于国外管理领域。
The base Mobile IPv4 protocol assumes that MNs are identified by their static home IP addresses and that all MSAs are statically preconfigured. The Diameter Mobile IPv4 application, together with extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4 protocol, allows an MN to be dynamically assigned a home address and/or home agent when it attaches to the Internet. This set of specifications also supports the dynamic configuration of the MN-HA, MN-FA, and FA-HA MSAs. The dynamic configuration of these relationships is important to support deployments in which the MN can attach to a visited network without having a pre-established relationship with it.
基本移动IPv4协议假定MN由其静态主IP地址标识，并且所有MSA都是静态预配置的。Diameter Mobile IPv4应用程序，连同基本移动IPv4协议的扩展[MIPNAI、MIPCHAL、MIPKEYS、AAANAI]，允许MN在连接到Internet时动态分配家庭地址和/或家庭代理。这组规范还支持MN-HA、MN-FA和FA-HA MSA的动态配置。这些关系的动态配置对于支持部署非常重要，在部署中，MN可以连接到已访问的网络，而不必与之建立预先建立的关系。
Initially, the MN is assumed to have a long-term AAA security association only with the AAAH. This security association is indexed by the MN's NAI, and, like the MSAs, comprises an agreement on a SPI, an algorithm, and a shared secret key. The MN enters a visited network and requests service from some FA by sending a Mobile IPv4 Registration Request. The FA contacts an AAAF in its own administrative domain to authenticate and authorize the request for service. The AAAF and AAAH may establish a Diameter session directly with each other, such as via a Diameter Redirect, or may pass messages via a network of Diameter proxies. Where the AAAF and AAAH route messages to each other through proxies, rather than a direct connection, transitive trust is assumed. MNs can include their Network Access Identifier (NAI) in a Mobile IPv4 Registration Request [MIPNAI], which serves in place of the home address to identify the MN. The NAI is used to route Diameter messages toward the correct
最初，假设MN仅与AAAH有长期AAA安全关联。该安全关联由MN的NAI编制索引，并且与MSA一样，包括SPI协议、算法和共享密钥。MN进入访问的网络并通过发送移动IPv4注册请求从某个FA请求服务。FA在其自己的管理域中联系AAAF以验证和授权服务请求。AAAF和AAAH可以彼此直接建立Diameter会话，例如通过Diameter重定向，或者可以通过Diameter代理网络传递消息。当AAAF和AAAH通过代理（而不是直接连接）将消息路由到彼此时，假定为可传递信任。MN可以将其网络访问标识符（NAI）包括在移动IPv4注册请求[MIPNAI]中，该请求代替家庭地址用于识别MN。NAI用于将Diameter消息路由到正确的路径
AAAH. This use of the NAI is consistent with the roaming model defined by the ROAMOPS Working Group [EVALROAM, RFC2607].
啊。NAI的这种使用与ROAMOPS工作组定义的漫游模型一致[EVALROAM，RFC2607]。
The AAAH can authenticate the Registration Request with the use of the MN-AAA security association [MIPCHAL]. If authentication is successful, the AAAH then generates and distributes MSAs to the MN, HA, and FA. For each of the MSA pairs that involve the MN (i.e., MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce and then hashes it together with the MN-AAA shared key to derive the session key for the MSA pair. The nonces are sent to the HA that includes them in the Registration Reply, which enables the MN to derive the same keys [MIPKEYS]. At the same time, the AAAH must distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to the FA. These are sent in Diameter AVPs and must be independently secured by using IPSec or TLS between the AAAH and the FA and between the AAAH and the HA. See section 8 for more information on key derivation and distribution.
AAAH可以使用MN-AAA安全关联[MIPCHAL]对注册请求进行身份验证。如果身份验证成功，AAAH将生成MSA并将其分发给MN、HA和FA。对于涉及MN的每个MSA对（即，MN-HA/HA-MN MSA和MN-FA/FA-MN MSA），AAAH生成一个nonce，然后将其与MN-AAA共享密钥一起散列，以导出MSA对的会话密钥。nonce被发送到HA，HA将其包括在注册回复中，这使得MN能够派生相同的密钥[MIPKEYS]。同时，AAAH必须将MN-HA/HA-MN MSA和FA-HA/HA-FA MSA分配给HA，并且必须将MN-FA/FA-MN MSA和FA-HA/HA-FA MSA分配给FA。这些是以直径AVP发送的，必须通过在AAAH和FA之间以及AAAH和HA之间使用IPSec或TLS进行独立保护。有关密钥派生和分发的更多信息，请参见第8节。
Note that MSAs in Mobile IP are unidirectional in that, for example, the MN-HA MSA (used to protect traffic from the MN to the HA) and the HA-MN MSA (used to protect traffic from the HA to the MN) can use different SPIs, algorithms, and shared secrets. This is true of the base Mobile IP protocol despite common existing practice during manual configuration of MSAs in which all parameters are set to the same value in both directions. This document supports the use of different SPIs in each direction; however, it only supports the distribution of a single session key for each pair of MSAs between two nodes. The security implications of this are discussed in section 13. This document sometimes names only one of the two unidirectional MSAs when referring to the distribution of the single shared secret and the pair of SPIs for the pair of MSAs between two entities.
注意，移动IP中的MSA是单向的，例如，MN-HA MSA（用于保护从MN到HA的流量）和HA-MN MSA（用于保护从HA到MN的流量）可以使用不同的SPI、算法和共享机密。基本移动IP协议也是如此，尽管在MSA的手动配置过程中，所有参数在两个方向上都设置为相同的值，这是常见的现有做法。本文件支持在每个方向使用不同的SPI；但是，它只支持在两个节点之间为每对MSA分发单个会话密钥。第13节讨论了这一点的安全影响。当提及两个实体之间MSA对的单个共享秘密和SPI对的分发时，本文档有时仅命名两个单向MSA中的一个。
In addition to supporting the derivation and transport of the MN-HA, MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff. When an MN moves from one point of attachment to another, the MN can continue the same Mobile IPv4 session by using its existing HA and home address.
除了支持MN-HA、MN-FA和FA-HA MSA的派生和传输外，此应用程序还支持MIPv4切换。当MN从一个连接点移动到另一个连接点时，MN可以使用其现有的HA和家庭地址继续相同的移动IPv4会话。
The MN accomplishes this by sending a Mobile IPv4 Registration Request from its new point of attachment. To enable a single set of accounting records to be maintained for the entire session, including handoffs, it is necessary to allow the AAAH to bind the new registration to the pre-existing session. To enable the Mobile IPv4 Registration Request to be routed to the same AAAH, the MN SHOULD
MN通过从其新的连接点发送移动IPv4注册请求来实现这一点。为了能够在整个会话（包括切换）中维护一组记帐记录，有必要允许AAAH将新注册绑定到先前存在的会话。要使移动IPv4注册请求能够路由到同一AAAH，MN应
include the AAAH NAI [AAANAI] in such re-registrations. Also, to assist the AAAH in routing the messages to the MN's existing HA the mobile node SHOULD include the HA NAI [AAANAI] in such re-registrations. If the mobile node does not support the Mobile IPv4 AAA NAI extension [AAANAI], this functionality is not available.
将AAAH-NAI[AAANAI]纳入此类重新注册。此外，为了帮助AAAH将消息路由到MN的现有HA，移动节点应在此类重新注册中包括HA NAI[AAANAI]。如果移动节点不支持移动IPv4 AAA NAI扩展[AAANAI]，则此功能不可用。
The remainder of this document is structured as follows. Section 2 provides acronym definitions. Section 3 provides some examples and message flows illustrating both the Mobile IPv4 and Diameter messages that occur when a mobile node attaches to the Internet. Section 4 defines the relationship of this application to the Diameter Base Protocol. Section 5 defines the new command codes. Section 6 defines the new result codes used by this application. Section 7 defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8 gives an overview of the key distribution capability, and Section 9 defines the key distribution AVPs. Section 10 defines the accounting AVPs, and section 11 contains a listing of all AVPs and their occurrence in Diameter commands. Finally, sections 12 and 13 give IANA and security considerations, respectively.
本文件其余部分的结构如下。第2节提供了首字母缩略词的定义。第3节提供了一些示例和消息流，说明了移动节点连接到Internet时发生的移动IPv4和Diameter消息。第4节定义了此应用程序与Diameter基本协议的关系。第5节定义了新的命令代码。第6节定义了本应用程序使用的新结果代码。第7节定义了一组强制属性值对（AVP）。第8节概述了密钥分发功能，第9节定义了密钥分发AVP。第10节定义了会计AVP，第11节包含所有AVP及其在Diameter命令中出现的列表。最后，第12节和第13节分别给出了IANA和安全注意事项。
AAAH Authentication, Authorization, and Accounting Home AAAF Authentication, Authorization, and Accounting Foreign AMA AA-Mobile-Node-Answer AMR AA-Mobile-Node-Request ASR Abort-Session-Request AVP Attribute Value Pair CoA Care-of-Address FA Foreign Agent FQDN Fully Qualified Domain Name HA Home Agent HAA Home-Agent-MIP-Answer HAR Home-Agent-MIP-Request MN Mobile Node MSA Mobility Security Association NAI Network Access Identifier RRQ Registration Request SPI Security Parameters Index STR Session-Termination-Request
AAAH认证、授权和记帐家庭AAAF认证、授权，和记帐外部AMA AA移动节点应答AMR AA移动节点请求ASR中止会话请求AVP属性值对CoA转交地址FA外部代理FQDN完全限定域名HA归属代理HAA归属代理MIP应答HAR归属代理MIP请求MN移动节点MSA移动安全协会NAI网络访问标识符RRQ注册请求SPI安全参数索引STR会话终止请求
This section presents four scenarios illustrating Diameter Mobile IPv4 application and describes the operation of key distribution.
本节介绍了Diameter移动IPv4应用程序的四个场景，并描述了密钥分发的操作。
In this document, the role of the "attendant" [MIPREQ] is performed by either the FA (when it is present in a visited network) or the HA (for co-located mobile nodes not registering via an FA), and these terms will be used interchangeably in the following scenarios.
在本文档中，“助理”[MIPREQ]的角色由FA（当它存在于访问的网络中时）或HA（对于不通过FA注册的同一位置的移动节点）执行，并且这些术语将在以下场景中互换使用。
When a mobile node requests service by issuing a Registration Request to the foreign agent, the foreign agent creates the AA-Mobile-Node-Request (AMR) message, which includes the AVPs defined in section 7. The Home Address, Home Agent, Mobile Node NAI, and other important fields are extracted from the registration messages for possible inclusion as Diameter AVPs. The AMR message is then forwarded to the local Diameter server, known as the AAA-Foreign, or AAAF.
当移动节点通过向外部代理发出注册请求来请求服务时，外部代理创建AA移动节点请求（AMR）消息，其中包括第7节中定义的avp。从注册消息中提取归属地址、归属代理、移动节点NAI和其他重要字段，以便可能包含为Diameter avp。然后将AMR消息转发到本地Diameter服务器，称为AAA外部服务器或AAAF。
Visited Realm Home Realm
+-----------+ +-----------+
|example.net| AMR/AMA |example.org|
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +-----------+ communication +-----------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@example.org
+--------+
Visited Realm Home Realm
+-----------+ +-----------+
|example.net| AMR/AMA |example.org|
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +-----------+ communication +-----------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@example.org
+--------+
Figure 1. Inter-realm Mobility
图1。域间移动性
Upon receiving the AMR, the AAAF follows the procedures outlined in [DIAMBASE] to determine whether the AMR should be processed locally or forwarded to another Diameter server known as the AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node (mn@example.org) requests service from a foreign provider (example.net). The request received by the AAAF is forwarded to example.org's AAAH server.
收到AMR后，AAAF遵循[DIAMBASE]中概述的程序，以确定AMR是否应在本地处理或转发到另一个称为AAA Home或AAAH的Diameter服务器。图1显示了一个示例，其中移动节点(mn@example.org)从外部提供商（例如.net）请求服务。AAAF收到的请求被转发到example.org的AAAH服务器。
Figure 2 shows the message flows involved when the foreign agent invokes the AAA infrastructure to request that a mobile node be authenticated and authorized. Note that it is not required that the foreign agent invoke AAA services every time a Registration Request is received from the mobile, but rather only when the prior authorization from the AAAH expires. The expiration time of the authorization is communicated through the Authorization-Lifetime AVP in the AA-Mobile-Node-Answer (AMA; see section 5.2) from the AAAH.
图2显示了当外部代理调用AAA基础结构以请求对移动节点进行身份验证和授权时所涉及的消息流。请注意，不要求外部代理在每次从移动设备接收到注册请求时调用AAA服务，而是仅当来自AAAH的事先授权到期时才调用AAA服务。授权的到期时间通过AAAH在AA移动节点应答（AMA；见第5.2节）中的授权生存期AVP进行通信。
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
Reg-Req&MN-AAA ---->
Reg-Req&MN-AAA ---->
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
HAR----------->
Session-Id = bar
HAR----------->
Session-Id = bar
<----------HAA
<----------HAA
Session-Id = bar
Session-Id = bar
<-----------AMA
Session-Id = foo
<-----------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<-------Reg-Reply
<-------Reg-Reply
Figure 2. Mobile IPv4/Diameter Message Exchange
图2。移动IPv4/Diameter消息交换
The foreign agent (as shown in Figure 2) MAY provide a challenge, which would give it direct control over the replay protection in the Mobile IPv4 registration process, as described in [MIPCHAL]. The mobile node includes the Challenge and MN-AAA authentication extension to enable authorization by the AAAH. If the authentication data supplied in the MN-AAA extension is invalid, the AAAH returns
外部代理（如图2所示）可能会提供质询，这将使其能够直接控制移动IPv4注册过程中的重播保护，如[MIPCHAL]中所述。移动节点包括质询和MN-AAA认证扩展以启用AAAH的授权。如果MN-AAA扩展中提供的身份验证数据无效，AAAH将返回
the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED.
结果代码AVP设置为DIAMETER_AUTHENTICATION_的响应（AMA）被拒绝。
The above scenario causes the MN-FA and MN-HA keys to be exposed to Diameter agents all along the Diameter route. If this is a concern, a more secure approach is to eliminate the AAAF and other Diameter agents, as shown in Figure 3.
上述场景导致MN-FA和MN-HA密钥在整个Diameter路由中暴露于Diameter代理。如果这是一个问题，更安全的方法是消除AAAF和其他直径代理，如图3所示。
Redirect FA AAAF Agent AAAH
重定向FA AAAF代理AAAH
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
Setup Security Association
<-------------------------------------------------->
Setup Security Association
<-------------------------------------------------->
AMR
AMR
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
Figure 3. Use of a Redirect Server with AMR/AMA
图3。通过AMR/AMA使用重定向服务器
In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC]-based security association with the AAAH directly and runs the AMR/AMA exchange over it. This provides end-to-end security for secret keys that may have to be distributed.
在图3中，FA直接与AAAH建立基于TLS[TLS]或IPSec[IPSec]的安全关联，并在其上运行AMR/AMA交换。这为可能必须分发的密钥提供了端到端的安全性。
Figure 4 shows the interaction between the AAAH and HA with the help of a redirect agent. When the AAAH and HA are in the same network, it is likely that the AAAH knows the IP address of the HA, so the redirect server would therefore not be needed; however, it is shown anyway for completeness. The redirect server will most likely be used in the case where the HA is allocated in a foreign network (see section 3.2 for more details of HA allocation in foreign networks).
图4显示了在重定向代理的帮助下AAAH和HA之间的交互。当AAAH和HA在同一网络中时，AAAH可能知道HA的IP地址，因此不需要重定向服务器；但是，为了完整性，还是显示了它。重定向服务器最有可能用于HA在外部网络中分配的情况（有关外部网络中HA分配的更多详细信息，请参阅第3.2节）。
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Figure 4. Use of a Redirect Server with HAR/HAA
图4。使用带有HAR/HAA的重定向服务器
As in Figure 2, the FA of Figure 3 would still provide the challenge and the mobile sends the RRQ, etc.; however, these steps were eliminated from Figure 3 to reduce clutter. The redirect server eliminates the AAAF and any other Diameter agents from seeing the keys as they are transported to the FA and HA. Note that the message flows in Figures 3 and 4 apply only to the initial authentication and key exchange. Accounting messages would still be sent via Diameter agents, not via the direct connection, unless network policies dictate otherwise.
如图2所示，图3的FA仍然提供挑战，移动设备发送RRQ，等等。；然而，为了减少混乱，图3中取消了这些步骤。重定向服务器消除了AAAF和任何其他Diameter代理在密钥传输到FA和HA时看到密钥的情况。注意，图3和图4中的消息流仅适用于初始身份验证和密钥交换。记帐消息仍将通过Diameter代理发送，而不是通过直接连接发送，除非网络策略另有规定。
A mobile node that supports the AAA NAI extension [AAANAI], which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, when re-authenticating. Therefore, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent-Host AVP with the identity and realm of the assigned HA found in the HA-NAI. If, on the other hand, the mobile node does not support the AAA NAI extension, the FA may not have the identity of the AAAH and the identity and realm of the assigned HA. This means that without support of the AAA NAI extension, the FA may not be able to guarantee that the AMR will be destined to the same AAAH, which previously authenticated and authorized the mobile node, as the FA may not know the identity of the AAAH.
支持AAA NAI扩展[AAANAI]的移动节点（之前已通过身份验证和授权）在重新身份验证时，必须始终在AAA NAI扩展的HA标识子类型中包含分配的归属代理，并在AAA NAI扩展的AAAH标识子类型中包含授权归属AAA服务器。因此，如果FA生成的AMR用于先前授权的会话，则它必须包括目标主机AVP，其标识为AAAH-NAI中找到的AAAH，以及MIP归属代理主机AVP，其标识和领域为HA-NAI中找到的分配HA。另一方面，如果移动节点不支持AAA NAI扩展，则FA可能不具有AAAH的标识以及所分配HA的标识和领域。这意味着，如果没有AAA NAI扩展的支持，FA可能无法保证AMR将被发送到相同的AAAH，该AAAH先前对移动节点进行了认证和授权，因为FA可能不知道AAAH的身份。
If the mobile node was successfully authenticated, the AAAH then determines which Home Agent to use for the session. First, the AAAH checks whether an HA has been requested by the MN by checking the MIP-Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The administrative domain owning the HA may be determined from the realm portion of the MIP-Home-Agent-Host AVP, or by checking the
如果移动节点已成功通过身份验证，AAAH将确定会话使用哪个归属代理。首先，AAAH通过检查MIP归属代理地址AVP和MIP归属代理主机AVP来检查MN是否请求了HA。拥有HA的管理域可以从MIP归属代理主机AVP的领域部分确定，或者通过检查
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and the value of the MIP-Originating-Foreign-AAA AVP. If the requested HA belongs to a permitted administrative domain, the AAAH SHOULD use the given HA for the session. Otherwise, the AAAH returns the response (AMA) with the Result-Code AVP set to either DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or DIAMETER_ERROR_HA_NOT_AVAILABLE.
MIP特征向量AVP的“外部网络中的归属代理”标志和源自外部AAA AVP的MIP值。如果请求的HA属于许可的管理域，AAAH应在会话中使用给定的HA。否则，AAAH返回响应（AMA），结果代码AVP设置为DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE或DIAMETER_ERROR_HA_NOT_AVAILABLE。
If the MN has not requested any particular HA, then an HA MUST be dynamically allocated. In this case the MIP-Feature-Vector will have the Home-Agent-Requested flag set. If the Home-Address-Allocatable-Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent-Available flag is set, then the AAAH SHOULD allow the foreign realm to allocate the HA (see section 3.2) but MAY allocate one itself in the home realm if dictated by local policy. If the Home-Address-Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST allocate an HA in the home realm on behalf of the MN. Allocation of the HA can be done in a variety of ways, including by using a load-balancing algorithm to keep the load on all home agents equal. The actual algorithm used and the method of discovering the home agents are outside the scope of this specification.
如果MN没有请求任何特定HA，则必须动态分配HA。在这种情况下，MIP特征向量将设置Home Agent Requested标志。如果未设置“仅在家庭领域可分配的家庭地址”标志，并且设置了“外国家庭代理可用”标志，则AAAH应允许外国领域分配HA（见第3.2节），但如果当地政策要求，AAAH可在家庭领域自行分配HA。如果设置了Home Address allocated Only in Home Realm标志，则AAAH必须代表MN在Home Realm中分配HA。HA的分配可以通过多种方式完成，包括使用负载平衡算法来保持所有家庭代理上的负载相等。使用的实际算法和发现归属代理的方法不在本规范的范围内。
The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains the Mobile IPv4 Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer to Figure 4 if the AAAH does not have a direct path to the HA. The AAAH MAY allocate a home address for the mobile node, and the Home Agent MUST support home address allocation. In the event that the AAAH handles address allocation, it includes the home address in a MIP-Mobile-Node-Address AVP within the HAR. The absence of this AVP informs the Home Agent that it must perform the home address allocation.
然后，AAAH向分配或请求的归属代理发送归属代理MIP请求（HAR），其中包含封装在MIP Reg Request AVP中的移动IPv4注册请求消息数据。如果AAAH没有到HA的直接路径，请参考图4。AAAH可以为移动节点分配归属地址，并且归属代理必须支持归属地址分配。在AAAH处理地址分配的情况下，它在HAR内的MIP移动节点地址AVP中包括家庭地址。缺少此AVP会通知归属代理必须执行归属地址分配。
Upon receipt of the HAR, the home agent first processes the Diameter message. The home agent processes the MIP-Reg-Request AVP and creates the Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. In the creation of the Registration Reply, the Home Agent MUST include the HA NAI and the AAAH NAI, which will be created from the Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is needed, the home agent MUST also assign one and include the address in both the Registration Reply and the MIP-Mobile-Node-Address AVP.
收到HAR后，归属代理首先处理Diameter消息。归属代理处理MIP Reg Request AVP并创建注册回复，并将其封装在MIP Reg Reply AVP中。在创建注册回复时，国内代理必须包括HA NAI和AAAH NAI，这将由HAR的源主机AVP和源领域AVP创建。如果需要归属地址，归属代理还必须分配一个，并在注册回复和MIP移动节点地址AVP中包含该地址。
Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer (AMA) message, which includes the same Acct-Multi-Session-Id contained in the HAA and the MIP-Home-Agent-Address and MIP-Mobile-
在收到HAA后，AAAH创建AA移动节点应答（AMA）消息，该消息包括HAA中包含的相同Acct多会话Id以及MIP归属代理地址和MIP移动-
Node-Address AVPs in the AMA message. See Figures 3 and 4 for the use of the redirect agent for the secure transport of the HAA and AMA messages.
AMA消息中的节点地址AVP。有关安全传输HAA和AMA消息的重定向代理的使用，请参见图3和图4。
See section 4.1 for information on the management of sessions and session identifiers by the Diameter Mobile IPv4 entities.
有关Diameter移动IPv4实体管理会话和会话标识符的信息，请参见第4.1节。
The Diameter Mobile IPv4 application allows a home agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag set to one. If the home agent address is set to 255.255.255.255, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero.
Diameter Mobile IPv4应用程序允许按照[MIPREQ，CDMA2000]中的要求在外部网络中分配归属代理。当外部代理检测到移动节点在注册请求消息中具有等于0.0.0.0或255.255.255.255的归属代理地址时，它必须添加MIP特征向量AVP，其中归属代理请求标志设置为1。如果主代理地址设置为255.255.255.255，则外部代理必须将仅在主域中可分配的主地址标志设置为1。如果归属代理地址设置为0.0.0.0，则外部代理必须将仅可在归属领域中分配的归属地址标志设置为零。
When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one and with the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in order to inform the AAAH that it is willing and able to assign a Home Agent for the mobile node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-Agent-Host AVP contains the identity (i.e., a DiameterIdentity, which is an FQDN) of the home agent that would be assigned to the mobile node, and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. The AAAF now sends the AMR to the AAAH. However, as discussed above, the use of Diameter agents between the FA and AAAH would expose the MN-FA key. If this is deemed undesirable, a redirect server approach SHOULD be utilized to communicate the AMR to the AAAH. This causes the FA to communicate the AMR directly to the AAAH via a security association.
当AAAF接收到AMR消息，其中归属代理请求标志设置为1并且归属地址仅可在归属领域中分配标志等于零时，AAAF可以在MIP特征向量AVP中设置外来归属代理可用标志，以便通知AAAH它愿意并且能够为移动节点分配归属代理。这样做时，AAAF必须包括MIP候选归属代理主机AVP和MIP发起的外来AAA AVP。MIP候选归属代理主机AVP包含将被分配给移动节点的归属代理的标识（即直径，它是FQDN），并且MIP发起外来AAA AVP包含AAAF的标识。AAAF现在将AMR发送给AAAH。然而，如上所述，在FA和AAAH之间使用直径剂会暴露MN-FA键。如果认为这是不需要的，则应使用重定向服务器方法将AMR与AAAH通信。这导致FA通过安全关联将AMR直接传达给AAAH。
If the mobile node with AAA NAI extension support [AAANAI] has been previously authorized by the AAAH, now has to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR, including the MIP-Home-Agent-Address AVP and the Destination-Host AVP based on the AAAH NAI, and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
如果具有AAA NAI扩展支持[AAANAI]的移动节点先前已由AAAH授权，现在必须重新认证，并且请求将分配的归属代理保留在外部网络中，则移动节点必须在向FA的注册请求中包括HA NAI和AAAH NAI。收到后，FA将创建AMR，包括MIP归属代理地址AVP和基于AAAH NAI的目标主机AVP，并包括基于归属代理NAI的MIP归属代理主机AVP。如果AAAF授权使用请求的归属代理，AAAF必须在MIP特征向量AVP中的外部网络位中设置归属代理。
If the mobile node has to be re-authenticated but does not support the AAA NAI extension, it sends a registration request without the AAA NAI and the HA NAI, even though it has previously been authorized by the AAAH and requests to keep the assigned home agent in the foreign network. Upon receipt, the FA will create the AMR, including the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested home agent, and if it knows that the agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
如果移动节点必须被重新认证但不支持AAA-NAI扩展，则其发送注册请求而不使用AAA-NAI和HA-NAI，即使其先前已被AAAH授权并请求将分配的归属代理保持在外部网络中。收到后，FA将创建AMR，包括MIP Home Agent地址AVP。如果AAAF授权使用所请求的归属代理，并且如果AAAF知道该代理在其自己的域中，则AAAF必须在MIP特征向量AVP中的外部网络比特中设置归属代理。
When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a Home Agent for the mobile node (i.e., the Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP), or if the AMR indicates that the AAAF has offered a previously allocated Home Agent for the mobile node (i.e., the Home-Agent-In-Foreign-Network is set in the MIP-Feature-Vector AVP), then the AAAH must decide whether its local policy would allow the user to have or keep a home agent in the foreign network. Assuming that the mobile node is permitted to do so, the AAAH determines the IP address of the HA based upon the FQDN of the HA by using DNS or learns it via an MIP-Home-Agent-Address AVP in a redirect response to an HAR (i.e., if the redirect server adds this AVP to the HAA). Then it sends an HAR message to Home Agent by including the Destination-Host AVP set to the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP. If DNS is used to determine the HA IP address, it is assumed that the HA has a public address and that it can be resolved by DNS.
当AAAH接收到AMR消息时，它首先根据MIP Reg Request AVP和MIP MN AAA Auth AVP检查移动节点提供的认证数据，并确定是否授权移动节点。如果AMR指示AAAF已经提供给移动节点分配归属代理（即，在MIP特征向量AVP中设置了可用的外来归属代理），或者如果AMR指示AAAF已经为移动节点提供了先前分配的归属代理（即，在MIP特征向量AVP中设置外部网络中的归属代理），则AAAH必须决定其本地策略是否允许用户在外部网络中拥有或保留归属代理。假设允许移动节点这样做，AAAH通过使用DNS基于HA的FQDN确定HA的IP地址，或在对HAR的重定向响应中通过MIP归属代理地址AVP学习（即，如果重定向服务器将此AVP添加到HAA）。然后，通过将目标主机AVP设置为AMR的MIP候选主代理主机AVP或MIP主代理主机AVP中的值，将HAR消息发送给主代理。如果使用DNS确定HA IP地址，则假定HA具有公共地址，并且可以通过DNS解析。
Security considerations may require that the HAR be sent directly from the AAAH to the HA without the use of intermediary Diameter agents. This requires that a security association between the AAAH and HA be established, as in Figure 4. If no security association can be established, the AAAH MUST return an AMA with the Result-Code AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
出于安全考虑，可能需要将HAR直接从AAAH发送给医管局，而无需使用中介机构。这需要在AAAH和HA之间建立安全关联，如图4所示。如果无法建立安全关联，AAAH必须返回结果代码AVP设置为DIAMETER\u ERROR\u END\u to\u END\u MIP\u KEY\u ENCRYPTION的AMA。
If Diameter agents are being used (e.g., if there is no redirect server) the AAAH sends the HAR to the originating AAAF. In this HAR the Destination-Host AVP is set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR is copied into the HAR.
如果正在使用Diameter代理（例如，如果没有重定向服务器），AAAH将HAR发送到发起AAAF。在该HAR中，目标主机AVP被设置为在AMR的MIP原始外部AAA AVP中找到的值，并且在AMR中找到的MIP归属代理主机AVP或MIP候选归属代理主机AVP被复制到HAR中。
Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, this new AAAF will send the HAR to the HA.
因此，AAAH必须始终将源自外部AAA AVP的MIP从AMR消息复制到HAR消息。如果另一个AAAF收到HAR，此新AAAF将向HA发送HAR。
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Figure 5. Home Agent Allocated in Visited Realm
图5。在访问域中分配的归属代理
Upon receipt of an HAA from the Home Agent in the visited realm, the AAAF forwards the HAA to the AAAH in the home realm. The AMA is then constructed and issued to the AAAF and, finally, to the FA. If the Result-Code indicates success, the HAA and AMA MUST include the MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs.
在收到来自访问域中的归属代理的HAA后，AAAF将HAA转发给归属域中的AAAH。然后构建AMA，并将其发送给AAAF，最后发送给FA。如果结果代码指示成功，HAA和AMA必须包括MIP归属代理地址和MIP移动节点地址AVPs。
If exposing keys to the Diameter Agents along the way represents an unacceptable security risk, then the redirect approach depicted in Figures 3 and 4 MUST be used instead.
如果沿途将密钥暴露给Diameter代理代表不可接受的安全风险，则必须使用图3和图4中描述的重定向方法。
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
Figure 6. MIP/Diameter Exchange for HA Is Allocated in Visited Realm
图6。HA的MIP/Diameter交换在访问域中分配
If the mobile node moves to another foreign Network, it MAY either request to keep the same Home Agent within the old foreign network or request to get a new one in the new foreign network. If the AAAH is willing to provide the requested service, the AAAH will have to provide services for both visited networks; e.g., key refresh.
如果移动节点移动到另一个外部网络，它可以请求在旧的外部网络中保持相同的归属代理，或者请求在新的外部网络中获得新的归属代理。如果AAAH愿意提供所请求的服务，AAAH必须为两个访问的网络提供服务；e、 例如，键刷新。
If a mobile node registers with the Home Agent as a co-located mobile node, no foreign agent is involved. Therefore, when the Home Agent receives the Registration Request, an AMR message is sent to the local AAAH server, with the Co-Located-Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent also includes the Acct-Multi-Session-Id AVP (see sections 4.1.1 and 4.1.2) in the AMR sent to the AAAH, as the AAAH may find this piece of session-state or log entry information useful.
如果移动节点向归属代理注册为同一位置的移动节点，则不涉及任何外部代理。因此，当归属代理接收到注册请求时，AMR消息被发送到本地AAAH服务器，并且在MIP特征向量AVP中设置了共同定位的移动节点比特。归属代理还包括发送给AAAH的AMR中的Acct多会话Id AVP（参见第4.1.1和4.1.2节），因为AAAH可能会发现这段会话状态或日志条目信息很有用。
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 7. Co-located Mobile Node
图7。同址移动节点
If the MN-HA-Key-Requested bit was set in the AMR message from the Home Agent, the home agent and mobile node's session keys would be present in the AMA message.
如果在来自归属代理的AMR消息中设置了MN HA密钥请求位，则归属代理和移动节点的会话密钥将出现在AMA消息中。
Figure 8 shows a signaling diagram that indicates a secure way to set up the necessary security associations when using redirect servers. The Proxy AAA represents any AAA server or servers that the HA may use. This applies to the visited or home network.
图8显示了一个信令图，它指出了在使用重定向服务器时设置必要安全关联的安全方法。代理AAA表示HA可能使用的任何AAA服务器。这适用于到访网络或家庭网络。
Local redirect HA Proxy AAA Agent AAAH
本地重定向HA代理AAA代理AAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA
图8。将重定向服务器用于位于同一位置的CoA和AMR/AMA
To allow the scaling of wireless data access across administrative domains, it is necessary to minimize the number of pre-existing Mobility Security Associations (MSAs) required. This means that each Foreign Agent should not be required to have a pre-configured MSA with each Home Agent on the Internet, nor should the mobile node be required to have a pre-configured MSA (as defined in [MOBILEIP]) with any specific foreign agent. Furthermore, when the mobile node requests a dynamically allocated home agent, it is likely to receive the address of a home agent for which it has no available mobility security association.
为了允许跨管理域扩展无线数据访问，有必要尽量减少所需的现有移动安全关联（MSA）的数量。这意味着不应要求每个外部代理与互联网上的每个归属代理具有预先配置的MSA，也不应要求移动节点与任何特定外部代理具有预先配置的MSA（如[MOBILEIP]中定义的）。此外，当移动节点请求动态分配的归属代理时，它很可能接收其没有可用的移动安全关联的归属代理的地址。
The Diameter Mobile IPv4 application solves this by including key distribution functionality, which means that after a Mobile Node is authenticated the authorization phase includes the generation of session keys and nonces. Specifically, three session keys and two nonces are generated:
Diameter Mobile IPv4应用程序通过包括密钥分发功能来解决这一问题，这意味着在对移动节点进行身份验证后，授权阶段包括生成会话密钥和nonce。具体而言，将生成三个会话密钥和两个nonce：
- K1: The MN-HA Session Key, which will be part of the MSA between the Mobile Node and the Home Agent. The MN-HA Session Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates this key using the same formula that AAA uses.
- K1:MN-HA会话密钥，它将是移动节点和归属代理之间MSA的一部分。MN-HA会话密钥来自AAA生成的nonce。移动节点在注册回复中获得该nonce，并使用AAA使用的相同公式生成该密钥。
- K2: The MN-FA Key, which will be part of the MSA between the Mobile Node and the Foreign Agent. The MN-FA Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates the MN-FA key using the same formula that AAA uses.
- K2:MN-FA密钥，它将是移动节点和外部代理之间MSA的一部分。MN-FA密钥来自AAA生成的nonce。移动节点在注册回复中获得该nonce，并使用AAA使用的相同公式生成MN-FA密钥。
- K3: The FA-HA Key, which will be part of the MSA between the Foreign Agent and the Home Agent.
- K3:FA-HA密钥，它将是外国代理和本国代理之间MSA的一部分。
The same session key is used in both directions between two entities; e.g., the Mobile Node and the Foreign Agent use the same session key for the MN-FA and the FA-MN authentication extensions. The security implications of this are examined in section 13. However, the SPIs may be different for the MN-FA and the FA-MN authentication extensions. The SPI for the MN-FA MSA is used on messages sent from the MN to the FA, and the SPI for the FA-MN MSA is used on messages sent from the FA to the MN.
在两个实体之间的两个方向上使用相同的会话密钥；e、 例如，移动节点和外部代理对MN-FA和FA-MN认证扩展使用相同的会话密钥。第13节研究了这一点的安全影响。然而，对于MN-FA和FA-MN认证扩展，SPI可能不同。MN-FA MSA的SPI用于从MN发送到FA的消息，FA-MN MSA的SPI用于从FA发送到MN的消息。
All keys and nonces are generated by the AAAH, even if a Home Agent is dynamically allocated in the foreign network.
所有密钥和nonce都由AAAH生成，即使在外部网络中动态分配了归属代理。
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity using the keys created by the DIAMETER server.
图9描述了使用DIAMETER服务器创建的密钥用于移动IPv4消息完整性的MSA。
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9. Mobility Security Associations after Session Key and Nonce Distribution
图9。会话密钥和Nonce分发后的移动安全关联
The keys destined for the foreign and home agent are propagated to the mobility agents via the Diameter protocol. If exposing keys to the Diameter Agents along the way represents an unacceptable security risk, then the keys MUST be protected either by IPSec or TLS security associations that exist directly between the HA and AAAH or the FA and AAAF, as explained above.
通过Diameter协议将目的地为外地代理和本地代理的密钥传播到移动代理。如果沿途将密钥暴露给Diameter代理代表不可接受的安全风险，则必须通过直接存在于HA和AAAH或FA和AAAF之间的IPSec或TLS安全关联来保护密钥，如上所述。
The keys destined for the mobile node MUST also be propagated via the Mobile IPv4 protocol and therefore MUST follow the mechanisms described in [MIPKEYS] instead. In [MIPKEYS], the mobile node receives a nonce for each key it needs, and the mobile node will use the nonce and the long-term shared secret to create the keys (see section 8).
目的地为移动节点的密钥也必须通过移动IPv4协议传播，因此必须遵循[MIPKEYS]中描述的机制。在[MIPKEYS]中，移动节点接收其需要的每个密钥的nonce，并且移动节点将使用nonce和长期共享密钥来创建密钥（参见第8节）。
Once the session keys have been established and propagated, the mobility devices can exchange registration information directly, as defined in [MOBILEIP], without the need of the Diameter infrastructure. However, the session keys have a lifetime, after which the Diameter infrastructure MUST be invoked again if new session keys and nonces are to be acquired.
一旦建立并传播了会话密钥，移动设备就可以直接交换注册信息，如[MOBILEIP]中所定义的，而无需Diameter基础设施。但是，会话密钥有一个生存期，在此之后，如果要获取新的会话密钥和nonce，则必须再次调用Diameter基础结构。
This section details the relationship of the Diameter Mobile IPv4 application to the Diameter base protocol.
本节详细介绍Diameter移动IPv4应用程序与Diameter基本协议的关系。
This document specifies Diameter Application-ID 2. Diameter nodes conforming to this specification MAY advertise support by including the value of two (2) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA commands. The value of two (2) MUST be used as the Application-Id in all ACR/ACA commands, as this application defines new, mandatory AVPs for accounting. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA and ASR/ASA commands, as these are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document.
本文档指定直径应用程序ID 2。符合本规范的Diameter节点可通过在功能交换请求和功能交换应答命令[DIAMBASE]的验证应用程序Id或Acct应用程序Id AVP中包含两（2）个值来公布支持。两（2）的值必须用作所有AMR/AMA和HAR/HAA命令中的应用程序Id。两（2）的值必须用作所有ACR/ACA命令中的应用程序Id，因为该应用程序定义了新的、强制性的会计AVP。零（0）值应用作所有STR/STA和ASR/ASA命令中的应用程序Id，因为这些命令在Diameter base协议中定义，本文档中未定义这些命令的其他强制性AVP。
Given the nature of Mobile IPv4, re-authentication can only be initiated by a mobile node, which does not participate in the Diameter message exchanges. Therefore, Diameter server initiated re-auth does not apply to this application, and RAR/RAA commands MUST NOT be sent for Diameter Mobile IPv4 sessions.
鉴于移动IPv4的性质，重新认证只能由不参与Diameter消息交换的移动节点发起。因此，Diameter服务器启动的重新身份验证不适用于此应用程序，并且不得为Diameter移动IPv4会话发送RAR/RAA命令。
The AAAH and AAAF MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST NOT maintain session-state. The AAAH, AAAF, proxies and relays agents MUST maintain transaction state.
AAAH和AAAF可以保持会话状态，或者可以是会话无状态的。AAA重定向代理和AAA中继代理不能保持会话状态。AAAH、AAAF、代理和中继代理必须维护事务状态。
A mobile node's session is identified via its identity in the User-Name AVP and the MIP-Mobile-Node-Address, and the MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state
移动节点的会话通过其在用户名AVP和MIP移动节点地址以及MIP归属代理地址AVPs中的标识来识别。这是允许会话状态的必要条件
machine, defined in the base protocol [DIAMBASE], to be used without modification for this application. However, as the MN may interact with more than one FA during the life of its session, it is important for the Diameter Mobile IPv4 application to distinguish the two pieces of the session (some state at the FA, some state at the HA) and to manage them independently. The following sub-sections give further details.
在基本协议[DIAMBASE]中定义的机器，用于此应用而无需修改。然而，由于MN可能在其会话的生命周期内与多个FA交互，因此Diameter移动IPv4应用程序区分会话的两个部分（FA处的一些状态，HA处的一些状态）并独立管理它们是很重要的。以下小节提供了进一步的详细信息。
During creation of the AMR, the FA will choose a session identifier. During the creation of the HAR, the AAAH MUST use a different session identifier than that used in the AMR/AMA. If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR.
在创建AMR期间，FA将选择会话标识符。在HAR的创建过程中，AAAH必须使用与AMR/AMA中使用的会话标识符不同的会话标识符。如果AAAH是会话有状态的，那么它必须为代表给定移动节点的会话启动的所有HARs发送相同的会话标识符。否则，如果AAAH是会话无状态的，它将为每个HAR生成唯一的会话id。
When the HA is first allocated, it MUST create and include an Acct-Multi-Session-Id AVP in the HAA returned to the AAAH. This identifier will be kept constant for the life of the Mobile IPv4 session, as detailed in the next subsection.
首次分配HA时，必须在返回给AAAH的HAA中创建并包括Acct多会话Id AVP。在移动IPv4会话的生命周期内，此标识符将保持不变，详见下一小节。
Given the nature of Mobile IPv4, a mobile node MAY receive service from many foreign agents during a period of time. However, the home realm should not view these handoffs as different sessions, as this could affect billing systems. Furthermore, foreign agents usually do not communicate between each other, which implies that AAA information cannot be exchanged between these entities.
鉴于移动IPv4的性质，一个移动节点可能在一段时间内从许多外部代理接收服务。但是，家庭领域不应将这些切换视为不同的会话，因为这可能会影响计费系统。此外，外国代理之间通常不进行通信，这意味着这些实体之间无法交换AAA信息。
A handoff registration request from a mobile node will cause the FA to send an AMR to its AAAF. The AMR will include a new session identifier and MAY be sent to a new AAAF (i.e., a AAAF different from that used by the previous FA). However, the AMR shall be received by the AAAH to which the user is currently registered (possibly via the redirect mechanism depicted in Figure 3).
来自移动节点的切换注册请求将导致FA向其AAAF发送AMR。AMR将包括新的会话标识符，并且可以发送给新的AAAF（即，与先前FA使用的AAAF不同的AAAF）。然而，AMR应由用户当前注册的AAAH接收（可能通过图3中描述的重定向机制）。
As the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node with a new session identifier and the HA can guarantee that this request is to extend an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier.
由于AAAH可能是无状态会话，因此有必要将医管局收到的HAR识别为现有会话的延续。如果HA接收到具有新会话标识符的移动节点的HAR，并且HA可以保证该请求是为了扩展现有服务，则HA必须能够修改其内部会话状态信息以反映新会话标识符。
For correlation to occur, accounting records must have some commonality across handoffs. Therefore, the home agent MUST send the same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Acct-Multi-Session-Id when receiving an HAR for a new session and returns this same value in every HAA for the session. This Acct-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in the accounting messages, as depicted in Figure 10.
为了产生相关性，会计记录必须在各个交接中具有某些共性。因此，归属代理必须在移动会话的所有HAA中发送相同的Acct多会话Id AVP值。也就是说，HA在接收新会话的HAR时生成唯一的Acct多会话Id，并在会话的每个HAA中返回相同的值。AMA中的AAAH将此Acct多会话Id AVP返回给外部代理。外部代理和本地代理都必须在记帐消息中包含Acct多会话Id，如图10所示。
A foreign and home agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks. For a Diameter Server to release any resources allocated to a specific mobile node, that server has to receive a Session-Termination-Request (STR) from a mobility agent. The mobility agents MUST issue the Session-Termination-Request (STR) if the Authorization Lifetime has expired and no subsequent MIP registration request has been received.
遵循此规范的外国和本国代理可能期望其各自的Diameter服务器维护其网络中每个移动节点的会话状态信息。为了让Diameter服务器释放分配给特定移动节点的任何资源，该服务器必须接收来自移动代理的会话终止请求（STR）。如果授权生存期已过期且未收到后续MIP注册请求，则移动代理必须发出会话终止请求（STR）。
The AAAH SHOULD only deallocate all resources after the STR is received from the home agent. This ensures that a mobile node that moves from one foreign agent to another (for example, as a result of a handover) does not cause the Home Diameter Server to free all resources for the mobile node. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the session state associated with the home agent (see Figure 10).
AAAH只应在从归属代理收到STR后解除分配所有资源。这确保了从一个外部代理移动到另一个（例如，由于切换）的移动节点不会导致Home Diameter服务器释放移动节点的所有资源。因此，来自外部代理的STR将从外部代理释放会话，但不会释放与归属代理关联的会话状态（参见图10）。
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 10. Session Termination and Session Identifiers
图10。会话终止和会话标识符
When deallocating all of the mobile node's resources, the home Diameter server (and the foreign Diameter server in the case of an HA allocated in foreign network) MUST destroy all session keys that may still be valid.
当解除分配移动节点的所有资源时，home Diameter服务器（以及在外部网络中分配HA的情况下的foreign Diameter服务器）必须销毁所有可能仍然有效的会话密钥。
In the event that the AAAF wishes to terminate a session, its Abort-Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. Similarly, the AAAH SHOULD send its message to the Home Agent.
如果AAAF希望终止会话，其中止会话请求（ASR）[DIAMBASE]消息应发送给FA。同样，AAAH应将其信息发送给本地代理。
This section defines Command-Code [DIAMBASE] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification:
本节定义了所有符合本规范的DIAMER实现必须支持的命令代码[DIAMBASE]值。本规范中定义了以下命令代码：
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.4
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.4
The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field set to 260 and the 'R' bit set in the Command Flags field, is sent by an attendant (i.e., the Foreign Agent), acting as a Diameter client, to an AAAF in order to request the authentication and authorization of a mobile node. The foreign agent (or home agent in the case of a co-located Mobile Node) uses information found in the Registration Request to construct the following AVPs, to be included as part of the AMR:
AA移动节点请求（AMR）由设置为260的命令代码字段和在命令标志字段中设置的“R”位指示，由作为Diameter客户端的助理（即外部代理）发送到AAAF，以便请求移动节点的认证和授权。外部代理（或位于同一位置的移动节点的本地代理）使用注册请求中的信息构建以下AVP，作为AMR的一部分包括：
Home Address (MIP-Mobile-Node-Address AVP) Home Agent Address (MIP-Home-Agent-Address AVP) Mobile Node NAI (User-Name AVP [DIAMBASE]) MN-HA Key Request (MIP-Feature-Vector AVP) MN-FA Key Request (MIP-Feature-Vector AVP) MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) Home Agent NAI (MIP-Home-Agent-Host AVP) Home AAA server NAI (Destination-Host AVP [DIAMBASE]) Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)
家庭地址（MIP移动节点地址AVP）家庭代理地址（MIP家庭代理地址AVP）移动节点NAI（用户名AVP[DIAMBASE]）MN-HA密钥请求（MIP特征向量AVP）MN-FA密钥请求（MIP特征向量AVP）MN-AAA身份验证扩展（MIP MN AAA身份验证AVP）外部代理质询扩展（MIP FA质询AVP）家庭代理NAI（MIP主代理主机AVP）主AAA服务器NAI（目标主机AVP[DIAMBASE]）主代理到外部代理SPI（MIP HA到FA SPI AVP）
If the mobile node's home address is zero, the foreign or home agent MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the home agent address is zero or all ones, the MIP-Home-Agent-Address AVP MUST NOT be present in the AMR.
如果移动节点的主地址为零，则外部代理或主代理不得在AMR中包含MIP移动节点地址AVP。如果归属代理地址为零或全部为一，则AMR中不得存在MIP归属代理地址AVP。
If a home agent is used in a visited network, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in the AMR message to indicate that it is willing to assign a Home Agent in the visited realm.
如果在到访网络中使用归属代理，则AAAF可以在AMR消息中的MIP特征向量AVP中设置外来归属代理可用标志，以指示其愿意在到访领域中分配归属代理。
If the mobile node's home address is all ones, the foreign or home agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.
如果移动节点的主地址为all ones，则外部或主代理必须包括MIP移动节点地址AVP，并设置为all ones。
If the mobile node includes the home agent NAI and the home AAA server NAI [AAANAI], the foreign agent MUST include the MIP-Home-Agent-Host AVP and the Destination-Host AVP in the AMR.
如果移动节点包括归属代理NAI和归属AAA服务器NAI[AAANAI]，则外部代理必须在AMR中包括MIP归属代理主机AVP和目标主机AVP。
Message Format
消息格式
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field set to 260 and the 'R' bit cleared in the Command Flags field, is sent by the AAAH in response to the AA-Mobile-Node-Request message. The User-Name MAY be included in the AMA if it is present in the AMR. The Result-Code AVP MAY contain one of the values defined in section 6, in addition to the values defined in [DIAMBASE].
AA移动节点应答（AMA）由命令代码字段设置为260和命令标志字段中清除的“R”位指示，由AAAH发送以响应AA移动节点请求消息。如果AMR中存在用户名，则可以将其包含在AMA中。结果代码AVP可能包含第6节中定义的值之一，以及[DIAMBASE]中定义的值。
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned to the mobile node, while the MIP-Mobile-Node-Address AVP contains the home address that was assigned. The AMA message MUST contain the MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the AMR and were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA AVPs MUST be present if the session keys were requested in the AMR and the Co-Located-Mobile-Node bit was set in the MIP-Feature-Vector AVP.
结果代码AVP设置为DIAMETER_SUCCESS的AMA消息必须包括MIP Home Agent地址AVP，必须包括MIP Mobile Node地址AVP，并且只有在MIP Feature Vector AVP中未设置位于同一位置的移动节点位时，才包括MIP Reg Reply AVP。MIP归属代理地址AVP包含分配给移动节点的归属代理，而MIP移动节点地址AVP包含分配给移动节点的归属地址。AMA消息必须包含MIP FA至HA MSA和MIP FA至MN MSA（如果AMR中有请求且HAR中存在）。如果在AMR中请求会话密钥，并且在MIP特征向量AVP中设置了同一位置的移动节点位，则MIP MN到HA MSA和MIP HA到MN MSA AVP必须存在。
Message Format
消息格式
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the Command-Code field set to 262 and the 'R' bit set in the Command Flags field, to the Home Agent. If the Home Agent is to be assigned in a foreign network, the HAR is issued by the AAAH and forwarded by the AAAF to the HA if no redirect servers are involved. If any are, the HAR is sent directly to the HA via a security association. If the HAR message does not include a MIP-Mobile-Node-Address AVP, the Registration Request has 0.0.0.0 for the home address, and the HAR is successfully processed, the Home Agent MUST allocate the mobile nodes address. If, on the other hand, the home agent's local AAA server allocates the mobile node's home address, the local AAA server MUST include the assigned address in a MIP-Mobile-Node-Address AVP.
AAA向归属代理发送归属代理MIP请求（HAR），该请求由设置为262的命令代码字段和在命令标志字段中设置的“R”位表示。如果要在外部网络中分配归属代理，则HAR由AAAH发出，如果不涉及重定向服务器，则由AAAF转发给HA。如果有，HAR将通过安全协会直接发送给医管局。如果HAR消息不包括MIP移动节点地址AVP，注册请求的归属地址为0.0.0.0，并且HAR处理成功，则归属代理必须分配移动节点地址。另一方面，如果归属代理的本地AAA服务器分配移动节点的归属地址，则本地AAA服务器必须在MIP移动节点地址AVP中包括分配的地址。
When session keys are requested for use by the mobile node, the AAAH MUST create them and include them in the HAR message. When a FA-HA session key is requested, it will be created and distributed by the AAAH server.
当移动节点请求使用会话密钥时，AAAH必须创建会话密钥并将其包含在HAR消息中。当请求FA-HA会话密钥时，它将由AAAH服务器创建和分发。
Message Format
消息格式
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
In response to a Home-Agent-MIP-Request, the Home Agent sends the Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field set to 262 and the 'R' bit cleared in the Command Flags field, to its local AAA server. The User-Name MAY be included in the HAA if it is present in the HAR. If the home agent allocated a home address for the mobile node, the address MUST be included in the MIP-Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of the values defined in section 6 instead of the values defined in [DIAMBASE].
作为对归属代理MIP请求的响应，归属代理向其本地AAA服务器发送归属代理MIP应答（HAA），由设置为262的命令代码字段和在命令标志字段中清除的“R”位指示。如果HAR中存在用户名，则该用户名可能包含在HAA中。如果归属代理为移动节点分配了归属地址，则该地址必须包含在MIP移动节点地址AVP中。结果代码AVP可能包含第6节中定义的值之一，而不是[DIAMBASE]中定义的值。
Message Format
消息格式
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
This section defines new Result-Code [DIAMBASE] values that MUST be supported by all Diameter implementations that conform to this specification.
本节定义了符合本规范的所有Diameter实现必须支持的新结果代码[DIAMBASE]值。
Errors in the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but that it may be able to satisfy the request in the future.
瞬态故障类别中的错误用于通知对等方在收到请求时无法满足请求，但将来可能能够满足请求。
DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 This error code is used by the home agent when processing of the Registration Request has failed.
DIAMETER_ERROR_MIP_REPLY_FAILURE 4005注册请求处理失败时，归属代理使用此错误代码。
DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 This error code is used to inform the foreign agent that the requested Home Agent cannot be assigned to the mobile node at this time. The foreign agent MUST return a Mobile IPv4 Registration Reply to the mobile node with an appropriate error code.
DIAMETER_ERROR_HA_NOT_AVAILABLE 4006此错误代码用于通知外部代理此时无法将请求的归属代理分配给移动节点。外部代理必须向移动节点返回带有适当错误代码的移动IPv4注册回复。
DIAMETER_ERROR_BAD_KEY 4007 This error code is used by the home agent to indicate to the local Diameter server that the key generated is invalid.
DIAMETER_ERROR_BAD_KEY 4007归属代理使用此错误代码向本地DIAMETER服务器指示生成的密钥无效。
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 This error code is used by a mobility agent to indicate to the home Diameter server that the requested packet filter Rules cannot be supported.
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008移动代理使用此错误代码向家庭DIAMETER服务器指示无法支持请求的数据包筛选器规则。
Errors that fall within the permanent failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.
属于永久故障类别的错误用于通知对等方请求失败，不应再次尝试。
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 This error is used by the AAAF to inform the AAAH that allocation of a home agent in the foreign domain is not permitted at this time.
DIAMETER_ERROR_NO_FOREIGN_HA_服务5024此错误由AAAF用于通知AAAH此时不允许在外域中分配归属代理。
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 This error is used by the AAAF/AAAH to inform the peer that the requested Mobile IPv4 session keys could not be delivered via a security association.
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 AAAF/AAAH使用此错误通知对等方无法通过安全关联传递请求的移动IPv4会话密钥。
The following table describes the Diameter AVPs defined in the Mobile IPv4 application; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted.
下表描述了移动IPv4应用程序中定义的直径AVP；其AVP代码值、类型和可能的标志值；以及AVP是否可以被加密。
Due to space constraints, the short form IPFiltrRule is used to represent IPFilterRule, and DiamIdent is used to represent DiameterIdentity.
由于空间限制，使用缩写形式IPFilterRule表示IPFilterRule，使用双齿表示直径。
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y |
Foreign-AAA
MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N |
Host
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y |
Foreign-AAA
MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N |
Host
The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the mobile node to the foreign agent.
MIP Reg Reg Request AVP（AVP代码320）为OctetString类型，包含移动节点发送给外部代理的移动IPv4注册请求[MOBILEIP]。
The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the home agent to the foreign agent.
MIP Reg Reply AVP（AVP代码321）为OctetString类型，包含由归属代理发送给外部代理的移动IPv4注册回复[MOBILEIP]。
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the mobile node's home IP address.
MIP移动节点地址AVP（AVP代码333）属于Address类型，并且包含移动节点的归属IP地址。
The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and contains the mobile node's home agent IP address.
MIP归属代理地址AVP（AVP代码334）是类型Address并且包含移动节点的归属代理IP地址。
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and is added with flag values set by the foreign agent or by the AAAF owned by the same administrative domain as the foreign agent. The foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR message it sends to the AAAF.
MIP特征向量AVP（AVP代码337）的类型为Unsigned32，并添加有由外部代理设置的标志值或由与外部代理相同的管理域所拥有的AAAF设置的标志值。外部代理应在发送给AAAF的AMR消息中包含MIP特征向量AVP。
Flag values currently defined include the following:
当前定义的标志值包括以下内容：
1 Mobile-Node-Home-Address-Requested 2 Home-Address-Allocatable-Only-in-Home-Realm 4 Home-Agent-Requested 8 Foreign-Home-Agent-Available 16 MN-HA-Key-Request 32 MN-FA-Key-Request 64 FA-HA-Key-Request 128 Home-Agent-In-Foreign-Network 256 Co-Located-Mobile-Node
1个移动节点请求的主地址2个仅在主域中可分配的主地址4个主代理请求的8个外部主代理可用16 MN HA密钥请求32 MN FA密钥请求64 FA HA密钥请求128个外部网络中的主代理256个共址移动节点
The flags are set according to the following rules.
根据以下规则设置标志。
If the mobile node includes a valid home address (i.e., one not equal to 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign agent sets the Mobile-Node-Home-Address-Requested flag in the MIP-Feature-Vector AVP to zero.
如果移动节点在其注册请求中包括有效的家庭地址（即，不等于0.0.0.0或255.255.255.255的家庭地址），则外部代理将MIP特征向量AVP中的移动节点家庭地址请求标志设置为零。
If the mobile node sets the home agent field equal to 255.255.255.255 in its Registration Request, the foreign agent sets both the Home-Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-Realm flag to one in the MIP-Feature-Vector AVP.
如果移动节点在其注册请求中将home agent字段设置为255.255.255.255，则外部代理将home agent Requested标志和home Address Allocated Only in home Realm标志都设置为MIP特征向量AVP中的一个。
If the mobile node sets the home agent field equal to 0.0.0.0 in its Registration Request, the foreign agent sets the Home-Agent-Requested flag to one and zeroes the Home-Address-Allocatable-Only-in-Home-Realm flag in the MIP-Feature-Vector AVP.
如果移动节点在其注册请求中将“归属代理”字段设置为0.0.0.0，则外部代理将“归属代理请求”标志设置为1，并将MIP特征向量AVP中的“仅可在归属领域中分配的归属地址”标志设置为零。
Whenever the foreign agent sets either the Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested flag to one, it MUST set the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set to one if the mobile node includes a "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension, with the subtype set to AAA.
每当外部代理将移动节点归属地址请求标志或归属代理请求标志设置为1时，它必须将MN HA密钥请求标志设置为1。如果移动节点包括“通用MN-HA密钥生成Nonce-Request”[MIPKEYS]扩展，且子类型设置为AAA，则MN-HA密钥请求标志也设置为1。
If the mobile node includes a "Generalized MN-FA Key Generation Nonce Request" [MIPKEYS] extension with the AAA subtype (1) in its Registration Request, the foreign agent sets the MN-FA-Key-Request flag to one in the MIP-Feature-Vector AVP.
如果移动节点在其注册请求中包括具有AAA子类型（1）的“通用MN-FA密钥生成Nonce请求”[MIPKEYS]扩展，则外部代理在MIP特征向量AVP中将MN-FA密钥请求标志设置为1。
If the mobile node requests a home agent in the foreign network either by setting the home address field to all ones, or by specifying a home agent in the foreign network, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit to one.
如果移动节点通过将home address字段设置为all或通过在外部网络中指定归属代理来请求外部网络中的归属代理，并且AAAF授权该请求，则AAAF必须将外部网络中的归属代理比特设置为1。
If the AAAF is willing and able to assign a home agent in the foreign network, the AAAF sets the Foreign-Home-Agent-Available flag to one.
如果AAAF愿意并且能够在外部网络中分配归属代理，则AAAF将外部归属代理可用标志设置为1。
If the Home Agent receives a Registration Request from the mobile node indicating that the MN is acting as a co-located mobile node, the home agent sets the Co-Located-Mobile-Node bit to one.
如果归属代理接收到来自移动节点的注册请求，指示MN正在充当同一位置的移动节点，则归属代理将同一位置的移动节点比特设置为1。
If the foreign agent's local policy allows it to receive AAA session keys and it does not have any existing FA-HA key with the home agent, the foreign agent MAY set the FA-HA-Key-Request flag.
如果外部代理的本地策略允许它接收AAA会话密钥，并且它与归属代理之间没有任何现有的FA-HA密钥，则外部代理可以设置FA-HA密钥请求标志。
The foreign agent MUST NOT set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flag both to one.
外部代理不得将“外部本地代理可用”和“外部网络中的本地代理”标志同时设置为一。
When the AAAF receives the AMR message, it MUST first verify that the sender was an authorized foreign agent. The AAAF then takes any actions indicated by the settings of the MIP-Feature-Vector AVP flags. The AAAF then MAY set additional flags. Only the AAAF may set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags to one. This is done according to local administrative policy. When the AAAF has finished setting additional flags according to its local policy, then the AAAF transmits the AMR with the possibly modified MIP-Feature-Vector AVP to the AAAH.
当AAAF收到AMR消息时，它必须首先验证发送者是否是授权的外国代理。AAAF然后采取MIP特征向量AVP标志设置指示的任何操作。然后，AAAF可以设置附加标志。只有AAAF可以将“外部归属代理可用”和“外部网络中的归属代理”标志设置为一。这是根据当地行政政策进行的。当AAAF根据其本地策略完成设置附加标志时，AAAF将具有可能修改的MIP特征向量AVP的AMR发送到AAAH。
The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains some ancillary data to simplify processing of the authentication data in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the target AAA server. Its value has the following ABNF grammar:
MN AAA Auth AVP（AVP代码322）属于分组类型，并且包含一些辅助数据，以简化目标AAA服务器对移动IPv4注册请求[MOBILEIP，MIPCHAL]中的认证数据的处理。其值具有以下ABNF语法：
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and indicates the MSA by which the targeted AAA server (AAAH) should attempt to validate the Authenticator computed by the mobile node over the Registration Request data.
MIP-MN-AAA-SPI AVP（AVP代码341）的类型为Unsigned32，并指示目标AAA服务器（AAAH）应通过其尝试验证移动节点根据注册请求数据计算的验证器的MSA。
The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type Unsigned32 and contains the length, in bytes, of the Registration Request data (data portion of MIP-Reg-Request AVP) that should be used as input to the algorithm, as indicated by the MN-AAA-SPI AVP, used to determine whether the Authenticator Data supplied by the mobile node is valid.
MIP Auth输入数据长度AVP（AVP代码338）的类型为Unsigned32，并且包含注册请求数据（MIP Reg Request AVP的数据部分）的长度（以字节为单位），如MN-AAA-SPI AVP所示，该数据应被用作算法的输入，用于确定由移动节点提供的认证器数据是否有效。
The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 and contains the length of the authenticator to be validated by the targeted AAA server (i.e., AAAH).
MIP验证器长度AVP（AVP代码339）的类型为Unsigned32，并且包含要由目标AAA服务器（即AAAH）验证的验证器的长度。
The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 and contains the offset into the Registration Request Data, of the authenticator to be validated by the targeted AAA server (i.e., AAAH).
MIP验证器偏移量AVP（AVP代码340）的类型为Unsigned32，并且将偏移量包含在要由目标AAA服务器（即AAAH）验证的验证器的注册请求数据中。
The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and contains the challenge advertised by the foreign agent to the mobile node. This AVP MUST be present in the AMR if the mobile node used the RADIUS-style MN-AAA computation algorithm [MIPCHAL].
MIP FA质询AVP（AVP代码344）是OctetString类型，并且包含由外部代理向移动节点通告的质询。如果移动节点使用RADIUS样式的MN-AAA计算算法[MIPCHAL]，则此AVP必须存在于AMR中。
The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and provides filter rules that have to be configured on the foreign or home agent for the user. The packet filtering rules are set by the AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if destined for the home agent and/or in the AMA if destined for the foreign agent.
MIP筛选规则AVP（AVP代码342）属于IPFilterRule类型，并提供必须在外部或本地代理上为用户配置的筛选规则。AAAH通过在HAR（如果目的地是归属代理）和/或AMA（如果目的地是外部代理）中添加一个或多个MIP过滤规则avp来设置分组过滤规则。
The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type DiameterIdentity and contains the identity of a home agent in the foreign network that the AAAF proposes to be dynamically assigned to the mobile node.
MIP候选归属代理主机AVP（AVP代码336）是diameteridenty类型，并且包含AAAF提议动态分配给移动节点的外部网络中的归属代理的身份。
The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is of type Grouped and contains the identity of the AAAF, which issues the AMR to the AAAH. The MIP-Originating-Foreign-AAA AVP MUST only be used in cases when the home agent is or may be allocated in a foreign domain. If the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH MUST copy it into the HAR.
源自外部AAA AVP（AVP代码347）的MIP属于分组类型，包含AAAF的标识，该标识向AAAH发出AMR。起源于外部AAA AVP的MIP必须仅在归属代理被或可能被分配到外部域的情况下使用。如果AMR中存在源自外部AAA AVP的MIP，AAAH必须将其复制到HAR中。
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped and contains the identity of the assigned Home Agent. If the MIP-Home-Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP归属代理主机AVP（AVP代码348）属于分组类型，并且包含分配的归属代理的标识。如果AMR中存在MIP Home Agent主机AVP，AAAH必须将其复制到HAR中。
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
The mobile node and mobility agents use session keys (i.e., the MN-FA, FA-HA, and MN-HA session keys) to compute authentication extensions applied to MIP registration messages, as defined in [MOBILEIP]. If session keys are requested, the AAAH MUST return the keys and nonces after the mobile node is successfully authenticated and authorized.
移动节点和移动代理使用会话密钥（即MN-FA、FA-HA和MN-HA会话密钥）来计算应用于MIP注册消息的认证扩展，如[MOBILEIP]中所定义。如果请求会话密钥，AAAH必须在移动节点成功地进行身份验证和授权后返回密钥和nonce。
The SPI values are used as key identifiers, and each session key has its own SPI value; nodes that share a key can have multiple different SPIs all referring to the same key. In all cases, the entity that receives an authentication extension (i.e., that verifies the authentication extension) is providing the entity that sends the authentication extension (i.e., that computes the authentication extension) the value of the SPI to use for that computation. Note that the keys in this model are symmetric in that they are used in both directions, even though the SPIs do not have to be symmetric.
SPI值用作密钥标识符，并且每个会话密钥具有其自己的SPI值；共享一个密钥的节点可以有多个不同的SPI，所有SPI都引用同一个密钥。在所有情况下，接收认证扩展的实体（即，验证认证扩展的实体）向发送认证扩展的实体（即，计算认证扩展的实体）提供用于该计算的SPI值。请注意，此模型中的密钥是对称的，因为它们在两个方向上使用，即使SPI不必是对称的。
The mobile node allocates SPIs for use in the FA-MN and HA-MN mobility security associations, via the Mobile IPv4 AAA Key Request extensions [MIPKEYS]. The home agent allocates SPIs for the MN-HA and FA-HA mobility security association. The foreign agent chooses SPIs for the MN-FA and HA-FA mobility security associations.
移动节点通过移动IPv4 AAA密钥请求扩展[MIPKEYS]分配SPI以用于FA-MN和HA-MN移动安全关联。归属代理为MN-HA和FA-HA移动安全关联分配SPI。外国代理为MN-FA和HA-FA移动安全协会选择SPI。
Once the session keys and nonces have been distributed, subsequent Mobile IPv4 registrations need not invoke the AAA infrastructure until the keys expire. As mandated by Mobile IPv4, these registrations MUST include the MN-HA authentication extension. Likewise, subsequent registrations MUST also include MN-FA authentication extension if the MN-FA session key was generated and distributed by AAA. The same hold true for subsequent use of the FA-HA authentication extensions.
一旦分发了会话密钥和nonce，后续的移动IPv4注册就不需要调用AAA基础设施，直到密钥过期。根据移动IPv4的要求，这些注册必须包括MN-HA身份验证扩展。同样，如果MN-FA会话密钥由AAA生成和分发，则后续注册还必须包括MN-FA身份验证扩展。后续使用FA-HA身份验证扩展时也是如此。
The Diameter Mobile IPv4 application makes use of two timers: the Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.
Diameter移动IPv4应用程序使用两个计时器：授权生存期AVP[DIAMBASE]和MIP MSA生存期AVP。
The Authorization-Lifetime contains the number of seconds before the mobile node must issue a subsequent MIP registration request. The content of the Authorization-Lifetime AVP corresponds to the Lifetime field in the MIP header [MOBILEIP].
授权生存期包含移动节点必须发出后续MIP注册请求之前的秒数。授权生存期AVP的内容对应于MIP头[MOBILEIP]中的生存期字段。
The MIP-MSA-Lifetime AVP contains the number of seconds before session keys destined for the mobility agents and the mobile node expire. A value of zero indicates infinity (no timeout). If not
MIP MSA Lifetime AVP包含发送给移动代理和移动节点的会话密钥到期前的秒数。值为零表示无限大（无超时）。如果不是
zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP.
零，MIP MSA生存期AVP的值必须至少等于授权生存期AVP中的值。
As described in section 3.4, the AAAH generates session keys and transmits them to the home agent and foreign agent. The AAAH generates nonces that correspond to the same keys and transmits them to the mobile node. When it is necessary to protect the session keys and SPIs from un-trusted Diameter agents, end-to-end security mechanisms such as TLS or IPSec are required to eliminate all Diameter Agents between the FA or HA and the AAAH, as outlined above.
如第3.4节所述，AAAH生成会话密钥并将其传输给本地代理和外部代理。AAAH生成对应于相同密钥的nonce，并将其发送到移动节点。当需要保护会话密钥和SPI免受不受信任的Diameter代理的攻击时，需要端到端安全机制（如TLS或IPSec）来消除FA或HA与AAAH之间的所有Diameter代理，如上所述。
In [MIPKEYS], the mobility security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH must generate a random [RANDOM] value of at least 128 bits [MIPKEYS]. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys.
在[MIPKEYS]中，移动安全关联是通过通过移动IPv4传输到移动节点的nonce建立的。为了提供nonce，AAAH必须生成至少128位[MIPKEYS]的随机[random]值。然后，移动节点使用nonce导出MN-HA和MN-FA会话密钥。
More details of the MN-HA and the MN-FA session key creation procedures are found in [MIPKEYS].
有关MN-HA和MN-FA会话密钥创建过程的更多详细信息，请参见[MIPKEYS]。
The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce.
移动节点用于构造会话密钥的哈希算法必须与AAAH在会话密钥生成过程中使用的哈希算法相同。因此，AAAH指示与nonce一起使用的算法。
The FA-HA and HA-FA session key is shared between the FA and HA. The AAAH generates a random [RANDOM] value of at least 128 bits for use as this session key.
FA-HA和HA-FA会话密钥在FA和HA之间共享。AAAH生成至少128位的随机[随机]值，用作此会话密钥。
See sections 9 for details about the format of the AVPs used to transport the session keys.
有关用于传输会话密钥的AVP格式的详细信息，请参见第9节。
If the mobile node does not have an MN-HA session key, then the AAAH is likely to be the only trusted entity that is available to the mobile node. Thus, the AAAH has to generate the MN-HA session key.
如果移动节点没有MN-HA会话密钥，则AAAH可能是移动节点可用的唯一受信任实体。因此，AAAH必须生成MN-HA会话密钥。
The distribution of the HA-MN (session) key to the HA is specified in sections 1.2 and 3.4. The HA and AAAH establish a security association (IPSec or TLS) and transport the key over it. If no security association exists between the AAAH and the home agent and a security association cannot be established, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
第1.2节和第3.4节规定了向HA分配HA-MN（会话）密钥。HA和AAAH建立安全关联（IPSec或TLS）并通过它传输密钥。如果AAAH和归属代理之间不存在安全关联，并且无法建立安全关联，则AAAH必须返回一个结果代码AVP，其中包含DIAMETER\u ERROR\u END\u TO\u END\u MIP\u KEY\u加密。
The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAAH only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IPv4 messages and extensions [MOBILEIP]. For this purpose, AAAH includes the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added to the HAR (for FA COA style Mobile IPv4) or to the AMA (for collocated COA-style Mobile IPv4 messages) and delivered either to a local home agent or a home agent in the visited network. Note that the mobile node will use the nonce to create the MN-HA session key by using the MN-AAA key it shares with the AAAH [MIPKEYS]. The AAAH has to rely on the home agent (which also understands Diameter) to transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply message. The HA includes the SPIs proposed by the mobile node and the home agent in the "Generalized MN-HA Key Generation Nonce Request" extension. The home agent can format the Reply message and extensions correctly for eventual delivery to the mobile node. The resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP.
AAAH还必须安排将密钥交付给移动节点。不幸的是，AAAH只知道Diameter消息和AVP，而移动节点只知道移动IPv4消息和扩展[MOBILEIP]。为此，AAAH将MN-HA MIP nonce AVP包括到MIP MN到HA MSA AVP中，该AVP被添加到HAR（对于FA-COA样式的移动IPv4）或AMA（对于并置的COA样式的移动IPv4消息）中，并被传送到到访网络中的本地归属代理或归属代理。注意，移动节点将使用nonce通过使用它与AAAH[MIPKEYS]共享的MN-AAA密钥来创建MN-HA会话密钥。AAAH必须依靠归属代理（它也理解Diameter）将nonce传输到注册应答消息中的移动IPv4“通用MN-HA密钥生成nonce应答”扩展[MIPKEYS]。HA在“广义MN-HA密钥生成Nonce请求”扩展中包括移动节点和归属代理提出的SPI。归属代理可以正确设置回复消息和扩展的格式，以便最终传送到移动节点。生成的注册回复被添加到HAA的MIP Reg Reply AVP中。
The AAAH parses the HAA message, transforms it into an AMA message containing an MIP-Reg-Reply AVP, and sends the AMA message to the foreign agent. The foreign agent then uses that AVP to recreate a Registration Reply message containing the "Generalized MN-HA Key Generation Nonce Reply" extension for delivery to the mobile node.
AAAH解析HAA消息，将其转换为包含MIP Reg Reply AVP的AMA消息，并将AMA消息发送给外部代理。然后，外部代理使用该AVP来重新创建包含“广义MN-HA密钥生成Nonce Reply”扩展的注册应答消息，以便将其传递到移动节点。
In summary, the AAAH generates the MN-HA nonce, which is added to the MIP-MN-to-HA-MSA AVP, and a session key, which is added to the MIP-HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in HAR or AMA messages. The home agent retains the session key for its own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a "Generalized MN-HA Key Generation Nonce Reply" extension, which is appended to the Mobile IPv4 Registration Reply message. This Registration Reply message MUST also include the HA-MN authentication extension, which is created by using the newly allocated HA-MN session key. The home agent then includes the Registration Reply message and extensions into a MIP-Reg-Reply AVP as part of the HAA message to be sent back to the AAA server.
总之，AAAH生成MN-HA nonce（添加到MIP MN-to-HA MSA AVP）和会话密钥（添加到MIP HA-to-MN MSA AVP）。这些AVP以HAR或AMA消息的形式发送给home agent。归属代理保留会话密钥以供自己使用，并将nonce从MIP MN复制到HA MSA AVP，复制到“广义MN-HA密钥生成nonce Reply”扩展中，该扩展被附加到移动IPv4注册应答消息中。此注册回复消息还必须包括HA-MN身份验证扩展，该扩展是使用新分配的HA-MN会话密钥创建的。然后，归属代理将注册回复消息和扩展包含到MIP Reg Reply AVP中，作为要发送回AAA服务器的HAA消息的一部分。
The key derived by the MN from the MN-HA session nonce is identical to the HA-MN session key provided to the HA.
MN从MN-HA会话nonce派生的密钥与提供给HA的HA-MN会话密钥相同。
The MN-FA session nonce is also generated by AAAH (upon request) and added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and copied by the home agent into a "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration Reply message. The HA also includes the SPIs proposed by the mobile
MN-FA会话nonce也由AAAH（根据请求）生成，并添加到MIP MN to FA MSA AVP中，该AVP被添加到HAR中，并由归属代理复制到移动IPv4注册回复消息的“通用MN-FA密钥生成nonce Reply”扩展[MIPKEYS]中。医管局亦包括流动电话公司所建议的SPI
node and foreign agent in the "Generalized MN-FA Key Generation Nonce Request" extension. The AAAH includes the FA-MN session key in the MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in the computation of the FA-MN authentication extension.
“广义MN-FA密钥生成Nonce请求”扩展中的节点和外部代理。AAAH在AMA中的MIP FA-to-MN MSA AVP中包括FA-MN会话密钥，由外部代理在计算FA-MN认证扩展时使用。
The key derived by the MN from the MN-FA session nonce is identical to the FA-MN session key provided to the FA.
MN从MN-FA会话nonce派生的密钥与提供给FA的FA-MN会话密钥相同。
If the foreign agent requests an FA-HA session key, it also includes a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the home agent for this purpose. The AAAH generates the FA-HA session key, which is identical to the HA-FA session key, and distributes that to both the HA and the FA over respective security associations by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA conveys the SPI that the FA MUST use in the HAA; this is similar to the way in which the FA conveys that the SPI that the HA MUST use in the AMR. The AAAH later includes these SPIs in the MIP-FA-HA-MSA and MIP-HA-FA-MSA AVPs, respectively, along with the session key.
如果外部代理请求FA-HA会话密钥，它还包括AMR中的MIP HA到FA SPI AVP，以传送归属代理为此目的使用的SPI。AAAH生成与HA-FA会话密钥相同的FA-HA会话密钥，并通过使用MIP HA到FA MSA和MIP FA到HA MSA AVP通过各自的安全关联将其分发给HA和FA。HA传达FA必须在HAA中使用的SPI；这类似于FA传达医管局必须在AMR中使用SPI的方式。AAAH随后将这些SPI与会话密钥一起分别包含在MIP-FA-HA-MSA和MIP-HA-FA-MSA AVP中。
Refer to Figures 2, 3, 4, and 6 for the messages involved.
请参阅图2、3、4和6以了解所涉及的消息。
Note that if multiple MNs are registered on the same FA and HA pair, then multiple mobility security associations would be distributed. However, only one is required to protect the Mobile IP control traffic between FA and HA. This creates an unacceptable level of state (i.e., to store the two SPIs and shared key for each FA-HA mobility security association). To improve scalability, the FA and HA may discard FA-HA mobility security associations prior to the time when they actually expire. However, if a proper discard policy is not chosen, this could cause Mobile IP messages in transit or waiting in queues for transmission to fail authentication.
请注意，如果在同一FA和HA对上注册了多个MN，则将分布多个移动安全关联。但是，只需要一个来保护FA和HA之间的移动IP控制流量。这会创建一个不可接受的状态级别（即，为每个FA-HA移动安全关联存储两个SPI和共享密钥）。为了提高可伸缩性，FA和HA可以在FA-HA移动安全关联实际过期之前丢弃它们。但是，如果未选择适当的丢弃策略，这可能会导致传输中的移动IP消息或在队列中等待传输的移动IP消息无法通过身份验证。
The FA MUST always use the FA-HA security association with the latest expiry time when computing authentication extensions on outgoing messages. The FA MAY discard HA-FA mobility security associations 10 seconds after a new HA-FA mobility security association arrives with a later expiry time.
在对传出消息计算身份验证扩展时，FA必须始终使用具有最新到期时间的FA-HA安全关联。在新的HA-FA移动安全关联到达10秒后，FA可以丢弃HA-FA移动安全关联，过期时间较晚。
The HA SHOULD use the HA-FA mobility security association that has the latest expiry time when computing authentication extensions in outgoing messages. However, when the HA receives a new HA-FA mobility security association with a later expiry time, the HA SHOULD wait 4 seconds for the AMA to propagate to the FA before using the new association. Note that the HA always uses the mobility security association from the HAR when constructing the Mobile IP Registration Reply in the corresponding HAA. The HA MAY discard an FA-HA mobility
在计算传出消息中的身份验证扩展时，HA应使用具有最新到期时间的HA-FA移动安全关联。然而，当HA接收到一个新的HA-FA移动安全关联且过期时间较晚时，HA应等待4秒，以便AMA在使用新关联之前传播到FA。注意，当在相应的HAA中构造移动IP注册应答时，HA总是使用来自HAR的移动安全关联。医管局可能会放弃FA-HA机动系统
security association once it receives a message authenticated by a FA-HA mobility security association with a later expiry time.
一旦安全关联接收到由FA-HA移动安全关联验证的消息，且到期时间较晚，则安全关联。
The Mobile-IP protocol defines a set of mobility security associations shared between the mobile node, foreign agent, and home agent. These three mobility security associations (MN-HA, MN-FA, and FA-HA) are dynamically created by the AAAH and have previously been described in sections 3.4 and 8. AAA servers supporting the Diameter Mobile IP Application MUST implement the key distribution AVPs defined in this document.
移动IP协议定义了移动节点、外部代理和归属代理之间共享的一组移动安全关联。这三个移动安全关联（MN-HA、MN-FA和FA-HA）由AAAH动态创建，之前已在第3.4节和第8节中描述。支持Diameter Mobile IP应用程序的AAA服务器必须实现本文档中定义的密钥分发AVP。
The names of the key distribution AVPs indicate the two entities sharing the mobility security association. The first named entity in the AVP name will use the mobility security association to create authentication extensions using the given SPI and key. The second named entity in the AVP name will use the mobility security association to verify the authentication extensions of received Mobile IP messages.
密钥分发avp的名称表示共享移动安全关联的两个实体。AVP名称中的第一个命名实体将使用移动安全关联创建使用给定SPI和密钥的身份验证扩展。AVP名称中的第二个命名实体将使用移动安全关联来验证接收到的移动IP消息的身份验证扩展。
For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce, which the mobile node will use to derive the MN-HA Key, and the MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note that mobility security associations are unidirectional; however, this application delivers only one key that is shared between both unidirectional security associations that exist between two peers. The security considerations of using the same key in each direction are given in section 13. The SPIs are, however, unique to each unidirectional security association and are chosen by the peer that will receive the Mobile IP messages authenticated with that security association.
例如，MIP MN-to-HA MSA AVP包含移动节点将用于派生MN-HA密钥的MN-HA nonce，MIP HA-to-MN MSA AVP包含归属代理的MN-HA密钥。注意，移动安全关联是单向的；但是，此应用程序只提供一个密钥，该密钥在两个对等方之间存在的两个单向安全关联之间共享。第13节给出了在每个方向使用相同密钥的安全注意事项。然而，SPI对于每个单向安全关联是唯一的，并且由将接收通过该安全关联认证的移动IP消息的对等方选择。
The following table describes the Diameter AVPs defined in the Mobile IP application and their AVP Code values, types, and possible flag values.
下表描述了移动IP应用程序中定义的直径AVP及其AVP代码值、类型和可能的标志值。
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and contains the FA-MN session key. This AVP is conveyed to the FA in an AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates an FA-MN authentication extension by using the session key and algorithm, and the MN verifies that extension by using the same session key and algorithm. The data field of this AVP has the following ABNF grammar:
MIP FA至MN MSA AVP（AVP代码326）属于分组类型，包含FA-MN会话密钥。此AVP通过AMA消息传送给FA。MN将MIP FA分配给MN SPI。FA使用会话密钥和算法创建FA-MN身份验证扩展，MN使用相同的会话密钥和算法验证该扩展。此AVP的数据字段具有以下ABNF语法：
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and contains the FA-HA session key. This AVP is conveyed to the FA in an AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates the FA-HA authentication extension by using the session key and algorithm, and the HA verifies that extension by using the same key and algorithm. The AVP's data field has the following ABNF grammar:
MIP FA到HA MSA AVP（AVP代码328）属于分组类型，包含FA-HA会话密钥。此AVP通过AMA消息传送给FA。HA将MIP FA分配给HA SPI。FA使用会话密钥和算法创建FA-HA身份验证扩展，HA使用相同的密钥和算法验证该扩展。AVP的数据字段具有以下ABNF语法：
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and contains the Home Agent's session key, which it shares with the foreign agent. This AVP is conveyed to the HA in an HAR message. The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA authentication extension by using the session key and algorithm, and the FA verifies that extension by using the same session key and algorithm. The AVP's data field has the following ABNF grammar:
MIP HA to FA MSA AVP（AVP代码329）属于分组类型，包含归属代理的会话密钥，它与外部代理共享该密钥。该AVP通过HAR消息传达给HA。FA将MIP HA分配给FA SPI。HA使用会话密钥和算法创建HA-FA身份验证扩展，FA使用相同的会话密钥和算法验证该扩展。AVP的数据字段具有以下ABNF语法：
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and contains the HA-MN session key. This AVP is conveyed to the HA in an HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the HA-MN authentication extension by using the session key and algorithm, and the MN verifies that extension by using the same key and algorithm. The AVP's field has the following ABNF grammar:
MIP HA到MN MSA AVP（AVP代码332）属于分组类型，包含HA-MN会话密钥。该AVP在HAR（用于FA COA移动IPv4）和AMA（用于并置COA移动IPv4）中传送给HA。MN将MIP HA分配给MN SPI。HA使用会话密钥和算法创建HA-MN身份验证扩展，MN使用相同的密钥和算法验证该扩展。AVP字段具有以下ABNF语法：
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and contains the MN-FA session nonce, which the mobile node uses to derive the MN-FA session key. This AVP is conveyed to the HA in an HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates the MN-FA authentication extension by using the session key and algorithm, and the FA verifies that extension using the same key and algorithm.
MIP MN-to-FA MSA AVP（AVP代码325）是分组的类型，并且包含移动节点用于导出MN-FA会话密钥的MN-FA会话nonce。该AVP通过HAR消息传达给HA。FA将MIP MN分配给FA SPI。MN使用会话密钥和算法创建MN-FA身份验证扩展，FA使用相同的密钥和算法验证该扩展。
The home agent uses this AVP in the construction of the Mobile IP "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
归属代理在移动IP“广义MN-FA密钥生成非应答”扩展[MIPKEYS]的构造中使用该AVP。
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and contains the MN-HA session nonce, which the mobile node uses to derive the MN-HA session key. This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension using the session key and algorithm, and the HA verifies that extension using the same session key and algorithm.
MIP MN-to-HA MSA AVP（AVP代码331）属于分组类型，并且包含MN-HA会话nonce，移动节点使用该会话nonce来派生MN-HA会话密钥。对于FA COA移动IPv4，该AVP在HAR消息中传输给HA，对于并置移动IPv4，该AVP在AMR中传输给HA。HA将MIP MN分配给HA SPI。MN使用会话密钥和算法创建MN-FA身份验证扩展，HA使用相同的会话密钥和算法验证该扩展。
The Home Agent uses this AVP in the construction of the Mobile IP "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].
归属代理在移动IP“广义MN-HA密钥生成非应答”扩展[MIPKEYS]的构造中使用该AVP。
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the Session Key for the associated Mobile IPv4 authentication extension. The HAAA selects the session key.
MIP会话密钥AVP（AVP代码343）为OctetString类型，包含相关移动IPv4身份验证扩展的会话密钥。HAAA选择会话密钥。
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and contains the Algorithm identifier for the associated Mobile IPv4 authentication extension. The HAAA selects the algorithm type. The following values are currently defined:
MIP算法类型AVP（AVP代码345）属于枚举类型，并且包含相关联的移动IPv4认证扩展的算法标识符。HAAA选择算法类型。当前定义了以下值：
2 HMAC-SHA-1 [HMAC]
2 HMAC-SHA-1[HMAC]
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent for authenticating the mobile node. The HAAA selects the replay mode.
MIP重播模式AVP（AVP代码346）是枚举的类型，并且包含归属代理用于认证移动节点的重播模式。HAAA选择重播模式。
The following values are supported (see [MOBILEIP] for more information):
支持以下值（有关更多信息，请参阅[MOBILEIP]：
1 None 2 Timestamps 3 Nonces
1无2时间戳3无
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it contains the Security Parameter Index the FA that and MN use to refer to the FA-MN mobility security association. The MN allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP FA to MN SPI AVP（AVP代码319）的类型为Unsigned32，它包含FA和MN用于引用FA-MN移动安全关联的安全参数索引。MN分配SPI，其值不得介于零（0）和255之间，这是[MOBILEIP]中定义的保留命名空间。
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and contains the Security Parameter Index the FA and HA use to refer to the FA-HA mobility security association. The HA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP FA到HA SPI AVP（AVP代码318）的类型为Unsigned32，包含FA和HA用于引用FA-HA移动安全关联的安全参数索引。HA分配SPI，其值不得介于零（0）和255之间，这是[MOBILEIP]中定义的保留命名空间。
The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains the nonce sent to the mobile node for the associated authentication extension. The mobile node follows the procedures in [MIPKEYS] to generate the session key used to authenticate Mobile IPv4 registration messages. The HAAA selects the nonce.
MIP Nonce AVP（AVP代码335）是OctetString类型，并且包含发送到移动节点用于相关认证扩展的Nonce。移动节点按照[MIPKEYS]中的过程生成用于验证移动IPv4注册消息的会话密钥。HAAA选择nonce。
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and represents the period of time (in seconds) for which the session key or nonce is valid. The associated session key or nonce, as the case may be, MUST NOT be used if the lifetime has expired; if the session key or nonce lifetime expires while the session to which it applies is still active, either the session key or nonce MUST be changed or the association Mobile IPv4 session MUST be terminated.
MIP MSA生存期AVP（AVP代码367）的类型为Unsigned32，表示会话密钥或nonce有效的时间段（以秒为单位）。如果生存期已过期，则不得使用相关会话密钥或nonce（视情况而定）；如果会话密钥或nonce生存期在其应用的会话仍处于活动状态时过期，则必须更改会话密钥或nonce，或者必须终止关联移动IPv4会话。
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and contains the Security Parameter Index the HA and FA use to refer to the HA-FA mobility security association. The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP HA到FA SPI AVP（AVP代码323）的类型为Unsigned32，包含HA和FA用于引用HA-FA移动安全关联的安全参数索引。FA分配SPI，其值不得介于零（0）和255之间，这是[MOBILEIP]中定义的保留命名空间。
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
记帐输入八位字节AVP（AVP代码363）的类型为Unsigned64，并且包含从用户接收的IP分组中的八位字节数。此AVP必须包含在所有记帐请求消息中，并且也可能出现在相应的记帐应答消息中。
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64 and contains the number of octets in IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
记帐输出八位字节AVP（AVP代码364）的类型为Unsigned64，包含发送给用户的IP数据包中的八位字节数。此AVP必须包含在所有记帐请求消息中，并且也可能出现在相应的记帐应答消息中。
The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates the length of the current session in seconds. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Acct Time AVP（AVP代码46）的类型为Unsigned32，以秒为单位指示当前会话的长度。此AVP必须包含在所有记帐请求消息中，并且也可能出现在相应的记帐应答消息中。
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and contains the number of IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
记帐输入数据包（AVP代码365）的类型为Unsigned64，包含从用户接收的IP数据包的数量。此AVP必须包含在所有记帐请求消息中，并且也可能出现在相应的记帐应答消息中。
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64 and contains the number of IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
记帐输出数据包（AVP代码366）的类型为Unsigned64，包含发送给用户的IP数据包的数量。此AVP必须包含在所有记帐请求消息中，并且也可能出现在相应的记帐应答消息中。
The Event-Timestamp (AVP Code 55) is of type Time and MAY be included in an Accounting-Request message to record the time at which this event occurred on the mobility agent, in seconds since January 1, 1970, 00:00 UTC.
事件时间戳（AVP代码55）属于时间类型，可以包括在记帐请求消息中，以记录自1970年1月1日00:00 UTC以来移动代理上发生此事件的时间（以秒为单位）。
The following tables present the AVPs defined in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
下表显示了本文档中定义的AVP及其在Diameter消息中的出现情况。请注意，此表中未显示只能出现在分组AVP中的AVP。
The table uses the following symbols:
该表使用以下符号：
0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message. 0 - 1 Zero or one instance of the AVP MAY be present in the message. 1 One instance of the AVP MUST be present in the message.
0消息中不得出现AVP。消息中可能存在0+零个或多个AVP实例。0-1消息中可能存在零个或一个AVP实例。1消息中必须有一个AVP实例。
The table in this section is limited to the Command Codes defined in this specification.
本节中的表格仅限于本规范中定义的命令代码。
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 |
MIP-FA-Challenge | 0-1 | 0 | 0 | 0 |
MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 |
MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 |
MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 |
MIP-FA-Challenge | 0-1 | 0 | 0 | 0 |
MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 |
MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 |
MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 | MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 | MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP MN到FA MSA | 0 | 0-1 | 0 | MIP MN到HA MSA | 0 | 0-1 | 0 | MIP FA到HA SPI | 0 | 0 | 0-1 | MIP HA到FA SPI 0 | 0 | 0-1|
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-FA至MN SPI | 0 | 0 | 0-1 | MIP-MN至FA-SPI | 0 | 0 | 0-1|
MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|
MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, as defined in [DIAMBASE].
本节中的表格用于表示本文档中定义的哪些AVP将出现在[DIAMBASE]中定义的记帐消息中。
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Acct-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
Event-Timestamp | 0-1 | 0 |
-------------------------------------|------+------+
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Acct-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
Event-Timestamp | 0-1 | 0 |
-------------------------------------|------+------+
This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.
本节包含在本规范中创建的名称空间，或将其值分配给IANA管理的现有名称空间。
This specification assigns the values 260 and 262 from the Command Code namespace defined in [DIAMBASE]. See section 5 for the assignment of the namespace in this specification.
本规范从[DIAMBASE]中定义的命令代码命名空间中指定值260和262。有关本规范中名称空间的分配，请参见第5节。
This specification assigns the values 318 - 348 and 363 - 367 from the AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 10 for the assignment of the namespace in this specification.
本规范从[DIAMBASE]中定义的AVP代码命名空间中分配值318-348和363-367。有关本规范中名称空间的分配，请参见第7、9和10节。
This specification assigns the values 4005 - 4008 and 5024 - 5025 from the Result-Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. See section 6 for the assignment of the namespace in this specification.
本规范从[DIAMBASE]中定义的结果代码AVP（AVP代码268）值命名空间中分配值4005-4008和5024-5025。有关本规范中名称空间的分配，请参见第6节。
There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that are available for assignment. This document assigns bits 1 - 9, as listed in section 7.5. The remaining bits should only be assigned via Standards Action [IANA].
MIP特征向量AVP（AVP代码337）中有32位可用于分配。本文件分配第1-9位，如第7.5节所列。剩余的位只能通过标准行动[IANA]分配。
As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) defines the value 2. All remaining values, except zero, are available for assignment via Designated Expert [IANA].
如第9.8节所定义，MIP算法类型AVP（AVP代码345）定义值2。所有剩余值（零除外）可通过指定专家[IANA]分配。
As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) defines the values 1 - 3. All remaining values, except zero, are available for assignment via Designated Expert [IANA].
如第9.9节所述，MIP回放模式AVP（AVP代码346）定义了值1-3。所有剩余值（零除外）可通过指定专家[IANA]分配。
This specification uses the value two (2) to the Application Identifier namespace defined in [DIAMBASE]. See section 4 for more information.
本规范对[DIAMBASE]中定义的应用程序标识符命名空间使用值2。更多信息请参见第4节。
This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent on the transforms used within the Mobile IPv4 protocol, and [MIPCHAL]. This specification, in conjunction with [MIPKEYS], also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IPv4 registration messages [MOBILEIP]. The key distribution is asymmetric, as communication with the mobile node occurs via the Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. Where untrusted Diameter agents are present, end-to-end security MUST be used. The end-to-end security takes the form of TLS or IPSec security associations between the AAAH and the FA and between the AAAH and the HA. These connections will be authenticated with the use of public keys and certificates; however, the identities that appear in the certificates must be authorized and bound to a particular Mobile IPv4 Diameter session before the AAAH can safely begin distribution of keys.
本规范描述了用于验证和授权移动IPv4移动节点的移动IPv4 Diameter应用程序。使用的身份验证算法取决于移动IPv4协议中使用的转换，以及[MIPCHAL]。本规范与[MIPKEYS]一起还定义了一种方法，home Diameter服务器可通过该方法创建和分发会话密钥和nonce，以用于验证和完整性保护移动IPv4注册消息[MOBILEIP]。密钥分配是不对称的，因为与移动节点的通信通过移动IPv4协议[MIPKEYS，MOBILEIP]进行，其中与归属代理和外部代理的通信通过Diameter协议进行。如果存在不受信任的Diameter代理，则必须使用端到端安全性。端到端安全采用AAAH和FA之间以及AAAH和HA之间TLS或IPSec安全关联的形式。这些连接将使用公钥和证书进行身份验证；但是，证书中显示的身份必须经过授权并绑定到特定的移动IPv4 Diameter会话，AAAH才能安全地开始分发密钥。
Note that the direct connections are established as a result of Diameter redirect messages. For example, in Figure 3, the FA gets a redirect response containing the Redirect-Host AVP of the AAAH. This is the identity that should be matched against the certificate presented by the AAAH when the secure connection is established. In this case, the network of Diameter proxies and redirect agents is trusted with the task of returning the correct AAAH identity to the FA.
请注意，直接连接是通过Diameter重定向消息建立的。例如，在图3中，FA获得一个重定向响应，其中包含AAAH的重定向主机AVP。这是在建立安全连接时应与AAAH提供的证书相匹配的标识。在这种情况下，Diameter代理和重定向代理网络被信任，其任务是向FA返回正确的AAAH标识。
The AAAH must also make an authorization decision when the FA establishes the connection. If the AAAH and the redirect server are one and the same, then the AAAH may have observed and noted the original AMR message that contained the identity of the FA and so may authorize the establishment of a TLS or IPSec connection from the same entity. Otherwise, the AAAH would need to maintain a list of all authorized visited domains (roaming partners) and authorize TLS or IPSec connections based on this list. Note that establishment of the connection is only the first step, and the AAAH has another opportunity to deny service upon receipt of the AMR message itself. At this step, the AAAH can check the internal AVPs of the AMR to ensure that the FA is valid; for example, it can check that the Mobile IP COA is equal to the IP address used as the endpoint of the TLS or IPSec connection. However, such a policy would prevent the FA from using different interfaces for AAA and Mobile IP tunnel packets and may not be desirable in every deployment situation.
当FA建立连接时，AAAH还必须做出授权决定。如果AAAH和重定向服务器是同一个，那么AAAH可能已经观察并记录了包含FA的标识的原始AMR消息，因此可以授权从同一实体建立TLS或IPSec连接。否则，AAAH将需要维护所有授权访问域（漫游伙伴）的列表，并根据该列表授权TLS或IPSec连接。请注意，建立连接只是第一步，AAAH在收到AMR消息本身时还有另一个拒绝服务的机会。在此步骤中，AAAH可以检查AMR的内部AVP，以确保FA有效；例如，它可以检查移动IP COA是否等于用作TLS或IPSec连接端点的IP地址。然而，这样的策略将防止FA对AAA和移动IP隧道分组使用不同的接口，并且在每种部署情况下可能都不可取。
A similar set of considerations applies to the connection between AAAH and HA when those entities are in different administrative domains. However, here the roles are reversed because it is the AAAH that contacts the HA via the HAR. The identity of the candidate HA is given to the AAAH in the AMR, and the AAAH should expect to receive the same identity in the public key certificates during TLS or IPSec negotiation. The HA may authorize individual connections by acting as its own redirect server, or it may maintain a list of trusted roaming partners.
当AAAH和HA之间的实体位于不同的管理域时，类似的考虑因素也适用于它们之间的连接。然而，这里的角色是相反的，因为是AAAH通过HAR联系医管局。候选HA的身份在AMR中提供给AAAH，并且AAAH应该期望在TLS或IPSec协商期间在公钥证书中接收相同的身份。HA可以通过充当其自己的重定向服务器来授权单个连接，或者它可以维护受信任漫游伙伴的列表。
This application creates and distributes a single session key for each pair of MSAs between two entities; e.g., the same session key is used for the MN-HA MSA and the HA-MN MSA. This is safe to do from a security perspective, as the session keys are only used with keyed hash functions to generate authenticator values that protect the integrity of each Mobile IP control message. Mobile IP messages have built-in replay protection with the use of timestamps or nonces [MOBILEIP], and, due to the nature of the protocol, requests are always different bitwise from responses, at least in the message type code. This avoids problems that might arise in other situations
此应用程序为两个实体之间的每对MSA创建和分发单个会话密钥；e、 例如，相同的会话密钥用于MN-HA MSA和HA-MN MSA。从安全角度来看，这样做是安全的，因为会话密钥仅与密钥哈希函数一起使用，以生成保护每个移动IP控制消息完整性的验证器值。移动IP消息具有内置的重播保护，使用时间戳或nonce[MOBILEIP]，并且，由于协议的性质，请求总是按位与响应不同，至少在消息类型代码中是这样。这样可以避免在其他情况下可能出现的问题
where an attacker could mount a replay or reflection attack if the same key were used (for example) to encrypt otherwise unprotected traffic on more than one connection leg in the network.
如果（例如）在网络中的多个连接分支上使用相同的密钥加密未受保护的流量，则攻击者可以装载重播或反射攻击。
Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-SHA-1 one-way function. Because the nonces and authentication extensions may be observed by anyone with access to a clear-text copy of the Registration Reply, the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack if it did not contain enough entropy. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits.
nonce被发送到移动节点，用于通过HMAC-SHA-1单向函数生成会话密钥。由于可以访问注册回复的明文副本的任何人都可能观察到nonce和身份验证扩展，因此，如果移动节点和home Diameter服务器之间的预共享密钥没有包含足够的熵，那么它将容易受到脱机字典攻击。为了防止这种情况，移动节点和home Diameter服务器之间的预共享密钥应该是至少96位的随机选择数量。
Because the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce is strongly recommended to be a random [RANDOM] value of at least 128 bits. The long-term secret between the MN and AAAH MUST be refreshed periodically, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished by using out-of-band mechanisms, which are not specified in this document.
由于会话密钥由长期秘密和nonce决定，因此nonce在时间上和全局上都是唯一的；如果nonce要重复，那么会话密钥也要重复。为了防止出现这种情况，强烈建议将nonce设置为至少128位的随机[随机]值。MN和AAAH之间的长期秘密必须定期刷新，以防止由于暂时重用或其他因素而恢复长期秘密。这是通过使用带外机制来实现的，本文档中未指定这些机制。
Note that it is not recommended to set the MIP-MSA-Lifetime AVP value to zero, as keeping session keys for a long time (no refresh) increases the level of vulnerability.
请注意，不建议将MIP MSA Lifetime AVP值设置为零，因为长时间保留会话密钥（无刷新）会增加漏洞级别。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[DIAMBASE]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MOBILEIP]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[MIPCHAL]Perkins，C.和P.Calhoun，“移动IPv4挑战/响应扩展”，RFC3012，2000年11月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[NAI]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[MIPKEYS] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IP", RFC 3957, March 2005.
[MIPKEYS]Perkins，C.和P.Calhoun，“移动IP的身份验证、授权和计费（AAA）注册密钥”，RFC 3957，2005年3月。
[AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
[AAANAI]Johansson，F.和T.Johansson，“用于承载网络访问标识符的移动IPv4扩展”，RFC 3846，2004年6月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[TLS] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[TLS]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[MIPREQ]Glass，S.，Hiller，T.，Jacobs，S.，和C.Perkins，“移动IP认证、授权和记帐要求”，RFC 29772000年10月。
[CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001.
[CDMA2000]Hiller，T.，Walsh，P.，Chen，X.，Munson，M.，Dommety，G.，Sivalingham，S.，Lim，B.，McCann，P.，Shiino，H.，Hirschman，B.，Manning，S.，Hsu，R.，Koo，H.，Lipford，M.，Calhoun，P.，Lo，C.，Jaques，E.，Campbell，E.，Xu，Y.，Baba，S.，Ayaki，T.，Seki，T.，A.Hameed，“AAA的CDMA2000无线数据要求”，RFC 31412001年6月。
[EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[EVALROAM]Aboba，B.和G.Zorn，“评估漫游协议的标准”，RFC 2477，1999年1月。
[MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[MIPNAI]Calhoun，P.和C.Perkins，“IPv4移动IP网络访问标识符扩展”，RFC 27942000年3月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and Pankaj Patel for their participation in the pre-IETF Document Reading Party; Erik Guttman for his very useful proposed text; and to Fredrik Johansson, Martin Julien, and Bob Kopacz for their very useful contributed text.
作者感谢尼纳德·特里富诺维奇、哈塞布·阿赫塔尔和潘卡吉·帕特尔参加IETF前文件阅读会；埃里克·古特曼提出的非常有用的文本；感谢弗雷德里克·约翰森、马丁·朱利安和鲍勃·科帕茨，感谢他们非常有用的贡献文本。
The authors would also like to thank the participants of 3GPP2's TSG-X working group for their valuable feedback, and the following people for their contribution in the development of the protocol: Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael Chen, Henry Haverinen, and Johan Johansson. General redirect server text due to Pasi Eronen was borrowed from Diameter-EAP.
作者还想感谢3GPP2的TSG-X工作组的参与者提供了宝贵的反馈，并感谢以下人员在协议制定过程中的贡献：Kevin Purser、Thomas Panagiotis、Mark Eklund、Paul Funk、Michael Chen、Henry Haverinen和Johan Johansson。由于Pasi-Eronen而导致的常规重定向服务器文本是从Diameter EAP借用的。
Pat Calhoun would like to thank Sun Microsystems, as most of the effort put into this document was done while he was in their employ.
Pat Calhoun要感谢Sun Microsystems，因为在本文档中投入的大部分精力都是在他任职期间完成的。
Authors' Addresses
作者地址
Questions about this memo can be directed to:
有关本备忘录的问题，请联系：
Pat Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Pat Calhoun Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
Phone: +1 408-853-5269
EMail: pcalhoun@cisco.com
Phone: +1 408-853-5269
EMail: pcalhoun@cisco.com
Tony Johansson Bytemobile, Inc. 2029 Stierlin Court Mountain View, CA 94043
托尼·约翰森·拜特莫比尔公司，2029年，加利福尼亚州斯迪尔林法院山景城，邮编94043
Phone: +1 650-641-7817
Fax: +1 650-641-7701
EMail: tony.johansson@bytemobile.com
Phone: +1 650-641-7817
Fax: +1 650-641-7701
EMail: tony.johansson@bytemobile.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
查尔斯·E·珀金斯诺基亚研究中心313飞兆半导体山景大道，加利福尼亚州94043
Phone: +1 650-625-2986
Fax: +1 650-625-2502
EMail: Charles.Perkins@nokia.com
Phone: +1 650-625-2986
Fax: +1 650-625-2502
EMail: Charles.Perkins@nokia.com
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA
汤姆·希勒·朗讯科技有限公司1960年美国伊利诺伊州朗讯巷纳珀维尔市，邮编：60566
Phone: +1 630-979-7673
EMail: tomhiller@lucent.com
Phone: +1 630-979-7673
EMail: tomhiller@lucent.com
Peter J. McCann Lucent Technologies 1960 Lucent Lane Naperville, IL 60563 USA
Peter J.McCann-Lucent Technologies，1960年美国伊利诺伊州朗讯巷纳珀维尔，邮编：60563
Phone: +1 630-713-9359
Fax: +1 630-713-1921
EMail: mccap@lucent.com
Phone: +1 630-713-9359
Fax: +1 630-713-1921
EMail: mccap@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。