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.

著作権(C)インターネット協会(2003)。全著作権所有。

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.

この文書では、一般的なルート追跡アプリケーションの要件を指定します。また、そのアプリケーションをサポートするプロトコルのための要件を指定します。ネットワークオペレータは、IPフォワーディングプレーンの適切な動作を検証するために、一般的なルート追跡アプリケーションを使用します。彼らはまた、IP転送をサポートするトンネルに関する詳細を発見するためにアプリケーションを使用します。

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.

ここに指定ジェネリックルート追跡アプリケーションは、「トレースルート」は、現在提供している機能のスーパーセットをサポートしています。トレースルートのように、一般的な経路追跡アプリケーションは、IPネットワークに含まれている2つのインタフェース間の転送パスを発見することができます。トレースルートとは異なり、このアプリケーションでは、IP転送パスをサポートするトンネルに関する詳細を明らかにすることができます。

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.

IPネットワークは、いくつかのトンネリング技術を利用しています。これらのトンネリング技術は、多くの便利な機能をオペレータに提供しますが、彼らはまた、経営上の課題を提示します。ネットワークオペレータは、彼らがIPフォワーディングプレーンの正しい動作を検証するために使用することができ、一般的なルート追跡アプリケーションが必要です。一般的な経路追跡アプリケーションは、トンネルを検出し、トンネルの詳細を明らかにすることができなければなりません。アプリケーションはまた、トンネル障害を診断するのに有用でなければなりません。

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.

現在、ネットワークオペレータは、IPネットワークの転送パスをトレースするために「トレースルート」を使用します。 [RFC-2151]のセクション3.4は、トレースルートの完全な説明を提供します。トレースルートは非常に信頼性が高く、非常に広く普及しているが、それはトンネルのトレースに関しては不十分です。

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.

トンネルタイプに応じて、トレースルートは、単一のIPホップとして全体のトンネルを表示することができる、またはIPのコレクションは、それらがトンネルの一部であることを示すことなく、ホップとしてトンネルを表示してもよいです。

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.

例えば、エンジニアは、IPネットワーク内のIPトンネルを展開すると仮定する。入口ルータは、外側IPヘッダに内側IPヘッダのTTL値をコピーしないように、それらはトンネルを設定すると仮定する。代わりに、入口ルータは、常にその最大許容値に外側TTL値を設定します。エンジニアがネットワークをトレースすると、トレースルートは常に出力インターフェイス以外のすべてのコンポーネントを隠し、単一のIPホップとしてトンネルが表示されます。

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.

今、エンジニアは、IPネットワーク内のMPLS LSPを展開することを前提としています。入口ルータは、MPLSヘッダにIPヘッダのTTL値を伝播するようにエンジニアがMPLS LSPを設定すると仮定する。エンジニアがネットワークを介してトレースする際IP一連のホップとして、トレースルートは、それらがトンネルの一部であることを示すことなく、LSPが表示されます。

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).

1)トンネルトレース要求の一部としてセキュリティ・トークンの概念をサポートします。セキュリティトークンは、トンネルをトレースするにはトレーサーの権限を識別します。ネットワーク要素は、トレーサーに要求された情報を返すかどうかを決定するために、このセキュリティトークンを使用します。具体的には、適切な権限は、アイテムのために必要とされる(2)、(3)、(6)、(8)、(10)、(13)、及び(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.

2)サポートインライントレース。インライントレースルート追跡アプリケーションが実行される時にホストとIPネットワーク内の任意のインタフェース間の経路を明らかにする。

Justification: Operators need to discover how the network would forward a datagram between any two IP interfaces.

正当化:オペレータは、ネットワークが任意の2つのIPインタフェース間のデータグラムを転送する方法を発見する必要があります。

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.

3)サードパーティのトレースをサポートしています。サードパーティのトレースは、IPネットワーク内の任意の2点間の経路を明らかにする。サードパーティのトレースを開始したアプリケーションは、トレースパスの一部であるホストまたはルータ時に実行する必要はありません。既存のソリューション[RFC-2151] [RFC-2925]とは異なり、アプリケーションはIPオプションに依存しないであろうか、サードパーティのトレースをサポートするために、SNMPエージェントにアクセスする必要があります。

Justification: Operators need to discover how the network would forward a datagram between any two IP interfaces.

正当化:オペレータは、ネットワークが任意の2つのIPインタフェース間のデータグラムを転送する方法を発見する必要があります。

