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
Multihoming for Small-Scale Fixed Networks
Using Mobile IP and Network Mobility (NEMO)
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).
著作権（C）IETFトラスト（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は、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
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（RFC 3775）およびネットワークモビリティ（; RFC 3963 NEMO）を使用して、両方のモバイルおよび固定ネットワーク環境のための共通のアーキテクチャを提案しています。複数の気付アドレス（のCoA）を使用することができるように提案されたアーキテクチャは、モバイルIPおよびNEMOの修正を必要とします。また、別の場所に位置している複数のホームエージェントは、（HAS）冗長性を確保するために必要とされています。
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を使用しますが、それはいくつかの問題があります。したがって、我々は小規模固定ネットワークのための[2] [1]及びNEMOモバイルIPを用いたマルチホームアーキテクチャを提案します。
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 Preference Settings
Oプリファレンスの設定値
Several multihoming technologies have been proposed so far. Conventional major multihoming networks use BGP, but it has some issues, as follows.
いくつかのマルチホーミング技術がこれまでに提案されています。従来の主要なマルチホーミングネットワークは、BGPを使用しますが、以下のように、それは、いくつかの問題があります。
(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へのアドレスブロックを宣伝する必要があります。マルチホーム利用者が一つだけ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を使用する従来のマルチホーミングアーキテクチャの場合には、着信トラフィックを制御することは容易ではありません。そのため、接続されたリンクの負荷分散が困難です。
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）とNEMOは、モバイルホストまたはモバイルネットワークのために提案されています。しかしながら、それらのアーキテクチャおよびプロトコルは、固定ネットワークのために使用することができ、上記の問題を解決します。溶液の詳細は以下のセクションに記載されています。
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とNEMOのプロトコルを使用して、ネットワーク運用のコストが低下します。モバイルIP環境でのユーザーのネットワークで使用するネットワークアドレスのプレフィックスは上流ISPのネットワークプレフィックスに依存しないようオフィスやネットワーク機器が再配置されている場合例えば、MIPおよびNEMOのアーキテクチャでは、IPアドレスをリナンバリングは、不要となります。
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.
その性質上、NEMOとモバイルIPは、マルチホーミングと協力しなければなりません。モバイルノードが無線リンクは常に安定していないため、ネットワーク接続の可用性を向上させるために複数のリンクを使用する必要があるためです。したがって、我々は、固定ノード（ルータとホスト）のためのマルチホーミングはNEMOとモバイル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 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は、基本的なマルチホーミングネットワークアーキテクチャを示しています。このアーキテクチャでは、マルチホームネットワークの境界ルータであるモバイルルータ（MR）は、複数のCoAを登録することによりMRとHAとの間のいくつかのトンネルを設定します。 HA（またはHAが属するルータ）は、ルーティングプロトコルを介してISPにユーザーのネットワークプレフィックス（図1のプレフィックスX）をアドバタイズ。 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
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が使用されるルートを選択します。ルート選択アルゴリズムは、この文書の範囲外のためです。これは、ユーザネットワークの可用性を向上させ、MRにISPから行くトラフィックを制御することができます。基本的なアーキテクチャでは、HA1は、単一障害点です。ユーザネットワークの可用性を向上させるためには、複数が必要とされています。これは、3.2節に記載されています。
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
Figure 2: Packet Forwarding by HA
図2：HAによるパケット転送
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.
複数の気付アドレスは、可用性を向上させるために、着信および発信トラフィックを制御するために必要とされます。現在のモバイルIPv6とNEMOベーシックサポートプロトコルは、複数の気付アドレスのホームエージェントにホームアドレスにバインドの登録を許可していません。そのため、[4]複数の気付アドレスの登録特定のホームアドレスのためにできるように、MIP6とNEMOベーシックサポートを拡張することを提案しています。
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を持っているすべてのネットワークは、それらに隣接するルータ/ネットワークに同じネットワークプレフィックスを通知すると、トラフィックは自動的にルーティングプロトコルトポロジの観点から最も近いホームエージェントにルーティングされます。この操作は、すでに内部ゲートウェイプロトコル（IGP）とエクステリアゲートウェイプロトコル（EGP）と、そのようなCDN（コンテンツ配信ネットワーク）などのWebサーバーアプリケーションの分野で働くことが証明されました。
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.
複数の有する動作させるために、全ての情報を結合するような同一の情報を持つ必要がありました。これは持っている間のデータベースを同期します。 HAHAプロトコル[5]は間結合の同期を導入します。これは、内部BGP（IBGP）と同じアーキテクチャです。データベースは、フルメッシュトポロジで同期されます。また、HAの操作を簡単にするために、データベースはスタートポロジーを使用して同期されます。これはIBGPルートリフレクタに類似しています。
sync
HA1 ------ HA2
| |
+-+----------+-+
| The Internet |
+-+----------+-+
| |
ISP-A ISP-B
| |
| |
+--- MR ---+
CoA1 | CoA2
|
-------+---------
Multihomed Network
Figure 3: Architecture with HA Redundancy
図3：HAの冗長性を持つアーキテクチャ
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:
この文書で提案されているマルチホームアーキテクチャは、基本的には、NEMOのアーキテクチャと同じです。さらに、NEMOプロトコルは、この文書に記載されている提案されたアーキテクチャの要件を満たします：
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をプロトコルは、CoAをホームアドレス（HoA）などの情報を送信するためにMRによって使用され、HA〜[4]一意識別子（BID）に結合することができます。
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プロトコルは、複数のサポートしており、複数が持っている間のバインディングキャッシュを同期させることができます。
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 architecture. Another solution is to propose a new protocol just like NEMO. Nevertheless, such a protocol would have functions just like those of NEMO.
提案されたマルチホームアーキテクチャは、NEMOのアプリケーションの一つとして、NEMOプロトコルを使用しています。言うまでもなく、NEMOプロトコルを使用して提案されたマルチホームアーキテクチャを達成するための解決策の一つです。別の解決策は、単にNEMOのような新しいプロトコルを提案することです。それにも関わらず、そのようなプロトコルは、ちょうどNEMOのもののような機能を持っているでしょう。
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事業者（マルチホームサービスプロバイダ）が導入されます。 xSP事業者は、概念のサービスプロバイダです。それはすべての実用的な目的のために、物理的にインターネットに接続する必要はありません。 xSP事業者は、一つ以上の集約モバイルネットワークプレフィックスを持っています。物理的にインターネットに接続されているいくつかのISPとxSP事業者との契約。この契約の目的は、いくつかは、これらのISPのネットワークにしている設定です。これらは、xSPの集約モバイルネットワークプレフィックスを発表しました。これは、それはちょうどボーダーゲートウェイルータのような仕事をしたことを意味し、このような状況は、ISPとxSP事業者の間でピアリングと同じです。この場合、自律システム（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.
複数のルートからの発表のこのモデルは、従来のスケーラブルなインターネットアーキテクチャと互換性があり、それは、スケーラビリティの問題を持っていません。
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ケアの各組織のアドレスを持っています。 MRはHAに気付アドレスを登録するために、複数の-CoAオプションを使用しています。
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.
この文書では、複数のCoAの要件について説明し、冗長性を持っています。要件を解決するためにMIPとNEMOのプロトコルを向上させる必要があります。これらのマルチホーミングネットワークのセキュリティに関する注意事項は、各プロトコルの仕様に考慮されなければなりません。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、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、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[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.、およびT.ノエル、 "マルチホーミングの目標と利点"、進行中で働いて、 2004年2月。
[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", Work in Progress, March 2007.
[4] Wakikawa、R.、エルンスト、T.、およびK.永見、 "複数の気付アドレスの登録" の進捗状況、2007年3月に、仕事。
[5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home Agents Protocol (HAHA)", Work in Progress, February 2004.
[5] Wakikawa、R.、Thubert、P.、およびV. Devarapalli、 "インターホームエージェントプロトコル（HAHA）"、進歩、2004年2月に作業。
Authors' Addresses
著者のアドレス
Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo 135-0075 Japan
けにち ながみ いんてＣ ねｔこれ いんｃ。 １ー３ー３、 しんーすな ことーく、 ときょ １３５ー００７５ じゃぱん
Phone: +81-3-5565-5069 Fax: +81-3-5565-5094 EMail: nagami@inetcore.com
電話：+ 81-3-5565-5069ファックス：+ 81-3-5565-5094 Eメール：nagami@inetcore.com
Satoshi Uda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 Japan
さとし うだ じゃぱん あｄゔぁんせｄ いんｓちつて おｆ Ｓしえんせ あんｄ てｃｈのぉｇｙ １ー１ あさひだい のみ、 いしかわ ９２３ー１２９２ じゃぱん
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
のぶお おがしわ ねとぉｒｋ おりえんてｄ そｆとぁれ いんｓちつて、 いんｃ。 １９０ー２、 よしい、 よしい、 たの、 ぐんま ３７０ー２１３２ じゃぱん
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
ひろし えさき てぇ うにゔぇｒしｔｙ おｆ ときょ ７ー３ー１ ほんご ぶんきょーく、 ときょ １１３ー８６５６ じゃぱん
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
りゅじ わきかわ けいお うにゔぇｒしｔｙ でぱｒｔめんｔ おｆ えんゔぃろんめんたｌ いんふぉｒまちおん、 けいお うにゔぇｒしｔｙ。 ５３２２ えんど ふじさわ、 かながわ ２５２ー８５２０ じゃぱん
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ファックス：+ 81-466-49-1395 Eメール：ryuji@sfc.wide.ad.jp URI：http://www.wakikawa.org/
Hiroyuki Ohnishi NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan
ひろゆき おｈにし んっｔ こｒぽらちおん ９ー１１、 みどりーちょ、 ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
メールアドレス：ohnishi.hiroyuki@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に及び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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。