Network Working Group E. Fogelstroem
Request for Comments: 4857 A. Jonsson
Category: Experimental Ericsson
C. Perkins
Nokia Siemens Networks
June 2007
Mobile IPv4 Regional Registration
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol.
モバイルIPを使用して、モバイルノードは、そのホームエージェントと、それは気付アドレスを変更するたびに登録します。この文書では、訪問先ドメインにローカルな「地域登録」、すなわち、登録の新しい種類を記述する。地域の登録は、ゲートウェイ外部エージェント（GFA）と呼ばれる新しいネットワークエンティティを介して行うと、訪問したドメイン内の階層構造の層を導入しています。地域の登録は、ホームネットワークにシグナリングメッセージの数を減らし、シグナリング遅延を低減する際、同じ訪問先ドメイン内の別の外国人のエージェントからモバイルノードに移動します。この文書では、モバイルIPv4プロトコルにオプションの拡張です。
Table of Contents
目次
1. Introduction ....................................................3
2. Overview of Regional Registrations ..............................4
3. Terminology .....................................................5
4. Description of the Protocol .....................................7
4.1. General Assumptions ........................................7
4.1.1. Visited Domain ......................................8
4.1.2. Authentication ......................................8
4.2. Protocol Overview ..........................................9
4.3. Advertising Foreign Agent and GFA .........................10
4.4. Backwards Compatibility with RFC 3344 .....................10
5. Home Registration ..............................................11
5.1. Mobile Node Considerations ................................11
5.2. Foreign Agent Considerations ..............................12
5.3. GFA Considerations ........................................13
5.4. Home Agent Considerations .................................14
6. Regional Registration ..........................................14
6.1. Mobile Node Considerations ................................15
6.2. Foreign Agent Considerations ..............................16
6.3. GFA Considerations ........................................16
7. Dynamic GFA Assignment .........................................17
7.1. Mobile Node Considerations for Dynamic GFA Assignment .....17
7.2. Foreign Agent Considerations for Dynamic GFA Assignment ...17
7.3. GFA Considerations for Dynamic GFA Assignment .............18
7.4. Home Agent Considerations for Dynamic GFA Assignment ......18
7.5. Regional Registration .....................................19
8. Router Discovery Extensions ....................................19
8.1. Regional Registration Flag ................................19
8.2. Foreign Agent NAI Extension ...............................19
9. Regional Extensions to Mobile IPv4 Registration Messages .......20
9.1. GFA IP Address Extension ..................................20
9.2. Hierarchical Foreign Agent Extension ......................21
9.3. Replay Protection Style ...................................22
9.4. Regional Registration Lifetime Extension ..................23
9.5. New Code Values for Registration Reply ....................24
10. Regional Registration Message Formats .........................25
10.1. Regional Registration Request ............................26
10.2. Regional Registration Reply ..............................27
10.3. New Regional Registration Reply Code Values ..............28
11. Authentication Extensions .....................................29
12. Security Considerations .......................................29
13. IANA Considerations ...........................................30
14. Acknowledgements ..............................................31
15. References ....................................................32
15.1. Normative References .....................................32
15.2. Informative References ...................................32
Appendix A. Authentication, Authorization, and Accounting (AAA)
Interactions ..........................................33
Appendix B. Anchoring at a GFA ....................................33
This document is an optional extension to the Mobile IPv4 protocol, and proposes a means for mobile nodes to register locally within a visited domain. By registering locally, the number of signaling messages to the home network are kept to a minimum, and the signaling delay is reduced.
この文書では、モバイルIPv4プロトコルにオプションの拡張であり、モバイルノードが訪問先ドメイン内で局所的に登録するための手段を提案しています。ローカルに登録することにより、ホームネットワークへのシグナリングメッセージの数が最小限に抑えられ、シグナリング遅延が低減されます。
In Mobile IP, as specified in [RFC3344], a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a solution for performing registrations locally in the visited domain: regional registrations. Regional registrations minimize the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This will both decrease the load on the home network, and speed up the process of handover within the visited domain.
モバイルIPにおいては、[RFC3344]で指定されるように、モバイルノードは、そのホームエージェントにそれが気付アドレスを変更するたびに登録します。訪問先ネットワークとモバイルノードのホーム・ネットワークの間の距離が大きい場合には、これらの登録のためのシグナリング遅延が長くなることがあります。地域の登録：私たちは、訪問先ドメインでローカルに登録を実行するためのソリューションを提案しています。地域の登録は、ホームネットワークにシグナリングメッセージの数を最小限にし、モバイルノードが同じ訪問したドメイン内の別の外国人のエージェントから移動したときのシグナリング遅延を減少させます。これは、ホームネットワーク上の負荷を減少させ、そして訪問したドメイン内のハンドオーバのプロセスをスピードアップします両方。
Regional registrations introduce a new network node: the Gateway Foreign Agent (GFA). The address of the GFA is advertised by the foreign agents in a visited domain. When a mobile node first arrives at this visited domain, it performs a home registration -- that is, a registration with its home agent. At this registration, the mobile node registers the address of the GFA as its care-of address with its home agent. When moving between different foreign agents within the same visited domain, the mobile node only needs to make a regional registration to the GFA.
ゲートウェイ外部エージェント（GFA）：地域の登録は、新しいネットワーク・ノードを導入します。 GFAのアドレスが訪問ドメインに外国人のエージェントによってアドバタイズされます。モバイルノードが最初にこの訪問先ドメインに到着すると、ホーム登録を行う - それは、そのホームエージェントへの登録です。この登録では、モバイルノードはその気付アドレスのホームエージェントと同様にGFAのアドレスを登録します。同じ訪問先ドメイン内の異なる外国人のエージェント間で移動する場合、移動ノードは、GFAに地域の登録を行う必要があります。
In their simplest form, regional registrations are performed transparently to the home agent. Additionally, regional registrations may also allow dynamic assignment of GFA. The solution for dynamic GFA assignment requires support in the mobile node, the foreign agent, the GFA, and the home agent.
最も単純な形式では、地域の登録は、ホームエージェントに透過的に実行されています。また、地域の登録もGFAの動的な割り当てを可能にすることができます。ダイナミックGFAの割り当てのためのソリューションは、モバイルノード、外部エージェント、GFA、およびホームエージェントでサポートが必要です。
The proposed regional registration protocol supports one level of foreign agent hierarchy beneath the GFA, but the protocol may be utilized to support several levels of hierarchy. Multiple levels of hierarchy are not discussed in this document.
提案された地域の登録プロトコルは、GFAの下に外国人のエージェント階層の1つのレベルをサポートしますが、プロトコルは、階層の複数のレベルをサポートするために利用することができます。階層の複数のレベルは、このドキュメントで説明されていません。
Although this document focuses on regional registrations in visited domains, regional registrations are also possible in the home domain.
この文書は訪問したドメインの地域登録に焦点を当てているが、地域の登録はホームドメインでも可能です。
Foreign agents that support regional registrations are also required to support registrations according to Mobile IPv4 [RFC3344].
地域の登録をサポートする外国剤はまた、モバイルIPv4 [RFC3344]に従って登録をサポートするために必要とされます。
The following section gives an overview of regional registrations.
次のセクションでは、地域の登録の概要を説明します。
In standard Mobile IP, there are three entities of interest. The Mobile Node (MN), the Foreign Agent (FA), and the Home Agent (HA). The MN communicates with the HA, either through an FA or directly (if it has a co-located care-of address). With Regional Registrations, a new entity is defined: the Gateway Foreign Agent (GFA). The GFA sits between the MN/FA and HA, and to the HA, it appears as if the MN's temporary care-of address is that of the GFA. When a MN moves within a site, it only need interact with the GFA, so that the GFA knows at what temporary address the MN is currently reachable.
標準のモバイルIPでは、関心の3つのエンティティがあります。モバイルノード（MN）、外部エージェント（FA）と、ホームエージェント（HA）。 MNがFAを介して、または直接のいずれか、HAと通信し（それは同じ場所に配置さ気付アドレスを持っている場合）。地域登録して、新しいエンティティが定義されている：ゲートウェイ外部エージェント（GFA）。 GFAは、MN / FAとHAの間に位置し、MNの一時的な気付アドレスはGFAのものであるかのようにHAに、それが表示されます。 MNは、サイト内を移動すると、それだけでGFAは、MNが現在到達可能な一時的なものをアドレスに知っているように、GFAと対話する必要があります。
Two types of registration messages are used. Regular [RFC3344] Registration Requests/Replies are still used for when the MN exchanges Registration Requests/Replies with the HA, but these messages get forwarded through a GFA, and include new extensions.
登録メッセージの二つのタイプが使用されています。定期的な[RFC3344]登録要求/回答はまだMN交換の登録要求が/ HAに返信するときに使用されているが、これらのメッセージは、GFAを介して転送を取得し、新しい拡張機能が含まれます。
In addition, a new pair of registration messages, Regional Registration Requests/Replies, are used between MNs/FAs/GFAs for intra-site signaling. A MN uses these messages to communicate its new addresses to the GFA as it moves around within a site.
また、登録メッセージ、地域の登録要求/回答の新しいペアは、サイト内のシグナル伝達のためのMN /のFA / GFAsの間で使用されています。 MNは、それがサイト内で動き回るようGFAにその新しいアドレスを伝えるために、これらのメッセージを使用しています。
There are two models of how the MN uses Regional Registrations. The FA can advertise a GFA to the MN. Alternatively, the FA can indicate that dynamic assignment of GFA is to be used. With dynamic GFA assignment, the MN does not choose the GFA, rather the FA (or GFA) does so after receiving a Registration Request from the MN. However, in this mode the HA must understand (and support) Regional Registrations in order for them to be used. This last form is not transparent because the MN doesn't know in advance what GFA will be used, and cannot include it in a signed message to the HA.
MNは、地域の登録を使用する方法の2つのモデルがあります。 FAは、MNにGFAを宣伝することができます。あるいは、FAはGFAの動的割り当てが使用されることを示すことができます。ダイナミックGFAの割り当てでは、MNはGFAを選択していない、FA（またはGFA）ではなくMNからの登録要求を受信した後、そのようにします。しかし、このモードでは、HAは、それらを使用するための地域登録の理解（とサポート）しなければなりません。 MNはGFAが使用されるかを事前に知っていない、とHAに署名されたメッセージに含めることはできませんので、この最後の形式は透明ではありません。
When a MN moves to a new domain (determined by comparing its Network Access Identifier (NAI) [RFC4282] with the FA-NAI included in received Agent Advertisements), it can opt to use Regional Registrations. A site indicates support for Regional Registrations by setting the I-bit of the Mobile IP Agent Advertisement extension. In addition, such advertisements include a list of one or more care-of addresses. If there is only one care-of address, this is the address of the FA itself. In addition, the advertisement may include the address of the GFA. A GFA care-of address of all-ones indicates that dynamic assignment of GFA is supported.
MNは、（FA-NAIとのネットワークアクセス識別子（NAI）[RFC4282]は受信したエージェント広告に含まれる比較することによって決定された）新しいドメインに移動するとき、それは地域の登録を使用することを選ぶことができます。このサイトは、モバイルIPエージェント広告拡張のIビットを設定することにより、地域の登録のためのサポートを示します。さらに、このような広告は、一つ以上の気付アドレスのリストが含まれています。唯一の気付アドレスがある場合、これはFA自身のアドレスです。また、広告はGFAのアドレスを含んでいてもよいです。 GFAのケア - のすべてのもののアドレスは、GFAの動的な割り当てがサポートされていることを示しています。
A MN requests initial Regional Registration by sending a normal Registration Request to the FA, but setting the care-of address to that of the GFA (i.e., if it has selected it wishes to use this GFA) or all-zeros (which signals a dynamic GFA assignment request). The FA adds a Hierarchical FA (HFA) extension and relays the request to the appropriate GFA. The HFA extension contains a single field: the IP address of the FA.
MNは、FAに、通常の登録リクエストを送信することにより、初期地域の登録を要求したが、信号GFA（すなわち、それがこのGFAを使用したいを選択した場合）、またはすべてゼロ（のことに気付アドレスを設定します動的GFA割当要求）。 FAは、階層FA（HFA）拡張子を追加し、適切なGFAに要求を中継します。 FAのIPアドレス：HFAの拡張子は、単一のフィールドが含まれています。
Note: the algorithm for MNs with co-located care-of addresses is similar, except that there is no FA, so the MN behaves as the FA in terms of the messages it sends.
注意：同じ場所に配置気付アドレスとのMNのためのアルゴリズムは、MNは、それが送信するメッセージの面でFAとして振る舞うので、何のFAが存在しないことを除いて、同様です。
A GFA receives Registration Requests relayed from an FA. If the care-of address in the received Registration Request is zero, the GFA assigns one. A GFA IP Address extension is then added to the Registration Request, and the message is forwarded to the HA. The GFA IP Address extension contains a single field: the IP address of the GFA. (A separate field is needed for this because the Registration Request message between the MN/HA is signed and cannot be modified.)
GFAはFAから中継された登録要求を受け取ります。気付けアドレス受信登録要求にはゼロの場合、GFAは1が割り当てられます。 GFA IPアドレス拡張は、登録要求に追加され、メッセージがHAに転送されます。 GFAのIPアドレス：GFA IPアドレス拡張は、単一のフィールドが含まれています。 （MN / HAとの間のRegistration Requestメッセージが署名され、変更することができないので、別のフィールドは、このために必要とされます。）
HAs process received Registration Requests in the same way as before, except in the case of dynamic GFA assignment. In this case, the HA uses the GFA address from the GFA IP Address extension as the MN's current care-of address. In addition, the Registration Reply message must include the GFA IP Address extension.
プロセスは、動的GFA割り当ての場合を除いて、前と同じように登録要求を受信しました。この場合、HAは、MNの現在の気付アドレスとしてGFA IPアドレスの延長からGFAアドレスを使用しています。また、登録応答メッセージは、GFA IPアドレスの拡張子を含める必要があります。
The regular Registration Requests/Replies are protected as described in [RFC3344], by use of the mobility security association between the MN and the HA. For regional registrations, it is assumed that a mobility security association is established between the MN and GFA during registration with the HA. Regional Registration Requests/ Replies are protected by use of this security association between the MN and the GFA, e.g., by use of a MN-GFA Authentication extension.
[RFC3344]で説明したように、通常の登録要求/返信はMNとHAの間のモビリティセキュリティアソシエーションを使用することにより、保護されています。地域の登録のためには、モビリティセキュリティアソシエーションがHAへの登録時にMNとGFAの間で確立されているものとします。地域の登録要求/返信は、MN-GFA認証拡張を使用することによって、例えば、MNとGFAの間に、このセキュリティアソシエーションを使用することによって保護されています。
HFA extensions, added by an FA to a Registration Request or Regional Registration Request, are protected by an FA-FA Authentication extension. Security associations between FAs and GFAs within a domain are assumed to exist prior to regional registrations.
登録要求や地域の登録要求にFAで追加されたHFAの拡張は、FA-FA認証拡張により保護されています。ドメイン内のFAとGFAs間のセキュリティアソシエーションは、前の地域登録に存在すると仮定されています。
Dynamic GFA assignment requires means for securely sending Registration Requests from the GFA to the HA, in order to protect the GFA IP Address extension.
ダイナミックGFAの割り当てが確実にGFA IPアドレス拡張を保護するために、HAにGFAからの登録要求を送信するための手段を必要とします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
Critical type A type value for an extension in the range 0-127, which indicates that the extension MUST either be known to the recipient, or that the message containing the extension MUST be rejected. In other words, an extension with a critical type value is non-skippable.
拡張子がいずれかの受信者に知られていなければならないこと、または内線番号を含むメッセージを拒否しなければならないことを示す範囲0-127、に拡張するために重要タイプAタイプ値。つまり、重要なタイプの値を持つ拡張は非スキップ可能です。
Domain A collection of networks sharing a common network administration.
ドメインの一般的なネットワーク管理を共有するネットワークの集合体。
Foreign Agent (FA) As defined in [RFC3344].
外部エージェント（FA）[RFC3344]で定義されているように。
Gateway Foreign Agent (GFA) A Foreign Agent which has a publicly routable IP address. A GFA may, for instance, be placed in or near a firewall.
公にルーティング可能なIPアドレスを持つゲートウェイ外部エージェント（GFA）フォーリンエージェント。 GFAは、例えば、ファイアウォール内または近くに配置されてもよいです。
Home Agent (HA) As defined in [RFC3344].
ホームエージェント（HA）[RFC3344]で定義されているように。
Home domain The domain where the home network and home agent are located.
ホームドメインのホームネットワークとホームエージェントが存在するドメイン。
Home network As defined in [RFC3344].
[RFC3344]で定義されているように、ホームネットワーク。
Home Registration A registration, processed by the home agent and the GFA, using the specification in [RFC3344] possibly with additional extensions defined in this document.
ホーム登録この文書で定義された追加の拡張子を持つ可能性が[RFC3344]で仕様を使用して、ホームエージェントとGFAによって処理の登録、。
Local Care-of Address A care-of address that is assigned to either a mobile node or a foreign agent offering local connectivity to a mobile node. A registration message from the mobile node is subsequently sent to a GFA via the local care-of address.
ローカル気付アドレス気付アドレスモバイルノードまたはモバイルノードにローカル接続性を提供する外国人のエージェントのいずれかに割り当てられています。モバイルノードからの登録メッセージは、その後、ローカル気付アドレスを介しGFAに送信されます。
Mobile Node (MN) As defined in [RFC3344].
[RFC3344]で定義されているように、モバイルノード（MN）。
Mobility Agent (MA) As defined in [RFC3344].
モビリティエージェント[RFC3344]で定義されているように（MA）。
Network Access Identifier(NAI) Some features of this protocol specification rely on use of the Network Access Identifier (NAI) [RFC2794].
ネットワークアクセス識別子（NAI）は、このプロトコル仕様の一部の機能は、ネットワークアクセス識別子（NAI）[RFC2794]の使用に依存します。
Regional Registration A mobile node performs registration locally at the visited domain, by sending a Regional Registration Request to a GFA, and receiving a Regional Registration Reply in return.
地域の登録モバイルノードは、GFAの地域登録リクエストを送信し、見返りに地域登録応答を受信することにより、訪問先ドメインでローカルに登録を行います。
Registration Key A key used by mobile nodes and mobility agents to secure certain signals and control messages specified by Mobile IP.
特定の信号を確保し、モバイルIPによって指定されたメッセージを制御するために、モバイルノードと移動エージェントが使用する登録キーのキー。
Visited domain The domain where the visited network, the current foreign agent, and the GFA are located.
訪問先ドメイン訪問先ネットワーク、現在の外部エージェント、およびGFAが配置されているドメイン。
Visited network As defined in [RFC3344].
[RFC3344]で定義されるようなネットワークを訪問しました。
This section provides an overview of the regional registration protocol.
このセクションでは、地域の登録プロトコルの概要を説明します。
Our general model of operation is illustrated in Figure 1, showing a visited domain with FA and GFA, and a home network with a HA:
操作の私たちの一般的なモデルはFAとGFA、およびHAとホームネットワークと訪問したドメインを示す、図1に示します。
+---------------------------+ +----------------+
| Visited Domain | | Home |
| | +---------+ | Network |
| | | | | |
| +------+ +-------+ | | Public | | +------+ |
| | FA |------| GFA |-------------------------| HA | |
| +--+---+ +-------+ | | Network | | +------+ |
| | | | | | |
+-----|---------------------+ +---------+ +----------------+
|
+--+---+
| MN |
+------+
Figure 1: Model of Operation
図1：動作のモデル
For MNs that cannot process a NAI, or with mobility agents that are not configured to advertise their NAI, regional registration is still useful, but processing the NAI makes it easier for the mobile node to reliably detect domain changes.
NAIを処理できないMNの場合、またはそのNAIを宣伝するように設定されていないモビリティエージェントと、地域の登録はまだ有用ですが、NAIを処理することは、より簡単にモバイルノードが確実にドメインの変更を検出できるようになります。
We assume two hierarchy levels of FAs in the visited domain. At the top level of the hierarchy, there is at least one GFA, which is an FA with additional features. A GFA must have a publicly routable address. Beneath a GFA, there are one or more FAs. We assume that there exist established security associations between a GFA and the FAs beneath it. When designing a domain supporting regional registrations, the FAs and GFAs in this domain must be compatible. That is, they should support the same encapsulation types, compression mechanisms, etc.
私たちは、訪問先ドメイン内のFAの2つの階層レベルを想定しています。階層の最上位レベルでは、追加機能を持つFA少なくとも一つGFAがあります。 GFAは、公にルーティング可能なアドレスを持っている必要があります。 GFAの下に、一の以上のFAがあります。私たちは、GFAとその下のFAとの間に確立されたセキュリティ結合が存在することを前提としています。地域の登録をサポートするドメインを設計するときは、このドメイン内のFAとGFAsは互換性がなければなりません。つまり、彼らは同じカプセル化タイプ、圧縮機構などをサポートする必要があります
When a MN changes care-of address under the same GFA, it MAY perform a regional registration. If the MN changes GFA, within a visited domain or between visited domains, it MUST perform a home registration.
MNは同じGFA下の気付アドレスを変更すると、それは地域の登録を行うことができます。 MNは訪問先ドメイン内または訪問したドメイン間で、GFAを変更する場合は、ホーム登録を実行しなければなりません。
With regional registrations, a GFA address is registered at the HA as the care-of address of the MN. If a Mobile-Foreign (MN-FA) Authentication extension is present in a Registration Request message directed to the HA, the GFA will perform the authentication. Similarly, if a Foreign-Home (FA-HA) Authentication extension is present in a Registration Request message, the authentication is performed between the GFA and the HA. To summarize, the GFA takes the role of an FA with regard to security associations in the home registrations.
地域の登録で、GFAアドレスは気付MNのアドレスとしてHAに登録されています。モバイル外国（MN-FA）認証拡張は、HAに向けRegistration Requestメッセージ内に存在する場合、GFAは、認証を実行します。外国ホーム（FA-HA）認証拡張子が登録要求メッセージに存在する場合も同様に、認証がGFAとHAとの間で行われます。要約すると、GFAは、ホーム登録でセキュリティアソシエーションに関して、FAの役割を果たしています。
Regional registration messages also need to be protected with authentication extensions in the same way as registrations with the HA. This means that the MN and the GFA MUST have received the keys needed to construct the authentication extensions before any regional registration is performed. As described above, since the GFA address is the registered care-of address of the MN at its home network, the GFA is the agent within the visited domain that has to have the appropriate security associations with the HA and the MN. The GFA's security association with the MN is then used to enable proper authentication for regional registrations (see Section 6). How the keys are distributed is outside the scope of this draft. One example is to distribute the keys as part of the home registration, for example according to [RFC4004] and [RFC3957]. Another example is pre-configured keys.
地域の登録メッセージはまた、HAと登録と同じ方法で認証の拡張機能で保護する必要があります。これは、MNとGFAは、任意の地域の登録が行われる前に、認証の拡張機能を構築するために必要なキーを受け取っていなければならないことを意味します。 GFAアドレスが登録気付けそのホームネットワークでのMNのアドレスであることから、前述したように、GFAは、HAとMNとの適切なセキュリティアソシエーションを持つ必要が訪問先ドメイン内のエージェントがあります。 MNとGFAのセキュリティアソシエーションは、その後、地域の登録のための適切な認証を有効にするために使用された（第6節を参照してください）。キーがどのように分布しているか、この案の範囲外です。一例では、[RFC4004]及び[RFC3957]によれば、例えば、ホーム登録の一部としてキーを配布することです。別の例では、事前に設定キーです。
When a MN first arrives at a visited domain, it performs a registration with its home network. During this registration, the HA registers the care-of address of the MN. In case the visited domain supports regional registrations, the care-of address that is registered at the HA is the address of a GFA. The GFA keeps a visitor list of all the MNs currently registered with it.
MNは、最初の訪問先ドメインに到着したとき、それはそのホームネットワークに登録を行います。この登録時に、HAは気付MNのアドレスを登録します。ケースで訪問したドメインは地域の登録をサポートし、気付アドレスHAに登録されGFAのアドレスです。 GFAは、現在、それに登録されているすべてのMNの訪問者リストを保持します。
Since the care-of address registered at the HA is the GFA address, it will not change when the MN changes FA under the same GFA. Thus, the HA does not need to be informed of further MN movements within the visited domain.
気付けHAに登録されたアドレスは、GFAアドレスであるので、MNは同じGFAの下にFAを変更したとき、それは変更されません。したがって、HAは、訪問先ドメイン内でさらにMNの動きを知らされる必要はありません。
Figure 2 illustrates the signaling message flow for home registration. During the home registration, the HA records the GFA address as the care-of address of the MN.
図2は、ホーム登録のためのシグナリングメッセージフローを示します。ホーム登録時には、HAは気付MNのアドレスとしてGFAアドレスを記録します。
MN FA1 GFA HA
| | | |
| Registration Request | | |
|---------------------->| Reg. Request | |
| |---------------------->| Reg. Request |
| | |--------------->|
| | | Reg. Reply |
| | Reg. Reply |<---------------|
| Registration Reply |<----------------------| |
|<----------------------| | |
| | | |
Figure 2: Home Registration
図2：ホーム登録
Figure 3 illustrates the signaling message flow for regional registration. Even though the MN's local care-of address changes, the HA continues to use the GFA address as the care-of address of the MN. We introduce two new message types for regional registrations: Regional Registration Request and Regional Registration Reply.
図3は、地域の登録のためのシグナリングメッセージフローを示します。でも、MNのローカル気付けアドレスの変更が、HAは気付MNのアドレスとしてGFAアドレスを使用し続けます。地域の登録要求と地域登録応答：私たちは、地域の登録のための2つの新しいメッセージタイプをご紹介します。
MN FA2 GFA HA
| | | |
| Regional Reg. Req. | | |
|---------------------->| Regional Registration Req. | |
| |----------------------------->| |
| | Regional Registration Reply | |
| Regional Reg. Reply |<-----------------------------| |
|<----------------------| | |
| | | |
Figure 3: Regional Registration
図3：地域登録
A FA typically announces its presence via an Agent Advertisement message [RFC3344]. If the domain to which an FA belongs supports regional registrations, the following changes apply to the Agent Advertisement.
FAは、一般的にエージェント広告メッセージ[RFC3344]を経由してその存在を発表しました。 FAが属するドメインは、地域の登録をサポートしている場合は、次の変更がエージェント広告に適用されます。
The 'I' flag (see Section 8.1) MUST be set to indicate that the domain supports regional registrations. If the 'I' flag is set, there MUST be at least one care-of address in the Agent Advertisement. If the 'I' flag is set and there is only one care-of address, it is the address of the FA. If the 'I' flag is set, and there is more than one care-of address, the first care-of address is the local FA, and the last care-of address is the GFA. (Any care-of addresses advertised in addition to these two are out of scope for this document).
「I」フラグが（8.1節を参照）、ドメインは地域の登録をサポートしていることを示すために設定しなければなりません。 「I」フラグが設定されている場合は、エージェント広告に少なくとも一つの気付けアドレスがあるに違いありません。 「I」フラグが設定されていて、唯一の気付けアドレスがあるされている場合は、FAのアドレスです。 「I」フラグが設定され、複数の気付アドレスがある場合は、最初の気付アドレスは、ローカルFAあり、そして最後の気付アドレスは、GFAです。 （いずれも気付けこれら二つに加えて、宣伝のアドレスは、このドキュメントの範囲外です）。
The FA-NAI (see Section 8.2) SHOULD also be present in the Agent Advertisement to enable the MN to decide whether or not it has moved to a new domain since its last registration. The decision is based on whether the realm part of the advertised FA-NAI matches the realm of the FA-NAI advertised by the MN's previous FA.
FA-NAIは（8.2節を参照）も、それはその最後の登録以来、新しいドメインに移動したか否かを判断するためにMNを可能にするために、エージェント広告で存在すべきです。決定は宣伝FA-NAIのレルム部分は、MNの以前のFAによってアドバタイズFA-NAIの領域と一致するかどうかに基づいています。
A domain that supports regional registrations should also be backwards compatible.
地域の登録をサポートするドメインはまた、後方互換性がなければなりません。
An FA MUST support registrations according to Mobile IPv4 as defined in [RFC3344]. This allows MNs that don't support regional registrations to register via this FA using standard Mobile IPv4. If the FA advertises both its own care-of address and a GFA care-of address, a MN that supports regional registrations but has a HA that doesn't, will still be able to make use of regional registrations through that GFA care-of address.
[RFC3344]で定義されるようにFAはモバイルIPv4に係る登録をサポートしなければなりません。これは、標準のモバイルIPv4を使用して、このFA経由で登録するには、地域の登録をサポートしていないのMNすることができます。 FAは、独自のアドレスのケア-とGFAの気付アドレス、地域の登録をサポートしていませんが、HAを持っているMNの両方をアドバタイズした場合、まだそのGFA気付を通じて地域登録を利用することができるようになります住所。
The advertised GFA care-of address MAY be set to all-ones, to indicate dynamic GFA assignment. If the MN supports regional registrations, and an all-ones GFA care-of address is advertised, the MN SHOULD use dynamic GFA assignment (see Section 7.1).
宣伝GFAの気付アドレスが動的にGFAの割り当てを示すために、すべてのものに設定されるかもしれません。 MNは、地域の登録をサポートし、GFAの気付アドレスのすべてのものが宣伝されている場合は、MNは、動的GFA割り当てを使用すべきである（7.1節を参照してください）。
This section gives a detailed description of home registration, i.e., registration with the HA (on the home network). Home registration is performed when a MN first arrives at a visited domain, when it requests a new HA, or when it changes GFA. Home registration is also performed to renew bindings which would otherwise expire.
このセクションでは、（ホームネットワーク上の）HAとホーム登録、即ち、登録の詳細な説明を与えます。それは新しいHA要求した場合、またはそれがGFAを変更したときMNは、まず、訪問先ドメインに到着すると、ホーム登録が行われます。ホーム登録もそうでない場合は期限切れになりバインディングを更新するために行われます。
Upon receipt of an Agent Advertisement message with the 'I' flag set and an FA-NAI extension, the MN compares the domain part of the FA NAI with the one received in the previous Agent Advertisement, to determine whether it has moved to a new domain since its last registration. If the NAIs do not match, the MN MUST assume it has moved to a new domain.
「I」フラグがセットおよびFA-NAI拡張機能を有するエージェント広告メッセージを受信すると、MNは、新しいに移動したかどうかを決定するために、以前のエージェント広告で受信したものとFA NAIのドメイン部分を比較しますその最後の登録以降のドメイン。 NAIが一致しない場合、MNは、それが新しいドメインに移動したと仮定しなければなりません。
If the MN determines that it has moved to a new domain, it SHOULD insert the advertised GFA address in the care-of address field in the Registration Request message. For dynamic GFA assignment, see Section 7.1.
MNは、それが新しいドメインに移動したと判断した場合は、登録要求メッセージに気付アドレスフィールドに宣伝GFAアドレスを挿入する必要があります。ダイナミックGFAの割り当てについては、項7.1を参照してください。
A MN with a co-located care-of address might also want to use regional registrations. It then finds out the address of a GFA, either from Agent Advertisements sent by an FA, or by some means not described in this document. The MN MAY then generate a Registration Request message, with the GFA address in the care-of address field, and send it directly to the GFA (not via an FA). In this case, the MN MUST add a Hierarchical Foreign Agent (HFA) extension (see Section 9.2), including its co-located care-of address, to the Registration Request before sending it. The HFA extension MUST be protected by an authentication extension. If the MN has established a mobility security association with the GFA, the HFA extension MUST be placed before the MN-FA Authentication extension, and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication extension. Otherwise, if the MN has no established mobility security association with the GFA, the HFA extension MUST be placed before the MN-HA authentication extension.
同じ場所に配置さ気付アドレスを持つMNは、地域の登録を使用する場合があります。その後、FAにより送信されたエージェント広告から、または本書に記述されていないいくつかの手段のいずれかによって、GFAのアドレスを発見します。 MNは、気付アドレスフィールドにGFAアドレスと、登録要求メッセージを生成し、GFA（ないFA経由）に直接送るかもしれません。この場合、MNは、それを送信する前に、登録要求に、その共存気付アドレスを含む、（9.2節を参照）階層の外部エージェント（HFA）拡張子を追加しなければなりません。 HFAの拡張は、認証の拡張により保護されなければなりません。 MNはGFAとモビリティセキュリティアソシエーションを確立している場合は、HFAの拡張子は、MN-FA認証拡張の前に置かなければなりません、そして、それは、モバイル・ホーム（MN-HA）認証拡張後に配置する必要があります。 MNはGFAとは確立モビリティセキュリティアソシエーションを持っていない場合はそれ以外の場合は、HFAの拡張子は、MN-HA認証拡張の前に置かなければなりません。
If the MN receives an Agent Advertisement with the 'R' bit set, even if it has a co-located care-of address, it still formulates the same Registration Request message with extensions, but it sends the message to the advertising FA instead of to the GFA.
MNは、「R」ビットが設定されたエージェント広告を受信した場合、それは同じ場所に配置さ気付アドレスを持っている場合でも、それはまだ拡張子を持つ同じ登録要求メッセージを定式化し、それが広告FAにメッセージを送る代わりに、 GFAへ。
If the home registration is about to expire, the MN performs a new home registration using the same GFA care-of address to refresh the binding [RFC3344]. If the MN has just moved to a new FA and not yet sent a Regional Registration Request when the home registration is due to expire, the MN sends only a Registration Request, as this will update both the GFA and the HA.
ホーム登録の有効期限が近づいている場合は、MNは、バインディング[RFC3344]を更新するには、同じGFAの気付アドレスを使用して、新しい家の登録を行います。 MNはちょうど新しいFAに移動し、ホーム登録が期限切れになるときはまだ地域の登録リクエストを送信していない場合は、MNは、これはGFAとHAの両方を更新するよう、唯一の登録要求を送信します。
If the Registration Reply includes a Replay Protection Style extension, the value in the Initial Identification field is the value to be used for replay protection in the next Regional Registration Request (see Section 6.1).
登録応答がリプレイ保護スタイルの拡張が含まれている場合は、最初の同定フィールドの値は、次の地域の登録要求にリプレイ保護のために使用される値である（6.1節を参照してください）。
When the FA receives a Registration Request message from a MN, it extracts the care-of address field to find the GFA to which the message shall be relayed. All FAs that advertise the 'I' flag MUST also be able to handle Registration Requests with an all-zeros care-of address (used for dynamic GFA assignment).
FAは、MNからの登録要求メッセージを受信すると、メッセージが中継されるものとするにGFAを見つけるために、気付アドレスフィールドを抽出します。 「I」フラグを宣伝するすべてのFAもすべてゼロ気付アドレス（動的GFAの割り当てに使用）と登録要求を処理できなければなりません。
If the FA receives a Registration Request where the care-of address is set to all-ones (which could happen if a MN that doesn't support Regional Registrations copied an all-ones care-of address from an Agent Advertisement), it MUST reply with the Code field set to "poorly formed request" [RFC3344].
FAは、気付アドレスは（地域の登録をサポートしていませんMNは、エージェント広告から気付アドレスのすべてのものをコピーした場合に発生する可能性が）すべてのものに設定されている登録リクエストを受信した場合、それはMUST Codeフィールドセットに「不完全に形成され、要求」[RFC3344]で応答。
If the Registration Request has the 'T' bit set, the MN is requesting Reverse Tunneling [RFC3024]. In this case, the FA has to tunnel packets from the MN to the GFA for further handling.
登録要求が「T」ビットがセットされている場合は、MNは、リバーストンネリング[RFC3024]を要求しています。この場合、FAは、さらに処理するためGFAにMNからトンネルパケットに有しています。
If the care-of address in the Registration Request is the address of the FA, the FA relays the message directly to the HA, as described in [RFC3344]. For each pending or current home registration, the FA maintains a visitor list entry as described in [RFC3344]. If reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields required in [RFC3344].
気付アドレス登録要求には、FAのアドレスである場合は、[RFC3344]に記載されているように、FAは、HAに直接メッセージを中継します。 [RFC3344]で説明したように、各保留中または現在のホームの登録については、FAは、訪問者リストエントリーを維持します。リバーストンネリングが使用されている場合、訪問者リストは、[RFC3344]で必要なフィールドに加えて、GFAのアドレスが含まれなければなりません。
Otherwise, if the care-of address in the Registration Request is the address of a GFA (or all-zeros), the FA adds a Hierarchical Foreign Agent (HFA) extension, including its own address, to the Registration Request, and relays it to the GFA. The HFA extension MUST be appended at the end of all previous extensions that were included in the Registration Request when the FA received it, and it MUST be protected by a Foreign-Foreign (FA-FA) Authentication extension (see Section 11).
それ以外の場合は、気付アドレス登録要求には、GFA（またはすべてゼロ）のアドレスであれば、FAは、それを登録要求に、自身のアドレスを含む階層的な外部エージェント（HFA）の拡張子を追加し、リレーGFAへ。 HFA拡張はFAがそれを受信した登録要求に含まれたすべての以前の拡張の終わりに添付しなければなりません、そして、それは外国外国（FA-FA）認証拡張（セクション11を参照）によって保護されなければなりません。
For each pending or current home registration, the GFA maintains a visitor list entry as described in [RFC3344]. This visitor list entry is also updated for the regional registrations performed by the MN. In addition to the fields required in [RFC3344], the list entry MUST contain:
[RFC3344]で説明したように、各保留中または現在のホームの登録について、GFAは、訪問者リストエントリーを維持します。この訪問者リストエントリーもMNによって実行される地域の登録のために更新されます。 [RFC3344]で必要なフィールドに加えて、リスト項目が含まれている必要があります
o the current care-of address of the MN (i.e., the FA or co-located address) received in the HFA extension o the remaining Lifetime of the regional registration o the style of replay protection in use for the regional registration o the Identification value for the regional registration.
O現在の気付MN（すなわち、FAまたは同じ場所に配置アドレス）のアドレスが識別値O地域の登録のために使用されているリプレイ保護のスタイルO地域登録の残りの寿命O HFA延長で受信しました地域の登録のため。
The default replay protection style for regional registrations is timestamp-based replay protection, as defined in Mobile IPv4 [RFC3344]. If the timestamp sent by the MN in the Registration Request is not close enough to the GFA's time-of-day clock, the GFA adds a Replay Protection Style extension (see Section 9.3) to the Registration Reply, with the GFA's time of day in the Identification field to synchronize the MN with the GFA for the regional registrations.
モバイルIPv4 [RFC3344]で定義されている地域の登録のためのデフォルトの再生保護のスタイルは、タイムスタンプベースのリプレイ保護です。登録要求にMNによって送信されたタイムスタンプは、GFAの時刻クロックに十分に近接していない場合は、GFAはリプレイ保護スタイルの拡張子を追加で一日のGFAの時間で、登録応答に（セクション9.3を参照してください）地域の登録のためのGFAとMNを同期するための識別フィールド。
If nonce-based replay protection is used, the GFA adds a Replay Protection Style extension to the Registration Reply, where the high-order 32 bits in the Identification fields is the nonce that should be used by the MN in the following regional registration.
ナンスベースのリプレイ保護を使用する場合は、GFAは識別の分野で上位32ビット登録応答にリプレイ保護スタイルの拡張子を追加し、次の地域の登録でMNによって使用されるべきナンスです。
If the Registration Request contains a Replay Protection Style extension (see Section 9.3) requesting a style of replay protection not supported by the GFA, the GFA MUST reject the Registration Request and send a Registration Reply with the value in the Code field set to REPLAY_PROT_UNAVAIL (see Section 9.5).
登録要求がリプレイ保護スタイルの拡張が含まれている場合はGFAでサポートされていないリプレイ保護のスタイルを要求する（第9.3節を参照）、GFAは、登録要求を拒絶しなければなりませんし、（REPLAY_PROT_UNAVAILに設定し、コードフィールドに値を持つ登録応答を送信します）9.5節を参照してください。
If the Hierarchical Foreign Agent (HFA) extension comes after the MN-FA Authentication extension, the GFA MUST remove it from the Registration Request. The GFA then sends the Registration Request to the HA. Upon receipt of the Registration Reply, the GFA consults its pending registration record to find the care-of address within its domain that is currently used by the MN, and sends the Registration Reply to that care-of address.
階層外部エージェント（HFA）拡張子はMN-FA認証拡張の後に来る場合は、GFAは、登録要求から削除する必要があります。 GFAは、HAに登録要求を送信します。登録応答を受信すると、GFAは気付現在MNによって使用され、そのドメイン内のアドレスを見つけるために、その保留登録レコードを参照し、その気付アドレスに登録応答を送信します。
If the Replay Protection Style extension (see Section 9.3) is present in a Registration Request, and follows the MN-HA Authentication extension, the GFA SHOULD remove the Replay Protection Style extension after performing any necessary processing and before sending the Registration Request to the HA.
リプレイ保護スタイルの拡張子は（9.3項を参照）を登録要求に存在し、MN-HA認証拡張を以下の場合は、GFAは、必要な処理を行った後とHAに登録要求を送信する前にリプレイ保護スタイルの拡張子を削除する必要があります。
If the GFA receives a Registration Request from a MN that it already has a mobility binding for, this is an update of a binding that is about to expire. If the address in the Hierarchical Foreign Agent (HFA) extension is the same as the current care-of address in the visitor list for the MN, the entries in the visitor list concerning regional registrations are not changed, except to update the lifetime. If the address in the HFA extension is a new address, the values for the regional registration are updated.
GFAは、それがすでにバインディングモビリティを持っていることをMNからの登録要求を受信した場合、これは、期限切れになることバインディングの更新です。階層外部エージェント（HFA）拡張子のアドレスは、現在の気付アドレスMNのための訪問者リストと同じであれば寿命を更新することを除いて、地域の登録に関する訪問者リスト内のエントリは、変更されません。 HFA拡張のアドレスは新しいアドレスであれば、地域の登録のための値が更新されます。
If the Registration Request has the 'T' bit set, the GFA has to decapsulate the packets from the FA and re-encapsulate them for further delivery back to the HA. These actions are required because the HA has to receive such packets from the expected care-of address (i.e., that of the GFA) instead of the local care-of address (i.e., that of the FA).
登録要求が「T」ビットがセットされている場合は、GFAはFAからのパケットをデカプセル化し、バックHAへの更なる配信のためにそれらを再カプセル化することがあります。 HAが期待気付アドレス（すなわちGFAの）代わりのローカル気付アドレス（すなわち、FAのもの）からそのようなパケットを受信しなければならないため、これらのアクションが要求されています。
When receiving a Registration Reply from the HA, the GFA MAY add a Regional Registration Lifetime extension to the message before relaying it to the FA. The extension defines the lifetime that the GFA allows the MN before it has to renew its regional registration. The GFA MUST set the lifetime of the regional registration to be no greater than the remaining lifetime of the MN's registration with its HA. If used, the Regional Registration Lifetime extension MUST be added after any other extensions, and MUST be protected by an MN-FA Authentication extension.
HAからの登録応答を受信すると、GFAはFAにそれを中継する前のメッセージに地域の登録生涯拡張子を追加するかもしれません。拡張子は、その地域の登録を更新する必要があります前に、GFAは、MNを可能に生涯を定義しています。 GFAは、HAとMNの登録の残りの寿命よりも大きくないために、地域の登録の有効期間を設定しなければなりません。使用している場合、地域の登録の有効期間延長は、任意の他の拡張子の後に追加されなければならない、とMN-FA認証拡張により保護されなければなりません。
The Registration Request is processed by the HA as described in [RFC3344].
登録要求は[RFC3344]に記載されているようにHAによって処理されます。
This section describes regional registrations. Once the HA has registered the GFA address as the care-of address of the MN, the MN may perform regional registrations. When performing regional registrations, the MN may either register an FA care-of address or a co-located address with the GFA. In the following, we assume that a home registration has already occurred, as described in Section 5, and that the GFA has a mobility security association with the MN.
このセクションでは、地域の登録について説明します。 HAは気付MNのアドレスとしてGFAアドレスを登録した後、MNは、地域の登録を行うことができます。地域の登録を行う場合には、MNは、アドレスFA用のケア、またはGFAと同じ場所に配置アドレスを登録することのいずれか。以下では、第5章で説明したように、私たちは、ホーム登録が既に発生していることを前提とし、GFAは、MNとのモビリティセキュリティアソシエーションを持っていること。
Suppose the MN moves from one FA to another FA within the same visited domain. It will then receive an Agent Advertisement from the new FA. Suppose further that the Agent Advertisement indicates that the visited domain supports regional registrations, and either that the advertised GFA address is the same as the one the MN has registered as its care-of address during its last home registration, or that the realm part of the newly advertised FA-NAI matches the FA-
同じ訪問先ドメイン内の別のFAに1 FAからMNが移動したとします。これは、新しいFAからのエージェント広告を受信します。エージェント広告が訪問ドメインは地域の登録をサポートしていることを示しており、いずれかの宣伝GFAアドレスは、MNは、その気付アドレスの最後のホーム登録時に登録しているものと同じである、またはのレルム一部ということがさらに仮定新しく宣伝FA-NAIは、FA-に一致します
NAI advertised by the MN's previous FA. Then, the MN can perform a regional registration with this FA and GFA. The MN issues a Regional Registration Request to the GFA via the new FA. The request is authenticated using the existing mobility security association between the GFA and the MN and the message is authenticated by the MN-GFA Authentication extension (see Section 11). The care-of address should be set to the address of the local FA.
NAIはMNの以前のFAによってアドバタイズ。その後、MNは、このFAとGFAと地域の登録を行うことができます。 MNは、新FA経由GFAに地域の登録リクエストを発行します。要求はGFAとMNとの間の既存のモビリティセキュリティアソシエーションを使用して認証され、メッセージは、MN-GFA認証拡張（セクション11を参照）によって認証されています。気付アドレスは、ローカルFAのアドレスに設定する必要があります。
If the Regional Registration Request contains a care-of address field of all-zeros, the FA adds a Hierarchical Foreign Agent (HFA) extension to the message and relays it to the GFA. Based on the information in the HFA extension, the GFA updates the MN's current point of attachment in its visitor list. The GFA then issues a Regional Registration Reply to the MN via the FA.
地域の登録要求が気付すべてゼロのアドレス・フィールドが含まれている場合は、FAは、メッセージに階層外部エージェント（HFA）の拡張子を追加し、GFAに中継します。 HFAの拡張子の情報に基づいて、GFAは、その訪問者リストの添付ファイルのMNの現在のポイントを更新します。 GFAは、FAを経由してMNへの地域の登録応答を発行します。
If the advertised GFA is not the same as the one the MN has registered as its care-of address, and if the MN is still within the same domain as it was when it registered that care-of address, the MN MAY try to perform a regional registration with its registered GFA. If the FA cannot support regional registration to a GFA, other than advertised, the FA denies the Regional Registration Request with code UNKNOWN_GFA (see Section 10.3). In this case, the MN has to do a new home registration via the new GFA.
広告を出してGFAは、MNがその気付アドレスとして登録されているものと同じではありません、それはその気付アドレスを登録したときにそれがあったとしてMNが同じドメイン内にある場合、MNは、実行しようとする可能性がある場合その登録GFAと地域の登録。 FAはアドバタイズされた以外のGFAへの地域の登録をサポートすることができない場合は、FAは、コードUNKNOWN_GFA（10.3節を参照）と地域の登録要求を拒否します。この場合、MNは、新しいGFAを経由して新しいホーム登録を行う必要があります。
New message types are introduced for the Regional Registration Request and Reply. The motivation for introducing new message types, rather than using the Registration Request and Reply defined in [RFC3344] is: (1) the MN must be able to distinguish regional registrations from home registrations, since in the former case the timestamps/nonces are synchronized with its GFA and in the latter with its HA; and (2) a home registration MUST be directed to the home network before the lifetime of the GFA care-of address expires.
新しいメッセージタイプは、地域の登録要求と応答のために導入されています。新しいメッセージタイプを導入するのではなく、登録要求を使用して、[RFC3344]で定義された返信用動機は次のとおりです。前者の場合には、タイムスタンプ/ナンスが同期しているので、（1）MNは、ホーム登録から地域の登録を区別することができなければなりませんそのGFAとそのHAとの後者において、 GFAの気付アドレスの有効期間が満了する前に、および（2）ホーム登録は、ホームネットワークに向けなければなりません。
For each pending or current home registration, the MN maintains the information described in [RFC3344]. The information is also updated for the regional registrations performed by the MN. In addition to the information described in [RFC3344], the MN MUST maintain the following information, if present:
各保留中または現在のホーム登録のために、MNは、[RFC3344]に記載された情報を維持します。情報は、MNによって行われる地域の登録のために更新されます。存在する場合、[RFC3344]に記載されている情報に加えて、MNは、以下の情報を維持しなければなりません。
o the GFA address o the remaining Lifetime of the regional registration o the style of replay protection in use for the regional registration o the Identification value for the regional registration.
地域の登録のための識別値O地域の登録のために使用されているリプレイ保護のスタイルO地域登録の残りの寿命のGFAアドレスO。
The replay protection for home registrations and regional registrations is performed as described in [RFC3344]. Since the MN performs regional registrations at the GFA in parallel with home registrations at the HA, the MN MUST be able to keep one replay protection mechanism and sequence for the GFA, and a separate mechanism and sequence for the HA.
[RFC3344]で説明したように、家庭の登録や地域の登録のためのリプレイ保護が行われます。 MNは、HA自宅の登録と並行して、GFAの地域の登録を実行するので、MNは、1つのリプレイ保護メカニズムとシーケンスGFAのため、およびHAのための別のメカニズムやシーケンスを維持できなければなりません。
For regional registrations, replay protection may also be provided at the FA by the challenge-response mechanism, as described in [RFC4721].
[RFC4721]に記載されているように地域登録のために、再生保護はまた、チャレンジレスポンス機構によってFAに設けられていてもよいです。
When the FA receives a Regional Registration Request from a MN, addressed to a GFA, it generally processes the message according to the rules of processing a Registration Request addressed to a HA (see Section 5.2). The only difference is that the GFA IP address field replaces the HA address field. If that address belongs to a known GFA, the FA forwards the request to the indicated GFA. Otherwise, the FA MUST generate a Regional Registration Reply with error code UNKNOWN_GFA.
FAは、MNから地域登録リクエストを受信すると、GFA宛、それは一般的に登録要求を処理するの規則に従ってメッセージを処理する（セクション5.2を参照）HA宛。唯一の違いは、GFA IPアドレスフィールドは、HAアドレスフィールドを置き換えるということです。そのアドレスが知られているGFAに属している場合は、FAが示さGFAに要求を転送します。そうでなければ、FAは、エラーコードUNKNOWN_GFAと地域の登録応答を生成しなければなりません。
For each pending or current registration, the FA maintains a visitor list entry as described in [RFC3344]. If reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields required in [RFC3344]. This is required so that the FA can tunnel datagrams, sent by the MN, to the GFA. The GFA then decapsulates the datagrams, re-encapsulates them, and sends them to the HA.
各保留中または現在の登録のために、FAは、[RFC3344]に記載されているように、訪問者リストエントリーを維持します。リバーストンネリングが使用されている場合、訪問者リストは、[RFC3344]で必要なフィールドに加えて、GFAのアドレスが含まれなければなりません。 GFAに、MNによって送信されたFAができトンネルデータグラム、ようにこれが必要です。 GFAは、それらを再カプセル化し、データグラムのカプセル化を解除し、HAに送信します。
If the GFA accepts a Regional Registration Request, it MUST set the lifetime of the regional registration to be no greater than the remaining lifetime of the MN's registration with its HA, and put this lifetime into the corresponding Regional Registration Reply. The GFA MUST NOT accept a request for a regional registration if the lifetime of the MN's registration with its HA has expired. In that case, the GFA sends a Regional Registration Reply with the value in the Code field set to NO_HOME_REG.
GFAは、地域の登録要求を受け入れる場合、それはそのHAとMNの登録の残りの寿命よりも大きくないために、地域の登録の有効期間を設定し、該当する地域の登録応答には、この寿命を置く必要があります。そのHAとMNの登録の有効期間が満了している場合GFAは、地域登録の要求を受け入れてはいけません。その場合には、GFAはNO_HOME_REGに設定されたコードフィールドの値を持つ地域の登録応答を送信します。
If the GFA receives a tunneled packet from an FA in its domain, then after decapsulation the GFA looks to see whether it has an entry in its visitor list for the source IP address of the inner IP header after decapsulation. If so, it checks the visitor list to see whether reverse tunneling has been requested; if it was requested, the GFA re-encapsulates the packet with its own address as the source IP address, and the address of the HA as the destination IP address.
GFAは、そのドメインFAからのトンネリングされたパケットを受信した場合、その後、カプセル化解除後GFAは、それがカプセル化解除した後、内側IPヘッダの送信元IPアドレスのためにその訪問者リストのエントリを持っているかどうかを調べます。もしそうなら、それは逆のトンネリングが要求されているかどうかを確認するために訪問者リストをチェックします。それは要求された場合、GFA元IPアドレス、宛先IPアドレスとしてHAのアドレスとして自身のアドレスを持つパケットを再カプセル化します。
Regional registrations may also allow dynamic assignment of a GFA to a MN. The visited network (i.e., the FA) indicates support for dynamic GFA assignment by advertising an all-ones care-of address in the Agent Advertisement. The MN then sets the care-of address in the Registration Request to all-zeros to request a dynamically assigned GFA. Upon receiving this Registration Request, the FA relays it to the appropriate GFA, and the GFA assigns its address to the MN by means of a GFA IP Address extension added to the Registration Request.
地域の登録もMNにGFAの動的な割り当てを可能にすることができます。訪問先ネットワーク（すなわち、FA）は、エージェント広告における気付アドレスのすべてのものを宣伝することにより、動的GFA割り当てのサポートを示します。 MNは、動的に割り当てられGFAを要求するために、すべてゼロに気付アドレス登録要求に設定されます。この登録リクエストを受信すると、FAは、適切なGFAにそれを中継し、GFAは、登録要求に付加GFA IPアドレス拡張の手段によってMNにそのアドレスを割り当てます。
In order for dynamic GFA assignment to work, the MN, GFA, and HA, respectively, MUST support the GFA IP Address extension. Also, the FA MUST be able to advertise an all-ones care-of address and handle a Registration Request with an all-zeros care-of address.
ダイナミックGFAの割り当てが機能するためには、MN、GFA、およびHAは、それぞれ、GFA IPアドレス拡張をサポートしなければなりません。また、FAは、すべてのものの気付アドレスを宣伝し、すべてゼロ気付アドレスで登録要求を処理できなければなりません。
Note also that protection of the GFA IP Address extension, added to the Registration Request, requires either the use of an FA-HA Authentication extension or other means to secure the Registration Request when forwarded from the GFA to the HA.
GFA IPアドレス拡張の注意また、その保護、登録要求に追加し、HAにGFAから転送されたときに登録リクエストを確保するためにFA-HA認証拡張や他の手段の使用のいずれかが必要です。
If the 'I' flag in the Agent Advertisement sent out by the FA is set, and the care-of address indicating the GFA is set to all-ones, this indicates support for dynamic GFA assignment.
エージェント広告の「I」フラグが設定され、気付けアドレスGFAを示すが、すべてのものに設定されているFAから送信された場合、これはダイナミックGFA割り当てのサポートを示します。
If the MN supports dynamic GFA assignment, and if the advertised GFA address is all-ones, the MN SHOULD set the care-of address field in the Registration Request to all-zeros to request to be assigned a GFA.
MNは、動的GFA割り当てをサポートし、広告を出してGFAアドレスはすべてのものである場合ならば、MNはGFAを割り当てることを要求するすべてゼロに登録要求に気付アドレスフィールドを設定する必要があります。
When requesting dynamic GFA assignment, the MN MUST check to make sure that it receives a GFA IP Address extension in the Registration Reply.
ダイナミックGFAの割り当てを要求すると、MNは、登録応答でGFA IPアドレス拡張を受けていることを確認するためにチェックしなければなりません。
If an FA supports dynamic GFA assignment, and receives a Registration Request with the care-of address field set to all-zeros, the FA assigns a GFA to the MN. A FA can either have a default GFA that it assigns to all MNs or it can assign a GFA by some means not described in this specification.
FAは、動的GFA割り当てをサポートし、気付アドレスフィールドすべてゼロに設定して登録リクエストを受信した場合、FAは、MNにGFAを割り当てます。 FAは、それがすべてのMNに割り当てるデフォルトGFAを持つことができますいずれか、またはそれがこの仕様書に記述されていないいくつかの手段によってGFAを割り当てることができます。
If an FA that does not support dynamic GFA assignment receives a Registration Request with the care-of address field set to all-zeros, the FA will deny the request as described in [RFC3344], i.e., by
動的GFA割り当てをサポートしていないFAがすべてゼロに設定気付アドレスフィールドを有する登録要求を受信した場合、すなわち、によって、[RFC3344]に記載されているように、FAは、要求を拒否します
sending a Registration Reply with the Code field set to "invalid care-of address".
「無効気付アドレス」に設定Codeフィールドで登録応答を送信します。
If a GFA supports dynamic GFA assignment, and receives a Registration Request with the care-of address field set to all-zeros, the GFA assigns its own IP address as care-of address for this MN, and adds a GFA IP Address extension with this address to the Registration Request. The GFA MUST NOT insert the GFA IP address directly in the care-of address field in the Registration Request, since that would cause the MN-HA authentication to fail.
GFAは、動的GFA割り当てをサポートし、すべてゼロに設定気付アドレスのフィールドで登録リクエストを受信した場合、GFAは、このMNのための気付けアドレスとして、自身のIPアドレスを割り当て、GFA IPアドレス拡張子を持つが追加されます登録要求に、このアドレス。それは、MN-HA認証が失敗する原因となるためGFAは、登録要求に気付アドレスフィールドに直接GFA IPアドレスを挿入してはなりません。
The GFA IP Address extension has to be protected so that it cannot be changed by a malicious node when the Registration Request is forwarded to the HA. If the HA and the GFA have a mobility security association, the GFA IP Address extension MUST be protected by the FA-HA authentication extension. Otherwise, the Registration Request MUST be sent to the HA in a secure way, for example via a secure AAA protocol (e.g., [RFC4004], [RFC3957]).
GFA IPアドレス拡張は、登録要求がHAに転送されるとき、それは、悪意のあるノードによって変更することができないように保護する必要があります。 HAとGFAは、モビリティセキュリティアソシエーションを持っている場合は、GFA IPアドレス拡張は、FA-HA認証拡張により保護されなければなりません。そうでなければ、登録要求は、セキュアなAAAプロトコル（例えば、[RFC4004]、[RFC3957]）を介して、例えば、安全な方法でHAに送信されなければなりません。
If the GFA does not support dynamic GFA assignment, it will deny the request by sending a Registration Reply with the Code field set to ZERO_COA_NOT_SUPP (see Section 9.5).
GFAは、動的GFAの割り当てをサポートしていない場合、それはZERO_COA_NOT_SUPPに設定Codeフィールドで登録応答を送信することにより、要求を拒否します（9.5節を参照してください）。
If a HA receives a Registration Request with a GFA IP Address extension, and the HA does not allow the use of this extension, the HA MUST return a Registration Reply with the Code value set to DYN_GFA_NOT_SUPP (see Section 9.5).
HAは、GFA IPアドレス拡張子の登録リクエストを受信すると、HAは、この拡張機能の使用を許可していない場合は、HAはDYN_GFA_NOT_SUPPに設定されたコード値を持つ登録応答を返さなければならない（9.5節を参照してください）。
If a HA receives a Registration Request message with the care-of address set to all-zeros, but no GFA IP Address extension, it MUST deny the request by sending a Registration Reply message with the Code field set to ZERO_CAREOF_ADDRESS (see Section 9.5).
HAは気付アドレスすべてゼロに設定して登録要求メッセージ、ないGFA IPアドレス拡張を受信した場合、それはZERO_CAREOF_ADDRESSに設定Codeフィールドで登録応答メッセージを送信することにより、要求を拒否しなければならない（9.5節を参照してください） 。
If a HA that does not support dynamic GFA assignment receives a Registration Request with a GFA IP Address extension, the request will be denied by the HA, as described in [RFC3344].
ダイナミックGFAの割り当てをサポートしていないHAは、GFA IPアドレス拡張子の登録リクエストを受信した場合、要求は[RFC3344]で説明したように、HAによって拒否されます。
If a HA that supports dynamic GFA assignment receives a Registration Request with the care-of address set to all-zeros and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the MN in its mobility binding list. If the Registration Request is accepted, the HA MUST include the GFA IP Address extension in the Registration Reply, before the MN-HA Authentication extension.
ダイナミックGFAの割り当てをサポートHAがすべてゼロとGFA IPアドレス拡張に気付アドレスのセットで登録リクエストを受信した場合、それは中MNの気付アドレスとして、GFAのIPアドレスを登録する必要があり、そのモビリティバインディングリスト。登録要求が受け入れられた場合、HAは、MN-HA認証拡張する前に、登録応答にGFA IPアドレス拡張を含まなければなりません。
If the MN receives an Agent Advertisement with the care-of address field indicating the GFA set to all-ones, and if the MN determines that it is within the same visited domain as when it did its last home registration, it MAY send a Regional Registration Request to its current GFA. Otherwise, it MUST send a Registration Request to its HA as described in Section 7.1.
MNはGFAが、すべてのものに設定さを示す気付アドレスフィールドにエージェント広告を受信した場合、およびMNは、それがその最後のホーム登録をしたときと同じ訪問先ドメイン内にあると判断した場合、それは地域を送るかもしれません現在のGFAへの登録要求。セクション7.1で説明したようにそれ以外の場合は、そのHAに登録要求を送らなければなりません。
This section specifies a new flag within the Mobile IP Agent Advertisement, and an optional extension to the ICMP Router Discovery Protocol [RFC1256].
このセクションでは、モバイルIPエージェント広告内の新しいフラグ、およびICMPルーター検出プロトコル[RFC1256]へのオプションの拡張子を指定します。
The only change to the Mobility Agent Advertisement Extension defined in [RFC3344] is a flag indicating that the domain, to which the FA generating the Agent Advertisement belongs, supports regional registrations. The flag is inserted after the flags defined in [RFC3344], [RFC3024], and [RFC3519].
[RFC3344]で定義されたモビリティエージェント広告拡張への唯一の変更は、ドメインは、FAはエージェント広告が所属生成していることを示すフラグであり、地域の登録をサポートしています。フラグは、[RFC3344]、[RFC3024]及び[RFC3519]で定義されたフラグの後に挿入されます。
Regional Registration flag:
地域の登録フラグ：
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The flag is defined as follows:
次のようにフラグが定義されます。
Type 16 (Mobility Agent Advertisement)
タイプ16（モビリティエージェント広告）
I Regional Registration. This domain supports regional registration as specified in this document.
私の地域登録。このドメインは、この文書で指定された地域の登録をサポートしています。
The FA-NAI extension is defined as subtype 3 of the NAI Carrying Extension [RFC3846].
FA-NAI拡張は拡張キャリングNAI [RFC3846]のサブタイプ3として定義されます。
The FA SHOULD include its NAI in the Agent Advertisement message. If present, the Foreign Agent NAI (FA-NAI) extension MUST appear in the Agent Advertisement message after any of the advertisement extensions defined in [RFC3344].
FAは、エージェント広告メッセージ内のNAIを含むべきです。存在する場合、外部エージェントNAI（FA-NAI）拡張子は[RFC3344]で定義された広告の拡張機能のいずれかの後に、エージェント広告メッセージに表示される必要があります。
By comparing the domain part of the FA-NAI with the domain part of the FA-NAI it received in the previous Agent Advertisement, the MN can determine whether it has moved to a new domain since it last registered.
それは、以前のエージェントの広告で受信FA-NAIのドメイン部分でFA-NAIのドメイン部分を比較することにより、MNは、それが最後に登録するので、それは新しいドメインに移動したかどうかを判断することができます。
In this section, we specify new Mobile IP registration extensions for the purpose of managing regional registrations.
このセクションでは、地域の登録を管理する目的のために、新たなモバイルIP登録の拡張子を指定します。
The GFA IP Address extension is defined for the purpose of supporting dynamic GFA assignment. If the MN requests a dynamically assigned GFA, the GFA adds a GFA IP Address extension to the Registration Request before relaying it to the HA. The MN indicates that it wants a GFA to be assigned by sending a Registration Request with the care-of address field set to all-zeros. The GFA IP Address extension MUST appear in the Registration Request before the FA-HA Authentication extension, if present.
GFA IPアドレス拡張は、動的GFAの割り当てをサポートする目的のために定義されています。 MNは、動的に割り当てられたGFAを要求した場合、GFAはHAにそれをリレーする前に、登録要求にGFA IPアドレス拡張が追加されます。 MNは、それがすべてゼロに設定気付アドレスのフィールドで登録リクエストを送信することにより割り当てられるGFAを望んでいることを示しています。存在する場合GFA IPアドレス拡張は、FA-HA認証拡張する前に登録要求に現れなければなりません。
If a HA receives a Registration Request message with the care-of address set to all-zeros, and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the MN. When generating a Registration Reply message, the HA MUST include the GFA IP Address extension from the Registration Request in the Registration Reply message. The GFA IP Address extension MUST appear in the Registration Reply message before the MN-HA Authentication extension.
HAは、すべてゼロに気付アドレスのセット、およびGFA IPアドレス拡張子の登録要求メッセージを受信した場合、それは気付MNのアドレスとしてGFAのIPアドレスを登録する必要があります。登録応答メッセージを生成するとき、HAは、登録応答メッセージに登録要求からGFA IPアドレス拡張を含まなければなりません。 GFA IPアドレス拡張は、MN-HA認証拡張する前に登録応答メッセージに表示される必要があります。
The GFA IP Address Extension is defined as follows:
次のようにGFAのIPアドレス拡張が定義されています。
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 46 (GFA IP Address) (non-skippable)
タイプ46（GFA IPアドレス）（非スキップ可能）
Length 6
長さ6
GFA IP Address The GFA IP Address field contains the Gateway Foreign Agent's (GFA) publicly routable address.
GFA IPはGFA IPアドレス]フィールドには、ゲートウェイ外部エージェントの（GFA）パブリックにルーティング可能なアドレスを含むアドレス。
The Hierarchical Foreign Agent (HFA) extension may be present in a Registration Request or Regional Registration Request. When an FA adds this extension to a Registration Request, the receiving mobility agent (GFA) sets up a pending registration record for the MN, using the IP address in the HFA extension as the care-of address for the MN. Furthermore, in this case, the extension MUST be appended at the end of all previous extensions that had been included in the registration message as received by the FA. The HFA extension MUST be protected by an FA-FA Authentication extension. When the receiving mobility agent (GFA) receives the registration message, it MUST remove the HFA extension added by the sending FA.
階層外部エージェント（HFA）拡張子が登録要求や地域の登録要求に存在することができます。 FAは、登録要求にこの拡張機能を追加すると、受信モビリティエージェント（GFA）は気付アドレスMN用としてHFA拡張にIPアドレスを使用して、MNのための保留中の登録レコードを設定します。また、この場合には、拡張子がFAにより受信された登録メッセージに含まれていた以前のすべての拡張の終わりに添付しなければなりません。 HFA拡張は、FA-FA認証拡張で保護する必要があります。受信モビリティエージェント（GFA）は登録メッセージを受信すると、送信FAによって追加HFA拡張子を削除する必要があります。
If a MN with a co-located care-of address adds the HFA extension to a Registration Request, the receiving mobility agent (GFA) sets up a pending registration record for the MN, using the IP address in the HFA extension as the care-of address for the MN. The extension MUST be protected by an authentication extension. If the MN has established a mobility security association with the GFA, the HFA extension MUST be placed before the MN-FA Authentication extension, and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication extension. Otherwise, if the MN has no established mobility security association with the GFA, the HFA extension MUST be placed before the MN-HA authentication extension. If the HFA extension is placed after all other extensions, the receiving mobility agent (GFA) MUST remove the HFA extension added by the MN. Otherwise, when the HA receives the registration message, it ignores the HFA extension.
同じ場所に配置さ気付アドレスとMNが登録要求にHFAの拡張子を追加する場合は、受信モビリティエージェント（GFA）はケア - としてHFA拡張のIPアドレスを使用して、MNのための保留中の登録レコードを設定しますMNのアドレスの。拡張子は、認証拡張により保護されなければなりません。 MNはGFAとモビリティセキュリティアソシエーションを確立している場合は、HFAの拡張子は、MN-FA認証拡張の前に置かなければなりません、そして、それは、モバイル・ホーム（MN-HA）認証拡張後に配置する必要があります。 MNはGFAとは確立モビリティセキュリティアソシエーションを持っていない場合はそれ以外の場合は、HFAの拡張子は、MN-HA認証拡張の前に置かなければなりません。 HFAの拡張子が他のすべての拡張子の後に置かれている場合は、受信したモビリティエージェント（GFA）MNによって追加HFAの拡張子を削除する必要があります。 HAは、登録メッセージを受信したときにそれ以外の場合、それはHFAの拡張子を無視します。
The Hierarchical Foreign Agent (HFA) Extension is defined as follows:
次のように階層的な外部エージェント（HFA）拡張が定義されています。
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 140 (Hierarchical Foreign Agent) (skippable)
タイプ140（階層的な外部エージェント）（スキップ可能）
Length 6
長さ6
FA IP Address The IP Address of the FA relaying the Registration Request.
FA IPは、登録要求を中継FAのIPアドレス。
When a MN uses Mobile IPv4 to register a care-of address with its HA, the style of replay protection used for the registration messages is assumed to be known by way of a mobility security association that is required to exist between the MN and the HA receiving the request. No such pre-existing security association between the MN and the GFA is likely to be available. By default, the MN SHOULD treat replay protection for Regional Registration messages exactly as specified in Mobile IPv4 [RFC3344] for timestamp-based replay protection.
MNは、そのHAとの気付アドレスを登録するために、モバイルIPv4を使用する場合、登録メッセージに使用される再生保護のスタイルは、MNとHAの間に存在することが必要とされているモビリティセキュリティアソシエーションの方法によって既知であると想定されます依頼を受けました。 MNとGFAの間には、このような既存のセキュリティアソシエーションが利用可能である可能性が高いではありません。デフォルトでは、MNは、タイムスタンプベースのリプレイ保護のためのモバイルIPv4 [RFC3344]で指定したとおりに地域の登録メッセージのリプレイ保護を扱うべきです。
If the MN requires nonce-based replay protection, also as specified in Mobile IPv4, it MAY append a Replay Protection Style extension to a Registration Request. Since Registration Requests are forwarded to the HA by way of the GFA, the GFA will be able to establish the selected replay protection (see Section 5.3).
MNはナンスベースのリプレイ保護を必要とする場合は、モバイルIPv4で指定され、また、それが登録要求にリプレイ保護スタイルの拡張子を付加してもよい（MAY）。登録要求は、GFAの方法によりHAに転送されているので、GFAは（5.3節を参照）を選択したリプレイ保護を確立することができるようになります。
The GFA also uses this extension by adding a Replay Protection Style extension to a Registration Reply to synchronize the replay protection for Regional Registrations (see Section 5.3).
GFAはまた、地域の登録（5.3節を参照）再生保護を同期するために登録応答にリプレイ保護スタイルの拡張子を追加することで、この拡張機能を使用しています。
The format of the Replay Protection Style extension is:
リプレイ保護スタイルの拡張子の形式は次のとおりです。
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 | Replay Protection Style |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Initial Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 141 (Replay Protection Style) (skippable)
（スキップ可能）141（リプレイ保護スタイル）を入力します
Length 2
長さ2
Replay Protection Style An integer specifying the style of replay protection desired by the MN.
MNが希望リプレイ保護のスタイルを指定するリプレイ保護スタイルアン整数。
Initial Identification The timestamp or nonce to be used for initial synchronization for the replay mechanism.
最初の同定タイムスタンプまたはノンスがリプレイ機構の初期同期のために使用されます。
Admissible values for the Replay Protection Style are as follows:
次のようにリプレイ保護のスタイルのための許容値は、次のとおりです。
+-------+-------------------------+
| Value | Replay Protection Style |
+-------+-------------------------+
| 0 | timestamp [RFC3344] |
| 1 | nonce [RFC3344] |
+-------+-------------------------+
The Replay Protection Style extension MUST be protected by an authentication extension. If the MN has an established mobility security association with the GFA, the Replay Protection Style extension MUST be placed before the MN-FA Authentication extension in the Registration Request, and SHOULD be placed after the MN-HA Authentication extension. Otherwise, the Replay Protection Style extension MUST be placed before the MN-HA Authentication extension in the Registration Request.
リプレイ保護スタイルの拡張は、認証の拡張により保護されなければなりません。 MNはGFAとの確立モビリティセキュリティアソシエーションを持っている場合は、リプレイ保護スタイル拡張子が登録要求にMN-FA認証拡張の前に置かなければなりませんし、MN-HA認証拡張後に配置する必要があります。そうでなければ、リプレイ保護スタイル拡張子が登録要求にMN-HA認証拡張の前に置かなければなりません。
If the GFA adds a Replay Protection Style extension to a Registration Reply, it SHOULD be placed before the MN-FA Authentication extension. The MN-FA Authentication extension should be based on security associations between the MN and GFA established during home registration.
GFAは、登録応答にリプレイ保護スタイルの拡張子を追加する場合は、MN-FA認証拡張の前に配置する必要があります。 MN-FA認証拡張ホーム登録中に確立MNとGFAの間でセキュリティアソシエーションに基づくべきです。
Replay protection MAY also be provided through a challenge-response mechanism, at the FA issuing the Agent Advertisement, as described in [RFC4721].
[RFC4721]で説明したようにリプレイ保護はまた、エージェント広告を出すFAで、チャレンジ・レスポンス機構を介して提供することができます。
The Regional Registration Lifetime extension allows the GFA to set a lifetime for the regional registration with an MN during its home registration. When receiving a Registration Reply from the HA, the GFA MAY add this extension to the Registration Reply before relaying it to the FA. The GFA MUST set the Regional Registration Lifetime to be no greater than the remaining lifetime of the MN's home registration.
地域の登録の有効期間延長はGFAが、そのホーム登録時にMNと地域の登録の有効期間を設定することができます。 HAからの登録応答を受信すると、GFAはFAにそれを中継する前に登録応答にこの拡張子を追加するかもしれません。 GFAは、MNのホーム登録の残りの寿命よりも大きくないために、地域の登録の有効期間を設定しなければなりません。
The Regional Registration Lifetime Extension is defined as follows:
次のように地域の登録生涯拡張が定義されています。
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regional Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 142 (Regional Registration Lifetime) (skippable)
タイプ142（地域別登録ライフタイム）（スキップ可能）
Length 6
長さ6
Regional Registration Lifetime If the Code field indicates that the registration was accepted, the Regional Registration Lifetime field is set to the number of seconds remaining before the regional registration is considered expired. A value of zero indicates that the MN has been deregistered with the GFA. A value of 0xffff indicates infinity. If the Code field indicates that the home registration was denied, the contents of the Regional Registration Lifetime field are unspecified and MUST be ignored on reception.
地域の登録ライフタイムコードフィールドは登録が受け入れられたことを示している場合は、地域の登録Lifetimeフィールドは、地域の登録が期限切れになったと見なされるまでの残りの秒数に設定されています。ゼロの値は、MNは、GFAで登録解除されたことを示しています。値0xffffは、無限大を示しています。 Codeフィールドは、ホーム登録が拒否されたことを示している場合は、地域の登録Lifetimeフィールドの内容は、指定されていないと受信で無視しなければなりません。
If the GFA adds a Regional Registration Lifetime extension to a Registration Reply, it MUST be placed before the MN-FA Authentication extension. The MN-FA Authentication extension should be based on security associations between the MN and GFA established during home registration.
GFAは、登録応答に地域登録の有効期間延長を追加した場合、それはMN-FA認証拡張の前に置かなければなりません。 MN-FA認証拡張ホーム登録中に確立MNとGFAの間でセキュリティアソシエーションに基づくべきです。
The values to use within the Code field of the Registration Reply are defined in [RFC3344]. In addition, the following values are defined:
登録応答のコードフィールド内で使用する値は[RFC3344]で定義されています。加えて、以下の値が定義されています。
Registration denied by the GFA:
GFAによって拒否された登録：
+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| REPLAY_PROT_UNAVAIL | 110 | Section 5.3 |
| ZERO_COA_NOT_SUPP | 111 | Section 7.3 |
+---------------------+-------+---------------------+
Registration denied by the HA (for dynamic GFA assignment):
登録（ダイナミックGFAの割り当てのために）HAによって拒否されました：
+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| ZERO_CAREOF_ADDRESS | 145 | Section 7.4 |
| DYN_GFA_NOT_SUPP | 146 | Section 7.4 |
+---------------------+-------+---------------------+
This section specifies two new registration message types: Regional Registration Request and Regional Registration Reply. These messages are used by the MN instead of the existing Mobile IPv4 Registration Request and Registration Reply, as described in Section 6.
地域の登録要求と地域登録応答：このセクションでは、2つの新しい登録メッセージの種類を指定します。第6節で説明したように、これらのメッセージは、代わりに、既存のモバイルIPv4登録要求および登録応答のMNによって使用されています。
Regional registration messages are protected by required authentication extensions, in the same way as the existing Mobile IPv4 registration messages are protected. The following rules apply to authentication extensions:
地域の登録メッセージは、既存のモバイルIPv4登録メッセージが保護されているのと同じ方法で、必要な認証の拡張機能によって保護されています。次の規則は、認証の拡張機能に適用されます。
o The MN-GFA Authentication extension [RFC3344] MUST be included in all regional registration messages. o The MN-FA Authentication extension [RFC3344] MAY be included in regional registration messages. o The FA-HA Authentication extension [RFC3344] MUST NOT be included in any regional registration message.
O MN-GFA認証拡張[RFC3344]は、すべての地域の登録メッセージに含まれなければなりません。 O MN-FA認証拡張[RFC3344]は地域の登録メッセージに含まれるかもしれません。 FA-HA認証拡張[RFC3344] oを任意の地域の登録メッセージに含まれてはいけません。
The Regional Registration Request is used by a MN to register with its current GFA.
地域の登録要求は、現在のGFAに登録するためにMNによって使用されます。
Regional Registration Request:
地域の登録要求：
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 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The Regional Registration Request is defined as the Registration Request in [RFC3344], but with the following changes:
地域登録要求は[RFC3344]に登録要求として定義されるが、以下の変更をされています。
Type 18 (Regional Registration Request)
タイプ18（リージョナル登録要求）
Lifetime The number of seconds remaining before the Regional Registration is considered expired. A value of zero indicates a request for deregistration with the GFA. A value of 0xffff indicates infinity.
寿命は地域の登録までの残りの秒数が期限切れになったと考えられています。ゼロの値は、GFAとの登録解除の要求を示します。値0xffffは、無限大を示しています。
GFA IP Address The IP address of the Gateway Foreign Agent (GFA). (Replaces Home Agent field in Registration Request message in [RFC3344].)
GFA IPゲートウェイ外部エージェント（GFA）のIPアドレス。 （[RFC3344]に登録要求メッセージでホームエージェントフィールドを置き換えます。）
Care-of Address Care-of address of local FA; MAY be set to all-ones.
気付ローカルFAの気付アドレスのアドレス;すべてのものに設定されるかもしれません。
Identification A 64-bit number, constructed by the MN, used for matching Regional Registration Requests with Regional Registration Replies, and for protecting against replay attacks of regional registration messages.
MNによって構成され、64ビットの数は、地域登録回答で地域登録要求をマッチングするための識別、および地域の登録メッセージのリプレイ攻撃から保護します。
Extensions For the Regional Registration Request, the Hierarchical Foreign Agent (HFA) Extension is an allowable extension (in addition to those which are allowable for the Registration Request).
地域の登録要求、階層外部エージェント（HFA）拡張のための拡張機能（登録要求のために許容されているものに加えて）許容拡張したものです。
The Regional Registration Reply delivers the indication of regional registration acceptance or denial to a MN.
地域の登録応答は、MNへの地域の登録受付または拒否の表示を実現します。
In the Regional Registration Reply, the UDP header is followed by the Mobile IP fields shown below:
地域登録応答では、UDPヘッダは、以下に示す移動IPフィールドが続きます。
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
This message is defined as the Registration Reply message in [RFC3344], but with the following changes:
このメッセージは、[RFC3344]に、しかし次のように変更して登録応答メッセージのように定義されます。
Type 19 (Regional Registration Reply)
タイプ19（リージョナル登録応答）
Code A value indicating the result of the Regional Registration Request. See [RFC3344] for a list of currently defined Code values.
コード地域の登録要求の結果を示す値。現在定義されているコード値のリストについては、[RFC3344]を参照してください。
Lifetime If the Code field indicates that the regional registration was accepted, the Lifetime field is set to the number of seconds remaining before the regional registration is considered expired. A value of zero indicates that the MN has been deregistered with the GFA. A value of 0xffff indicates infinity. If the Code field indicates that the regional registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception.
生涯Codeフィールドは、地域の登録が受け入れられたことを示している場合は、有効期間フィールドは地域の登録が期限切れになったと見なされるまでの残りの秒数に設定されています。ゼロの値は、MNは、GFAで登録解除されたことを示しています。値0xffffは、無限大を示しています。 Codeフィールドは、地域の登録が拒否されたことを示している場合、Lifetimeフィールドの内容は、指定されていないと受信で無視しなければなりません。
GFA IP Address The IP address of the Gateway Foreign Agent (GFA) generating the Regional Registration Reply. (Replaces Home Agent field specified in Mobile IPv4 [RFC3344].)
GFA IPは、地域の登録応答を生成するゲートウェイ外部エージェント（GFA）のIPアドレス。 （モバイルIPv4 [RFC3344]で指定されたホームエージェントフィールドを置き換えます。）
Identification A 64-bit number used for matching Regional Registration Requests with Regional Registration Replies, and for protecting against replay attacks of regional registration messages. The value is based on the Identification field from the Regional Registration Request message from the MN, and on the style of replay protection used in the security context between the MN and its GFA (defined by the mobility security association between them).
識別地域の登録応答を持つ地域の登録要求に合致するため、地域登録メッセージのリプレイ攻撃から保護するために使用され、64ビットの数。値は、MNから地域の登録要求メッセージからの識別フィールドに、そしてMNとそのGFA（それらの間のモビリティセキュリティアソシエーションによって定義される）の間のセキュリティコンテキストで使用されるリプレイ保護のスタイルに基づいています。
For a Regional Registration Reply, the following additional Code values are defined in addition to those specified in Mobile IPv4 [RFC3344].
地域登録応答のために、以下の追加のコード値はモバイルIPv4 [RFC3344]で指定されたものに加えて定義されています。
Registration denied by the FA:
FAによって拒否された登録：
+----------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+----------------------+-------+---------------------+
| UNKNOWN_GFA | 112 | Section 6.2 |
| GFA_UNREACHABLE | 113 | |
| GFA_HOST_UNREACHABLE | 114 | |
| GFA_PORT_UNREACHABLE | 115 | |
+----------------------+-------+---------------------+
Registration denied by the GFA:
GFAによって拒否された登録：
+-------------+-------+---------------------+
| Error Name | Value | Section of Document |
+-------------+-------+---------------------+
| NO_HOME_REG | 193 | Section 6.3 |
+-------------+-------+---------------------+
The four first Code values are returned to the MN in response to ICMP errors that may be received by the FA.
4つの第1のコード値は、FAによって受信されるICMPエラーに応答してMNに戻されます。
In this section, two new subtypes for the Generalized Authentication Extension [RFC4721] are specified. First, the FA-FA Authentication extension is used by FAs to secure the HFA extension to the Registration Request and Regional Registration Request messages. A new authentication extension is necessary because the HFA extension is typically added after the MN-HA Authentication extension or, e.g., the MN-AAA Authentication extension [RFC4721].
このセクションでは、一般化された認証拡張[RFC4721]のための2つの新しいサブタイプが指定されています。まず、FA-FA認証拡張が、登録要求と地域登録要求メッセージにHFA拡張子を確保するためのFAで使用されています。 HFA拡張は、典型的には、MN-HA認証拡張または、例えば、MN-AAA認証拡張[RFC4721]の後に追加されるため、新しい認証拡張が必要です。
The MN-GFA Authentication extension is used whenever the MN has a co-located address. The MN-GFA Authentication extension is also used to provide authentication for a Regional Registration Request.
MNは同一場所に配置アドレスを有するときはいつでもMN-GFA認証拡張が使用されます。 MN-GFA認証拡張も地域の登録要求の認証を提供するために使用されます。
The subtype values for these new subtypes are as follows:
次のようにこれらの新しい亜型のためのサブタイプの値は次のとおりです。
+-----------------------+-------+
| Subtype Name | Value |
+-----------------------+-------+
| FA-FA authentication | 2 |
| MN-GFA authentication | 3 |
+-----------------------+-------+
The default algorithm for computation of the authenticator is the same as for the MN-AAA Authentication subtype defined in [RFC4721].
オーセンティケータを計算するためのデフォルトのアルゴリズムは[RFC4721]で定義されたMN-AAA認証のサブタイプの場合と同じです。
This document proposes a method for a MN to register locally in a visited domain. The authentication extensions to be used are those defined in [RFC3344] and [RFC4721]. Key distribution, assumed to take place during home registration, is to be performed, for instance, according to [RFC4004] or [RFC3957]. Alternatively, the keys can be pre-configured.
この文書では、MNが訪問ドメインにローカルに登録するための方法を提案しています。使用する認証拡張機能は[RFC3344]及び[RFC4721]で定義されたものです。鍵の配布は、ホーム登録時に場所を取ると仮定し、[RFC4004]か[RFC3957]によると、例えば、実行されるべきです。あるいは、キーは事前に構成することができます。
If the Hierarchical Foreign Agent (HFA) extension is appended to a Registration Request, this extension is to be followed by an FA-FA Authentication extension (see Section 11) to prevent any modification to the data. Security associations between FAs and GFAs within a domain are assumed to exist prior to regional registrations.
階層外部エージェント（HFA）拡張子が登録要求に追加されている場合は、この拡張機能は、データへの変更を防ぐために（セクション11を参照）FA-FA認証拡張が続くことがあります。ドメイン内のFAとGFAs間のセキュリティアソシエーションは、前の地域登録に存在すると仮定されています。
If the GFA IP Address extension is added to a registration message, it is to be followed by a authentication extension. In case of the GFA IP Address extension being added to a Registration Request, it should be protected by an FA-HA Authentication extension. If no security association exists between the GFA and the HA, the Registration Request needs to be protected by other means not defined in this document. When a GFA IP Address extension is added to a Registration Reply, it is protected by the Mobile-Home Authentication extension as defined in [RFC3344].
GFA IPアドレス拡張が登録メッセージに付加されている場合は、認証拡張が続くことがあります。登録要求に付加されているGFA IPアドレス拡張の場合は、FA-HA認証拡張により保護されなければなりません。何のセキュリティアソシエーションは、GFAとHA間に存在しない場合は、登録要求は、この文書で定義されていない他の手段によって保護される必要があります。 GFA IPアドレス拡張が登録応答に追加されると、[RFC3344]で定義され、それがモバイル・ホーム認証拡張により保護されています。
Replay protection for regional registrations is defined similarly to [RFC3344], with the addition of a Replay Protection Style extension. If this extension is added to a Registration Reply by a GFA, it needs to be protected by a MN-FA Authentication extension.
地域の登録のためのリプレイ保護はリプレイ保護スタイルの拡張子を追加して、[RFC3344]と同様に定義されます。この拡張機能は、GFAにより登録応答に追加された場合、それはMN-FA認証拡張によって保護される必要があります。
A co-operating malicious MN-HA pair can trick the GFA into setting up state for an incorrect MN home address. This would result in redirection of data of the node that actually owns that IP address to the malicious MN. Given that the forwarding happens based on the home address at the GFA, such an attack is scoped to the prefix of the HA, not that of the GFA. This type of attack, or its consequences, is not considered in this document.
協働し、悪質なMN-HAペアは、間違ったMNのホームアドレスの状態を設定するにGFAをだますことができます。これは実際に悪意のあるMNにそのIPアドレスを所有しているノードのデータのリダイレクトにつながります。転送が起こることを考えるとGFAのホームアドレスに基づいて、このような攻撃は、HAのプレフィックスではなく、GFAのようにスコープされます。この攻撃の種類、またはその影響は、このドキュメントでは考慮されていません。
This document defines:
この文書では、定義されています。
o A subtype for the NAI Carrying Extension [RFC3846] is specified in Section 8.2, which needs to have a value assigned from the space of NAI Carrying Extension subtypes.
O拡張[RFC3846]を運ぶNAIのためのサブタイプは、拡張サブタイプを運ぶNAIの空間から割り当てられた値を有する必要があるセクション8.2で指定されています。
o Four new extensions to Mobile IP Registration messages: GFA IP Address, Hierarchical Foreign Agent, Replay Protection Style, and Regional Registration Lifetime (see Sections 9.1, 9.2, 9.3, and 9.4). The Type values for the GFA IP Address extension must be within the range 0 through 127, while the other three must be within the range 128 through 255.
モバイルIP登録メッセージに四の新しい拡張機能○：GFA IPアドレス、階層外部エージェント、リプレイ保護のスタイル、および地域の登録の有効期間（セクション9.1、9.2、9.3、および9.4を参照）。他の三つは、255までの範囲128内になければならないしながらGFA IPアドレス拡張のタイプ値は、127を介して範囲0内になければなりません。
o New Code values for Registration Reply messages (see Section 9.5).
登録応答メッセージのO新しいコード値（9.5節を参照してください）。
o Two new subtypes for the Generalized Authentication Extension [RFC4721]; see Section 11.
O汎用認証拡張[RFC4721]のための二つの新しいサブタイプ。セクション11を参照してください。
o Two new message types for Mobile IP: Regional Registration Request and Regional Registration Reply (see Sections 10.1 and 10.2).
モバイルIPのための二つの新しいメッセージタイプ○：地域の登録要求と地域登録応答（セクション10.1と10.2を参照してください）。
o Code values for Regional Registration Reply messages (see Section 10.3).
地域の登録応答メッセージのOコード値（セクション10.3を参照してください）。
This document is a logical successor to documents written with Pat Calhoun and Gabriel Montenegro; thanks to them and their many efforts to help explore this problem space. Many thanks also to Jari Malinen for his commentary on a rough version of this document.
この文書では、パットカルフーンとガブリエルモンテネグロで書かれた文書に論理的後継者です。彼らと彼らの多くの努力のおかげで、この問題空間を探索するのに役立ちます。このドキュメントのラフバージョン彼の解説のためのヤリMalinenにも感謝します。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]デアリング、S.、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G.は、RFC 3024、2001年1月、 "モバイルIPのためのリバーストンネリングは、改訂されました"。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003.
、RFC 3519、2003年5月、 "ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル" [RFC3519] Levkowetz、H.とS. Vaarala、。
[RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
"ネットワークアクセス識別子を実施するためのモバイルIPv4拡張" [RFC3846]ヨハンソン、F.とT.ヨハンソン、RFC 3846、2004年6月。
[RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[RFC4721]パーキンス、C.、カルフーン、P.、およびJ. Bharatia、 "モバイルIPv4チャレンジ/レスポンス拡張（改訂版）"、RFC 4721、2007年1月。
[RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[RFC3957]パーキンス、C.とP.カルフーン、 "モバイルIPv4のための認証、許可、アカウンティング（AAA）の登録キー"、RFC 3957、2005年3月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004]カルフーン、P.、ヨハンソン、T.、パーキンス、C.、ヒラー、T.、およびP.マッキャン、 "直径モバイルIPv4アプリケーション"、RFC 4004、2005年8月。
Appendix A. Authentication, Authorization, and Accounting (AAA) Interactions
付録Aの認証、許可、アカウンティング（AAA）の相互作用
When the mobile node has to obtain authorization by way of Authentication, Authorization, and Accounting (AAA) infrastructure services, the control flow implicit in the main body of this specification is likely to be modified. Typically, the mobile node will supply credentials for authorization by AAA as part of its registration messages. The GFA will parse the credentials supplied by the mobile and forward the appropriate authorization request to a local AAA server (see [RFC3012] and [RFC4004]).
モバイルノードは、認証、許可、アカウンティング（AAA）インフラストラクチャ・サービスを介して許可を得る必要がある場合、本明細書の本体内の暗黙の制御フローは、変更される可能性があります。典型的には、モバイルノードは登録メッセージの一部としてAAAによる認証のための認証情報を供給します。 GFAは、モバイルによって提供された資格情報を解析し、（[RFC3012]及び[RFC4004]を参照）ローカルAAAサーバに適切な認証要求を転送します。
Concretely, this means that:
具体的には、これはことを意味します。
o The GFA MAY include the Mobile IP Registration Request data inside an authorization request, directed to a local AAA server.
O GFAは、ローカルAAAサーバに向け認証要求内のモバイルIP登録要求データを含むことができます。
o The GFA MAY receive the Mobile IP Registration Reply data from a message granting authorization, received from the AAA infrastructure.
oをGFAは、AAAインフラストラクチャから受信し、メッセージを許可、認可からモバイルIP登録応答データを受信することができます。
Appendix B. Anchoring at a GFA
付録B. GFAでアンカー
As described earlier in this draft, once a mobile node has registered the address of a GFA as its care-of address with its home agent, it MAY perform regional registrations when changing foreign agent under the same GFA. When detecting that is has changed foreign agent, and if the new foreign agent advertises the 'I' flag, the mobile node MAY address a Regional Registration Request message to its registered GFA, even if the address of that particular GFA is not advertised by the new foreign agent. The foreign agent MAY then relay the request to the GFA in question, or deny the request with error code UNKNOWN_GFA.
同じGFAの下で外国人のエージェントを変更するときに、このドラフトで先に述べたように、一度モバイルノードがそのホームエージェントにその気付アドレスとしてGFAのアドレスを登録している、それが地域の登録を行うことができます。検出した場合、それは外国人のエージェントを変更したされ、新しい外国人のエージェントが「I」フラグをアドバタイズしている場合、モバイルノードは、その特定のGFAのアドレスがによってアドバタイズされていない場合でも、その登録GFAに地域の登録要求メッセージに対処することができます新しい外国人のエージェント。外国人のエージェントは、質問にGFAへの要求を中継、またはエラーコードUNKNOWN_GFAで要求を拒否することができます。
Authors' Addresses
著者のアドレス
Eva Fogelstroem Ericsson Torshamnsgatan 23 SE-164 80 Stockholm Sweden
エヴァFogelstroemエリクソンTorshamnsgatan 23 SE-164 80ストックホルムスウェーデン
EMail: eva.fogelstrom@ericsson.com
メールアドレス：eva.fogelstrom@ericsson.com
Annika Jonsson Ericsson Tellusborgsvagen 83-87 S-126 37 Hagersten Sweden
アニカ・ジョンソンエリクソンTellusborgsvagen 83-87 S-126 37ヘゲルステンスウェーデン
EMail: annika.jonsson@ericsson.com
メールアドレス：annika.jonsson@ericsson.com
Charles E. Perkins Nokia Siemens Networks 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキア・シーメンス・ネットワーク313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
EMail: charles.perkins@nsn.com
メールアドレス：charles.perkins@nsn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。