RFC3609 日本語訳
3609 Tracing Requirements for Generic Tunnels. R. Bonica, K. Kompella,D. Meyer. September 2003. (Format: TXT=17859 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Bonica
Request for Comments: 3609 MCI
Category: Informational K. Kompella
Juniper Networks
D. Meyer
Sprint
September 2003
Bonicaがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3609年のMCIカテゴリ: 情報のK.Kompella杜松ネットワークD.マイヤーは2003年9月に全速力で走ります。
Tracing Requirements for Generic Tunnels
Generic Tunnelsのための追跡要件
Status of this Memo
この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.
Copyright(C)インターネット協会(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.
このドキュメントはルートをたどるジェネリックアプリケーションのための要件を指定します。 また、それはそのアプリケーションをサポートするプロトコルのための要件を指定します。 ネットワーク・オペレータは、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推進飛行機の正しい操作について確かめるのに使用できるルートをたどるジェネリックアプリケーションを必要とします。 ルートをたどるジェネリックアプリケーションはトンネルと顕なトンネルの詳細を検出できなければなりません。 アプリケーションもトンネル欠点を診断する際に役に立つに違いありません。
Bonica, et al. Informational [Page 1] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[1ページ]のRFC3609
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を配布すると仮定してください。 また、イングレスルータがIPヘッダーからMPLSヘッダーまでTTL値を伝播するように、技術者がMPLS LSPを構成すると仮定してください。 いつがネットワークを通して跡を設計するか、そして、IPのシリーズが跳ぶとき、トレースルートはLSPを表示するでしょう、それらがトンネルの一部であることを示さない。
Bonica, et al. Informational [Page 2] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[2ページ]のRFC3609
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.
ネットワーク・オペレータは新しいルートをたどるアプリケーションを必要とします。 新しいアプリケーションはトレースルートが現在提供するすべての機能性をサポートしなければなりません。 また、それは高められたトンネル追跡能力を提供しなければなりません。
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ホップか詳細のどちらかにトンネルを表示してください。 ユーザの要求は、アプリケーションがどのようにこれをする許可を持っているユーザを条件としてトンネルを表示するかを決定します。
Bonica, et al. Informational [Page 3] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[3ページ]のRFC3609
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.
7) 以下のトンネリングが技術であるとサポートしてください: GRE、MPLS、IPSEC、GMPLS、IPにおけるIP、L2TP。 新しいトンネル技術をサポートするのにおいて容易に広げることができてください。
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) 入れ子にされて、異種のトンネルを通って(例えば、MPLSの上の中のIP IP)をたどってください。
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.
正当化: コントロール飛行機情報はすべてのトンネルタイプに関して利用可能です。
Bonica, et al. Informational [Page 4] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[4ページ]のRFC3609
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.
11) すべてのトンネルへの推進飛行機を通したサポートのたどるのはTTLが減少させるその道具(または、何らかの同様のメカニズム)をタイプします。 推進飛行機を通してたどるとき、ホップ出口デバイスレポートは詳細を飛び越します。 ホップ出口デバイスはホップを終えるデバイスです。
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.)
12) すべてのトンネルへの推進飛行機を通したサポートのたどるのは、トンネルがTTLに従事しているかどうかにかかわらず道具TTLが伝播を減少させるのをタイプします。 (すなわち、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ポイントの間の経路を明らかにします。 また、アクセス方針が可能にすると、プロトコルはトンネルの詳細を明らかにします。
Bonica, et al. Informational [Page 5] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[5ページ]のRFC3609
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つの応答を引き出します。 各応答は2つのインタフェースの間の経路に貢献するホップを表します。 ホップは、トップレベル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 Router Alert Optionとのただ一つの探測装置を使用して、代替的アプローチが容認できないので各応答を引き出すのに別々の探測装置を使用しなければなりません。 と異なって多くのネットワークが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.
プロトコルは状態がないに違いありません。 すなわち、ノードは連続したトレースルートメッセージの間の状態を維持するはずである必要はありません。
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ルートを維持しなければなりません。 トンネル追跡アプリケーションを主催するデバイスはたどられた経路をサポートするいかなる他のデバイスにもルートを維持する必要はありません。
Bonica, et al. Informational [Page 6] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[6ページ]のRFC3609
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ツール、およびユーティリティに関する入門書」、FYI30、RFC2151、1997年6月。
[RFC-2925] White, K., "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", RFC 2925,
September 2000.
[RFC-2925]ホワイト、K.、「リモートピング、トレースルート、およびルックアップ操作のための管理オブジェクトの定義」、RFC2925、2000年9月。
7. Acknowledgements
7. 承認
Thanks to Randy Bush and Steve Bellovin for their comments.
彼らのコメントをランディ・ブッシュとスティーブBellovinをありがとうございます。
Bonica, et al. Informational [Page 7] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[7ページ]のRFC3609
8. Authors' Addresses
8. 作者のアドレス
Ronald P. Bonica MCI 22001 Loudoun County Pkwy Ashburn, Virginia, 20147
Pkwy Ashburn、ロナルドP.Bonica MCI22001Loudounカウンティーのヴァージニア 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杜松はInc.1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
David Meyer
デヴィッド・マイヤー
EMail: dmm@maoz.com
メール: dmm@maoz.com
Bonica, et al. Informational [Page 8] RFC 3609 Tracing Requirements for Generic Tunnels September 2003
Bonica、他 2003年9月にGeneric Tunnelsのための要件をたどる情報[8ページ]のRFC3609
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Bonica, et al. Informational [Page 9]
Bonica、他 情報[9ページ]
一覧
スポンサーリンク
