[要約] RFC 5563は、WiMAX Forumと3GPP2の間で合意されたProxy Mobile IPv4の仕様を定義しています。この仕様の目的は、WiMAXネットワークと3GPP2ネットワーク間でのモバイルIPv4のシームレスな移動を実現することです。
Independent Submission K. Leung
Request for Comments: 5563 G. Dommety
Category: Informational Cisco Systems
ISSN: 2070-1721 P. Yegani
Juniper Networks
K. Chowdhury
Starent Networks
February 2010
WiMAX Forum / 3GPP2 Proxy Mobile IPv4
Wimax Forum / 3GPP2プロキシモバイルIPv4
Abstract
概要
Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2.
モバイルIPv4は、IPアドレスを維持しながらIPv4デバイスがネットワーク内で移動できるようにする標準のモビリティプロトコルです。モバイルデバイスには、モバイルIPv4クライアント機能があり、ホームエージェントとして知られるルーティングアンカーにその場所を信号を送信します。ただし、さまざまな理由により、このような機能がない多くのIPv4デバイスがあります。このドキュメントでは、プロキシモバイルIPv4（PMIPV4）について説明します。これは、ネットワークエンティティにモバイルIPv4クライアント機能を持つことに基づいたスキームであり、変更されていないモビリティに不在のIPv4デバイスのモビリティサポートを提供します。このドキュメントでは、WIMAXフォーラムで指定されているPMIPv4の特定のアプリケーションと、3GPP2で採用される別のアプリケーションについても説明しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5563.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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は、これらのデバイスに「触れる」ことなくモビリティサポートを提供します。このスキームは、モバイルデバイスのモビリティ管理機能を実行するネットワークエンティティに基づいています。デバイスの位置は、アクセスネットワークのネットワーク要素（プロキシモビリティエージェント（PMA）と呼ばれる）によって信号を送信して、ホームネットワーク上のネットワークエンティティ（ホームエージェント（HA）と呼ばれる）に関連付けられています。デバイスで使用される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. ワイヤレスローカルエリアネットワーク（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アドレスのルートとトンネリングエンドポイントをセットアップし、モバイルデバイスのデバイスを有効にするための構成パラメーター（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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" 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クライアントとcollocedされているか、分離されています。プロキシモバイル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の実装を再利用できます（つまり、クライアントベースのモビリティプロトコルを「AS-IS」に使用して、ネットワークベースのモビリティをサポートできます）。ただし、モバイルIPv4に追加される新しいPMIPV4拡張機能は、ソリューションの柔軟性を向上させます。クライアントベースとネットワークベースのモビリティの両方に共通のモビリティプロトコルを持つことの実際的な利点は、ホームエージェントがすべてのタイプのモバイルデバイスとモバイルIPv4機能を欠くものの両方を固定できることです。
The network-based mobility management solution defined in this document has the following significant reasons for its use in any wireless network:
このドキュメントで定義されているネットワークベースのモビリティ管理ソリューションには、任意のワイヤレスネットワークで使用される重要な理由があります。
1. Support for Unmodified Hosts
1. 修正されていないホストのサポート
An overwhelming majority of IPv4 hosts do not have Mobile IPv4 capability. Providing mobility for them is achievable using Proxy Mobile IPv4. This is accomplished without "touching" the user's devices by running on a myriad of operating systems and networking stacks.
IPv4ホストの圧倒的多数には、モバイルIPv4機能がありません。プロキシモバイルIPv4を使用して、彼らにモビリティを提供することが達成可能です。これは、無数のオペレーティングシステムとネットワーキングスタックで実行することにより、ユーザーのデバイスに「触れる」ことなく実現されます。
2. Re-Use of Existing Home Agent
2. 既存のホームエージェントの再利用
An existing Home Agent implementation can be used for network-based mobility as well. Further enhancements are optional and only incremental in nature. There are many commonalities between client-based and network-based mobility, and sharing the same protocol is a significant benefit.
既存のホームエージェントの実装も、ネットワークベースのモビリティにも使用できます。さらなる機能強化はオプションであり、本質的には漸進的です。クライアントベースとネットワークベースのモビリティの間には多くの共通点があり、同じプロトコルを共有することは大きな利点です。
3. Reduction of Air-Link Resource Consumption
3. エアリンクリソース消費の削減
Mobility-related signaling over the air-link is eliminated.
エアリンクを介したモビリティ関連のシグナルは排除されます。
4. Support for Heterogeneous Wireless Link Technologies
4. 不均一なワイヤレスリンクテクノロジーのサポート
Since Proxy Mobile IPv4 is based on an access, technology-independent, mobility protocol, it can be used for any type of access network.
プロキシモバイルIPv4はアクセス、テクノロジーに依存しないモビリティプロトコルに基づいているため、あらゆるタイプのアクセスネットワークに使用できます。
From the network perspective, a mobile device is identified by the Network Access Identifier (NAI) and the forwarding is set up between the PMA and HA for the mobile device's current point of attachment on the network. The mobile device may be attached to 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）。
5. Support for IPv4 and IPv6 Hosts
5. IPv4およびIPv6ホストのサポート
As IPv6 increases in popularity, the host will likely be dual stack. Adding IPv6 support to the host for Proxy Mobile IPv4 involves the methods defined in [RFC5454]. There are additional enhancements needed, which are described in "Proxy Mobile IPv6" [RFC5213]. However, support for an IPv6 host is out of the scope of this document.
IPv6の人気が高まるにつれて、ホストはデュアルスタックになる可能性があります。プロキシモバイルIPv4のホストにIPv6サポートを追加するには、[RFC5454]で定義された方法が含まれます。「プロキシモバイルIPv6」[RFC5213]に記載されている追加の機能強化が必要です。ただし、IPv6ホストのサポートはこのドキュメントの範囲外です。
After the mobile device completes network-access authentication, the PMA exchanges Proxy Mobile IPv4 registration messages with the HA to set up proper routing and tunneling of packets from/to the Mobile Node. The PMIPv4 client is responsible for initiating the Proxy Mobile IPv4 registration. For integrated PMA, the PMIPv4 client and the FA interaction is all within the node. In the case of split PMA implementation, the interactions between the PMIPv4 client and the FA are exposed. The interface between the PMIP Client and the FA in the split PMA scenario is defined in a standards organization specification [NWG] and is consequently out of the scope of this document.
モバイルデバイスがネットワークアクセス認証を完了した後、PMAはHAとモバイルIPv4登録メッセージをプロキシを交換して、モバイルノードからのパケットの適切なルーティングとトンネリングをセットアップします。PMIPV4クライアントは、プロキシモバイルIPv4登録の開始を担当します。統合されたPMAの場合、PMIPV4クライアントとFAインタラクションはすべてノード内にあります。Split PMA実装の場合、PMIPV4クライアントとFAの間の相互作用が公開されます。分割PMAシナリオのPMIPクライアントとFAの間のインターフェイスは、標準組織仕様[NWG]で定義されているため、このドキュメントの範囲外です。
The following call flows describe the operations of Proxy Mobile IPv4. The initial network attachment, registration renewal, and resource cleanup procedures are covered. Note that the protocols that interact with Proxy Mobile IP are identified and explained in more detail. The PPP/IPCP (IP Control Protocol) protocol involves a PPP client in the mobile device and a Network Access Server (NAS) in the AR. DHCP involves a DHCP client in the MN and a DHCP server in either the AR or the HA. PMIPv4 involves a PMA in the AR and an HA in the router on the home network. The Authentication, Authorization, and Accounting (AAA) protocol involves a AAA client in the AR and a AAA server in the network. The collocation of the functional entities in the AR/HA enables parameters to be shared/processed among the protocols.
次の通話フローは、プロキシモバイルIPv4の操作について説明しています。初期ネットワークの添付ファイル、登録更新、およびリソースクリーンアップ手順について説明します。プロキシモバイルIPと相互作用するプロトコルが特定され、詳細に説明されていることに注意してください。PPP/IPCP（IPコントロールプロトコル）プロトコルには、モバイルデバイスのPPPクライアントとARのネットワークアクセスサーバー（NAS）が含まれます。DHCPには、MNのDHCPクライアントとARまたはHAのいずれかのDHCPサーバーが含まれます。PMIPV4には、ARにPMAとホームネットワークのルーターにHAが含まれます。認証、承認、および会計（AAA）プロトコルには、ARのAAAクライアントとネットワーク内のAAAサーバーが含まれます。AR/HAの機能エンティティのコロケーションにより、パラメーターをプロトコル間で共有/処理できます。
When the various network entities are not collocated, any sharing of parameters or other state information between them is out of the scope of this document.
さまざまなネットワークエンティティがコロケートされていない場合、パラメーターまたはその他の状態情報の共有は、このドキュメントの範囲外です。
+----+ +-------+ +-------+ +-----+
| | | AR / | | | | |
| MN | | PMA | | AAA | | HA |
| | | | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1a | 1b | |
Authentication |<------------->|<----------->| |
| | | |
| 2 | | |
+-> |-------------->| | |
| | | 3 | |
| | |-------------------------->| <-+
Address | | | | | |PMIP
Acquisition| | | 4 | | |
| | |<--------------------------| <-+
| | 5 | | |
+-> |<--------------| | |
| | | |
| 6 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
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.
初期のネットワークアタッチメント手順については、以下に説明します。3つの異なるフェーズがあります。まず、モバイルデバイスがネットワークにアクセスすると、認証と承認が発生します。次に、モバイルデバイスは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（アクセスルーター）でアクセス認証/承認を実行します。このフェーズでは、PPP [RFC1661]が使用されている場合、モバイルデバイスはチャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]または拡張可能な認証プロトコル（EAP）[RFC3748]をFOO（FOOは特定のアクセステクノロジー、またはパナ[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.
2. モバイルデバイスは、PPP/IPCP [RFC1332]またはDHCP [RFC2131]を介してIPアドレスを要求します。特にPPPの場合、PPPクライアントはNASにIPCP Configure-Requestを送信します。DHCPに関しては、DHCPクライアントはDHCP発見メッセージをDHCPリレーエージェント/サーバーに送信します。
For the DHCP case, the DHCP server or DHCP relay agent sends the DHCP Ack message to the DHCP client after PMIPv4 signaling has completed.
DHCPケースの場合、DHCPサーバーまたはDHCPリレーエージェントは、PMIPv4シグナリングが完了した後、DHCP ACKメッセージをDHCPクライアントに送信します。
3. Triggered by step 2, the PMA sends a Proxy Registration Request (PRRQ) to the HA. The HA's IP address is either obtained from the AAA server at step 1b or discovered by some other method. The PRRQ contains the Care-of Address (CoA) of the PMA (the collocated FA in this case). The Home Address field is set to zero or the IP address is specified as a hint in the DHCP or IPCP message. The PRRQ MUST be protected by the methods described in the Security Considerations (Section 13) of this document. The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document.
3. ステップ2でトリガーされたPMAは、HAにプロキシ登録要求（PRRQ）を送信します。HAのIPアドレスは、ステップ1BのAAAサーバーから取得されるか、他の方法で発見されます。PRRQには、PMA（この場合、Collocated FA）のケアアドレス（COA）が含まれています。ホームアドレスフィールドはゼロに設定されているか、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は、プロキシ登録返信（PRRP）のホームアドレスとGREキー（該当する場合）をPMAに返します。要求されたホームアドレスが承認されていない場合、ホームエージェントはエラーコード129（管理上禁止）で登録を拒否します。PMAがPRRPを処理した後、PMAとHAの間のホームアドレスの転送パスが確立されます。PMAとHA [Mip4Grekey]の間でGREトンネルを使用できます。このイベントは、初期ネットワーク添付ファイルのプロキシモバイル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はステップ2に応じてモバイルデバイスにIPアドレスを提供します。IPCPの場合、NASはIPCP Configure-NakでPPPクライアントに返信します。IPCP構成オプションのIPアドレス構成オプションとDNSサーバーアドレス。
The following procedure happens when the DHCP server is on the AR. The DHCP server sends a DHCP Offer with the PMIPv4-assigned Home Address in the yiaddr field to the DHCP client. The DHCP client sends a DHCP Request to the DHCP server, which replies with a DHCP Ack. The host configuration (such as the DNS server address) is included in the DHCP options in the message. Note that the DHCP messages are exchanged directly between the DHCP client and the DHCP server.
次の手順は、DHCPサーバーがAR上にあるときに発生します。DHCPサーバーは、YIADDRフィールドのPMIPV4が割り当てられたホームアドレスとDHCPクライアントにDHCPオファーを送信します。DHCPクライアントは、DHCPサーバーにDHCPリクエストを送信し、DHCP ACKで返信します。ホスト構成（DNSサーバーアドレスなど）は、メッセージのDHCPオプションに含まれています。DHCPメッセージは、DHCPクライアントとDHCPサーバーの間で直接交換されることに注意してください。
In the case when AR acts as a DHCP relay agent, the DHCP Discover is relayed to the DHCP server on the HA. The DHCP server sends a DHCP Offer with the PMIPv4-assigned Home Address in the yiaddr field to the DHCP relay agent, which forwards it to the DHCP client. The DHCP Request and DHCP Ack messages are exchanged between the DHCP client and DHCP server via the DHCP relay agent. Regardless of the sequence of PMIPv4 signaling and DHCP exchanges, the interaction between PMIPv4 and DHCP involves in the same IP address for Home Address field and yiaddr field, respectively.
ARがDHCPリレーエージェントとして機能する場合、DHCP発見はHAのDHCPサーバーにリレーされます。DHCPサーバーは、YiadDRフィールドのPMIPV4が割り当てられたホームアドレスとDHCPリレーエージェントにDHCPオファーを送信し、DHCPクライアントに転送します。DHCPリクエストとDHCP ACKメッセージは、DHCPリレーエージェントを介してDHCPクライアントとDHCPサーバーの間で交換されます。PMIPV4シグナル伝達とDHCP交換のシーケンスに関係なく、PMIPV4とDHCPの相互作用は、それぞれホームアドレスフィールドとYiadDRフィールドの同じIPアドレスに含まれます。
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アドレスを更新します。IPアドレスのリースは、DHCPサーバーからのDHCP ACKがDHCPクライアントによって受信されると延長されます。
+----+ +-------+ +-----+
| | | 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はモバイルデバイスのモビリティ結合の期間を延長するためにPRRQをHAに送信します。このPRRQは、初期のPRRQ（つまり、割り当てられたHAに設定されたHAフィールド、およびPMAに設定されたCOAフィールド）に似ていますが、ホームアドレスフィールドは常にモバイルデバイスの割り当てられたIPアドレスに設定されます。モバイルデバイスのIPスタックは、HAに固定されたホームアドレスを使用して、引き続きIPパケットを送信および受信できます。
2. The HA sends the PRRP in response to the PRRQ received from the PMA. After the PMA processes the PRRP, the forwarding path between AR and HA remains intact.
2. HAは、PMAから受け取ったPRRQに応じてPRRPを送信します。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は、PRRQをHAに送信します。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を処理すると、モバイルデバイスの既存のモビリティバインディングエントリを更新します。ホームエージェントは、PRRPのバインディングから新しいPMAに連れて行かれたホームアドレスを返します。PMAがPRRPを処理した後、新しいARとHAの間のホームアドレスの転送パスが確立されます。このイベントは、ARハンドオーバーのプロキシモバイルIPv4シグナリングを完了します。
4. At this step, which happens around the same time as step 2, the mobile device's IP stack may detect L2 link going down and up after access re-authentication. The mobile device's IP stack may attempt to validate its IP address connectivity. See Sections 6.1, 6.2, and 6.3 of this document for considerations on ARP [RFCARP], ICMP [RFCICMP], and DHCP [RFC2131], respectively. Because the forwarding path is established between the new PMA and HA, the mobile device can receive or send IP packets using the Home Address.
4. ステップ2とほぼ同じ時期に発生するこのステップでは、モバイルデバイスのIPスタックは、アクセスの再認証後にL2リンクを検出して上下する可能性があります。モバイルデバイスのIPスタックは、IPアドレスの接続を検証しようとする場合があります。ARP [RFCARP]、ICMP [RFCICMP]、およびDHCP [RFC2131]に関する考慮事項については、このドキュメントのセクション6.1、6.2、および6.3を参照してください。転送パスは新しいPMAとHAの間に確立されるため、モバイルデバイスはホームアドレスを使用してIPパケットを受信または送信できます。
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| | | 1 |
+-> | | |<------------|
| | | | |
Revocation | | | o 2 |
| | | | |
| | | | 3 |
+-> | | |------------>|
| | | |
Figure 4: Registration Revocation for Previous PMA
図4：以前のPMAの登録の取り消し
The resource cleanup procedure for the old AR is described below. This cleanup is necessary when the old AR needs to delete its PMIPv4 and other associated states for a mobile device that has moved to another AR. Therefore, this is an optional procedure for Proxy Mobile IP. The alternative method is based on the new PMA notifying the old PMA to clean up resources. The alternative method is out of the scope of this document.
古いARのリソースクリーンアップ手順を以下に説明します。このクリーンアップは、古いARが別のARに移動したモバイルデバイスのPMIPv4およびその他の関連状態を削除する必要がある場合に必要です。したがって、これはプロキシモバイルIPのオプションの手順です。代替方法は、古いPMAにリソースをクリーンアップするように通知する新しいPMAに基づいています。代替方法は、このドキュメントの範囲外です。
1. Triggered by the update of the mobility binding entry for a mobile device that has moved to a new AR, the HA may send a Registration Revocation (as specified in RFC 3543 [RFC3543]) to the old PMA (i.e., specifically to the Foreign Agent entity) in order to clean up unused resources in an expeditious manner.
1. 新しいARに移動したモバイルデバイスのモビリティバインディングエントリの更新によってトリガーされ、HAは登録撤去（RFC 3543 [RFC3543]で指定）を古いPMAに（つまり、特に外国のエージェントに送信する可能性があります。エンティティ）迅速な方法で未使用のリソースをクリーンアップするため。
2. The old PMA removes the PMIPv4 states for the mobile device.
2. 古いPMAは、モバイルデバイスのPMIPv4状態を削除します。
3. The old PMA sends revocation acknowledgement to the HA.
3. 古いPMAは、HAに取り消し承認を送信します。
The PMA and HA set up a tunnel between them for the Home Address after the PMIPv4 registration message exchange.
PMIPV4登録メッセージ交換後、PMAとHAは自宅の住所のためにそれらの間にトンネルを設定しました。
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からトンネルで受信したパケットをカプセル化します。通常、転送は宛先IPアドレスとイングレスHAトンネル（GREキーがある場合がある）に基づいています。これにより、モバイルデバイスに向けたパケットに対して、重複するIPアドレスをサポートできます。たとえば、PMAは、これらのモバイルデバイスにサービスを提供するHA用に作成されたトンネルのGREキー値に基づいて、同じIPアドレスを各モバイルデバイスに関連付けられたリンクに同じIPアドレスを持つモバイルデバイスにパケットを転送します。
The tunnel operation between the PMA and HA is the same as between the FA and HA in RFC 3344. The IP TTL (Time to Live), fragmentation, re-assembly, etc. logic remain the same. The tunnel mode is IPinIP by default or GRE as an option.
PMAとHAの間のトンネル動作は、RFC 3344のFAとHAの間の間の操作と同じです。IPTTL（ライブまで）、断片化、再組み立てなど。ロジックは同じままです。トンネルモードは、デフォルトではIPINIPまたはGREがオプションとしてGREです。
Broadcast packet processing for DHCP and ARP (Address Resolution Protocol) messages are described in Section 6.3 and Section 6.1, respectively. For other types of broadcast packets, the PMA and HA 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サポートの場合、FA-HA認証拡張機能またはIPSEC（PMIPV4拡張機能に示されています）を使用して、PMAとHAの間のシグナリングメッセージ（登録の取り消し[RFC3543]を含む）を認証します。IPSECの場合、必須の整合性保護を備えた輸送モードのセキュリティペイロード（ESP）[RFC4303]をカプセル化する必要があります。IPSECエンドポイントは、PMAおよびHAのIPアドレスです。
For per-MN SA support, the MN-HA Authentication extension and/or MN-AAA Authentication extension are used to authenticate the signaling.
MN SAサポートの場合、MN-HA認証拡張および/またはMN-AAA認証拡張機能を使用して、シグナリングを認証します。
The creation of the security association may be assisted by the AAA server at the time of access authentication.
セキュリティ協会の作成は、アクセス認証時にAAAサーバーによって支援される場合があります。
The Identification field in the registration message provides replay protection and sequencing when the timestamp method is used. This mechanism allows the HA to know the sequence of messages from the same PMA or different PMAs based on the Identification field. The HA can also synchronize the PMA's clock by using the Identification mismatch error code in the Proxy Registration Reply. This reply message would not be necessary when the PMA's clocks are synchronized using the Network Time Protocol [RFC1305] or some other method. Note that the use of nonce for sequencing and replay protection is outside the scope of this document.
登録メッセージの識別フィールドは、タイムスタンプメソッドを使用するときにリプレイ保護とシーケンスを提供します。このメカニズムにより、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フォーラムで使用されている分割PMAモデル（セクション10を参照）の場合、PMIPV4クライアントはハンドオーバー中に固定されたままであることに注意してください（セクション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認証拡張機能に加えて、登録を認証するための代替方法を示します。Nodeごとに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
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：国際的なモバイル機器ID（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タイプフィールドで示された型の識別子を含む可変長さのオクテットシーケンス。
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タイプフィールドで示された型の識別子を含む可変長さのオクテットシーケンス。
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
2
Sub-Type
サブタイプ
4 (Access Technology Type)
4（アクセステクノロジータイプ）
Tech-Type
技術タイプ
An 8-bit field that specifies the access technology through which the mobile device is connected to the access network.
モバイルデバイスがアクセスネットワークに接続されているアクセステクノロジーを指定する8ビットフィールド。
The values (0 - 255) are allocated and managed by IANA. The following values have been assigned to the specified access technology types.
値（0-255）は、IANAによって割り当てられ、管理されます。次の値は、指定されたアクセステクノロジータイプに割り当てられています。
0: Reserved
0：予約済み
1: 802.3
1：802.3
2: 802.11a/b/g
2：802.11a/b/g
3: 802.16e
3：802.16e
4: 802.16m
4：802.16m
5: 3GPP EUTRAN/LTE
5：3GPP eutran/lte
6: 3GPP UTRAN/GERAN 7: 3GPP2 1xRTT/HRPD
6：3GPP Utran/Geran 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を介してホームネットワーク上の別のホストのMACアドレス（[RFCARP]）を介して学習し、DHCP（[RFC2131]）を介してIPアドレスとその他のホスト構成を取得し、Link-Local Multicastと送信しますブロードキャストパケット。ホストに対するネットワークの応答は、ホストがホームネットワーク上にある場合の状況と同等です。リンク状態が変更されると、一部のホストは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 Ethernet Convergence Sublayerなど）の場合、モバイルデバイスは、同じネットワークの対応するノード（CN）とデフォルトゲートウェイのARP要求を送信します。ARPエントリを維持する目的は、宛先MACアドレスを使用してモバイルデバイスからCNにパケットの配信を許可することです。IPおよびMACアドレスマッピングを解決するためのARP手順は、3GPP2のCDMA2000およびWIMAX IP Convergence Sublayerネットワークには必要ありません。
The access router is always the L2 endpoint for the mobile device. The destination MAC address in the packet does not need to be set to the CN's MAC address. As long as the packet can be received by the access router, it will be forwarded toward the CN via the home network node (further details in Section 4.2.1). The ARP table in the mobile device does not need to be populated with CNs' MAC addresses in order for the packet to reach the CNs.
アクセスルーターは、常にモバイルデバイスのL2エンドポイントです。パケット内の宛先MACアドレスは、CNのMACアドレスに設定する必要はありません。パケットをアクセスルーターで受信できる限り、ホームネットワークノードを介してCNに向かって転送されます（セクション4.2.1の詳細）。パケットがCNSに到達するために、モバイルデバイスのARPテーブルにCNSのMacアドレスを入力する必要はありません。
A mobile device has ARP entries for the default gateway and hosts on the same subnet. Regardless of what the MAC addresses are, the AR receives the packets sent from the mobile device.
モバイルデバイスには、デフォルトゲートウェイのARPエントリがあり、同じサブネットにホストがあります。MACアドレスが何であるかに関係なく、ARはモバイルデバイスから送信されたパケットを受信します。
For movement detection, certain types of network stack on the mobile device will send an ICMP request [RFCICMP] to the default gateway after detecting the link went down and up. The IP TTL in the message is set to 1 to check if the default gateway is still directly reachable on the access network. The PMA MAY send an ICMP reply when it is providing Proxy Mobile IPv4 service for the mobile device. This response confirms to the mobile device that it has remained on the home network after link state change. This behavior is observed on existing client implementation. "Detecting Network Attachment in IPv4 (DNAv4)" [RFC4436] can be employed.
移動検出のために、モバイルデバイスの特定のタイプのネットワークスタックは、リンクがダウンして上下した後、ICMPリクエスト[RFCICMP]をデフォルトゲートウェイに送信します。メッセージ内のIP TTLは1に設定されており、デフォルトゲートウェイがアクセスネットワーク上で直接到達可能かどうかを確認します。PMAは、モバイルデバイスにプロキシモバイルIPv4サービスを提供するときに、ICMPの返信を送信する場合があります。この応答は、リンク状態の変更後にホームネットワーク上に残っていることをモバイルデバイスに確認します。この動作は、既存のクライアントの実装で観察されます。「IPv4（DNAV4）でのネットワークアタッチメントの検出」[RFC4436]を使用できます。
General ICMP traffic is handled as normal IP packets and tunneled between the PMA and HA.
一般的なICMPトラフィックは、通常のIPパケットとして処理され、PMAとHAの間にトンネルが付けられています。
DHCP [RFC2131] is used to obtain an IP address and other host configuration parameters for a mobile device. The mobile device is expected to behave as a normal DHCP client when connected to the network with Proxy Mobile IPv4 service. There are two DHCP phases: bootup and renewal/release. The bootup procedure relies on the DHCP relay agent to obtain a lease on the IP address for the DHCP client from the DHCP server. The DHCP client directly renews and releases the lease with the DHCP server.
DHCP [RFC2131]は、モバイルデバイスのIPアドレスおよびその他のホスト構成パラメーターを取得するために使用されます。モバイルデバイスは、プロキシモバイルIPv4サービスでネットワークに接続すると、通常のDHCPクライアントとして動作すると予想されます。2つのDHCPフェーズがあります：ブートアップと更新/リリース。ブートアップ手順は、DHCPリレーエージェントに依存して、DHCPサーバーからDHCPクライアントのIPアドレスのリースを取得します。DHCPクライアントは、DHCPサーバーでリースを直接更新およびリリースします。
In Proxy Mobile IPv4, the mobile device boots up on a network that is not the home network associated with the leased IP address. Also, the mobile device can move to other networks that are not related to that IP address. Yet, the DHCP client on the mobile device continues to operate as a stationary device that is directly on the network associated with its IP address. The PMA and HA create the transparency of the remote home network and mobility events by providing the expected network response to the DHCP client.
プロキシモバイルIPv4では、モバイルデバイスは、リースされたIPアドレスに関連付けられているホームネットワークではないネットワークで起動します。また、モバイルデバイスは、そのIPアドレスに関係のない他のネットワークに移動できます。しかし、モバイルデバイスのDHCPクライアントは、IPアドレスに関連付けられたネットワーク上に直接ある固定デバイスとして動作し続けています。PMAとHAは、DHCPクライアントに予想されるネットワーク応答を提供することにより、リモートホームネットワークとモビリティイベントの透明度を作成します。
There are several methods for the network infrastructure to interface with the mobile device such that the mobile device believes it is always fixed on the same network. The following methods are identified here, though others may be used as well.
ネットワークインフラストラクチャがモバイルデバイスとインターフェイスする方法がいくつかあり、モバイルデバイスが常に同じネットワークで固定されていると考えています。ここでは、次の方法が特定されていますが、他の方法も使用できます。
DHCP Server in the AR:
ARのDHCPサーバー：
The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the AR. When the mobile device is on a different AR than the AR/DHCP server, the DHCP message from the client needs to be able to either be forwarded to 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サーバーによって処理される必要があります。モバイルデバイスのIPアドレスのDHCPリース時間が期限切れになるか、現在のARでDHCPリリースメッセージが受信されると、ARはPMIPV4の登録をHAに送信します。
DHCP Relay Agent in the AR:
ARのDHCPリレーエージェント：
The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the HA. When the mobile device is on a different AR, DHCP messages from the client are relayed to the DHCP server in the HA. When the DHCP lease time expires for the mobile device's IP address or the DHCP release message is received on the HA, the HA deletes the mobility binding entry for the mobile device and sends registration revocation [RFC3543] to the AR.
モバイルデバイスが起動してDHCPを開始します。手順については、図1に説明します。DHCPクライアントは、HAのDHCPサーバーでIPアドレスを直接更新またはリリースします。モバイルデバイスが別のAR上にある場合、クライアントからのDHCPメッセージがHAのDHCPサーバーに中継されます。モバイルデバイスのIPアドレスのDHCPリース時間が期限切れになるか、HAでDHCPリリースメッセージが受信されると、HAはモバイルデバイスのモビリティバインディングエントリを削除し、登録装備[RFC3543]をARに送信します。
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（Link Control Protocol）Chapがユーザーを認証するために使用されます。認証後、NAS（AR/PMA）はプロキシモバイルIPv4登録要求をHAに送信します。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は、Link-Local MulticastまたはBroadcast in the HAに運命づけられているすべてのパケットをトンネルする場合があります。HAは、同じサブネットにあるホストを調べ、それぞれに重複したパケットを送信します。
The PMA performs the functions of a Mobile Node entity as described in RFC 3344, with the exceptions identified below.
PMAは、以下で特定された例外を除いて、RFC 3344で説明されているように、モバイルノードエンティティの機能を実行します。
- No agent discovery (i.e., agent solicitation and advertisement) is supported.
- エージェントの発見（つまり、エージェントの勧誘と広告）はサポートされていません。
- The D-bit (De-encapsulation by MN) in the Registration Request is always set to zero.
- 登録リクエストのDビット（MNによる脱カプセル化）は、常にゼロに設定されます。
The main responsibility of the PMA is to set up and maintain the routing path between itself and the HA for a mobile device that is attached on the network. When it detects a mobile device is no longer attached, the routing path is torn down. It is possible that the PMA functions may be split up in implementations such as WiMAX (Section 10).
PMAの主な責任は、ネットワークに接続されているモバイルデバイスのルーティングパスとHAの間のルーティングパスをセットアップおよび維持することです。モバイルデバイスが添付されなくなった場合、ルーティングパスが取り壊されます。PMA関数がWiMaxなどの実装で分割される可能性があります（セクション10）。
The PMA needs to know the following information, at a minimum, for sending a proxy registration:
PMAは、プロキシ登録を送信するために、少なくとも次の情報を知る必要があります。
1. NAI of the mobile device.
1. モバイルデバイスのnai。
2. MN-HA security association, when per-mobile device security association is used.
2. MN-HAセキュリティ協会、モバイルごとのデバイスセキュリティ協会が使用される場合。
3. FA-HA Mobility security association or IPsec security association when per-node security association is used. Note that these associations are specific only between PMA and HA, and are cryptographically unrelated to the associations between the MN and other network nodes.
3. FA-HAモビリティセキュリティ協会またはIPSECセキュリティ協会ごとのセキュリティ協会が使用される場合。これらの関連は、PMAとHAの間でのみ固有であり、MNと他のネットワークノードとの関連性と暗号化的に無関係であることに注意してください。
4. HA Address.
4. HAアドレス。
This information is typically downloaded from the AAA server during access authentication.
この情報は通常、アクセス認証中にAAAサーバーからダウンロードされます。
The Home Agent has the functionality described in RFC 3344 [RFC3344]. In addition, the following features are introduced by Proxy Mobile IPv4:
ホームエージェントには、RFC 3344 [RFC3344]で説明されている機能があります。さらに、次の機能はプロキシモバイルIPv4によって導入されています。
1. Sequencing between PRRQs from multiple PMAs. For the integrated PMA case, there is a period after handover that may result in both the new PMA and old PMA sending PRRQs. It is imperative that the old PMA confirm that the mobile device is attached before sending a PRRQ when the re-registration timer expires. This would ensure that the HA only receives registration from the PMA that is serving the mobile device.
1. 複数のPMAからのPRRQ間のシーケンス。統合されたPMAケースの場合、ハンドオーバー後の期間があり、新しいPMAと古いPMAの両方がPRRQを送信する可能性があります。古い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.
2. ノードごとのセキュリティ協会（FA-HA AEまたはIPSEC AH/ESP）に基づくPRRQの認証は、統合されたPMAの場合に適用できます。この場合、PRRQにおけるMn-Ha AEまたはMn-AAA AEの存在は必要ありません。PMIPv4はPMAとHAの間のシグナル伝達に基づいているため、メッセージのセキュリティはピアの関係に基づいて認証できます。HAは、AAAサーバーに連絡することにより、PMAのモバイルデバイスのPMIPV4サービスを承認できます。
3. The ability to process the Proxy Mobile IPv4 extensions defined in this document for enhanced capabilities of PMIPv4.
3. PMIPv4の機能を強化するために、このドキュメントで定義されているプロキシモバイルIPv4拡張機能を処理する機能。
When a Proxy Registration Request is received, the HA looks up the mobility binding entry indexed by the NAI. If the entry exists, HA compares the sequence numbers between the message and mobility binding entry (MBE), if present. If the value in the message is zero or greater than or equal to the one in the MBE, HA accepts the registration. The HA replies with a sequence number that is one greater than the larger value of either the MBE or Proxy Registration Request. If the registration is denied, then HA sends error code "Administratively prohibited (65)". If the HA is not enabled with Proxy Mobile IPv4 or cannot process the Proxy Mobile IPv4 Extensions defined in this document, it sends a Registration Reply with error code PMIP_UNSUPPORTED ("Proxy Registration not supported by the HA"). In the case when the PMA is not allowed to send a Proxy Registration Request to the HA, the HA sends a Proxy Registration Reply with error code PMIP_DISALLOWED ("Proxy Registrations from this PMA are not allowed").
プロキシ登録リクエストが受信されると、HAはNAIによってインデックス付けされたモビリティバインディングエントリを調べます。エントリが存在する場合、HAは、存在する場合、メッセージとモビリティバインディングエントリ（MBE）の間のシーケンス番号を比較します。メッセージ内の値がMBEの値がゼロまたは等しい場合、HAは登録を受け入れます。HAは、MBEまたはプロキシ登録要求のいずれかの値よりも大きいシーケンス番号で応答します。登録が拒否された場合、HAはエラーコード「管理上禁止（65）」を送信します。HAがプロキシモバイルIPv4で有効になっていない場合、またはこのドキュメントで定義されているプロキシモバイルIPv4拡張機能を処理できない場合、エラーコードPMIP_UNSUPPORTED（「HAによってサポートされていないプロキシ登録」）で登録返信を送信します。PMAがHAにプロキシ登録リクエストを送信することが許可されていない場合、HAはエラーコードPMIP_DISALLOWEDを使用してプロキシ登録返信を送信します（「このPMAからのプロキシ登録は許可されていません」）。
A PMA receiving these error codes SHOULD NOT retry sending Proxy Mobile IPv4 messages to the HA that sent replies with these error codes.
これらのエラーコードを受信するPMAは、これらのエラーコードで返信が送信された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アドレスを使用して常に通信できます。現在添付されているPMAは、モバイルデバイスのトラフィックに適切な転送パスを確保するためにHAに信号を送信します。
When the mobile device accesses the network for the first time and attaches to a network on the PMA, it will present its identity in the form of an NAI to the network as part of the network-access authentication process.
モバイルデバイスが初めてネットワークにアクセスし、PMAのネットワークに接続すると、ネットワークアクセス認証プロセスの一部としてネットワークにNAIの形でアイデンティティを提示します。
Once the address configuration is complete, the mobile device will always be able to use that IP address anywhere in the network.
アドレス構成が完了すると、モバイルデバイスは常にネットワーク内のどこでもそのIPアドレスを使用できます。
When a mobile device moves to a new PMA from another PMA, the following occurs:
モバイルデバイスが別のPMAから新しいPMAに移動すると、以下が発生します。
The mobile device may perform a network-access authentication with the new AR/PMA. If the authentication fails, the mobile device will not be able to use the link. After a successful authentication, the new PMA will have the identifier and the other profile data of the mobile device. The new PMA can also obtain the mobile device's information using a context-transfer mechanism, which is out of the scope of this document.
モバイルデバイスは、新しいAR/PMAを使用してネットワークアクセス認証を実行できます。認証が失敗した場合、モバイルデバイスはリンクを使用できません。認証が成功した後、新しいPMAには識別子とモバイルデバイスの他のプロファイルデータがあります。新しいPMAは、このドキュメントの範囲外であるコンテキスト転送メカニズムを使用して、モバイルデバイスの情報を取得することもできます。
Once the network-access authentication process is complete, the mobile device may sense a change in the Link Layer and use ARP, DHCP, and/or ICMP to detect if it is still on the same subnet. These mechanisms are handled by the network as described in "Appearance of Being At Home Network" (Section 6).
ネットワークアクセス認証プロセスが完了すると、モバイルデバイスはリンクレイヤーの変更を検出し、ARP、DHCP、および/またはICMPを使用して、同じサブネット上にあるかどうかを検出する場合があります。これらのメカニズムは、「在宅ネットワークにある」（セクション6）に記載されているように、ネットワークによって処理されます。
All packets that are to be sent from the mobile device to the Corresponding Node (CN) will be sent as normal IPv4 packets, setting the Source Address of the IPv4 header to the Home Address and the Destination Address to the Corresponding Node's IP address. In Proxy Mobile IPv4 operation, the default gateway for the mobile device is set up to reach the PMA.
モバイルデバイスから対応するノード（CN）に送信されるすべてのパケットは、通常のIPv4パケットとして送信され、IPv4ヘッダーのソースアドレスをホームアドレスに設定し、対応するノードのIPアドレスに宛先アドレスを設定します。プロキシモバイルIPv4操作では、PMAに到達するためにモバイルデバイスのデフォルトゲートウェイが設定されています。
Similarly, all packets sent to the mobile device's IP address by the Corresponding Node will be received by the mobile device in the original form (without any tunneling overhead).
同様に、対応するノードによってモバイルデバイスのIPアドレスに送信されたすべてのパケットは、元の形式のモバイルデバイスによって受信されます（頭上にトンネリングなし）。
For Proxy Mobile IP, the packet from the mobile device is transported to the HA to reach the destination, regardless of the destination IP address. For a CN with an IP address on the same network as the mobile device but that is physically located elsewhere, the HA will tunnel the packet to the CN. Otherwise, the HA forwards the traffic via normal routing.
プロキシモバイルIPの場合、宛先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 Forum Network Working Group（NWG）は、プロキシモバイルIPv4スキームを使用して、IPv4接続とIPモビリティを提供します。Wimaxフォーラムからの関連する仕様は[NWG]です。
The Proxy Mobile IPv4 protocol is used over NWG reference point 3 (R3). Most of the Proxy Mobile IPv4 related procedures and requirements are described in reference to mobility management over R3.
プロキシモバイルIPv4プロトコルは、NWG参照ポイント3（R3）で使用されます。プロキシモバイルIPv4関連の手順と要件のほとんどは、R3を超えるモビリティ管理に関して説明されています。
The Proxy Mobile IPv4 use case in the WiMAX Forum specification is illustrated in the following diagram:
WIMAXフォーラムの仕様のプロキシモバイルIPv4ユースケースについては、次の図に示します。
|
| CSN
|
|
+-------+ | +-------+
| | | | |
|AAAV |--------------|------------| AAAH |
| | | | |
| | | | |
+-------+ | +-------+
| | |
| | |
| | |
+------------------+ | |
| +-------+ | | |
| | NAS | | | |
| | PMIP | ASN1 | | |
| | Client| | | |
| +-------+ | | |
| | | | |
| | R4 | | |
| +-------+ | | +------+
+----+ | | FA, | | | PMIPv4 | |
| MN |-------| DHCP |---------------------------| HA |
+----+ | | Relay/| | | R3 | |
| | Server| ASN2 | | +------+
| +-------+ | |
| | |
+------------------+
Split PMA
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（別名、認証機ASN）のNASと協力されます。NWGアーキテクチャは、ネットワークを2つの部分に分割します。アクセス部品は「アクセスサービスネットワーク」（ASN）と呼ばれます。コアパーツは「接続サービスネットワーク」（CSN）と呼ばれます。MNは、ASN2の802.16ラジオに付着します（別名、アンカーデータパス関数）。ラジオ（ベースステーション）は、ASN2のアンカーデータパス関数（A_DPF）に接続し、ASN1の認証器ASN（NAS）に接続します。ASN1はMNを認証および承認します。AAAインフラストラクチャは、MNを認証および承認するために使用されます。
Note that, during initial network entry by the MN, the PMA can be an integrated PMA with all the functions collocated in ASN1. Due to mobility, the FA part of the PMA may have to be relocated to a more 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部分は、より良いベアラー管理のために、より最適化された場所に移動する必要がある場合があります。ただし、プロキシモバイルIPv4のWIMAX固有のユースケースを説明するために、WiMax NWGモビリティフレームワークのより一般的な表現であるため、Split 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]のセクション4.3、ステージ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:
Wimax NWGのプロキシモバイルIPv4操作は、このドキュメントのセクション4で説明されているように、基本的なプロキシモバイル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.
1. プロキシモバイルIPv4登録のためのPER-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).
2. PMIPV4クライアントはNAS（Authenticator 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]で使用されます。
4. GRE key identifier is optionally used between the HA and the PMA.
4. GREキー識別子は、HAとPMAの間でオプションで使用されます。
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. Inter-ASN（Inter Accessルーター）のハンドオーバーを処理し、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モデルを使用するため、コールフローには、PMIPv4クライアントとPMA内のFAの間のWIMAX独自のシグナル伝達が含まれます。次の呼び出しフローはこれを示しています。
Split PMA
+-----------------------------------+
+----+ | +------+ +------+ +-----+ | +-----+
| | | | NAS/ | | Old | | New | | | |
| MN | | | PMIP | | FA | | FA | | | HA |
| | | |Client| | | | | | | |
+----+ | +------+ +------+ +-----+ | +-----+
| +----|------------|------------|----+ |
| | | PMIP Tunnel |
| | |<=======================>|
| | | | |
| | | R4 tunnel | |
| | |<==========>| |
| | 1 | | |
|<---------------------------------->| |
| | | | |
| | | 2 | |
| | |<---------->| |
| | 3 | | |
| |<----------------------- | |
| | | | |
| | 4 | | |
+-> | |------------------------>| |
| | | | | 5 |
| | | | |----------->|
| | | | | |
PMIP | | | | | 6 |
| | | | |<-----------|
| | | | | |
| | | 7 | | |
+-> | |<------------------------| |
| | | | |
| | | 8 | |
| | |<---------->| |
| | | | |
| 9 | | |PMIP Tunnel |
Data |<---------------------------------->|<==========>|
Forwarding | | | | |
Figure 6: Proxy Handover Operation in WiMAX with Split PMA
図6：スプリットPMAを使用したWimaxでのプロキシハンドオーバー操作
In this scenario, the MN has moved to a new FA's area (known as the Data Path Function in WiMAX). The old FA and the new FA interact with each other and also with the PMIPv4 client over a WiMAX-specified R4 reference point to perform the handover. The steps are described below:
このシナリオでは、MNは新しいFAの領域（WIMAXのデータパス関数として知られています）に移動しました。古いFAと新しいFAは、互いに相互作用し、またWIMAX指定のR4基準点を介してPMIPV4クライアントと対話し、ハンドオーバーを実行します。手順を以下に説明します。
1. The mobile device establishes a L2 link with a base station (not shown), which connects to a new FA (aka, new Data Path Function in WiMAX). Note that, in this case, the MN does not perform authentication and authorization. The PMIPv4 tunnel remains between the old FA (aka, old Data Path Function in WiMAX). The data flows through the PMIPv4 tunnel between the HA and the old FA, and through the WiMAX-specific R4 tunnel between the old FA and the new FA and from the new FA to the MN.
1. モバイルデバイスは、ベースステーション（図示せず）にL2リンクを確立します。これは、新しいFA（別名、Wimaxの新しいデータパス関数）に接続します。この場合、MNは認証と承認を実行しないことに注意してください。PMIPV4トンネルは、古いFA（別名、WIMAXの古いデータパス関数）の間に残ります。データは、HAと古いFAの間のPMIPV4トンネルを通過し、古いFAと新しいFAの間のWIMAX固有のR4トンネルを通過し、新しいFAからMNに流れます。
2. The new FA interacts with the old FA using a WiMAX-specific R4 reference point to initiate the handover process.
2. 新しいFAは、WIMAX固有のR4基準点を使用して古いFAと対話し、ハンドオーバープロセスを開始します。
3. The new FA uses the WiMAX-specific R4 reference point to request the PMIPv4 client to begin the PMIPv4 handover.
3. 新しいFAは、WIMAX固有のR4基準点を使用して、PMIPV4クライアントにPMIPV4ハンドオーバーを開始するよう要求します。
4. Triggered by step 3, the PMIPv4 client sends a PRRQ to the new FA. The PRRQ contains the FA-CoA of the new FA. The Home Address field is set to the address of the assigned IP address of the Mobile Node. The PRRQ is embedded in the WiMAX-specific R4 packet.
4. ステップ3でトリガーされたPMIPV4クライアントは、PRRQを新しいFAに送信します。PRRQには、新しいFAのFA-COAが含まれています。ホームアドレスフィールドは、モバイルノードの割り当てられたIPアドレスのアドレスに設定されています。PRRQは、WIMAX固有のR4パケットに埋め込まれています。
5. The new FA forwards the PRRQ to the HA.
5. 新しいFAは、PRRQをHAに転送します。
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は、WIMAX固有のR4パケットでPMIPV4クライアントにカプセル化した後、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スキームを使用して、以下のシナリオにモビリティサービスを提供します（以下の図に示すように）：
1. Mobility between the base station (BS) and access gateway (AGW)
1. 基地局（BS）とアクセスゲートウェイ（AGW）の間のモビリティ
2. Mobility between the AGW and the Home Agent (HA).
2. AGWとホームエージェント（HA）の間のモビリティ。
As shown in the diagrams below, in use case 1, the BS acts as the PMA and the AGW acts as the HA for Proxy Mobile IPv4 operation. In use case 2, the AGW acts as the PMA while the HA assumes the role of the Home Agent.
以下の図に示すように、ユースケース1では、BSはPMAとして機能し、AGWはプロキシモバイルIPv4操作のHAとして機能します。ユースケース2では、AGWはPMAとして機能し、HAはホームエージェントの役割を引き受けます。
RAN Core
走ったコア
+-------+ +------+
+----+ | BS/ | PMIPv4 | |
| MN |------| PMA |-----------------------| AGW/ |
+----+ | | | HA |
| | +------+
+-------+
Integrated PMA
統合されたPMA
Figure 7: 3GPP2's PMIPv4 Use Case 1 - BS-AGW Interface Mobility
図7：3GPP2のPMIPV4ユースケース1 -BS -AGWインターフェイスモビリティ
RAN Core
走ったコア
+-------+ +------+
+----+ | AGW/ | PMIPv4 | |
| MN |------| PMA |-----------------------| HA |
+----+ | | | |
| | +------+
+-------+
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（ケース1）のプロキシモバイルIPv4使用シナリオを次の図に示します。
+----+ +-------+ +-------+ +------+
| | | | | | | |
| 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はULTRAモバイルブロードバンド（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。BSは、MNを認証するためにAR（図には示されていない）を介してHome AAAサーバーとAAAメッセージを交換します。このステップの一部として、ARはMNに関する情報をダウンロードする場合があります（例：ユーザーのプロファイル、携帯電話タイプ、割り当てられたホームエージェントアドレス、およびMNのその他の機能）。この情報は、次のステップで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.
3. ステップ2でトリガーされたPMA/BSは、AGW/HAにPRRQを送信します。HAのアドレスは、Home AAAサーバー（HAAA）からステップ1Bで受信されるか、他の手段によって発見されます。PRRQには、PMA（この場合はColocated FA）の住所（COA）のケア（COA）が含まれています。HOAフィールドは、すべてのゼロ（またはすべてのゼロ）に設定されています。PRRQは、このドキュメントで説明されている方法によって保護されています。MN-HAまたはFA-HAキーの派生と分布は、このドキュメントの範囲外です。
4. The AGW/HA registers the MN's session, assigns a symmetric GRE key, and returns this key in the PRRP to the BS/PMA.
4. AGW/HAはMNのセッションを登録し、対称GREキーを割り当て、PRRPのこのキーをBS/PMAに返します。
5. The BS/PMA responds back to the MN with a layer 2 signaling message.
5. BS/PMAは、レイヤー2シグナル伝達メッセージでMNに返信されます。
6. At this step, the MN is assigned an IP address and is connected to the network (via the AGW).
6. このステップでは、MNにIPアドレスが割り当てられ、ネットワークに接続されています（AGW経由）。
In use case 2, the same procedures are followed except the PMIPv4 tunnel is established between the AGW and the HA. In this case, GRE tunneling may not be used.
ユースケース2では、AGWとHAの間にPMIPV4トンネルが確立されることを除いて、同じ手順に従います。この場合、GREトンネルは使用されない場合があります。
There are some special handover considerations in 3GPP2's Proxy Mobile IPv4 use case. Below is an illustration of the specific use case:
3GPP2のプロキシモバイルIPv4ユースケースには、特別なハンドオーバーに関する考慮事項があります。以下は、特定のユースケースの例です。
+----+ +-------+ +-------+ +-------+
| | | | | | | |
| MN | | New | | AGW/ | | Old |
| | | PMA/BS| | HA | | PMA/BS|
+----+ +-------+ +-------+ +-------+
| | | |
| | 1 | |
| |------------->| |
| | | |
| | | |
| | o 2 |
| | | |
| | | |
| | 3 | |
| |<-------------| |
| | | |
| | | |
| | 4 | |
| |<----------------------->|
| | | |
| | | |
| | | o 5
| | | |
| | | |
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を検証し、MBEのMBEを更新します。MBEはこの時点で暫定的に保たれます。
3. The AGW sends a Proxy Registration Reply to the new BS. No Registration Revocation is used in the 3GPP2's use case.
3. AGWは、新しいBSへのプロキシ登録返信を送信します。3GPP2のユースケースでは、登録の取り消しは使用されません。
4. A 3GPP2's proprietary PMA movement notification message may be exchanged between the AGW and the old BS.
4. 3GPP2の独自のPMA運動通知メッセージは、AGWと古いBSの間で交換される場合があります。
5. The MBE update with the new BS is committed at this step.
5. 新しいBSでのMBEアップデートは、このステップでコミットされます。
This specification registers 47 for the Proxy Mobile IPv4 Non-Skippable Extension and 147 for Proxy Mobile IPv4 Skippable Extension, both of which are described in Section 5. The ranges for Mobile IPv4 [RFC3344] extension types are defined at http://www.iana.org. This specification also creates a new subtype space for the type number of the extensions. The subtype value 1 is defined for the PMIPv4 Non-Skippable Extension. The subtype values 1 to 4 are defined for the PMIPv4 Skippable Extension. Similar to the procedures specified for Mobile IPv4 number spaces, future allocations from the number space require expert review [RFC5226].
この仕様は、プロキシモバイルIPv4非スキップ可能な拡張機能の場合は47、プロキシモバイルIPv4スキップ可能な拡張機能の場合は147を記録します。どちらもセクション5で説明されています。iana.org。この仕様は、拡張機能のタイプ番号の新しいサブタイプ空間も作成します。SubType値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 Expert Reviewを通じて行われます。
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 Expert Reviewを通じて行われます。
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 Expert Reviewを通じて行われます。
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 Expert Reviewを通じて行われます。
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).
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）、およびSri Gundavelli（Cisco）。
[3GPP2] "3GPP2 Basic IP Service for Converged Access Network", X.S0054-100-0 Version 2.0, August 2008.
[3GPP2]「3GPP2コンバージドアクセスネットワーク用の基本IPサービス」、X.S0054-100-0バージョン2.0、2008年8月。
[NWG] "WiMAX Forum Network Architecture (Stage 3: Detailed Protocols and Procedures)" Release 1, Version 1.2.3, July 2008.
[NWG] "Wimaxフォーラムネットワークアーキテクチャ（ステージ3：詳細プロトコルと手順）"リリース1、バージョン1.2.3、2008年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024] Montenegro、G.、ed。、「モバイルIPの逆トンネル、改訂」、RFC 3024、2001年1月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543] Glass、S。およびM. Chandra、「モバイルIPv4の登録の取り消し」、RFC 3543、2003年8月。
[MIP4GREKEY] Yegani, P., "GRE Key Extension for Mobile IPv4", Work in Progress, June 2007.
[Mip4grekey] Yegani、P。、「モバイルIPv4のGREキーエクステンション」、2007年6月、進行中の作業。
[MIP4MCBC] Chakrabarti, S., "IPv4 Mobility extension for Multicast and Broadcast Packets", Work in Progress, November 2007.
[MIP4MCBC] Chakrabarti、S。、「マルチキャストおよびブロードキャストパケットのIPv4モビリティ拡張」、2007年11月、進行中の作業。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005.
[RFC4058] Yegin、A.、ed。、Ohba、Y.、Penno、R.、Tsirtsis、G。、およびC. Wang、「ネットワークアクセス（PANA）要件のための認証を運ぶためのプロトコル」、RFC 4058、2005年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4332] Leung, K., Patel, A., Tsirtsis, G., and E. Klovning, "Cisco's Mobile IPv4 Host Configuration Extensions", RFC 4332, December 2005.
[RFC4332] Leung、K.、Patel、A.、Tsirtsis、G。、およびE. Klovning、「CiscoのモバイルIPv4ホスト構成拡張機能」、RFC 4332、2005年12月。
[RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006.
[RFC4433] Kulkarni、M.、Patel、A。、およびK. Leung、「モバイルIPv4ダイナミックホームエージェント（HA）割り当て」、RFC 4433、2006年3月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「IPv4（DNAV4）のネットワークアタッチメントの検出」、RFC 4436、2006年3月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454] Tsirtsis、G.、Park、V。、およびH. Soliman、「Dual Stack Mobile 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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、1982年11月、STD 37、RFC 826。
[RFCICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFCICMP] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
Authors' Addresses
著者のアドレス
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
Kent Leung Cisco Systems 170 West Tasman Drive San Jose、CA 95134 US
EMail: kleung@cisco.com
Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose、CA 95134 US
EMail: gdommety@cisco.com
Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206
Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089-1206
EMail: pyegani@juniper.net
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury、MA 01876 USA
EMail: kchowdhury@starentnetworks.com