4) Support partial traces through broken paths or tunnels.

4)壊れたパスまたはトンネルを通して部分的トレースを支援します。

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.

いずれかのインライントレースまたはサードパーティのトレースの一部として、トンネルを介してトレースする場合5)、単一のIPホップとして、または詳細のいずれかのトンネルを表示します。ユーザの要求は、アプリケーションがこれを行うための権限を持つユーザーに対象のトンネルを、どのように表示するかを決定します。

Justification: As they discover IP forwarding details, operators may need to reveal or mask tunneling details.

正当化:彼らはIP転送の詳細を発見すると、事業者は、トンネルの詳細を明らかにするか、マスクする必要があるかもしれません。

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.

詳細にトンネルを表示するとき6)、トンネル型(例えば、GRE、MPLS)、トンネル名(該当する場合)、トンネル識別子(該当する場合)、トンネルエンドポイントアドレスを含みます。また、各成分を横切るトンネル成分及びラウンドトリップ遅延を含みます。

Justification: As they discover IP forwarding details, operators may need to reveal tunneling details.

正当化:彼らはIP転送の詳細を発見すると、事業者は、トンネルの詳細を明らかにする必要があるかもしれません。

7) Support the following tunneling technologies: GRE, MPLS, IPSEC, GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel technologies.

GRE、MPLS、IPSEC、GMPLS、IP-で-IP、L2TP:7)以下のトンネリング技術をサポートしています。新しいトンネル技術をサポートするように容易に拡張可能です。

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.

正当化:オペレータは、IPネットワークがデータグラムを転送する方法を発見するために、一般的なルート追跡アプリケーションを使用します。多くのトンネルタイプがIPネットワークをサポートすることができるように、一般的な経路追跡アプリケーションを検出し、複数のトンネルタイプに関する詳細を明らかにしなければなりません。

8) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP over MPLS).

ネストされた、異種トンネルを介して8)トレース(例えば、IPインIP 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.

正当化:オペレータは、IPネットワークがデータグラムを転送する方法を発見するために、一般的なルート追跡アプリケーションを使用します。ネストされたとして、異種のトンネルは、IPネットワークをサポートすることができ、一般的なルート追跡アプリケーションを検出し、ネストされた、異種のトンネルに関する詳細を明らかにしなければなりません。

9) At the users request, trace through the forwarding plane, the control plane or both.

9)ユーザ要求時に、転送プレーン、制御プレーンまたは両方を介してトレース。

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.

10)すべてのトンネルタイプのトレース制御プレーンをサポート。コントロールプレーンを介しトレースするとき、ホップ進入デバイスは、ホップの詳細を報告します。ホップ進入デバイスは、ホップを発信するデバイスです。

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.

TTLをデクリメント(またはいくつかの同様の機構)を実装するすべてのトンネルタイプのプレーンの転送を介してトレース11)のサポート。フォワーディングプレーンを通じてトレースするとき、ホップ出口デバイスは、ホップの詳細を報告します。ホップ出口デバイスは、ホップを終了デバイスです。

Justification: Forwarding plane information may not be available for tunnels that do not support TTL decrement.

正当化:平面情報を転送すると、TTLの減少をサポートしていないトンネルに使用できない場合があります。

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.)

関係なく、トンネルがTTL伝播に従事するかどうかの、TTLの減少を実現するすべてのトンネルタイプの転送プレーンを介してトレース12)サポート。 (すなわち、関係なく、TTL値を内部ヘッダからトンネル入口で外部ヘッダにコピーされているか否かのトレース支持トンネルです。)

Justification: Forwarding plane information is always available, regardless of whether the tunnel engages in TTL propagation.

正当化:転送プレーンの情報にかかわらず、トンネルがTTL伝播に従事するかどうかを、常に利用可能です。

13) When tracing through the control plane, display the MTU associated with each interface that forwards datagrams through the traced path.

制御プレーンを介してトレースするとき13)、トレース経路を介してデータグラムを転送する各インターフェースに関連付けられたMTUを表示します。

Justification: MTU information is sometimes useful in identifying the root cause of forwarding and control plane failures.

正当化:MTU情報は、転送と制御プレーン障害の根本原因を識別するのに便利な場合があります。

14) When tracing through the forwarding plane, display the MTU associated with each interface that receives datagrams along the traced path.

