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
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.
著作権（C）インターネット協会（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:
[1]モバイルIP仕様のセクション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]（1）そのホーム・ネットワーク内のマルチキャストグループに参加し、そして（2）それらがそのホームネットワークから発するようにマルチキャストパケットを送信するトンネルがホームから離れて移動ノードを有効に逆。
- 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は、（例えば、そのホームネットワーク内の他のホストにパケットを送信するとき）は、彼らの目的地に到達する前に期限切れになるように低くてもよいです。逆方向トンネルは、一つの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
- 任意[7]ヘッダーをトンネルパケットに追加されている可能性がある[6]または暗号化、ファイアウォールは、任意の認証を処理するために必要なセキュリティアソシエーションを共有介在。
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カプセル化におけるIP [2]特に明記しない限り想定されます。
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.
ルート最適化は、[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仕様の主な目的の一つは、この動作モードを必要としないことです。
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 Agentは、リバーストンネリングサービスを提供しています。
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ヘッダー内のフィールドを生存時間は、これは、悪意のあるホストが偽の登録要求を（セクション6を参照）を送信するサービス拒否攻撃を制限255に設定しなければなりません。
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
１３０
Length
長さ
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」ビットが設定された登録要求に応答して、モバイルノードは、外部エージェントとホームエージェントからコード134（不完全に形成されたリクエスト）からコード70（不完全に形成された要求）を受信することができる（そして受け入れなければなりません）。しかし、逆のトンネリングをサポートし、外国とホームエージェントは、それぞれ、コード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
「T」ビットを設定することに加えて、モバイルノードは、対応する拡張を含めることにより、カプセル化配送スタイルを要求することができます。外国人のエージェントは、カプセル化を実装していない場合
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.
配信スタイルは、それがコード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つのエンティティは、モビリティセキュリティアソシエーションを共有している場合、登録プロトコルのデータグラムを交換する際、特に、彼らは適切な認証拡張（モバイル外国人、外国-Homeまたはモバイル・ホーム認証拡張）を使用する必要があります。許容認証拡張（例えばモバイル・ホーム認証拡張）は、常に、モバイルノードとそのホームエージェントとの間に登録メッセージを認証するために存在しなければなりません。
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).
255これにIPヘッダのTTLフィールドを設定しなければならないモバイルノードが逆方向トンネルハイジャック攻撃（第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。応答コードによっては、モバイルノードは、（1つが存在した場合）のカプセル化デリバリースタイル拡張を排除して、新規登録を発行し、「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]で指定されたパケットを処理し、それは前方にトンネル要請を収容することができるか否かを判定する。それができない場合は、適切なコードを返します。外国人のエージェントは、カプセル化の要求された形式をサポートすることができない場合は特に、それは配達のスタイルの要求された形式をサポートできない場合、それはコード79（サポートされていない配信スタイル）を返さなければならないコード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（遠くモバイルノード）の登録を拒絶しなければならないことを確かめなければなりません。フォーリンエージェントは、毎秒最大にこれら登録応答を送信する速度を制限する必要があります。
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」ビットが設定された登録要求を受信したホームエージェントは、[1]モバイルIP仕様で指定されたパケットを処理し、それが前方にトンネル要請を収容することができるか否かを判定する。それができない場合は、適切なコードを返します。ホームエージェントは、カプセル化の要求された形式をサポートすることができない場合は特に、それはコード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における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におけるIP [2]）が、登録時にネゴシエートされたようにカプセル化の他の方法を用いてもよいです。
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における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におけるIP [2]）が、登録時にネゴシエートされたようにカプセル化の他の方法を用いてもよいです。
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における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におけるIP [2]）が、登録時にネゴシエートされたようにカプセル化の他の方法を用いてもよいです。
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.
モバイルノードが同一位置気付アドレスで動作している場合、ブロードキャストおよびマルチキャストデータグラムは、[1]セクション4.3およびモバイルIP仕様の4.4に従って処理されます。フォーリンエージェント気付アドレスを使用して、モバイルノードが外国人のエージェントによって逆トンネリング彼らのブロードキャストおよびマルチキャストデータグラムを持っているかもしれません。しかし、そうする任意のモバイルノードは、カプセル化し配信スタイルを使用しなければなりません。
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.
必要なモビリティセキュリティアソシエーションが利用できない場合は、この文書では、攻撃の範囲と有効性を低減するための仕組みを導入しています。モバイルノードは、255に外国人のエージェントに送信された登録要求のIPヘッダのTTL値を設定しなければなりません。これは、より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は、外国人のエージェント拒否とホームエージェントの拒否のためのコード137-139のためのコード74-76を割り当て。 「配信スタイルはサポートされていません」のコードは、この目的のために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]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2]パーキンス、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、info.cert.orgから匿名ftpで利用可能な1995年1月/パブ/ cert_advisoriesインチ
[4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[4]パーキンス、C.およびD.ジョンソン、「モバイル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]ケント、S.とR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
[7]ケント、S.とR.アトキンソン、 "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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、RFC 2267、1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[10]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、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.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、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.モンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メランFRANCE
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：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パティルノキア・ネットワーク6000接続のドライブアーヴィング、TX 75039 USA
Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Raj.Patil@nokia.com
電話：+1 972-894-6709ファックス：+1 972-894-5349電子メール：Raj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
フィル・ロバーツモトローラ1501西シュアードライブアーリントンハイツ、IL 60004 USA
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
電話：+1 847-632-3148電子メール：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に固有のものであり、この文書の範囲を超えています。次のセクションでは、さらに、このドキュメントに関連する問題の範囲を制限します。以降のセクションでは、それらに取り組むために使用することができる方法をリバーストンネリングを説明します。
A.1. Scope of the Reverse Tunneling Solution
A.1。リバーストンネリングソリューションの範囲
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.
- [1]およびリバーストンネリングモバイルIPによって定義されたものを超えて追加のプロトコル要素は存在しません。具体的には、ヘッダ内の登録要求又は応答、または追加のビットに追加の拡張 - 潜在的に有用であるが - は、この文書の範囲外です。
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：異種のアドレス空間内の非ルーティング可能なPACKETS
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、及びフォーリンエージェント（FA）のアドレスを有し、アドレス上の空間AとBザモバイルノードの（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）にパケットを送信したとします。それはそうレイヤ2つのメカニズムを使用しないため、おそらく、MNは、FAにこのパケットを提供する何の困難を持っていません。どういうわけか、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:
リバーストンネリングが（他が、GREのようなことも可能である）IPカプセル化のIPを仮定すると、アドレス空間B内のその通過中のパケット（FB、Hbの先の送信元IPアドレス）にトポロジー的に有意なIPヘッダを付加し、これは何ですかパケットは、次のようになります。
Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA
図A2：FA TO HA FROM IP REVERSEトンネリングされたパケット内の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限りFbのを宣伝するように構成することができ、前方有効である。ここでHのすべての値のため、Hは任意のホームエージェントのアドレスであり、それぞれ、トンネルを逆にすることが保証されていますモバイルノードは、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ヘモグロビン：また、モバイルノードは、そのホームエージェントのための適切なアドレスを供給する必要があります。どのようにこの問題が発生することは、この文書の範囲外です。いくつかの可能なメカニズムは、次のとおりです。
- 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).
- 移動ノードは常に、特別（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:
プライベートアドレスによって導入もう一つの主要な問題は、同じ数字のIPアドレスを持つ2つの以上の移動ノードのものです：
Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES
図A3：競合しているアドレスWITHモバイルノード
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）が存在すると仮定する。それぞれのアドレスH1bをし、H2B、とのアドレス空間Bにおける2つのホームエージェント（HA1とHA2）が、あります。 HA1はCでH1Cを有し、HA2はホームアドレスMCとメリーランドと2つのモバイルノードが、アドレスに対応しているD. MN1及びMN2にH2Dを有する：ホームエージェントの各々は、空間Bに対処するために加えてプライベートアドレス空間内のインターフェースを有していますそれぞれ空間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.
RFC1918で定義されているMCとMdはプライベートアドレスである場合、それらは（Mに等しい両方）数値的に同等であってもよいです。このため、外国人のエージェントは、もはやその異なるバインディングの中で明確にするだけで、モバイルノードのホームアドレスに頼ることはできません。
A.2. Terminating Forward Tunnels at the Foreign Agent
A.2。外部エージェントに転送するトンネルの終端
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パケットにIPを逆多重化するのに十分な固有のタプル[IPIP（プロトコル4）です。
- 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にMD数値的に同等のアドレスを有することができるように一見、それはそうです。
- 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と同じタプルに基づいて分離されます。 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・イン・IPまたはGREカプセル化のために働く、と内側のパケットが明らかになっていることを前提としています。内部パケットのヘッダを暗号化するカプセル化は、この文書の範囲外です。
A.3. Initiating Reverse Tunnels at the Foreign Agent
A.3。外部エージェントで逆方向トンネルを開始
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.
この情報は、登録時に設定して記録されなければなりません。上記の項目は、外国人のエージェントが使用する適切な結合を選択するために十分なものです。これは、順番に、ホームエージェントのアドレス、および登録プロセス中にネゴシエートリバーストンネリングオプションを生成します。外国人のエージェントは現在、リバーストンネリングを進めることができます。
A.4. Limited Private Address Scenario
A.4。限定プライベートアドレスシナリオ
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.
限定プライベートアドレスシナリオ（LPAS）は、セルラーワイヤレス業界から注目されているので、それを定義し、その要件が何であるかを明確にするために有用です。
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は、この付録で説明する異種のアドレス空間のシナリオのサブセットです。このセクションでは、LPASは、モバイルIP仕様の現在の状態を考慮に展開することができる方法を説明します。
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).
- なくてはいけないMUSTから降格することにより、オプションの配信サポートをカプセル化するメイド。また、これは（IANAによって割り当てられた）新しいエラーコード79を定義する必要がありました。
- 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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。