[要約] RFC 3024は、モバイルIPの逆トンネリングに関する改訂版であり、モバイルデバイスの通信をセキュアに転送するための方法を提供します。目的は、モバイルデバイスのセキュリティと通信の信頼性を向上させることです。
Network Working Group G. Montenegro, Editor
Request for Comments: 3024 Sun Microsystems, Inc.
Obsoletes: 2344 January 2001
Category: Standards Track
Reverse Tunneling for Mobile IP, revised
モバイルIPの逆トンネル、改訂
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
モバイルインターネットプロトコル（IP）は、ホームエージェントからモバイルノードのケアオブアドレスへのトンネリングを使用しますが、逆方向にはめったにありません。通常、モバイルノードは、外部ネットワーク上のルーターを介してパケットを送信し、ルーティングはソースアドレスから独立していると想定しています。この仮定が真実でない場合、住所からホームエージェントへのトポロジカルな逆トンネルを確立するのが便利です。
This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.
このドキュメントは、トポロジー的に逆トンネルをサポートするために、モバイルIPへの後方互換拡張を提案しています。このドキュメントは、ホームエージェントとモバイルノードのケアオブアドレスの間にあるファイアウォールによってもたらされる問題を解決しようとはしません。
This document obsoletes RFC 2344.
このドキュメントは、RFC 2344を廃止します。
Table of Contents
目次
1. Introduction ................................................... 3
1.1. Terminology .................................................. 4
1.2. Assumptions .................................................. 4
1.3. Justification ................................................ 5
2. Overview ....................................................... 5
3. New Packet Formats ............................................. 6
3.1. Mobility Agent Advertisement Extension ....................... 6
3.2. Registration Request ......................................... 6
3.3. Encapsulating Delivery Style Extension ....................... 7
3.4. New Registration Reply Codes ................................. 8
4. Changes in Protocol Behavior ................................... 9
4.1. Mobile Node Considerations ................................... 9
4.1.1. Sending Registration Requests to the Foreign Agent ......... 9
4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10
4.2. Foreign Agent Considerations ................................. 10
4.2.1. Receiving Registration Requests from the Mobile Node ....... 11
4.2.2. Relaying Registration Requests to the Home Agent ........... 11
4.3. Home Agent Considerations .................................... 11
4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12
4.3.2. Sending Registration Replies to the Foreign Agent .......... 12
5. Mobile Node to Foreign Agent Delivery Styles ................... 13
5.1. Direct Delivery Style ........................................ 13
5.1.1. Packet Processing .......................................... 13
5.1.2. Packet Header Format and Fields ............................ 13
5.2. Encapsulating Delivery Style ................................. 14
5.2.1 Packet Processing ........................................... 14
5.2.2. Packet Header Format and Fields ............................ 15
5.3. Support for Broadcast and Multicast Datagrams ................ 16
5.4. Selective Reverse Tunneling .................................. 16
6. Security Considerations ........................................ 17
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17
6.2. Ingress Filtering ............................................ 18
6.3. Reverse Tunneling for Disparate Address Spaces ............... 18
7. IANA Considerations ............................................ 18
8. Acknowledgements ............................................... 18
References ........................................................ 19
Editor and Chair Addresses ........................................ 20
Appendix A: Disparate Address Space Support ....................... 21
A.1. Scope of the Reverse Tunneling Solution ................... 21
A.2. Terminating Forward Tunnels at the Foreign Agent .......... 24
A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 26
A.4. Limited Private Address Scenario .......................... 26
Appendix B: Changes from RFC2344 .................................. 29
Full Copyright Statement .......................................... 30
Section 1.3 of the Mobile IP specification [1] lists the following assumption:
モバイルIP仕様[1]のセクション1.3には、次の仮定がリストされています。
It is assumed that IP unicast datagrams are routed based on the destination address in the datagram header (i.e., not by source address).
IPユニキャストデータグラムは、データグラムヘッダーの宛先アドレスに基づいてルーティングされると想定されています（つまり、ソースアドレスではありません）。
Because of security concerns (for example, IP spoofing attacks), and in accordance with RFC 2267 [8] and CERT [3] advisories to this effect, routers that break this assumption are increasingly more common.
セキュリティの懸念（たとえば、IPスプーフィング攻撃）のため、およびこの効果に対するRFC 2267 [8]およびCERT [3]の勧告に従って、この仮定を破るルーターはますます一般的になります。
In the presence of such routers, the source and destination IP address in a packet must be topologically correct. The forward tunnel complies with this, as its endpoints (home agent address and care-of address) are properly assigned addresses for their respective locations. On the other hand, the source IP address of a packet transmitted by the mobile node does not correspond to the network prefix from where it emanates.
このようなルーターの存在下では、パケット内のソースおよび宛先IPアドレスはトポロジカルに正しい必要があります。そのエンドポイント（ホームエージェントアドレスと住所）は、それぞれの場所のアドレスが適切に割り当てられているため、前方トンネルはこれに準拠しています。一方、モバイルノードから送信されたパケットのソースIPアドレスは、発せられる場所からネットワークプレフィックスに対応していません。
This document discusses topologically correct reverse tunnels.
このドキュメントでは、トポロジー的に正しい逆トンネルについて説明します。
Mobile IP does dictate the use of reverse tunnels in the context of multicast datagram routing and mobile routers. However, the source IP address is set to the mobile node's home address, so these tunnels are not topologically correct.
モバイルIPは、マルチキャストデータグラムルーティングとモバイルルーターのコンテキストで逆トンネルの使用を指示します。ただし、ソースIPアドレスはモバイルノードのホームアドレスに設定されているため、これらのトンネルはトポロジカルでは正しいものではありません。
Notice that there are several uses for reverse tunnels regardless of their topological correctness:
トポロジーの正しさに関係なく、逆トンネルにはいくつかの用途があることに注意してください。
- Mobile routers: reverse tunnels obviate the need for recursive tunneling [1].
- モバイルルーター：リバーストンネルは、再帰トンネリングの必要性を回します[1]。
- Multicast: reverse tunnels enable a mobile node away from home to (1) join multicast groups in its home network, and (2) transmit multicast packets such that they emanate from its home network [1].
- マルチキャスト：リバーストンネルは、自宅から離れたモバイルノードを有効にして、（1）ホームネットワークでマルチキャストグループに参加し、（2）ホームネットワークから発生するようにマルチキャストパケットを送信します[1]。
- The TTL of packets sent by the mobile node (for example, when sending packets to other hosts in its home network) may be so low that they might expire before reaching their destination. A reverse tunnel solves the problem as it represents a TTL decrement of one [5].
- モバイルノードから送信されるパケットのTTL（たとえば、ホームネットワークの他のホストにパケットを送信するとき）は非常に低いため、目的地に到達する前に期限切れになる可能性があります。逆トンネルは、1つのTTL減少を表すため、問題を解決します[5]。
The discussion below uses terms defined in the Mobile IP specification. Additionally, it uses the following terms:
以下の説明では、モバイルIP仕様で定義されている用語を使用しています。さらに、次の用語を使用します。
Forward Tunnel
前方トンネル
A tunnel that shuttles packets towards the mobile node. It starts at the home agent, and ends at the mobile node's care-of address.
モバイルノードに向かってパケットをシャトルするトンネル。ホームエージェントから始まり、モバイルノードのケアオブアドレスで終わります。
Reverse Tunnel
逆トンネル
A tunnel that starts at the mobile node's care-of address and terminates at the home agent.
モバイルノードの住所から始まり、ホームエージェントで終了するトンネル。
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 [9].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [9]に記載されているように解釈される。
Mobility is constrained to a common IP address space (that is, the routing fabric between, say, the mobile node and the home agent is not partitioned into a "private" and a "public" network).
モビリティは、一般的なIPアドレススペースに制約されます（つまり、モバイルノードとホームエージェントの間のルーティングファブリックは、「プライベート」と「パブリック」ネットワークに分割されていません）。
This document does not attempt to solve the firewall traversal problem. Rather, it assumes one of the following is true:
このドキュメントは、ファイアウォールのトラバーサル問題を解決しようとはしません。むしろ、それは次のいずれかが真実であると仮定します：
- There are no intervening firewalls along the path of the tunneled packets.
- トンネルパケットの経路に沿って介在するファイアウォールはありません。
- Any intervening firewalls share the security association necessary to process any authentication [6] or encryption [7] headers which may have been added to the tunneled packets.
- 介在するファイアウォールは、トンネルパケットに追加された可能性のある認証[6]または暗号化[7]ヘッダーを処理するために必要なセキュリティ協会を共有します。
The reverse tunnels considered here are symmetric, that is, they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel. IP in IP encapsulation [2] is assumed unless stated otherwise.
ここで考慮される逆トンネルは対称です。つまり、フォワードトンネルと同じ構成（カプセル化方法、IPアドレスエンドポイント）を使用します。IPカプセル化[2]のIPは、特に明記しない限り想定されます。
Route optimization [4] introduces forward tunnels initiated at a correspondent host. Since a mobile node may not know if the correspondent host can decapsulate packets, reverse tunnels in that context are not discussed here.
Route Optimization [4]は、特派員のホストで開始された前方のトンネルを導入します。モバイルノードは、特派員のホストがパケットを脱カプセル化できるかどうかを知らない場合があるため、そのコンテキストでの逆トンネルはここでは説明されていません。
Why not let the mobile node itself initiate the tunnel to the home agent? This is indeed what it should do if it is already operating with a topologically correct co-located care-of address.
モバイルノード自体にホームエージェントにトンネルを開始させてみませんか？これは確かに、トポロジカルで正しい共同配置された住所ですでに動作している場合に行うべきことです。
However, one of the primary objectives of the Mobile IP specification is not to require this mode of operation.
ただし、モバイルIP仕様の主な目的の1つは、この操作モードを必要としないことです。
The mechanisms outlined in this document are primarily intended for use by mobile nodes that rely on the foreign agent for forward tunnel support. It is desirable to continue supporting these mobile nodes, even in the presence of filtering routers.
このドキュメントで概説されているメカニズムは、主に、外国のエージェントに依存して順方向トンネルサポートを提供するモバイルノードが使用することを目的としています。フィルタリングルーターが存在する場合でも、これらのモバイルノードをサポートし続けることが望ましいです。
A mobile node arrives at a foreign network, listens for agent advertisements and selects a foreign agent that supports reverse tunnels. It requests this service when it registers through the selected foreign agent. At this time, and depending on how the mobile node wishes to deliver packets to the foreign agent, it also requests either the Direct or the Encapsulating Delivery Style (section 5).
モバイルノードは、外国のネットワークに到着し、エージェントの広告を聴き、逆トンネルをサポートする外国人エージェントを選択します。選択した外国人エージェントを介して登録するときに、このサービスを要求します。現時点では、モバイルノードが外国人エージェントにパケットを配信する方法によって、直接またはカプセル化の配信スタイルも要求します（セクション5）。
In the Direct Delivery Style, the mobile node designates the foreign agent as its default router and proceeds to send packets directly to the foreign agent, that is, without encapsulation. The foreign agent intercepts them, and tunnels them to the home agent.
直接配信スタイルでは、モバイルノードは外国人エージェントをデフォルトのルーターとして指定し、外国人エージェント、つまりカプセル化なしでパケットを直接送信します。外国人エージェントはそれらを傍受し、それらをホームエージェントにトンネルします。
In the Encapsulating Delivery Style, the mobile node encapsulates all its outgoing packets to the foreign agent. The foreign agent decapsulates and re-tunnels them to the home agent, using the foreign agent's care-of address as the entry-point of this new tunnel.
カプセル化配信スタイルでは、モバイルノードはすべての発信パケットを外国人エージェントにカプセル化します。外国人のエージェントは、外国人のエージェントのケアオブアドレスをこの新しいトンネルのエントリポイントとして使用して、それらをホームエージェントに脱カプセル化し、再攻撃します。
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|V|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The only change to the Mobility Agent Advertisement Extension [1] is the additional 'T' bit:
モビリティエージェント広告拡張機能[1]の唯一の変更は、追加の「t」ビットです。
T Agent offers reverse tunneling service.
Tエージェントは逆トンネルサービスを提供しています。
A foreign agent that sets the 'T' bit MUST support the Direct Delivery Style. Encapsulating Delivery Style SHOULD be supported as well (section 5).
「T」ビットを設定する外国人エージェントは、直接配達スタイルをサポートする必要があります。配信スタイルのカプセル化もサポートする必要があります（セクション5）。
Using this information, a mobile node is able to choose a foreign agent that supports reverse tunnels. Notice that if a mobile node does not understand this bit, it simply ignores it as per [1].
この情報を使用して、モバイルノードは逆トンネルをサポートする外国のエージェントを選択できます。モバイルノードがこのビットを理解していない場合、[1]に従って単に無視するだけであることに注意してください。
Reverse tunneling support is added directly into the Registration Request by using one of the "rsvd" bits. If a foreign or home agent that does not support reverse tunnels receives a request with the 'T' bit set, the Registration Request fails. This results in a registration denial (failure codes are specified in section 3.4).
「RSVD」ビットのいずれかを使用して、リバーストンネルサポートが登録要求に直接追加されます。リバーストンネルをサポートしない外国人またはホームエージェントが「T」ビットセットでリクエストを受け取った場合、登録要求は失敗します。これにより、登録拒否が行われます（障害コードはセクション3.4で指定されています）。
Home agents SHOULD NOT object to providing reverse tunnel support, because they "SHOULD be able to decapsulate and further deliver packets addressed to themselves, sent by a mobile node" [1]. In the case of topologically correct reverse tunnels, the packets are not sent by the mobile node as distinguished by its home address. Rather, the outermost (encapsulating) IP source address on such datagrams is the care-of address of the mobile node.
ホームエージェントは、「モバイルノードによって送信された自分自身にアドレス指定されたパケットを脱カプセル化し、さらに配信できる必要があるため、逆トンネルのサポートを提供することに反対するべきではありません[1]。トポロジカルで正しい逆トンネルの場合、自宅の住所で区別されるように、パケットはモバイルノードによって送信されません。むしろ、このようなデータグラムの最も外側の（カプセル化）IPソースアドレスは、モバイルノードのケアアドレスです。
In Registration Requests sent by a mobile node, the Time to Live field in the IP header MUST be set to 255. This limits a denial of service attack in which malicious hosts send false Registration Requests (see Section 6).
モバイルノードから送信された登録リクエストでは、IPヘッダーのライブフィールドへの時間を255に設定する必要があります。これにより、悪意のあるホストが誤った登録要求を送信するサービス拒否攻撃が制限されます（セクション6を参照）。
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|V|T|-| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The only change to the Registration Request packet is the additional 'T' bit:
登録要求パケットの唯一の変更は、追加の「t」ビットです。
T If the 'T' bit is set, the mobile node asks its home agent to accept a reverse tunnel from the care-of address. Mobile nodes using a foreign agent care-of address ask the foreign agent to reverse-tunnel its packets.
t「t」ビットが設定されている場合、モバイルノードはホームエージェントに、住所のケアから逆トンネルを受け入れるように依頼します。外国人エージェントのケアオブアドレスを使用したモバイルノードは、外国人エージェントにパケットを逆転させるように依頼します。
The Encapsulating Delivery Style Extension MAY be included by the mobile node in registration requests to further specify reverse tunneling behavior. It is expected to be used only by the foreign agent. Accordingly, the foreign agent MUST consume this extension (that is, it must not relay it to the home agent or include it in replies to the mobile node). As per Section 3.6.1.3 of [1], the mobile node MUST include the Encapsulating Delivery Style Extension after the Mobile-Home Authentication Extension, and before the Mobile-Foreign Authentication Extension, if present.
逆トンネリング動作をさらに指定するために、登録要求にモバイルノードによってカプセル化された配信スタイルの拡張機能が含まれる場合があります。外国人がのみ使用することが期待されています。したがって、外国人エージェントはこの拡張機能を消費する必要があります（つまり、ホームエージェントに伝えたり、モバイルノードへの返信に含めてはいけません）。[1]のセクション3.6.1.3によると、モバイルノードには、モバイルホーム認証拡張の後、モバイル外定認証拡張の前に存在する場合は、カプセル化配信スタイルの拡張機能を含める必要があります。
The Encapsulating Delivery Style Extension MUST NOT be included if the 'T' bit is not set in the Registration Request.
「T」ビットが登録リクエストに設定されていない場合、カプセル化配信スタイルの拡張機能を含めてはなりません。
If this extension is absent, Direct Delivery is assumed. Encapsulation is done according to what was negotiated for the forward tunnel (that is, IP in IP is assumed unless specified otherwise). For more details on the delivery styles, please refer to section 5.
この拡張機能がない場合、直接配信が想定されます。カプセル化は、前方トンネルのために交渉されたものに従って行われます（つまり、特に指定されていない限り、IPのIPは想定されます）。配信スタイルの詳細については、セクション5を参照してください。
Foreign agents SHOULD support the Encapsulating Delivery Style Extension.
外国人エージェントは、カプセル化配信スタイルの拡張をサポートする必要があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
130
130
Length
長さ
0
0
Foreign and home agent registration replies MUST convey if the reverse tunnel request failed. These new reply codes are defined:
外国およびホームエージェントの登録返信は、逆トンネルの要求が失敗した場合に伝える必要があります。これらの新しい返信コードは定義されています。
Service denied by the foreign agent:
外国人が拒否したサービス：
74 requested reverse tunnel unavailable 75 reverse tunnel is mandatory and 'T' bit not set 76 mobile node too distant 79 delivery style not supported
74要求されたリバーストンネルが利用できない75逆トンネルは必須であり、「t」ビットが設定されていない76モバイルノードがあまりにも遠すぎる79配信スタイルがサポートされていない
NOTE: Code 79 has not yet been assigned by IANA.
注：コード79はまだIANAによって割り当てられていません。
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
Service denied by the home agent:
ホームエージェントによるサービス：
137 requested reverse tunnel unavailable 138 reverse tunnel is mandatory and 'T' bit not set 139 requested encapsulation unavailable
137要求された逆トンネルの利用不可能138逆トンネルは必須であり、「t」ビットが設定されていない139要求されたカプセル化は利用できません
In response to a Registration Request with the 'T' bit set, mobile nodes may receive (and MUST accept) code 70 (poorly formed request) from foreign agents and code 134 (poorly formed request) from home agents. However, foreign and home agents that support reverse tunneling MUST use codes 74 and 137, respectively.
「t」ビットセットの登録要求に応じて、モバイルノードは、外国人エージェントからコード70（貧弱に形成された要求）を受信（受け入れる必要があります）、および在宅エージェントからコード134（不十分に形成された要求）を受け取ることができます。ただし、逆トンネリングをサポートする外国人およびホームエージェントは、それぞれコード74と137を使用する必要があります。
In addition to setting the 'T' bit, the mobile node also MAY request the Encapsulating Delivery Style by including the corresponding extension. If a foreign agent does not implement the Encapsulating Delivery Style, it MUST respond to the mobile node with code 79 (delivery style not supported). This also applies if the foreign agent does not support a requested delivery style that may be defined in the future.
「T」ビットを設定することに加えて、モバイルノードは、対応する拡張機能を含めることにより、カプセル化する配信スタイルを要求する場合もあります。外国人エージェントがカプセル化配信スタイルを実装していない場合、コード79（配信スタイルはサポートされていない）でモバイルノードに応答する必要があります。これは、外国人が将来定義される可能性のある要求された配送スタイルをサポートしていない場合にも適用されます。
Absence of the 'T' bit in a Registration Request MAY elicit denials with codes 75 and 138 at the foreign agent and the home agent, respectively.
登録要求に「t」ビットがない場合、外国人エージェントとホームエージェントでそれぞれコード75および138で拒否を引き出す可能性があります。
Forward and reverse tunnels are symmetric, that is, both are able to use the same tunneling options negotiated at registration. This implies that the home agent MUST deny registrations if an unsupported form of tunneling is requested (code 139). Notice that Mobile IP [1] already defines the analogous failure code 72 for use by the foreign agent.
前方および逆トンネルは対称です。つまり、両方とも登録時に交渉された同じトンネルオプションを使用できます。これは、サポートされていない形式のトンネルが要求された場合、ホームエージェントが登録を拒否しなければならないことを意味します（コード139）。モバイルIP [1]は、外国のエージェントが使用するための類似の障害コード72を既に定義していることに注意してください。
Unless otherwise specified, behavior specified by Mobile IP [1] is assumed. In particular, if any two entities share a mobility security association, they MUST use the appropriate Authentication Extension (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication Extension) when exchanging registration protocol datagrams. An admissible authentication extension (for example the Mobile-Home Authentication Extension) MUST always be present to authenticate registration messages between a mobile node and its home agent.
特に指定されていない限り、モバイルIP [1]によって指定された動作が想定されます。特に、2つのエンティティがモビリティセキュリティ協会を共有している場合、登録プロトコルデータグラムを交換する際に、適切な認証拡張機能（モバイル外国、またはモバイルホーム認証拡張機能）を使用する必要があります。モバイルノードとそのホームエージェント間の登録メッセージを認証するには、許容可能な認証拡張機能（モバイルホーム認証拡張機能など）を常に存在する必要があります。
Reverse tunneling imposes additional protocol processing requirements on mobile entities. Differences in protocol behavior with respect to Mobile IP [1] are specified in the subsequent sections.
逆トンネリングは、モバイルエンティティに追加のプロトコル処理要件を課します。モバイルIP [1]に関するプロトコル挙動の違いは、後続のセクションで指定されています。
This section describes how the mobile node handles registrations that request a reverse tunnel.
このセクションでは、モバイルノードが逆トンネルを要求する登録を処理する方法について説明します。
In addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel.
[1]の考慮事項に加えて、モバイルノードは登録リクエストで「T」ビットを逆トンネルに請願するために設定します。
The mobile node MUST set the TTL field of the IP header to 255. This is meant to limit the reverse tunnel hijacking attack (Section 6).
モバイルノードは、IPヘッダーのTTLフィールドを255に設定する必要があります。これは、逆トンネルハイジャック攻撃を制限することを目的としています（セクション6）。
The mobile node MAY optionally include an Encapsulating Delivery Style Extension.
モバイルノードには、オプションで、配信スタイルの拡張機能がカプセル化される場合があります。
Possible valid responses are:
可能な有効な応答は次のとおりです。
- A registration denial issued by either the home agent or the foreign agent:
- ホームエージェントまたは外国人エージェントのいずれかによって発行された登録拒否：
a. The mobile node follows the error checking guidelines in [1], and depending on the reply code, MAY try modifying the registration request (for example, by eliminating the request for alternate forms of encapsulation or delivery style), and issuing a new registration.
a. モバイルノードは、[1]のエラーチェックガイドラインに従い、返信コードに応じて、登録リクエストを変更してみることができます（たとえば、カプセル化または配信スタイルの代替フォームのリクエストを排除し、新しい登録を発行することができます。
b. Depending on the reply code, the mobile node MAY try zeroing the 'T' bit, eliminating the Encapsulating Delivery Style Extension (if one was present), and issuing a new registration. Notice that after doing so the registration may succeed, but due to the lack of a reverse tunnel data transfer may not be possible.
b. 返信コードに応じて、モバイルノードは「T」ビットをゼロにし、カプセル化する配信スタイルの拡張機能（存在する場合）を排除し、新しい登録を発行することができます。そうすることで登録が成功する可能性がありますが、逆トンネルのデータ転送がないため、不可能かもしれません。
- The home agent returns a Registration Reply indicating that the service will be provided.
- ホームエージェントは、サービスが提供されることを示す登録返信を返します。
In this last case, the mobile node has succeeded in establishing a reverse tunnel between its care-of address and its home agent. If the mobile node is operating with a co-located care-of address, it MAY encapsulate outgoing data such that the destination address of the outer header is the home agent. This ability to selectively reverse-tunnel packets is discussed further in section 5.4.
この最後のケースでは、モバイルノードは、住所とホームエージェントの間に逆トンネルを確立することに成功しました。モバイルノードが共同配置された住所で動作している場合、外側のヘッダーの宛先アドレスがホームエージェントになるように、発信データをカプセル化する可能性があります。タンネルパケットを選択的に逆転させるこの機能については、セクション5.4でさらに説明します。
If the care-of address belongs to a separate foreign agent, the mobile node MUST employ whatever delivery style was requested (Direct or Encapsulating) and proceed as specified in section 5.
住所のケアが別の外国人エージェントに属している場合、モバイルノードは、要求された配信スタイル（直接またはカプセル化）を使用して、セクション5で指定されたとおりに進める必要があります。
A successful registration reply is an assurance that both the foreign agent and the home agent support whatever alternate forms of encapsulation (other than IP in IP) were requested. Accordingly, the mobile node MAY use them at its discretion.
登録返信の成功とは、外国人エージェントとホームエージェントの両方が、カプセル化の代替形式（IPのIP以外）が要求されたものをサポートするという保証です。したがって、モバイルノードはその裁量でそれらを使用する場合があります。
This section describes how the foreign agent handles registrations that request a reverse tunnel.
このセクションでは、外国人が逆トンネルを要求する登録を処理する方法について説明します。
A foreign agent that receives a Registration Request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1], and determines whether it can accommodate the forward tunnel request. If it cannot, it returns an appropriate code. In particular, if the foreign agent is unable to support the requested form of encapsulation it MUST return code 72. If it cannot support the requested form of delivery style it MUST return code 79 (delivery style not supported).
「T」ビットを使用して登録要求を受信する外国人エージェントは、モバイルIP仕様[1]で指定されたパケットを処理し、フォワードトンネルリクエストに対応できるかどうかを決定します。できない場合は、適切なコードを返します。特に、外国人エージェントが要求されたフォームのカプセル化をサポートできない場合、コード72を返す必要があります。
The foreign agent MAY reject Registration Requests without the 'T' bit set by denying them with code 75 (reverse tunnel is mandatory and 'T' bit not set).
外国人エージェントは、コード75でそれらを拒否することにより、「T」ビットなしで登録リクエストを拒否できます（逆トンネルは必須であり、「T」ビットが設定されていません）。
The foreign agent MUST verify that the TTL field of the IP header is set to 255. Otherwise, it MUST reject the registration with code 76 (mobile node too distant). The foreign agent MUST limit the rate at which it sends these registration replies to a maximum of one per second.
外国人エージェントは、IPヘッダーのTTLフィールドが255に設定されていることを確認する必要があります。そうでなければ、コード76（モバイルノードが遠すぎます）で登録を拒否する必要があります。外国のエージェントは、これらの登録返信を最大1秒に送信するレートを制限する必要があります。
As a last check, the foreign agent verifies that it can support a reverse tunnel with the same configuration. If it cannot, it MUST return a Registration Reply denying the request with code 74 (requested reverse tunnel unavailable).
最後のチェックとして、外国人エージェントは、同じ構成で逆トンネルをサポートできることを確認します。できない場合は、コード74でリクエストを拒否する登録返信を返す必要があります（リクエストされた逆トンネルは利用できません）。
Otherwise, the foreign agent MUST relay the Registration Request to the home agent.
それ以外の場合、外国人エージェントは登録要求をホームエージェントに中継する必要があります。
Upon receipt of a Registration Reply that satisfies validity checks, the foreign agent MUST update its visitor list, including indication that this mobile node has been granted a reverse tunnel and the delivery style expected (section 5).
有効性チェックを満たす登録回答を受け取ると、外国人エージェントは訪問者リストを更新する必要があります。これには、このモバイルノードに逆トンネルが付与されており、予想される配信スタイルが付与されています（セクション5）。
While this visitor list entry is in effect, the foreign agent MUST process incoming traffic according to the delivery style, encapsulate it and tunnel it from the care-of address to the home agent's address.
この訪問者リストエントリは有効ですが、外国人エージェントは配達スタイルに応じて着信トラフィックを処理し、それをカプセル化して、住所からホームエージェントの住所までトンネルを鳴らす必要があります。
This section describes how the home agent handles registrations that request a reverse tunnel.
このセクションでは、ホームエージェントが逆トンネルを要求する登録を処理する方法について説明します。
A home agent that receives a Registration Request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1] and determines whether it can accommodate the forward tunnel request. If it cannot, it returns an appropriate code. In particular, if the home agent is unable to support the requested form of encapsulation it MUST return code 139 (requested encapsulation unavailable).
「T」ビットを使用して登録要求を受信するホームエージェントは、モバイルIP仕様[1]で指定されたパケットを処理し、フォワードトンネルリクエストに対応できるかどうかを判断します。できない場合は、適切なコードを返します。特に、ホームエージェントが要求されたフォームのカプセル化をサポートできない場合、コード139を返す必要があります（要求されたカプセル化は利用できません）。
The home agent MAY reject registration requests without the 'T' bit set by denying them with code 138 (reverse tunnel is mandatory and ' T' bit not set).
ホームエージェントは、コード138で拒否して「T」ビットなしで登録リクエストを拒否できます（逆トンネルは必須であり、「T」ビットが設定されていません）。
As a last check, the home agent determines whether it can support a reverse tunnel with the same configuration as the forward tunnel. If it cannot, it MUST send back a registration denial with code 137 (requested reverse tunnel unavailable).
最後のチェックとして、ホームエージェントは、前方トンネルと同じ構成で逆トンネルをサポートできるかどうかを決定します。できない場合は、コード137（リバーストンネルが利用できない要求）で登録の拒否を返送する必要があります。
Upon receipt of a Registration Reply that satisfies validity checks, the home agent MUST update its mobility bindings list to indicate that this mobile node has been granted a reverse tunnel and the type of encapsulation expected.
有効性チェックを満たす登録回答を受け取ると、ホームエージェントはモビリティバインディングリストを更新して、このモバイルノードに逆トンネルと予想されるカプセル化の種類が付与されていることを示す必要があります。
In response to a valid Registration Request, a home agent MUST issue a Registration Reply to the mobile node.
有効な登録要求に応じて、ホームエージェントはモバイルノードへの登録返信を発行する必要があります。
After a successful registration, the home agent may receive encapsulated packets addressed to itself. Decapsulating such packets and blindly injecting them into the network is a potential security weakness (section 6.1). Accordingly, the home agent MUST implement, and, by default, SHOULD enable the following check for encapsulated packets addressed to itself:
登録が成功した後、ホームエージェントはそれ自体にアドレス指定されたカプセル化されたパケットを受信する場合があります。このようなパケットを脱カプセル化し、それらをネットワークに盲目的に注入することは、潜在的なセキュリティの弱点です（セクション6.1）。したがって、ホームエージェントは実装する必要があり、デフォルトでは、それ自体に対処されたカプセル化されたパケットの次のチェックを有効にする必要があります。
The home agent searches for a mobility binding whose care-of address is the source of the outer header, and whose mobile node address is the source of the inner header.
ホームエージェントは、外部ヘッダーのソースであり、モバイルノードアドレスが内側ヘッダーのソースであるモビリティバインディングを検索します。
If no such binding is found, or if the packet uses an encapsulation mechanism that was not negotiated at registration the home agent MUST silently discard the packet and SHOULD log the event as a security exception.
そのようなバインディングが見つからない場合、または登録時に交渉されなかったカプセル化メカニズムをパケットが使用する場合、ホームエージェントはパケットを静かに廃棄しなければならず、セキュリティ例外としてイベントを記録する必要があります。
Home agents that terminate tunnels unrelated to Mobile IP (for example, multicast tunnels) MAY turn off the above check, but this practice is discouraged for the aforementioned reasons.
モバイルIP（たとえば、マルチキャストトンネルなど）と関係のないトンネルを終了するホームエージェントは、上記のチェックをオフにする可能性がありますが、この慣行は前述の理由で推奨されています。
While the registration is in effect, a home agent MUST process each valid reverse tunneled packet (as determined by checks like the above) by decapsulating it, recovering the original packet, and then forwarding it on behalf of its sender (the mobile node) to the destination address (the correspondent host).
登録が有効ですが、ホームエージェントは、それを脱カプセル化し、元のパケットを回復し、送信者（モバイルノード）に代わって転送することにより、それぞれ有効な逆トンネルパケット（上記のようなチェックによって決定されます）を処理する必要があります（モバイルノード）宛先アドレス（特派員ホスト）。
This section specifies how the mobile node sends its data traffic via the foreign agent. In all cases, the mobile node learns the foreign agent's link-layer address from the link-layer header in the agent advertisement.
このセクションでは、モバイルノードが外国人エージェントを介してデータトラフィックを送信する方法を指定します。すべての場合において、モバイルノードは、エージェント広告のリンク層ヘッダーから外国人エージェントのリンク層アドレスを学習します。
This delivery mechanism is very simple to implement at the mobile node, and uses small (non-encapsulated) packets on the link between the mobile node and the foreign agent (potentially a very slow link). However, it only supports reverse-tunneling of unicast packets, and does not allow selective reverse tunneling (section 5.4).
この配信メカニズムは、モバイルノードで実装するのが非常に簡単で、モバイルノードと外国エージェントの間のリンクで小さな（カプセル化されていない）パケットを使用します（潜在的に非常に遅いリンク）。ただし、ユニキャストパケットのリバースタンネルのみをサポートし、選択的な逆トンネリングを許可しません（セクション5.4）。
The mobile node MUST designate the foreign agent as its default router. Not doing so will not guarantee encapsulation of all the mobile node's outgoing traffic, and defeats the purpose of the reverse tunnel. The foreign agent MUST:
モバイルノードは、外部エージェントをデフォルトのルーターとして指定する必要があります。そうしないと、すべてのモバイルノードの発信トラフィックのカプセル化が保証されず、逆トンネルの目的を打ち負かします。外国人がしなければなりません：
- detect packets sent by the mobile node, and
- モバイルノードから送信されたパケットを検出します
- modify its forwarding function to encapsulate them before forwarding.
- 転送前に転送機能を変更してカプセル化します。
This section shows the format of the packet headers used by the Direct Delivery style. The formats shown assume IP in IP encapsulation [2].
このセクションは、直接配信スタイルで使用されるパケットヘッダーの形式を示しています。示されている形式は、IPカプセル化のIPを想定しています[2]。
Packet format received by the foreign agent (Direct Delivery Style):
外国人エージェントが受信したパケット形式（直接配達スタイル）：
IP fields: Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IPフィールド：ソースアドレス=モバイルノードのホームアドレス宛先アドレス=特派員ホストのアドレス上層層プロトコル
Packet format forwarded by the foreign agent (Direct Delivery Style):
外国人エージェントによって転送されたパケット形式（直接配達スタイル）：
IP fields (encapsulating header): Source Address = foreign agent's care-of address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IPフィールド（ヘッダーのカプセル化）：ソースアドレス=外国人エージェントのケアオブアドレス宛先アドレス=ホームエージェントのアドレスプロトコルフィールド：4（IP IN IP）IPフィールド（元のヘッダー）：ソースアドレス=モバイルノードのホームアドレス宛先上層層プロトコルをアドレスします
These fields of the encapsulating header MUST be chosen as follows:
カプセル化ヘッダーのこれらのフィールドは、次のように選択する必要があります。
IP Source Address
IPソースアドレス
Copied from the Care-of Address field within the Registration Request.
登録リクエスト内の住所ケアフィールドからコピーされました。
IP Destination Address
IP宛先アドレス
Copied from the Home Agent field within the most recent successful Registration Reply.
最新の成功した登録返信内でホームエージェントフィールドからコピーされました。
IP Protocol Field
IPプロトコルフィールド
Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time.
デフォルトは4（IP [2]のIP）ですが、その他のカプセル化方法は、登録時にネゴシエートされたものとして使用できます。
This mechanism requires that the mobile node implement encapsulation, and explicitly directs packets at the foreign agent by designating it as the destination address in a new outermost header. Mobile nodes that wish to send either broadcast or multicast packets MUST use the Encapsulating Delivery Style.
このメカニズムでは、モバイルノードがカプセル化を実装し、新しい外側のヘッダーの宛先アドレスとして指定することにより、外部エージェントにパケットを明示的に指示する必要があります。ブロードキャストまたはマルチキャストパケットのいずれかを送信したいモバイルノードは、カプセル化する配信スタイルを使用する必要があります。
The foreign agent does not modify its forwarding function. Rather, it receives an encapsulated packet and after verifying that it was sent by the mobile node, it:
外国人エージェントは転送機能を変更しません。むしろ、カプセル化されたパケットを受信し、モバイルノードによって送信されたことを確認した後、次のとおりです。
- decapsulates to recover the inner packet,
- 内側のパケットを回復するために脱カプセル化します。
- re-encapsulates, and sends it to the home agent.
- 再カプセル化し、ホームエージェントに送信します。
If a foreign agent receives an un-encapsulated packet from a mobile node which had explicitly requested the Encapsulated Delivery Style, then the foreign agent MUST NOT reverse tunnel such a packet and rather MUST forward it using standard, IP routing mechanisms.
外国人エージェントが、カプセル化された配信スタイルを明示的に要求したモバイルノードからカプセル化されていないパケットを受け取った場合、外国人エージェントはそのようなパケットを逆転させてはならず、標準のIPルーティングメカニズムを使用して転送する必要があります。
This section shows the format of the packet headers used by the Encapsulating Delivery style. The formats shown assume IP in IP encapsulation [2].
このセクションでは、カプセル化配信スタイルで使用されるパケットヘッダーの形式を示します。示されている形式は、IPカプセル化のIPを想定しています[2]。
Packet format received by the foreign agent (Encapsulating Delivery Style):
外国人エージェントが受信したパケット形式（配信スタイルのカプセル化）：
IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = foreign agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IPフィールド（ヘッダーのカプセル化）：ソースアドレス=モバイルノードのホームアドレス宛先アドレス=外国エージェントのアドレスプロトコルフィールド：4（IP IN IP）IPフィールド（元のヘッダー）：ソースアドレス=モバイルノードのホームアドレス宛先レイヤープロトコル
The fields of the encapsulating IP header MUST be chosen as follows:
カプセル化IPヘッダーのフィールドは、次のように選択する必要があります。
IP Source Address
IPソースアドレス
The mobile node's home address.
モバイルノードのホームアドレス。
IP Destination Address
IP宛先アドレス
The address of the agent as learned from the IP source address of the agent's most recent successful registration reply.
エージェントの最新の成功した登録返信のIPソースアドレスから学んだエージェントのアドレス。
IP Protocol Field
IPプロトコルフィールド
Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time.
デフォルトは4（IP [2]のIP）ですが、その他のカプセル化方法は、登録時にネゴシエートされたものとして使用できます。
Packet format forwarded by the foreign agent (Encapsulating Delivery Style):
外国人エージェントによって転送されたパケット形式（配信スタイルのカプセル）：
IP fields (encapsulating header): Source Address = foreign agent's care-of address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IPフィールド（ヘッダーのカプセル化）：ソースアドレス=外国人エージェントのケアオブアドレス宛先アドレス=ホームエージェントのアドレスプロトコルフィールド：4（IP IN IP）IPフィールド（元のヘッダー）：ソースアドレス=モバイルノードのホームアドレス宛先上層層プロトコルをアドレスします
These fields of the encapsulating IP header MUST be chosen as follows:
カプセル化IPヘッダーのこれらのフィールドは、次のように選択する必要があります。
IP Source Address
IPソースアドレス
Copied from the Care-of Address field within the Registration Request.
登録リクエスト内の住所ケアフィールドからコピーされました。
IP Destination Address
IP宛先アドレス
Copied from the Home Agent field within the most recent successful Registration Reply.
最新の成功した登録返信内でホームエージェントフィールドからコピーされました。
IP Protocol Field
IPプロトコルフィールド
Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time.
デフォルトは4（IP [2]のIP）ですが、その他のカプセル化方法は、登録時にネゴシエートされたものとして使用できます。
If a mobile node is operating with a co-located care-of address, broadcast and multicast datagrams are handled according to Sections 4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a foreign agent care-of address MAY have their broadcast and multicast datagrams reverse-tunneled by the foreign agent. However, any mobile nodes doing so MUST use the encapsulating delivery style.
モバイルノードが共同配置されたアドレスのケアで動作している場合、モバイルIP仕様のセクション4.3および4.4に従って、放送およびマルチキャストのデータグラムが処理されます[1]。外国人エージェントのケアオブアドレスを使用したモバイルノードには、外国人エージェントが逆に転換し、マルチキャストデータグラムを備えている場合があります。ただし、そうするモバイルノードは、カプセル化する配信スタイルを使用する必要があります。
This delivers the datagram only to the foreign agent. The latter decapsulates it and then processes it as any other packet from the mobile node, namely, by reverse tunneling it to the home agent.
これにより、データグラムは外国のエージェントにのみ配信されます。後者はそれを脱カプセル化してから、モバイルノードからの他のパケット、つまりホームエージェントに逆トンネネル化することにより、それを処理します。
Packets destined to local resources (for example, a nearby printer) might be unaffected by ingress filtering. A mobile node with a co-located care-of address MAY optimize delivery of these packets by not reverse tunneling them. On the other hand, a mobile node using a foreign agent care-of address MAY use this selective reverse tunneling capability by requesting the Encapsulating Delivery Style, and following these guidelines:
ローカルリソース（近くのプリンターなど）が運命づけられているパケットは、イングレスフィルタリングの影響を受けない場合があります。共同配置された住所を備えたモバイルノードは、それらを逆トンネリングしないことにより、これらのパケットの配信を最適化する場合があります。一方、外国のエージェントのケアオブアドレスを使用したモバイルノードは、カプセル化の配信スタイルを要求し、次のガイドラインに従うことにより、この選択的な逆トンネリング機能を使用できます。
Packets NOT meant to be reversed tunneled:
逆転することを意図していないパケットトンネリング：
Sent using the Direct Delivery style. The foreign agent MUST process these packets as regular traffic: they MAY be forwarded but MUST NOT be reverse tunneled to the home agent.
直接配信スタイルを使用して送信されます。外国のエージェントは、これらのパケットを通常のトラフィックとして処理する必要があります。それらは転送される可能性がありますが、ホームエージェントに逆トンネルを繰り返してはなりません。
Packets meant to be reverse tunneled:
逆トンネリングを意味するパケット：
Sent using the Encapsulating Delivery style. The foreign agent MUST process these packets as specified in section 5.2: they MUST be reverse tunneled to the home agent.
カプセル化配信スタイルを使用して送信されます。外国人エージェントは、セクション5.2で指定されているようにこれらのパケットを処理する必要があります。それらは、ホームエージェントに逆トンネルをかけなければなりません。
The extensions outlined in this document are subject to the security considerations outlined in the Mobile IP specification [1]. Essentially, creation of both forward and reverse tunnels involves an authentication procedure, which reduces the risk for attack.
このドキュメントで概説されている拡張機能は、モバイルIP仕様[1]で概説されているセキュリティ上の考慮事項の対象となります。基本的に、前方トンネルと逆トンネルの両方を作成するには、認証手順が含まれ、攻撃のリスクが低下します。
Once the tunnel is set up, a malicious node could hijack it to inject packets into the network. Reverse tunnels might exacerbate this problem, because upon reaching the tunnel exit point packets are forwarded beyond the local network. This concern is also present in the Mobile IP specification, as it already dictates the use of reverse tunnels for certain applications.
トンネルがセットアップされると、悪意のあるノードがハイジャックしてネットワークにパケットを注入することができます。逆トンネルはこの問題を悪化させる可能性があります。これは、トンネル出口ポイントパケットに到達するとローカルネットワークを越えて転送されるためです。この懸念は、特定のアプリケーションに逆トンネルの使用を既に決定しているため、モバイルIP仕様にも存在します。
Unauthenticated exchanges involving the foreign agent allow a malicious node to pose as a valid mobile node and re-direct an existing reverse tunnel to another home agent, perhaps another malicious node. The best way to protect against these attacks is by employing the Mobile-Foreign and Foreign-Home Authentication Extensions defined in [1].
外国人エージェントを含む認定されていない交換により、悪意のあるノードが有効なモバイルノードとしてポーズをとり、既存の逆トンネルを別のホームエージェント、おそらく別の悪意のあるノードに再ダイレクトすることができます。これらの攻撃から保護する最良の方法は、[1]で定義されているモバイル外国および外国の在宅認証拡張機能を採用することです。
If the necessary mobility security associations are not available, this document introduces a mechanism to reduce the range and effectiveness of the attacks. The mobile node MUST set to 255 the TTL value in the IP headers of Registration Requests sent to the foreign agent. This prevents malicious nodes more than one hop away from posing as valid mobile nodes. Additional codes for use in registration denials make those attacks that do occur easier to track.
必要なモビリティセキュリティ協会が利用できない場合、このドキュメントでは、攻撃の範囲と有効性を低下させるメカニズムを紹介します。モバイルノードは、外国人エージェントに送信された登録要求のIPヘッダーで255に設定する必要があります。これにより、悪意のあるノードが有効なモバイルノードとしてポーズをとることから1枚以上離れています。登録拒否で使用する追加のコードにより、追跡が簡単に発生する攻撃が発生します。
With the goal of further reducing the attacks the Mobile IP Working Group considered other mechanisms involving the use of unauthenticated state. However, these introduce the possibilities of denial-of-service attacks. The consensus was that this was too much of a trade-off for mechanisms that guarantee no more than weak (non-cryptographic) protection against attacks.
攻撃をさらに減らすことを目的として、モバイルIPワーキンググループは、認識されていない状態の使用を含む他のメカニズムを考慮します。ただし、これらはサービス拒否攻撃の可能性を導入します。コンセンサスは、これは、攻撃に対する弱い（非暗号化）保護にすぎないメカニズムに対するトレードオフのようなものであるということでした。
There has been some concern regarding the long-term effectiveness of reverse-tunneling in the presence of ingress filtering. The conjecture is that network administrators will target reverse-tunneled packets (IP in IP encapsulated packets) for filtering. The ingress filtering recommendation spells out why this is not the case [8]:
イングレスフィルタリングの存在下での逆ツンネルの長期的な有効性に関して、ある程度の懸念がありました。推測は、ネットワーク管理者がフィルタリングのために逆タンネルパケット（IPカプセル化されたパケットのIP）をターゲットにするということです。イングレスフィルタリングの推奨事項は、なぜそうでないのかを説明しています[8]：
Tracking the source of an attack is simplified when the source is more likely to be "valid."
ソースが「有効」になる可能性が高い場合、攻撃のソースを追跡することは簡素化されます。
There are security implications involved with the foreign agent's using link-layer information to select the proper reverse tunnel for mobile node packets (section A.3). Unauthenticated link-layers allow a malicious mobile node to misuse another's existing reverse tunnel, and inject packets into the network.
リンク層情報を使用して、モバイルノードパケット用の適切な逆トンネルを選択する外国人エージェントに関連するセキュリティの意味があります（セクションA.3）。未認識のリンク層により、悪意のあるモバイルノードが他の既存の逆トンネルを誤用し、ネットワークにパケットを注入することができます。
For this solution to be viable, the link-layer MUST securely authenticate traffic received by the foreign agent from the mobile nodes. Unauthenticated link-layer technologies (for example shared ethernet) are not recommended to implement disparate address support.
このソリューションを実行可能にするために、リンク層は、モバイルノードから外国のエージェントが受け取ったトラフィックを安全に認証する必要があります。異なる住所サポートを実装するために、認識されていないリンク層技術（共有イーサネットなど）は推奨されません。
The Encapsulating Delivery Style extension defined in section 3.3 is a Mobile IP registration extension as defined in [1]. IANA assigned the value of 130 for this purpose at the time of the publication of RFC 2344.
セクション3.3で定義されているカプセル化配信スタイルの拡張機能は、[1]で定義されているモバイルIP登録拡張機能です。IANAは、RFC 2344の公開時にこの目的のために130の値を割り当てました。
The Code values defined in section 3.4 are error codes as defined in [1]. They correspond to error values associated with rejection by the home and foreign agents. At the time of the publication of RFC 2344, IANA assigned codes 74-76 for the foreign agent rejections and codes 137-139 for the home agent rejections. The code for 'delivery style not supported' has been assigned a value of 79 by the IANA for this purpose.
セクション3.4で定義されているコード値は、[1]で定義されているエラーコードです。それらは、家庭および外国人のエージェントによる拒絶に関連するエラー値に対応しています。RFC 2344の発行時に、IANAは、外国のエージェントの拒否にコード74-76を割り当て、ホームエージェントの拒絶にコード137-139を割り当てました。「サポートされていない」「配信スタイル」のコードには、この目的のためにIANAによって79の値が割り当てられています。
The encapsulating style of delivery was proposed by Charlie Perkins. Jim Solomon has been instrumental in shaping this document into its present form. Thanks to Samita Chakrabarti for helpful comments on disparate address space support, and for most of the text in section A.4.
配達のカプセル化スタイルは、チャーリーパーキンスによって提案されました。ジム・ソロモンは、この文書を現在の形に形作るのに役立ちました。異なる住所スペースサポートに関する有益なコメントと、セクションA.4のテキストのほとんどについて、Samita Chakrabartiに感謝します。
References
参考文献
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories.
[3] コンピューター緊急対応チーム（CERT）、「IPスプーフィング攻撃とハイジャックされたターミナル接続」、CA-95：01、1995年1月。Info.cert.orgin /pub /cert_advisoriesから匿名FTPを介して入手可能。
[4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[4] Perkins、C。およびD. Johnson、「モバイルIPのルート最適化」は、進行中の作業です。
[5] Manuel Rodriguez, private communication, August 1995.
[5] マヌエル・ロドリゲス、プライベートコミュニケーション、1995年8月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[6] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
[7] Kent、S。およびR. Atkinson、「IPカプセル化ペイロード」、RFC 2406、1998年11月。
[8] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[8] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、RFC 2267、1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[10] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[11] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[12] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G.J。E.リア、「プライベートインターネットのアドレス配分」、BCP 5、RFC 1918、1996年2月。
[13] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, August 2000.
[13] Dommety、G。、「キーおよびシーケンス番号GREへの拡張」、RFC 2890、2000年8月。
Editor and Chair Addresses
編集者と椅子のアドレス
Questions about this document may be directed at:
このドキュメントに関する質問は、次のように向けられます。
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサンマイクロシステムズラボラトリーズ、ヨーロッパ29、ケミンデュヴィューチェーン38240メイランフランス
Phone: +33 476 18 80 45
EMail: gab@sun.com
The working group can be contacted via the current chairs:
ワーキンググループは、現在の椅子から連絡できます。
Basavaraj Patil Nokia Networks 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia Networks 6000 Connection Drive Irving、TX 75039 USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Raj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
フィルロバーツモトローラ1501ウェストシュアードライブアーリントンハイツ、イリノイ60004 USA
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Appendix A: Disparate Address Space Support
付録A：異なるアドレススペースサポート
Mobile IP [1] assumes that all the entities involved (mobile node, foreign agent and home agent) have addresses within the same globally routable address space. In many deployment scenarios, when a mobile node leaves its home network it may wander into a region where its home address is not routable or known by the local routing fabric. Similarly, the IP addresses of the foreign agent and the home agent may belong to disparate address spaces, which precludes their exchanging registration protocol messages directly. These issues are possible particularly if the entities involved use addresses from the ranges specified in RFC1918 [12] to support private networks.
モバイルIP [1]は、関係するすべてのエンティティ（モバイルノード、外国人エージェント、ホームエージェント）が同じグローバルにルーティング可能なアドレススペース内に住所を持っていると想定しています。多くの展開シナリオでは、モバイルノードがホームネットワークを離れると、ホームアドレスがルーティング可能でないか、ローカルルーティングファブリックが知らない地域にさまよう可能性があります。同様に、外国人エージェントとホームエージェントのIPアドレスは、異なるアドレススペースに属している可能性があります。これらの問題は、関係するエンティティがRFC1918 [12]で指定された範囲のアドレスを使用してプライベートネットワークをサポートする場合に可能です。
Accurately speaking, the use of private addresses is not the only cause. It may, in fact, be the most common, but the root of the problem lies in the use of disparate address spaces. For example, corporations often have several properly allocated address ranges. They typically advertise reachability to only a subset of those ranges, leaving the others for use exclusively within the corporate network. Since these ranges are not routable in the general Internet, their use leads to the same problems encountered with "private" addresses, even though they are not taken from the ranges specified in RFC1918.
正確に言えば、プライベートアドレスの使用が唯一の原因ではありません。実際、それは最も一般的なものかもしれませんが、問題の根本は異なるアドレス空間の使用にあります。たとえば、企業は多くの場合、いくつかの適切に割り当てられた住所範囲を持っています。彼らは通常、それらの範囲のサブセットのみに到達可能性を宣伝し、他の範囲はコーポレートネットワーク内でのみ使用するようにします。これらの範囲は一般的なインターネットではルーティングできないため、RFC1918で指定された範囲から取得されていないにもかかわらず、それらの使用は「プライベート」アドレスで発生するのと同じ問題につながります。
Even if the mobile node, home agent and foreign agent all reside within the same address space, problems may arise if the correspondent node does not. However, this problem is not specific to Mobile IP, and is beyond the scope of this document. The next section limits even further the scope of the issues relevant to this document. A subsequent section explains how reverse tunneling may be used to tackle them.
モバイルノード、ホームエージェント、および外国人エージェントがすべて同じアドレススペースに存在している場合でも、特派員ノードがそうでない場合、問題が発生する可能性があります。ただし、この問題はモバイルIPに固有のものではなく、このドキュメントの範囲を超えています。次のセクションでは、このドキュメントに関連する問題の範囲をさらに制限します。次のセクションでは、それらに取り組むために逆トンネリングを使用する方法について説明します。
Reverse tunneling (as defined in this document) may be used to cope with disparate address spaces, within the following constraints:
逆トンネリング（このドキュメントで定義されている）は、次の制約内で、異なるアドレススペースに対処するために使用できます。
- There are no provisions to solve the case in which the correspondent node and the mobile node are in disparate address spaces. This limits the scope of the problem to only those issues specific to Mobile IP.
- 特派員ノードとモバイルノードが異なるアドレススペースにあるケースを解決するための規定はありません。これにより、問題の範囲がモバイルIPに固有の問題のみに制限されます。
- The foreign agent and the home agent are directly reachable to each other by virtue of residing in the same address space. This limits the scope of the problem to only the simplest of cases. This also implies that the registration protocol itself has a direct path between the foreign agent and the home agent, and, in this respect, is not affected by disparate address spaces. This restriction also applies to mobile nodes operating with a co-located care-of address. In this case, reverse tunneling is a complete and elegant solution.
- 外国人エージェントとホームエージェントは、同じ住所スペースに住むことにより、互いに直接到達可能です。これにより、問題の範囲が最も単純なケースのみに制限されます。これはまた、登録プロトコル自体が外国人エージェントとホームエージェントの間に直接的なパスを持っていることを意味し、この点で、異なる住所スペースの影響を受けません。この制限は、共同住みのケアオブアドレスを使用して動作するモバイルノードにも適用されます。この場合、逆トンネリングは完全でエレガントなソリューションです。
- There are no additional protocol elements beyond those defined by Mobile IP [1] and reverse tunneling. In particular, additional extensions to the registration requests or replies, or additional bits in the header--although potentially useful--are outside the scope of this document.
- モバイルIP [1]および逆トンネルで定義されたプロトコル要素を超えて追加のプロトコル要素はありません。特に、登録要求または返信への追加の拡張、またはヘッダー内の追加ビット（潜在的に有用ではありますが）は、このドキュメントの範囲外です。
In spite of the limitations, reverse tunneling may be used to solve the most common issues. The range of problems that can be solved are best understood by looking at some simple diagrams:
制限にもかかわらず、最も一般的な問題を解決するために逆トンネリングを使用することができます。解決できる問題の範囲は、いくつかの簡単な図を見ることで最もよく理解されています。
Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES
図A1：異種のアドレススペースにある不可能なパケット
Mc Fa Fb Hb Hc Yc
[MN]-----------------[FA]----------------[HA]---------------[Y]
Addr space A Addr space B Addr space C
In this diagram, there are three disparate address spaces: A, B and C. The home agent (HA) has one address each on address spaces B and C, and the foreign agent (FA), on address spaces A and B. The mobile node's (MN) has a permanent address, Mc, within address space C.
この図には、3つの異なるアドレススペースがあります。A、B、およびCには、ホームエージェント（HA）には、アドレススペースBとCにそれぞれ1つのアドレスがあり、外国人エージェント（FA）が住所スペースAおよびBに1つのアドレスがあります。モバイルノード（MN）には、アドレス空間C内の永久住所MCがあります。
In the most common scenario both A and C are "private" address spaces, and B is the public Internet.
最も一般的なシナリオでは、AとCの両方が「プライベート」アドレススペースであり、Bはパブリックインターネットです。
Suppose MN sends a packet to correspondent node (Y) in its home network. Presumably, MN has no difficulties delivering this packet to the FA, because it does so using layer 2 mechanisms. Somehow, the FA must realize that this packet must be reverse tunneled, and it must fetch the proper binding to do so. Possible mechanisms are outlined in section A.3.
MNがホームネットワークで特派員ノード（Y）にパケットを送信するとします。おそらく、MNはこのパケットをFAに配信するのに困難はありません。レイヤー2メカニズムを使用してそうするからです。どういうわけか、FAは、このパケットを逆トンネルにしなければならないことを認識しなければならず、そうするために適切なバインディングを取得する必要があります。可能なメカニズムは、セクションA.3で概説されています。
However, once the packet is in address space B it becomes non-routable. Note that ingress filtering only exacerbates the problem, because it adds a requirement of topological significance to the source IP address in addition to the that of the destination address. As Mobile IP matures, others entities may be defined (for example, AAA servers). Their addition places even more requirements on the address spaces in use.
ただし、パケットがアドレススペースBにあると、ルート不可能になります。イングレスフィルタリングは、宛先アドレスのアドレスに加えて、ソースIPアドレスにトポロジカルな重要性の要件を追加するため、問題を悪化させることに注意してください。モバイルIPが成熟すると、他のエンティティが定義される場合があります（たとえば、AAAサーバー）。それらの追加により、使用中のアドレススペースにさらに多くの要件があります。
Reverse tunneling adds a topologically significant IP header to the packet (source IP address of Fb, destination of Hb) during its transit within address space B. Assuming IP in IP encapsulation (although others, like GRE are also possible), this is what the packet looks like:
逆トンネリングは、アドレススペースB内でのトランジット中に、トポロジカルに有意なIPヘッダーをパケット（FBのソースIPアドレス、HBの宛先）に追加します。IPカプセル化のIPを仮定します（GREのように他のIPも可能ですが）、これはパケットは次のように見えます：
Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA
図A2：FAからHAへのIP逆トンネルパケットのIP
+-----------------+
| +-------+|
| Fb->Hb | Mc->Yc||
| +-------+|
+--------+--------+
HA receives this packet, recovers the original packet, and since it is cognizant of address space C, delivers it to the appropriate interface.
HAはこのパケットを受信し、元のパケットを回復し、アドレススペースCを認識しているため、適切なインターフェイスに配信します。
Of course, for this to happen, the care-of address registered by the MN is not the usual Fa, but Fb. How this happens is outside the scope of this document. Some possible mechanisms are:
もちろん、これが起こるためには、MNによって登録されているケアオブアドレスは通常のFAではなく、FBです。これがどのように起こるかは、このドキュメントの範囲外です。可能なメカニズムのいくつかは次のとおりです。
- FA recognizes mobile nodes whose addresses fall within the private address ranges specified by RFC1918. In this case, the foreign agent could force the use of Fb as the care-of address, perhaps by rejecting the initial registration request with an appropriate error message and supplemental information.
- FAは、アドレスがRFC1918で指定されたプライベートアドレス範囲内にあるモバイルノードを認識します。この場合、外国人エージェントは、おそらく適切なエラーメッセージと補足情報で最初の登録要求を拒否することにより、FBの使用を住所のケアとして強制することができます。
- FA could be configured to always advertise Fb as long as H->Fb and Fb->H are guaranteed to be valid forward and reverse tunnels, respectively, for all values of H. Here, H is the address of any home agent whose mobile nodes may register via FA.
- FAは、H-> FBとFB-> HがHのすべての値に対してそれぞれ有効な前方トンネルと逆トンネルであることが保証されている限り、常にFBを宣伝するように構成できます。ノードはFA経由で登録できます。
- FA could indicate that it supports disparate address spaces via a currently undefined 'P' bit in its advertisements, and an indication of the relevant address space for any or all of its care-of addressed by including an NAI [11] or a realm indicator (perhaps a variant of the NAI). Alternatively, mobile nodes so configured could solicit the NAI or realm indicator information in response to advertisements with the 'P' bit set.
- FAは、その広告に現在未定義の「P」ビットを介して異なるアドレススペースをサポートし、NAI [11]またはレルムインジケーターを含めることにより、そのケアの一部またはすべてのケアのための関連するアドレススペースの指標を示すことができます。（おそらくNAIのバリアント）。あるいは、そのように構成されたモバイルノードは、「P」ビットセットを使用して広告に応じてNAIまたはレルムインジケーター情報を求めることができます。
Additionally, the mobile node needs to supply the appropriate address for its home agent: Hb instead of the usual Hc. How this happens is outside the scope of this document. Some possible mechanisms are:
さらに、モバイルノードは、通常のHCの代わりに、ホームエージェント：HBに適切なアドレスを提供する必要があります。これがどのように起こるかは、このドキュメントの範囲外です。可能なメカニズムのいくつかは次のとおりです。
- This determination could be triggered in response to using the foreign agent's Fb as the care-of address.
- この決定は、外国のエージェントのFBを住所のケアとして使用することに応じてトリガーできます。
- The mobile node could always use Hb as its home agent address, specially (1) if Hb is routable within address space C, or (2) if MN is certain never to be at home (in some configurations, the mobile nodes are always roaming).
- モバイルノードは常にHBをホームエージェントアドレスとして使用できます。特に（1）HBがアドレススペースC内でルーティング可能な場合、または（2）MNが自宅にいないことを確実に使用できます（一部の構成では、モバイルノードは常にローミングしています）。
- The mobile node could be configured with different home agent addresses and their corresponding address space (perhaps indicated via an NAI [11] or a variant of it).
- モバイルノードは、異なるホームエージェントアドレスと対応するアドレススペース（おそらくNAI [11]またはそのバリアントを介して示されている）で構成できます。
Another major issue introduced by private addresses is that of two or more mobile nodes with the same numeric IP address:
プライベートアドレスによって導入されたもう1つの主要な問題は、同じ数値IPアドレスを持つ2つ以上のモバイルノードの問題です。
Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES
図A3：競合するアドレスを持つモバイルノード
Mc=M H1b H1c
[MN1]-------+ +----[HA1]----+---------
| | | Address
| | | space C
Address | | Address +----------
Space Fa-[FA]-Fb Space
A | | B +---------
| | | Address
| | | space D
[MN2]-------+ +----[HA2]----+---------
Md=M H2b H2d
Suppose there are two address spaces A and B, and a foreign agent (FA) with interfaces on both. There are two home agents (HA1 and HA2) in address space B, with addresses H1b and H2b, respectively. Each of the home agents has an interface in a private address space in addition to address space B: HA1 has H1c on C, and HA2 has H2d on D. MN1 and MN2 are two mobile nodes with home addresses Mc and Md, corresponding to address space C and D, respectively.
2つのアドレススペースAとBがあり、両方にインターフェイスがある外国人エージェント（FA）があるとします。アドレススペースBには、それぞれアドレスH1BとH2Bを備えた2つのホームエージェント（HA1とHA2）があります。各ホームエージェントには、アドレススペースに加えてプライベートアドレススペースにインターフェイスがあります。HA1はCにH1Cを持ち、HA2はD. MN1とMN2にH2Dがあります。それぞれスペースCとD。
If Mc and Md are private addresses as defined in RFC1918, they may be numerically equivalent (both equal to M). Because of this, the foreign agent can no longer rely on only the mobile node's home address to disambiguate amongst its different bindings.
MCとMDがRFC1918で定義されているプライベートアドレスである場合、それらは数値的に等価である可能性があります（両方ともmに等しい）。このため、外国人エージェントは、モバイルノードのホームアドレスのみに依存して、その異なるバインディングの中で微妙になりません。
In figure A1, suppose the correspondent node Y sends a packet to the mobile node at address Mc. The packet is intercepted by the home agent at Hc and tunneled towards the mobile node via address Fb.
図A1では、特派員ノードYがアドレスMCのモバイルノードにパケットを送信するとします。このパケットは、HCのホームエージェントによって傍受され、アドレスFBを介してモバイルノードに向かってトンネルが付けられます。
Once the packet reaches FA (via address Fb), the foreign agent must identify which of its registered mobile nodes is the ultimate destination for the internal packet. In order to do so, it needs to identify the proper binding via a tuple guaranteed to be unique among all of its mobile nodes.
パケットがFAに到達すると（アドレスFB経由）、外国人エージェントは、登録されたモバイルノードのどれが内部パケットの究極の目的地であるかを特定する必要があります。そのためには、すべてのモバイルノードの中で一意であることが保証されているタプルを介して適切なバインディングを特定する必要があります。
The unique tuple sufficient for demultiplexing IP in IP packets [IPIP] (protocol 4) is:
IPパケット[IPIP]（Protocol 4）でIPを非難するのに十分なユニークなタプルは次のとおりです。
- destination IP address of the encapsulated (internal) header
- カプセル化（内部）ヘッダーの宛先IPアドレス
This is mobile node MN's home address (Mc in the above example). At first glance, it seems like this is unique among all mobile nodes, but as mentioned above, with private addresses another mobile may have an address Md numerically equivalent to Mc.
これは、モバイルノードMNのホームアドレスです（上記の例のMC）。一見すると、これはすべてのモバイルノードの中でユニークであるように思われますが、上記のように、プライベートアドレスでは、別のモバイルがMCと数値的に同等のアドレスを持つ場合があります。
- source IP address of the external header
- 外部ヘッダーのソースIPアドレス
This, the remote end of the tunnel, is Hb in the above example.
これは、トンネルのリモートエンドである上記の例ではHBです。
- destination IP address of the external header
- 外部ヘッダーの宛先IPアドレス
This, the local end of the tunnel, is Fb in the above example.
これは、トンネルの局所端であり、上記の例ではFBです。
The three values above are learned from a successful registration and are the mobile node's home address, the home agent's address and the care-of address. Thus, it is possible to identify the right binding. Once FA identifies the ultimate destination of the packet, Mc, it delivers the internal packet using link layer mechanisms.
上記の3つの値は、登録の成功から学習され、モバイルノードのホームアドレス、ホームエージェントの住所、およびケアオブアドレスです。したがって、正しい結合を識別することが可能です。FAがパケットの究極の目的地であるMCを識別すると、リンクレイヤーメカニズムを使用して内部パケットを提供します。
GRE packets [10] (protocol 47) are only handled if their Protocol Type field has a value of 0x800 (other values are outside the scope of this document), and are demultiplexed based on the same tuple as IP in IP packets. In GRE terminology, the tuple is:
GREパケット[10]（プロトコル47）は、プロトコル型フィールドの値が0x800の値（他の値がこのドキュメントの範囲外）である場合にのみ処理され、IPパケットのIPと同じタプルに基づいて非glexedされます。GRE用語では、タプルは次のとおりです。
- destination IP address of the payload (internal) packet
- ペイロード（内部）パケットの宛先IPアドレス
- source IP address of the delivery (external) packet
- 配信（外部）パケットのソースIPアドレス
- destination IP address of the delivery (external) packet
- 配達（外部）パケットの宛先IPアドレス
Notice that the Routing, Sequence Number, Strict Source Route and Key fields have been deprecated from GRE [10]. However, a separate document specifies their use [13].
ルーティング、シーケンス番号、厳密なソースルート、およびキーフィールドがGREから廃止されていることに注意してください[10]。ただし、個別の文書はその使用を指定しています[13]。
The above tuples work for IP-in-IP or GRE encapsulation, and assume that the inner packet is in the clear. Encapsulations which encrypt the inner packet header are outside the scope of this document.
上記のタプルは、IP-in-IPまたはGREのカプセル化で機能し、内側のパケットが明確であると仮定します。内側のパケットヘッダーを暗号化するカプセルは、このドキュメントの範囲外です。
In figure A3, suppose mobile node M1 sends a packet to a correspondent node in its home address space, C, and mobile node M2 sends a packet to a correspondent node in its home address space, D.
図A3では、モバイルノードM1がホームアドレススペースの特派員ノードにパケットを送信すると、CおよびモバイルノードM2がホームアドレススペースDの特派員ノードにパケットを送信するとします。
At FA, the source addresses for both packets will be seen as M, thus this is not sufficient information. The unique tuple required to identify the proper binding is:
FAでは、両方のパケットのソースアドレスがMと見なされるため、これは十分な情報ではありません。適切なバインディングを識別するために必要なユニークなタプルは次のとおりです。
- link-layer information related to the MN
- MNに関連するリンク層情報
This may be in the form of a MAC address, a PPP session (or incoming interface) or channel coding for a digital cellular service. Device ID's can also be used in this context.
これは、MACアドレス、PPPセッション（または着信インターフェイス）、またはデジタルセルラーサービスのチャネルコーディングの形式である場合があります。このコンテキストでは、デバイスIDも使用できます。
- source IP address of the IP header.
- IPヘッダーのソースIPアドレス。
As was pointed out, this by itself is not guaranteed to be unique.
指摘されたように、これ自体がユニークであることは保証されていません。
This information must be established and recorded at registration time. The above items are sufficient for the foreign agent to select the proper binding to use. This, in turn, produces the address of the home agent, and the reverse tunneling options negotiated during the registration process. The foreign agent can now proceed with reverse tunneling.
この情報は、登録時に確立および記録する必要があります。上記の項目は、外国人が使用する適切なバインディングを選択するのに十分です。これにより、ホームエージェントの住所が生成され、登録プロセス中に交渉された逆トンネリングオプションが生成されます。外国人エージェントは、逆トンネリングを進めることができます。
The Limited Private Address Scenario (LPAS) has received much attention from the cellular wireless industry, so it is useful to define it and to clarify what its requirements are.
限られたプライベートアドレスシナリオ（LPA）は、セルラーワイヤレス業界から多くの注目を集めているため、それを定義し、その要件を明確にすることが役立ちます。
LPAS is a subset of the disparate address space scenario discussed in this appendix. This section explains how LPAS could be deployed given the current state of the Mobile IP specifications.
LPASは、この付録で説明した異なるアドレス空間シナリオのサブセットです。このセクションでは、モバイルIP仕様の現在の状態を考慮して、LPAを展開する方法について説明します。
Figure A4: EXAMPLE PRIVATE ADDRESS SCENARIO
図A4：プライベートアドレスシナリオの例
10.10.1.2
+----+ IF1=COA1+-------+ HAA2 +-----+
| MN1|------------------------| FA |---------| HA2 |
+----+ +------------| | +-----+
| IF2=COA2+-------+
+---+ |
| |
+-----+ |
| MN2 | |
+-----+ |
10.10.1.2 |
| HAA1
+------+
| HA1 |
+------+
The above figure presents a very simple scenario in which private addresses are used. Here, "private addresses" are strictly those defined in RFC 1918 [12]. In this deployment scenario, the only entities that have private addresses are the mobile nodes. Foreign agent and home agent addresses are publicly routable on the general Internet. More specifically, the care-of addresses advertised by the foreign agents (COA1 and COA2 in Figure A4) and the home agent addresses used by mobile nodes in registration requests (HAA1 and HAA2 in Figure A4) are publicly routable on the general Internet. As a consequence, any Mobile IP tunnels can be established between any home agent home address and any foreign agent care-of address.
上記の図は、プライベートアドレスが使用される非常にシンプルなシナリオを示しています。ここでは、「プライベートアドレス」は厳密にRFC 1918で定義されているものです[12]。この展開シナリオでは、プライベートアドレスを持つ唯一のエンティティはモバイルノードです。外国のエージェントとホームエージェントアドレスは、一般的なインターネットで公開されます。より具体的には、外国人エージェント（図A4のCOA1およびCOA2）によって宣伝されているアドレスと、登録要求でモバイルノードで使用されるホームエージェントアドレス（図A4のHAA1とHAA2）は、一般的なインターネットで公開されます。結果として、モバイルIPトンネルは、ホームエージェントホームアドレスと外国人エージェントのケアオブアドレスの間に確立できます。
Also, note that two different mobile nodes (MN1 and MN2) with the same private address (10.10.1.2) are visiting the same foreign agent FA. This is supported as long as MN1 and MN2 are serviced by different home agents. Hence, from any given home agent's perspective, each mobile node has a unique IP address, even if it happens to be a private address as per RFC 1918.
また、同じプライベートアドレス（10.10.1.2）を持つ2つの異なるモバイルノード（MN1およびMN2）が同じ外国人エージェントFAにアクセスしていることに注意してください。これは、MN1とMN2が異なるホームエージェントによってサービスを提供している限りサポートされています。したがって、特定のホームエージェントの観点から見ると、各モバイルノードには、RFC 1918に従ってプライベートアドレスであっても、一意のIPアドレスがあります。
Operation in the presence of route optimization [4] is outside the scope of this document.
ルート最適化[4]の存在下での操作は、このドキュメントの範囲外です。
Requirements for the above private address scenario:
上記のプライベートアドレスシナリオの要件：
Mobile node requirements:
モバイルノードの要件：
Mobile nodes intending to use private addresses with Mobile IP MUST set the 'T' bit and employ reverse tunneling. Mobile node's private addresses within a given address space MUST be unique. Thus two mobile nodes belonging to a single home agent cannot have the same private addresses. Thus, when receiving or sending tunneled traffic for a mobile node, the tunnel endpoints are used to disambiguate amongst conflicting mobile node addresses.
モバイルIPでプライベートアドレスを使用することを目的としたモバイルノードは、「T」ビットを設定し、逆トンネリングを使用する必要があります。特定のアドレススペース内のモバイルノードのプライベートアドレスは一意でなければなりません。したがって、単一のホームエージェントに属する2つのモバイルノードは、同じプライベートアドレスを持つことはできません。したがって、モバイルノードのトンネルトラフィックを受信または送信する場合、トンネルエンドポイントを使用して、競合するモバイルノードアドレスの間で露出します。
If the mobile node happens to register with multiple home agents simultaneously through the same foreign agent, there must be some link-layer information that is distinct for each mobile node. If no such distinct link-layer information is available, the mobile nodes MUST use unique address.
モバイルノードがたまたま複数のホームエージェントと同時に同じ外国人エージェントを介して登録している場合、各モバイルノードで異なるリンク層情報がある必要があります。このような明確なリンク層情報が利用できない場合、モバイルノードは一意のアドレスを使用する必要があります。
Foreign agent requirements:
外国のエージェント要件：
All advertising interfaces of the foreign agent MUST have publicly routable care-of address. Thus, a mobile node with a private address visits the foreign agent only in its publicly routable network.
外国人エージェントのすべての広告インターフェイスには、公開されている住所のケアが必要です。したがって、プライベートアドレスを備えたモバイルノードは、公開されているネットワークでのみ外国人エージェントにアクセスします。
Foreign agents MUST support reverse tunneling in order to support private addressed mobile nodes. If a foreign agent receives a registration request from a mobile node with a private address, and the mobile node has not set the 'T' bit, the foreign agent SHOULD reject it.
外国人エージェントは、プライベートアドレス指定されたモバイルノードをサポートするために、逆トンネリングをサポートする必要があります。外国人エージェントがプライベートアドレスを持つモバイルノードから登録リクエストを受信し、モバイルノードが「T」ビットを設定していない場合、外国人エージェントはそれを拒否する必要があります。
When delivering packets to or receiving packets from mobile nodes, foreign agents MUST disambiguate among mobile node with conflicting private addresses by using link-layer information as mentioned previously (Appendix section A.2 and A.3). A foreign agent in absence of route optimization, should make sure that two mobile nodes visiting the same foreign agent corresponds with each other through their respective home agents.
モバイルノードにパケットを配信または受信する場合、外国人エージェントは、前述のようにリンク層情報を使用して、競合するプライベートアドレスを持つモバイルノード間で明確にしなければなりません（付録セクションA.2およびA.3）。ルート最適化がない場合の外国人エージェントは、同じ外国人エージェントにアクセスする2つのモバイルノードが、それぞれのホームエージェントを介して互いに対応することを確認する必要があります。
If a foreign agent supports reverse tunneling, then it MUST support the simple scenario of private address support described in this section.
外国人エージェントが逆トンネリングをサポートする場合、このセクションで説明するプライベートアドレスサポートの簡単なシナリオをサポートする必要があります。
Home agent requirements:
ホームエージェントの要件：
Any home agent address used by mobile nodes in registration request MUST be a publicly routable address. Home agents will not support overlapping private home addresses, thus each private home address of a mobile node registered with a home agent is unique. When the 'T' bit is set in the registration request from the mobile node, the home agent MUST recognize and accept registration request from mobile nodes with private addresses. Also, the home agent SHOULD be able to assign private addresses out of its address pool to mobile nodes for use as home addresses. This does not contravene home agent processing in section 3.8 of [1].
登録要求でモバイルノードで使用されるホームエージェントアドレスは、公開されているアドレスでなければなりません。ホームエージェントは、重複するプライベートホームアドレスをサポートしないため、ホームエージェントに登録されたモバイルノードの各プライベートホームアドレスはユニークです。モバイルノードからの登録要求で「t」ビットが設定されている場合、ホームエージェントはプライベートアドレスを持つモバイルノードからの登録要求を認識して受け入れる必要があります。また、ホームエージェントは、住所プールからプライベートアドレスをモバイルノードに割り当てて、ホームアドレスとして使用することができるはずです。これは、[1]のセクション3.8でホームエージェント処理に違反しません。
Appendix B: Changes from RFC2344
付録B：RFC2344からの変更
This section lists the changes with respect to the previous version of this document (RFC2344).
このセクションでは、このドキュメントの以前のバージョン（RFC2344）に関する変更をリストします。
- Added Appendix A on support for Disparate Addresses spaces and private addresses.
- 異なる住所スペースとプライベートアドレスのサポートに関する付録Aを追加しました。
- Added the corresponding section (6.3) under 'Security Considerations'.
- 「セキュリティ上の考慮事項」に対応するセクション（6.3）を追加しました。
- Made Encapsulating Delivery Support optional by demoting from a MUST to a should. This also required defining a new error code 79 (assigned by IANA).
- 必須からデモをすることにより、配信サポートをオプションにカプセル化しました。また、新しいエラーコード79（IANAによって割り当てられた）を定義する必要がありました。
- Mentioned the possibility of an admissible authentication extension which may be different from the Mobile-Home authentication extension.
- モバイルホーム認証拡張機能とは異なる場合がある許容可能な認証拡張機能の可能性について言及しました。
- An IANA considerations section was added.
- IANAの考慮事項セクションが追加されました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。