RFC4487 日本語訳
4487 Mobile IPv6 and Firewalls: Problem Statement. F. Le, S. Faccin,B. Patil, H. Tschofenig. May 2006. (Format: TXT=32022 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Le
Request for Comments: 4487 CMU
Category: Informational S. Faccin
B. Patil
Nokia
H. Tschofenig
Siemens
May 2006
Leがコメントのために要求するワーキンググループF.をネットワークでつないでください: 4487年の米カーネギーメロン大学カテゴリ: 情報のS.のパティルノキアH.TschofenigジーメンスFaccin B.2006年5月
Mobile IPv6 and Firewalls: Problem Statement
モバイルIPv6とファイアウォール: 問題声明
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.
このドキュメントはモバイルIPv6とファイアウォールをサポートするとIPv6ネットワークの展開で起こるかもしれない問題を得ます。 問題も、企業網を保護するファイアウォールに適切であるだけではありませんが、また、汎用パケット無線システム/普遍的なモバイルTelecommunications Systemなどの3Gモバイルネットワーク(GPRS/UMTS)とCDMA2000ネットワークで適切です。
The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions.
このドキュメントの目標は、ファイアウォールとモバイルIPv6と共に問題を強調して、さらなる議論のためのイネーブラとして機能することです。 適切な解決策を見いだすことによって、ここで特定された問題は解決できます。
Le, et al. Informational [Page 1] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[1ページ]のRFC4487MIPv6とファイアウォール2006年5月
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Abbreviations ...................................................4
4. Overview of Firewalls ...........................................4
5. Analysis of Various Scenarios Involving MIP6 Nodes and
Firewalls .......................................................6
5.1. Scenario Where the Mobile Node Is in a Network
Protected by Firewall(s) ...................................7
5.2. Scenario Where the Correspondent Node Is in a
Network Protected by Firewall(s) ...........................9
5.3. Scenario Where the HA Is in a Network Protected by
Firewall(s) ...............................................12
5.4. Scenario Where the MN Moves to a Network Protected by
Firewall(s) ...............................................12
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Appendix A. Applicability to 3G Networks ..........................15
1. 序論…3 2. 用語…4 3. 略語…4 4. ファイアウォールの概要…4 5. MIP6ノードとファイアウォールにかかわる様々なシナリオの分析…6 5.1. ネットワークにはモバイルノードがあるシナリオはファイアウォールのそばに保護されました…7 5.2. ネットワークには通信員ノードがあるシナリオはファイアウォールのそばに保護されました…9 5.3. シナリオ、どこ、ハ、ネットワークがファイアウォールに保護したコネはそうであるか。12 5.4. ミネソタがネットワークに移行するシナリオはファイアウォールのそばに保護されました…12 6. 結論…13 7. セキュリティ問題…14 8. 承認…14 9. 参照…14 9.1. 標準の参照…14 9.2. 有益な参照…14 3Gネットワークへの付録A.の適用性…15
Le, et al. Informational [Page 2] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[2ページ]のRFC4487MIPv6とファイアウォール2006年5月
1. Introduction
1. 序論
Network elements such as firewalls are an integral aspect of a majority of IP networks today, given the state of security in the Internet, threats, and vulnerabilities to data networks. Current IP networks are predominantly based on IPv4 technology, and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development.
今日ファイアウォールなどのネットワーク原理はIPネットワークの大部分の不可欠の局面です、データ網へのインターネット、脅威、および脆弱性におけるセキュリティの状態を考えて。 現在のIPネットワークはIPv4技術に支配的に基づいています、そして、したがって、ファイアウォールはこれらのネットワークのために設計されています。 それにしても、IPv6ネットワークの展開は現在、緩慢で進歩をしています。 IPv6ネットワークのためのファイアウォールはまだ開発を熟させて開発中です。
Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6.
IPv6の移動性サポートはRFC3775で指定されるように標準化されました。 モバイルIPv6が最近の規格であるという事実を考えて、IPv6ネットワークに利用可能なほとんどのファイアウォールはモバイルIPv6をサポートしません。
Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere with the smooth operation of the protocol and can be a detriment to deployment.
ファイアウォールがモバイルIPv6プロトコルの詳細を意識していない場合、これらのセキュリティデバイスは、プロトコルの円滑な運用を妨げて、展開への損傷であるかもしれません。
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile IPv6 node to be reachable via its home IPv6 address irrespective of any link that the mobile attaches to. This is possible as a result of the extensions to IPv6 defined in the Mobile IPv6 specification [1].
モバイルIPv6はIPv6ノードのためにIPの移動性を可能にします。 それは、モバイルIPv6ノードにモバイルが付くどんなリンクの如何にかかわらずホームIPv6アドレスで届いているのを許容します。 これはモバイルIPv6仕様[1]に基づき定義されたIPv6への拡大の結果、可能です。
Mobile IPv6 protocol design also incorporates a feature termed Route Optimization. This set of extensions is a fundamental part of the protocol that enables optimized routing of packets between a mobile node and its correspondent node and therefore optimized performance of the communication.
また、モバイルIPv6プロトコルデザインはRoute Optimizationと呼ばれた特徴を取り入れます。 このセットの拡大はモバイルノードとその通信員ノードの間のパケットの最適化されたルーティングとコミュニケーションのしたがって、最適化された性能を可能にするプロトコルの基本的な部分です。
In most cases, current firewall technologies, however, do not support Mobile IPv6 or are not even aware of Mobile IPv6 headers and extensions. Since most networks in the current business environment deploy firewalls, this may prevent future large-scale deployment of the Mobile IPv6 protocol.
多くの場合、現在のファイアウォール技術は、しかしながら、モバイルIPv6をサポートしないか、またはモバイルIPv6ヘッダーと拡大を意識してさえいません。 現在の経営環境におけるほとんどのネットワークがファイアウォールを配布するので、これはモバイルIPv6プロトコルの今後の大規模な展開を防ぐかもしれません。
This document presents in detail some of the issues that firewalls present for Mobile IPv6 deployment, as well as the impact of each issue.
このドキュメントは詳細にモバイルIPv6展開へのそのファイアウォールプレゼントを問題のいくつかに提示します、それぞれの問題の影響と同様に。
Le, et al. Informational [Page 3] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[3ページ]のRFC4487MIPv6とファイアウォール2006年5月
2. Terminology
2. 用語
Return Routability Test (RRT): The Return Routability Test is a
procedure defined in RFC 3775 [1]. It is performed prior to the
Route Optimization (RO), where a mobile node (MN) instructs a
correspondent node (CN) to direct the mobile node's data traffic
to its claimed care-of address (CoA). The Return Routability
procedure provides some security assurance and prevents the misuse
of Mobile IPv6 signaling to maliciously redirect the traffic or to
launch other attacks.
テスト(RRT)をRoutabilityに返してください: Return Routability TestはRFC3775[1]で定義された手順です。 実行されて、指示してくださいモバイルノード(ミネソタ)が通信員ノード(CN)にモバイルノードのデータ通信量を命令するRoute Optimization(RO)の前では、それが要求されたということである、注意、-、(CoA)を扱ってください。 Return Routability手順は、何らかの安全保証を前提として、モバイルIPv6の誤用が、陰湿にトラフィックを向け直すか、または他の攻撃に着手するのを示すのを防ぎます。
3. Abbreviations
3. 略語
This document uses the following abbreviations:
このドキュメントは以下の略語を使用します:
o CN: Correspondent Node
o CN: 通信員ノード
o CoA: Care of Address
o CoA: アドレスの注意
o CoTI: Care of Test Init
o CoTI: テストイニットの注意
o HA: Home Agent
o ハ: ホームのエージェント
o HoA: Home Address
o HoA: ホームアドレス
o HoTI: Home Test Init
o HoTI: ホームテストイニット
o HoT: Home Test
o 熱い: ホームテスト
o MN: Mobile Node
o ミネソタ: モバイルノード
o RO: Route Optimization
o RO: 経路最適化
o RRT: Return Routability Test
o RRT: リターンRoutabilityテスト
4. Overview of Firewalls
4. ファイアウォールの概要
The following section provides a brief overview of firewalls. It is intended as background information so that issues with the Mobile IPv6 protocol can then be presented in detail in the following sections.
以下のセクションはファイアウォールの簡潔な概要を提供します。 それは、次に、以下のセクションに詳細にモバイルIPv6プロトコルの問題を提示できるように基礎的な情報として意図します。
There are different types of firewalls, and state can be created in these firewalls through different methods. Independent of the adopted method, firewalls typically look at five parameters of the traffic arriving at the firewalls:
異なったタイプのファイアウォールがあります、そして、これらのファイアウォールに異なったメソッドで状態は創設できます。 採用されたメソッドの如何にかかわらず、ファイアウォールは、トラフィックの5つのパラメタがファイアウォールに到着するのを通常見ます:
Le, et al. Informational [Page 4] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[4ページ]のRFC4487MIPv6とファイアウォール2006年5月
o Source IP address
o ソースIPアドレス
o Destination IP address
o 送付先IPアドレス
o Protocol type
o プロトコルタイプ
o Source port number
o ソースポート番号
o Destination port number
o 目的地ポートナンバー
Based on these parameters, firewalls usually decide whether to allow the traffic or to drop the packets. Some firewalls may filter only incoming traffic, while others may also filter outgoing traffic.
これらのパラメタに基づいて、通常、ファイアウォールは、トラフィックを許容するか、またはパケットを下げるかを決めます。 いくつかのファイアウォールが入って来るトラフィックだけをフィルターにかけるかもしれませんが、また、他のものは外向的なトラフィックをフィルターにかけるかもしれません。
According to Section 3.29 of RFC 2647 [2], stateful packet filtering refers to the process of forwarding or rejecting traffic based on the contents of a state table maintained by a firewall. These types of firewalls are commonly deployed to protect networks from different threats, such as blocking unsolicited incoming traffic from the external networks. The following briefly describes how these firewalls work since they can create additional problems with the Mobile IPv6 protocol as described in the subsequent sections.
RFC2647[2]のセクション3.29によると、statefulパケットフィルタリングはファイアウォールによって維持されたステートテーブルのコンテンツに基づくトラフィックを進めるか、または拒絶するプロセスについて言及します。 これらのタイプのファイアウォールは異なった脅威からネットワークを保護するために一般的に配布されます、外部のネットワークから求められていない入って来るトラフィックを妨げるのなどように。 以下は簡潔にその後のセクションで説明されるようにモバイルIPv6プロトコルに関する追加問題を生じさせることができるのでこれらのファイアウォールがどう働いているかを説明します。
In TCP, an MN sends a TCP SYN message to connect to another host in the Internet.
TCPでは、ミネソタはインターネットの別のホストに接するTCP SYNメッセージを送ります。
Upon receiving that SYN packet, the firewall records the source IP address, the destination IP address, the Protocol type, the source port number, and the destination port number indicated in that packet before transmitting it to the destination.
そのSYNパケット、それを目的地に送る前にソースIPアドレス、送付先IPアドレス、プロトコルタイプ、ソースポート番号、および仕向港番号がそのパケットで示したファイアウォール記録を受け取ることに関して。
When an incoming message from the external networks reaches the firewall, it searches the packet's source IP address, destination IP address, Protocol type, source port number, and destination port number in its entries to see if the packet matches the characteristics of a request sent previously. If so, the firewall allows the packet to enter the network. If the packet was not solicited from an internal node, the packet is blocked.
外部のネットワークからの入力メッセージがファイアウォールに達すると、それは、パケットが以前に送られた要求の特性に合っているかどうか確認するためにエントリーでパケットのソースIPアドレス、送付先IPアドレス、プロトコルタイプ、ソースポート番号、および仕向港番号を身体検査します。 そうだとすれば、ファイアウォールで、パケットはネットワークに入ることができます。 パケットが内部のノードから請求されなかったなら、パケットは妨げられます。
When the TCP close session packets are exchanged or after some configurable period of inactivity, the associated entry in the firewall is deleted. This mechanism prevents entries from remaining when TCP are abruptly terminated.
TCPの近いセッションパケットを交換する時かいつかの構成可能な期間の不活発の後に、ファイアウォールの関連エントリーは削除されます。 このメカニズムは、TCPが突然に終えられるとき、エントリーが残っているのを防ぎます。
A similar entry is created when using UDP. The difference with this transport protocol is that UDP is connectionless and does not have packets signaling the initiation or termination of a session. Consequently, the duration of the entries relies solely on timers.
UDPを使用するとき、同様のエントリーは作成されます。 このトランスポート・プロトコルがある違いはUDPがコネクションレスであり、パケットにセッションの開始か終了を合図させないということです。 その結果、エントリーの持続時間は唯一タイマを当てにします。
Le, et al. Informational [Page 5] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[5ページ]のRFC4487MIPv6とファイアウォール2006年5月
5. Analysis of Various Scenarios Involving MIP6 Nodes and Firewalls
5. MIP6ノードとファイアウォールにかかわる様々なシナリオの分析
The following section describes various scenarios involving MIP6 nodes and firewalls and also presents the issues related to each scenario.
以下のセクションは、MIP6ノードとファイアウォールにかかわる様々なシナリオについて説明して、また、各シナリオに関連する問題を提示します。
The Mobile IPv6 specifications define three main entities: the mobile node (MN), the correspondent node (CN), and the home agent (HA). Each of these entities may be in a network protected by one or many firewalls:
モバイルIPv6仕様は3つの主な実体を定義します: モバイルノード(ミネソタ)、通信員ノード(CN)、およびホームのエージェント(HA)。 1か多くのファイアウォールによって保護されたネットワークにはそれぞれのこれらの実体があるかもしれません:
o Section 5.1 analyzes the issues when the MN is in a network
protected by firewall(s)
o ファイアウォールによって保護されたネットワークにミネソタがあるとき、セクション5.1は問題を分析します。(s)
o Section 5.2 analyzes the issues when the CN is in a network
protected by firewall(s)
o ファイアウォールによって保護されたネットワークにCNがあるとき、セクション5.2は問題を分析します。(s)
o Section 5.3 analyzes the issues when the HA is in a network
protected by firewall(s)
o ファイアウォールによって保護されたネットワークにHAがあるとき、セクション5.3は問題を分析します。(s)
The MN may also be moving from an external network, to a network protected by firewall(s). The issues of this case are described in Section 5.4.
また、ミネソタは外部のネットワークからファイアウォールによって保護されたネットワークまで移行しているかもしれません。 本件の問題はセクション5.4で説明されます。
Some of the described issues (e.g., Sections 5.1 and 5.2) may require modifications to the protocols or to the firewalls, and others (e.g., Section 5.3) may require only that appropriate rules and configuration be in place.
説明された問題(例えば、セクション5.1と5.2)のいくつかがプロトコル、または、ファイアウォールへの変更を必要とするかもしれません、そして、他のもの(例えば、セクション5.3)は適切な規則と構成が適所にあるだけであるのを必要とするかもしれません。
Le, et al. Informational [Page 6] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[6ページ]のRFC4487MIPv6とファイアウォール2006年5月
5.1. Scenario Where the Mobile Node Is in a Network Protected by
Firewall(s)
5.1. ファイアウォールによって保護されたネットワークにはモバイルノードがあるシナリオ(s)
Let's consider MN A, in a network protected by firewall(s).
ファイアウォールによって保護されたネットワークでミネソタがAであると考えましょう。
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
+----------------+ +----+ | | | ハ| | | +----+ | | ホームのエージェント| +---+ +----+ +について---+ | | A| | FW| | B| | +---+ +----+ +---+ |内部| 外部| ミネソタ| ノード| | +----------------+ ネットワークは保護されました。
Figure 1: Issues between MIP6 and firewalls when MN is in a network
protected by firewalls
図1: ネットワークにミネソタがあるとき、MIP6とファイアウォールの間の問題はファイアウォールのそばに保護されました。
A number of issues need to be considered:
多くの問題が、考えられる必要があります:
Issue 1: When MN A connects to the network, it should acquire a local
IP address (CoA) and send a Binding Update (BU) to its Home Agent
to update the HA with its current point of attachment. The
Binding Updates and Acknowledgements should be protected by IPsec
ESP according to the MIPv6 specifications [1]. However, as a
default rule, many firewalls drop IPsec ESP packets because they
cannot determine whether inbound ESP packets are legitimate. It
is difficult or impossible to create useful state by observing the
outbound ESP packets. This may cause the Binding Updates and
Acknowledgements between the mobile nodes and their home agent to
be dropped.
問題1: ミネソタAがネットワークに接続するとき、それは、現在の接着点があるHAをアップデートするために、ローカルアイピーアドレス(CoA)を習得して、Binding Update(BU)をホームのエージェントに送るべきです。 Binding UpdatesとAcknowledgementsはIPsecによって保護されるはずです。MIPv6仕様[1]に従った超能力。 しかしながら、省略時の解釈として、本国行きの超能力パケットが正統であるかどうか決定できないので、多くのファイアウォールがIPsec超能力パケットを下げます。 外国行きの超能力パケットを観察することによって役に立つ状態を創設するのは、難しいか、または不可能です。 これで、モバイルノードと彼らのホームのエージェントの間のBinding UpdatesとAcknowledgementsを下げるかもしれません。
Issue 2: Let's now consider a node in the external network, B, trying
to establish a communication with MN A.
問題2: ミネソタAとのコミュニケーションを確立しようとして、現在、外部のネットワーク、Bでノードを考えましょう。
* B sends a packet to the mobile node's home address.
* Bはモバイルノードのホームアドレスにパケットを送ります。
* The packet is intercepted by the MN's home agent, which tunnels
it to the MN's CoA [1].
* パケットはミネソタのホームのエージェントによって妨害されます。(そのエージェントは、ミネソタのCoA[1]にそれにトンネルを堀ります)。
* When arriving at the firewall(s) protecting MN A, the packet
may be dropped since the incoming packet may not match any
existing state. As described in Section 4, stateful inspection
packet filters (for example) typically drop unsolicited
incoming traffic.
* ミネソタAを保護しながらファイアウォールに到着するとき、入って来るパケットが少しの現状にも合わないかもしれないので、パケットは下げられるかもしれません。 セクション4で説明されるように、(例えば、)ステートフルインスペクションパケットフィルタは求められていない入って来るトラフィックを通常下げます。
Le, et al. Informational [Page 7] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[7ページ]のRFC4487MIPv6とファイアウォール2006年5月
* B will thus not be able to contact MN A and establish a
communication.
* Bは、ミネソタAに接触して、その結果、コミュニケーションを確立できないでしょう。
Even though the HA is updated with the location of an MN,
firewalls may prevent correspondent nodes from establishing
communications when the MN is in a network protected by
firewall(s).
ミネソタの位置でHAをアップデートしますが、ファイアウォールは、ファイアウォールによって保護されたネットワークにミネソタがあるとき、通信員ノードがコミュニケーションを確立するのを防ぐかもしれません。
Issue 3: Let's assume a communication between MN A and an external
node B. MN A may want to use Route Optimization (RO) so that
packets can be directly exchanged between the MN and the CN
without passing through the HA. However, the firewalls protecting
the MN might present issues with the Return Routability procedure
that needs to be performed prior to using RO.
問題3: ミネソタAと外部ノードB.ミネソタAとのコミュニケーションがミネソタとCNの間で直接HAを通り抜けないでパケットを交換できるように、Route Optimization(RO)を使用したがっているかもしれないと仮定しましょう。 しかしながら、ミネソタを保護するファイアウォールはROを使用する前に実行される必要があるReturn Routability手順の問題を提示するかもしれません。
According to the MIPv6 specifications, the Home Test message of
the RRT must be protected by IPsec in tunnel mode. However,
firewalls might drop any packet protected by ESP, since the
firewalls cannot analyze the packets encrypted by ESP (e.g., port
numbers). The firewalls may thus drop the Home Test messages and
prevent the completion of the RRT procedure.
MIPv6仕様に従って、IPsecはトンネルモードでRRTに関するホームTestメッセージを保護しなければなりません。 しかしながら、ファイアウォールは超能力によって保護されたどんなパケットも下げるかもしれません、ファイアウォールが超能力(例えば、ポートナンバー)によって暗号化されたパケットを分析できないので。 ファイアウォールは、その結果、ホームTestメッセージを下げて、RRT手順の完成を防ぐかもしれません。
Issue 4: Let's assume that MN A successfully sends a Binding Update
to its home agent (resp. correspondent nodes) -- which solves
issue 1 (resp. issue 3) -- and that the subsequent traffic is sent
from the HA (resp. CN) to the MN's CoA. However there may not be
any corresponding state in the firewalls. The firewalls
protecting A may thus drop the incoming packets.
問題4: ミネソタAが首尾よくホームのエージェント(resp通信員ノード)にBinding Updateを送って(どれが問題1(resp問題3)を解決するか)、その後のトラフィックがHAから送られると仮定しましょう。(resp。 CN) ミネソタのCoAに。 しかしながら、少しの対応する状態もファイアウォールにないかもしれません。 その結果、Aを保護するファイアウォールは入って来るパケットを下げるかもしれません。
The appropriate states for the traffic to the MN's CoA need to be
created in the firewall(s).
ミネソタのCoAへのトラフィックのための適切な州は、ファイアウォールで作成される必要があります。
Issue 5: When MN A moves, it may move to a link that is served by a
different firewall. MN A might be sending a BU to its CN;
however, incoming packets may be dropped at the firewall, since
the firewall on the new link that the MN attaches to does not have
any state that is associated with the MN.
問題5: ミネソタAが移行すると、それは異なったファイアウォールによって役立たれているリンクに移行するかもしれません。 ミネソタAはBUをCNに送るかもしれません。 しかしながら、入って来るパケットはファイアウォールで下げられるかもしれません、いずれにもそれを述べさせないようにミネソタが取り付ける新しいリンクの上のファイアウォールがミネソタに関連しているので。
The issues described above result from the fact that the MN is behind the firewall. Consequently, the MN's communication capability with other nodes is affected by the firewall rules.
結果を超えてファイアウォールの後ろにミネソタがあるという事実から説明された問題。 その結果、他のノードがあるミネソタのコミュニケーション能力はファイアウォール規則で影響を受けます。
Le, et al. Informational [Page 8] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[8ページ]のRFC4487MIPv6とファイアウォール2006年5月
5.2. Scenario Where the Correspondent Node Is in a Network Protected by
Firewall(s)
5.2. ファイアウォールによって保護されたネットワークには通信員ノードがあるシナリオ(s)
Let's consider an MN in a network, communicating with a Correspondent Node C in a network protected by firewall(s). There are no issues with the presence of a firewall in the scenario where the MN is sending packets to the CN via a reverse tunnel that is set up between the MN and HA. However, firewalls may present different issues to Route Optimization.
ファイアウォールによって保護されたネットワークでCorrespondent Node Cとコミュニケートして、ネットワークでミネソタを考えましょう。 シナリオでのファイアウォールの存在には問題が全くミネソタがミネソタとHAの間でセットアップされる逆のトンネルを通してパケットをCNに送るところにありません。 しかしながら、ファイアウォールはRoute Optimizationに別問題を提示するかもしれません。
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
+----------------+ +----+ | | | ハ| | | +----+ | | ホームのエージェント| +---+ +----+ Bについて| |CN| | FW| | | C| +----+ | +---+ | +---+ | | | B| | | +---+ +----------------+ 外部のモバイルNetworkはファイアウォールのそばにNodeを保護しました。
Figure 2: Issues between MIP6 and firewalls when a CN is in a network
protected by firewalls
図2: ネットワークにCNがあるとき、MIP6とファイアウォールの間の問題はファイアウォールのそばに保護されました。
The following issues need to be considered:
以下の問題は、考えられる必要があります:
Issue 1: The MN (MN B) should use its Home Address (HoA B) when
establishing the communication with the CN (CN C), if MN B wants
to take advantage of the mobility support provided by the Mobile
IPv6 protocol for its communication with CN C. The state created
by the firewall protecting CN C is therefore created based on the
IP address of C (IP C) and the home address of Node B (IP HoA B).
The states may be created via different means, and the protocol
type as well as the port numbers depend on the connection setup.
問題1: CN(CN C)とのコミュニケーションを確立するとき、ミネソタ(ミネソタB)はホームAddress(HoA B)を使用するべきです、したがって、ファイアウォール保護CN Cによって創設された状態がC(IP C)のIPアドレスとNode B(IP HoA B)に関するホームアドレスに基づいてCN C.とのコミュニケーションのためのモバイルIPv6プロトコルによって創設されるならミネソタBが移動性サポートを利用したいなら。 州は異なった手段で創設されるかもしれません、そして、ポートナンバーと同様にプロトコルタイプは接続設定を当てにします。
Uplink packet filters (1)
アップリンクパケットフィルタ(1)
Source IP address: IP C
ソースIPアドレス: IP C
Destination IP address: HoA B
送付先IPアドレス: HoA B
Protocol Type: TCP/UDP
タイプについて議定書の中で述べてください: TCP/UDP
Source Port Number: #1
ソースポート番号: #1
Le, et al. Informational [Page 9] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[9ページ]のRFC4487MIPv6とファイアウォール2006年5月
Destination Port Number: #2
仕向港番号: #2
Downlink packet filters (2)
ダウンリンクパケットフィルタ(2)
Source IP address: HoA B
ソースIPアドレス: HoA B
Destination IP address: IP C
送付先IPアドレス: IP C
Protocol Type: TCP/UDP
タイプについて議定書の中で述べてください: TCP/UDP
Source Port Number: #2
ソースポート番号: #2
Destination Port Number: #1
仕向港番号: #1
Nodes C and B might be topologically close to each other, while
B's home agent may be far away, resulting in a trombone effect
that can create delay and degrade the performance. MN B may
decide to initiate the route optimization procedure with Node C.
Route optimization requires MN B to send a Binding Update to Node
C in order to create an entry in its binding cache that maps the
MN's home address to its current care-of-address. However, prior
to sending the binding update, the mobile node must first execute
a Return Routability Test:
ノードCとBは互いに位相的に閉じることであるかもしれません、ビーズのホームのエージェントが遠いかもしれませんが、遅れを作成して、性能を下げることができるトロンボーン効果をもたらして。 ミネソタBは、アドレスの現在の注意にミネソタのホームアドレスを写像する拘束力があるキャッシュにおけるエントリーを作成するためにRoute最適化が、ミネソタBがBinding Updateを送るのを必要とするNode C.がある経路最適化手順にNode Cに着手すると決めるかもしれません。 しかしながら、モバイルノードは最初に、拘束力があるアップデートを送る前に、Return Routability Testを実行しなければなりません:
* Mobile Node B has to send a Home Test Init (HoTI) message via
its home agent and
* そしてモバイルNode Bがホームのエージェントを通してホームTest Init(HoTI)メッセージを送らなければならない。
* a Care of Test Init (COTI) message directly to its
Correspondent Node C.
* 直接Correspondent Node CへのTest Init(COTI)メッセージのCare。
The Care of Test Init message is sent using the CoA of B as the
source address. Such a packet does not match any entry in the
protecting firewall (2). The CoTi message will thus be dropped by
the firewall.
Test InitメッセージのCareにソースアドレスとしてBのCoAを使用させます。 そのようなパケットは保護しているファイアウォール(2)の少しのエントリーにも合っていません。 その結果、CoTiメッセージはファイアウォールによって下げられるでしょう。
The HoTI is a Mobility Header packet, and as the protocol type
differs from the established state in the firewall (see (2)), the
HoTI packet will also be dropped.
HoTIはMobility Headerパケットであり、プロトコルタイプとしてファイアウォールで設立された状態と異なっています。((2)) HoTIパケットがそうするのを確実にしてください、そして、また、下げられてください。
As a consequence, the RRT cannot be completed, and route
optimization cannot be applied. Every packet has to go through
Node B's home agent and tunneled between B's home agent and B.
結果として、RRTは完成できません、そして、経路最適化は適用できません。 あらゆるパケットがビーズのホームのエージェントであってビーズホームのエージェントとBの間でトンネルを堀られたNodeを通らなければなりません。
Le, et al. Informational [Page 10] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[10ページ]のRFC4487MIPv6とファイアウォール2006年5月
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW |
| +------+ | | | HoTI
| | | |
| | | CoTI (CoA)+------+
| | +------------------| MN B |
+----------------+ +------+
Network protected External Mobile
by a firewall Node
+----------------+ | +----+ HoTI(HoA)+----+ | | FW|X<。---------------|ハ、B| | +----X+----+ | +------+ | ^CoTI&HoTI^| | CN C| | | FWで、低下します。| | +------+ | | | HoTI| | | | | | | CoTI(CoA)+------+ | | +------------------| ミネソタB| +----------------+ +------+ ファイアウォールNodeのそばのモバイルのネットワーク保護されたExternal
Figure 3: Issues with Return Routability Test
図3: リターンRoutabilityテストの問題
Issue 2: Let's assume that the Binding Update to the CN is
successful; the firewall(s) might still drop packets that are:
問題2: CNへのBinding Updateがうまくいっていると仮定しましょう。 ファイアウォールはまだ以下の通りであるパケットを下げているかもしれません。
1. coming from the CoA, since these incoming packets are sent
from the CoA and do not match the Downlink Packet filter (2).
1. CoAから来て、これらの入って来るパケットがCoAから送られて、合っていないので、Downlink Packetは(2)をフィルターにかけます。
2. sent from the CN to the CoA if uplink packet filters are
implemented. The uplink packets are sent to the MN's CoA and
do not match the uplink packet filter (1).
2. アップリンクであるならCNからCoAに送って、パケットフィルタは実装されます。 アップリンクパケットは、ミネソタのCoAに送られて、アップリンクパケットフィルタ(1)に合っていません。
The packet filters for the traffic sent to (resp. from) the CoA
need to be created in the firewall(s).
トラフィックのためのパケットフィルタが発信した、(resp、)、CoAは、ファイアウォールで作成される必要があります。
Requiring the firewalls to update the connection state upon
detecting Binding Update messages from a node outside the network
protected by the firewall does not appear feasible or desirable,
since currently the firewall does not have any means to verify the
validity of Binding Update messages and therefore to modify the
state information securely. Changing the firewall states without
verifying the validity of the Binding Update messages could lead
to denial of service attacks. Malicious nodes may send fake
binding updates, forcing the firewall to change its state
information, and therefore leading the firewall to drop packets
from the connections that use the legitimate addresses. An
adversary might also use an address update to enable its own
traffic to pass through the firewall and enter the network.
ファイアウォールによって保護されたネットワークの外にノードからのBinding Updateメッセージを検出するとき接続状態をアップデートするためにファイアウォールを必要とするのは可能であるか望ましく見えません、現在のファイアウォールにはBinding Updateメッセージの正当性について確かめて、したがってしっかりと州の情報を変更するどんな手段もないので。 Binding Updateメッセージの正当性について確かめないでファイアウォール州を変えるのはサービス不能攻撃に通じるかもしれません。 悪意があるノードはにせの拘束力があるアップデートを送るかもしれません、ファイアウォールに州の情報を変えさせて、したがって、ファイアウォールが正統のアドレスを使用する接続からパケットを下げるように導きます。 また、敵は、それ自身のトラフィックがファイアウォールを通り抜けて、ネットワークに入るのを可能にするのにアドレス最新版を使用するかもしれません。
Issue 3: Let's assume that the Binding Update to the CN is
successful. The CN may be protected by different firewalls, and
as a result of the MN's change of IP address, incoming and
outgoing traffic may pass through a different firewall. The new
問題3: CNへのBinding Updateがうまくいっていると仮定しましょう。 CNは異なったファイアウォールによって保護されるかもしれません、そして、ミネソタのIPアドレスの変化の結果、送受信のトラフィックは異なったファイアウォールを通り抜けるかもしれません。 新しさ
Le, et al. Informational [Page 11] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[11ページ]のRFC4487MIPv6とファイアウォール2006年5月
firewall may not have any state associated with the CN, and
incoming packets (and potentially outgoing traffic as well) may be
dropped at the firewall.
ファイアウォールには、CNに関連している少しの状態もないかもしれません、そして、入って来るパケット(そして、また、潜在的に外向的なトラフィック)はファイアウォールで下げられるかもしれません。
Firewall technology allows clusters of firewalls to share state
[3]. This, for example, allows the support of routing asymmetry.
However, if the previous and the new firewalls, through which the
packets are routed after the Binding Update has been sent, do not
share state, this may result in packets being dropped at the new
firewall. As the new firewall does not have any state associated
with the CN, incoming packets (and potentially outgoing traffic as
well) may be dropped at the new firewall.
ファイアウォール技術で、ファイアウォールのクラスタは状態[3]を共有できます。 例えば、これはルーティング非対称のサポートを許します。 しかしながら、前のファイアウォールと新しいファイアウォール(Binding Updateを送った後にパケットを発送する)が状態を共有しないなら、これは新しいファイアウォールで下げられるパケットをもたらすかもしれません。 新しいファイアウォールにCNに関連している少しの状態もないとき、入って来るパケット(そして、また、潜在的に外向的なトラフィック)は新しいファイアウォールで下げられるかもしれません。
5.3. Scenario Where the HA Is in a Network Protected by Firewall(s)
5.3. シナリオ、どこ、ハ、ファイアウォールによって保護されたネットワークには、あるか。(s)
In the scenarios where the home agent is in a network protected by firewall(s), the following issues may exist:
ファイアウォールによって保護されたネットワークにはホームのエージェントがいるシナリオでは、以下の問題は存在するかもしれません:
Issue 1: If the firewall(s) protecting the home agent block ESP
traffic, much of the MIPv6 signaling (e.g., Binding Update, HoT)
may be dropped at the firewall(s), preventing MN(s) from updating
their binding cache and performing Route Optimization, since
Binding Update, HoT, and other MIPv6 signaling must be protected
by IPsec ESP.
問題1: ホームのエージェントを保護するファイアウォールが超能力トラフィックを妨げるなら、MIPv6シグナリング(例えば、Binding Update、HoT)の多くはIPsecがBinding Update、HoT、および他のMIPv6シグナリングを保護しなければならないので、ファイアウォールで下げられて、ミネソタがそれらの拘束力があるキャッシュをアップデートするのを防いで、Route Optimizationを実行するのが、超能力であったなら妨げます。
Issue 2: If the firewall(s) protecting the home agent block
unsolicited incoming traffic (e.g., as stateful inspection packet
filters do), the firewall(s) may drop connection setup requests
from CNs, and packets from MNs.
問題2: ホームのエージェントを保護するファイアウォールが求められていない入って来るトラフィック(例えばフィルタがするステートフルインスペクションパケットとしての)を妨げるなら、CNsから接続設定要求を落として、ファイアウォールはMNsからパケットを落とすかもしれません。
Issue 3: If the home agent is in a network protected by several
firewalls, an MN/CN's change of IP address may result in the
passage of traffic to and from the home agent through a different
firewall that may not have the states corresponding to the flows.
As a consequence, packets may be dropped at the firewall.
問題3: いくつかのファイアウォールによって保護されたネットワークにホームのエージェントがいるなら、ミネソタ/CNのIPアドレスの変化はエージェントとホームのエージェントから異なった州を流れに対応するようにしないかもしれないファイアウォールのトラフィックの通路をもたらすかもしれません。 結果として、パケットはファイアウォールで下げられるかもしれません。
5.4. Scenario Where the MN Moves to a Network Protected by Firewall(s)
5.4. ミネソタがファイアウォールによって保護されたネットワークに移行するシナリオ(s)
Let's consider an HA in a network protected by firewall(s). The following issues need to be investigated:
ファイアウォールによって保護されたネットワークでHAを考えましょう。 以下の問題は、調査される必要があります:
Issue 1: Similarly to issue 1 described in Section 5.1, the MN will
send a Binding Update to its home agent after acquiring a local IP
address (CoA). The Binding Updates and Acknowledgements should be
protected by IPsec ESP according to the MIPv6 specifications [1].
However, as a default rule, many firewalls drop ESP packets. This
may cause the Binding Updates and Acknowledgements between the
mobile nodes and their home agent to be dropped.
問題1: 同様に、セクション5.1で説明されていた状態で1を発行するために、ローカルアイピーアドレス(CoA)を習得した後に、ミネソタはホームのエージェントにBinding Updateを送るでしょう。 Binding UpdatesとAcknowledgementsはIPsecによって保護されるはずです。MIPv6仕様[1]に従った超能力。 しかしながら、省略時の解釈として、多くのファイアウォールが超能力パケットを下げます。 これで、モバイルノードと彼らのホームのエージェントの間のBinding UpdatesとAcknowledgementsを下げるかもしれません。
Le, et al. Informational [Page 12] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[12ページ]のRFC4487MIPv6とファイアウォール2006年5月
Issue 2: The MN may be in a communication with a CN, or a CN may be
attempting to establish a connection with the MN. In both cases,
packets sent from the CN will be forwarded by the MN's HA to the
MN's CoA. However, when the packets arrive at the firewall(s),
the incoming traffic may not match any existing state, and the
firewall(s) may therefore drop it.
問題2: ミネソタがCNとのコミュニケーションにあるかもしれませんか、またはCNは、ミネソタと共に取引関係を築くのを試みているかもしれません。 どちらの場合も、CNから送られたパケットはミネソタのHAによってミネソタのCoAに送られるでしょう。 しかしながら、パケットがファイアウォールに到着するとき、入って来るトラフィックはしたがって(s)が止めるかもしれないどんな現状、およびファイアウォールにも合わないかもしれません。
Issue 3: If the MN is in a communication with a CN, the MN may
attempt to execute an RRT for packets to be route optimized.
Similarly to issue 3, Section 5.1, the Home Test message that
should be protected by ESP may be dropped by firewall(s)
protecting the MN. Firewall(s) may as a default rule drop any ESP
traffic. As a consequence, the RRT cannot be completed.
問題3: ミネソタがCNとのコミュニケーションにあるなら、ミネソタは、パケットが最適化されたルートであるためにRRTを実行するのを試みるかもしれません。 同様に、超能力によって保護されるべきであるホームTestメッセージを3、セクション5.1に発行するのは、ミネソタを保護しながら、ファイアウォールによって落とされるかもしれません。 省略時の解釈がどんな超能力交通も落とすのに従って、ファイアウォールはそうするかもしれません。 結果として、RRTは完成できません。
Issue 4: If the MN is in a communication with a CN, and assuming that
the MN successfully sent a Binding Update to its CN to use Route
Optimization, packets will then be sent from the CN to the MN's
CoA and from the MN's CoA to the CN.
問題4: Route Optimizationを使用するためにミネソタがCNと、それを仮定するとのミネソタが首尾よくCNへのBinding Updateを送ったコミュニケーションにあると、CNからミネソタのCoAまでミネソタのCoAからCNにパケットを送るでしょう。
Packets sent from the CN to the MN's CoA may, however, not match
any existing entry in the firewall(s) protecting the MN, and
therefore be dropped by the firewall(s).
しかしながら、CNからミネソタのCoAに送られたパケットは、ミネソタを保護しながらファイアウォールで少しの既存のエントリーにも合わないで、したがって、ファイアウォールによって落とされるかもしれません。
If packet filtering is applied to uplink traffic (i.e., traffic
sent by the MN), packets sent from the MN's CoA to the CN may not
match any entry in the firewall(s) either and may be dropped as
well.
パケットフィルタリングがアップリンク交通(すなわち、ミネソタによって送られた交通)に適用されるなら、ミネソタのCoAからCNに送られたパケットは、ファイアウォールの少しのエントリーにも合わないで、また、落とされるかもしれません。
6. Conclusions
6. 結論
Current firewalls may not only prevent route optimization but may also prevent regular TCP and UDP sessions from being established in some cases. This document describes some of the issues between the Mobile IPv6 protocol and current firewall technologies.
現在のファイアウォールは、いくつかの場合、通常のTCPとUDPセッションが確立されるのを経路最適化を防ぐだけではありませんが、また、防ぐかもしれません。 このドキュメントはモバイルIPv6プロトコルと現在のファイアウォール技術の間の問題のいくつかについて説明します。
This document captures the various issues involved in the deployment of Mobile IPv6 in networks that would invariably include firewalls. A number of different scenarios are described, which include configurations where the mobile node, correspondent node, and home agent exist across various boundaries delimited by the firewalls. This enables a better understanding of the issues when deploying Mobile IPv6 as well as the issues for firewall design and policies to be installed therein.
このドキュメントは不変的にファイアウォールを含んでいるネットワークにおける、モバイルIPv6の展開にかかわる様々な問題を得ます。 多くの異なったシナリオ(可動のノード、通信員ノード、および家のエージェントがファイアウォールによって区切られた様々な境界の向こう側に存在するところに構成を含んでいる)が説明されます。 ファイアウォールデザインと方針がそこにインストールされるために問題と同様にモバイルIPv6を配備するとき、これは問題の、より良い理解を可能にします。
Le, et al. Informational [Page 13] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[13ページ]のRFC4487MIPv6とファイアウォール2006年5月
7. Security Considerations
7. セキュリティ問題
This document describes several issues that exist between the Mobile IPv6 protocol and firewalls.
このドキュメントはモバイルIPv6プロトコルとファイアウォールの間に存在するいくつかの問題について説明します。
Firewalls may prevent Mobile IP6 signaling in addition to dropping incoming/outgoing traffic.
ファイアウォールは、入って来るか外向的な交通を落とすことに加えてモバイルIP6が合図するのを防ぐかもしれません。
If the firewall configuration is modified in order to support the Mobile IPv6 protocol but not properly configured, many attacks may be possible as outlined above: malicious nodes may be able to launch different types of denial of service attacks.
ファイアウォール構成がモバイルIPv6プロトコルをサポートするように変更されますが、適切に構成されないなら、多くの攻撃が以下の上に概説されているように可能であるかもしれません。 悪意があるノードは異なったタイプのサービス不能攻撃に着手できるかもしれません。
8. Acknowledgements
8. 承認
We would like to thank James Kempf, Samita Chakrabarti, Giaretta Gerardo, Steve Bellovin, Henrik Levkowetz, and Spencer Dawkins for their valuable comments. Their suggestions have helped improve both the presentation and the content of the document.
彼らの貴重なコメントについてジェームス・ケンフ、Samita Chakrabarti、Giarettaヘラルド、スティーブBellovin、Henrik Levkowetz、およびスペンサー・ダウキンズに感謝申し上げます。 彼らの提案は、プレゼンテーションとドキュメントの中身の両方を改良するのを助けました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[1] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
9.2. Informative References
9.2. 有益な参照
[2] Newman, D., "Benchmarking Terminology for Firewall Performance",
RFC 2647, August 1999.
[2] ニューマン、D.、「ファイアウォールパフォーマンスのためのベンチマーキング用語」、RFC2647、1999年8月。
[3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R.,
Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/
Firewall-1 Advanced Configuration and Troubleshooting", Syngress
Publishing Inc., 2003.
[3]貴族、J.、ダグ、D.、Hourihan、K.、Hourihan、K.、スティーブンズ、R.、スティーフェル、B.、Amon、A.、およびC.Tobkin、「検査点NG VPN-1/ファイアウォール-1は構成とトラブルシューティングを進めました」、Syngressが株式会社、2003を発行して。
[4] Chen, X., Rinne, J., Wiljakka, J., and M. Watson, "Problem
Statement for MIPv6 Interactions with GPRS/UMTS Packet
Filtering", Work in Progress, January 2006.
[4] チェン、X.、リンネ、J.、J.、およびM.ワトソン、「GPRS/UMTSパケットフィルタリングとのMIPv6相互作用のための問題声明」というWiljakkaは進行中(2006年1月)で働いています。
Le, et al. Informational [Page 14] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[14ページ]のRFC4487MIPv6とファイアウォール2006年5月
Appendix A. Applicability to 3G Networks
3Gネットワークへの付録A.の適用性
In 3G networks, different packet filtering functionalities may be implemented to prevent malicious nodes from flooding or launching other attacks against the 3G subscribers. The packet filtering functionality of 3G networks is further described in [4]. Packet filters are set up and applied to both uplink and downlink traffic: outgoing and incoming data not matching the packet filters is dropped. The issues described in this document also apply to 3G networks.
3Gネットワークでは、異なったパケットフィルタリングの機能性は、氾濫から悪意があるノードを防ぐために実行されるか、または3G加入者に対して他の攻撃に着手しているかもしれません。 3Gネットワークの機能性をフィルターにかけるパケットは[4]でさらに説明されます。 パケットフィルタは、アップリンクとダウンリンク交通の両方に準備させられて、適用されます: パケットフィルタに合っていない送受信のデータが落とされます。 また、本書では説明された問題は3Gネットワークに適用されます。
Authors' Addresses
作者のアドレス
Franck Le Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 USA
フランクLeカーネギーメロン大学5000フォーブズ・Avenue PA15213ピッツバーグ(米国)
EMail: franckle@cmu.edu
メール: franckle@cmu.edu
Stefano Faccin Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
ステファーノFaccinノキアResearch Center6000接続Driveテキサス75039アービング(米国)
EMail: sfaccinstd@gmail.com
メール: sfaccinstd@gmail.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000の接続Driveテキサス75039アービング(米国)
EMail: Basavaraj.Patil@nokia.com
メール: Basavaraj.Patil@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ミュンヘン、ハンネスTschofenigシーメンスオットーハーン一味6バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
メール: Hannes.Tschofenig@siemens.com ユリ: http://www.tschofenig.com
Le, et al. Informational [Page 15] RFC 4487 MIPv6 and Firewalls May 2006
Le、他 情報[15ページ]のRFC4487MIPv6とファイアウォール2006年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Le, et al. Informational [Page 16]
Le、他 情報[16ページ]
一覧
スポンサーリンク
