RFC3024 日本語訳
3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Ed.. January 2001. (Format: TXT=63929 bytes) (Obsoletes RFC2344) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Montenegro, Editor Request for Comments: 3024 Sun Microsystems, Inc. Obsoletes: 2344 January 2001 Category: Standards Track
ワーキンググループG.モンテネグロ、コメントを求めるエディタ要求をネットワークでつないでください: 3024 サン・マイクロシステムズ・インクは以下を時代遅れにします。 2344 2001年1月のカテゴリ: 標準化過程
Reverse Tunneling for Mobile IP, revised
改訂されて、モバイルIPのためにTunnelingを逆にしてください。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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)モバイルノードのもの、注意、-、アドレス、めったにコネは反対の方向をそうします。 通常、モバイルノードは、外国ネットワークのルータを通してパケットを送って、ルーティングがソースアドレスから独立していると仮定します。 この仮定が本当でないときに、逆がトンネルを堀るのが正しい状態でaを位相的に設立するのが便利である、注意、-、ホームのエージェントへのアドレス。
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.
このドキュメントはRFC2344を時代遅れにします。
Montenegro Standards Track [Page 1] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[1ページ]RFC3024Reverse Tunneling
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
1. 序論… 3 1.1. 用語… 4 1.2. 仮定… 4 1.3. 正当化… 5 2. 概要… 5 3. 新しいパケット・フォーマット… 6 3.1. 移動性エージェント広告拡大… 6 3.2. 登録要求… 6 3.3. 配送をカプセル化して、拡大を流行に合わせてください… 7 3.4. 新規登録回答コード… 8 4. プロトコルの振舞いにおける変化… 9 4.1. モバイルノード問題… 9 4.1.1. 登録要求を外国人のエージェントに送ります… 9 4.1.2. 登録を受けるのは外国人のエージェントから返答します… 10 4.2. 外国エージェント問題… 10 4.2.1. モバイルノードから登録要求を受け取ります… 11 4.2.2. ホームのエージェントに登録要求をリレーします… 11 4.3. ホームエージェント問題… 11 4.3.1. 外国人のエージェントから登録要求を受け取ります… 12 4.3.2. 送付登録は外国人のエージェントに答えます… 12 5. 外国エージェント配送様式へのモバイルノード… 13 5.1. 配送様式を指示してください… 13 5.1.1. パケット処理… 13 5.1.2. パケットのヘッダーの形式とフィールズ… 13 5.2. 配送が様式であるとカプセル化します… 14 5.2 .1 パケット処理… 14 5.2.2. パケットのヘッダーの形式とフィールズ… 15 5.3. 放送とマルチキャストには、データグラムをサポートしてください… 16 5.4. 選択している逆のトンネリング… 16 6. セキュリティ問題… 17 6.1. 逆トンネルハイジャックとサービス不能攻撃… 17 6.2. イングレスフィルタリング… 18 6.3. 異種のアドレス空間のためにトンネリングを逆にしてください… 18 7. IANA問題… 18 8. 承認… 18の参照箇所… 19エディタと議長Addresses… 20 付録A: 異種のアドレス空間サポート… 21 A.1。 ソリューションにトンネルを堀る逆の範囲… 21 A.2。 フォワードを終えるのは外国人のエージェントでトンネルを堀ります… 24 A.3。 逆を起こすのは外国人のエージェントでトンネルを堀ります… 26 A.4。 株式会社プライベート・アドレスシナリオ… 26 付録B: RFC2344からの変化… 29 完全な著作権宣言文… 30
Montenegro Standards Track [Page 2] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[2ページ]RFC3024Reverse Tunneling
1. Introduction
1. 序論
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スプーフィング攻撃)、RFC2267[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].
- マルチキャスト: (2) トンネルが家で遠くのモバイルノードを(1)に可能にする逆はマルチキャストグループにホームネットワークで加わります、そして、ホームネットワーク[1]から発するようにマルチキャストパケットを伝えてください。
- The TTL of packets sent by the mobile node (for example, when
sending packets to other hosts in its home network) may be so
low that they might expire before reaching their destination.
A reverse tunnel solves the problem as it represents a TTL
decrement of one [5].
- モバイルノード(例えばホームネットワークで他のホストにパケットを送るとき)によって送られたパケットのTTLは彼らが目的地に到着する前に期限が切れることができるくらい低いかもしれません。 1つ[5]のTTL減少を表すとき、逆のトンネルは問題を解決します。
Montenegro Standards Track [Page 3] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[3ページ]RFC3024Reverse Tunneling
1.1. Terminology
1.1. 用語
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.
モバイルノードに向かってパケットを往復させるトンネル。 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.
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[9]で説明されるように本書では解釈されることであるべきですか?
1.2. Assumptions
1.2. 仮定
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:
このドキュメントは、ファイアウォール縦断問題を解決するのを試みません。 むしろ、以下の1つが本当であると仮定します:
- There are no intervening firewalls along the path of the
tunneled packets.
- トンネルを堀られたパケットの経路に沿って介入しているファイアウォールが全くありません。
- Any intervening firewalls share the security association
necessary to process any authentication [6] or encryption [7]
headers which may have been added to the tunneled packets.
- どんな介入しているファイアウォールもどんな認証[6]も処理するのに必要なセキュリティ協会かトンネルを堀られたパケットに加えられるかもしれない暗号化[7]ヘッダーを共有します。
The reverse tunnels considered here are symmetric, that is, they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel. IP in IP encapsulation [2] is assumed unless stated otherwise.
ここで考えられた逆のトンネルが左右対称である、すなわち、それらは前進のトンネルと同じ構成(カプセル化メソッド、IPアドレス終点)を使用します。 別の方法で述べられない場合、IPカプセル化[2]におけるIPは想定されます。
Route optimization [4] introduces forward tunnels initiated at a correspondent host. Since a mobile node may not know if the correspondent host can decapsulate packets, reverse tunnels in that context are not discussed here.
経路最適化[4]は通信員のホストで開始された前進のトンネルを導入します。 モバイルノードが、通信員のホストがそうすることができるかどうかを知らないかもしれないので、ここでdecapsulateパケット、その文脈の逆のトンネルについて議論しません。
Montenegro Standards Track [Page 4] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[4ページ]RFC3024Reverse Tunneling
1.3. Justification
1.3. 正当化
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.
モバイルノード自体になぜホームのエージェントに開始させませんか?トンネルを 共同見つけられて、aで既に正しい状態で位相的に作動しているなら本当に、これがそれがするべきであることである、注意、-、アドレス。
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.
本書では概説されたメカニズムは使用のために前進のトンネル支保工のために外国人のエージェントに頼るモバイルノードで主として意図します。 ルータをフィルターにかけるのであることの面前でさえこれらがモバイルノードであるとサポートし続けているのは望ましいです。
2. Overview
2. 概要
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).
モバイルノードは、外国ネットワークに到着して、エージェント広告の聞こうとして、逆のトンネルを支える外国人のエージェントを選びます。 選択された外国人のエージェントを通して登録するとき、それはこのサービスを要求します。 このとき、そして、モバイルノードが外国人のエージェントにパケットを提供したがっていて、また、それがどうDirectかEncapsulating Delivery様式のどちらかを要求するかに(セクション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.
Direct Delivery様式では、モバイルノードは、デフォルトルータとして外国人のエージェントを任命して、直接外国人のエージェントにパケットを送りかけます、すなわち、カプセル化なしで。 外国人のエージェントは、ホームのエージェントにそれらを妨害して、それらにトンネルを堀ります。
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.
Encapsulating Delivery様式では、モバイルノードはすべての出発しているパケットを外国人のエージェントにカプセルに入れります。 外国人のエージェントは、ホームのエージェントにそれらをdecapsulatesして、再トンネルを堀ります、外国人のエージェントのものを使用して注意、-、この新しいトンネルのエントリー・ポイントとしてのアドレス。
Montenegro Standards Track [Page 5] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[5ページ]RFC3024Reverse Tunneling
3. New Packet Formats
3. 新しいパケット・フォーマット
3.1. Mobility Agent Advertisement Extension
3.1. 移動性エージェント広告拡大
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 |
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯|R|B|H|F|M|G|V|T| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上、Care、-、Addresses| | ... |
The only change to the Mobility Agent Advertisement Extension [1] is the additional 'T' bit:
MobilityエージェントAdvertisement Extension[1]への唯一の変化が追加'T'ビットです:
T Agent offers reverse tunneling service.
Tエージェント申し出はトンネリングサービスを逆にします。
A foreign agent that sets the 'T' bit MUST support the Direct Delivery Style. Encapsulating Delivery Style SHOULD be supported as well (section 5).
'T'ビットを設定する外国人のエージェントは、Direct Deliveryが様式であるとサポートしなければなりません。 また(セクション5)、Delivery様式SHOULDをカプセル化して、サポートされてください。
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]に従って単にそれを無視するのに注意してください。
3.2. Registration Request
3.2. 登録要求
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つを使用することによって、直接Registration Requestに加えられます。 'T'ビットがセットした状態で逆のトンネルを支えない外国かホームのエージェントが要求を受け取るなら、Registration Requestは失敗します。 これは登録否定をもたらします(失敗コードはセクション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.
SHOULD NOTが提供に反対させるホームのエージェントがトンネル支保工を逆にする、彼ら、「SHOULDはdecapsulateにできて、さらに自分たちに扱われたパケットを提供します、モバイルノードで送って」[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).
モバイルノードによって送られたRegistration Requestsでは、IPヘッダーのLive分野へのTimeは255に用意ができなければなりません。 これは悪意があるホストが偽のRegistration Requestsを送るサービス不能攻撃を制限します(セクション6を見てください)。
Montenegro Standards Track [Page 6] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[6ページ]RFC3024Reverse Tunneling
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 ...
+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|S|B|D|M|G|V|T|-| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームのエージェント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
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が設定している、モバイルノードが逆のトンネルを受け入れるホームのエージェントを尋ねる、注意、-、アドレス アドレスは逆トンネルに外国人のエージェントを招きます。外国人のエージェントを使用するモバイルノード、注意、-、そのパケット。
3.3. Encapsulating Delivery Style Extension
3.3. 配送様式が拡大であるとカプセル化します。
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.
Encapsulating Delivery様式Extensionはさらに逆のトンネリングの振舞いを指定するという登録要求にモバイルノードによって含まれるかもしれません。 それは単に外国人のエージェントによって使用されると予想されます。 それに従って、外国人のエージェントはこの拡大を消費しなければなりません(すなわち、それは、ホームのエージェントにそれをリレーしてはいけませんし、また回答でモバイルノードにそれを含めてはいけません)。 に従って、セクション3.6 .1 .3 [1]では、モバイルノードはモバイルホームAuthentication Extensionの後、およびモバイル外国のAuthentication Extensionの前にEncapsulating Delivery様式Extensionを含まなければなりません、存在しているなら。
The Encapsulating Delivery Style Extension MUST NOT be included if the 'T' bit is not set in the Registration Request.
'T'ビットがRegistration Requestに設定されないなら、Encapsulating Delivery様式Extensionを含んではいけません。
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.
この拡大が欠けるなら、Direct Deliveryは想定されます。 前進のトンネルと交渉されたことに従って、カプセル化をします(別の方法で指定されない場合、すなわち、IPにおけるIPは想定されます)。 配送スタイルに関するその他の詳細について、セクション5を参照してください。
Montenegro Standards Track [Page 7] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[7ページ]RFC3024Reverse Tunneling
Foreign agents SHOULD support the Encapsulating Delivery Style Extension.
SHOULDがEncapsulating Delivery様式Extensionをサポートする外国人のエージェント。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
130
130
Length
長さ
0
0
3.4. New Registration Reply Codes
3.4. 新規登録回答コード
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'ビットは遠方であり過ぎる79配送スタイルがサポートしなかった76のモバイルノードを設定しませんでした。
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の逆のトンネルが義務的であるよう要求しました、そして、セット139ではなく、'T'ビットが入手できないカプセル化を要求しました。
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'ビットがセットしたことでのRegistration Requestに対応して、モバイルノードは外国人のエージェントとコード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'ビットを設定することに加えて、モバイルノードも、対応する拡大を含んでいることによって、Encapsulating Delivery様式を要求するかもしれません。 外国人のエージェントがEncapsulatingを実装しないなら
Montenegro Standards Track [Page 8] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[8ページ]RFC3024Reverse Tunneling
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.
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を定義するのに注意してください。
4. Changes in Protocol Behavior
4. プロトコルの振舞いにおける変化
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つの実体が移動性セキュリティ協会を共有するなら、特に、それらは適切なAuthentication Extension(モバイルに外国のForeign-ホームかモバイルホームAuthentication Extension)を使用しなければなりません。容認できる認証拡大(例えば、モバイルホーム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]に関するプロトコルの振舞いの違いはその後のセクションで指定されます。
4.1. Mobile Node Considerations
4.1. モバイルノード問題
This section describes how the mobile node handles registrations that request a reverse tunnel.
このセクションはモバイルノードがどう逆のトンネルを要求する登録証明書を扱うかを説明します。
4.1.1. Sending Registration Requests to the Foreign Agent
4.1.1. 登録要求を外国人のエージェントに送ります。
In addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel.
[1]の問題に加えて、モバイルノードはRegistration Requestに'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.
モバイルノードは任意にEncapsulating Delivery様式Extensionを含むかもしれません。
Montenegro Standards Track [Page 9] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[9ページ]RFC3024Reverse Tunneling
4.1.2. Receiving Registration Replies from the Foreign Agent
4.1.2. 外国人のエージェントから登録回答を受け取ります。
Possible valid responses are:
可能な有効回答は以下の通りです。
- A registration denial issued by either the home agent or the
foreign agent:
- ホームのエージェントか外国人のエージェントのどちらかによって発行された登録否定:
a. The mobile node follows the error checking guidelines in
[1], and depending on the reply code, MAY try modifying the
registration request (for example, by eliminating the
request for alternate forms of encapsulation or delivery
style), and issuing a new registration.
a。 モバイルノードは[1]でガイドラインをチェックする誤りに続きます、そして、登録要求(例えば代替のフォームのカプセル化か配送スタイルを求める要求を排除することによって)を変更して、回答コードによって、新規登録を発行してみるかもしれません。
b. Depending on the reply code, the mobile node MAY try zeroing
the 'T' bit, eliminating the Encapsulating Delivery Style
Extension (if one was present), and issuing a new
registration. Notice that after doing so the registration
may succeed, but due to the lack of a reverse tunnel data
transfer may not be possible.
b。 回答コードによって、モバイルノードは'T'ビットのゼロに合っていてみるかもしれません、Encapsulating Delivery様式Extension(1つが存在していたなら)を排除して、新規登録を発行して。 そう登録した後のそれが成功するかもしれませんが、逆のトンネルデータ転送の不足のために可能でないかもしれないのに注意してください。
- 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.
この最後の場合では、モバイルノードが、逆のトンネルを確立するのに成功した、それ、注意、-、アドレス、そして、そのホームのエージェント。 aが共同見つけられている状態でモバイルノードが作動している、注意、-、アドレス、発信データをカプセル化するかもしれないので、外側のヘッダーの送付先アドレスはホームのエージェントです。 セクション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.
または、注意、-、アドレス、属、別々の外国人のエージェントに、モバイルノードが要求されたどんな配送スタイルも使わなければならない、(ダイレクトである、Encapsulating)、セクション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を除いた)のフォームを交替しても外国人のエージェントとホームのエージェントがサポートする両方が要求されたという保証です。 それに従って、モバイルノードは自己判断でそれらを使用するかもしれません。
4.2. Foreign Agent Considerations
4.2. 外国エージェント問題
This section describes how the foreign agent handles registrations that request a reverse tunnel.
このセクションは外国人のエージェントがどう逆のトンネルを要求する登録証明書を扱うかを説明します。
Montenegro Standards Track [Page 10] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[10ページ]RFC3024Reverse Tunneling
4.2.1. Receiving Registration Requests from the Mobile Node
4.2.1. モバイルノードから登録要求を受け取ります。
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'ビットがセットした状態でRegistration Requestを受け取る外国人のエージェントは、指定されるとしてのモバイルIP仕様[1]によるパケットを処理して、それが前進のトンネル要求に対応できるかどうかと決心しています。 そうすることができないなら、それは適切なコードを返します。 外国人のエージェントが要求されたフォームのカプセル化をサポートすることができないなら、特に、それは復帰コード72がそうしなければなりません。 要求されたフォームの配送スタイルをサポートすることができないなら、それは復帰コード79(スタイルがサポートしなかった配送)がそうしなければなりません。
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'ビットなしでRegistration Requestsを拒絶するかもしれません(逆のトンネルは義務的です、そして、'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を返さなければなりません。
4.2.2. Relaying Registration Requests to the Home Agent
4.2.2. ホームのエージェントに登録要求をリレーします。
Otherwise, the foreign agent MUST relay the Registration Request to the home agent.
さもなければ、外国人のエージェントはホームのエージェントにRegistration Requestをリレーしなければなりません。
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.
エントリーが事実上、配送スタイルに従って外国人のエージェントが入って来るトラフィックを処理しなければならないということであり、それをカプセル化して、それにトンネルを堀るこの訪問者リストをゆったり過ごしてください、注意、-、ホームのエージェントのアドレスへのアドレス。
4.3. Home Agent Considerations
4.3. ホームエージェント問題
This section describes how the home agent handles registrations that request a reverse tunnel.
このセクションはホームのエージェントがどう逆のトンネルを要求する登録証明書を扱うかを説明します。
Montenegro Standards Track [Page 11] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[11ページ]RFC3024Reverse Tunneling
4.3.1. Receiving Registration Requests from the Foreign Agent
4.3.1. 外国人のエージェントから登録要求を受け取ります。
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'ビットがセットした状態でRegistration Requestを受け取るホームのエージェントは、指定されるとしてのモバイルIP仕様[1]によるパケットを処理して、それが前進のトンネル要求に対応できるかどうかと決心しています。 そうすることができないなら、それは適切なコードを返します。 ホームのエージェントが要求されたフォームのカプセル化をサポートすることができないなら、特に、それは復帰コード139(入手できない要求されたカプセル化)がそうしなければなりません。
The home agent MAY reject registration requests without the 'T' bit set by denying them with code 138 (reverse tunnel is mandatory and ' T' bit not set).
ホームのエージェントは'T'ビットのない要求がコード138でそれらを否定することによって設定する登録を拒絶するかもしれません(逆のトンネルは義務的です、そして、'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を受け取り次第、ホームのエージェントは結合が逆のトンネルがこのモバイルノードに与えられたのを示すために記載して、カプセル化のタイプが予想した移動性をアップデートしなければなりません。
4.3.2. Sending Registration Replies to the Foreign Agent
4.3.2. 送付登録は外国人のエージェントに答えます。
In response to a valid Registration Request, a home agent MUST issue a Registration Reply to the mobile node.
有効なRegistration Requestに対応して、ホームのエージェントはモバイルノードにRegistration Replyを発行しなければなりません。
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:
うまくいっている登録の後に、ホームのエージェントはそれ自体に扱われたカプセル化されたパケットを受けるかもしれません。 そのようなパケットをDecapsulatingして、盲目的にネットワークにそれらを注ぐのは、潜在的セキュリティ弱点(セクション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.
ホームのエージェントがだれのものを縛るaの移動性を捜し求める、注意、-、アドレスは外側のヘッダーの源とだれのモバイルノードアドレスが内側のヘッダーの源であるかということです。
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(例えば、マルチキャストトンネル)に関係ないトンネルを終えるホームのエージェントは上のチェックをオフにするかもしれませんが、この習慣は前述の理由でがっかりしています。
Montenegro Standards Track [Page 12] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[12ページ]RFC3024Reverse Tunneling
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).
登録が有効である間、ホームのエージェントはそれをdecapsulatingすることによって、それぞれの有効な逆のトンネルを堀られたパケット(上記のようなチェックで決定するように)を処理しなければなりません、送付先アドレス(通信員のホスト)への送付者(モバイルノード)を代表してオリジナルのパケットを回復して、次に、それを進めて。
5. Mobile Node to Foreign Agent Delivery Styles
5. 外国エージェント配送様式へのモバイルノード
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.
このセクションはモバイルノードが外国人のエージェントを通してどうデータ通信量を送るかを指定します。 すべての場合では、モバイルノードはエージェント広告におけるリンクレイヤヘッダーから外国人のエージェントのリンクレイヤアドレスを学びます。
5.1. Direct Delivery Style
5.1. ダイレクト配送様式
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)を許容しません。
5.1.1. Packet Processing
5.1.1. パケット処理
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.
- 推進機能を変更して、推進の前にそれらをカプセル化してください。
5.1.2. Packet Header Format and Fields
5.1.2. パケットのヘッダー形式と分野
This section shows the format of the packet headers used by the Direct Delivery style. The formats shown assume IP in IP encapsulation [2].
このセクションはDirect Deliveryスタイルによって使用されるパケットのヘッダーの書式を示しています。 示された書式はIPカプセル化[2]でIPを仮定します。
Packet format received by the foreign agent (Direct Delivery Style):
外国人のエージェント(ダイレクトDelivery様式)によって受け取られたパケット・フォーマット:
IP fields:
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer Protocol
IP分野: ソースAddressはモバイルノードのホームアドレスDestination Address=通信員ホストのアドレスUpper Layerプロトコルと等しいです。
Packet format forwarded by the foreign agent (Direct Delivery Style):
外国人のエージェント(ダイレクトDelivery様式)によって進められたパケット・フォーマット:
Montenegro Standards Track [Page 13] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[13ページ]RFC3024Reverse Tunneling
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分野(ヘッダーをカプセルに入れります): ソースAddressが外国人のエージェントのものと等しい、注意、-、アドレスDestination Addressはホームのエージェントのアドレスプロトコル分野と等しいです: 4 (IPにおけるIP) IPは(オリジナルのヘッダー)をさばきます: ソースAddressはモバイルノードのホームアドレスDestination Address=通信員ホストのアドレスUpper Layerプロトコルと等しいです。
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.
模造する、Care、-、Registration Requestの中のAddress分野。
IP Destination Address
IP送付先アドレス
Copied from the Home Agent field within the most recent
successful Registration Reply.
最新のうまくいっているRegistration Replyの中のホームエージェント分野から、コピーされます。
IP Protocol Field
IPプロトコル分野
Default is 4 (IP in IP [2]), but other methods of encapsulation
MAY be used as negotiated at registration time.
デフォルトはそうです。4 (カプセル化のIP[2])の、しかし、他のメソッドによるIPは登録時に交渉されるように使用されるかもしれません。
5.2. Encapsulating Delivery Style
5.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.
このメカニズムは、モバイルノードがカプセル化を実装するのが必要であり、送付先アドレスとして新しい一番はずれのヘッダーでそれを指定することによって、外国人のエージェントに明らかにパケットを向けます。 発信したがっているモバイルノードが放送するか、またはマルチキャストパケットはEncapsulating Delivery様式を使用しなければなりません。
5.2.1 Packet Processing
5.2.1 パケット処理
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,
- 内側のパケットを回復するdecapsulates
- 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.
外国人のエージェントが明らかにEncapsulated Delivery様式を要求したモバイルノードから不-カプセル化されたパケットを受けるなら、規格を使用して、エージェントが逆にしてはいけない外国は、そのようなパケットにトンネルを堀って、むしろそれを進めなければなりません、IPルーティングメカニズム。
Montenegro Standards Track [Page 14] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[14ページ]RFC3024Reverse Tunneling
5.2.2. Packet Header Format and Fields
5.2.2. パケットのヘッダー形式と分野
This section shows the format of the packet headers used by the Encapsulating Delivery style. The formats shown assume IP in IP encapsulation [2].
このセクションはEncapsulating Deliveryスタイルによって使用されるパケットのヘッダーの書式を示しています。 示された書式はIPカプセル化[2]でIPを仮定します。
Packet format received by the foreign agent (Encapsulating Delivery Style):
外国人のエージェント(Deliveryが様式であるとカプセル化する)によって受け取られたパケット・フォーマット:
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分野(ヘッダーをカプセルに入れります): モバイルソースAddress=ノードのホームアドレスDestination Addressは外国人のエージェントのアドレスプロトコル分野と等しいです: 4 (IPにおけるIP) IPは(オリジナルのヘッダー)をさばきます: ソースAddressはモバイルノードのホームアドレスDestination Address=通信員ホストのアドレスUpper Layerプロトコルと等しいです。
The fields of the encapsulating IP header MUST be chosen as follows:
以下の通り要約のIPヘッダーの分野を選ばなければなりません:
IP Source Address
IPソースアドレス
The mobile node's home address.
モバイルノードのホームアドレス。
IP Destination Address
IP送付先アドレス
The address of the agent as learned from the IP source address
of the agent's most recent successful registration reply.
エージェントの最新のうまくいっている登録回答のIPソースアドレスから同じくらい学識があるエージェントのアドレス。
IP Protocol Field
IPプロトコル分野
Default is 4 (IP in IP [2]), but other methods of encapsulation
MAY be used as negotiated at registration time.
デフォルトはそうです。4 (カプセル化のIP[2])の、しかし、他のメソッドによるIPは登録時に交渉されるように使用されるかもしれません。
Packet format forwarded by the foreign agent (Encapsulating Delivery Style):
外国人のエージェント(Deliveryが様式であるとカプセル化する)によって進められたパケット・フォーマット:
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分野(ヘッダーをカプセルに入れります): ソースAddressが外国人のエージェントのものと等しい、注意、-、アドレスDestination Addressはホームのエージェントのアドレスプロトコル分野と等しいです: 4 (IPにおけるIP) IPは(オリジナルのヘッダー)をさばきます: ソースAddressはモバイルノードのホームアドレスDestination Address=通信員ホストのアドレスUpper Layerプロトコルと等しいです。
These fields of the encapsulating IP header MUST be chosen as follows:
以下の通り要約のIPヘッダーのこれらの分野を選ばなければなりません:
Montenegro Standards Track [Page 15] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[15ページ]RFC3024Reverse Tunneling
IP Source Address
IPソースアドレス
Copied from the Care-of Address field within the Registration
Request.
模造する、Care、-、Registration Requestの中のAddress分野。
IP Destination Address
IP送付先アドレス
Copied from the Home Agent field within the most recent
successful Registration Reply.
最新のうまくいっているRegistration Replyの中のホームエージェント分野から、コピーされます。
IP Protocol Field
IPプロトコル分野
Default is 4 (IP in IP [2]), but other methods of encapsulation
MAY be used as negotiated at registration time.
デフォルトはそうです。4 (カプセル化のIP[2])の、しかし、他のメソッドによるIPは登録時に交渉されるように使用されるかもしれません。
5.3. Support for Broadcast and Multicast Datagrams
5.3. 放送のサポートとマルチキャストデータグラム
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.
aが共同見つけられている状態でモバイルノードが作動している、注意、-、モバイルIP仕様[1]のセクション4.3と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.
これは外国人のエージェントだけにデータグラムを提供します。 すなわち、モバイルノードからのいかなる他のパケットもホームのエージェントにそれにトンネルを堀りながら逆になるとき、後者は、それをdecapsulatesして、次に、それを処理します。
5.4. Selective Reverse Tunneling
5.4. 選択している逆のトンネリング
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:
ローカル資源(例えば、近くのプリンタ)に運命づけられたパケットはイングレスフィルタリングで影響を受けないかもしれません。 aがあるモバイルノードが共同場所を見つけた、注意、-、アドレスはそれらにトンネルを堀らないどんな逆によるこれらのパケットの配送も最適化するかもしれません。 他方では、外国人のエージェントを使用するモバイルノード、注意、-、Encapsulating Delivery様式を要求して、これらのガイドラインに従うことで能力にトンネルを堀って、アドレスはこの選択している逆を使用するかもしれません:
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.
Direct Deliveryスタイルを使用させます。 外国人のエージェントは通常のトラフィックとしてこれらのパケットを処理しなければなりません: それらは、ホームのエージェントにトンネルを堀られた状態で進めるかもしれませんが、逆であるはずがありません。
Montenegro Standards Track [Page 16] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[16ページ]RFC3024Reverse Tunneling
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.
Encapsulating Deliveryスタイルを使用させます。 外国人のエージェントはセクション5.2の指定されるとしてのこれらのパケットを処理しなければなりません: それらはホームのエージェントにトンネルを堀られた状態で逆であるに違いありません。
6. Security Considerations
6. セキュリティ問題
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]に概説されたセキュリティ問題を受けることがあります。 本質的には、前進のものと同様に逆のトンネルの作成は認証手順にかかわります。(それは、攻撃のために危険を減少させます)。
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks
6.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].
外国人のエージェントにかかわるUnauthenticated交換で、悪意があるノードは、別のホームのエージェント、恐らく別の悪意があるノードに有効なモバイルノードのふりをして、既存の逆のトンネルを向け直します。 これらの攻撃から守る最も良い方法は[1]で定義されたモバイルに外国の、そして、Foreign家へ帰っている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.
必要な移動性セキュリティ協会が利用可能でないなら、このドキュメントは、攻撃の範囲と有効性を減少させるためにメカニズムを紹介します。 モバイルノードは外国人のエージェントに送られたRegistration RequestsのIPヘッダーにTTL値を255に設定しなければなりません。 これは、十二分に遠くのワンバウンドの悪意があるノードが有効なモバイルノードのふりをするのを防ぎます。 登録否定における使用のための追加コードは追跡するのが、より簡単な状態で起こるそれらの攻撃をします。
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作業部会は非認証された状態の使用にかかわる他のメカニズムを考えました。 しかしながら、これらはサービス不能攻撃の可能性を導入します。 コンセンサスはこれがあまりに攻撃に対する弱い(非暗号の)保護よりいいえを保証するメカニズムのためのトレードオフの多くであったということでした。
Montenegro Standards Track [Page 17] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[17ページ]RFC3024Reverse Tunneling
6.2. Ingress Filtering
6.2. イングレスフィルタリング
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."
ソースが「有効である」より傾向があるときに、攻撃の源を追跡するのは簡易型です。
6.3. Reverse Tunneling for Disparate Address Spaces
6.3. 異種のアドレス空間のためにトンネリングを逆にしてください。
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)のために適切な逆のトンネルを選択するのにリンクレイヤ情報を使用する外国人のエージェントのものにかかわるセキュリティ含意があります。 Unauthenticatedリンクレイヤで、悪意があるモバイルノードは、別のものの既存の逆のトンネルを誤用して、ネットワークにパケットを注ぎます。
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.
このソリューションが実行可能であるように、リンクレイヤはしっかりと外国人のエージェントによってモバイルノードから受け取られたトラフィックを認証しなければなりません。 Unauthenticatedリンクレイヤ技術(例えば、共有されたイーサネット)が、異種のアドレスがサポートであると実装することが勧められません。
7. IANA Considerations
7. IANA問題
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で定義されたEncapsulating Delivery様式拡張子は[1]で定義されるようにモバイルIP登録拡大です。 IANAはこのためにRFC2344の公表時点で、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で定義されたCode値は[1]で定義されるようにエラーコードです。 彼らはホームのそばで拒絶に関連している誤り値と外国人のエージェントに文通します。 RFC2344の公表時点で、IANAは外国エージェント拒絶のためのコード74-76とホームエージェント拒絶のためのコード137-139を割り当てました。 79の値はIANAによってこのために'スタイルがサポートしなかった配送'のためのコードに割り当てられました。
8. Acknowledgements
8. 承認
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をありがとうございます。
Montenegro Standards Track [Page 18] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[18ページ]RFC3024Reverse Tunneling
References
参照
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[2] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、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] コンピュータ緊急対応チーム、(本命) 「IPは攻撃とハイジャックされた端末のコネクションズを偽造する」カリフォルニア-95: 01 1995年1月。 info.cert.orgからのアノニマスFTPで、/pub/cert_状況報告で利用可能です。
[4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
Work in Progress.
[4] 「モバイルIPにおける経路最適化」というパーキンス、C.、およびD.ジョンソンは進行中で働いています。
[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認証ヘッダー」、RFC2402、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406,
November 1998.
[7] ケントとS.とR.アトキンソン、「有効搭載量をカプセル化するIP」、RFC2406、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を破ります」、RFC2267、1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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.と2000年のP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC2784行進。
[11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[11]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、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.、deグルート、G.J.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[13] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC
2890, August 2000.
[13]Dommety、G.、「GREへのキーと一連番号拡大」、RFC2890、2000年8月。
Montenegro Standards Track [Page 19] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[19ページ]RFC3024Reverse Tunneling
Editor and Chair Addresses
エディタと議長Addresses
Questions about this document may be directed at:
このドキュメントに関する質問は以下で指示されるかもしれません。
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン・フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
以下に電話をしてください。 +33 476 18 80 45はメールされます: 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接続Driveテキサス75039アービング(米国)
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
西シュアー・Driveフィル・ロバーツ・モトローラ1501IL60004アーリントンハイツ(米国)
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
以下に電話をしてください。 +1 847-632-3148 メールしてください: QA3445@email.mot.com
Montenegro Standards Track [Page 20] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[20ページ]RFC3024Reverse Tunneling
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
- 互いにおいて、同じアドレス空間で住んでいることによる外国人のエージェントとホームのエージェントは直接届いています。 これは問題の範囲を最も簡単なケースだけに制限します。 また、これがそれを含意する、登録
Montenegro Standards Track [Page 21] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[21ページ]RFC3024Reverse Tunneling
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.
プロトコル自体は、外国人のエージェントとホームのエージェントの間の直接路を持って、この点で異種のアドレス空間で影響を受けません。 また、この制限がaが共同見つけられている状態で作動するモバイルノードに適用される、注意、-、アドレス。 この場合、逆のトンネリングは完全で上品なソリューションです。
- There are no additional protocol elements beyond those
defined by Mobile IP [1] and reverse tunneling. In
particular, additional extensions to the registration
requests or replies, or additional bits in the
header--although potentially useful--are outside the scope
of this document.
- 追加議定書要素は全くモバイルIP[1]と逆のトンネリングによって定義されたものを超えていません。 登録要求か回答への特定の、そして、追加している拡大、または潜在的に役に立ちますが、ヘッダーの追加ビットに、このドキュメントの範囲が外にあります。
In spite of the limitations, reverse tunneling may be used to solve the most common issues. The range of problems that can be solved are best understood by looking at some simple diagrams:
制限にもかかわらず、逆のトンネリングは、最も一般的な問題を解決するのに使用されるかもしれません。 解決されているのが、最も良い簡単であるとしていくつかを見るのに解釈されたダイヤグラムであるということであるかもしれない問題の範囲:
Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES
A1は計算します: 異種のアドレス空間における非ROUTABLEパケット
Mc Fa Fb Hb Hc Yc
[MN]-----------------[FA]----------------[HA]---------------[Y]
Addr space A Addr space B Addr space C
mcファFb Hb Hc Yc[ミネソタ]-----------------[ファ]----------------[ハ]---------------[Y] AddrスペースA AddrスペースB Addrスペース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つの異種のアドレス空間があります: C. A、B、およびホームのエージェント(HA)はアドレス空間Bにそれぞれあるアドレスを持っています、そして、モバイルノードのアドレス空間AとB.(ミネソタ)のC、および外国人のエージェント(FA)には、本籍があります、Mc、アドレス空間Cの中で。
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.
ミネソタがホームネットワークで通信員ノード(Y)にパケットを送ると仮定してください。 おそらく、ミネソタは、そうするのでこのパケットをFAに提供するのに層の2メカニズムを使用することで全く苦労しません。どうにか、FAはこのパケットがトンネルを堀られた状態で逆であるに違いなく、そうするために適正束縛をとって来なければならないとわからなければなりません。 可能なメカニズムはセクションA.3で概説されています。
However, once the packet is in address space B it becomes non- routable. Note that ingress filtering only exacerbates the problem, because it adds a requirement of topological significance to the source IP address in addition to the that of the destination address. As Mobile IP matures, others entities may be defined (for example, AAA servers). Their addition places even more requirements on the address spaces in use.
しかしながら、アドレス空間Bにパケットがいったんあると、それは非発送可能になります。 に加えてイングレスフィルタリングだけが問題を悪化させることに注意してください、位相的な意味の要件をソースIPアドレスに追加するので送付先アドレスのもの。 他のもの実体はモバイルIPが熟すと定義されるかもしれません(例えば、AAAサーバ)。 それらの追加はさらに多くの要件を使用中のアドレス空間に置きます。
Montenegro Standards Track [Page 22] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[22ページ]RFC3024Reverse Tunneling
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:
逆のトンネリングが加える、位相的である、重要なIPヘッダー、IPカプセル化(他のものですが、また、同様のGREも可能である)におけるアドレス空間B.Assuming IPの中のトランジットの間のパケット(FbのIPアドレスの出典を明示してください、Hbの目的地)に、これはパケットが似ていることです:
Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA
A2は計算します: IP IN IP逆がファからのパケットにトンネルを堀った、ハ。
+-----------------+
| +-------+|
| Fb->Hb | Mc->Yc||
| +-------+|
+--------+--------+
+-----------------+ | +-------+| | 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:
もちろん、これが起こるように注意、-、ミネソタによって登録されたアドレスは普通の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とFb>HがHがH.Hereのすべての値のためにそれぞれ前方で有効であり、トンネルを逆にするためには、モバイルノードが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が、aを通した現在未定義の'P'が広告、およびいずれかすべてのための関連アドレス空間のしるしで噛み付いた異種のアドレス空間をサポートするのを示すことができた、それ、注意、-、NAIを含んでいることによって、[11]か分野インディケータが(恐らくNAIの異形)であると扱いました。 あるいはまた、そのように構成されたモバイルノードはNAIに請求できましたか、または'P'ビットによる広告に応えて分野インディケータ情報はセットしました。
Additionally, the mobile node needs to supply the appropriate address for its home agent: Hb instead of the usual Hc. How this happens is outside the scope of this document. Some possible mechanisms are:
さらに、モバイルノードは、適切なアドレスをホームのエージェントに提供する必要があります: 普通のHcの代わりにHb。 このドキュメントの範囲の外にこれがどう起こるかがあります。 いくつかの可能なメカニズムは以下の通りです。
- This determination could be triggered in response to using the
foreign agent's Fb as the care-of address.
- 外国人のエージェントのFbを使用することに対応してこの決断を引き起こすことができた、注意、-、アドレス。
Montenegro Standards Track [Page 23] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[23ページ]RFC3024Reverse Tunneling
- 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)としていつもHbを使用するかもしれません。
- 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は計算します: 闘争アドレスがあるモバイルノード
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
mcはM H1b H1c[MN1]と等しいです。-------+ +----[HA1]----+--------- | | | アドレス| | | スペースC Address| | アドレス+---------- スペースファ[ファ]-FbスペースA| | B+--------- | | | アドレス| | | スペースD[MN2]-------+ +----[HA2]----+--------- MdはM H2b H2dと等しいです。
Suppose there are two address spaces A and B, and a foreign agent (FA) with interfaces on both. There are two home agents (HA1 and HA2) in address space B, with addresses H1b and H2b, respectively. Each of the home agents has an interface in a private address space in addition to address space B: HA1 has H1c on C, and HA2 has H2d on D. MN1 and MN2 are two mobile nodes with home addresses Mc and Md, corresponding to address space C and D, respectively.
インタフェースが両方にある状態で2つのアドレス空間AとB、および外国人のエージェント(FA)がいると仮定してください。 そこに、それぞれアドレス空間Bには2人のホームのエージェント(HA1とHA2)がアドレスのH1bとH2bと共にいますか? ホームエージェントの各人はアドレス空間Bに加えたプライベート・アドレススペースにインタフェースを持っています: HA1はCにH1cを持っています、そして、HA2はD. MN1にH2dを持っています、そして、MN2はそれぞれアドレス空間CとDに対応するホームアドレスのMcとMdとの2つのモバイルノードです。
If Mc and Md are private addresses as defined in RFC1918, they may be numerically equivalent (both equal to M). Because of this, the foreign agent can no longer rely on only the mobile node's home address to disambiguate amongst its different bindings.
McとMdがRFC1918で定義されるようにプライベート・アドレスであるなら、それらは数の上で同等であるかもしれません(ともにMと等しい)。 これのために、外国人のエージェントはもう異なった結合の中であいまいさを除くモバイルノードのホームアドレスだけを当てにすることができません。
A.2. Terminating Forward Tunnels at the Foreign Agent
A.2。 外国人のエージェントで前進のTunnelsを終えます。
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を通してモバイルノードに向かってトンネルを堀られます。
Montenegro Standards Track [Page 24] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[24ページ]RFC3024Reverse Tunneling
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を通した)に達すると、外国人のエージェントは、内部のパケットのために登録されたモバイルノードのどれが最終仕向地であるかを特定しなければなりません。 そうして、それは、モバイルノードのすべて中で特有になるのに保証されたtupleを通して適正束縛を特定する必要があります。
The unique tuple sufficient for demultiplexing IP in IP packets [IPIP] (protocol 4) is:
IPパケット[IPIP](プロトコル4)で逆多重化IPに十分なユニークなtupleは以下の通りです。
- 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.
これはモバイルノードミネソタのホームアドレス(上記の例の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)は、それらのプロトコルType分野に0×800の値がある場合にだけ(このドキュメントの範囲の外に他の値があります)扱われて、IPと同じtupleに基づいてIPパケットで反多重送信されます。 GRE用語では、tupleは以下の通りです。
- 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].
ルート設定、Sequence Number、Strict Source Route、およびKey分野がGRE[10]から推奨しないのに注意してください。 しかしながら、別々のドキュメントは彼らの使用[13]を指定します。
Montenegro Standards Track [Page 25] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[25ページ]RFC3024Reverse Tunneling
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のための上のtuples仕事かGREカプセル化、内側のパケットが明確にあると仮定してください。 このドキュメントの範囲の外に内側のパケットのヘッダーを暗号化するカプセル化があります。
A.3. Initiating Reverse Tunnels at the Foreign Agent
A.3。 外国人のエージェントで逆のTunnelsを開始します。
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が見られるでしょう、その結果、これが十分な情報ではありません。 適正束縛を特定しなければならなかったユニークなtupleは以下の通りです。
- link-layer information related to the 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.
株式会社兵士のAddress Scenario(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はこの付録で議論した異種のアドレス空間シナリオの部分集合です。 このセクションはモバイルIP仕様の現状を考えて、どうLPASを配布することができたかを説明します。
Montenegro Standards Track [Page 26] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[26ページ]RFC3024Reverse Tunneling
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 |
+------+
10.10.1.2 +----+ IF1=COA1+-------+ HAA2+-----+ | MN1|------------------------| ファ|---------| 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.
また、同じプライベート・アドレスでその2の異なったモバイルノード(MN1とMN2)に注意してください、(10.10 .1 .2) 同じ外国人のエージェントFAを訪問しています。 MN1とMN2が異なったホームのエージェントによって調整される限り、これはサポートされます。 したがって、それぞれのモバイルノードには、どんな与えられたホームのエージェントの見解からも、固有のIPアドレスがあります、RFC1918に従ってプライベート・アドレスであることが起こっても。
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
使用に個人的な意図がモバイルIPと共に扱うモバイルノードは、'T'ビットを設定して、逆のトンネリングを使わなければなりません。 与えられたアドレス空間の中のモバイルノードのプライベート・アドレスはユニークであるに違いありません。 その結果、独身のホームのエージェントのものである2つのモバイルノード
Montenegro Standards Track [Page 27] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[27ページ]RFC3024Reverse Tunneling
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.
同じプライベート・アドレスを持つことができません。 受信か送付がモバイルノードのためにトラフィックにトンネルを堀ったとき、したがって、トンネル終点は、闘争する中でモバイルノードアドレスのあいまいさを除くのに使用されます。
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'ビットを設定していないなら、外国人のエージェントSHOULDはそれを拒絶します。
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
登録要求におけるモバイルノードによって使用されるどんなホームエージェントアドレスも公的に発送可能なアドレスであるに違いありません。 ホームのエージェントは、重なるのが個人的なホームアドレスであるとサポートしないでしょう、その結果、ホームのエージェントに登録されたモバイルノードのそれぞれの自家アドレスがユニークです。 'T'ビットがモバイルノードからの登録要求に設定されるとき、ホームのエージェントは、個人的でモバイルノードから登録要求を認めて、受け入れなければなりません。
Montenegro Standards Track [Page 28] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[28ページ]RFC3024Reverse Tunneling
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].
アドレス。 ホームのエージェントもSHOULD、ホームアドレスとしてプライベート・アドレスをアドレスプールから使用のためのモバイルノードに割り当てることができてください。 これは[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.
- Disparate Addresses空間とプライベート・アドレスのサポートのときにAppendix Aを加えました。
- Added the corresponding section (6.3) under 'Security
Considerations'.
- 'セキュリティ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).
- aから格下げすることによって任意の人工のEncapsulating Delivery Supportはaにそうしなければならないべきです。 また、これは、新しいエラーコード79(IANAによって割り当てられます)を定義するのを必要としました。
- Mentioned the possibility of an admissible authentication
extension which may be different from the Mobile-Home
authentication extension.
- モバイルホーム認証拡大と異なるかもしれない容認できる認証拡大の可能性について言及しました。
- An IANA considerations section was added.
- IANA問題部は加えられました。
Montenegro Standards Track [Page 29] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
2001年1月に改訂されたモバイルIPのためのモンテネグロStandards Track[29ページ]RFC3024Reverse Tunneling
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Montenegro Standards Track [Page 30]
モンテネグロ標準化過程[30ページ]
一覧
スポンサーリンク
