この文書はRFC3258の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group T. Hardie Request for Comments: 3258 Nominum, Inc. Category: Informational April 2002 Distributing Authoritative Name Servers via Shared Unicast Addresses 共有ユニキャストアドレスによる分散権威ネームサーバ 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 (2002). All Rights Reserved. Abstract 概要 This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. このメモは正式なネームサーバオペレーターが多数の場所で１つのネーム サーバーへのアクセスを供給を意図する習慣を記述します。これらの習慣 の開発と展開のための主要な動機はネットワークトポロジーによりサポー トされていないエリアにドメインネームシステム（ＤＮＳ）サーバの展開 を増やし、それらのエリアでＤＮＳ問合せ回答の遅延を減らすことです。 1. Introduction 1. はじめに This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of DNS servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. This document presumes a one-to-one mapping between named authoritative servers and administrative entities (operators). This document contains no guidelines or recommendations for caching name servers. The shared unicast system described here is specific to IPv4; applicability to IPv6 is an area for further study. It should also be noted that the system described here is related to that described in [ANYCAST], but it does not require dedicated address space, routing changes, or the other elements of a full anycast infrastructure which that document describes. このメモは正式なネームサーバオペレーターが多数の場所で１つのネーム サーバーへのアクセスを供給を意図する習慣を記述します。これらの習慣 の開発と展開のための主要な動機はネットワークトポロジーによりサポー トされていないエリアにＤＮＳサーバの展開を増やし、それらのエリアで ＤＮＳ問合せ回答の遅延を減らすことです。この文書はネーム権威サーバー と管理者（オペレーター）の間に１対１のマッピングを予想します。この 文書はキャッシュネームサーバに対するガイドラインや推薦を含んでいま せん。ここで記述された共有ユニキャストシステムはＩＰｖ４に特化して います；ＩＰｖ６への適用は今後の研究エリアです。ここで記述されたシ ステムが[ANYCAST]で記述されているものと関係があることを指摘します が、しかしここのシステムは専用アドレス空間やルーティング変更やその 他の[ANYCAST]が記述する完全なエニキャスト基盤要素を必要としません。 2. Architecture 2. 構造 2.1 Server Requirements 2.1 サーバ要求条件 Operators of authoritative name servers may wish to refer to [SECONDARY] and [ROOT] for general guidance on appropriate practice for authoritative name servers. In addition to proper configuration as a standard authoritative name server, each of the hosts participating in a shared-unicast system should be configured with two network interfaces. These interfaces may be either two physical interfaces or one physical interface mapped to two logical interfaces. One of the network interfaces should use the IPv4 shared unicast address associated with the authoritative name server. The other interface, referred to as the administrative interface below, should use a distinct IPv4 address specific to that host. The host should respond to DNS queries only on the shared-unicast interface. In order to provide the most consistent set of responses from the mesh of anycast hosts, it is good practice to limit responses on that interface to zones for which the host is authoritative. 権威ネームサーバーのオペレーターが権威ネームサーバーの適切な運用の一 般的な指導のために[SECONDARY]と[ROOT]を参照することを望むかもしれませ ん。権威ネームサーバーとしての適切な設定のほかに、共有ユニキャストシ ステムに参加している各ホストは２つのネットワークインタフェースを配置 するべきです。これらのインタフェースは２つの物理インターフェースかも しれないし、２つの論理インタフェースに対応する１つの物理インタフェー スかもしれません。ネットワークインタフェースの１つが権威ネームサーバー のＩＰｖ４共有ユニキャストアドレスを使うべきです。他のインタフェース は、下で管理インタフェースと述べられ、そのホスト固有のＩＰｖ４アドレ スを使うべきです。ホストは共有ユニキャストインタフェースに対してだけ ＤＮＳ問合せに返答するべきです。エニキャストホストのメッシュから一貫 した回答を供給するため、インタフェース上で権威ゾーンの回答だけをする ように制限するのも良い実行です。 2.2 Zone file delivery 2.2 ゾーンファイル配達 In order to minimize the risk of man-in-the-middle attacks, zone files should be delivered to the administrative interface of the servers participating in the mesh. Secure file transfer methods and strong authentication should be used for all transfers. If the hosts in the mesh make their zones available for zone transfer, the administrative interfaces should be used for those transfers as well, in order to avoid the problems with potential routing changes for TCP traffic noted in section 2.5 below. 中間者攻撃の危険を最小にするために、ゾーンファイルがメッシュに参加し ているサーバーの管理インタフェースに配達されるべきです。セキュリティ の高いファイル転送方法と強い認証がすべての転送で使われるべきです。も しメッシュのホストがゾーン転送を利用可能にするなら、２.５章で指摘さ れるＴＣＰトラフィックのルーティング変更の可能性の問題を避けるために、 ゾーン転送での管理インタフェースが使われるべきです。 2.3 Synchronization 2.3 同期 Authoritative name servers may be loosely or tightly synchronized, depending on the practices set by the operating organization. As noted below in section 4.1.2, lack of synchronization among servers using the same shared unicast address could create problems for some users of this service. In order to minimize that risk, switch-overs from one data set to another data set should be coordinated as much as possible. The use of synchronized clocks on the participating hosts and set times for switch-overs provides a basic level of coordination. A more complete coordination process would involve: 権威ネームサーバーが、運用組織の決めた規則によって、だいたいもしくは 厳密に同期するかもしれません。４.１.２章で記述したように、共有ユニキャ ストアドレスを使うサーバの間で同期がないとあるサービスのユーザーに問 題が起こります。その危険を最小にするために、１つのデータセットから他 のデータセットへの切替はまで可能な限り調整されるべきです。参加ホスト の時刻同期を用いて、切替時間を設定し、基本的なレベルの調整を供給しま す。より完全な調整処理はいかが必要でしょう： a) receipt of zones at a distribution host a) 分配ホストでのゾーンの受領 b) confirmation of the integrity of zones received b) 受信ゾーンの完全性の確認 c) distribution of the zones to all of the servers in the mesh c) メッシュサーバーのすべてへのゾーンの配布 d) confirmation of the integrity of the zones at each server d) 各サーバーでのゾーン完全性の確認 e) coordination of the switchover times for the servers in the mesh e) メッシュサーバーの切替時刻の調整 f) institution of a failure process to ensure that servers that did not receive correct data or could not switchover to the new data ceased to respond to incoming queries until the problem could be resolved. f) 正しいデータを受け取らないか、新しいデータへの切替に失敗したサー バーが入ってくる問合せに返答することをやめることを保証する失敗 プロセスの制定 Depending on the size of the mesh, the distribution host may also be a participant; for authoritative servers, it may also be the host on which zones are generated. メッシュの大きさに依存して分配ホストも関係者かもしれません；権威があ るサーバーにとって、これはゾーンが生成されるホストであるかもしれませ ん。 This document presumes that the usual DNS failover methods are the only ones used to ensure reachability of the data for clients. It does not advise that the routes be withdrawn in the case of failure; it advises instead that the DNS process shutdown so that servers on other addresses are queried. This recommendation reflects a choice between performance and operational complexity. While it would be possible to have some process withdraw the route for a specific server instance when it is not available, there is considerable operational complexity involved in ensuring that this occurs reliably. Given the existing DNS failover methods, the marginal improvement in performance will not be sufficient to justify the additional complexity for most uses. この文書はＤＮＳ故障切替方法がクライアントのデータの可到達性を保証す るために使われる唯一のものであると推測します。これは経路障害の故障の 場合に通知がありません；これは、ＤＮＳシャットダウン処理の代わりに他 のアドレスのサーバーに聞くように知らせます。この推薦は性能と操作の複 雑さの間に選択を反映します。特定のサーバーの経路を消すプロセスが利用 可能であろうが、利用可能でない時、これを信頼できるようにするにはかな りの操作の複雑さがあります。既存のＤＮＳ故障切替方法の存在化で、パ フォーマンスのあまり重要でない改良はたいていの使用で追加の複雑さを認 めるのに十分ではないでしょう。 2.4 Server Placement 2.4 サーバー配置 Though the geographic diversity of server placement helps reduce the effects of service disruptions due to local problems, it is diversity of placement in the network topology which is the driving force behind these distribution practices. Server placement should emphasize that diversity. Ideally, servers should be placed topologically near the points at which the operator exchanges routes and traffic with other networks. サーバを地理的に様々な場所に設置することはローカルな問題でサービス中 断をおこすのを減らすのに役立つけれども、これは分散クライアントの縁の 下の力持ち的なネットワークトポロジーでの配置の多様性です。サーバー配 置がその多様性を強調するべきです。理想的には、オペレーターが他のネッ トワークと経路やトラフィックを交換する場所のトポロジー的に近くにサー バーが置かれるべきです。 2.5 Routing 2.5 ルーチング The organization administering the mesh of servers sharing a unicast address must have an autonomous system number and speak BGP to its peers. To those peers, the organization announces a route to the network containing the shared-unicast address of the name server. The organization's border routers must then deliver the traffic destined for the name server to the nearest instantiation. Routing to the administrative interfaces for the servers can use the normal routing methods for the administering organization. ユニキャストアドレスを共有しているサーバメッシュを管理している組織は 自律システム番号を持ち、ピアとＢＧＰを話さなくてはなりません。それら のピアに、組織はネットワークがネームサーバの共有ユニキャストアドレス を含んでいる経路を広告します。組織の境界ルータは最も近くのネームサー バにネームサーバ行きのトラフィックを届けなくてはなりません。サーバー の管理インタフェースへのルーティングには管理組織のために標準的なルー ティング方法を使うことができます。 One potential problem with using shared unicast addresses is that routers forwarding traffic to them may have more than one available route, and those routes may, in fact, reach different instances of the shared unicast address. Applications like the DNS, whose communication typically consists of independent request-response messages each fitting in a single UDP packet present no problem. Other applications, in which multiple packets must reach the same endpoint (e.g., TCP) may fail or present unworkable performance characteristics in some circumstances. Split-destination failures may occur when a router does per-packet (or round-robin) load sharing, a topology change occurs that changes the relative metrics of two paths to the same anycast destination, etc. 共有ユニキャストアドレスを使うことでの１つの可能性がある問題はトラ フィックを転送しているルーターが複数の利用可能な経路を持ち、それぞれ の経路が異なるサーバに届くかもしれないということです。ＤＮＳのような 各要求回答が他の要求回答と独立で、それぞれのメッセージがひとつのＵＤ Ｐパケットにのるようなアプリケーションは問題をおこしません。多数のパ ケットが同じサーバに到達しないといけないほかのアプリケーション（例え ばＴＣＰ）、ある状況で実行不可能な性能問題を起こすかもしれません。ルー ターがパケット毎（又はラウンドロビンで）負荷分散を行う場合、同じエニ キャスト宛の２つのパスの相対的な距離がを変えるトポロジー変更が起こる 時、宛先分割の失敗が起こるかもしれません。 Four things mitigate the severity of this problem. The first is that UDP is a fairly high proportion of the query traffic to name servers. The second is that the aim of this proposal is to diversify topological placement; for most users, this means that the coordination of placement will ensure that new instances of a name server will be at a significantly different cost metric from existing instances. Some set of users may end up in the middle, but that should be relatively rare. The third is that per packet load sharing is only one of the possible load sharing mechanisms, and other mechanisms are increasing in popularity. ４つのことがこの問題の重大さを和らげます。最初はネームサーバに問合せ トラフィックのかなり高い割合がＵＤＰであるということです。第２はこの 提案の目的がトポロジー配置を多様化するはずということです；たいていの ユーザーにとって、これはサーバ配置の際に新しいネームサーバが古いネー ムサーバと異なるコスト距離にあるだろうということを意味します。いずれ かのユーザーの２つの真中にあるかもしれませんが、それは比較的まれであ るべきです。第３にパケット毎の負荷分散が可能な負荷分散ロード共有機構 の１つに過ぎず、他のメカニズムに人気があることです。 Lastly, in the case where the traffic is TCP, per packet load sharing is used, and equal cost routes to different instances of a name server are available, any DNS implementation which measures the performance of servers to select a preferred server will quickly prefer a server for which this problem does not occur. For the DNS failover mechanisms to reliably avoid this problem, however, those using shared unicast distribution mechanisms must take care that all of the servers for a specific zone are not participants in the same shared-unicast mesh. To guard even against the case where multiple meshes have a set of users affected by per packet load sharing along equal cost routes, organizations implementing these practices should always provide at least one authoritative server which is not a participant in any shared unicast mesh. Those deploying shared- unicast meshes should note that any specific host may become unreachable to a client should a server fail, a path fail, or the route to that host be withdrawn. These error conditions are, however, not specific to shared-unicast distributions, but would occur for standard unicast hosts. 最後に、トラフィックがＴＣＰの場合、パケット毎負荷分散が使われ、複数 のネームサーバへの平しい経路コストはありえますが、望ましいサーバーを 選ぶためにサーバーの性能を測るＤＮＳ実装が応答が速くこの問題を起こさ ないサーバを好むでしょう。ＤＮＳ故障切替メカニズムが信頼できるように この問題を避けるために、共有ユニキャストメカニズムは、指定ゾーンのサー バーの全てが同じ共有ユニキャストメッシュに加わっているのではないこと に注意します。同一コスト経路のパケット毎の負荷分散の影響があるユーザ と多数のメッシュがある場合に、組織は常に共有されたユニキャストメッシュ に加わらない少なくとも１つの正式なサーバーを供給するべきです。共有ユ ニキャストメッシュを配置している人たちはもしサーバ障害やパス障害やホ ストへの経路障害があると特定のホストのクライアントに到達不可能になる かもしれないことを指摘するべきです。これらのエラー状態は、しかしなが ら、共有ユニキャスト分散に特有ではなく、標準ユニキャストホストで存在 するでしょう。 Since ICMP response packets might go to a different member of the mesh than that sending a packet, packets sent with a shared unicast source address should also avoid using path MTU discovery. ＩＣＭＰ応答パケットがメッシュ内のパケットを送ったのと異なるサーバに 行くかもしれないので、共有ユニキャストソースアドレスに送られたパケッ トが同じくパスＭＴＵ探索を使うのを避けるべきです。 Appendix A. contains an ASCII diagram of an example of a simple implementation of this system. In it, the odd numbered routers deliver traffic to the shared-unicast interface network and filter traffic from the administrative network; the even numbered routers deliver traffic to the administrative network and filter traffic from the shared-unicast network. These are depicted as separate routers for the ease this gives in explanation, but they could easily be separate interfaces on the same router. Similarly, a local NTP source is depicted for synchronization, but the level of synchronization needed would not require that source to be either local or a stratum one NTP server. 付録Ａがこのシステムの単純な実装の例のASCII図を含んでいます。その中 にの基数番号を付けられたルーターは共有ユニキャストインタフェースネッ トワークへトラヒックを届け管理ネットワークからのトラヒックをフィル ターします；さらに偶数番号を付けられたルーターは管理ネットワークか らのトラヒックを届け共有ユニキャストネットワークからのとトラヒック をフィルタします。これらは説明の容易さのために別のルーターとして描 写されますが、同じルータ上の別のインタフェースかもしれません。同様 に、ローカルＮＴＰソースが同期のために描写されますが、必要とされる 同時発生のレベルは時刻情報源がローカルやstratum 1のＮＴＰサーバを 要求しないでしょう。 3. Administration 3. 管理 3.1 Points of Contact 3.1 連絡のポイント A single point of contact for reporting problems is crucial to the correct administration of this system. If an external user of the system needs to report a problem related to the service, there must be no ambiguity about whom to contact. If internal monitoring does not indicate a problem, the contact may, of course, need to work with the external user to identify which server generated the error. 報告問題のためのひとつの連絡ポイントがシステムの正しい運用に極めて重 大です。もしシステム外のユーザーがサービスと関係がある問題を報告する 必要があるなら、誰と連絡を取るべきかについてあいまい性があってはなり ません。もし内部のモニタリングが問題を示さないなら、どのサーバーがエ ラーを生成したかについて明らかにするためにコンタクト者は外部のユーザー と共に働く必要があるかもしれません。 4. Security Considerations 4. セキュリティの考察 As a core piece of Internet infrastructure, authoritative name servers are common targets of attack. The practices outlined here increase the risk of certain kinds of attacks and reduce the risk of others. インターネットインフラのコアの一部として、権威ネームサーバーは攻撃の 一般的な標的です。ここで概説された習慣はある特定の種類の攻撃の危険を 増やして、そして他のものの危険を減らします。 4.1 Increased Risks 4.1 リスクの増加 4.1.1 Increase in physical servers 4.1.1 物理的なサーバーの増加 The architecture outlined in this document increases the number of physical servers, which could increase the possibility that a server mis-configuration will occur which allows for a security breach. In general, the entity administering a mesh should ensure that patches and security mechanisms applied to a single member of the mesh are appropriate for and applied to all of the members of a mesh. "Genetic diversity" (code from different code bases) can be a useful security measure in avoiding attacks based on vulnerabilities in a specific code base; in order to ensure consistency of responses from a single named server, however, that diversity should be applied to different shared-unicast meshes or between a mesh and a related unicast authoritative server. この文書で概説されたアーキテクチャは物理的なサーバーの数を増やし、こ れはセキュリティ違反になる間違ったサーバ設定が存在する可能性を増やし ます。一般に、メッシュ管理者は、メッシュのメンバーの１つに適用したパッ チやセキュリティメカニズムは、全てのメンバーに適用されることを確実に すべきです。「遺伝子の多様性」（出典の異なるプログラム）は特定のプロ グラムの弱みに基づいた攻撃を避けることに有用なセキュリティ方法であり 得ます；しかし１つのサーバからの回答の一貫性を保証するために、多様性 は異なる共有ユニキャストメッシュか、メッシュと関連したユニキャスト権 威サーバ間で適用するべきです。 4.1.2 Data synchronization problems 4.1.2 データ同期問題 The level of systemic synchronization described above should be augmented by synchronization of the data present at each of the servers. While the DNS itself is a loosely coupled system, debugging problems with data in specific zones would be far more difficult if two different servers sharing a single unicast address might return different responses to the same query. For example, if the data associated with www.example.com has changed and the administrators of the domain are testing for the changes at the example.com authoritative name servers, they should not need to check each instance of a named authoritative server. The use of NTP to provide a synchronized time for switch-over eliminates some aspects of this problem, but mechanisms to handle failure during the switchover are required. In particular, a server which cannot make the switchover must not roll-back to a previous version; it must cease to respond to queries so that other servers are queried. 上に記述した全体の同期のレベルはサーバの各データの同期によって増加す べきです。ＤＮＳ自身は大ざっぱにつながれたシステムであるが、特定のゾー ンデータにおける問題をデバッグする時に、もしひとつのユニキャストアド レスを共有している２つの異なったサーバーが同じ問合せに対する異なった 回答を返すかもしれないなら、デバッグははるかに難しいでしょう。例えば、 もしwww.example.comと結び付けられたデータが変化し、ドメインの管理者 ががexample.comの変更について権威ネームサーバーをテストしているなら、 それぞれのネーム権威サーバの実際の実体を検査する必要があるべきではあ りません。切替のためにＮＴＰを時刻合わせに使用することはこの問題のあ る面を排除しますが、切替失敗を処理するメカニズムが必要です。特に切替 に失敗したサーバが前の版に戻るべきではありません；サーバは、他のサー バーが問い合わせられるように、質問に返答をやめなくてはなりません。 4.1.3 Distribution risks 4.1.3 分散リスク If the mechanism used to distribute zone files among the servers is not well secured, a man-in-the-middle attack could result in the injection of false information. Digital signatures will alleviate this risk, but encrypted transport and tight access lists are a necessary adjunct to them. Since zone files will be distributed to the administrative interfaces of meshed servers, the access control list for distribution of the zone files should include the administrative interface of the server or servers, rather than their shared unicast addresses. もしサーバーにゾーンファイルを配布するために使われたメカニズムが安全 でないなら、中間者攻撃が偽情報の注射をもたらします。ディジタル署名が この危険を軽減するであろう、しかしトランスポート暗号化と厳密なアクセ スリストが必要です。ゾーンファイルがメッシュサーバの管理インタフェー スに配られるであろうから、ゾーンファイルの配布アクセス制御リストはユ ニキャストアドレスではなくサーバの管理インターフェースを含むべきです。 4.2 Decreased Risks 4.2 リスクの減少 The increase in number of physical servers reduces the likelihood that a denial-of-service attack will take out a significant portion of the DNS infrastructure. The increase in servers also reduces the effect of machine crashes, fiber cuts, and localized disasters by reducing the number of users dependent on a specific machine. 物理的なサーバーの数の増加はサービス否認攻撃がＤＮＳインフラの重要な 部分を使えなくする可能性を減らします。サーバーの増加は同じく機械故障、 ファイバーカットの影響を減らし、特定の機械に依存しているユーザーの数 を減らすことで大惨事を局地的に制限します。 5. Acknowledgments 5. 謝辞 Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato, Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all provided input and commentary on this work. The editor wishes to remember in particular the contribution of the late Scott Tucker, whose extensive systems experience and plain common sense both contributed greatly to the editor's own deployment experience and are missed by all who knew him. Masataka OhtaとBill ManningとRandy BushとChris YarnellとRay Plzakと Mark AndrewsとRobert ElzとGeoff HustonとBill NortonとAkira Katoと Suzanne WoolfとBernard AbobaとCasey AjalatとGunnar Lindbergはすべて この仕事の入力と論評を供給しました。編集者は特に大規模なシステム経験 と平易な常識の両方で大いにエディタの自身の展開経験に貢献してた故 Scott Tuckerの貢献を覚えていることを望み、彼を知っていたすべてを残念 に思います。 6. References 6. 参考文献 [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997. [ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000. [ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. Appendix A. 付録Ａ __________________ Peer 1-| | Peer 2-| | Peer 3-| Switch | Transit| | _________ _________ etc | |--|Router1|---|----|----------|Router2|---WAN-| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| Switch | | Transit| | _________ _________ | etc | |--|Router3|---|----|----------|Router4|---WAN-| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| Switch | | Transit| | _________ _________ | etc | |--|Router5|---|----|----------|Router6|---WAN-| | | --------- | | --------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| Switch | | Transit| | _________ _________ | etc | |--|Router7|---|----|----------|Router8|---WAN-| | | --------- | | --------- | | | | | | | | ------------------ [NTP] [DNS] 7. Editor's Address 7. 著者のアドレス Ted Hardie Nominum, Inc. 2385 Bay Road. Redwood City, CA 94063 Phone: 1.650.381.6226 EMail: Ted.Hardie@nominum.com 8. Full Copyright Statement 8. 著作権表示全文 Copyright (C) The Internet Society (2002). All Rights Reserved. 著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、 この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装 を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出 版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ ンターネット標準を開発する目的で必要な場合以外は、インターネット学会 や他のインターネット組織は著作権表示や参照を削除されるような変更がで きません、インターネット標準を開発する場合はインターネット標準化プロ セスで定義された著作権の手順に従われます。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 上に与えられた限定された許可は永久で、インターネット学会やその後継者 や譲渡者によって無効にされません。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって 供給されます。