転送プレーンを介してトレースするとき14)、トレースの経路に沿ってデータグラムを受信する各インタフェースに関連付けられたMTUを表示します。

Justification: MTU information is sometimes useful in identifying the root cause of forwarding and control plane failures.

正当化:MTU情報は、転送と制御プレーン障害の根本原因を識別するのに便利な場合があります。

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.

15)一般的な経路追跡のためのプロトコルサポートを提供していないデバイスを含む経路を介して部分的なトレースを支援します。アプリケーションは、このようなデバイスを検出すると、ユーザーに通知し、下流の次のインタフェースに関する詳細を発見しようとしなければなりません。

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.

実装者は、一般的なルート追跡アプリケーションをサポートする新しいプロトコルが必要です。このプロトコルは、IPネットワークの2点間の経路を明らかにする。場合アクセスポリシー許可、プロトコルは、トンネルの詳細を明らかにする。

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.

プロトコルは、プローブおよびプローブ応答から成ります。各プローブは、1つの応答を誘発します。各応答は、二つのインタフェース間の経路に寄与するホップを表します。ホップは、トップレベルのIPホップ又はトンネルに含まれる低レベルのホップのいずれかであり得ます。

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.

正当化:一般的な経路追跡アプリケーションが壊れパスをトレースする必要があるため、必要なプロトコルが各ホップに関する詳細を提供するために別々の応答メッセージを使用しなければなりません。プロトコルは、IPルータ警告オプションで単一のプローブを使用して、別のアプローチので、各応答を誘発するために別個のプローブを使用する必要があり、許容できません。多くのネットワークは、彼らがIPオプションを指定しないデータグラムを転送するよりも、異なるIPオプションを指定するデータグラムを転送します。そのため、IPオプションの導入は、そのユーザーが追跡することを目的とパス以外の転送パスをトレースするアプリケーションを引き起こします。

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.

UDPは、彼らの宛先にすべてのプロトコルメッセージを伝える必要があります。プロトコルの詳細が指定されているときに他のトランスポート機構が考えられます。

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.

正当化:上記プローブ/レスポンス方式がステートレスであるため、ステートレス輸送が必要です。候補トランスポートはIP、IPおよびICMPの上にUDPが含まれています。 ICMPデータグラムにMPLS情報を担持する層の違反を構成することになるので、ICMPは失格しました。 IPは、プロトコル識別子を節約するために失格とされました。

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.

トレースされた経路の入口にIPルートを維持しなければならない経路追跡アプリケーションをホストするデバイス。それはまた、トンネルの詳細を要求された各トンネルの入口にIPルートを維持しなければなりません。トンネルトレースアプリケーションをホストデバイスが追跡パスをサポートする他のデバイスへのルートを維持する必要はありません。

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.

トンネルの詳細を提供するプロトコルのために、トンネルに含まれるすべてのデバイスがトンネル入口にIPルートを維持しなければなりません。

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.

新しいプロトコルは、セキュリティホールを導入したり、過剰なリソース(例えば、CPU、帯域幅)を消費してはなりません。また、DoS攻撃を起動するか、メッセージを再生することにより、これらの攻撃可能であってはなりません。

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-2151]ケスラー、G.とS.シェパード、 "インターネットとTCP / IPツールおよびユーティリティの手引き"、FYI 30、RFC 2151、1997年6月。

[RFC-2925] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000.

[RFC-2925]ホワイト、K.、RFC 2925 "リモートピング、トレースルート、およびルックアップ操作のための管理オブジェクトの定義"、2000年9月。

7. Acknowledgements
7.謝辞

Thanks to Randy Bush and Steve Bellovin for their comments.

彼らのコメントのためのランディブッシュとスティーブBellovin氏に感謝します。

8. Authors' Addresses
8.著者のアドレス

Ronald P. Bonica MCI 22001 Loudoun County Pkwy Ashburn, Virginia, 20147

ロナルドP. Bonica MCI 22001ラウドン郡パークウェイアッシュバーン、バージニア州、20147

EMail: ronald.p.bonica@mci.com

メールアドレス:ronald.p.bonica@mci.com

Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089

Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、カリフォルニア94089

EMail: kireeti@juniper.net

メールアドレス:kireeti@juniper.net

David Meyer

デビッド・マイヤー

EMail: dmm@maoz.com

メールアドレス:dmm@maoz.com

9. Full Copyright Statement
9.完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

著作権(C)インターネット協会(2003)。全著作権所有。

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.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。