[要約] RFC 4908は、モバイルIPとNEMOを使用した小規模固定ネットワークのマルチホーミングに関する要約と目的を提供しています。
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)
モバイルIPとネットワークモビリティ（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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）とネットワークモビリティ（NEMO; RFC 3963）を使用して、モバイルと固定ネットワーク環境の両方の共通アーキテクチャを提案しています。提案されたアーキテクチャでは、複数のアドレス（COA）を使用できるように、モバイルIPとNEMOの変更が必要です。さらに、異なる場所にある複数のホームエージェント（持っている）は、冗長性に必要です。
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]とNEMO [2]を使用してマルチホームアーキテクチャを提案します。
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 設定設定
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にアドレスブロックを宣伝する必要があります。Multihomedユーザーが1つのISPのみに接続する場合、ISPはルーティング情報を宣伝してそれらを集約することができます。しかし、一部のマルチホームユーザーは、ISP障害に備えるために、異なるISPと接続する必要があります。この場合、ISPは集約なしでマルチホームユーザーのルーティング情報を宣伝する必要があります。したがって、インターネット内のルーティングエントリの数は1つずつ増加しています。
(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のアーキテクチャとプロトコルを使用することにより、ネットワーク操作のコストが削減されます。たとえば、MIPとNEMOのアーキテクチャでは、モバイルIP環境でユーザーネットワークが使用するネットワークアドレスのプレフィックスは、アップストリームISPのネットワークのプレフィックスに依存しないため、オフィスまたはネットワーク機器の移動時に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に属するルーター）は、ルーティングプロトコルを介してユーザーのネットワークプレフィックス（図1のプレフィックスx）をISPに宣伝します。HAに複数のマルチホームネットワーク（図1のプレフィックスXとY）がある場合、ISPSの集計されたネットワークプレフィックスを宣伝できます。したがって、マルチホームユーザーの数が増加した場合、インターネットルーティングエントリは1つずつ増加しません。
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が使用されるルートを選択します。ルート選択アルゴリズムは、このドキュメントの範囲用にリリースされています。これにより、ユーザーネットワークの可用性が向上し、ISPからMRへのトラフィックを制御できます。基本的なアーキテクチャでは、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 Basic Support Protocolでは、ホームエージェントへのホームアドレスにバインドされた複数のケアのケアの登録を許可していません。したがって、[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が隣接するルーター/ネットワークに同じネットワークプレフィックスを宣伝するすべてのネットワークが、ルーティングプロトコルトポロジの観点から、トラフィックが自動的に最も近いホームエージェントにルーティングされます。この操作は、Interior Gateway Protocol（IGP）およびExterior Gateway Protocol（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.
複数の操作を行うには、すべてが拘束力のある情報などの同じ情報を持っている必要があります。これにより、HASのデータベースが同期されます。HAHAプロトコル[5]は、HASの間で結合同期を導入します。これは、内部BGP（IBGP）と同じアーキテクチャです。データベースは、フルメッシュトポロジによって同期されています。さらに、HAの動作を簡素化するために、データベースはSTARトポロジを使用して同期されます。これは、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 プロトコルは、MRがCOA、ホームアドレス（HOA）、バインディングユニークな識別子（BID）[4]などの情報をHAに送信するために使用できます。
o The protocol can establish multiple tunnels between the MR and HA.
o
o The protocol supports multiple HAs and can synchronize Binding Caches among multiple HAs.
o プロトコルは、複数のHASをHASと同期する複数のHASをサポートします。
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のアプリケーションの1つとして使用しています。言うまでもなく、NEMOプロトコルを使用することは、提案されているMultihomeアーキテクチャを達成するためのソリューションの1つです。別の解決策は、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には、1つ以上の集計可能なモバイルネットワークのプレフィックスがあります。XSPは、インターネットに物理的に接続されている一部のISPと契約します。この契約の目的は、ISPSのネットワークにあるものを設定することです。これらは、XSPの集約されたモバイルネットワークのプレフィックスを発表しました。これは、それが境界ゲートウェイルーターのように機能することを意味し、この状況はISPとXSPの間の覗き見と同じです。この場合、HASから発表された起源の自律システム（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からのルートアナウンスのこのモデルは、従来のスケーラブルなインターネットアーキテクチャと互換性があり、スケーラビリティの問題はありません。
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は、複数COAオプションを使用して、住所のケアをHAに登録します。
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のプロトコルを強化する必要があります。これらのマルチホームネットワークのセキュリティ上の考慮事項は、各プロトコルの仕様で考慮する必要があります。
7.1. Normative References
7.1. 引用文献
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、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] Ernst、T.、Montavont、N.、Wakikawa、R.、Paik、E.、Ng、C.、Kuladinithi、K。、およびT. Noel、「Multihomingの目標と利益」、2004年2月の作業。
[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", Work in Progress, March 2007.
[4] Wakikawa、R.、Ernst、T。、およびK. Nagami、「複数のアドレス対応登録」、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、「Inter Home Agents Protocol（HAHA）」、Work in Progress、2004年2月。
Authors' Addresses
著者のアドレス
Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo 135-0075 Japan
kenichi nagami intec netcore Inc. 1-3-3、shin-suna koto-ku、東京135-0075日本
Phone: +81-3-5565-5069 Fax: +81-3-5565-5094 EMail: nagami@inetcore.com Satoshi Uda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 Japan
電話：81-3-5565-5069 FAX：81-3-5565-5094メール：nagami@inetcore.com satoshi uda日本先進科学技術研究所
EMail: zin@jaist.ac.jp
Nobuo Ogashiwa Network Oriented Software Institute, Inc. 190-2, Yoshii, Yoshii, Tano, Gunma 370-2132 Japan
Nobuo ogashiwa Network arireed Software Institute、Inc。190-2、Yoshii、Yoshii、Tano、Gunma 370-2132 Japan
EMail: ogashiwa@noware.co.jp
Hiroshi Esaki The University of Tokyo 7-3-1 Hongo Bunkyo-ku, Tokyo 113-8656 Japan
東京大学大usaki 7-3-1ホンゴ・ブンキオ・クー、東京113-8656日本
EMail: hiroshi@wide.ad.jp
Ryuji Wakikawa Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
キオ大学環境情報学部和川川沿いの大学。5322藤沢内、金沢252-8520日本
Phone: +81-466-49-1100
Fax: +81-466-49-1395
EMail: 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
Hiroyuki ohnishi ntt Corporation 9-11、Midori-cho、3-Chome Musashino-Shi、Tokyo 180-8585 Japan
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。