RFC2344 日本語訳
2344 Reverse Tunneling for Mobile IP. G. Montenegro, Ed.. May 1998. (Format: TXT=39468 bytes) (Obsoleted by RFC3024) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Montenegro, Editor Request for Comments: 2344 Sun Microsystems, Inc. Category: Standards Track May 1998
ワーキンググループG.モンテネグロ、コメントを求めるエディタ要求をネットワークでつないでください: 2344年のサン・マイクロシステムズ・インクカテゴリ: 標準化過程1998年5月
Reverse Tunneling for Mobile IP
モバイルIPのためにトンネリングを逆にしてください。
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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がホームのエージェントからのトンネリングを使用する、モバイルノードのもの、注意、-、アドレス、めったにコネは反対の方向をそうします。 通常、モバイルノードは、外国ネットワークのルータを通してパケットを送って、ルーティングがソースアドレスから独立していると仮定します。 この仮定が本当でないときに、逆がトンネルを堀るのが正しい状態でaを位相的に設立するのが便利である、注意、-、ホームのエージェントへのアドレス。
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
1. 序論… 2 1.1. 用語… 3 1.2. 仮定… 4 1.3. 正当化… 4 2. 概要… 4 3. 新しいパケット・フォーマット… 5 3.1. 移動性エージェント広告拡大… 5 3.2. 登録要求… 5 3.3. 配送をカプセル化して、拡大を流行に合わせてください… 6 3.4. 新規登録回答コード… 7 4. プロトコルの振舞いにおける変化… 8 4.1. モバイルノード問題… 8
Montenegro Standards Track [Page 1] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[1ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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
4.1.1. 登録要求を外国人のエージェントに送ります… 8 4.1.2. 登録を受けるのは外国人のエージェントから返答します… 9 4.2. 外国エージェント問題… 9 4.2.1. モバイルノードから登録要求を受け取ります… 10 4.2.2. ホームのエージェントに登録要求をリレーします… 10 4.3. ホームエージェント問題… 10 4.3.1. 外国人のエージェント. 11 4.3.2から登録要求を受け取ります。 送付登録は外国人のエージェントに答えます… 11 5. 外国エージェント配送様式へのモバイルノード… 12 5.1. 配送様式を指示してください… 12 5.1.1. パケット処理… 12 5.1.2. パケットのヘッダーの形式とフィールズ… 12 5.2. 配送が様式であるとカプセル化します… 13 5.2 .1 パケット処理… 13 5.2.2. パケットのヘッダーの形式とフィールズ… 14 5.3. 放送とマルチキャストには、データグラムをサポートしてください… 15 5.4. 選択している逆のトンネリング… 15 6. セキュリティ問題… 16 6.1. 逆トンネルハイジャックとサービス不能攻撃… 16 6.2. イングレスフィルタリング… 17 7. 承認… 17の参照箇所… 17エディタと議長Addresses… 18 完全な著作権宣言文… 19
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.
このドキュメントは正しい逆のトンネルについて位相的に議論します。
Montenegro Standards Track [Page 2] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[2ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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減少を表すとき、逆のトンネルは問題を解決します。
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]で説明されるように本書では解釈されることであるべきですか?
Montenegro Standards Track [Page 3] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[3ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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パケット、その文脈の逆のトンネルについて議論しません。
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
モバイルノードは、外国ネットワークに到着して、エージェント広告の聞こうとして、逆のトンネルを支える外国人のエージェントを選びます。 選択された外国人のエージェントを通して登録するとき、それはこのサービスを要求します。 このとき、依存、オンである、どのように
Montenegro Standards Track [Page 4] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[4ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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して、再トンネルを堀ります、外国人のエージェントのものを使用して注意、-、この新しいトンネルのエントリー・ポイントとしてのアドレス。
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 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]に従って単にそれを無視するのに注意してください。
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で指定されます)。
Montenegro Standards Track [Page 5] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[5ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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.
ほとんどのホームのエージェントが逆のトンネル支保工を提供するのに反対しないだろう、彼ら、「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を見てください)。
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
Encapsulating Delivery様式Extensionはさらに逆のトンネリングの振舞いを指定するという登録要求にモバイルノードによって含まれるかもしれません。 それは単に外国人のエージェントによって使用されると予想されます。 それに従って、外国人のエージェントがこの拡大を消費しなければならない、(すなわち、それは、ホームのエージェントにそれをリレーしてはいけませんし、また中でそれを含めてはいけません。
Montenegro Standards Track [Page 6] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[6ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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.
モバイルノードに関する回答) に従って、セクション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を参照してください。
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
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の逆のトンネルが義務的であるよう要求しました、そして、セット139ではなく、'T'ビットが入手できないカプセル化を要求しました。
Montenegro Standards Track [Page 7] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[7ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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を使用しなければなりません。
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. The Mobile-Home Authentication Extension MUST always be present.
別の方法で指定されない場合、モバイル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 8] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[8ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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), 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 9] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[9ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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 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'ビットがセットした状態でRegistration Requestを受け取る外国人のエージェントは、指定されるとしてのモバイルIP仕様[1]によるパケットを処理して、それは前進のトンネルが要求するaccomodateをそうすることができるかどうかと決心しています。 そうすることができないなら、それは適切なコードを返します。 外国人のエージェントが要求されたフォームのカプセル化をサポートすることができないなら、特に、それは復帰コード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'ビットなしで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 10] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[10ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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 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]によるパケットを処理して、それは前進のトンネルが要求するaccomodateをそうすることができるかどうかと決心しています。 そうすることができないなら、それは適切なコードを返します。 ホームのエージェントが要求されたフォームのカプセル化をサポートすることができないなら、特に、それは復帰コード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 11] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[11ページ]RFC2344は1998年5月にモバイル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).
登録が有効である間、ホームのエージェントはそれを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 12] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[12ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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 Registration
Request.
Registration Requestの中のホームエージェント分野から、コピーされます。
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 13] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[13ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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 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 14] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[14ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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 Registration
Request.
Registration Requestの中のホームエージェント分野から、コピーされます。
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 15] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[15ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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 16] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[16ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
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."
ソースが「有効である」より傾向があるときに、攻撃の源を追跡するのは簡易型です。
7. Acknowledgements
7. 承認
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移動性サポート」、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で、/パブ/本命_状況報告で利用可能です。
[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] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[7] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[7] アトキンソン、R.、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC1827、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.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月。
Montenegro Standards Track [Page 17] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[17ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
Editor and Chair Addresses
エディタと議長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.モンテネグロサン・マイクロシステムズ・インク901サンアントニオ道路Mailstop UMPK15-214カリフォルニア 94303
Voice: +1-415-786-6288 Fax: +1-415-786-6445 EMail: gabriel.montenegro@eng.sun.com
声: +1-415-786-6288 Fax: +1-415-786-6445 メールしてください: 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
ジムソロモンモトローラ1301E.アルゴンキン族通り - スカンバーブ、Rm2240イリノイ 60196
Voice: +1-847-576-2753 Fax: +1-847-576-3240 EMail: solomon@comm.mot.com
声: +1-847-576-2753 Fax: +1-847-576-3240 メールしてください: solomon@comm.mot.com
Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK17-202 Mountain View, California 94303
エリックNordmarkサン・マイクロシステムズ・インク901サンアントニオ道路Mailstop UMPK17-202マウンテンビュー、カリフォルニア 94303
Voice: +1-415-786-5166 EMail: erik.nordmark@eng.sun.com
声: +1-415-786-5166 メールしてください: erik.nordmark@eng.sun.com
Montenegro Standards Track [Page 18] RFC 2344 Reverse Tunneling for Mobile IP May 1998
モンテネグロ標準化過程[18ページ]RFC2344は1998年5月にモバイルIPのためにトンネリングを覆します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Montenegro Standards Track [Page 19]
モンテネグロ標準化過程[19ページ]
一覧
スポンサーリンク
