この文書はRFC3609の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Bonica
Request for Comments: 3609 MCI
Category: Informational K. Kompella
Juniper Networks
D. Meyer
Sprint
September 2003
Tracing Requirements for Generic Tunnels
一般的なトンネルのための追跡必要条件
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 (2003). All Rights Reserved.
Abstract
概要
This document specifies requirements for a generic route-tracing
application. It also specifies requirements for a protocol that will
support that application. Network operators will use the generic
route-tracing application to verify proper operation of the IP
forwarding plane. They will also use the application to discover
details regarding tunnels that support IP forwarding.
この文書は一般的な経路追跡アプリケーションのための必要条件を指定しま
す。これは同じくそのアプリケーションを支援するであろうプロトコルの必
要条件を指定します。ネットワークオペレータがＩＰ転送面の適切な運用を
確かめるために一般的な経路追跡アプリケーションを使うでしょう。オペレー
タはＩＰ転送をサポートするトンネルに関しする詳細を発見するためにもア
プリケーションを使うでしょう。
The generic route-tracing application, specified herein, supports a
superset of the functionality that "traceroute" currently offers.
Like traceroute, the generic route-tracing application can discover
the forwarding path between two interfaces that are contained by an
IP network. Unlike traceroute, this application can reveal details
regarding tunnels that support the IP forwarding path.
ここで指定される、一般的な経路追跡アプリケーションは、現在
「traceroute」が提供する機能の上位セットをサポートします。traceroute
のように、一般的な経路追跡するアプリケーションはＩＰネットワークに含
まれる２つのインタフェース間の転送パスを発見することができます。
tracerouteと異なり、このアプリケーションはＩＰ転送パスをサポートする
トンネルに関しての細部を明らかにすることができます。
1. Introduction
1. はじめに
IP networks utilize several tunneling technologies. Although these
tunneling technologies provide operators with many useful features,
they also present management challenges. Network operators require a
generic route-tracing application that they can use to verify the
correct operation of the IP forwarding plane. The generic
route-tracing application must be capable of detecting tunnels and
revealing tunnel details. The application also must be useful in
diagnosing tunnel faults.
ＩＰネットワークがいくつかのトンネル技術を利用します。これらのトンネ
ル技術が多くの有用な機能をオペレータに提供するけれども、同時に管理上
のチャレンジを発生します。ネットワークオペレータは使用できる一般的な
経路追跡アプリケーションでＩＰ転送面の正しい運用を確かめれる事を要求
します。一般的経路追跡アプリケーションはトンネルを発見して、トンネル
の細部を明らかにすることができなくてはなりません。アプリケーションは
同じくトンネル障害を診断することに有用であるに違いありません。
Implementors also require a new protocol that will support the
generic-route tracing application. This document specifies
requirements for that protocol. It specifies requirements,
primarily, by detailing the desired capabilities of the generic
route-tracing application. A particular version of generic
route-tracing application may implement some subset of the desired
capabilities. It may also implement a superset of those
capabilities. However, protocol designers are not required to
consider the additional capabilities when designing the new protocol.
実装者が同じく一般的な経路追跡アプリケーションをサポートするであろう
新しいプロトコルを必要とします。この文書はそのプロトコルのための必要
条件を指定します。これは主に、一般的な経路追跡アプリケーションの望ま
しい能力を詳述することによって必要条件を指定します。一般的な経路追跡
アプリケーションの特定のバージョンがいずれかの望ましい能力の一部を実
装してもよいです。これはより多くの能力を実装するかもしれません。しか
しながら、プロトコル設計者が新しいプロトコルを設計する時、追加の能力
を考慮するようには要求されません。
This document also specifies a few protocol requirements, stated as
such. These requirements are driven by desired characteristics of
the generic route-tracing application. Whenever a protocol
requirement is stated, it is mapped to the desired characteristic of
the route-tracing application.
この文書はまた少数のプロトコル必要条件を指定します。これらの必要条件
は一般的な経路追跡アプリケーションの望ましい機能から派生します。プロ
トコル必要条件が述べられる時は、経路追跡アプリケーションの望ましい機
能に対応づけされます。
2. Review of Existing Functionality
2. 既存の機能の再検討
Currently, network operators use "traceroute" to trace through the
forwarding path of an IP network. Section 3.4 of [RFC-2151] provides
a thorough description of traceroute. Although traceroute is very
reliable and very widely deployed, it is deficient with regard to
tunnel tracing.
現在、ネットワークオペレータがＩＰネットワークの転送パスを追跡するた
め「traceroute」を使います。[RFC-2151]の３.４章がtracerouteの詳細な
記述を供給します。tracerouteは非常に信頼性が高く、そして非常に広く利
用されているけれども、トンネルを追跡することに関しては不十分です。
Depending upon tunnel type, traceroute may display an entire tunnel
as a single IP hop, or it may display the tunnel as a collection of
IP hops, without indicating that they are part of a tunnel.
トンネルタイプによっては、tracerouteが全部のトンネルを１つのＩＰホッ
プとして表示するかもしれません、あるいはトンネルの一部であることを示
さないで、トンネルをＩＰホップの集合として表示するかもしれません。
For example, assume that engineers deploy an IP tunnel in an IP
network. Assume also that they configure the tunnel so that the
ingress router does not copy the TTL value from the inner IP header
to outer IP header. Instead, the ingress router always sets the
outer TTL value to its maximum permitted value. When engineers trace
through the network, traceroute will always display the tunnel as a
single IP hop, hiding all components except the egress interface.
例えば、エンジニアがＩＰネットワークでＩＰトンネルを設定すると想定し
てください。入口ルータが内部ＩＰヘッダから外部ＩＰヘッダにＴＴＬ値を
コピーしないようにトンネルを設定すると想定してください。代わりに、入
口ルータは常に外部ＴＴＬ値をその最大の認められた値に設定します。エン
ジニアがネットワークを追跡する時、tracerouteが常に出口インタフェース
以外のすべてコンポーネントを隠し、トンネルを１ホップと表示するでしょ
う。
Now assume that engineers deploy an MPLS LSP in an IP network.
Assume also that engineers configure the MPLS LSP so that the ingress
router propagates the TTL value from the IP header to the MPLS
header. When engineers trace through the network, traceroute will
display the LSP as a series of IP hops, without indicating that they
are part of a tunnel.
次に、エンジニアがＩＰネットワークでＭＰＬＳのＬＳＰを設定すると想定
してください。エンジニアが、入口ルータがＩＰヘッダからＭＰＬＳヘッダ
にＴＴＬ値を伝えるように、ＭＰＬＳのＬＳＰを設定すると想定してくださ
い。エンジニアがネットワークを追跡する時、tracerouteはトンネルの一部
であることを示さずに、ＬＳＰを一連のＩＰホップと表示するでしょう。
3. Application Requirements
3. アプリケーション必要条件
Network operators require a new route-tracing application. The new
application must support all functionality that traceroute currently
offers. It also must provide enhanced tunnel tracing capabilities.
ネットワークオペレータが新しい経路追跡アプリケーションを必要とします。
新しいアプリケーションはtracerouteが現在提供するすべての機能をサポー
トしなくてはなりません。
The following list provides specific requirements for the new
route-tracing application:
同じく拡張されたトンネルを追跡能力を供給しなくてはなりません。次のリ
ストは新しい経路追跡アプリケーションのための特定の必要条件を供給しま
す：
1) Support the notion of a security token as part of the tunnel
trace request. The security token identifies the tracer's
privileges in tracing tunnels. Network elements will use this
security token to determine whether or not to return the requested
information to the tracer. In particular, appropriate privileges
are required for items (2), (3), (6), (8), (10), (13), and (14).
１）トンネル追跡要求の一部として、セキュリティトークンの考えをサポー
トしてください。セキュリティトークンはトンネルを追跡する際に追跡者
の特権を識別します。ネットワーク要素が追跡者に求められた情報を返す
べきかどうか決定するためのこのセキュリティトークンを使うでしょう。
特に、適切な特権が項目（２）（３）（６）（８）（１０）（１３）（１４）に
必要とされます。
Justification: Operators may need to discover network forwarding
details, while concealing those details from unauthorized parties.
正当化：オペレーターが、無許可者から詳細を隠しながら、ネットワーク
転送の詳細を発見する必要があるかもしれません。
2) Support in-line traces. An in-line trace reveals the path
between the host upon which the route-tracing application executes
and any interface in an IP network.
２）インライン追跡のサポート。インライン追跡は経路追跡アプリケー
ションを実行するホストとＩＰネットワークのインタフェース間の経路を
明らかにします。
Justification: Operators need to discover how the network would
forward a datagram between any two IP interfaces.
正当化：オペレータがネットワークがどの２つのＩＰインタフェース間で
どうやってデータグラムが転送するか発見する必要があります。
3) Support third-party traces. A third-party trace reveals the
path between any two points in an IP network. The application
that initiates a third-party trace need not execute upon a host or
router that is part of the traced path. Unlike existing solutions
[RFC-2151] [RFC-2925], the application will not rely upon IP
options or require access to the SNMP agent in order to support
third-party traces.
３）第三者追跡のサポート第三者追跡がＩＰネットワークの任意の２点間
のパスを明らかにします。第三者追跡を開始するアプリケーションを、追
跡するパスの一部であるホストやルータ上で実行する必要がありません。
既存の解決策[RFC-2151] [RFC-2925]と異なり、アプリケーションはＩＰ
オプションに頼るか、あるいは第三者追跡をサポートするＳＮＭＰエー
ジェントへのアクセスを必要としないでしょう。
Justification: Operators need to discover how the network would
forward a datagram between any two IP interfaces.
正当化：オペレータがネットワークの任意の２つのＩＰインタフェース間
でデータグラムを転送する方法を発見する必要があります。
4) Support partial traces through broken paths or tunnels.
４）壊れたパスやトンネルを通る部分追跡のサポート
Justification: Operators need to identify the root cause of
forwarding plane failures.
正当化：オペレータが転送面障害の根本原因を識別する必要があります。
5) When tracing through a tunnel, either as part of an in-line
trace or a third-party trace, display the tunnel either as a
single IP hop or in detail. The user's request determines how the
application displays tunnels, subject to the user having
permission to do this.
５）インライン追跡か第三者追跡の一部としてトンネルの追跡をする時に、
１ＩＰホップあるいは詳細としてトンネルを示してください。ユーザの要
求でどのようにアプリケーションが、ユーザがこの許可を持つかに従って、
トンネルを示すか決定します。
Justification: As they discover IP forwarding details, operators
may need to reveal or mask tunneling details.
正当化：これらでＩＰ転送の細部を発見するｍｐで。オペレータがトンネ
ル詳細を明らかにするか、あるいは隠す必要があるかもしれません。
6) When displaying a tunnel in detail, include the tunnel type
(e.g., GRE, MPLS), the tunnel name (if applicable), the tunnel
identifier (if applicable) and tunnel endpoint addresses. Also,
include tunnel components and round trip delay across each
component.
６）トンネルの詳細を示す時、トンネルタイプ（例えば、ＧＲＥやＭＰＬ
Ｓ）と、トンネル名（もし利用可能であるなら）と、トンネル識別子（も
し利用可能であるなら）と、トンネル末端アドレスを含んでください。同
じく、それぞれのトンネルコンポーネントと、コンポーネント間の往復遅
延を含んでください。
Justification: As they discover IP forwarding details, operators
may need to reveal tunneling details.
正当化：それらがＩＰ転送の詳細を発見するから、オペレータがトンネル
細部を明らかにする必要があるかもしれません。
7) Support the following tunneling technologies: GRE, MPLS, IPSEC,
GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel
technologies.
７）次の技術をサポートしてください：ＧＲＥ、ＭＰＬＳ、ＩＰＳＥＣ、
ＧＭＰＬＳ、ＩＰ−ｉｎ−ＩＰ、Ｌ２ＴＰ。新しいトンネル技術をサポー
トするために容易に拡張可能であってください。
Justification: Operators will use the generic route-tracing
application to discover how an IP network forwards datagrams. As
many tunnel types may support the IP network, the generic
route-tracing application must detect and reveal details
concerning multiple tunnel types.
正当化：ＩＰネットワークがデータグラムを転送する方法を発見するため
に、オペレータが一般的な経路追跡アプリケーションを使うでしょう。多
くのトンネルタイプがＩＰネットワークをサポートするかもしれないから、
一般的な経路追跡アプリケーションは多数のトンネルタイプに関して詳細
を検出し、そして明らかにしなくてはなりません。
8) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP
over MPLS).
８）入れ子のの異種のトンネル（例えば、ＭＰＬＳ上のＩＰ−ｉｎ−ＩＰ」）
を追跡してください。
Justification: Operators will use the generic route-tracing
application to discover how an IP network forwards datagrams. As
nested, heterogeneous tunnels may support the IP network, the
generic route-tracing application must detect and reveal details
concerning nested, heterogeneous tunnels.
正当化：ＩＰネットワークがデータグラムを転送する方法を発見するため
に、オペレータが一般的な経路追跡アプリケーションを使うでしょう。入
れ子の異種のトンネルがＩＰネットワークをサポートするかもしれません、
一般的な経路追跡アプリケーションは入れ子の異種のトンネルに関して詳
細を検出し、明らかにしなくてはなりません。
9) At the users request, trace through the forwarding plane, the
control plane or both.
９）ユーザ要求で、転送面か制御面かあるいは両方を追跡してください。
Justification: Operators need to identify the root cause of
forwarding plane failures. Control plane information is sometimes
useful in determining the cause of forwarding plane failure.
正当化：オペレータが転送面の障害の根本原因を識別する必要があります。
制御面情報は転送面障害の原因を決定する際に、しばしば有用です。
10) Support control plane tracing for all tunnel types. When
tracing through the control plane, the hop ingress device reports
hop details. The hop ingress device is the device that originates
the hop.
１０）すべてのトンネルタイプのために制御面追跡をサポートしてくださ
い。制御面を追跡する時、ホップ入口装置はホップの詳細を報告します。
ホップ入口装置はホップを生成する装置です。
Justification: Control plane information is available regarding
all tunnel types.
正当化：制御面情報はすべてのトンネルタイプで利用可能です。
11) Support tracing through forwarding plane for all tunnel types
that implement TTL decrement (or some similar mechanism). When
tracing through the forwarding plane, the hop egress device
reports hop details. The hop egress device is the device that
terminates the hop.
１１）ＴＴＬ減算（あるいは類似のメカニズム）を実行する全てのトンネ
ルタイプで、転送面の追跡をサポートしてください。転送面を追跡する時、
ホップ出口装置はホップ細部を報告します。ホップ出口装置はホップを終
端する装置です。
Justification: Forwarding plane information may not be available
for tunnels that do not support TTL decrement.
正当化：ＴＴＬ減算をサポートしないトンネルの転送面情報は入手可能で
はないかもしれないません。
12) Support tracing through the forwarding plane for all tunnel
types that implement TTL decrement, regardless of whether the
tunnel engages in TTL propagation. (That is, support tunnel
tracing regardless of whether the TTL value is copied from an
inner header to an outer header at tunnel ingress.)
１２)ＴＴＬ減算を実行する全てのトンネルタイプで、トンネルがＴＴＬ
伝播に従事するかにかかわらず、転送面を追跡することをサポートしてく
ださい。（すなわち、ＴＴＬ値がトンネル入口で内側ヘッダから外側ヘッ
ダにコピーされるかどうかにかかわらず、トンネルの追跡をサポートして
ください。）
Justification: Forwarding plane information is always available,
regardless of whether the tunnel engages in TTL propagation.
正当化：転送面情報は、トンネルがＴＴＬ伝播に従事するかどうかにかか
わらず、常に利用可能です。
13) When tracing through the control plane, display the MTU
associated with each interface that forwards datagrams through the
traced path.
１３）制御面を通して追跡する時、追跡されたパスのデータグラムを転送
するそれぞれのインタフェースのＭＴＵを表示してください。
Justification: MTU information is sometimes useful in identifying
the root cause of forwarding and control plane failures.
正当化：ＭＴＵ情報は転送と制御面障害の根本原因を識別するさいにしば
しば有用です。
14) When tracing through the forwarding plane, display the MTU
associated with each interface that receives datagrams along the
traced path.
１４) 転送面を追跡する時、追跡されたパスでデータグラムを受け取るそ
れぞれのインタフェースのＭＴＵを表示してください。
Justification: MTU information is sometimes useful in identifying
the root cause of forwarding and control plane failures.
正当化：情報は転送と制御面障害の根本原因を識別するさいにしばしば有
用です。
15) Support partial traces through paths containing devices that
do not provide protocol support for generic route tracing. When
the application encounters such a device, it should inform the
user and attempt to discover details regarding the next interface
downstream.
１５) 一般的な経路追跡に対するプロトコルサポートを供給しない装置を
含んでいるパスでも部分的なサポートをしてください。アプリケーション
がこのようなデバイスに遭遇する時、ユーザに知らせて、下流の次のイン
タフェースに関して詳細を発見しようと試みるべきです。
Justification: The application must provide useful information
even if the supporting protocol is not universally deployed.
正当化：アプリケーションは、たとえサポートのプロトコルが広く一般に
実装されないとしても、有用な情報を供給しなくてはなりません。
4. Protocol Requirements
4. プロトコル必要条件
Implementors require a new protocol that supports the generic
route-tracing application. This protocol reveals the path between
two points in an IP network. When access policy permits, the
protocol also reveals tunnel details.
実装者が一般的経路追跡アプリケーションをサポートする新しいプロトコル
を必要とします。このプロトコルはＩＰネットワークで、２点間のパスを明
らかにします。アクセスポリシが許す時、プロトコルは同じくトンネル詳細
を明らかにします。
4.1. Information Requirements
4.1. 情報必要条件
The protocol consists of probes and probe responses. Each probe
elicits exactly one response. Each response represents a hop that
contributes to the path between two interfaces. A hop can be either
a top-level IP hop or lower-level hop that is contained by a tunnel.
プロトコルは調査と調査回答から成り立ちます。それぞれの調査が正確に１
つの回答を引き出します。それぞれの回答が２つのインタフェース間のパス
のホップを表します。ホップは上位ＩＰホップか、トンネルに含まれる下位
レベルホップであり得ます。
Justification: Because the generic route-tracing application must
trace through broken paths, the required protocol must use a separate
response message to deliver details regarding each hop. The protocol
must use a separate probe to elicit each response because the
alternative approach, using the single probe with the IP Router Alert
Option, is unacceptable. Many networks forward datagrams that
specify IP options differently than they would forward datagrams that
do not specify IP options. Therefore, the introduction of IP options
would cause the application to trace a forwarding path other than the
path that its user intended to trace.
正当化：一般的経路追跡アプリケーションが障害経路を通して追跡をしなく
てはならないから、必要とされるプロトコルはそれぞれのホップに関して詳
細を届ける別の回答メッセージを使わなくてはなりません。ＩＰルータ警告
オプションを使ってひとつの探索で終わらせる代わりのアプローチは受け入
れ難いから、プロトコルはそれぞれの回答を引き出すために別の探索を使わ
なくてはなりません。多くのネットワークはＩＰオプションを指定しないデー
タグラムを送るのとＩＰオプションを指定するデータグラムで異なる転送を
します。それ故に、ＩＰオプションの利用はユーザが追跡するつもりであっ
た経路以外にアプリケーションを転送経路を追跡させるでしょう。
4.2. Transport Layer Requirements
4.2. トランスポートレイヤ必要条件
UDP should carry all protocol messages to their destinations. Other
transport mechanisms may be considered when protocol details are
specified.
ＵＤＰはそれらの宛先へすべてのプロトコルメッセージを運ぶべきです。プ
ロトコル詳細を指定する時、他のトランスポートメカニズムが考えられるか
もしれません。
Justification: Because the probe/response scheme described above is
stateless, a stateless transport is required. Candidate transports
included UDP over IP, IP and ICMP. ICMP was disqualified because
carrying MPLS information in an ICMP datagram would constitute a
layer violation. IP was disqualified in order to conserve protocol
identifiers.
正当化：上記調査／応答機構はステートレスで、ステートレストランスポー
トが必要とされます。候補となるトランスポートはＩＰ上のＵＤＰかＩＰか
ＩＣＭＰを含みます。ＩＣＭＰは、ＩＣＭＰデータグラムでＭＰＬＳ情報を
運ぶことがレイヤ違反を生成するであろうから、不適格とされました。ＩＰ
はプロトコル識別子を節約するために不適格とされました。
4.3. Stateless Protocol
4.3. ステートレスプロトコル
The protocol must be stateless. That is, nodes should not have to
maintain state between successive traceroute messages.
プロトコルはステートレスであるに違いありません。すなわち、ノードが連
続したtracerouteメッセージ間で状態をもつべきではありません。
Justification: Statelessness is required to support scaling and to
prevent denial of service attacks.
正当化：ステートレスがスケール性をサポートし、サービス妨害攻撃を妨げ
るので、要求されます。
4.4. Routing Requirements
4.4. ルーティング必要条件
The device that hosts the route-tracing application must maintain an
IP route to the ingress of the traced path. It must also maintain an
IP route to the ingress of each tunnel for which it is requesting
tunnel details. The device that hosts the tunnel tracing application
need not maintain a route to any other device that supports the
traced path.
経路追跡アプリケーションを実行する装置は追跡経路の出口のＩＰ経路を維
持しなくてはなりません。これはトンネル詳細を求めているそれぞれのトン
ネルの入口でＩＰ経路を維持しなくてはなりません。トンネルを追跡してい
るアプリケーションのホストとして機能する装置は追跡経路をサポートする
他の装置の経路を維持する必要がありません。
All of the devices to which the route-tracing application must
maintain a route must maintain a route back to the route-tracing
application.
経路追跡アプリケーションが経路を維持しなくてはならない装置のすべてが、
経路追跡アプリケーションのために経路を維持しなくてはなりません。
In order for the protocol to provide tunnel details, all devices
contained by a tunnel must maintain an IP route to the tunnel
ingress.
プロトコルがトンネルの詳細を供給するために、すべてのトンネルに含まれ
る装置はトンネル入口へのＩＰ経路を維持しなくてはなりません。
Justification: The protocol must be sufficiently robust to operate
when tunnel interior devices do not maintain a route back to the
device that hosts the route tracing application.
正当化：トンネル内部装置が経路追跡アプリケーションのホストとして機能
する装置に戻る経路を維持しない時、プロトコルは運用に十分に強靭である
に違いありません。
5. Security Considerations
5. セキュリティの考察
A configurable access control policy determines the degree to which
features described herein are delivered. The access control policy
requires user identification and authorization.
設定可能なアクセス制御ポリシがここに記述された機能が動作する程度を決
定します。アクセス制御ポリシはユーザ識別と認可を必要とします。
The new protocol must not introduce security holes nor consume
excessive resources (e.g., CPU, bandwidth). It also must not be
exploitable by those launching DoS attacks or replaying messages.
新しいプロトコルはセキュリティ・ホールを導入したり、極端な資源消費を
してはなりません（例えば、ＣＰＵ、バンド幅）。同じくサービス妨害攻撃
やメッセージ再生攻撃に利用できてはなりません。
6. Informative References
6. 有益な参考文献
[RFC-2151] Kessler, G. and S. Shepard, "A Primer On Internet and
TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.
[RFC-2925] White, K., "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", RFC 2925,
September 2000.
7. Acknowledgements
7. 謝辞
Thanks to Randy Bush and Steve Bellovin for their comments.
Randy BushとSteve Bellovinにコメントを感謝します。
8. Authors' Addresses
8. 著者のアドレス
Ronald P. Bonica
MCI
22001 Loudoun County Pkwy
Ashburn, Virginia, 20147
EMail: ronald.p.bonica@mci.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, California 94089
EMail: kireeti@juniper.net
David Meyer
EMail: dmm@maoz.com
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (2003). 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 assignees.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。