RFC4908 日本語訳
4908 Multi-homing for small scale fixed network Using Mobile IP andNEMO. K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H.Ohnishi. June 2007. (Format: TXT=20230 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Nagami
Request for Comments: 4908 INTEC NetCore
Category: Experimental S. Uda
JAIST
N. Ogashiwa
NOWARE, Inc.
H. Esaki
University of Tokyo
R. Wakikawa
Keio University
H. Ohnishi
NTT
June 2007
Nagamiがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4908年のインテックNetCoreカテゴリ: 実験的なS.のWakikawa慶応義塾大学H.Ohnishi NTT宇田JAIST N.Ogashiwa NOWARE Inc.H.江崎東京大学R.2007年6月
Multihoming for Small-Scale Fixed Networks
Using Mobile IP and Network Mobility (NEMO)
モバイルIPとネットワークの移動性を使用する小規模の固定ネットワークのためのマルチホーミング(ネモ)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
IETF Note
IETF注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配布しているプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実装と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Nagami, et al. Experimental [Page 1] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[1ページ]RFC4908マルチホーミング
Abstract
要約
Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy.
マルチホーミング技術はホストとネットワークの接続性の有用性を改良します。 修理されてモバイルのネットワークの振舞いが異なるので、それぞれのための異なったアーキテクチャは、議論して、提案されました。 このドキュメントはモバイルの、そして、固定の両方にされたネットワーク環境のために一般的なアーキテクチャを提案します、モバイルIP(RFC3775)とNetwork Mobility(ネモ; RFC3963)を使用して。 提案されたアーキテクチャは、Addresses(CoAs)の複数のCareを使用できるようにモバイルIPとネモの変更を必要とします。 さらに、異なった場所に位置している複数のホームのエージェント(HAs)が冗長に必要です。
1. Motivation
1. 動機
Users of small-scale networks need an easy method to improve network availability and to load balance several links. Multihoming technology is one of the solutions to improve availability. Conventional major multihoming networks use BGP, but it has some issues. Therefore, we propose a multihoming architecture using mobile IP [1] and NEMO [2] for small-scale fixed networks.
小規模のネットワークのユーザはネットワークの有用性を改良する簡易法を必要とします、そして、バランスをロードするために、数個がリンクされます。 マルチホーミング技術は有用性を改良するソリューションの1つです。 従来の主要なマルチホーミングネットワークはBGPを使用しますが、それには、いくつかの問題があります。 したがって、私たちは、小規模の固定ネットワークにモバイルIP[1]とネモ[2]を使用することでマルチホーミングアーキテクチャを提案します。
1.1. General Benefits of Multihoming
1.1. マルチホーミングの一般利益
In a multihoming network environment, both users and network managers benefit from controlling outgoing traffic, incoming traffic, or both of them. Those benefits are described in "Goals and Benefits of Multihoming" [3]. The following is a summary of those goals and benefits:
マルチホーミングネットワーク環境で、ユーザとネットワークマネージャの両方がそれらの外向的なトラフィックを制御するか、入って来るトラフィック、または両方の利益を得ます。 それらの利益は「マルチホーミングの目標と利益」[3]で説明されます。 ↓これはそれらの目標と利益の概要です:
o Ubiquitous Access
o 遍在しているアクセス
o Redundancy/Fault-Recovery
o 欠点冗長/回復
o Load Sharing
o 負荷分割法
o Load Balancing
o ロードバランシング
o Bi-casting
o 両性愛者のキャスティング
o Preference Settings
o 好みの設定
1.2. Problems to be Solved to Accomplish Multihoming
1.2. Accomplish MultihomingへのSolvedである問題
Several multihoming technologies have been proposed so far. Conventional major multihoming networks use BGP, but it has some issues, as follows.
いくつかのマルチホーミング技術が今までのところ、提案されました。 従来の主要なマルチホーミングネットワークはBGPを使用しますが、それには、以下のいくつかの問題があります。
Nagami, et al. Experimental [Page 2] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[2ページ]RFC4908マルチホーミング
(1) Increasing route entries in the Internet
(1) インターネットの増加するルートエントリー
In the multihoming environments, each user's network needs to
advertise its address block to all ISPs connected to them. If a
multihomed user connects to only one ISP, the ISP can advertise
routing information to aggregate them. But some multihomed users
need to connect with different ISPs to be prepared for ISP
failure. In this case, ISPs need to advertise routing information
for multihomed users without aggregation. Therefore, the number
of routing entries in the Internet is increasing one by one.
マルチホーミング環境で、各ユーザのネットワークは、それらに接続されたすべてのISPにあて先ブロックの広告を出す必要があります。 「マルチ-家へ帰」っているユーザが1つのISPだけに接続するなら、ISPは、それらに集めるためにルーティング情報の広告を出すことができます。 しかし、或るものはISP失敗のために準備される異なったISPに接続するユーザの必要性を「マルチ-家へ帰」らせました。 この場合、ISPは、「マルチ-家へ帰」っているユーザのために集合なしでルーティング情報の広告を出す必要があります。 したがって、インターネットのルーティングエントリーの数はひとつずつ増加しています。
(2) Difficulty of using multiple links efficiently
(2) 効率的に複数のリンクを使用するという困難
It is not easy to control incoming traffic in the case of the
conventional multihoming architecture using BGP. Therefore, load
balancing of connected links is difficult.
BGPを使用する従来のマルチホーミングアーキテクチャの場合で入って来るトラフィックを制御するのは簡単ではありません。 したがって、接続リンクのロードバランシングは難しいです。
1.3. Using the Architecture of Mobile IP and NEMO to Solve the Problems
1.3. 問題を解決するのにモバイルIPとネモのアーキテクチャを使用します。
Basically, mobile IP (MIP) and NEMO have been proposed for mobile hosts or mobile networks; however, their architecture and protocol can be used for fixed networks and to solve the problems mentioned above. The details of the solution are described in the sections below.
基本的に、モバイルIP(MIP)とネモはモバイルホストかモバイルネットワークのために提案されました。 しかしながら、固定ネットワーク、前記のように問題を解決するのにそれらのアーキテクチャとプロトコルを使用できます。 ソリューションの詳細は下のセクションで説明されます。
Moreover, by using the architecture and the protocol of MIP and the NEMO, the cost of network operation will be decreased. For instance, in the architecture of MIP and NEMO, renumbering IP addresses when office or network equipment is relocated becomes unnecessary, as the network address prefix used by a user network in a mobile IP environment does not depend on the upstream ISP's network prefix.
そのうえ、MIPとネモのアーキテクチャとプロトコルを使用することによって、ネットワーク操作の費用は下がるでしょう。 例えば、オフィスかネットワーク装置が移動するときMIPとネモのアーキテクチャでIPアドレスに番号を付け替えさせるのは不要になります、モバイルIP環境でユーザネットワークによって使用されたネットワーク・アドレス接頭語が上流のISPのネットワーク接頭語によらないとき。
2. Multihoming Architecture Using Mobile IP and NEMO
2. モバイルIPとネモを使用するマルチホーミングアーキテクチャ
2.1. Mobile Network Includes Fixed Network
2.1. モバイルネットワークは固定ネットワークを含んでいます。
By their nature, NEMO and mobile IP must work with multihoming. This is because mobile nodes need to use multiple links to improve the availability of network connectivity since the wireless link is not always stable. Therefore, we propose that multihoming for fixed nodes (routers and hosts) uses the framework of NEMO and mobile IP.
本質的に、ネモとモバイルIPはマルチホーミングで働かなければなりません。 これはモバイルノードが、ワイヤレスのリンクがいつも安定しているというわけではないのでネットワークの接続性の有用性を改良するのに複数のリンクを使用する必要があるからです。 したがって、私たちは、固定ノード(ルータとホスト)のためのマルチホーミングがネモとモバイルIPのフレームワークを使用するよう提案します。
2.2. Overview of Multihoming Network Architecture Using Mobile IP
2.2. モバイルIPを使用するマルチホーミングネットワークアーキテクチャの概要
Figure 1 shows the basic multihoming network architecture. In this architecture, a mobile router (MR), which is a border router of the multihomed network, sets up several tunnels between the MR and the HA by multiple-CoA registration. An HA (or a router to which the HA
図1は基本的なマルチホーミングネットワークアーキテクチャを示しています。 このアーキテクチャでは、モバイルルータ(MR)は複数のCoA登録でMRとHAの間のいくつかのトンネルを設立します。(それは、「マルチ-家へ帰」っているネットワークの境界ルータです)。 HA、(ルータ、どれ、HA
Nagami, et al. Experimental [Page 3] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[3ページ]RFC4908マルチホーミング
belongs) advertises the user's network prefix (Prefix X in Figure 1) to ISPs via the routing protocol. If the HA has several multihomed networks (Prefix X and Y in Figure 1), they can advertise an aggregated network prefix to ISPs. Therefore, the Internet routing entries do not increase one by one when the number of multihomed users is increased.
属、)、ルーティング・プロトコルでユーザのネットワーク接頭語(図1の接頭語X)のISPに広告を出します。 HAにいくつかの「マルチ-家へ帰」っているネットワーク(図1の接頭語XとY)があるなら、それらは集められたネットワーク接頭語のISPに広告を出すことができます。 したがって、「マルチ-家へ帰」っているユーザの数が増強されるとき、インターネット・ルーティングエントリーはひとつずつ増加しません。
HA1
||(Advertise aggregated prefix X and Y)
|v
ISP
|
+------------------------+---------------------+
| The Internet |
+-+----------+--------------------+----------+-+
| | | |
ISP-A ISP-B ISP-A' ISP-B'
| | | |
| | | |
+--- MR ---+ +--- MR ---+
CoA1 | CoA2 CoA1|CoA2
| |
-------+--------- (Prefix X) -------+------ (Prefix Y)
Multihomed Network X Multihomed Network Y
HA1||(集められた接頭語XとYの広告を出します) |ISPに対して| +------------------------+---------------------+ | インターネット| +-+----------+--------------------+----------+-+ | | | | ISP'A ISP B ISP A'ISP B'| | | | | | | | +--- さん---+ +--- さん---+ CoA1| CoA2 CoA1|CoA2| | -------+--------- (接頭語X) -------+------ (接頭語Y) ネットワークX MultihomedネットワークYをMultihomedしました。
Figure 1: Advertisement of aggregated prefixes
図1: 集められた接頭語の広告
Packets to multihomed users go to the HA, and the HA sends packets to the MR using CoA1 and CoA2. The HA selects a route in which a CoA is used. The route selection algorithm is out for scope of this document. This can improve the availability of the user network and control traffic going from the ISP to the MR. In the basic architecture, HA1 is the single point of failure. In order to improve the availability of the user network, multiple HAs are needed. This is described in Section 3.2.
「マルチ-家へ帰」っているユーザへのパケットはHAに行きます、そして、HAはCoA1とCoA2を使用することでパケットをMRに送ります。 HAはCoAが使用されているルートを選択します。 このドキュメントの範囲にはルート選択アルゴリズムがあります。 これはISPからMRまで行くユーザネットワークとコントロールトラフィックの有用性を改良できます。基本的なアーキテクチャでは、HA1は失敗の単一のポイントです。 ユーザネットワークの有用性を改良するために、複数のHAsが必要です。 これはセクション3.2で説明されます。
Nagami, et al. Experimental [Page 4] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[4ページ]RFC4908マルチホーミング
HA1
^ | |
(1) Packets to prefix X | | | (2) HA forwards the packets
are sent to HA | | v to CoA1 or CoA2
+-------+------+
| The Internet |
+-+----------+-+
| |
| | |(3) Packets are forwarded over
| | | the MIP tunnel selected by
| | v the HA1
ISP-A ISP-B
| | |
| | |
+--- MR ---+ v
CoA1 | CoA2
|
-------+--------- (Prefix X)
Multihomed Network A
HA1^| | (1) Xを前に置くパケット| | | (2) パケットがHAに送られるHAフォワード| | CoA1かCoA2+へのv-------+------+ | インターネット| +-+----------+-+ | | | | |(3) パケットを進めます。| | | 選択されたMIPトンネル| | HA1 ISP-A ISP Bに対して| | | | | | +--- さん---+ CoA1に対して| CoA2| -------+--------- (接頭語X) ネットワークAをMultihomedしました。
Figure 2: Packet Forwarding by HA
図2: 進められるパケット、ハ。
3. Requirements for Mobile IP and NEMO
3. モバイルIPとネモのための要件
3.1. Multiple Care-of-Addresses (CoAs)
3.1. アドレスの複数の注意(CoAs)
Multiple Care-of-Addresses are needed to improve the availability and to control incoming and outgoing traffic. The current Mobile IPv6 and the NEMO Basic Support protocol does not allow registration of more than one Care-of Address bound to a home address to the home agent. Therefore, [4] proposes to extend MIP6 and NEMO Basic Support to allow multiple Care-of Address registrations for the particular home address.
アドレスの複数のCareが、有用性を改良して、送受信のトラフィックを制御するのに必要です。 現在のモバイルIPv6とBasic Supportプロトコルがするネモが1以上の登録を許さない、Care、-、Addressはホームのエージェントへのホームアドレスにバウンドしています。 したがって、[4]が、倍数を許容するためにMIP6とネモBasic Supportを広げるよう提案する、Care、-、特定のホームアドレスのためのAddress登録証明書。
3.2. Multiple Home Agents
3.2. 複数のホームのエージェント
Multiple Home Agents should be geographically distributed across the Internet to improve service availability and for the load balancing of the HA. When all the networks that have HA advertise the same network prefix to their adjacent router/network, the traffic is automatically routed to the nearest Home Agent from the viewpoint of routing protocol topology. This operation has already been proven to work in the area of Web server applications, such as CDN (Contents Delivery Network), with the Interior Gateway Protocol (IGP) and Exterior Gateway Protocol (EGP).
複数のホームのエージェントがサービスの有用性を改良するインターネットの向こう側にHAのロードバランシングように地理的に分配されるべきです。 HAを持っているすべてのネットワークがそれらの隣接しているルータ/ネットワークに同じネットワーク接頭語の広告を出すとき、トラフィックはルーティング・プロトコルトポロジーの観点から最も近いホームのエージェントに自動的に発送されます。 この操作がウェブサーバ・アプリケーションの領域で働くと既に立証されました、CDN(コンテンツDelivery Network)などのように、Interiorゲートウェイプロトコル(IGP)とExteriorゲートウェイプロトコル(EGP)で。
Nagami, et al. Experimental [Page 5] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[5ページ]RFC4908マルチホーミング
In order to operate multiple HAs, all HAs must have the same information such as binding information. This synchronizes the databases among the HAs. The HAHA protocol [5] introduces the binding synchronization among HAs. This is the same architecture as Internal BGP (IBGP). The database is synchronized by full-mesh topology. In addition, in order to simplify operation of the HA, the database is synchronized using star topology. This is analogous to the IBGP route reflector.
複数のHAsを操作するために、すべてのHAsには拘束力がある情報などの同じ情報がなければなりません。 これはHAsの中でデータベースを同期させます。 HAHAプロトコル[5]は拘束力がある同期をHAsに紹介します。 これはInternal BGP(IBGP)と同じアーキテクチャです。 データベースは完全なメッシュトポロジーによって同期させられます。 さらに、HAの操作を簡素化するために、データベースはスタートポロジーを使用することで同期します。 これはIBGPルート反射鏡に類似しています。
sync
HA1 ------ HA2
| |
+-+----------+-+
| The Internet |
+-+----------+-+
| |
ISP-A ISP-B
| |
| |
+--- MR ---+
CoA1 | CoA2
|
-------+---------
Multihomed Network
同時性HA1------ HA2| | +-+----------+-+ | インターネット| +-+----------+-+ | | ISP A ISP B| | | | +--- さん---+ CoA1| CoA2| -------+--------- ネットワークをMultihomedしました。
Figure 3: Architecture with HA Redundancy
図3: アーキテクチャ、ハ、冗長
4. Discussion on the Mailing List
4. メーリングリストについての議論
4.1. Why the Proposed Architecture Uses NEMO Protocols
4.1. 提案されたアーキテクチャがネモProtocolsを使用する理由
The multihomed architecture proposed in this document is basically the same as the architecture of NEMO. Furthermore, NEMO protocols meet the requirements of the proposed architecture in this document, which are:
本書では提案された「マルチ-家へ帰」っているアーキテクチャはネモのアーキテクチャと基本的に同じです。 その上、ネモプロトコルはこのドキュメントの提案されたアーキテクチャに関する必要条件を満たします。(必要条件は以下の通りです)。
o The protocol can be used by the MR to send information such as the
CoA, Home Address (HoA), and Binding Unique Identifier (BID) [4]
to the HA.
o MRは、CoA、ホームAddressなどの情報(HoA)、およびBinding Unique Identifier(BID)[4]をHAに送るのにプロトコルを使用できます。
o The protocol can establish multiple tunnels between the MR and HA.
o プロトコルはMRとHAの間の複数のトンネルを確立できます。
o The protocol supports multiple HAs and can synchronize Binding
Caches among multiple HAs.
o プロトコルは、複数のHAsをサポートして、複数のHAsの中でBinding Cachesを連動させることができます。
The proposed multihomed architecture uses NEMO protocols as one of the applications of NEMO. Needless to say, using the NEMO protocol is one of the solutions to accomplish the proposed multihome
提案された「マルチ-家へ帰」っているアーキテクチャはネモのアプリケーションの1つとしてネモプロトコルを使用します。 言うまでもなく、ネモプロトコルを使用して、ソリューションの1つは提案された「マルチ-ホーム」を達成することになっていますか?
Nagami, et al. Experimental [Page 6] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[6ページ]RFC4908マルチホーミング
architecture. Another solution is to propose a new protocol just like NEMO. Nevertheless, such a protocol would have functions just like those of NEMO.
アーキテクチャ。 他の解決法はまさしくネモのような新しいプロトコルを提案することです。 それにもかかわらず、そのようなプロトコルには、まさしくネモのもののような機能があるでしょう。
4.2. Route Announcement from Geographically Distributed Multiple HAs
4.2. 地理的に分配された倍数からのルート発表はそうしました。
In the proposed architecture, the xSP (Multihomed Service Provider) is introduced. The xSP is a conceptual service provider; it doesn't have to be connected to the Internet physically for all practical purposes. xSP has one or more aggregatable mobile network prefixes. xSP contracts with some ISPs that are physically connected to the Internet. The purpose of this contract is to set up some HAs in those ISPs' networks. Those HAs announce the xSP's aggregated mobile network prefixes. This means that HAs work just like border gateway routers, and this situation is the same as peering between the ISP and xSP. In this case, the origin Autonomous System (AS) announced from the HAs is the xSP.
提案されたアーキテクチャでは、xSP(Multihomed Service Provider)を導入します。 xSPは概念的なサービスプロバイダーです。 それは物理的に実際上はインターネットに関連づけられる必要はありません。xSPには、1つ以上の「集合-可能」モバイルネットワーク接頭語物理的にインターネットに関連づけられるいくつかのISPとのxSP契約があります。 この契約の目的はそれらのISPのネットワークにおけるいくつかのHAsをセットアップすることです。 それらのHAsは、xSPがモバイルネットワーク接頭語に集めたと発表します。 これは、HAsがまさしく境界ゲートウェイルータのように働いていることを意味します、そして、この状況はISPとxSPの間をじっと見るのと同じです。 この場合、HAsから発表された発生源Autonomous System(AS)はxSPです。
On the other hand, a multihomed user (a small office user or home user) contracts with the xSP to acquire a mobile network prefix from the xSP. Each multihomed user has an MR and multiple L3 connectivity to the Internet via multiple ISPs, and the MR will establish multiple tunnels to the HA. Since the user's mobile network prefixes are aggregated and announced from the HA, the packets to the user's mobile network will be sent to the nearest HA depending on global routing information at that time. The HA that received such packets will forward them to the user's network over the established multiple tunnels.
他方では、「マルチ-家へ帰」っているユーザ(小さいオフィスユーザか家庭でのユーザ)は、xSPと共にxSPからモバイルネットワーク接頭語を習得するのを契約します。 それぞれの「マルチ-家へ帰」っているユーザは複数のISPでMRと複数のL3の接続性をインターネットに持っています、そして、MRは複数のトンネルをHAに確立するでしょう。 ユーザのモバイルネットワーク接頭語がHAから集められて、発表されるので、その時グローバルなルーティング情報による最も近いHAにユーザのモバイルネットワークへのパケットを送るでしょう。 パケットがそれらを送るそのようなものをユーザのネットワークに受けたHAは確立した倍数の上でトンネルを堀ります。
This model of route announcement from multiple HAs is compatible with the conventional scalable Internet architecture, and it doesn't have scalability problems.
複数のHAsからのルート発表のこのモデルは従来のスケーラブルなインターネットアーキテクチャと互換性があります、そして、それには、スケーラビリティ問題がありません。
5. Implementation and Experimentation
5. 実装と実験
We have implemented and experimented with the proposed architecture. Currently, the system works well not only on our test-bed network, but on the Internet. In our experimentation, the MR has two upstream organizations (ISPs) and two Care-of Addresses for each organization. The MR uses the multiple-CoA option to register the Care-of Addresses to the HA.
私たちは、提案されたアーキテクチャを実装して、実験しました。 現在、システムは私たちのテストベッドネットワークでうまくいくだけではなく、インターネットでもうまくいきます。 私たちの実験では、MRが2つの上流の組織(ISP)と2を持っている、Care、-、各組織のためのAddresses。 MRが登録するのに複数のCoAオプションを使用する、Care、-、HAへのAddresses。
Nagami, et al. Experimental [Page 7] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[7ページ]RFC4908マルチホーミング
6. Security Considerations
6. セキュリティ問題
This document describes requirements of multiple CoAs and HAs for redundancy. It is necessary to enhance the protocols of MIP and NEMO to solve the requirements. Security considerations of these multihoming networks must be considered in a specification of each protocol.
このドキュメントは冗長のために複数のCoAsとHAsの要件について説明します。 プロトコルを高めるために、MIPとネモが要件を解決しに必要です。 それぞれのプロトコルの仕様でこれらのマルチホーミングネットワークのセキュリティ問題を考えなければなりません。
7. References
7. 参照
7.1. Normative References
7.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月の移動性サポート。」
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
7.2. Informative References
7.2. 有益な参照
[3] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C.,
Kuladinithi, K., and T. Noel, "Goals and Benefits of
Multihoming", Work in Progress, February 2004.
[3] エルンスト、T.、Montavont、N.、Wakikawa、R.、パク、E.、ウン、C.、Kuladinithi、K.、およびクリスマスと、「マルチホーミングの目標と利益」が進歩、2004年2月に働かせるT.。
[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration", Work in Progress, March 2007.
[4]Wakikawa、R.、エルンスト、T.、およびK.Nagami、「複数、注意、-、登録を扱う、」、3月2007、進行中で、働いてください。
[5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home
Agents Protocol (HAHA)", Work in Progress, February 2004.
[5] R.、Thubert、P.、およびV.Devarapalli、「間のホームエージェントプロトコル(ハハハ)」というWakikawaは進歩、2004年2月に働いています。
Authors' Addresses
作者のアドレス
Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo 135-0075 Japan
健一NagamiインテックNetCore Inc.1-3-3、江東区、向こうずね-suna日本東京135-0075
Phone: +81-3-5565-5069 Fax: +81-3-5565-5094 EMail: nagami@inetcore.com
以下に電話をしてください。 +81-3-5565-5069 Fax: +81-3-5565-5094 メールしてください: nagami@inetcore.com
Nagami, et al. Experimental [Page 8] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[8ページ]RFC4908マルチホーミング
Satoshi Uda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 Japan
Satoshi宇田北陸先端科学技術大学院大学1-1Asahidai能美、日本の石川923-1292
EMail: zin@jaist.ac.jp
メール: zin@jaist.ac.jp
Nobuo Ogashiwa Network Oriented Software Institute, Inc. 190-2, Yoshii, Yoshii, Tano, Gunma 370-2132 Japan
Nobuo Ogashiwaは指向のソフトウェア研究所Inc.190-2、芳井、芳井、Tano、日本群馬370-2132をネットワークでつなぎます。
EMail: ogashiwa@noware.co.jp
メール: ogashiwa@noware.co.jp
Hiroshi Esaki The University of Tokyo 7-3-1 Hongo Bunkyo-ku, Tokyo 113-8656 Japan
Hiroshi江崎東京大学7-3-1Hongo文京区、日本東京113-8656
EMail: hiroshi@wide.ad.jp
メール: hiroshi@wide.ad.jp
Ryuji Wakikawa Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
環境情報の龍治Wakikawa慶応義塾大学部、慶応義塾大学。 5322 藤沢の遠藤、日本神奈川252-8520
Phone: +81-466-49-1100 Fax: +81-466-49-1395 EMail: ryuji@sfc.wide.ad.jp URI: http://www.wakikawa.org/
以下に電話をしてください。 +81-466-49-1100 Fax: +81-466-49-1395 メールしてください: ryuji@sfc.wide.ad.jp ユリ: http://www.wakikawa.org/
Hiroyuki Ohnishi NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan
ヒロユキOhnishi NTT社の9-11テロ、美土里町、3丁目の武蔵野市、日本東京180-8585
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
メール: ohnishi.hiroyuki@lab.ntt.co.jp
Nagami, et al. Experimental [Page 9] RFC 4908 Multihoming for Fixed Network June 2007
Nagami、他 固定ネットワーク2007年6月のための実験的な[9ページ]RFC4908マルチホーミング
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nagami, et al. Experimental [Page 10]
Nagami、他 実験的[10ページ]
一覧
スポンサーリンク
