Independent Submission K. Leung
Request for Comments: 5563 G. Dommety
Category: Informational Cisco Systems
ISSN: 2070-1721 P. Yegani
Juniper Networks
K. Chowdhury
Starent Networks
February 2010
Independent Submission K. Leung
Request for Comments: 5563 G. Dommety
Category: Informational Cisco Systems
ISSN: 2070-1721 P. Yegani
Juniper Networks
K. Chowdhury
Starent Networks
February 2010
WiMAX Forum / 3GPP2 Proxy Mobile IPv4
WiMAX论坛/3GPP2代理移动IPv4
Abstract
摘要
Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2.
移动IPv4是一种标准移动协议，它使IPv4设备能够在网络之间移动，同时保持其IP地址。移动设备具有移动IPv4客户端功能，以向路由锚（称为归属代理）发送其位置信号。然而，由于各种原因，有许多IPv4设备没有这种功能。本文档描述了代理移动IPv4（PMIPv4），这是一种基于在网络实体中具有移动IPv4客户端功能的方案，用于为未改变且不具有移动性的IPv4设备提供移动性支持。本文档还描述了WiMAX论坛中指定的PMIPv4的特定应用以及3GPP2中将采用的另一个应用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5563.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5563.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Benefits of Proxy Mobile IPv4 ...................................6
4. Overview of Proxy Mobile IPv4 ...................................7
4.1. Mobility Signaling for Mobile Device .......................7
4.1.1. Proxy Registration during Initial Network
Attachment ..........................................8
4.1.2. Proxy Registration Renewal .........................11
4.1.3. Proxy Handover Support .............................12
4.1.4. Resource Cleanup ...................................13
4.2. Establishment of a Bi-Directional Tunnel ..................14
4.2.1. Packet Forwarding ..................................14
4.2.2. Broadcast and Multicast ............................14
4.2.3. Forwarding between Devices on the Same PMA .........15
4.3. Security Association between the PMA and the HA ...........15
4.4. Registration Sequencing ...................................15
4.5. Mobile Device Interface Configuration .....................16
4.6. Dynamic HA Discovery ......................................16
5. Proxy Mobile IPv4 Extensions ...................................16
5.1. PMIPv4 Per-Node Authentication Method Extension ...........17
5.2. Proxy Mobile IPv4 Interface ID Extension ..................18
5.3. Proxy Mobile IPv4 Device ID Extension .....................18
5.4. Proxy Mobile IPv4 Subscriber ID Extension .................19
5.5. PMIPv4 Access Technology Type Extension ...................20
6. Appearance of Being at Home Network ............................22
6.1. ARP Considerations ........................................22
6.2. ICMP Considerations .......................................23
6.3. DHCP Considerations .......................................23
6.4. PPP IPCP Considerations ...................................24
6.5. Link-Local Multicast and Broadcast Considerations .........24
7. Proxy Mobility Agent Operation .................................24
8. Home Agent Operation ...........................................25
8.1. Processing Proxy Registration Requests ....................26
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Benefits of Proxy Mobile IPv4 ...................................6
4. Overview of Proxy Mobile IPv4 ...................................7
4.1. Mobility Signaling for Mobile Device .......................7
4.1.1. Proxy Registration during Initial Network
Attachment ..........................................8
4.1.2. Proxy Registration Renewal .........................11
4.1.3. Proxy Handover Support .............................12
4.1.4. Resource Cleanup ...................................13
4.2. Establishment of a Bi-Directional Tunnel ..................14
4.2.1. Packet Forwarding ..................................14
4.2.2. Broadcast and Multicast ............................14
4.2.3. Forwarding between Devices on the Same PMA .........15
4.3. Security Association between the PMA and the HA ...........15
4.4. Registration Sequencing ...................................15
4.5. Mobile Device Interface Configuration .....................16
4.6. Dynamic HA Discovery ......................................16
5. Proxy Mobile IPv4 Extensions ...................................16
5.1. PMIPv4 Per-Node Authentication Method Extension ...........17
5.2. Proxy Mobile IPv4 Interface ID Extension ..................18
5.3. Proxy Mobile IPv4 Device ID Extension .....................18
5.4. Proxy Mobile IPv4 Subscriber ID Extension .................19
5.5. PMIPv4 Access Technology Type Extension ...................20
6. Appearance of Being at Home Network ............................22
6.1. ARP Considerations ........................................22
6.2. ICMP Considerations .......................................23
6.3. DHCP Considerations .......................................23
6.4. PPP IPCP Considerations ...................................24
6.5. Link-Local Multicast and Broadcast Considerations .........24
7. Proxy Mobility Agent Operation .................................24
8. Home Agent Operation ...........................................25
8.1. Processing Proxy Registration Requests ....................26
9. Mobile Device Operation ........................................26
9.1. Initial Network Access ....................................27
9.2. Mobile Device Mobility ....................................27
9.3. Sending and Receiving Packets .............................27
10. Proxy Mobile IPv4 Use Case in WiMAX ...........................28
10.1. Proxy Mobile IPv4 Call Flow Examples with Split
PMA in WiMAX .............................................31
11. Proxy Mobile IPv4 Use Case in 3GPP2 ...........................33
11.1. Handover Considerations in 3GPP2 .........................36
12. IANA Considerations ...........................................37
12.1. Mobile IPv4 Extension Types ..............................38
12.2. Mobile IPv4 Error Codes ..................................38
13. Security Considerations .......................................38
14. Acknowledgements ..............................................38
15. References ....................................................39
15.1. Normative References .....................................39
15.2. Informative References ...................................39
9. Mobile Device Operation ........................................26
9.1. Initial Network Access ....................................27
9.2. Mobile Device Mobility ....................................27
9.3. Sending and Receiving Packets .............................27
10. Proxy Mobile IPv4 Use Case in WiMAX ...........................28
10.1. Proxy Mobile IPv4 Call Flow Examples with Split
PMA in WiMAX .............................................31
11. Proxy Mobile IPv4 Use Case in 3GPP2 ...........................33
11.1. Handover Considerations in 3GPP2 .........................36
12. IANA Considerations ...........................................37
12.1. Mobile IPv4 Extension Types ..............................38
12.2. Mobile IPv4 Error Codes ..................................38
13. Security Considerations .......................................38
14. Acknowledgements ..............................................38
15. References ....................................................39
15.1. Normative References .....................................39
15.2. Informative References ...................................39
There are many IPv4 devices that do not have or cannot be enabled with Mobile IPv4 [RFC3344] functionality. Yet, mobility for them is essential. Proxy Mobile IPv4 provides mobility support without "touching" these devices. The scheme is based on network entities that perform the mobility-management function for a mobile device. The location of the device is signaled by the network element on the access network (referred to as the Proxy Mobility Agent (PMA)) to inform the network entity on the home network (referred to as the Home Agent (HA)) associated with the IPv4 address used by the device. Mobile IPv4 messaging is used by the PMA and HA, which correspond to the RFC 3344 entities Mobile Node (in proxy mode) and Home Agent, respectively.
许多IPv4设备没有或无法启用移动IPv4[RFC3344]功能。然而，流动性对他们来说至关重要。代理移动IPv4在不“接触”这些设备的情况下提供移动支持。该方案基于为移动设备执行移动性管理功能的网络实体。设备的位置由接入网络上的网元（称为代理移动代理（PMA））发信号通知归属网络上的网络实体（称为归属代理（HA））与设备使用的IPv4地址相关联。移动IPv4消息由PMA和HA使用，它们分别对应于RFC 3344实体移动节点（在代理模式下）和归属代理。
These are some examples of Proxy Mobile IPv4:
以下是代理移动IPv4的一些示例：
1. A Wireless Local Area Network (WLAN) access point or cellular base station performs registration with the Home Agent when a mobile device is associated on the air-link.
1. 当移动设备在空中链路上关联时，无线局域网（WLAN）接入点或蜂窝基站向归属代理执行注册。
2. An access router or Foreign Agent performs registration with the Home Agent when a mobile device is detected on the network.
2. 当在网络上检测到移动设备时，接入路由器或外部代理向归属代理执行注册。
Mobile IPv4 is used by the network entities because the mobility protocol has the functions needed to set up the route and tunneling endpoints for the mobile device's IP address and to deliver configuration parameters (e.g., DNS server addresses, default gateway) for enabling the mobile device's IP stack. When Mobile IPv4 is used in this way, the security association is between the PMA and
网络实体使用移动IPv4是因为移动协议具有为移动设备的IP地址设置路由和隧道端点所需的功能，并提供用于启用移动设备的IP堆栈的配置参数（例如DNS服务器地址、默认网关）。当以这种方式使用移动IPv4时，安全关联在PMA和IPv4之间
the HA because these entities are the signaling endpoints. Also, when the mobile device moves to a new PMA, the sequencing of messages sourced from multiple PMAs needs to be handled properly by the HA.
HA，因为这些实体是信令端点。此外，当移动设备移动到新的便携式维修辅助设备时，来自多个便携式维修辅助设备的消息序列需要由医管局妥善处理。
This document describes how the network entities, PMA and HA, provide mobility management for the mobile device. It is organized to cover the generic functionality of Proxy Mobile IPv4 and also the specifics pertaining to WiMAX (Section 10) and 3GPP2 (Section 11).
本文档描述了网络实体PMA和HA如何为移动设备提供移动性管理。它的组织涵盖了代理移动IPv4的一般功能，以及与WiMAX（第10节）和3GPP2（第11节）相关的细节。
Note that Proxy Mobile IPv6 [RFC5213] is an IETF standard for network-based mobility management that enables IP mobility for a host without requiring its participation in any mobility-related signaling.
请注意，代理移动IPv6[RFC5213]是基于网络的移动性管理的IETF标准，它支持主机的IP移动性，而无需参与任何移动性相关信令。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following new terminology and abbreviations are introduced in this document; all other general mobility-related terms are as defined in Mobile IPv4 specification [RFC3344].
本文件中引入了以下新术语和缩写：；移动IPv4规范[RFC3344]中定义了所有其他通用移动相关术语。
Mobile Device
移动设备
The mobile device is used to refer to an IPv4 device with its mobility provided by the network. The mobile device is not required to participate in any mobility-related signaling for achieving mobility for an obtained IP address.
移动设备用于指具有由网络提供的移动性的IPv4设备。移动设备不需要参与任何与移动性相关的信令以实现所获得的IP地址的移动性。
Proxy Mobile IPv4 Client (PMIPv4 Client)
代理移动IPv4客户端（PMIPv4客户端）
This network function is responsible for initiating and maintaining the Proxy Mobile IPv4 registration on behalf of the mobile device. Essentially, it performs the Mobile IPv4 client function but is hosted in the network. In some cases, this function is collocated with the Foreign Agent; in others, it is not. In both cases, Proxy Mobile IPv4 registration still goes via the Foreign Agent at all practical effects, even if it is internal to the node.
此网络功能负责代表移动设备启动和维护代理移动IPv4注册。本质上，它执行移动IPv4客户端功能，但托管在网络中。在某些情况下，此功能与外部代理并置；在其他国家，情况并非如此。在这两种情况下，代理移动IPv4注册实际上仍然通过外部代理进行，即使它是节点的内部代理。
Home Agent (HA)
房屋署（房委会）
The Home Agent that is defined in Mobile IPv4 [RFC3344] is used in the Proxy Mobile IPv4 scheme. It is the topological anchor point for the mobile device's home network and is the entity that manages the mobile device's reachability state. The additional
移动IPv4[RFC3344]中定义的归属代理用于代理移动IPv4方案。它是移动设备家庭网络的拓扑锚定点，是管理移动设备可达性状态的实体。附加的
capabilities for supporting Proxy Mobile IPv4 in the Home Agent are defined in this document.
本文档中定义了在归属代理中支持代理移动IPv4的功能。
Foreign Agent (FA)
外国代理人（FA）
The Foreign Agent that is defined in [RFC3344] is used in the Proxy Mobile IPv4 scheme. It is either collocated with or separate from the PMIPv4 client. It serves the purpose of tunnel endpoint from Proxy Mobile IPv4 perspective.
[RFC3344]中定义的外部代理用于代理移动IPv4方案。它要么与PMIPv4客户端并置，要么与PMIPv4客户端分离。从代理移动IPv4的角度来看，它服务于隧道端点。
Access Router (AR)
接入路由器（AR）
Access Router is a commonly used term that refers to the node in the network that connects the hosts to the IP network.
访问路由器是一个常用术语，指网络中连接主机与IP网络的节点。
Proxy Mobility Agent (PMA)
代理移动代理（PMA）
Proxy Mobility Agent is the logical entity in the network that encompasses both the PMIPv4 client and the FA functions. The PMIPv4 client and the FA collocation in the Access Router constitute an integrated PMA. When the PMIPv4 client and the FA functions are not collocated in the Access Router, it is referred to as a split PMA. A PMIPv4 client may have association with multiple FAs, and vice versa.
代理移动代理是网络中包含PMIPv4客户端和FA功能的逻辑实体。PMIPv4客户端和接入路由器中的FA配置构成一个集成的PMA。当PMIPv4客户端和FA功能未在接入路由器中并置时，它被称为分割PMA。PMIPv4客户端可能与多个FAs关联，反之亦然。
Proxy Registration Request (PRRQ)
代理注册请求（PRRQ）
The Registration Request message is sent by the Proxy Mobility Agent to the Home Agent in order to set up a mobility binding entry for a mobile device. The message format is identical to that of the Mobile IPv4 Registration Request, though the Proxy Mobile IPv4 extensions that are defined in this document may be included for enhanced features of network-based mobility management.
注册请求消息由代理移动代理发送到归属代理，以便为移动设备设置移动绑定条目。该消息格式与移动IPv4注册请求的消息格式相同，但为了增强基于网络的移动性管理功能，可能会包括本文档中定义的代理移动IPv4扩展。
Proxy Registration Reply (PRRP)
代理注册回复（PRRP）
The Registration Reply message is sent by the Home Agent in response to the Proxy Registration Request received from the Proxy Mobility Agent. The message format is identical to that of the Mobile IPv4 Registration Reply, though the Proxy Mobile IPv4 extensions that are defined in this document may be included for enhanced features of network-based mobility management.
注册回复消息由归属代理发送，以响应从代理移动代理接收的代理注册请求。该消息格式与移动IPv4注册回复的消息格式相同，但为了增强基于网络的移动性管理功能，可能会包括本文档中定义的代理移动IPv4扩展。
Proxy Mobile IPv4 (PMIPv4) is designed to satisfy the requirements listed below. In addition, while this specification and Proxy Mobile IPv4 are not standards, they employ a standard: Mobile IPv4. Implementations of Mobile IPv4 can be re-used (i.e., a client-based mobility protocol can be used "as-is" to support network-based mobility). However, new PMIPv4 extensions that are added to Mobile IPv4 improves the flexibility of the solution. The practical advantage of having a common mobility protocol for both client-based and network-based mobility is that a Home Agent can anchor all types of mobile devices, both ones that have and ones that lack the Mobile IPv4 function.
代理移动IPv4（PMIPv4）旨在满足下列要求。此外，虽然此规范和代理移动IPv4不是标准，但它们使用了一个标准：移动IPv4。移动IPv4的实现可以重复使用（即，基于客户端的移动协议可以“按原样”使用以支持基于网络的移动）。但是，添加到移动IPv4的新PMIPv4扩展提高了解决方案的灵活性。为基于客户端和基于网络的移动性提供通用移动性协议的实际优势在于，归属代理可以锚定所有类型的移动设备，包括具有和缺少移动IPv4功能的移动设备。
The network-based mobility management solution defined in this document has the following significant reasons for its use in any wireless network:
本文档中定义的基于网络的移动性管理解决方案在任何无线网络中使用的主要原因如下：
1. Support for Unmodified Hosts
1. 支持未修改的主机
An overwhelming majority of IPv4 hosts do not have Mobile IPv4 capability. Providing mobility for them is achievable using Proxy Mobile IPv4. This is accomplished without "touching" the user's devices by running on a myriad of operating systems and networking stacks.
绝大多数IPv4主机不具备移动IPv4功能。使用代理移动IPv4可以为他们提供移动性。通过在无数操作系统和网络堆栈上运行，无需“触摸”用户的设备即可实现这一点。
2. Re-Use of Existing Home Agent
2. 重新使用现有的Home Agent
An existing Home Agent implementation can be used for network-based mobility as well. Further enhancements are optional and only incremental in nature. There are many commonalities between client-based and network-based mobility, and sharing the same protocol is a significant benefit.
现有的归属代理实现也可用于基于网络的移动性。进一步的增强是可选的，本质上只是增量的。基于客户端和基于网络的移动性之间有许多共同点，共享相同的协议是一个显著的好处。
3. Reduction of Air-Link Resource Consumption
3. 减少空中链路资源消耗
Mobility-related signaling over the air-link is eliminated.
消除了空中链路上与移动性相关的信令。
4. Support for Heterogeneous Wireless Link Technologies
4. 支持异构无线链路技术
Since Proxy Mobile IPv4 is based on an access, technology-independent, mobility protocol, it can be used for any type of access network.
由于代理移动IPv4基于接入、独立于技术的移动协议，因此它可以用于任何类型的接入网络。
From the network perspective, a mobile device is identified by the Network Access Identifier (NAI) and the forwarding is set up between the PMA and HA for the mobile device's current point of attachment on the network. The mobile device may be attached to
从网络的角度来看，移动设备由网络接入标识符（NAI）标识，并且在PMA和HA之间为移动设备在网络上的当前连接点设置转发。移动设备可以连接到移动设备
multiple networks concurrently, although the network treats each access interface independently. This feature can be supported with the use of the PMIPv4 Access Technology Type Extension (Section 5.5).
同时多个网络，尽管网络独立地处理每个接入接口。使用PMIPv4访问技术类型扩展（第5.5节）可以支持此功能。
5. Support for IPv4 and IPv6 Hosts
5. 支持IPv4和IPv6主机
As IPv6 increases in popularity, the host will likely be dual stack. Adding IPv6 support to the host for Proxy Mobile IPv4 involves the methods defined in [RFC5454]. There are additional enhancements needed, which are described in "Proxy Mobile IPv6" [RFC5213]. However, support for an IPv6 host is out of the scope of this document.
随着IPv6的普及，主机可能会是双栈的。向主机添加对代理移动IPv4的IPv6支持涉及[RFC5454]中定义的方法。还需要其他增强功能，如“代理移动IPv6”[RFC5213]中所述。但是，对IPv6主机的支持超出了本文档的范围。
After the mobile device completes network-access authentication, the PMA exchanges Proxy Mobile IPv4 registration messages with the HA to set up proper routing and tunneling of packets from/to the Mobile Node. The PMIPv4 client is responsible for initiating the Proxy Mobile IPv4 registration. For integrated PMA, the PMIPv4 client and the FA interaction is all within the node. In the case of split PMA implementation, the interactions between the PMIPv4 client and the FA are exposed. The interface between the PMIP Client and the FA in the split PMA scenario is defined in a standards organization specification [NWG] and is consequently out of the scope of this document.
在移动设备完成网络接入认证后，PMA与HA交换代理移动IPv4注册消息，以设置从/到移动节点的数据包的正确路由和隧道。PMIPv4客户端负责启动代理移动IPv4注册。对于集成PMA，PMIPv4客户端和FA交互都在节点内。在拆分PMA实现的情况下，PMIPv4客户端和FA之间的交互是公开的。在分割PMA场景中，PMIP客户机和FA之间的接口在标准组织规范[NWG]中定义，因此不在本文件范围内。
The following call flows describe the operations of Proxy Mobile IPv4. The initial network attachment, registration renewal, and resource cleanup procedures are covered. Note that the protocols that interact with Proxy Mobile IP are identified and explained in more detail. The PPP/IPCP (IP Control Protocol) protocol involves a PPP client in the mobile device and a Network Access Server (NAS) in the AR. DHCP involves a DHCP client in the MN and a DHCP server in either the AR or the HA. PMIPv4 involves a PMA in the AR and an HA in the router on the home network. The Authentication, Authorization, and Accounting (AAA) protocol involves a AAA client in the AR and a AAA server in the network. The collocation of the functional entities in the AR/HA enables parameters to be shared/processed among the protocols.
以下调用流描述代理移动IPv4的操作。介绍了初始网络连接、注册续订和资源清理过程。请注意，与代理移动IP交互的协议已被识别并进行了更详细的解释。PPP/IPCP（IP控制协议）协议涉及移动设备中的PPP客户端和AR中的网络访问服务器（NAS）。DHCP涉及MN中的DHCP客户端和AR或HA中的DHCP服务器。PMIPv4涉及AR中的PMA和家庭网络上路由器中的HA。认证、授权和记帐（AAA）协议涉及AR中的AAA客户端和网络中的AAA服务器。AR/HA中功能实体的配置使得参数能够在协议之间共享/处理。
When the various network entities are not collocated, any sharing of parameters or other state information between them is out of the scope of this document.
当各种网络实体未并置时，它们之间的任何参数或其他状态信息共享不在本文档的范围内。
+----+ +-------+ +-------+ +-----+
| | | AR / | | | | |
| MN | | PMA | | AAA | | HA |
| | | | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1a | 1b | |
Authentication |<------------->|<----------->| |
| | | |
| 2 | | |
+-> |-------------->| | |
| | | 3 | |
| | |-------------------------->| <-+
Address | | | | | |PMIP
Acquisition| | | 4 | | |
| | |<--------------------------| <-+
| | 5 | | |
+-> |<--------------| | |
| | | |
| 6 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
+----+ +-------+ +-------+ +-----+
| | | AR / | | | | |
| MN | | PMA | | AAA | | HA |
| | | | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1a | 1b | |
Authentication |<------------->|<----------->| |
| | | |
| 2 | | |
+-> |-------------->| | |
| | | 3 | |
| | |-------------------------->| <-+
Address | | | | | |PMIP
Acquisition| | | 4 | | |
| | |<--------------------------| <-+
| | 5 | | |
+-> |<--------------| | |
| | | |
| 6 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
Figure 1: Network Connection Setup
图1：网络连接设置
The initial network-attachment procedure is described below. There are three distinct phases. First, authentication and authorization happen when the mobile device accesses the network. Then, the mobile device attempts to obtain an IP address. This triggers Proxy Mobile IP, which assigns/authorizes the IP address and sets up forwarding between the PMA and HA. The host configuration parameters may be passed in the PMIPv4 signaling. Finally, the mobile device configures its IP stack with the IP address and the obtained host configuration. Packets to and from the mobile device transit both the PMA and HA.
初始网络连接程序如下所述。有三个不同的阶段。首先，身份验证和授权发生在移动设备访问网络时。然后，移动设备尝试获取IP地址。这将触发代理移动IP，代理移动IP分配/授权IP地址，并在PMA和HA之间建立转发。主机配置参数可以在PMIPv4信令中传递。最后，移动设备使用IP地址和获得的主机配置配置其IP堆栈。进出移动设备的数据包传输PMA和HA。
1a. The mobile device establishes a L2 (Layer 2) link with the base station (not shown) and performs access authentication/authorization with the AR (Access Router). During this phase, the mobile device may run either the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] if PPP [RFC1661] is used or the Extensible Authentication Protocol (EAP) [RFC3748] over foo (foo being the specific access technology, or PANA [RFC4058]). The AR acts as the NAS (Network Access Server) in this step.
1a。移动设备与基站（未示出）建立L2（第2层）链路，并与AR（接入路由器）执行接入认证/授权。在此阶段期间，如果使用了PPP[RFC1661]，则移动设备可以运行质询握手认证协议（CHAP）[RFC1994]，或者通过foo（foo是特定接入技术，或者PANA[RFC4058]）运行可扩展认证协议（EAP）[RFC3748]。在此步骤中，AR充当NAS（网络访问服务器）。
1b. The AAA client exchanges AAA messages with the AAA infrastructure to perform authentication and authorization of the mobile device. As part of this step, the AAA server may download some information about the mobile device (e.g., the user's profile, handset type, assigned Home Agent address, and other capabilities of the mobile device).
1b。AAA客户端与AAA基础设施交换AAA消息，以执行移动设备的身份验证和授权。作为该步骤的一部分，AAA服务器可以下载关于移动设备的一些信息（例如，用户的简档、手持设备类型、分配的归属代理地址和移动设备的其他功能）。
2. The mobile device requests an IP address via a PPP/IPCP [RFC1332] or DHCP [RFC2131]. Specifically for PPP, the PPP client sends an IPCP Configure-Request to the NAS. As for DHCP, the DHCP client sends the DHCP Discover message to the DHCP relay agent/ server.
2. 移动设备通过PPP/IPCP[RFC1332]或DHCP[RFC2131]请求IP地址。特别是对于PPP，PPP客户端向NAS发送IPCP配置请求。对于DHCP，DHCP客户端向DHCP中继代理/服务器发送DHCP发现消息。
For the DHCP case, the DHCP server or DHCP relay agent sends the DHCP Ack message to the DHCP client after PMIPv4 signaling has completed.
对于DHCP情况，DHCP服务器或DHCP中继代理在PMIPv4信令完成后向DHCP客户端发送DHCP Ack消息。
3. Triggered by step 2, the PMA sends a Proxy Registration Request (PRRQ) to the HA. The HA's IP address is either obtained from the AAA server at step 1b or discovered by some other method. The PRRQ contains the Care-of Address (CoA) of the PMA (the collocated FA in this case). The Home Address field is set to zero or the IP address is specified as a hint in the DHCP or IPCP message. The PRRQ MUST be protected by the methods described in the Security Considerations (Section 13) of this document. The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document.
3. 由步骤2触发，PMA向HA发送代理注册请求（PRRQ）。HA的IP地址要么在步骤1b从AAA服务器获得，要么通过某种其他方法发现。PRRQ包含PMA（本例中为并置FA）的转交地址（CoA）。Home Address字段设置为零，或者在DHCP或IPCP消息中将IP地址指定为提示。PRRQ必须采用本文件安全注意事项（第13节）中所述的方法进行保护。MN-HA或FA-HA密钥的派生和分发不在本文档的范围内。
4. The Home Agent sets up the mobility binding entry for the mobile device after assigning an IP address or authorizing the requested Home Address. The Home Agent may also assign a Generic Routing Encapsulation (GRE) key in this step (if GRE tunneling is used between the PMA and HA). The HA returns the Home Address and the GRE key (if applicable) in the Proxy Registration Reply (PRRP) to the PMA. If the requested Home Address is not authorized, the Home Agent denies the registration with error code 129 (administratively prohibited). After the PMA processes the PRRP, the forwarding path for the Home Address between the PMA and HA is established. A GRE tunnel may be used between the PMA and the HA [MIP4GREKEY]. This event completes the Proxy Mobile IPv4 signaling for initial network attachment.
4. 归属代理在分配IP地址或授权所请求的归属地址之后为移动设备设置移动绑定条目。归属代理还可以在此步骤中分配通用路由封装（GRE）密钥（如果在PMA和HA之间使用GRE隧道）。医管局会将代理注册回复（PRRP）中的家庭地址和GRE密钥（如适用）返回给PMA。如果请求的家庭地址未经授权，则家庭代理拒绝注册，错误代码为129（行政禁止）。PMA处理PRRP后，建立PMA和HA之间的家庭地址转发路径。可在PMA和HA之间使用GRE通道[MIP4GREKEY]。此事件完成初始网络连接的代理移动IPv4信令。
5. After the Proxy Mobile IPv4 registration exchange, the AR provides the IP address to the mobile device in response to step 2. For IPCP, the NAS replies to the PPP client with an IPCP Configure-Nak, which includes the PMIPv4-assigned Home Address
5. 在代理移动IPv4注册交换之后，AR响应于步骤2向移动设备提供IP地址。对于IPCP，NAS使用IPCP配置Nak（包括PMIPv4分配的家庭地址）回复PPP客户端
in the IP address configuration option and the DNS server address in the IPCP configuration option.
IP地址配置选项中的DNS服务器地址和IPCP配置选项中的DNS服务器地址。
The following procedure happens when the DHCP server is on the AR. The DHCP server sends a DHCP Offer with the PMIPv4-assigned Home Address in the yiaddr field to the DHCP client. The DHCP client sends a DHCP Request to the DHCP server, which replies with a DHCP Ack. The host configuration (such as the DNS server address) is included in the DHCP options in the message. Note that the DHCP messages are exchanged directly between the DHCP client and the DHCP server.
当DHCP服务器位于AR上时，将发生以下过程。DHCP服务器将在yiaddr字段中使用PMIPv4分配的主地址向DHCP客户端发送DHCP提供。DHCP客户端向DHCP服务器发送DHCP请求，DHCP服务器用DHCP Ack进行回复。主机配置（如DNS服务器地址）包含在消息中的DHCP选项中。请注意，DHCP消息直接在DHCP客户端和DHCP服务器之间交换。
In the case when AR acts as a DHCP relay agent, the DHCP Discover is relayed to the DHCP server on the HA. The DHCP server sends a DHCP Offer with the PMIPv4-assigned Home Address in the yiaddr field to the DHCP relay agent, which forwards it to the DHCP client. The DHCP Request and DHCP Ack messages are exchanged between the DHCP client and DHCP server via the DHCP relay agent. Regardless of the sequence of PMIPv4 signaling and DHCP exchanges, the interaction between PMIPv4 and DHCP involves in the same IP address for Home Address field and yiaddr field, respectively.
在AR充当DHCP中继代理的情况下，DHCP发现将中继到HA上的DHCP服务器。DHCP服务器将在yiaddr字段中带有PMIPv4分配的主地址的DHCP提供发送到DHCP中继代理，该代理将其转发到DHCP客户端。DHCP请求和DHCP Ack消息通过DHCP中继代理在DHCP客户端和DHCP服务器之间交换。无论PMIPv4信令和DHCP交换的顺序如何，PMIPv4和DHCP之间的交互分别涉及到相同的IP地址（用于Home address字段和yiaddr字段）。
6. At this step, the mobile device's IP stack is configured with an IP address that has a forwarding path between the AR/PMA and HA. Also, the host configuration (such as DNS servers) is configured at this time. Now that the IPCP or DHCP procedure has completed, the mobile device is ready to receive or send IP packets. If DHCP is used, the DHCP client renews the IP address by sending a DHCP Request directly to the DHCP server. The lease for the IP address is extended when a DHCP Ack from the DHCP server is received by the DHCP client.
6. 在该步骤中，移动设备的IP栈被配置为具有AR/PMA和HA之间的转发路径的IP地址。此外，主机配置（如DNS服务器）也在此时进行配置。现在IPCP或DHCP过程已经完成，移动设备就可以接收或发送IP数据包了。如果使用DHCP，DHCP客户端将通过直接向DHCP服务器发送DHCP请求来更新IP地址。当DHCP客户端接收到来自DHCP服务器的DHCP Ack时，IP地址的租约将延长。
+----+ +-------+ +-----+
| | | AR / | | |
| MN | | PMA | | HA |
| | | | | |
+----+ +-------+ +-----+
| | |
| | 1 |
| |----------------------->|
PMIPv4 | | |
Renewal | | 2 |
| |<-----------------------|
| | |
| | |
+----+ +-------+ +-----+
| | | AR / | | |
| MN | | PMA | | HA |
| | | | | |
+----+ +-------+ +-----+
| | |
| | 1 |
| |----------------------->|
PMIPv4 | | |
Renewal | | 2 |
| |<-----------------------|
| | |
| | |
Figure 2: Network Connection Maintenance
图2：网络连接维护
The network-connection maintenance procedure is described below. As long as the mobile device remains attached to the AR, the Proxy Mobile IPv4 session is maintained by re-registration exchanges between the AR and HA.
网络连接维护程序如下所述。只要移动设备保持连接到AR，代理移动IPv4会话就通过AR和HA之间的重新注册交换来维护。
1. Before the PMIPv4 registration lifetime expires, and assuming the AR has not received any indication that the mobile device detached from the network, the PMA sends a PRRQ to the HA to extend the duration of the mobility binding of the mobile device. This PRRQ is similar to the initial PRRQ (i.e., HA field set to the assigned HA, and CoA field set to the PMA), though the Home Address field is always set to the assigned IP address of the mobile device. The mobile device's IP stack can continue to send and receive IP packets using the Home Address anchored at the HA.
1. 在PMIPv4注册生存期到期之前，并且假设AR没有接收到移动设备从网络分离的任何指示，则PMA向HA发送PRRQ以延长移动设备的移动绑定的持续时间。该PRRQ类似于初始PRRQ（即，HA字段设置为分配的HA，CoA字段设置为PMA），尽管Home Address字段始终设置为移动设备的分配IP地址。移动设备的IP栈可以使用锚定在HA的归属地址继续发送和接收IP分组。
2. The HA sends the PRRP in response to the PRRQ received from the PMA. After the PMA processes the PRRP, the forwarding path between AR and HA remains intact.
2. 医管局会发送PRRP，以回应从PMA收到的PRRQ。PMA处理PRRP后，AR和HA之间的转发路径保持不变。
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
Authentication |<------------->| | |
| | | |
| | 2 | |
+-> | |-------------------------->|
PMIPv4 | | | | |
| | | 3 | |
+-> | |<--------------------------|
| | | |
| 4 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
Authentication |<------------->| | |
| | | |
| | 2 | |
+-> | |-------------------------->|
PMIPv4 | | | | |
| | | 3 | |
+-> | |<--------------------------|
| | | |
| 4 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
Figure 3: AR Handover
图3：AR移交
The AR handover procedure is described below. There are three phases. First, authentication and authorization happen when the mobile device attaches to the new AR in the network. The successful authentication triggers the Proxy Mobile IPv4 signaling. In the last phase, the forwarding path between the new AR and HA is set up for the mobile device to send and receive IP packets using the same Home Address anchored at the HA.
AR移交程序如下所述。有三个阶段。首先，当移动设备连接到网络中的新AR时，认证和授权发生。成功的身份验证将触发代理移动IPv4信令。在最后阶段，为移动设备设置新AR和HA之间的转发路径，以使用锚定在HA处的相同归属地址发送和接收IP分组。
1. The mobile device establishes L2 link with the base station (not shown) and performs access authentication/authorization with the new AR, using the security method for network re-attachment.
1. 移动设备与基站（未示出）建立L2链路，并使用用于网络重新连接的安全方法对新AR执行接入认证/授权。
2. Triggered by successful authentication, the PMA sends a PRRQ to the HA. The HA's IP address is typically obtained or is known by the method used for fast re-authentication during AR handover (e.g., context transfer between the two ARs), though other methods may be used. The PRRQ contains the CoA of the new PMA. The Home Address field is set to zero or the assigned IP address of the mobile device. The IP address is also obtained/known by the same method mentioned before.
2. 由成功的身份验证触发，PMA向HA发送PRRQ。HA的IP地址通常由AR切换期间用于快速重新认证的方法获得或已知（例如，两个AR之间的上下文传输），但也可以使用其他方法。PRRQ包含新PMA的CoA。家庭地址字段设置为零或移动设备的分配IP地址。IP地址也是通过前面提到的相同方法获得/已知的。
3. The Home Agent updates the existing mobility binding entry for the mobile device upon processing the PRRQ. The Home Agent returns the Home Address, fetched from the binding, in the PRRP to the new PMA. After the PMA processes the PRRP, the forwarding
3. 归属代理在处理PRRQ时更新移动设备的现有移动绑定条目。归属代理将PRRP中从绑定获取的归属地址返回给新的PMA。PMA处理PRRP后，转发
path for the Home Address between the new AR and HA is established. The event completes the Proxy Mobile IPv4 signaling for AR handover.
建立新AR和HA之间的家庭地址路径。事件完成AR切换的代理移动IPv4信令。
4. At this step, which happens around the same time as step 2, the mobile device's IP stack may detect L2 link going down and up after access re-authentication. The mobile device's IP stack may attempt to validate its IP address connectivity. See Sections 6.1, 6.2, and 6.3 of this document for considerations on ARP [RFCARP], ICMP [RFCICMP], and DHCP [RFC2131], respectively. Because the forwarding path is established between the new PMA and HA, the mobile device can receive or send IP packets using the Home Address.
4. 在该步骤中，该步骤大约与步骤2同时发生，移动设备的IP堆栈可以检测到在访问重新认证之后L2链路的下行和上行。移动设备的IP堆栈可能会尝试验证其IP地址连接。有关ARP[RFCARP]、ICMP[RFCICMP]和DHCP[RFC2131]的注意事项，请参见本文件第6.1、6.2和6.3节。因为在新的PMA和HA之间建立了转发路径，所以移动设备可以使用归属地址接收或发送IP分组。
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| | | 1 |
+-> | | |<------------|
| | | | |
Revocation | | | o 2 |
| | | | |
| | | | 3 |
+-> | | |------------>|
| | | |
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| | | 1 |
+-> | | |<------------|
| | | | |
Revocation | | | o 2 |
| | | | |
| | | | 3 |
+-> | | |------------>|
| | | |
Figure 4: Registration Revocation for Previous PMA
图4：先前PMA的注册撤销
The resource cleanup procedure for the old AR is described below. This cleanup is necessary when the old AR needs to delete its PMIPv4 and other associated states for a mobile device that has moved to another AR. Therefore, this is an optional procedure for Proxy Mobile IP. The alternative method is based on the new PMA notifying the old PMA to clean up resources. The alternative method is out of the scope of this document.
旧AR的资源清理过程如下所述。当旧AR需要删除已移动到另一AR的移动设备的PMIPv4和其他关联状态时，此清理是必要的。因此，这是代理移动IP的可选过程。替代方法基于新PMA通知旧PMA清理资源。替代方法不在本文件范围内。
1. Triggered by the update of the mobility binding entry for a mobile device that has moved to a new AR, the HA may send a Registration Revocation (as specified in RFC 3543 [RFC3543]) to the old PMA (i.e., specifically to the Foreign Agent entity) in order to clean up unused resources in an expeditious manner.
1. 由已移动到新AR的移动设备的移动绑定条目的更新触发，HA可向旧PMA（即，特别是向外部代理实体）发送注册撤销（如RFC 3543[RFC3543]中所规定），以便快速清理未使用的资源。
2. The old PMA removes the PMIPv4 states for the mobile device.
2. 旧的PMA删除移动设备的PMIPv4状态。
3. The old PMA sends revocation acknowledgement to the HA.
3. 旧PMA向医管局发送撤销确认。
The PMA and HA set up a tunnel between them for the Home Address after the PMIPv4 registration message exchange.
PMA和HA在PMIPv4注册消息交换后为家庭地址在他们之间建立了一个隧道。
The bi-directional tunnel between the PMA and the HA allows packets to flow in both directions, while the mobile device is connected on the visited network. All traffic to and from the mobile device travels through this tunnel.
当移动设备连接到访问的网络上时，PMA和HA之间的双向隧道允许数据包在两个方向上流动。所有进出移动设备的流量都通过此隧道。
While the PMA is serving a mobile device, it MUST be able to intercept all packets sent from the mobile device and forward them out the tunnel created for supporting that mobile device. Typically, forwarding is based on layer 2 information such as the source Media Access Control (MAC) address or ingress interface. This allows overlapping IP addresses to be supported for the packet from the mobile device. For example, the PMA forwards packets from mobile devices with the same IP address to the tunnel associated with each mobile device, based on the source MAC address.
当PMA为移动设备提供服务时，它必须能够截获从移动设备发送的所有数据包，并将其转发到为支持该移动设备而创建的隧道外。通常，转发基于第2层信息，例如源媒体访问控制（MAC）地址或入口接口。这允许来自移动设备的数据包支持重叠的IP地址。例如，PMA基于源MAC地址将来自具有相同IP地址的移动设备的分组转发到与每个移动设备相关联的隧道。
The PMA de-encapsulates any packets received on the tunnel from the HA before forwarding to the mobile device on its link. Typically, the forwarding is based on the destination IP address and ingress HA tunnel (which may have a GRE key). This allows overlapping IP addresses to be supported for the packet destined to the mobile device. For example, the PMA forwards packets to mobile devices with the same IP address to the link associated with each mobile device, based on the GRE key value of the tunnel created for the HA that serves these mobile devices.
PMA在通过其链路转发到移动设备之前，对在隧道上从HA接收到的任何数据包进行反封装。通常，转发基于目标IP地址和入口HA隧道（可能具有GRE密钥）。这允许目的地为移动设备的分组支持重叠的IP地址。例如，PMA基于为服务于这些移动设备的HA创建的隧道的GRE密钥值，将分组转发到具有相同IP地址的移动设备，以与每个移动设备相关联的链路。
The tunnel operation between the PMA and HA is the same as between the FA and HA in RFC 3344. The IP TTL (Time to Live), fragmentation, re-assembly, etc. logic remain the same. The tunnel mode is IPinIP by default or GRE as an option.
PMA和HA之间的隧道操作与RFC 3344中FA和HA之间的隧道操作相同。IP TTL（生存时间）、碎片、重新组装等逻辑保持不变。隧道模式默认为IPinIP或GRE作为选项。
Broadcast packet processing for DHCP and ARP (Address Resolution Protocol) messages are described in Section 6.3 and Section 6.1, respectively. For other types of broadcast packets, the PMA and HA
第6.3节和第6.1节分别描述了DHCP和ARP（地址解析协议）消息的广播数据包处理。对于其他类型的广播数据包，PMA和HA
process them in accordance to [RFC3344], [RFC3024], and [MIP4MCBC]. Only the Direct Encapsulation Delivery Style is supported, as there is no encapsulation for the packets between the mobile device and PMA.
按照[RFC3344]、[RFC3024]和[MIP4MCBC]进行处理。仅支持直接封装交付方式，因为移动设备和PMA之间的数据包没有封装。
When the communication peers are both attached to the same PMA, the packet is forwarded as specified in Section 4.2.1. The traffic between them should be routed via the HA without taking a local shortcut on the PMA. This ensures that data-traffic enforcement at the HA is not bypassed.
当通信对等方都连接到同一PMA时，按照第4.2.1节的规定转发数据包。他们之间的交通应该通过HA进行路由，而不必在PMA上走本地捷径。这确保不会绕过HA的数据流量强制执行。
The security relationship for protecting the control message exchanges between the PMA and the HA may be either per node (i.e., same security association for all mobile devices) or per MN (i.e., unique security association per mobile device). The method of obtaining the security association is outside the scope of this document.
用于保护PMA和HA之间的控制消息交换的安全关系可以是每个节点（即，所有移动设备的相同安全关联）或每个MN（即，每个移动设备的唯一安全关联）。获取安全关联的方法不在本文档的范围内。
For per-node SA support, the FA-HA Authentication extension or IPsec (indicated in the PMIPv4 extension) is used to authenticate the signaling messages (including Registration Revocation [RFC3543]) between PMA and HA. In the case of IPsec, Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection should be used. The IPsec endpoints are the IP addresses of the PMA and HA.
对于每个节点SA支持，FA-HA认证扩展或IPsec（在PMIPv4扩展中指示）用于认证PMA和HA之间的信令消息（包括注册撤销[RFC3543]）。在IPsec的情况下，应使用具有强制性完整性保护的传输模式封装安全有效负载（ESP）[RFC4303]。IPsec端点是PMA和HA的IP地址。
For per-MN SA support, the MN-HA Authentication extension and/or MN-AAA Authentication extension are used to authenticate the signaling.
对于每MN SA支持，MN-HA认证扩展和/或MN-AAA认证扩展用于认证信令。
The creation of the security association may be assisted by the AAA server at the time of access authentication.
在访问认证时，AAA服务器可以协助创建安全关联。
The Identification field in the registration message provides replay protection and sequencing when the timestamp method is used. This mechanism allows the HA to know the sequence of messages from the same PMA or different PMAs based on the Identification field. The HA can also synchronize the PMA's clock by using the Identification mismatch error code in the Proxy Registration Reply. This reply message would not be necessary when the PMA's clocks are synchronized using the Network Time Protocol [RFC1305] or some other method. Note that the use of nonce for sequencing and replay protection is outside the scope of this document.
当使用时间戳方法时，注册消息中的标识字段提供重播保护和排序。该机制允许医管局根据识别字段了解来自相同或不同PMA的消息序列。医管局也可以使用代理注册回复中的标识不匹配错误代码来同步PMA的时钟。当使用网络时间协议[RFC1305]或其他方法同步PMA时钟时，不需要此回复消息。请注意，将nonce用于排序和重播保护超出了本文档的范围。
The method above is sufficient when there is a single source for signaling as in the split PMA case. However, in the integrated PMA case, the Proxy Registration Request is sent from different sources (i.e., different PMAs). If the previous PMA is unaware that the mobile device has moved away and continues to send re-registration, then the HA would be misinformed on the location of the device. Therefore, an integrated PMA MUST confirm that the mobile device is still attached before sending a Proxy Registration Request.
当存在单一信号源时，如分割PMA情况，上述方法就足够了。但是，在集成PMA的情况下，代理注册请求是从不同的来源（即不同的PMA）发送的。如果先前的PMA不知道移动设备已经移开并继续发送重新注册，则HA将错误地获得设备位置的信息。因此，集成PMA必须在发送代理注册请求之前确认移动设备仍然连接。
Note that, for the split PMA model as used in WiMAX Forum (see Section 10), the PMIPv4 client remains anchored during handover (see Section 10.1). In this case, the PMIPv4 client is the only source of the PRRQ. However, there are cases (such as PMIPv4 client relocation and uncontrolled handover events) when more than one PMA performs registration. The same method for the integrated PMA is used to ensure proper sequencing of registration on the HA.
请注意，对于WiMAX论坛中使用的拆分PMA模型（参见第10节），PMIPv4客户端在切换期间保持锚定状态（参见第10.1节）。在这种情况下，PMIPv4客户端是PRRQ的唯一来源。但是，当多个PMA执行注册时，也存在一些情况（例如PMIPv4客户端重新定位和不受控制的切换事件）。为确保在医管局注册的先后次序正确，综合物业管理协议亦采用同样的方法。
Typically, the mobile device's interface needs to be configured with an IP address, network prefix, default gateway, and DNS server addresses before the network connection can be enabled to be used for communication. For some IP stacks, the default gateway IP address has to be on the same subnet as the mobile device's IP address. When the Home Agent's IP address is not on the same subnet as the Home Address, vendor-specific extensions (e.g., [RFC4332]) or other methods MAY be used by the PMA to obtain the default gateway.
通常，移动设备的接口需要配置IP地址、网络前缀、默认网关和DNS服务器地址，然后才能启用网络连接以用于通信。对于某些IP堆栈，默认网关IP地址必须与移动设备的IP地址位于同一子网上。当归属代理的IP地址与归属地址不在同一子网上时，PMA可使用特定于供应商的扩展（例如，[RFC4332]）或其他方法来获取默认网关。
The PMA can perform dynamic HA discovery by sending the registration with Home Agent field set to 0.0.0.0 or 255.255.255.255. The Home Agent responds with its IP address in the Home Agent field as specified in "Mobile IPv4 Dynamic Home Agent (HA) Assignment" [RFC4433].
PMA可以通过发送设置为0.0.0.0或255.255.255.255的注册归属代理字段来执行动态HA发现。归属代理在“移动IPv4动态归属代理（HA）分配”[RFC4433]中指定的归属代理字段中使用其IP地址进行响应。
The following PMIPv4 extensions are not required for base functionality but may be used in some cases where such features are applicable. They are included before the authentication extension (e.g., MN-HA or FA-HA Authentication extension) in the registration message.
基本功能不需要以下PMIPv4扩展，但在某些情况下可以使用这些功能。它们包含在注册消息中的身份验证扩展（例如，MN-HA或FA-HA身份验证扩展）之前。
The Proxy Mobile IPv4 Authentication Method extension indicates alternative methods for authenticating the registration besides the default MN-HA Authentication extension as specified in RFC 3344. This extension MUST be included in the Registration Request and Registration Reply when the security association for authenticating the message is between the PMA and HA on a per-node basis. This means that a common key or set of keys (indexed by the SPI) are used for message authentication by the PMA and HA. The key is independent of the mobile device, which is identified in the registration.
代理移动IPv4身份验证方法扩展指示除了RFC 3344中指定的默认MN-HA身份验证扩展之外，用于验证注册的其他方法。当用于验证消息的安全关联基于每个节点在PMA和HA之间时，此扩展必须包含在注册请求和注册回复中。这意味着公共密钥或密钥集（由SPI索引）用于PMA和HA的消息身份验证。密钥独立于在注册中识别的移动设备。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Method |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Method |
+-+-+-+-+-+-+-+-+
PMIPv4 Per-Node Authentication Method Extension
PMIPv4每节点身份验证方法扩展
Type
类型
47 (Proxy Mobile IPv4 Non-Skippable Extension)
47（代理移动IPv4不可跳过扩展）
Sub-Type
子类型
1 (PMIPv4 Per-Node Authentication Method)
1（PMIPv4每节点身份验证方法）
Length
长
1
1.
Method
方法
An 8-bit field that specifies the authentication type for protecting the signaling messages.
一个8位字段，指定用于保护信令消息的身份验证类型。
The values (0 - 255) are allocated and managed by IANA. The following values have been assigned to the specified method types.
值（0-255）由IANA分配和管理。以下值已分配给指定的方法类型。
0: Reserved
0:保留
1: FA-HA Authentication
1:FA-HA认证
2: IPsec Authentication
2:IPsec身份验证
The Proxy Mobile IPv4 Interface ID extension identifies the interface address of the device used to attach to the network. The information MAY be included in the Registration Request when the PMA is aware of it.
代理移动IPv4接口ID扩展标识用于连接到网络的设备的接口地址。当PMA意识到该信息时，该信息可能会包含在注册请求中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Interface ID Extension
PMIPv4接口ID扩展
Type
类型
147 (Proxy Mobile IPv4 Skippable Extension)
147（代理移动IPv4可跳过扩展）
Length
长
The length of the extension in octets, excluding Type and Length fields.
扩展名的长度（以八位字节为单位），不包括类型和长度字段。
Sub-Type
子类型
1 (PMIPv4 Interface ID)
1（PMIPv4接口ID）
Identifier
标识符
A variable-length octet sequence that contains an identifier of the interface.
包含接口标识符的可变长度八位字节序列。
The Proxy Mobile IPv4 Device ID extension identifies the device used to connect to the network. The information MAY be included in the Registration Request when the PMA is aware of it.
代理移动IPv4设备ID扩展标识用于连接到网络的设备。当PMA意识到该信息时，该信息可能会包含在注册请求中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Device ID Extension
PMIPv4设备ID扩展
Type
类型
147 (Proxy Mobile IPv4 Skippable Extension)
147（代理移动IPv4可跳过扩展）
Length
长
The length of the extension in octets, excluding Type and Length fields.
扩展名的长度（以八位字节为单位），不包括类型和长度字段。
Sub-Type
子类型
2 (PMIPv4 Device ID)
2（PMIPv4设备ID）
ID-Type
ID类型
An 8-bit field that specifies the device ID type.
指定设备ID类型的8位字段。
The values (0 - 255) are allocated and managed by IANA. The following values have been assigned to the specified device ID types.
值（0-255）由IANA分配和管理。以下值已分配给指定的设备ID类型。
0: Reserved
0:保留
1: Ethernet MAC address
1：以太网MAC地址
2: Mobile Equipment Identifier (MEID)
2：移动设备标识符（MEID）
3: International Mobile Equipment Identity (IMEI)
3：国际移动设备标识（IMEI）
4: Electronic Serial Number (ESN)
4：电子序列号（ESN）
Identifier
标识符
A variable-length octet sequence that contains an identifier of the type indicated by the ID-Type field.
一种可变长度的八位字节序列，包含ID type字段所指示类型的标识符。
The Proxy Mobile IPv4 Subscriber ID extension identifies the mobile subscription. The information MAY be included in the Registration Request when the PMA is aware of it.
代理移动IPv4订户ID扩展标识移动订阅。当PMA意识到该信息时，该信息可能会包含在注册请求中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Subscriber ID Extension
PMIPv4用户ID扩展
Type
类型
147 (Proxy Mobile IPv4 Skippable Extension)
147（代理移动IPv4可跳过扩展）
Length
长
The length of the extension in octets, excluding Type and Length fields.
扩展名的长度（以八位字节为单位），不包括类型和长度字段。
Sub-Type
子类型
3 (PMIPv4 Subscriber ID)
3（PMIPv4用户ID）
ID-Type
ID类型
An 8-bit field that specifies the subscriber ID type.
指定订阅服务器ID类型的8位字段。
The values (0 - 255) are allocated and managed by IANA. The following values have been assigned to the specified subscriber ID types.
值（0-255）由IANA分配和管理。以下值已分配给指定的订阅服务器ID类型。
0: Reserved
0:保留
1: International Mobile Subscriber Identity (IMSI)
1：国际移动用户标识（IMSI）
Identifier
标识符
A variable-length octet sequence that contains an identifier of the type indicated by the ID-Type field.
一种可变长度的八位字节序列，包含ID type字段所指示类型的标识符。
The Proxy Mobile IPv4 Access Technology Type extension indicates the type of radio-access technology on which the mobile device is attached. This extension MAY be included in the Registration Request when the PMA is aware of the information. The HA can provide mobility on the same access technology type for a mobile device with
代理移动IPv4接入技术类型扩展指示移动设备所连接的无线接入技术的类型。当PMA知道该信息时，该扩展可包括在注册请求中。HA可以为具有相同接入技术类型的移动设备提供移动性
multiple interfaces, assuming each interface is connected on a different access technology type. The HA does not include the extension in the associated Registration Reply.
多个接口，假设每个接口连接在不同的访问技术类型上。医管局在有关的注册答覆中并没有包括有关的延期。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Tech-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Tech-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Access Technology Type Extension
PMIPv4接入技术类型扩展
Type
类型
147 (Proxy Mobile IPv4 Skippable Extension)
147（代理移动IPv4可跳过扩展）
Length
长
2
2.
Sub-Type
子类型
4 (Access Technology Type)
4（接入技术类型）
Tech-Type
技术类型
An 8-bit field that specifies the access technology through which the mobile device is connected to the access network.
一个8位字段，指定移动设备通过其连接到接入网络的接入技术。
The values (0 - 255) are allocated and managed by IANA. The following values have been assigned to the specified access technology types.
值（0-255）由IANA分配和管理。以下值已分配给指定的访问技术类型。
0: Reserved
0:保留
1: 802.3
1: 802.3
2: 802.11a/b/g
2: 802.11a/b/g
3: 802.16e
3:802.16e
4: 802.16m
4:802.16m
5: 3GPP EUTRAN/LTE
5:3GPP EUTRAN/LTE
6: 3GPP UTRAN/GERAN
6:3GPP UTRAN/GERAN
7: 3GPP2 1xRTT/HRPD
7:3GPP2 1xRTT/HRPD
8: 3GPP2 UMB
8:3GPP2 UMB
Since the Mobile Node is not aware of its mobility and does not participate in handover signaling, the network entities emulate the home network to the mobile device attached on the network. From the mobile device's perspective, it operates as if it were at the home network. However, the network is directing the mobile device's traffic to and from its current location and will continue to do so when it moves to a new location.
由于移动节点不知道其移动性并且不参与切换信令，因此网络实体向连接在网络上的移动设备模拟归属网络。从移动设备的角度来看，它就像在家庭网络中一样工作。然而，网络正在引导移动设备的流量往返于其当前位置，并且在移动到新位置时将继续这样做。
An unmodified mobile device on a shared link learns the MAC address of another host on the home network via ARP ([RFCARP]), obtains an IP address and other host configuration via DHCP ([RFC2131]), and sends link-local multicast and broadcast packets. The network's response to the host is equivalent to the situation when a host is on the home network. When the link state changes, some hosts use ARP, ICMP, and/or DHCP to detect if it has changed the point of attachment on the network.
共享链路上未经修改的移动设备通过ARP（[RFCARP]）学习家庭网络上另一主机的MAC地址，通过DHCP（[RFC2131]）获得IP地址和其他主机配置，并发送链路本地多播和广播分组。网络对主机的响应相当于主机在家庭网络上的情况。当链路状态改变时，一些主机使用ARP、ICMP和/或DHCP来检测它是否改变了网络上的连接点。
For IEEE 802 type of access networks (e.g., WLAN, WiMAX Ethernet Convergence Sublayer), the mobile device sends ARP requests for the Corresponding Node (CN) and default gateway on the same network. The purpose of maintaining an ARP entry is to allow the delivery of the packet from the mobile device to the CN using the destination MAC address. The ARP procedure for resolving IP and MAC address mapping is not needed for 3GPP2's cdma2000 and WiMAX IP Convergence Sublayer networks.
对于IEEE 802类型的接入网络（例如，WLAN、WiMAX以太网融合子层），移动设备向同一网络上的相应节点（CN）和默认网关发送ARP请求。维护ARP条目的目的是允许使用目的地MAC地址将分组从移动设备传送到CN。3GPP2的cdma2000和WiMAX IP汇聚子层网络不需要解析IP和MAC地址映射的ARP过程。
The access router is always the L2 endpoint for the mobile device. The destination MAC address in the packet does not need to be set to the CN's MAC address. As long as the packet can be received by the access router, it will be forwarded toward the CN via the home network node (further details in Section 4.2.1). The ARP table in the mobile device does not need to be populated with CNs' MAC addresses in order for the packet to reach the CNs.
接入路由器始终是移动设备的L2端点。分组中的目的地MAC地址不需要设置为CN的MAC地址。只要接入路由器能够接收到数据包，它就会通过家庭网络节点转发到CN（更多详情见第4.2.1节）。为了使数据包到达CNs，移动设备中的ARP表不需要填充CNs的MAC地址。
A mobile device has ARP entries for the default gateway and hosts on the same subnet. Regardless of what the MAC addresses are, the AR receives the packets sent from the mobile device.
移动设备具有默认网关和同一子网上主机的ARP条目。无论MAC地址是什么，AR都会接收从移动设备发送的数据包。
For movement detection, certain types of network stack on the mobile device will send an ICMP request [RFCICMP] to the default gateway after detecting the link went down and up. The IP TTL in the message is set to 1 to check if the default gateway is still directly reachable on the access network. The PMA MAY send an ICMP reply when it is providing Proxy Mobile IPv4 service for the mobile device. This response confirms to the mobile device that it has remained on the home network after link state change. This behavior is observed on existing client implementation. "Detecting Network Attachment in IPv4 (DNAv4)" [RFC4436] can be employed.
对于移动检测，移动设备上的某些类型的网络堆栈将在检测到链路上下移动后向默认网关发送ICMP请求[RFCICMP]。消息中的IP TTL设置为1，以检查默认网关是否仍然可以在访问网络上直接访问。当PMA为移动设备提供代理移动IPv4服务时，PMA可以发送ICMP应答。该响应向移动设备确认其在链路状态改变后仍保持在家庭网络上。在现有的客户端实现上可以观察到这种行为。可以使用“检测IPv4（DNAv4）中的网络连接”[RFC4436]。
General ICMP traffic is handled as normal IP packets and tunneled between the PMA and HA.
一般ICMP流量作为正常IP数据包进行处理，并在PMA和HA之间进行隧道传输。
DHCP [RFC2131] is used to obtain an IP address and other host configuration parameters for a mobile device. The mobile device is expected to behave as a normal DHCP client when connected to the network with Proxy Mobile IPv4 service. There are two DHCP phases: bootup and renewal/release. The bootup procedure relies on the DHCP relay agent to obtain a lease on the IP address for the DHCP client from the DHCP server. The DHCP client directly renews and releases the lease with the DHCP server.
DHCP[RFC2131]用于获取移动设备的IP地址和其他主机配置参数。当使用代理移动IPv4服务连接到网络时，移动设备应表现为普通DHCP客户端。DHCP有两个阶段：启动和更新/释放。启动过程依赖DHCP中继代理从DHCP服务器获取DHCP客户端IP地址的租约。DHCP客户端直接与DHCP服务器续订和释放租约。
In Proxy Mobile IPv4, the mobile device boots up on a network that is not the home network associated with the leased IP address. Also, the mobile device can move to other networks that are not related to that IP address. Yet, the DHCP client on the mobile device continues to operate as a stationary device that is directly on the network associated with its IP address. The PMA and HA create the transparency of the remote home network and mobility events by providing the expected network response to the DHCP client.
在代理移动IPv4中，移动设备在与租用IP地址关联的家庭网络之外的网络上启动。此外，移动设备可以移动到与该IP地址无关的其他网络。然而，移动设备上的DHCP客户端继续作为固定设备运行，该设备直接位于与其IP地址相关联的网络上。PMA和HA通过向DHCP客户端提供预期的网络响应来创建远程家庭网络和移动事件的透明度。
There are several methods for the network infrastructure to interface with the mobile device such that the mobile device believes it is always fixed on the same network. The following methods are identified here, though others may be used as well.
网络基础设施与移动设备接口有几种方法，以便移动设备相信它始终固定在同一网络上。此处确定了以下方法，但也可以使用其他方法。
DHCP Server in the AR:
AR中的DHCP服务器：
The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the AR. When the mobile device is on a different AR than the AR/DHCP server, the DHCP message from the client needs to be able to either be forwarded to
移动设备启动并启动DHCP。该过程如图1所示。DHCP客户端直接与AR中的DHCP服务器续订或释放IP地址。当移动设备位于不同于AR/DHCP服务器的AR上时，来自客户端的DHCP消息需要能够转发到
the DHCP server in the previous AR or handled by the DHCP server in the new AR. When the DHCP lease time expires for the mobile device's IP address or the DHCP release message is received on the current AR, the AR sends PMIPv4 de-registration to the HA.
前一AR中的DHCP服务器或由新AR中的DHCP服务器处理。当移动设备IP地址的DHCP租用时间到期或在当前AR上收到DHCP释放消息时，AR向HA发送PMIPv4取消注册。
DHCP Relay Agent in the AR:
AR中的DHCP中继代理：
The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the HA. When the mobile device is on a different AR, DHCP messages from the client are relayed to the DHCP server in the HA. When the DHCP lease time expires for the mobile device's IP address or the DHCP release message is received on the HA, the HA deletes the mobility binding entry for the mobile device and sends registration revocation [RFC3543] to the AR.
移动设备启动并启动DHCP。该过程如图1所示。DHCP客户端直接与HA中的DHCP服务器续订或释放IP地址。当移动设备位于不同的AR上时，来自客户端的DHCP消息将中继到HA中的DHCP服务器。当移动设备的IP地址的DHCP租用时间到期或在HA上接收到DHCP释放消息时，HA删除移动设备的移动绑定条目，并向AR发送注册撤销[RFC3543]。
When the mobile device accesses the network via PPP [RFC1661], LCP (Link Control Protocol) CHAP is used to authenticate the user. After authentication, the NAS (which is the AR/PMA) sends the Proxy Mobile IPv4 Registration Request to the HA. The HA responds with the Home Address in the Proxy Registration Reply. The NAS informs the mobile device to use the Home Address during IPCP [RFC1332]. When the mobile device moves to a new NAS, the same procedure happens and that mobile device has the same IP address for communication.
当移动设备通过PPP[RFC1661]访问网络时，使用LCP（链路控制协议）CHAP对用户进行身份验证。认证后，NAS（即AR/PMA）向HA发送代理移动IPv4注册请求。医管局在代理注册回复中回复家庭地址。NAS通知移动设备在IPCP[RFC1332]期间使用家庭地址。当移动设备移动到新的NAS时，会发生相同的过程，并且该移动设备具有相同的通信IP地址。
The message exchange is illustrated in Figure 1.
消息交换如图1所示。
Depending on configuration policies, the PMA may tunnel all packets destined to Link-Local Multicast or Broadcast to the HA. The HA looks up the hosts that are in the same subnet and sends a duplicated packet to each of them.
根据配置策略，PMA可以通过隧道传输所有目的地为链接本地多播或广播到HA的分组。HA查找位于同一子网中的主机，并向每个主机发送重复的数据包。
The PMA performs the functions of a Mobile Node entity as described in RFC 3344, with the exceptions identified below.
PMA执行RFC 3344中所述的移动节点实体的功能，以下识别的例外情况除外。
- No agent discovery (i.e., agent solicitation and advertisement) is supported.
- 不支持代理发现（即代理征集和广告）。
- The D-bit (De-encapsulation by MN) in the Registration Request is always set to zero.
- 注册请求中的D位（MN解除封装）始终设置为零。
The main responsibility of the PMA is to set up and maintain the routing path between itself and the HA for a mobile device that is attached on the network. When it detects a mobile device is no longer attached, the routing path is torn down. It is possible that the PMA functions may be split up in implementations such as WiMAX (Section 10).
PMA的主要职责是为连接在网络上的移动设备设置和维护其自身与HA之间的路由路径。当它检测到移动设备不再连接时，路由路径被拆除。PMA功能可能在WiMAX等实现中被拆分（第10节）。
The PMA needs to know the following information, at a minimum, for sending a proxy registration:
PMA至少需要知道以下信息才能发送代理注册：
1. NAI of the mobile device.
1. 移动设备的NAI。
2. MN-HA security association, when per-mobile device security association is used.
2. MN-HA安全关联，当使用每移动设备安全关联时。
3. FA-HA Mobility security association or IPsec security association when per-node security association is used. Note that these associations are specific only between PMA and HA, and are cryptographically unrelated to the associations between the MN and other network nodes.
3. 使用每节点安全关联时，FA-HA移动安全关联或IPsec安全关联。请注意，这些关联仅在PMA和HA之间是特定的，并且在加密方面与MN和其他网络节点之间的关联无关。
4. HA Address.
4. HA地址。
This information is typically downloaded from the AAA server during access authentication.
此信息通常在访问身份验证期间从AAA服务器下载。
The Home Agent has the functionality described in RFC 3344 [RFC3344]. In addition, the following features are introduced by Proxy Mobile IPv4:
归属代理具有RFC 3344[RFC3344]中描述的功能。此外，代理移动IPv4还引入了以下功能：
1. Sequencing between PRRQs from multiple PMAs. For the integrated PMA case, there is a period after handover that may result in both the new PMA and old PMA sending PRRQs. It is imperative that the old PMA confirm that the mobile device is attached before sending a PRRQ when the re-registration timer expires. This would ensure that the HA only receives registration from the PMA that is serving the mobile device.
1. 来自多个PMA的PRRQ之间的测序。对于综合PMA案例，移交后的一段时间可能会导致新PMA和旧PMA发送PRRQ。当重新注册计时器过期时，在发送PRRQ之前，旧PMA必须确认移动设备已连接。这将确保医管局只收到为移动设备提供服务的便携式维修辅助设备的注册。
2. Authentication of PRRQs based on per-node security associations (FA-HA AE or IPsec AH/ESP) is applicable in the integrated PMA case. The presence of MN-HA AE or MN-AAA AE in the PRRQ is not necessary in this case. Since PMIPv4 is based on signaling between the PMA and the HA, the security for the message can be authenticated based on the peers' relationship. The HA can authorize PMIPv4 service for the mobile device at the PMA by contacting the AAA server.
2. 基于每个节点安全关联（FA-HA AE或IPsec AH/ESP）的PRRQ认证适用于集成PMA案例。在这种情况下，PRRQ中不必存在MN-HA AE或MN-AAA AE。由于PMIPv4基于PMA和HA之间的信令，因此可以基于对等方的关系来验证消息的安全性。HA可以通过联系AAA服务器为PMA处的移动设备授权PMIPv4服务。
3. The ability to process the Proxy Mobile IPv4 extensions defined in this document for enhanced capabilities of PMIPv4.
3. 处理本文档中定义的代理移动IPv4扩展以增强PMIPv4功能的能力。
When a Proxy Registration Request is received, the HA looks up the mobility binding entry indexed by the NAI. If the entry exists, HA compares the sequence numbers between the message and mobility binding entry (MBE), if present. If the value in the message is zero or greater than or equal to the one in the MBE, HA accepts the registration. The HA replies with a sequence number that is one greater than the larger value of either the MBE or Proxy Registration Request. If the registration is denied, then HA sends error code "Administratively prohibited (65)". If the HA is not enabled with Proxy Mobile IPv4 or cannot process the Proxy Mobile IPv4 Extensions defined in this document, it sends a Registration Reply with error code PMIP_UNSUPPORTED ("Proxy Registration not supported by the HA"). In the case when the PMA is not allowed to send a Proxy Registration Request to the HA, the HA sends a Proxy Registration Reply with error code PMIP_DISALLOWED ("Proxy Registrations from this PMA are not allowed").
当收到代理注册请求时，HA查找NAI索引的移动绑定条目。如果条目存在，HA将比较消息和移动绑定条目（MBE）（如果存在）之间的序列号。如果消息中的值为零或大于或等于MBE中的值，HA接受注册。HA回复的序列号比MBE或代理注册请求的较大值大一个。如果注册被拒绝，HA将发送错误代码“行政禁止（65）”。如果HA未启用代理移动IPv4或无法处理本文档中定义的代理移动IPv4扩展，则会发送一个注册回复，错误代码为PMIP_UNSUPPORTED（“HA不支持代理注册”）。如果不允许PMA向医管局发送代理注册请求，医管局将发送一份代理注册回复，错误代码为PMIP_DISALLOWED（“不允许来自该PMA的代理注册”）。
A PMA receiving these error codes SHOULD NOT retry sending Proxy Mobile IPv4 messages to the HA that sent replies with these error codes.
接收到这些错误代码的PMA不应尝试将代理移动IPv4消息发送给使用这些错误代码发送回复的HA。
As per this specification, a mobile device would function as a normal IPv4 host. The required behavior of the node will be consistent with the base IPv4 specification [RFC0791]. The mobile station will have the ability to retain its IPv4 address as it moves from one point of network attachment to the other without ever requiring it to participate in any mobility-related signaling.
根据此规范，移动设备将作为普通IPv4主机运行。节点所需的行为将与基本IPv4规范[RFC0791]一致。当移动站从一个网络连接点移动到另一个网络连接点时，移动站将能够保留其IPv4地址，而无需参与任何与移动相关的信令。
When booting up for the first time, a mobile device obtains an IPv4 address using DHCP or IPCP.
首次启动时，移动设备使用DHCP或IPCP获得IPv4地址。
As the mobile device roams, it is always able to communicate using the obtained IP address on the home network. The PMA on the currently attached network signals to the HA to ensure a proper forwarding path for the mobile device's traffic.
当移动设备漫游时，它总是能够使用家庭网络上获得的IP地址进行通信。当前连接的网络上的PMA向HA发送信号，以确保移动设备流量的正确转发路径。
When the mobile device accesses the network for the first time and attaches to a network on the PMA, it will present its identity in the form of an NAI to the network as part of the network-access authentication process.
当移动设备首次接入网络并连接到PMA上的网络时，作为网络接入认证过程的一部分，它将以NAI的形式向网络呈现其身份。
Once the address configuration is complete, the mobile device will always be able to use that IP address anywhere in the network.
一旦地址配置完成，移动设备将始终能够在网络中的任何位置使用该IP地址。
When a mobile device moves to a new PMA from another PMA, the following occurs:
当移动设备从另一个PMA移动到新的PMA时，会发生以下情况：
The mobile device may perform a network-access authentication with the new AR/PMA. If the authentication fails, the mobile device will not be able to use the link. After a successful authentication, the new PMA will have the identifier and the other profile data of the mobile device. The new PMA can also obtain the mobile device's information using a context-transfer mechanism, which is out of the scope of this document.
移动设备可以使用新的AR/PMA执行网络接入认证。如果身份验证失败，移动设备将无法使用该链接。成功认证后，新PMA将具有移动设备的标识符和其他配置文件数据。新的PMA还可以使用上下文传输机制获取移动设备的信息，这超出了本文的范围。
Once the network-access authentication process is complete, the mobile device may sense a change in the Link Layer and use ARP, DHCP, and/or ICMP to detect if it is still on the same subnet. These mechanisms are handled by the network as described in "Appearance of Being At Home Network" (Section 6).
一旦网络接入认证过程完成，移动设备可感测链路层中的变化，并使用ARP、DHCP和/或ICMP来检测其是否仍在同一子网上。这些机制由网络处理，如“家庭网络的外观”（第6节）所述。
All packets that are to be sent from the mobile device to the Corresponding Node (CN) will be sent as normal IPv4 packets, setting the Source Address of the IPv4 header to the Home Address and the Destination Address to the Corresponding Node's IP address. In Proxy Mobile IPv4 operation, the default gateway for the mobile device is set up to reach the PMA.
将从移动设备发送到相应节点（CN）的所有数据包将作为正常IPv4数据包发送，将IPv4报头的源地址设置为家庭地址，将目标地址设置为相应节点的IP地址。在代理移动IPv4操作中，移动设备的默认网关设置为访问PMA。
Similarly, all packets sent to the mobile device's IP address by the Corresponding Node will be received by the mobile device in the original form (without any tunneling overhead).
类似地，由相应节点发送到移动设备的IP地址的所有分组将由移动设备以原始形式接收（没有任何隧道开销）。
For Proxy Mobile IP, the packet from the mobile device is transported to the HA to reach the destination, regardless of the destination IP address. For a CN with an IP address on the same network as the mobile device but that is physically located elsewhere, the HA will tunnel the packet to the CN. Otherwise, the HA forwards the traffic via normal routing.
对于代理移动IP，来自移动设备的数据包被传输到HA以到达目的地，而与目的地IP地址无关。对于IP地址与移动设备在同一网络上但物理上位于别处的CN，HA将通过隧道将数据包传输到CN。否则，HA通过正常路由转发流量。
No special operation is required by the mobile device to either send or receive packets.
移动设备不需要特殊操作来发送或接收数据包。
Mobile devices attached to the same PMA may be using different HAs for transporting their traffic.
连接到同一PMA的移动设备可能使用不同的HAs来传输其流量。
WiMAX Forum Network Working Group (NWG) uses the Proxy Mobile IPv4 scheme to provide IPv4 connectivity and IP mobility. The relevant specification from WiMAX Forum is [NWG].
WiMAX论坛网络工作组（NWG）使用代理移动IPv4方案提供IPv4连接和IP移动性。WiMAX论坛的相关规范是[NWG]。
The Proxy Mobile IPv4 protocol is used over NWG reference point 3 (R3). Most of the Proxy Mobile IPv4 related procedures and requirements are described in reference to mobility management over R3.
代理移动IPv4协议在NWG参考点3（R3）上使用。大多数与代理移动IPv4相关的过程和要求都参考了R3上的移动性管理。
The Proxy Mobile IPv4 use case in the WiMAX Forum specification is illustrated in the following diagram:
WiMAX论坛规范中的代理移动IPv4用例如下图所示：
|
| CSN
|
|
+-------+ | +-------+
| | | | |
|AAAV |--------------|------------| AAAH |
| | | | |
| | | | |
+-------+ | +-------+
| | |
| | |
| | |
+------------------+ | |
| +-------+ | | |
| | NAS | | | |
| | PMIP | ASN1 | | |
| | Client| | | |
| +-------+ | | |
| | | | |
| | R4 | | |
| +-------+ | | +------+
+----+ | | FA, | | | PMIPv4 | |
| MN |-------| DHCP |---------------------------| HA |
+----+ | | Relay/| | | R3 | |
| | Server| ASN2 | | +------+
| +-------+ | |
| | |
+------------------+
Split PMA
|
| CSN
|
|
+-------+ | +-------+
| | | | |
|AAAV |--------------|------------| AAAH |
| | | | |
| | | | |
+-------+ | +-------+
| | |
| | |
| | |
+------------------+ | |
| +-------+ | | |
| | NAS | | | |
| | PMIP | ASN1 | | |
| | Client| | | |
| +-------+ | | |
| | | | |
| | R4 | | |
| +-------+ | | +------+
+----+ | | FA, | | | PMIPv4 | |
| MN |-------| DHCP |---------------------------| HA |
+----+ | | Relay/| | | R3 | |
| | Server| ASN2 | | +------+
| +-------+ | |
| | |
+------------------+
Split PMA
Figure 5: WiMAX NWG Network Configuration for PMIPv4 Use
图5:PMIPv4使用的WiMAX NWG网络配置
As shown in the figure above, WiMAX NWG uses the split PMA model. The PMIPv4 client is collocated with the NAS in ASN1 (aka, Authenticator ASN). The NWG architecture divides the network into two parts. The Access part is termed the "Access Service Network" (ASN). The Core part is termed the "Connectivity Service Network" (CSN). The MN attaches to an 802.16 radio in the ASN2 (aka, Anchor Data Path Function). The radio (base station) connects to the Anchor Data Path Function (A_DPF) in ASN2, which in turn connects to the Authenticator ASN (NAS) in ASN1. ASN1 authenticates and authorizes the MN. The AAA infrastructure is used to authenticate and authorize the MN.
如上图所示，WiMAX NWG使用拆分PMA模型。PMIPv4客户端与ASN1中的NAS（也称为身份验证器ASN）并置。NWG架构将网络分为两部分。接入部分被称为“接入服务网络”（ASN）。核心部分被称为“连接服务网络”（CSN）。MN连接到ASN2中的802.16无线电（也称为锚定数据路径功能）。无线电（基站）连接到ASN2中的锚数据路径功能（A_DPF），该功能又连接到ASN1中的认证器ASN（NAS）。ASN1认证和授权MN。AAA基础设施用于对MN进行身份验证和授权。
Note that, during initial network entry by the MN, the PMA can be an integrated PMA with all the functions collocated in ASN1. Due to mobility, the FA part of the PMA may have to be relocated to a more
注意，在MN初始进入网络期间，PMA可以是一个集成的PMA，所有功能都配置在ASN1中。由于机动性的原因，PMA的固定资产部分可能必须重新安置到更高的位置
optimized location for better bearer management. However, to describe the WiMAX specific use case for Proxy Mobile IPv4, we will use the split PMA model since it is a more generic representation of the WiMAX NWG mobility framework.
优化位置以实现更好的承载管理。然而，为了描述代理移动IPv4的WiMAX特定用例，我们将使用分割PMA模型，因为它是WiMAX NWG移动框架的更通用表示。
The WiMAX NWG specification [NWG] defines a key bootstrapping scheme for use with Proxy Mobile IPv4. The specification uses per-MN security association for Proxy Mobile IPv4 operation. The relevant keys (e.g., MN-HA key) are derived using EAP authentication as specified in this document. For more information, please refer to Section 4.3 of [NWG], stage-3 specification.
WiMAX NWG规范[NWG]定义了一个密钥引导方案，用于代理移动IPv4。该规范将每MN安全关联用于代理移动IPv4操作。相关密钥（如MN-HA密钥）是使用本文档中规定的EAP身份验证派生的。有关更多信息，请参考[NWG]第3阶段规范第4.3节。
Mobile IPv4 Registration Revocation is optionally supported in WiMAX. The security association for this is per node. It is provided with FA-HA AE. The FA-HA key is also bootstrapped via the same key hierarchy that is described in Section 4.3 of [NWG].
WiMAX可选地支持移动IPv4注册撤销。此节点的安全关联为每个节点。它配备了FA-HA AE。FA-HA密钥也通过[NWG]第4.3节中描述的相同密钥层次结构进行引导。
The Proxy Mobile IPv4 operation in WiMAX NWG is aligned with the basic Proxy Mobile IPv4 operation as described in Section 4 of this document. There are specific considerations for WiMAX NWG 1.0.0 use of Proxy Mobile IPv4. These are listed below:
WiMAX NWG中的代理移动IPv4操作与本文档第4节中描述的基本代理移动IPv4操作一致。WiMAX NWG 1.0.0使用代理移动IPv4有一些具体的考虑因素。这些措施如下：
1. Use of per-MS SA for Proxy Mobile IPv4 registration. In this case, MN-HA AE is used.
1. 使用per MS SA进行代理移动IPv4注册。在这种情况下，使用MN-HA AE。
2. Use of split PMA to handle FA relocation while the PMIPv4 client remains anchored with the NAS (Authenticator ASN).
2. 使用拆分PMA处理FA重新定位，同时PMIPv4客户端保持与NAS（验证器ASN）的锚定。
3. Only the Proxy Mobile IPv4 Access Technology Type extension defined in this document is used in the NWG specification [NWG].
3. NWG规范[NWG]中仅使用本文档中定义的代理移动IPv4访问技术类型扩展。
4. GRE key identifier is optionally used between the HA and the PMA.
4. 在HA和PMA之间选择性地使用GRE密钥标识符。
5. The PMIPv4 client and the FA interact via the WiMAX specific reference point and protocol (aka, R4). For more information, please refer to the NWG specification [NWG].
5. PMIPv4客户端和FA通过WiMAX特定的参考点和协议（aka，R4）进行交互。有关更多信息，请参阅NWG规范[NWG]。
6. In order to handle inter-ASN (inter Access Router) handover and still allow the MN to use the same DHCP server's IP address that was sent in DHCPOFFER/ACK, the DHCP server (aka, proxy) functions in the ASN are required to be configured with the same IP address.
6. 为了处理内部ASN（内部访问路由器）切换，并且仍然允许MN使用在DHCPOFFER/ACK中发送的相同DHCP服务器的IP地址，需要使用相同的IP地址配置ASN中的DHCP服务器（aka，代理）功能。
7. The MN - AR (trigger for Proxy Mobile IPv4) interaction is based on DHCP. DHCPDISCOVER from the MN triggers the Proxy Mobile IPv4 process in the ASN.
7. MN-AR（代理移动IPv4的触发器）交互基于DHCP。来自MN的DHCPDISCOVER触发ASN中的代理移动IPv4进程。
Since WiMAX uses the split PMA model, the call flows involve WiMAX proprietary signaling between the PMIPv4 client and FA within the PMA. The following call flows illustrate this.
由于WiMAX使用分割PMA模型，因此呼叫流涉及PMIPv4客户端和PMA内FA之间的WiMAX专有信令。下面的调用流说明了这一点。
Split PMA
+-----------------------------------+
+----+ | +------+ +------+ +-----+ | +-----+
| | | | NAS/ | | Old | | New | | | |
| MN | | | PMIP | | FA | | FA | | | HA |
| | | |Client| | | | | | | |
+----+ | +------+ +------+ +-----+ | +-----+
| +----|------------|------------|----+ |
| | | PMIP Tunnel |
| | |<=======================>|
| | | | |
| | | R4 tunnel | |
| | |<==========>| |
| | 1 | | |
|<---------------------------------->| |
| | | | |
| | | 2 | |
| | |<---------->| |
| | 3 | | |
| |<----------------------- | |
| | | | |
| | 4 | | |
+-> | |------------------------>| |
| | | | | 5 |
| | | | |----------->|
| | | | | |
PMIP | | | | | 6 |
| | | | |<-----------|
| | | | | |
| | | 7 | | |
+-> | |<------------------------| |
| | | | |
| | | 8 | |
| | |<---------->| |
| | | | |
| 9 | | |PMIP Tunnel |
Data |<---------------------------------->|<==========>|
Forwarding | | | | |
Split PMA
+-----------------------------------+
+----+ | +------+ +------+ +-----+ | +-----+
| | | | NAS/ | | Old | | New | | | |
| MN | | | PMIP | | FA | | FA | | | HA |
| | | |Client| | | | | | | |
+----+ | +------+ +------+ +-----+ | +-----+
| +----|------------|------------|----+ |
| | | PMIP Tunnel |
| | |<=======================>|
| | | | |
| | | R4 tunnel | |
| | |<==========>| |
| | 1 | | |
|<---------------------------------->| |
| | | | |
| | | 2 | |
| | |<---------->| |
| | 3 | | |
| |<----------------------- | |
| | | | |
| | 4 | | |
+-> | |------------------------>| |
| | | | | 5 |
| | | | |----------->|
| | | | | |
PMIP | | | | | 6 |
| | | | |<-----------|
| | | | | |
| | | 7 | | |
+-> | |<------------------------| |
| | | | |
| | | 8 | |
| | |<---------->| |
| | | | |
| 9 | | |PMIP Tunnel |
Data |<---------------------------------->|<==========>|
Forwarding | | | | |
Figure 6: Proxy Handover Operation in WiMAX with Split PMA
图6：使用拆分PMA的WiMAX中的代理切换操作
In this scenario, the MN has moved to a new FA's area (known as the Data Path Function in WiMAX). The old FA and the new FA interact with each other and also with the PMIPv4 client over a WiMAX-specified R4 reference point to perform the handover. The steps are described below:
在这种情况下，MN移动到了一个新的FA区域（在WiMAX中称为数据路径功能）。旧FA和新FA彼此交互，并且通过WiMAX指定的R4参考点与PMIPv4客户端交互，以执行切换。步骤如下所述：
1. The mobile device establishes a L2 link with a base station (not shown), which connects to a new FA (aka, new Data Path Function in WiMAX). Note that, in this case, the MN does not perform authentication and authorization. The PMIPv4 tunnel remains between the old FA (aka, old Data Path Function in WiMAX). The data flows through the PMIPv4 tunnel between the HA and the old FA, and through the WiMAX-specific R4 tunnel between the old FA and the new FA and from the new FA to the MN.
1. 移动设备与基站（未示出）建立L2链路，基站连接到新FA（也称为WiMAX中的新数据路径功能）。注意，在这种情况下，MN不执行身份验证和授权。PMIPv4隧道仍然位于旧FA（又称WiMAX中的旧数据路径函数）之间。数据通过HA和旧FA之间的PMIPv4隧道，以及旧FA和新FA之间的WiMAX特定R4隧道，并从新FA流向MN。
2. The new FA interacts with the old FA using a WiMAX-specific R4 reference point to initiate the handover process.
2. 新FA使用WiMAX特定的R4参考点与旧FA交互以启动切换过程。
3. The new FA uses the WiMAX-specific R4 reference point to request the PMIPv4 client to begin the PMIPv4 handover.
3. 新FA使用WiMAX特定的R4参考点请求PMIPv4客户端开始PMIPv4切换。
4. Triggered by step 3, the PMIPv4 client sends a PRRQ to the new FA. The PRRQ contains the FA-CoA of the new FA. The Home Address field is set to the address of the assigned IP address of the Mobile Node. The PRRQ is embedded in the WiMAX-specific R4 packet.
4. 由步骤3触发，PMIPv4客户端向新FA发送PRRQ。PRRQ包含新FA的FA CoA。归属地址字段设置为移动节点的分配IP地址的地址。PRRQ嵌入到WiMAX特定的R4数据包中。
5. The new FA forwards the PRRQ to the HA.
5. 新足总将PRRQ转发给医管局。
6. The Home Agent updates the existing mobility binding entry for the mobile device upon processing the PRRQ. The Home Agent responds back to the new FA with PRRP.
6. 归属代理在处理PRRQ时更新移动设备的现有移动绑定条目。主代理用PRRP回复新FA。
7. The new FA forwards the PRRP after encapsulating it in a WiMAX-specific R4 packet to the PMIPv4 client.
7. 新FA将PRRP封装在WiMAX特定R4数据包中后转发给PMIPv4客户端。
8. The new FA and the old FA exchange WiMAX-specific R4 messages between them to confirm the handover. The old FA cleans up its resources for the MN. The R4 bearer forwarding also stops at this point.
8. 新FA和旧FA之间交换特定于WiMAX的R4消息以确认切换。老FA为MN清理资源。R4承载转发也在此点停止。
9. The forward and reverse direction traffic flows via the new FA. The handover is complete at this point.
9. 正向和反向交通通过新FA流动。此时已完成移交。
3GPP2 uses the Proxy Mobile IPv4 scheme to provide mobility service for the following scenarios (as shown in the figures below):
3GPP2使用代理移动IPv4方案为以下场景提供移动服务（如下图所示）：
1. Mobility between the base station (BS) and access gateway (AGW)
1. 基站（BS）和接入网关（AGW）之间的移动性
2. Mobility between the AGW and the Home Agent (HA).
2. AGW和归属代理（HA）之间的移动性。
As shown in the diagrams below, in use case 1, the BS acts as the PMA and the AGW acts as the HA for Proxy Mobile IPv4 operation. In use case 2, the AGW acts as the PMA while the HA assumes the role of the Home Agent.
如下图所示，在用例1中，BS充当PMA，AGW充当代理移动IPv4操作的HA。在用例2中，AGW充当PMA，而HA充当Home Agent。
RAN Core
岩芯
+-------+ +------+
+----+ | BS/ | PMIPv4 | |
| MN |------| PMA |-----------------------| AGW/ |
+----+ | | | HA |
| | +------+
+-------+
+-------+ +------+
+----+ | BS/ | PMIPv4 | |
| MN |------| PMA |-----------------------| AGW/ |
+----+ | | | HA |
| | +------+
+-------+
Integrated PMA
集成PMA
Figure 7: 3GPP2's PMIPv4 Use Case 1 - BS-AGW Interface Mobility
图7:3GPP2的PMIPv4用例1-BS-AGW接口移动性
RAN Core
岩芯
+-------+ +------+
+----+ | AGW/ | PMIPv4 | |
| MN |------| PMA |-----------------------| HA |
+----+ | | | |
| | +------+
+-------+
+-------+ +------+
+----+ | AGW/ | PMIPv4 | |
| MN |------| PMA |-----------------------| HA |
+----+ | | | |
| | +------+
+-------+
Integrated PMA
集成PMA
Figure 8: 3GPP2's PMIPv4 Use Case 2 - AGW-HA Interface Mobility
图8:3GPP2的PMIPv4用例2-AGW-HA接口移动性
The figure below shows a simplified 3GPP2 architecture. For details, please refer to the 3GPP2 Converged Access Network (CAN) architecture ([3GPP2]).
下图显示了简化的3GPP2体系结构。有关详细信息，请参考3GPP2融合接入网络（CAN）架构（[3GPP2]）。
RAN Core
-----------^------------ -------^-------------
| | | |
V V V V
RAN Core
-----------^------------ -------^-------------
| | | |
V V V V
+------+ +------+ +-----+
+----+ | | PMIPv4 | | PMIPv4 | |
| MN |------| BS |------------| AGW |-----------| HA |
+----+ | | | | | |
+------+ +------+ +-----+
+------+ +------+ +-----+
+----+ | | PMIPv4 | | PMIPv4 | |
| MN |------| BS |------------| AGW |-----------| HA |
+----+ | | | | | |
+------+ +------+ +-----+
Figure 9: Simplified 3GPP2 Architecture
图9：简化的3GPP2体系结构
The Proxy Mobile IPv4 usage scenario in 3GPP2 (case 1) is illustrated in the following diagram:
3GPP2中的代理移动IPv4使用场景（情况1）如下图所示：
+----+ +-------+ +-------+ +------+
| | | | | | | |
| MN | | BS/ | | HAAA | | AGW/ |
| | | PMA | | | | HA |
+----+ +-------+ +-------+ +------+
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
|<======================================>|
| | | |
+----+ +-------+ +-------+ +------+
| | | | | | | |
| MN | | BS/ | | HAAA | | AGW/ |
| | | PMA | | | | HA |
+----+ +-------+ +-------+ +------+
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
|<======================================>|
| | | |
Figure 10: Network Connection Setup (use case 1)
图10：网络连接设置（用例1）
Description of the steps:
步骤说明：
1a. MN performs layer 2 establishment with the BS/PMA and performs access authentication/authorization. During this phase, the MN runs EAP over Ultra Mobile Broadband (UMB). The BS acts as the NAS in this phase.
1a。MN使用BS/PMA执行第2层建立，并执行访问认证/授权。在此阶段，MN通过超移动宽带（UMB）运行EAP。在此阶段，基站充当NAS。
1b. The BS exchanges AAA messages with the Home AAA server via the AR (not shown in the figure) to authenticate the MN. As part of this step, the AR may download some information about the MN (e.g., user's profile, handset type, assigned Home Agent address, and other capabilities of the MN). This information is passed to the PMA/BS (as necessary) to set up the PMIPv4 tunnel in the next step(s).
1b。BS通过AR（图中未显示）与家庭AAA服务器交换AAA消息以认证MN。作为该步骤的一部分，AR可以下载关于MN的一些信息（例如，用户的简档、手持设备类型、分配的归属代理地址以及MN的其他能力）。此信息将传递给PMA/BS（如有必要），以便在下一步中设置PMIPv4隧道。
2. The MN sends layer 2 signaling messages to the BS/PMA to trigger the PMIPv4 tunnel setup process.
2. MN向BS/PMA发送第2层信令消息以触发PMIPv4隧道设置过程。
3. Triggered by step 2, the PMA/BS sends a PRRQ to the AGW/HA. The HA's address is either received at step 1b from the Home AAA server (HAAA) or is discovered by other means. The PRRQ contains the Care-of Address (CoA) of the PMA (collocated FA in this case). The HoA field is set to all zeros (or all ones). The PRRQ is protected by the method described in this document. The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document.
3. 由步骤2触发，PMA/BS向AGW/HA发送PRRQ。HA的地址要么在步骤1b从家庭AAA服务器（HAAA）接收，要么通过其他方式发现。PRRQ包含PMA（本例中为并置FA）的转交地址（CoA）。HoA字段设置为全零（或全一）。PRRQ受本文件所述方法的保护。MN-HA或FA-HA密钥的派生和分发不在本文档的范围内。
4. The AGW/HA registers the MN's session, assigns a symmetric GRE key, and returns this key in the PRRP to the BS/PMA.
4. AGW/HA注册MN的会话，分配对称GRE密钥，并将PRRP中的该密钥返回给BS/PMA。
5. The BS/PMA responds back to the MN with a layer 2 signaling message.
5. BS/PMA使用第2层信令消息回复MN。
6. At this step, the MN is assigned an IP address and is connected to the network (via the AGW).
6. 在该步骤中，MN被分配一个IP地址并连接到网络（通过AGW）。
In use case 2, the same procedures are followed except the PMIPv4 tunnel is established between the AGW and the HA. In this case, GRE tunneling may not be used.
在用例2中，除了在AGW和HA之间建立PMIPv4隧道外，遵循相同的程序。在这种情况下，可能不使用GRE隧道。
There are some special handover considerations in 3GPP2's Proxy Mobile IPv4 use case. Below is an illustration of the specific use case:
3GPP2的代理移动IPv4用例中有一些特殊的切换注意事项。下面是特定用例的图示：
+----+ +-------+ +-------+ +-------+
| | | | | | | |
| MN | | New | | AGW/ | | Old |
| | | PMA/BS| | HA | | PMA/BS|
+----+ +-------+ +-------+ +-------+
| | | |
| | 1 | |
| |------------->| |
| | | |
| | | |
| | o 2 |
| | | |
| | | |
| | 3 | |
| |<-------------| |
| | | |
| | | |
| | 4 | |
| |<----------------------->|
| | | |
| | | |
| | | o 5
| | | |
| | | |
+----+ +-------+ +-------+ +-------+
| | | | | | | |
| MN | | New | | AGW/ | | Old |
| | | PMA/BS| | HA | | PMA/BS|
+----+ +-------+ +-------+ +-------+
| | | |
| | 1 | |
| |------------->| |
| | | |
| | | |
| | o 2 |
| | | |
| | | |
| | 3 | |
| |<-------------| |
| | | |
| | | |
| | 4 | |
| |<----------------------->|
| | | |
| | | |
| | | o 5
| | | |
| | | |
Figure 11: 3GPP2 Registration Revocation for Previous PMA
图11：先前PMA的3GPP2注册撤销
Description of the steps:
步骤说明：
1. MN attaches to the new BS (L2 gets established). There is an ongoing mobility binding entry (MBE) in the AGW for the MN. The PMA in the new BS sends a PRRQ to the AGW.
1. MN连接到新的BS（建立L2）。MN的AGW中有一个正在进行的移动绑定条目（MBE）。新基站中的PMA向AGW发送PRRQ。
2. The AGW receives a Proxy Registration Request for a Mobile Node and detects that it has an existing Mobility Binding Entry (MBE). The AGW validates the PRRQ from the new BS and updates the MBE for the MN. The MBE is kept tentative at this point.
2. AGW接收移动节点的代理注册请求，并检测其具有现有的移动绑定条目（MBE）。AGW验证来自新BS的PRRQ，并更新MN的MBE。MBE在这一点上是暂时的。
3. The AGW sends a Proxy Registration Reply to the new BS. No Registration Revocation is used in the 3GPP2's use case.
3. AGW向新的BS发送代理注册回复。3GPP2的用例中不使用注册撤销。
4. A 3GPP2's proprietary PMA movement notification message may be exchanged between the AGW and the old BS.
4. 3GPP2的专有PMA移动通知消息可在AGW和旧BS之间交换。
5. The MBE update with the new BS is committed at this step.
5. 在此步骤中，提交使用新BS的MBE更新。
This specification registers 47 for the Proxy Mobile IPv4 Non-Skippable Extension and 147 for Proxy Mobile IPv4 Skippable Extension, both of which are described in Section 5. The ranges for Mobile IPv4 [RFC3344] extension types are defined at http://www.iana.org. This specification also creates a new subtype space for the type number of the extensions. The subtype value 1 is defined for the PMIPv4 Non-Skippable Extension. The subtype values 1 to 4 are defined for the PMIPv4 Skippable Extension. Similar to the procedures specified for Mobile IPv4 number spaces, future allocations from the number space require expert review [RFC5226].
本规范为代理移动IPv4不可跳过扩展注册了47个，为代理移动IPv4可跳过扩展注册了147个，这两个都在第5节中描述。移动IPv4[RFC3344]扩展类型的范围在中定义http://www.iana.org. 该规范还为扩展的类型号创建了一个新的子类型空间。为PMIPv4不可跳过的扩展定义了子类型值1。子类型值1到4是为PMIPv4可跳过扩展定义的。与移动IPv4号码空间指定的程序类似，号码空间的未来分配需要专家审查[RFC5226]。
The PMIPv4 Per-Node Authentication Method extension defined in Section 5.1 of this document, introduces a new authentication method numbering space, where the values from 0 to 2 have been assigned per this document. Approval of new Access Technology type values are to be made through IANA Expert Review.
本文件第5.1节中定义的PMIPv4每节点认证方法扩展引入了一个新的认证方法编号空间，其中根据本文件分配了0到2的值。新接入技术类型值的批准将通过IANA专家评审进行。
The PMIPv4 Device ID extension defined in Section 5.3 of this document, introduces a new ID type numbering space, where the values from 0 to 4 have been assigned per this document. Approval of new Access Technology type values are to be made through IANA Expert Review.
本文件第5.3节中定义的PMIPv4设备ID扩展引入了一个新的ID类型编号空间，其中根据本文件分配了0到4的值。新接入技术类型值的批准将通过IANA专家评审进行。
The PMIPv4 Subscriber ID extension defined in Section 5.4 of this document, introduces a new ID type numbering space, where the values from 0 to 1 have been reserved by this document. Approval of new Access Technology type values are to be made through IANA Expert Review.
本文件第5.4节中定义的PMIPv4用户ID扩展引入了一个新的ID类型编号空间，其中0到1的值由本文件保留。新接入技术类型值的批准将通过IANA专家评审进行。
The PMIPv4 Access Technology Type extension defined in Section 5.5 of this document, introduces a new technology type numbering space, where the values from 0 to 8 have been reserved by this document. Approval of new Access Technology type values are to be made through IANA Expert Review.
本文件第5.5节中定义的PMIPv4访问技术类型扩展引入了一个新的技术类型编号空间，其中0到8的值由本文件保留。新接入技术类型值的批准将通过IANA专家评审进行。
This document introduces the following Mobile IP extension types.
本文档介绍以下移动IP扩展类型。
Name : Proxy Mobile IPv4 Non-Skippable Extension Type Value : 47 Section : 5
名称：代理移动IPv4不可跳过扩展类型值：47节：5
Name : Proxy Mobile IPv4 Skippable Extension Type Value : 147 Section : 5
名称：代理移动IPv4可跳过扩展类型值：147节：5
This document introduces the following error code that can be returned by the HA in a Proxy Registration Reply.
本文档介绍了以下错误代码，医管局可在代理注册回复中返回这些代码。
Name Value First referenced
---- ----- ----------------
PMIP_UNSUPPORTED 149 Section 8.1 of RFC 5563
PMIP_DISALLOWED 150 Section 8.1 of RFC 5563
Name Value First referenced
---- ----- ----------------
PMIP_UNSUPPORTED 149 Section 8.1 of RFC 5563
PMIP_DISALLOWED 150 Section 8.1 of RFC 5563
The functionality in this document is protected by the authentication extensions described in RFC 3344 [RFC3344] or IPsec [RFC4301]. Each PMA needs to have an security association (e.g., MN-HA, FA-HA, IPsec AH/ESP) with the HA to register the MN's IP address. The security association can be provisioned by the administrator or dynamically derived. The dynamic key derivation and distribution for this scheme is outside the scope of this document.
本文档中的功能受RFC 3344[RFC3344]或IPsec[RFC4301]中描述的身份验证扩展的保护。每个PMA都需要与HA建立安全关联（如MN-HA、FA-HA、IPsec AH/ESP），以注册MN的IP地址。安全关联可以由管理员设置，也可以动态派生。此方案的动态密钥派生和分发不在本文档的范围内。
The authors would like to thank the following individuals for their review, comments, and suggestions to improve the content of this document.
作者感谢以下个人对改进本文件内容的评论、意见和建议。
Shahab Sayeedi (Motorola), Alper Yegin (Samsung), Premec Domagoj (Siemens), Michael Hammer (Cisco), Jun Wang (Qualcomm), Jayshree Bharatia (Nortel), Semyon Mizikovsky (Alcatel-Lucent), Federico De Juan Huarte (Alcatel-Lucent), Paula Tjandra (Motorola), Alice Qinxia (Huawei), Howie Koh (Greenpacket), John Zhao (Huawei), Pete McCann (Motorola), and Sri Gundavelli (Cisco).
Shahab Sayeedi（摩托罗拉）、Alper Yegin（三星）、Premec Domagoj（西门子）、Michael Hammer（思科）、Jun Wang（高通）、Jayshree Bharatia（北电）、Semyon Mizikovsky（阿尔卡特朗讯）、Federico De Juan Huarte（阿尔卡特朗讯）、Paula Tjandra（摩托罗拉）、Alice Qinxia（华为）、Howie Koh（绿包）、John Zhao（华为）、Pete McCann（摩托罗拉），和斯里·冈达维利（思科）。
[3GPP2] "3GPP2 Basic IP Service for Converged Access Network", X.S0054-100-0 Version 2.0, August 2008.
[3GPP2]“融合接入网络的3GPP2基本IP服务”，X.S0054-100-0版本2.0，2008年8月。
[NWG] "WiMAX Forum Network Architecture (Stage 3: Detailed Protocols and Procedures)" Release 1, Version 1.2.3, July 2008.
[NWG]“WiMAX论坛网络架构（第3阶段：详细协议和程序）”第1版，1.2.3版，2008年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]黑山，G.，编辑，“移动IP反向隧道，修订版”，RFC 3024，2001年1月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，Ed.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543]Glass，S.和M.Chandra，“移动IPv4中的注册撤销”，RFC 3543，2003年8月。
[MIP4GREKEY] Yegani, P., "GRE Key Extension for Mobile IPv4", Work in Progress, June 2007.
[MIP4GREKEY]Yegani，P.，“移动IPv4的GRE密钥扩展”，正在进行的工作，2007年6月。
[MIP4MCBC] Chakrabarti, S., "IPv4 Mobility extension for Multicast and Broadcast Packets", Work in Progress, November 2007.
[MIP4MCBC]Chakrabarti，S.，“多播和广播数据包的IPv4移动扩展”，正在进行的工作，2007年11月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005.
[RFC4058]Yegin，A.，Ed.，Ohba，Y.，Penno，R.，Tsirtsis，G.，和C.Wang，“承载网络接入认证（PANA）要求的协议”，RFC 4058，2005年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4332] Leung, K., Patel, A., Tsirtsis, G., and E. Klovning, "Cisco's Mobile IPv4 Host Configuration Extensions", RFC 4332, December 2005.
[RFC4332]Leung，K.，Patel，A.，Tsirtsis，G.，和E.Kloving，“思科的移动IPv4主机配置扩展”，RFC 4332，2005年12月。
[RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006.
[RFC4433]Kulkarni，M.，Patel，A.，和K.Leung，“移动IPv4动态归属代理（HA）分配”，RFC 44332006年3月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454]Tsirtsis，G.，Park，V.和H.Soliman，“双栈移动IPv4”，RFC 54542009年3月。
[RFCARP] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFCARP]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFCICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFCICMP]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
Authors' Addresses
作者地址
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞西塔斯曼大道170号肯特梁思科系统公司，邮编95134
EMail: kleung@cisco.com
EMail: kleung@cisco.com
Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞西塔斯曼大道170号Gopal Dommety Cisco Systems，邮编95134
EMail: gdommety@cisco.com
EMail: gdommety@cisco.com
Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206
帕维兹·耶加尼·朱尼珀网络公司加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089-1206
EMail: pyegani@juniper.net
EMail: pyegani@juniper.net
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA
Kuntal Chowdhury Starent Networks美国马萨诸塞州特克斯伯里国际广场30号01876
EMail: kchowdhury@starentnetworks.com
EMail: kchowdhury@starentnetworks.com