[要約] RFC 2344は、モバイルIPの逆トンネリングに関する技術仕様です。このRFCの目的は、モバイルデバイスがホームネットワークに接続されているように見えるようにするために、逆トンネリングを使用する方法を提案することです。
Network Working Group G. Montenegro, Editor
Request for Comments: 2344 Sun Microsystems, Inc.
Category: Standards Track May 1998
Reverse Tunneling for Mobile IP
モバイル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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
Mobile 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 in order 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に対する下位互換性のある拡張を提案します。このドキュメントは、ホームエージェントとモバイルノードの気付アドレスの間にあるファイアウォールによって引き起こされる問題を解決しようとするものではありません。
Table of Contents
目次
1. Introduction ................................................ 2
1.1. Terminology ............................................... 3
1.2. Assumptions ............................................... 4
1.3. Justification ............................................. 4
2. Overview .................................................... 4
3. New Packet Formats .......................................... 5
3.1. Mobility Agent Advertisement Extension .................... 5
3.2. Registration Request ...................................... 5
3.3. Encapsulating Delivery Style Extension .................... 6
3.4. New Registration Reply Codes .............................. 7
4. Changes in Protocol Behavior ................................ 8
4.1. Mobile Node Considerations ................................ 8
4.1.1. Sending Registration Requests to the Foreign Agent ...... 8
4.1.2. Receiving Registration Replies from the Foreign Agent ... 9
4.2. Foreign Agent Considerations .............................. 9
4.2.1. Receiving Registration Requests from the Mobile Node ... 10
4.2.2. Relaying Registration Requests to the Home Agent ....... 10
4.3. Home Agent Considerations ................................ 10
4.3.1. Receiving Registration Requests from the Foreign Agent . 11
4.3.2. Sending Registration Replies to the Foreign Agent ...... 11
5. Mobile Node to Foreign Agent Delivery Styles ............... 12
5.1. Direct Delivery Style .................................... 12
5.1.1. Packet Processing ...................................... 12
5.1.2. Packet Header Format and Fields ........................ 12
5.2. Encapsulating Delivery Style ............................. 13
5.2.1 Packet Processing ....................................... 13
5.2.2. Packet Header Format and Fields ........................ 14
5.3. Support for Broadcast and Multicast Datagrams ............ 15
5.4. Selective Reverse Tunneling .............................. 15
6. Security Considerations .................................... 16
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ... 16
6.2. Ingress Filtering ........................................ 17
7. Acknowledgements ........................................... 17
References .................................................... 17
Editor and Chair Addresses .................................... 18
Full Copyright Statement ...................................... 19
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は（たとえば、ホームネットワーク内の他のホストにパケットを送信する場合）、非常に低いため、宛先に到達する前に期限切れになる可能性があります。リバーストンネルは、TTLデクリメントが1であるため、問題を解決します[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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「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.
- 介在するファイアウォールは、トンネルパケットに追加された可能性のある認証[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 in 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仕様の主な目的の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:
Mobility Agent Advertisement Extension [1]に対する唯一の変更は、追加の「T」ビットです。
T Agent offers reverse tunneling service.
Tエージェントは、リバーストンネリングサービスを提供します。
A foreign agent that sets the 'T' bit MUST support the two delivery styles currently supported: Direct and Encapsulating Delivery Style (section 5).
「T」ビットを設定する外部エージェントは、現在サポートされている2つの配信スタイル（直接配信とカプセル化配信スタイル（セクション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」ビットの1つを使用して、登録要求に直接追加されます。リバーストンネルをサポートしない外部エージェントまたはホームエージェントが「T」ビットが設定された要求を受信すると、登録要求は失敗します。これにより、登録が拒否されます（障害コードはセクション3.4で指定されています）。
Most home agents would 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. Nevertheless, home agents probably already support the required decapsulation and further forwarding.
ほとんどのホームエージェントは、「モバイルノードから送信された自分宛てのパケットのカプセル化を解除してさらに配信できる必要があるため[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ヘッダーのTime to Liveフィールドを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:
Registration Requestパケットに対する唯一の変更は、追加の「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 in IPが想定されます）。配信スタイルの詳細については、セクション5を参照してください。
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
74要求されたリバーストンネルを使用できません75リバーストンネルは必須であり、「T」ビットが設定されていません76モバイルノードが離れすぎています
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を使用する必要があります。
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.
Registration Requestに「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. The Mobile-Home Authentication Extension MUST always be present.
特に指定のない限り、モバイルIP [1]で指定された動作が想定されます。特に、2つのエンティティがモビリティセキュリティアソシエーションを共有している場合、登録プロトコルデータグラムを交換するときに、適切な認証拡張機能（Mobile-Foreign、Foreign-HomeまたはMobile-Home Authentication Extension）を使用する必要があります。モバイルホーム認証拡張機能は常に存在している必要があります。
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), 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」ビットのゼロ化、カプセル化配信スタイル拡張（存在する場合）の削除、および新しい登録の発行を試行できます（MAY）。これを行った後、登録は成功する可能性がありますが、リバーストンネルがないため、データ転送ができない場合があります。
- The home agent returns a Registration Reply indicating that the service will be provided.
- ホームエージェントは、サービスが提供されることを示すRegistration Replyを返します。
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.
この最後のケースでは、モバイルノードは気付アドレスとホームエージェントの間に逆方向トンネルを確立することに成功しました。モバイルノードが同じ場所に配置された気付アドレスで動作している場合、外部ヘッダーの宛先アドレスがホームエージェントになるように発信データをカプセル化できます（MAY）。パケットを選択的に逆トンネルするこの機能については、セクション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 in IP以外）が要求された場合にサポートすることが保証されます。したがって、モバイルノードはその裁量でそれらを使用してもよい（MAY）。
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 accomodate 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.
「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秒あたり最大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の要求を拒否するRegistration Replyを返さなければなりません（要求されたリバーストンネルは使用不可）。
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).
有効性チェックを満たすRegistration Replyを受信すると、外部エージェントは、このモバイルノードにリバーストンネルが許可されていることの表示と予期される配信スタイルを含めて、ビジターリストを更新する必要があります（セクション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 accomodate 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」ビットが設定されたRegistration Requestを受信したホームエージェントは、モバイルIP仕様[1]で指定されているようにパケットを処理し、フォワードトンネル要求に対応できるかどうかを判断します。できない場合は、適切なコードを返します。特に、ホームエージェントが要求された形式のカプセル化をサポートできない場合、コード139（要求されたカプセル化は利用不可）を返さなければなりません（MUST）。
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.
有効性チェックを満たすRegistration Replyを受信すると、ホームエージェントはモビリティバインディングリストを更新して、このモバイルノードにリバーストンネルと予期されるカプセル化のタイプが許可されていることを示す必要があります。
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）。したがって、ホームエージェントは実装する必要があり、デフォルトでは、自分宛てのカプセル化されたパケットに対して次のチェックを有効にする必要があります（SHOULD）。
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.
そのようなバインディングが見つからない場合、またはパケットが登録時にネゴシエートされなかったカプセル化メカニズムを使用する場合、ホームエージェントはパケットをサイレントに破棄し、セキュリティ例外としてイベントを記録する必要があります（SHOULD）。
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.
Registration Request内のCare-of Addressフィールドからコピーされます。
IP Destination Address
IP宛先アドレス
Copied from the Home Agent field within the Registration Request.
Registration Request内のHome Agentフィールドからコピーされます。
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 in IP [2]）ですが、登録時にネゴシエートされた他のカプセル化方法を使用できます（MAY）。
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 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 in IP [2]）ですが、登録時にネゴシエートされた他のカプセル化方法を使用できます（MAY）。
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.
Registration Request内のCare-of Addressフィールドからコピーされます。
IP Destination Address
IP宛先アドレス
Copied from the Home Agent field within the Registration Request.
Registration Request内のHome Agentフィールドからコピーされます。
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 in IP [2]）ですが、登録時にネゴシエートされた他のカプセル化方法を使用できます（MAY）。
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]。外部エージェントの気付アドレスを使用するモバイルノードは、ブロードキャストおよびマルチキャストデータグラムを外部エージェントによって逆トンネリングすることができます（MAY）。ただし、そうするすべてのモバイルノードは、カプセル化配信スタイルを使用する必要があります。
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.
直接配信スタイルを使用して送信されます。外部エージェントはこれらのパケットを通常のトラフィックとして処理しなければなりません（MUST）。それらは転送される場合がありますが、ホームエージェントにリバーストンネルされてはなりません（MUST）。
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で指定されているように、外部エージェントはこれらのパケットを処理しなければなりません（MUST）。これらはホームエージェントにリバーストンネルされる必要があります。
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]で定義されているMobile-ForeignおよびForeign-Home Authentication Extensionsを使用することです。
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ヘッダーのTTL値を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."
攻撃元が「有効」である可能性が高い場合、攻撃元の追跡は簡略化されます。
The encapsulating style of delivery was proposed by Charlie Perkins. Jim Solomon has been instrumental in shaping this document into its present form.
カプセル化形式の配信は、チャーリー・パーキンスによって提案されました。ジム・ソロモンは、この文書を現在の形に形作るのに尽力しています。
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] Computer Emergency Response Team（CERT）、「IP Spoofing Attacks and Hijacked Terminal Connections」、CA-95：01、1995年1月。info.cert.orgin / pub / cert_advisoriesから匿名ftpで入手できます。
[4] Johnson, D., and C. Perkins, "Route Optimization in Mobile IP", Work in Progress.
[4] ジョンソン、D。、およびC.パーキンス、「モバイルIPにおけるルート最適化」、作業中。
[5] Manuel Rodriguez, private communication, August 1995.
[5] マヌエルロドリゲス、プライベートコミュニケーション、1995年8月。
[6] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[6] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[7] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[7] Atkinson、R。、「IP Encapsulating Security Payload」、RFC 1827、1995年8月。
[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.セニー、「ネットワーク入力フィルタリング：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月。
Editor and Chair Addresses
編集者と議長の住所
Questions about this document may be directed at:
このドキュメントに関する質問は、次の宛先に送られます。
Gabriel E. Montenegro Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
ガブリエルE.モンテネグロSun Microsystems、Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View、California 94303
Voice: +1-415-786-6288
Fax: +1-415-786-6445
EMail: gabriel.montenegro@eng.sun.com
The working group can be contacted via the current chairs:
ワーキンググループは、現在の議長を通じて連絡を取ることができます。
Jim Solomon Motorola, Inc. 1301 E. Algonquin Rd. - Rm 2240 Schaumburg, IL 60196
ジムソロモンモトローラ社1301 E.アルゴンキンロード-Rm 2240 Schaumburg、IL 60196
Voice: +1-847-576-2753
Fax: +1-847-576-3240
EMail: solomon@comm.mot.com
Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK17-202 Mountain View, California 94303
Erik Nordmark Sun Microsystems、Inc. 901 San Antonio Road Mailstop UMPK17-202 Mountain View、California 94303
Voice: +1-415-786-5166
EMail: erik.nordmark@eng.sun.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。