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
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は、そのIPアドレスを維持しながらネットワーク間を移動するためのIPv4デバイスを可能にする標準的なモビリティプロトコルです。モバイルデバイスは、ホームエージェントとして知られているルーティングアンカーにその位置を知らせるために、モバイルIPv4クライアント機能を持っています。しかし、様々な理由により、このような機能を持たない多くのIPv4デバイスがあります。この文書では、プロキシモバイルIPv4（はPMIPv4）、不変とモビリティ非対応のIPv4デバイス用のモビリティサポートを提供するネットワークエンティティでモバイルIPv4クライアント機能を有することに基づく方式が記載されています。この文書はまた、WiMAXフォーラムと3GPP2に採用される他のアプリケーションで指定されるようにはPMIPv4の特定の用途を記載しています。
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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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 [RFC3344]機能を有効にすることはできません多くのIPv4デバイスがあります。しかし、彼らのために移動度が不可欠です。プロキシモバイルIPv4は、これらのデバイスを「触れる」ことなく、モビリティサポートを提供します。スキームは、モバイルデバイスのためのモビリティ管理機能を実行するネットワークエンティティに基づいています。デバイスの位置は、関連付けられた（ホームエージェント（HA）と呼ばれる）、ホームネットワーク上のネットワークエンティティに通知する（プロキシモビリティエージェント（PMA）と呼ばれる）は、アクセスネットワーク上のネットワーク要素によって通知されますデバイスが使用するIPv4アドレス。モバイルIPv4メッセージングは、それぞれ、RFC 3344のにエンティティモバイルノード（プロキシモード）とホームエージェントに対応するPMAとHAによって使用されています。
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. Aワイヤレスローカルエリアネットワーク（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 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.
モビリティプロトコルは、モバイルデバイスのIPアドレスのルートと、トンネルのエンドポイントを設定すると実現するために必要な機能を持っているので、モバイルIPv4は、ネットワークエンティティによって使用される構成パラメータ（例えば、DNSサーバアドレス、デフォルトゲートウェイ）できるようにするため、モバイルデバイスのIPスタック。モバイルIPv4は、このように使用されている場合、これらのエンティティは、シグナリングエンドポイントであるため、セキュリティアソシエーションは、PMAとHAとの間にあります。モバイルデバイスは新しいPMAに移動した場合にも、複数のPMAから供給されたメッセージのシーケンシングは、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]は、任意のモビリティ関連のシグナリングへの参加を必要とせずにホストのIPモビリティを可能にするネットワーク・ベースのモビリティ管理のためのIETF標準であることに留意されたいです。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります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)
ホームエージェント（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 capabilities for supporting Proxy Mobile IPv4 in the Home Agent are defined in this document.
モバイルIPv4 [RFC3344]で定義されているホーム・エージェントは、プロキシモバイルIPv4方式で使用されています。これは、モバイルデバイスのホーム・ネットワークのトポロジカルアンカーポイントであり、モバイルデバイスの到達可能性状態を管理するエンティティです。ホームエージェントでのプロキシモバイル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クライアントからのと同じ場所または別されますか。これは、プロキシモバイル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クライアントは、複数のFAとの関連、およびその逆を有することができます。
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:
この文書で定義されたネットワークベースのモビリティ管理ソリューションは、あらゆる無線ネットワークでの使用のために、次の重要な理由があります。
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.
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.
Mobility-related signaling over the air-link is eliminated.
エアリンクを介してモビリティ関連シグナリングが排除されます。
Since Proxy Mobile IPv4 is based on an access, technology-
independent, mobility protocol, it can be used for any type of
access network.
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 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).
ネットワークの観点から、モバイルデバイスは、ネットワークアクセス識別子（NAI）によって識別され、転送は、ネットワーク上のアタッチメントのモバイルデバイスの現在のポイントのPMAとHAとの間に設定されています。ネットワークは、独立して、各アクセスインターフェースを扱うが、モバイルデバイスは、同時に複数のネットワークに取り付けられてもよいです。この機能ははPMIPv4アクセス技術の種類拡張子（5.5節）を使用してサポートすることができます。
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.
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.
モバイルデバイスは、ネットワーク・アクセス認証を完了した後、HAとPMA交換プロキシモバイル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制御プロトコル）プロトコルは、モバイルデバイスとARのネットワークアクセスサーバー（NAS）でのPPPクライアントを必要とします。 DHCPは、ARやHAのいずれかにおけるMNとDHCPサーバにDHCPクライアントを必要とします。 PMIPv4は、ホームネットワーク上のルータでARとHAにおけるPMAを必要とします。認証、許可、アカウンティング（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 |<------------->|<=========================>|
| | | |
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アドレスを許可し、PMAとHAの間の転送を設定プロキシモバイルIP、トリガ。ホスト構成パラメータはは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（アクセスルータ）とアクセス認証/認可を行います。このフェーズでは、モバイルデバイスが実行することができるいずれかのチャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994] PPP [RFC1661]を使用する場合、またはFOOを超える拡張認証プロトコル（EAP）[RFC3748]（FOOされている特定のアクセス技術、又はPANA [RFC4058]）。 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.
前記モバイルデバイスは、PPP / IPCP [RFC1332]またはDHCP [RFC2131]を介してIPアドレスを要求します。具体的にPPPのため、PPPクライアントはNASへのIPCP設定要求を送信します。 DHCPについては、DHCPクライアントがDHCPリレーエージェント/サーバにDHCP Discoverメッセージを送信します。
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.
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.
ステップ2によってトリガ3、PMAは、HAへのプロキシ登録要求（PRRQ）を送信します。 HAのIPアドレスは、どちらかのステップ1BでAAAサーバから取得またはいくつかの他の方法によって発見されました。 PRRQは、気付アドレス（CoA）PMA（この場合は併置FA）のが含まれています。ホームアドレスフィールドはゼロに設定されているか、またはIPアドレスがDHCPまたはIPCPメッセージの中にヒントとして指定されています。 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）キーを割り当てることができます。 HAは、PMAにプロキシ登録応答（PRRP）でのホームアドレスとGREキー（該当する場合）を返します。要求されたホームアドレスが許可されていない場合は、ホームエージェントはエラーコード129（管理上禁止）への登録を拒否します。 PMAはPRRPを処理した後、PMAとHAの間にホームアドレスの転送パスが確立されています。 GREトンネルは、PMAとHA [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 in the IP address configuration option and the DNS server address in the IPCP configuration option.
5.プロキシモバイルIPv4登録交換の後、ARは、IPCP 2.ステップに応答して、モバイルデバイスにIPアドレスを提供し、NASははPMIPv4割り当てられたホームを含むIPCP設定否定応答とPPPクライアントに返信IPアドレスの設定オプションと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.
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サーバは、DHCPクライアントに転送するDHCPリレーエージェントへのyiaddrフィールド値ではPMIPv4-割り当てられたホームアドレスとDHCPオファーを送信します。 DHCP要求およびDHCP ACKメッセージは、DHCPリレーエージェント経由でDHCPクライアントとDHCPサーバ間で交換されます。かかわらずはPMIPv4シグナリングおよびDHCP交換の一連の、はPMIPv4とDHCP間の相互作用は、それぞれ、ホームアドレスフィールドに同じIPアドレスと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 ACKがDHCPクライアントによって受信されたときにIPアドレスのリースが延長されます。
+----+ +-------+ +-----+
| | | 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を送信します。ホームアドレスフィールドは、常にモバイルデバイスの割り当てられたIPアドレスに設定されているが、これPRRQは、初期PRRQ（割り当てられたHAに設定され、すなわち、HAフィールド、およびPMAに設定のCoAフィールド）に似ています。モバイルデバイスの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. HAはPRRQに応じてPRRPは、PMAから受信した送信します。 PMAはPRRPを処理した後、ARとHAとの間の転送経路が無傷のままです。
+----+ +-------+ +-------+ +-----+
| | | 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ハンドオーバ手順を以下に説明します。 3つのフェーズがあります。まず、認証と承認は、モバイルデバイスがネットワーク内の新しい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ハンドオーバ中速い再認証に使用される方法で知られている（例えば2つの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 path for the Home Address between the new AR and HA is established. The event completes the Proxy Mobile IPv4 signaling for AR handover.
3.ホームエージェントはPRRQを処理すると、モバイルデバイスのための既存のモビリティバインディングエントリを更新します。ホームエージェントは、新しいPMAにPRRPで、結合からフェッチホームアドレスを返します。 PMAはPRRPを処理した後、新しいARとHAの間にホームアドレスの転送パスが確立されています。イベントは、プロキシモバイルIPv4は、ARハンドオーバーのためのシグナリングを完了する。
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上の考慮事項については、セクション6.1、6.2、およびこのドキュメントの6.3 [RFCARP]、ICMP [RFCICMP]、およびDHCP [RFC2131]を参照してください。フォワーディングパスが新しいPMAとHAの間で確立されているので、モバイルデバイスは、ホームアドレスを使用してIPパケットを受信または送信することができます。
+----+ +-------+ +-------+ +-----+
| | | 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.
新しいARに移動したモバイルデバイスのモビリティバインディングエントリの更新を契機1、HAは、具体的に古いPMA（すなわち、への登録取り消し（RFC 3543で指定された[RFC3543]）を送信することができ迅速な方法で、未使用のリソースをクリーンアップするために、外部エージェントエンティティ）。
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は、モバイルデバイスにサービスを提供しているが、モバイルデバイスから送信されたすべてのパケットを傍受し、そのモバイルデバイスをサポートするために作成トンネルをそれらを転送することができなければなりません。典型的には、転送は、ソースメディアアクセス制御（MAC）アドレスまたは入力インタフェースとしてレイヤ2情報に基づいています。これは、重複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からトンネル上で受信されたDEがカプセル化。典型的には、転送は、宛先IPアドレスおよび（GREキーを有していてもよい）入口HAトンネルに基づいています。これは、重複する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の間のトンネル動作はIP TTL（生存時間）、断片化、再アセンブリRFC 3344におけるFAとHAの間で同じである、等ロジック同じままです。トンネルモードは、オプションとして、デフォルトまたはGREでのIPinIPされます。
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 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.
DHCPおよびARP（アドレス解決プロトコル）のメッセージのブロードキャストパケットの処理は、それぞれ、6.3節と6.1節で説明されています。ブロードキャストパケットの他のタイプについては、PMAとHAは、[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で指定されるように転送されます。それらの間のトラフィックは、PMA上のローカルのショートカットを取ることなくHAを経由して配線してください。これは、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をサポートするために、（はPMIPv4拡張子で示される）FA-HA認証拡張またはIPsecは、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.
タイムスタンプ方式が使用されるとき、登録メッセージ内の識別フィールドは、再生保護及びシーケンシングを提供します。このメカニズムは、HAは、識別フィールドに基づいて、同じPMAまたは異なるのPMAからのメッセージのシーケンスを知ることができます。 HAはまた、プロキシ登録応答で識別不一致エラーコードを使用してPMAのクロックを同期させることができます。 PMAのクロックはネットワークタイムプロトコル[RFC1305]またはいくつかの他の方法を使用して同期している場合は、この応答メッセージには必要ではないでしょう。シーケンシングおよびリプレイ保護のための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フォーラム（セクション10を参照）、はPMIPv4クライアントはハンドオーバー中に固定されたままで使用されるように分割PMAモデルのために、なお（10.1節を参照してください）。この場合、クライアントはPMIPv4はPRRQの唯一の情報源です。しかし、複数のPMAの登録を行う（例えばはPMIPv4クライアント・リロケーションと非制御ハンドオーバーイベントなど）場合があります。統合されたPMAのための同じ方法をHAに登録の適切な順序付けを確実にするために使用されます。
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アドレスはホームアドレスと同じサブネット上にない場合は、ベンダー固有の拡張機能（例えば、[RFC4332]）、またはその他の方法は、デフォルトゲートウェイを取得するためにPMAで使用されるかもしれません。
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 |
+-+-+-+-+-+-+-+-+
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
１
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
プロキシモバイルIPv4のアクセス技術の種類の拡張子は、モバイルデバイスが接続されている無線アクセス技術の種類を示します。 PMAは、情報を認識しているときに、この拡張機能は、登録要求に含まれるかもしれません。 HAは、各インターフェイスが異なるアクセス技術タイプに接続されていると仮定すると、複数のインタフェースを持つモバイルデバイスに対して同じアクセス技術タイプにモビリティを提供することができます。 HAは、関連する登録応答での拡張が含まれていません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Tech-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Access Technology Type Extension
PMIPv4アクセス技術の種類拡張子
Type
タイプ
147 (Proxy Mobile IPv4 Skippable Extension)
147（プロキシモバイルIPv4スキップ可能エクステンション）
Length
長さ
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
１： ８０２。３
2: 802.11a/b/g
2：の802.11a / b / gに
3: 802.16e
3：802.16eの
4: 802.16m
4：802.16メートル
5: 3GPP EUTRAN/LTE
5：3GPP EUTRAN / LTE
6: 3GPP UTRAN/GERAN
I：香水/グランを疑問に思います
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へのパケットの送出を可能にすることです。 IPとMACアドレスのマッピングを解決するためのARP手順は、3GPP2のCDMA2000およびWiMAX IPコンバージェンスサブレイヤネットワークには必要ありません。
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アドレスに設定する必要はありません。限りパケットは、アクセスルータによって受信することができるように、ホーム・ネットワーク・ノード（セクション4.2.1でさらに詳細）を介してCNに向けて転送されます。モバイルデバイスでのARPテーブルは、CNSに到達するパケットのための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.
動き検出のために、モバイルデバイス上のネットワークスタックの特定の種類は、リンクがダウンして上昇した検出した後にデフォルトゲートウェイに[RFCICMP] ICMP要求を送信します。メッセージ内のIP TTLは、デフォルトゲートウェイがまだアクセスネットワーク上で直接到達可能であるかどうかを確認するために1に設定されています。それは、モバイルデバイス用のプロキシモバイルIPv4サービスを提供しているとき、PMAは、ICMP応答を送信することができます。この応答は、それがリンク状態を変更した後、ホームネットワーク上で推移しているモバイルデバイスに確認します。この動作は、既存のクライアントの実装に観察されます。 [RFC4436] "はIPv4（DNAv4）で検出ネットワーク接続" は使用することができます。
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クライアントとして動作するように期待されています。起動時および更新/解除：2台のDHCPのフェーズがあります。ブートアップ手順は、DHCPサーバーからDHCPクライアントのIPアドレスのリースを取得するためにDHCPリレーエージェントに依存しています。 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 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.
モバイルデバイスが起動すると、DHCPを開始します。手順は図1. DHCPクライアントに記述されているARでDHCPサーバーと直接IPアドレスを更新またはリリース。モバイルデバイスは、AR / DHCPサーバーとは異なるAR上にある場合は、クライアントからのDHCPメッセージは、前のARにDHCPサーバに転送したり、新しいARでDHCPサーバによって処理されるのいずれかのことができるようにする必要があります。 DHCPリース時間は、モバイルデバイスのIPアドレスの有効期限が切れるか、DHCP解放メッセージは、現在のAR上で受信されると、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を開始します。手順は、DHCPクライアントがHAでのDHCPサーバーと直接IPアドレスを更新またはリリースの図1に記載されています。モバイルデバイスが異なるAR上にある場合、クライアントからのDHCPメッセージは、HA内のDHCPサーバに中継されています。 DHCPリース時間は、モバイルデバイスのIPアドレスの有効期限が切れるか、DHCP解放メッセージは、HA上で受信されると、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は、ユーザを認証するために使用されます。認証後、（AR / PMAである）NASは、HAへのプロキシモバイルIPv4登録リクエストを送信します。 HAは、プロキシ登録応答におけるホームアドレスで応答します。 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.
以下に特定の例外を除いて、RFC 3344に記載されているようにPMAは、モバイルノードエンティティの機能を実行します。
- 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は、プロキシ登録を送信するために、最低限、以下の情報を知っておく必要があります。
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と他のネットワークノード間の関連とは無関係であることに注意してください。
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.
複数のPMAからPRRQs間1.配列決定。統合されたPMAのケースでは、新しいPMAとPRRQsを送る古いPMAの両方をもたらすことができるハンドオーバー後の期間があります。古いPMAは、モバイルデバイスは、再登録のタイマーが満了したときPRRQを送信する前に添付されていることを確認することが不可欠です。これは、HAは唯一のモバイルデバイスにサービスを提供している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.
ノードごとのセキュリティアソシエーションに基づいPRRQsの2認証（FA-HA AEやIPsec AH / ESP）が統合された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.
PMIPv4の拡張機能のために、この文書で定義されたプロキシモバイルIPv4拡張を処理するため3.能力。
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において1に等しい場合、HAは、登録を受け付けます。 HAは、MBEまたはプロキシ登録要求のいずれか大きい方の値より1大きいシーケンス番号で応答します。登録が拒否された場合、HAは、「管理上禁止（65）」エラーコードを送信します。 HAは、プロキシモバイルIPv4を有効にするか、この文書で定義されたプロキシモバイルIPv4拡張機能を処理することはできません、それはエラーコードPMIP_UNSUPPORTED（「HAでサポートされていないプロキシ登録」）で登録応答を送信します。されていない場合PMAは、HAへのプロキシ登録リクエストを送信することが許可されていない場合には、HAは、（「このPMAからプロキシ登録が許可されていません」）エラーコードPMIP_DISALLOWEDとプロキシの登録応答を送信します。
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は、これらのエラーコードで応答を送信し、HAへのプロキシモバイルIPv4メッセージの送信を再試行すべきではありません。
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アドレスを使用して通信することが可能です。 HAに現在接続されたネットワーク信号のPMAは、モバイルデバイスのトラフィックのための適切な転送パスを確保します。
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）へのモバイルデバイスから送信されるすべてのパケットはホームアドレスと対応するノードのIPアドレスへの宛先アドレスにIPv4ヘッダの送信元アドレスを設定し、通常のIPv4パケットとして送信されます。プロキシモバイル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は、モバイルデバイスからのパケットは関係なく、宛先IPアドレス、宛先に到達するためにHAに搬送されます。モバイルデバイスと同じネットワーク上の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に接続モバイルデバイスは、そのトラフィックを搬送するための別の持って使用することができます。
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接続とIPモビリティを提供するために、プロキシモバイルIPv4方式を採用しています。 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
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無線機に接続します。無線（基地局）が順番にASN1に認証ASN（NAS）に接続ASN2アンカーデータパス機能（A_DPF）に接続されています。 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 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.
MNによって初期ネットワーク進入時に、PMAはASN1に併置すべての機能を備えた統合PMAすることができ、ことに注意してください。モビリティのために、PMAのFAの一部は、より良いベアラ管理のために、より最適化された場所に移転しなければならないかもしれません。それは、WiMAX NWGモビリティフレームワークのより一般的な表現であるので、プロキシモバイルIPv4のWiMAXの特定のユースケースを記述するために、我々は、分割されたPMAモデルを使用します。
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で使用するための重要なブートストラップ方式を定義します。仕様は、プロキシモバイルIPv4の動作にあたり-MNのセキュリティアソシエーションを使用しています。関連キー（例えば、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].
モバイルIPv4登録の失効は、必要に応じてWiMAXの中でサポートされています。このためセキュリティアソシエーションは、ノードごとです。これは、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:
このドキュメントのセクション4で説明したようにのWiMAX NWGにおけるプロキシモバイルIPv4の動作は、基本的なプロキシモバイルIPv4の動作と位置合わせされます。プロキシモバイルIPv4のWiMAXのNWG 1.0.0の使用のための具体的な考慮事項があります。これらは次のとおりです。
1. Use of per-MS SA for Proxy Mobile IPv4 registration. In this case, MN-HA AE is used.
プロキシモバイルIPv4登録あたり-MS SAの使用。この場合、MN-HA AEが使用されています。
2. Use of split PMA to handle FA relocation while the PMIPv4 client remains anchored with the NAS (Authenticator ASN).
PMIPv4クライアントは、NAS（認証ASN）に停泊したままFAの再配置を処理するための分割PMAの使用。
3. Only the Proxy Mobile IPv4 Access Technology Type extension defined in this document is used in the NWG specification [NWG].
3.この文書で定義されたプロキシ・モバイルIPv4アクセス技術タイプ拡張子はNWG仕様[NWG]で使用されるのみ。
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特定基準点とプロトコル（別名、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アドレスを使用できるようにするためには、ASNでDHCPサーバ（別名、プロキシ）の機能が必要とされています同じIPアドレスが設定されます。
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モデルを使用しているため、コールフローは、PMA内ではPMIPv4クライアントと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 | | | | |
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は、（WiMAXの中のデータ・パス関数として知られている）新しいFAのエリアに移動しました。旧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.モバイルデバイスが新しいFA（WiMAXの中別名、新たなデータパス機能）に接続された基地局（図示せず）とL2リンクを確立します。この場合には、MNは、認証と承認を行っていない、ということに注意してください。 PMIPv4トンネルは旧FA（WiMAXのでは別名、古いデータパス機能）の間に残ります。データは、HAと旧FAとの間にはPMIPv4トンネルを介して、旧FAと新FAとの間および新しいFAからMNへのWiMAX固有R4トンネルを通って流れます。
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ははPMIPv4ハンドオーバを開始するためにはPMIPv4クライアントを要求するために、WiMAXの固有R4基準点を使用します。
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.
ステップ3をきっかけ4.はPMIPv4クライアントは、新たなFAにPRRQを送信します。 PRRQは、新FAのFA-CoAを含んでいます。ホームアドレスフィールドは、モバイルノードの割り当てられたIPアドレスのアドレスに設定されています。 PRRQは、WiMAXの固有R4パケットに埋め込まれています。
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ははPMIPv4クライアントにWiMAXの固有R4パケットでそれをカプセル化した後PRRPを転送します。
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方式を使用します。
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およびプロキシモバイルIPv4動作のためのHAとしてAGW作用として働きます。 HAはホームエージェントの役割を果たしながら、ユースケース2では、AGWは、PMAとして機能します。
RAN Core
コアをRAN
+-------+ +------+
+----+ | 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
コアをRAN
+-------+ +------+
+----+ | 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
+------+ +------+ +-----+
+----+ | | 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 | | |
|<======================================>|
| | | |
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を実行します。 BSは、このフェーズで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。 MNを認証するためのAR（図示せず）を介してBS交換ホームAAAサーバとのAAAメッセージを。このステップの一環として、ARは、MN（例えば、ユーザーのプロフィール、携帯電話の種類、割り当てられたホームエージェントアドレス、およびMNのその他の機能）に関するいくつかの情報をダウンロードすることができます。この情報は、次のステップ（S）にはPMIPv4トンネルを設定する（必要に応じて）PMA / BSに渡されます。
2. The MN sends layer 2 signaling messages to the BS/PMA to trigger the PMIPv4 tunnel setup process.
2. MNははPMIPv4トンネルセットアッププロセスをトリガするBS / PMAにレイヤ2のシグナリングメッセージを送信します。
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.
ステップ2によってトリガ3は、PMA / BSがAGW / HAにPRRQを送信します。 HAのアドレスはホームAAAサーバ（HAAA）からステップ1Bで受信されるか、または他の手段によって発見されました。 PRRQは、気付アドレス（CoA）PMA（この場合はFAを併置）のが含まれています。 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キーを割り当て、BS / PMAにPRRPでこのキーを返します。
5. The BS/PMA responds back to the MN with a layer 2 signaling message.
5. BS / PMAは、バックMNにレイヤ2シグナリング・メッセージで応答します。
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.
PMIPv4トンネルがAGWとHAとの間で確立された以外はユースケース2においては、同じ手順が続いています。この場合、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
| | | |
| | | |
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）があります。新しいBSでの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. A 3GPP2独自のPMA移動通知メッセージはAGWと古いBSの間で交換することができます。
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。また、この仕様は拡張のタイプ番号の新しいサブタイプのスペースを作成します。サブタイプ値1はPMIPv4非スキップ可能な拡張のために定義されています。 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拡張は、0から4までの値が、この文書ごとに割り当てられた新たなIDタイプの番号空間を導入します。新しいアクセス技術タイプ値の承認は、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拡張子は、0から1までの値は、このドキュメントによって予約された新たなIDタイプの番号空間を導入します。新しいアクセス技術タイプ値の承認は、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.
この文書では、プロキシ登録応答にHAによって返すことができる次のエラーコードを紹介します。
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は、MNのIPアドレスを登録するHAとのセキュリティアソシエーション（例えば、MN-HA、FA-HA、IPsecのAH / ESP）を持っている必要があります。セキュリティアソシエーションは、管理者によってプロビジョニングまたは動的に導出することができます。この方式のための動的キー導出および分布は、この文書の範囲外です。
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).
シャハブSayeedi（モトローラ）、アルパースYegin（サムスン）、Premec Domagoj（シーメンス）、マイケル・ハマー（シスコ）、6月王（クアルコム）、Jayshree Bharatia（ノーテル）、セミヨンMizikovsky（アルカテル・ルーセント）、フェデリコ・デ・フアンHuarteの（アルカテル-Lucent）、ポーラTjandra（モトローラ）、アリスQinxia（華為）、ハウィーコ（グリーンパケット）、ジョン・趙（華為）、ピート・マッキャン（モトローラ）、およびスリランカGundavelli（シスコ）。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年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]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543]ガラス、S.とM.チャンドラ、 "モバイル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]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（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.編、オオバ、Y.、Penno、R.、Tsirtsis、G.、及びC.王、 "要件ネットワークアクセス（PANA）の認証を搬送するプロトコル"、RFC 4058、2005年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、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]レオン、K.、パテル、A.、Tsirtsis、G.、およびE. Klovning、 "シスコのモバイル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.、パテル、A.、およびK.レオン、 "モバイルIPv4ダイナミックホームエージェント（HA）譲渡"、RFC 4433、2006年3月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、カールソン、J.、およびS.チェシャー、 "IPv4の（DNAv4）で検出ネットワーク接続"、RFC 4436、2006年3月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
【Ramphsi 5213] gundavelli、S。、ら、Leunji、K.、Devarapalliは、VEの、Chaudhuriの、K.、およびb。パティル、 "プロキシ・モバイル・20 6"、rphak 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.、公園、V.、およびH.ソリマン、 "デュアルスタックモバイルIPv4"、RFC 5454、2009年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]プラマー、D.、：、STD 37、RFC 826、1982年11月「イーサネットアドレス解決プロトコルやネットワーク・プロトコルを変換するには、イーサネットハードウェア上での伝送のためのイーサネットアドレスを48ビットにIPアドレス」。
[RFCICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFCICMP]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
Authors' Addresses
著者のアドレス
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
ケント・レオンシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134米国
EMail: kleung@cisco.com
メールアドレス：kleung@cisco.com
Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
ゴパルDommetyシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134米国
EMail: gdommety@cisco.com
メールアドレス：gdommety@cisco.com
Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206
Prvijhアグニジュニパーネットワークスの1194北マチルダアベニュー..サニーベール、94089-1206
EMail: pyegani@juniper.net
メールアドレス：pyegani@juniper.net
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA
Kuntalチョードリースタレントネットワークス30・インターナショナル・プレイステュークスベリー、MA 01876 USA
EMail: kchowdhury@starentnetworks.com
メールアドレス：kchowdhury@starentnetworks.com