[要約] RFC 4857は、モバイルIPv4の地域登録に関する規格であり、モバイルノードの地域情報を登録するための手順とプロトコルを提供しています。このRFCの目的は、モバイルノードの正確な地域情報を提供し、モバイルネットワークの効率と信頼性を向上させることです。
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
モバイルIPv4地域登録
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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を使用して、モバイルノードは、住所のケアを変更するたびにホームエージェントを登録します。このドキュメントでは、新しい種類の「地域登録」、つまり訪問ドメインのローカル登録について説明します。地域登録は、Gateway Foreign Agent（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.
[RFC3344]で指定されているように、モバイルIPでは、住所のケアを変更するたびにモバイルノードがホームエージェントを登録します。訪問されたネットワークとモバイルノードのホームネットワーク間の距離が大きい場合、これらの登録のシグナリング遅延は長い場合があります。訪問ドメイン：地域登録でローカルで登録を実行するためのソリューションを提案します。地域の登録は、ホームネットワークへの信号メッセージの数を最小限に抑え、モバイルノードが同じ訪問ドメイン内である外国人エージェントから別のエージェントに移動するときのシグナリング遅延を減らします。これにより、ホームネットワークの負荷が減少し、訪問ドメイン内のハンドオーバープロセスが高速化されます。
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.
地域登録には、新しいネットワークノードが導入されています：The Gateway Foreign Agent（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の間にあり、HAには、MNの一時的な住所がGFAのものであるかのように見えます。MNがサイト内を移動する場合、GFAとのみ対話する必要があるため、GFAはMNが現在到達可能な一時的な住所で知っています。
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.
2種類の登録メッセージが使用されます。通常の[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.
さらに、登録メッセージの新しいペア、地域登録要求/返信が、サイト内シグナリングのためにMNS/FAS/GFAの間で使用されます。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を選択しません。MNから登録リクエストを受け取った後、FA（またはGFA）はそうします。ただし、このモードでは、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が新しいドメインに移動すると（ネットワークアクセス識別子（NAI）[RFC4282]とFA-NAIが受信エージェント広告に含まれるFA-NAI）を比較することで決定されると、地域の登録を使用することができます。サイトは、モバイルIPエージェント広告拡張機能のIビットを設定することにより、地域登録のサポートを示しています。さらに、このような広告には、1つ以上の住所のリストが含まれています。住所のケアが1つしかない場合、これは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を使用したい場合は選択した場合）またはAll-Zeros（動的GFA割り当てリクエスト）。FAは階層FA（HFA）拡張機能を追加し、リクエストを適切なGFAにリレーします。HFA拡張には、FAのIPアドレス：単一のフィールドが含まれています。
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.
注：Co-Located Care-of AddressのMNSのアルゴリズムは類似していますが、FAがないことを除いて、MNは送信するメッセージの観点から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はそれを割り当てます。次に、GFA IPアドレス拡張機能が登録リクエストに追加され、メッセージがHAに転送されます。GFA IPアドレス拡張機能には、単一のフィールドが含まれています。GFAのIPアドレスです。（MN/HA間の登録要求メッセージが署名されており、変更できないため、これには別のフィールドが必要です。）
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はGFA IPアドレス拡張のGFAアドレスをMNの現在のケアアドレスとして使用します。さらに、登録返信メッセージには、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.
MNとHAの間のモビリティセキュリティ協会を使用することにより、通常の登録要求/返信は[RFC3344]に記載されているように保護されています。地域登録の場合、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とGFAのセキュリティ関連は、地域登録前に存在すると想定されています。
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アドレスの拡張機能を保護するために、GFAからHAに安全に登録要求を送信する手段が必要です。
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].
[RFC3344]で定義されている外国人エージェント（FA）。
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.
Gateway外国人エージェント（GFA）公開されているIPアドレスを持つ外国人エージェント。たとえば、GFAはファイアウォールまたはその近くに配置される場合があります。
Home Agent (HA) As defined in [RFC3344].
[RFC3344]で定義されているホームエージェント（HA）。
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.
ホーム登録ホームエージェントとGFAによって処理された登録。[RFC3344]の仕様を使用して、おそらくこのドキュメントで定義されている追加の拡張機能を使用します。
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:
私たちの一般的な動作モデルは図1に示されています。FAとGFAを備えた訪問ドメインとHAのホームネットワークを示しています。
+---------------------------+ +----------------+
| 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つの階層レベルを想定しています。階層の上位レベルには、少なくとも1つのGFAがあり、これは追加機能を備えたFAです。GFAには、公開されているアドレスが必要です。GFAの下には、1つ以上のFAがあります。GFAとその下のFASの間に確立されたセキュリティ関連が存在すると仮定します。地域の登録をサポートするドメインを設計する場合、このドメインのFASとGFAは互換性がなければなりません。つまり、同じカプセル化タイプ、圧縮メカニズムなどをサポートする必要があります。
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に登録されます。HAに向けられた登録要求メッセージにモバイル外国（MN-FA）認証拡張機能が存在する場合、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.
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はGFAアドレスをMNのケアアドレスとして記録します。
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はGFAアドレスをMNのケアアドレスとして引き続き使用しています。地域登録のための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」フラグが設定されている場合、エージェント広告には少なくとも1つの住所がある必要があります。「i」フラグが設定されており、住所の世話が1つしかない場合、それはFAのアドレスです。「i」フラグが設定されており、複数の住所がある場合、最初の住所はローカルFAであり、最後のケアオブアドレスはGFAです。（これら2つに加えて宣伝されている住所は、このドキュメントの範囲外です）。
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.
FAは、[RFC3344]で定義されているように、モバイルIPv4に従って登録をサポートする必要があります。これにより、地域登録をサポートしないMNSは、標準のモバイルIPv4を使用してこのFAを介して登録できます。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（ホームネットワーク上）への登録を示します。MNが最初に訪問ドメインに到着したとき、新しいHAを要求するとき、またはGFAを変更したときに、住宅登録が実行されます。他の方法では期限切れになるバインディングを更新するために、住宅登録も実行されます。
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のドメイン部分を以前のエージェント広告で受信したドメイン部分と比較して、新しいエージェントに移動したかどうかを判断します。最後の登録以来のドメイン。NAISが一致しない場合、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アドレスがCare of Addressフィールドにある登録要求メッセージを生成し、GFAに直接送信する場合があります（FA経由ではありません）。この場合、MNは、送信する前に登録リクエストに、登録リクエストに、階層外部エージェント（HFA）拡張（セクション9.2を参照）を追加する必要があります（セクション9.2を参照）。HFA拡張は、認証拡張機能によって保護する必要があります。MNがGFAとモビリティセキュリティ協会を確立した場合、HFA拡張はMN-FA認証拡張の前に配置する必要があり、モバイルホーム（MN-HA）認証拡張の後に配置する必要があります。それ以外の場合、MNがGFAと確立されたモビリティセキュリティ協会がない場合、MN-HA認証拡張の前にHFA拡張機能を配置する必要があります。
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は同じGFAのケアオブアドレスを使用して新しい住宅登録を実行して、バインディングを更新します[RFC3344]。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は、All-Zerosのケアオブアドレス（動的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がエージェント広告からオールオーンズケアオブアドレスをコピーした場合に発生する可能性があります）コードフィールドを「貧弱に形成されたリクエスト」に設定して返信します[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はMNからGFAへのパケットをさらに処理するためにトンネルしなければなりません。
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のアドレスである場合、FAは[RFC3344]で説明されているように、メッセージをHAに直接リレーします。保留中または現在の住宅登録ごとに、FAは[RFC3344]で説明されているように訪問者リストエントリを維持します。逆トンネリングが使用されている場合、[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:
保留中または現在の住宅登録ごとに、GFAは[RFC3344]に記載されているように、訪問者リストエントリを維持します。この訪問者リストエントリは、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 HFA拡張で受け取ったMN（すなわち、FAまたは共同配置された住所）の現在のケアのケアo地域登録の残りの寿命o地域登録に使用されるリプレイ保護のスタイルoの識別値地域登録。
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は登録返信にリプレイ保護スタイルの拡張機能（セクション9.3を参照）を追加します。地域登録のためにMNをGFAと同期する識別フィールド。
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.
NonCeベースのリプレイ保護が使用される場合、GFAは登録応答にリプレイ保護スタイルの拡張機能を追加します。この場合、識別フィールドの高次32ビットは、次の地域登録でMNが使用する必要があるNonCEです。
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は登録リクエストを拒否し、repray_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がローカルの住所（つまり、FAのケア）の代わりに、予想される住所（つまり、GFAのケア）からそのようなパケットを受信する必要があるためです。
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は、地域登録の寿命を、MNのHAとの登録の残りの寿命よりも大きくないように設定する必要があります。使用する場合は、他の拡張機能の後に地域登録の寿命延長を追加する必要があり、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のケアのケアまたはCo-Locatedアドレスを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- 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.
MNが同じ訪問ドメイン内の1つのFAから別のFAに移動するとします。その後、新しいFAからエージェント広告を受け取ります。さらに、エージェントの広告は、訪問されたドメインが地域登録をサポートしていることを示していると仮定し、広告されたGFAアドレスは、MNが最後の住宅登録中にそのケアアドレスとして登録したものと同じであるか、または新しく宣伝されたFA-NAIは、MNの以前のFAによって宣伝されたFANAIと一致します。次に、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がそのケアオブアドレスとして登録したGFAと同じではない場合、およびMNが住所のケアを登録したときと同じドメイン内にある場合、MNは実行しようとすることができます登録されたGFAとの地域登録。FAがGFAへの地域登録をサポートできない場合、広告以外に、FAはコード不明_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]で定義されている登録リクエストと返信を使用するのではなく、新しいメッセージタイプを導入する動機は次のとおりです。GFAを使用し、後者ではHAで。（2）GFAのケアオブアドレスの寿命が切れる前に、住宅登録をホームネットワークに送信する必要があります。
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 GFAは、地域登録の残りの寿命o地域登録に使用されているリプレイ保護のスタイル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はGFAの1つのリプレイ保護メカニズムとシーケンスを維持し、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がGFAに宛てられたMNから地域登録要求を受け取ると、通常、HAに宛てられた登録要求の処理規則に従ってメッセージを処理します（セクション5.2を参照）。唯一の違いは、GFA IPアドレスフィールドがHAアドレスフィールドを置き換えることです。そのアドレスが既知のGFAに属している場合、FAは指定されたGFAにリクエストを転送します。それ以外の場合、FAはエラーコード不明_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のアドレスを含める必要があります。これは、FAがMNによって送信されるデータグラムをGFAにトンネルできるようにするために必要です。次に、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が地域の登録要求を受け入れた場合、地域登録の寿命を、MNのHAとの登録の残りの寿命よりも大きくないように設定し、この生涯を対応する地域登録返信に入れなければなりません。GFAは、MNのHAとの登録の寿命が期限切れになった場合、地域登録の要求を受け入れてはなりません。その場合、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.
また、地域の登録により、GFAをMNに動的に割り当てることもできます。訪問されたネットワーク（つまり、FA）は、エージェント広告でオールオーンズのアドレスを宣伝することにより、動的なGFA割り当てのサポートを示しています。次に、MNは登録リクエストにAll-Zerosに登録リクエストに設定して、動的に割り当てられた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アドレス拡張の保護には、GFAからHAに転送されたときに登録要求を保護するための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.
FAから送信されたエージェント広告の「i」フラグが設定され、GFAを示すケアのケアがすべてのものに設定されている場合、これは動的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は登録リクエストでAll-Zerosに登録リクエストで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の割り当てをサポートし、All-Zerosに設定されたアドレスのケアオブアドレスフィールドで登録リクエストを受信した場合、FAはGFAをMNに割り当てます。FAは、すべてのMNSに割り当てるデフォルトの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 sending a Registration Reply with the Code field set to "invalid care-of address".
動的GFA割り当てをサポートしないFAがAll-Zerosに設定されたCare of Addressフィールドで登録要求を受け取る場合、FAは[RFC3344]で説明されているように、つまり、コードに登録返信を送信することにより、リクエストを拒否します。「無効な住所」に設定されています。
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の割り当てをサポートし、All-Zerosに設定されたCare of Addressフィールドで登録リクエストを受け取った場合、GFAは独自のIPアドレスをこのMNのケアアドレスとして割り当て、GFA IPアドレス拡張機能を追加します。登録リクエストへのこのアドレス。GFAは、MN-HA認証が失敗するため、登録リクエストのCare of Addressフィールドに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に設定した登録返信を送信することにより、リクエストを拒否します（セクション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がAll-Zerosに設定されたCare-of Addressの登録要求メッセージを受信しているが、GFA IPアドレス拡張機能がない場合、登録返信メッセージをZero_Careof_Addressに設定した登録返信メッセージを送信してリクエストを拒否する必要があります（セクション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が、All-Zerosに設定されたCare of AddressとGFA IPアドレス拡張機能の登録リクエストを受信した場合、GFAのIPアドレスをMNのCare of MnのCare of of the Mnとして登録する必要があります。モビリティバインディングリスト。登録要求が受け入れられた場合、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.
I地域登録。このドメインは、このドキュメントで指定されている地域登録をサポートしています。
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を含める必要があります。存在する場合、[RFC3344]で定義されている広告拡張機能の後、外国のエージェントNAI（FA-NAI）拡張機能がエージェント広告メッセージに表示される必要があります。
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は、All-Zerosに設定されたアドレスのケアフィールドを使用して登録要求を送信することにより、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がAll-Zerosに設定されたCare of Addressの登録要求メッセージとGFA IPアドレス拡張メッセージを受信する場合、GFAのIPアドレスをMNのケアアドレスとして登録する必要があります。登録返信メッセージを生成する場合、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アドレスフィールドには、Gateway Foreign Agent（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がこの拡張機能を登録要求に追加すると、MNのIPアドレスを使用して、MNのIPアドレスを使用して、MNの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）がMNの保留中の登録記録を設定し、HFA拡張機能のIPアドレスをケアとして使用します。MNの住所の。拡張機能は、認証拡張機能によって保護する必要があります。MNがGFAとモビリティセキュリティ協会を確立した場合、HFA拡張はMN-FA認証拡張の前に配置する必要があり、モバイルホーム（MN-HA）認証拡張の後に配置する必要があります。それ以外の場合、MNがGFAと確立されたモビリティセキュリティ協会がない場合、MN-HA認証拡張の前にHFA拡張機能を配置する必要があります。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がモバイルIPv4を使用してHAでケアオブアドレスを登録する場合、登録メッセージに使用されるリプレイ保護のスタイルは、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で指定されているように、NonCeベースのリプレイ保護を必要とする場合、登録リクエストにリプレイ保護スタイルの拡張機能を追加する場合があります。登録リクエストは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.
地域登録の寿命コードフィールドが登録が受け入れられたことを示した場合、地域登録の寿命フィールドは、地域登録の期限が切れると見なされる前に残り秒数に設定されます。ゼロの値は、MNがGFAに登録されていることを示します。0xffffの値は無限を示します。コードフィールドが住宅登録が拒否されたことを示した場合、地域登録生涯フィールドの内容は不特定であり、受信で無視する必要があります。
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):
HAによって拒否された登録（動的GFA割り当ての場合）：
+---------------------+-------+---------------------+
| 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]は、地域登録メッセージに含まれる場合があります。o FA-HA認証拡張機能[RFC3344]は、地域の登録メッセージに含めてはなりません。
The Regional Registration Request is used by a MN to register with its current GFA.
地域登録要求は、MNが現在のGFAに登録するために使用されます。
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アドレスGateway Foreign Agent（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.
生涯コードフィールドが地域の登録が受け入れられたことを示した場合、生涯フィールドは、地域登録が期限切れと見なされる前に残り秒数に設定されます。ゼロの値は、MNがGFAに登録されていることを示します。0xffffの値は無限を示します。コードフィールドが地域の登録が拒否されたことを示した場合、生涯フィールドの内容は不特定であり、受信時に無視する必要があります。
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.
FAが受信する可能性のあるICMPエラーに応じて、4つの最初のコード値が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認証拡張機能はFASによって使用され、HFA拡張機能を登録要求および地域登録リクエストメッセージに保護します。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）拡張機能が登録リクエストに追加された場合、この拡張機能の後にFA-FA認証拡張機能（セクション11を参照）が続き、データの変更を防ぎます。ドメイン内のFAとGFAのセキュリティ関連は、地域登録前に存在すると想定されています。
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ペアは、GFAをだまして、MNホームアドレスが誤っているために状態を設定することができます。これにより、実際にそのIPアドレスを悪意のあるMNに所有するノードのデータがリダイレクトされます。転送がGFAのホームアドレスに基づいて行われることを考えると、このような攻撃はGFAの接頭辞ではなく、HAのプレフィックスにスコープされます。このタイプの攻撃、またはその結果は、このドキュメントでは考慮されていません。
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 NAI Charining Extension [RFC3846]のサブタイプは、セクション8.2で指定されています。これは、拡張サブタイプを運ぶNAIのスペースから割り当てられた値を必要とする必要があります。
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.
o モバイルIP登録メッセージへの4つの新しい拡張機能：GFA IPアドレス、階層外国エージェント、リプレイ保護スタイル、地域登録寿命（セクション9.1、9.2、9.3、および9.4を参照）。GFA IPアドレス拡張の型値は0〜127の範囲内でなければならず、他の3つは範囲128〜255内でなければなりません。
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 一般化された認証拡張の2つの新しいサブタイプ[RFC4721];セクション11を参照してください。
o Two new message types for Mobile IP: Regional Registration Request and Regional Registration Reply (see Sections 10.1 and 10.2).
o モバイルIPの2つの新しいメッセージタイプ：地域登録要求と地域登録返信（セクション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.
この文書は、パット・カルホーンとガブリエル・モンテネグロと書かれた文書の論理的後継者です。彼らと、この問題の空間を探求するための彼らの多くの努力に感謝します。この文書の大まかなバージョンに関する彼の解説をしてくれたJari Malinenにも感謝します。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G。、「モバイルIPの逆トンネル、改訂版」、RFC 3024、2001年1月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、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.
[RFC3519] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年5月。
[RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
[RFC3846] Johansson、F。およびT. Johansson、「ネットワークアクセス識別子を携帯するためのモバイルIPv4拡張機能」、RFC 3846、2004年6月。
[RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[RFC4721] Perkins、C.、Calhoun、P。、およびJ. Bharatia、「Mobile IPv4 Challenge/Response Extensions（改訂）」、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] Perkins、C。およびP. Calhoun、「認証、認可、および会計（AAA）モバイルIPv4の登録キー」、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] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「直径モバイル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は、モバイルによって提供された資格情報を解析し、適切な承認要求をローカルAAAサーバーに転送します（[RFC3012]および[RFC4004]を参照）。
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登録返信データを受信する場合があります。
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に中継するか、エラーコード不明_GFAでリクエストを拒否することができます。
Authors' Addresses
著者のアドレス
Eva Fogelstroem Ericsson Torshamnsgatan 23 SE-164 80 Stockholm Sweden
Eva Fogelstroem Ericsson Torshamnsgatan 23 Se-164 80 Stockholm Sweden
EMail: eva.fogelstrom@ericsson.com
Annika Jonsson Ericsson Tellusborgsvagen 83-87 S-126 37 Hagersten Sweden
Annika Jonsson Ericsson Tellusborgsvagen 83-87 S-126 37 Hagersten Sweden
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。