RFC2983 日本語訳
2983 Differentiated Services and Tunnels. D. Black. October 2000. (Format: TXT=35644 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Black Request for Comments: 2983 EMC Corporation Category: Informational October 2000
コメントを求めるワーキンググループのD.の黒い要求をネットワークでつないでください: 2983年のEMC社のカテゴリ: 情報の2000年10月
Differentiated Services and 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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document considers the interaction of Differentiated Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.
このドキュメントは様々な形式のIPトンネルとのDifferentiated Services(diffserv)(RFC2474、RFC2475)の相互作用を考えます。diffserv構造(RFC2475)における、トンネルの議論はトンネルのデザイナーとimplementersに不十分な指導を供給します。 このドキュメントは、インターネットプロトコル(IP)トンネルとのdiffservの相互作用のために2人の概念モデルについて説明して、機能性の結果として起こる構成と組み合わせについて調査するのにそれらを使います。 重要な考慮すべき事柄は、トンネルカプセル化と被膜剥離術があるときdiffserv交通調節を実行するのが適切であるどのように、ところであるか。 また、トンネルが別の方法でdiffserv交通調節モデルに追加する複雑さを制限するいくつかの簡単なメカニズムが提案されます。 IPSecトンネルへのセキュリティ問題はいくつかの事情の可能な機能性を制限します。
1. Conventions used in this document
1. 本書では使用されるコンベンション
An IP tunnel encapsulates IP traffic in another IP header as it passes through the tunnel; the presence of these two IP headers is a defining characteristic of IP tunnels, although there may be additional headers inserted between the two IP headers. The inner IP header is that of the original traffic; an outer IP header is attached and detached at tunnel endpoints. In general, intermediate network nodes between tunnel endpoints operate solely on the outer IP header, and hence diffserv-capable intermediate nodes access and modify only the DSCP field in the outer IP header. The terms "tunnel" and "IP tunnel" are used interchangeably in this document. For simplicity, this document does not consider tunnels other than IP tunnels (i.e., for which there is no encapsulating IP header), such
トンネルを通り抜けるのに従って、IPトンネルは別のIPヘッダーのIP交通を要約します。 これらの2個のIPヘッダーの存在はIPトンネルの定義の特性です、2個のIPヘッダーの間に挿入された追加ヘッダーがあるかもしれませんが。 内側のIPヘッダーは元の交通のものです。 外側のIPヘッダーは、トンネル終点で取り付けられて、取り外されます。 一般に、トンネル終点の間の中間ネットワークノードが唯一外側のIPヘッダーを手術して、したがって、diffservできる中間的ノードは、外側のIPヘッダーのDSCP分野だけにアクセスして、変更します。 用語「トンネル」と「IPトンネル」は互換性を持って本書では使用されます。 簡単さのために、このドキュメントはIPトンネル(すなわち、要約のIPヘッダーが全くない)以外のトンネルを考えません、そのようなもの
Black Informational [Page 1] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[1ページ]のRFC2983DiffservとTunnels2000年10月
as MPLS paths and "tunnels" formed by encapsulation in layer 2 (link) headers, although the conceptual models and approach described here may be useful in understanding the interaction of diffserv with such tunnels.
MPLSとして、経路と「トンネル」は層2の(リンク)ヘッダーでカプセル化によって形成されました、ここで説明された概念モデルとアプローチはそのようなトンネルとのdiffservの相互作用を理解する際に役に立つかもしれませんが。
This analysis considers tunnels to be unidirectional; bi-directional tunnels are considered to be composed of two unidirectional tunnels carrying traffic in opposite directions between the same tunnel endpoints. A tunnel consists of an ingress where traffic enters the tunnel and is encapsulated by the addition of the outer IP header, an egress where traffic exits the tunnel and is decapsulated by the removal of the outer IP header, and intermediate nodes through which tunneled traffic passes between the ingress and egress. This document does not make any assumptions about routing and forwarding of tunnel traffic, and in particular assumes neither the presence nor the absence of route pinning in any form.
この分析は、トンネルが単方向であると考えます。 それぞれ反対の方向に同じトンネル終点の間の交通を運ぶ2つの単方向のトンネルで双方向のトンネルが構成されると考えられます。 交通がトンネルに入って、外側のIPヘッダー(交通がトンネルを出て、外側のIPヘッダー、およびトンネルを堀られた交通がイングレスと出口の間を通り過ぎる中間的ノードの取り外しでdecapsulatedされる出口)の追加で要約されるところでトンネルはイングレスから成ります。 このドキュメントは、トンネル交通のルーティングと推進に関する少しの仮定もしないで、またどんなフォームが、存在もルートのピンで止めることの不在も特に仮定しません。
2. Diffserv and Tunnels Overview
2. DiffservとTunnels Overview
Tunnels range in complexity from simple IP-in-IP tunnels [RFC 2003] to more complex multi-protocol tunnels, such as IP in PPP in L2TP in IPSec transport mode [RFC 1661, RFC 2401, RFC 2661]. The most general tunnel configuration is one in which the tunnel is not end- to-end, i.e., the ingress and egress nodes are not the source and destination nodes for traffic carried by the tunnel; such a tunnel may carry traffic with multiple sources and destinations. If the ingress node is the end-to-end source of all traffic in the tunnel, the result is a simplified configuration to which much of the analysis and guidance in this document are applicable, and likewise if the egress node is the end-to-end destination.
トンネルは簡単なIPにおけるIPトンネル[RFC2003]から、より複雑なマルチプロトコルトンネルまで複雑さのねらいを定めます、IPSec交通機関[RFC1661、RFC2401、RFC2661]によるL2TPのPPPのIPなどのように。 すなわち、イングレスと出口ノードは、トンネルによって運ばれた交通のための最も一般的なトンネル構成がトンネルが終わりから終わりでないものであり、ソースとまたは目的地ノードではありません。 そのようなトンネルは複数のソースと目的地で交通を運ぶかもしれません。 イングレスノードが終わりから終わりへのトンネルのすべての交通の源であるなら、結果は本書では分析と指導の多くがどれであるかに適切な簡易型の構成と同様に、出口ノードが終わりから端への目的地であるかどうかということです。
A primary concern for differentiated services is the use of the Differentiated Services Code Point (DSCP) in the IP header [RFC 2474, RFC 2475]. The diffserv architecture permits intermediate nodes to examine and change the value of the DSCP, which may result in the DSCP value in the outer IP header being modified between tunnel ingress and egress. When a tunnel is not end-to-end, there are circumstances in which it may be desirable to propagate the DSCP and/or some of the information that it contains to the outer IP header on ingress and/or back to inner IP header on egress. The current situation facing tunnel implementers is that [RFC 2475] offers incomplete guidance. Guideline G.7 in Section 3 is an example, as some PHB specifications have followed it by explicitly specifying the PHBs that may be used in the outer IP header for tunneled traffic. This is overly restrictive; for example, if a specification requires that the same PHB be used in both the inner and outer IP headers, traffic conforming to that specification cannot be tunneled across domains or networks that do not support that PHB.
微分されたサービスに関する第一の心配はIPヘッダー[RFC2474、RFC2475]でDifferentiated Services Code Point(DSCP)の使用です。 diffserv構造は、中間的ノードがトンネルイングレスと出口の間で変更されながら外側のIPヘッダーでDSCP値をもたらすかもしれないDSCPの値を調べて、変えるのを許容します。 トンネルが終わらせる終わりでないとき、出口でDSCP、そして/または、それがイングレスの外側のIPヘッダー内側のIPヘッダーに含んで戻す情報何らかの伝播するのが望ましいかもしれない事情があります。 現在の状況の面しているトンネルimplementersは[RFC2475]が不完全な指導を提供するということです。 セクション3におけるガイドラインG.7は例です、明らかにトンネルを堀られた交通に外側のIPヘッダーで使用されるかもしれないPHBsを指定することによっていくつかのPHB仕様がそれに続いたとき。 これはひどく制限しています。 例えば、仕様が、同じPHBが両方の内側の、そして、外側のIPヘッダーで使用されるのを必要とするなら、そのPHBを支持しないドメインかネットワークの向こう側にその仕様に従う交通にトンネルを堀ることができません。
Black Informational [Page 2] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[2ページ]のRFC2983DiffservとTunnels2000年10月
A more flexible approach that should be used instead is to describe the behavioral properties of a PHB that are important to preserve when traffic is tunneled and allow the outer IP header to be marked in any fashion that is sufficient to preserve those properties.
代わりに使用されるべきであるよりフレキシブルなアプローチは、PHBの交通がトンネルを堀られるとき保存するために重要な行動の特性について説明して、外側のIPヘッダーがどんなそれらの特性を保持するために十分なファッションでもマークされるのを許容することです。
This document proposes an approach in which traffic conditioning is performed in series with tunnel ingress or egress processing, rather than in parallel. This approach does not create any additional paths that transmit information across a tunnel endpoint, as all diffserv information is contained in the DSCPs in the IP headers. The IPSec architecture [RFC 2401] requires that this be the case to preserve security properties at the egress of IPSec tunnels, but this approach also avoids complicating diffserv traffic conditioning blocks by introducing out-of-band inputs. A consequence of this approach is that the last sentence of Guideline G.7 in Section 3 of [RFC 2475] becomes moot because there are no tunnel egress diffserv components that have access to both the inner and outer DSCPs.
このドキュメントは交通調節が連続的に平行よりむしろトンネルイングレスか出口処理で実行されるアプローチを提案します。 このアプローチはトンネル終点の向こう側に情報を送るどんな追加経路も作成しません、すべてのdiffserv情報がIPヘッダーにDSCPsに含まれているとき。 IPSec構造[RFC2401]は、IPSecトンネルの出口にセキュリティの特性を保持するためにこれがそうであることを必要としますが、また、このアプローチは、バンドの外で入力を導入することによってdiffserv交通調節ブロックを複雑にするのを避けます。 このアプローチの結果は両方の内側の、そして、外側のDSCPsに近づく手段を持っているトンネルの出口のdiffservの部品が全くないので[RFC2475]のセクション3における、Guideline G.7に関する最後の文が論争中になるということです。
An additional advantage of this traffic conditioning approach is that it places no additional restrictions on the positioning of diffserv domain boundaries with respect to traffic conditioning and tunnel encapsulation/decapsulation components. An interesting class of configurations involves a diffserv domain boundary that passes through (i.e., divides) a network node; such a boundary can be split to create a DMZ-like region between the domains that contains the tunnel encapsulation or decapsulation processing. Diffserv traffic conditioning is not appropriate for such a DMZ-like region, as traffic conditioning is part of the operation and management of diffserv domains.
この交通がアプローチを条件とさせる追加利点はdiffservドメイン境界の位置決めに関して交通調節とトンネルカプセル化/被膜剥離術コンポーネントに関してどんな追加制限も課さないということです。 おもしろいクラスの構成はネットワーク・ノードを通り抜ける(すなわち、分割します)diffservドメイン境界にかかわります。 ドメインの間のトンネルカプセル化か被膜剥離術処理を含むDMZのような領域を作成するためにそのような境界を分けることができます。 そのようなDMZのような領域には、Diffserv交通調節が適切ではありません、交通調節が操作の一部とdiffservドメインの管理であるので。
3. Conceptual Models for Diffserv Tunnels
3. Diffserv Tunnelsのための概念モデル
This analysis introduces two conceptual traffic conditioning models for IP tunnels based on an initial discussion that assumes a fully diffserv-capable network. Configurations in which this is not the case are taken up in Section 3.2.
この分析はdiffserv完全にできるネットワークを仮定する初期の議論に基づくIPトンネルを2つの概念的な交通調節モデルに紹介します。 これがそうでない構成はセクション3.2で始められます。
3.1 Conceptual Models for Fully DS-capable Configurations
3.1 DS完全にできる構成のための概念的なモデル
The first conceptual model is a uniform model that views IP tunnels as artifacts of the end to end path from a traffic conditioning standpoint; tunnels may be necessary mechanisms to get traffic to its destination(s), but have no significant impact on traffic conditioning. In this model, any packet has exactly one DS Field that is used for traffic conditioning at any point, namely the DS Field in the outermost IP header; any others are ignored. Implementations of this model copy the DSCP value to the outer IP header at encapsulation and copy the outer header's DSCP value to the
第1代概念モデルは交通調節見地からIPトンネルを経路を終わらせる終わりの人工物であるとみなす一定のモデルです。 トンネルは目的地に交通を届ける必要なメカニズムであるかもしれませんが、交通調節に重要な変化も与えないでください。 このモデルでは、どんなパケットも一番はずれのIPヘッダーに任意な点での交通調節に使用される、1DS Field、ちょうどすなわち、DS Fieldを持っています。 どんな他のものも無視されます。 このモデルの実現は、カプセル化で外側のIPヘッダーにDSCP値をコピーして、外側のヘッダーのDSCP値をコピーします。
Black Informational [Page 3] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[3ページ]のRFC2983DiffservとTunnels2000年10月
inner IP header at decapsulation. Use of this model allows IP tunnels to be configured without regard to diffserv domain boundaries because diffserv traffic conditioning functionality is not impacted by the presence of IP tunnels.
被膜剥離術における内側のIPヘッダー。 diffserv交通調節の機能性がIPトンネルの存在によって影響を与えられないので、このモデルの使用は、IPトンネルが関係なしでdiffservドメイン境界に構成されるのを許容します。
The second conceptual model is a pipe model that views an IP tunnel as hiding the nodes between its ingress and egress so that they do not participate fully in traffic conditioning. In this model, a tunnel egress node uses traffic conditioning information conveyed from the tunnel ingress by the DSCP value in the inner header, and ignores (i.e., discards) the DSCP value in the outer header. The pipe model cannot completely hide traffic conditioning within the tunnel, as the effects of dropping and shaping at intermediate tunnel nodes may be visible at the tunnel egress and beyond.
第2代概念モデルがそのイングレスと出口の間にノードを隠すとIPトンネルをみなすパイプモデルであるので、それらは完全に交通調節に参加するというわけではありません。 このモデルでは、トンネル出口ノードは、内側のヘッダーでDSCP値によってトンネルイングレスから伝えられた交通調節情報を使用して、外側のヘッダーでDSCP値を無視します(すなわち、捨てます)。 パイプモデルは完全にトンネル出口における向こうの中間的トンネルノードで低下して、形成するという効果が目に見えるかもしれないのでトンネルの中で条件とする交通を隠すことができるというわけではありません。
The pipe model has traffic conditioning consequences when the ingress and egress nodes are in different diffserv domains. In such a situation, the egress node must perform traffic conditioning to ensure that the traffic exiting the tunnel has DSCP values acceptable to the egress diffserv domain (see Section 6 of the diffserv architecture [RFC 2475]). An inter-domain TCA (Traffic Conditioning Agreement) between the diffserv domains containing the tunnel ingress and egress nodes may be used to reduce or eliminate egress traffic conditioning. Complete elimination of egress traffic conditioning requires that the diffserv domains at ingress and egress have compatible service provisioning policies for the tunneled traffic and support all of the PHB groups and DSCP values used for that traffic in a consistent fashion. Examples of this situation are provided by some virtual private network tunnels; it may be useful to view such tunnels as linking the diffserv domains at their endpoints into a diffserv region by making the tunnel endpoints virtually contiguous even though they may be physically separated by intermediate network nodes.
イングレスと出口ノードが異なったdiffservドメインにあるとき、パイプモデルには、交通調節結果があります。 そのような状況で、出口ノードは、トンネルを出る交通でDSCP値が出口diffservドメインに許容できるようになるのを保証するために交通調節を実行しなければなりません(diffserv構造[RFC2475]のセクション6を見てください)。 トンネルイングレスと出口ノードを含むdiffservドメインの間の相互ドメインTCA(交通Conditioning Agreement)は、出口交通調節を抑えるか、または排除するのに使用されるかもしれません。 出口交通調節の完全な除去は、イングレスと出口のdiffservドメインが方針に食糧を供給するコンパチブルサービスをトンネルを堀られた交通に持って、一貫したファッションでその交通に使用されるPHBグループとDSCP値のすべてを支持するのを必要とします。 いくつかの仮想私設網トンネルはこの状況に関する例を提供します。 それらの終点でそれらが中間ネットワークノードによって物理的に切り離されるかもしれませんが、トンネル終点を実際には隣接にすることによってdiffservドメインをdiffserv領域にリンクするようなトンネルを見るのは役に立つかもしれません。
The pipe model is also appropriate for situations in which the DSCP itself carries information through the tunnel. For example, if transit between two domains is obtained via a path that uses the EF PHB [RFC 2598], the drop precedence information in the AF PHB DSCP values [RFC 2597] will be lost unless something is done to preserve it; an IP tunnel is one possible preservation mechanism. A path that crosses one or more non-diffserv domains between its DS-capable endpoints may experience a similar information loss phenomenon if a tunnel is not used due to the limited set of DSCP codepoints that are compatible with such domains.
また、DSCP自身がトンネルを通って情報を運ぶ状況に、パイプモデルも適切です。 例えば、EF PHB[RFC2598]を使用する経路を通して2つのドメインの間のトランジットを得て、それを保存するために何かをしないと、AF PHB DSCP値[RFC2597]における低下先行情報を失うでしょう。 IPトンネルは1つの可能な保存メカニズムです。 トンネルがそのようなドメインと互換性があるDSCP codepointsの限られたセットのため使用されないなら、DSできる終点の間の1つ以上の非diffservドメインに交差する経路は同様の情報損失現象になるかもしれません。
Black Informational [Page 4] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[4ページ]のRFC2983DiffservとTunnels2000年10月
3.2 Considerations for Partially DS-capable Configurations
3.2 DS部分的にできる構成のための問題
If only the tunnel egress node is DS-capable, [RFC 2475] requires the egress node to perform any edge traffic conditioning needed by the diffserv domain for tunneled traffic entering from outside the domain. If the egress node would not otherwise be a DS edge node, one way to meet this requirement is to perform edge traffic conditioning at an appropriate upstream DS edge node within the tunnel, and copy the DSCP value from the outer IP header to the inner IP header as part of tunnel decapsulation processing; this applies the uniform model to the portion of the tunnel within the egress node's diffserv domain. A second alternative is to discard the outer DSCP value as part of decapsulation processing, reducing the resulting traffic conditioning problem and requirements to those of an ordinary DS ingress node. This applies the pipe model to the portion of the tunnel within the egress node's diffserv domain and hence the adjacent upstream node for DSCP marking purposes is the tunnel ingress node, rather than the immediately upstream intermediate tunnel node.
トンネル出口ノードだけがDSできるなら、[RFC2475]は、diffservドメインによってドメインの外から入るトンネルを堀られた交通に必要とされたどんな縁の交通調節も実行するために出口ノードを必要とします。 そうでなければ、出口ノードがDS縁のノードでないなら、この必要条件を満たす1つの方法は、トンネルの中で適切な上流のDS縁のノードで縁の交通調節を実行して、トンネル被膜剥離術処理の一部として外側のIPヘッダーから内側のIPヘッダーまでDSCP値をコピーすることです。 これは出口ノードのdiffservドメインの中で一定のモデルをトンネルの一部に適用します。 2番目の代替手段は被膜剥離術処理の一部として外側のDSCP値を捨てることです、普通のDSイングレスノードのものに結果として起こる交通調節問題と要件を減らして。 これは出口ノードのdiffservドメインの中でパイプモデルをトンネルの一部に適用します、そして、したがって、目的をマークするDSCPのための隣接している上流のノードはすぐに上流の中間的トンネルノードよりむしろトンネルイングレスノードです。
If only the tunnel ingress node is DS-capable, [RFC 2475] requires that traffic emerging from the tunnel be compatible with the network at the tunnel egress. If tunnel decapsulation processing discards the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable tunnel ingress node is obligated to set the inner header's DSCP to a value compatible with the network at the tunnel egress. The value 0 (DSCP of 000000) is used for this purpose by a number of existing tunnel implementations. If the egress network implements IP precedence as specified in [RFC 791], then some or all of the eight class selector DSCP codepoints defined in [RFC 2474] may be usable. DSCP codepoints other than the class selectors are not generally suitable for this purpose, as correct operation would usually require diffserv functionality at the DS-incapable tunnel egress node.
トンネルイングレスノードだけがDSできるなら、[RFC2475]は、トンネルから現れる交通がトンネル出口のネットワークと互換性があるのを必要とします。 トンネル被膜剥離術処理が内側のヘッダーのDSCP値を変えないで外側のヘッダーのDSCP値を捨てるなら、DSできるトンネルイングレスノードがトンネル出口のネットワークとのコンパチブル値に内側のヘッダーのDSCPを設定するのが義務付けられます。 値0(000000のDSCP)はこのために多くの既存のトンネル実現で使用されます。 出口ネットワークが[RFC791]での指定されるとしてのIP先行を実行するなら、[RFC2474]で定義された8クラスセレクタDSCP codepointsのいくつかかすべてが使用可能であるかもしれません。 一般に、クラスセレクタ以外のDSCP codepointsはこのために適当ではありません、正しい操作が通常DS不可能なトンネル出口ノードにおけるdiffservの機能性を必要とするだろうというとき。
4. Ingress Functionality
4. イングレスの機能性
As described in Section 3 above, this analysis is based on an approach in which diffserv functionality and/or out-of-band communication paths are not placed in parallel with tunnel encapsulation processing. This allows three possible locations for traffic conditioning with respect to tunnel encapsulation processing, as shown in the following diagram that depicts the flow of IP headers through tunnel encapsulation:
セクション3で説明されるように、この分析はどのdiffservの機能性で上では、アプローチに基づいているか、そして、バンドの外に、通信路がトンネルカプセル化処理と平行して置かれません。 これはトンネルカプセル化処理に関して交通調節のための3つの可能な位置を許容します、それがトンネルカプセル化を通したIPヘッダーの流れについて表現するのが以下のダイヤグラムで示されるように:
Black Informational [Page 5] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[5ページ]のRFC2983DiffservとTunnels2000年10月
+--------- [2 - Outer] -->>
/
/
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
+--------- [2--、外側、]、--、>>//>>。---- [1--以前]-------- 要約してください。------ [3--より多くのin]、--、>>。
Traffic conditioning at [1 - Before] is logically separate from the tunnel, as it is not impacted by the presence of tunnel encapsulation, and hence should be allowed by tunnel designs and specifications. Traffic conditioning at [2 - Outer] may interact with tunnel protocols that are sensitive to packet reordering; such tunnels may need to limit the functionality at [2 - Outer] as discussed further in Section 5.1. In the absence of reordering sensitivity, no additional restrictions should be necessary, although traffic conditioning at [2 - Outer] may be responsible for remarking traffic to be compatible with the next diffserv domain that the tunneled traffic enters.
調節を取引する、[1--以前]、それがトンネルカプセル化の存在によって影響を与えられないときトンネルから論理的に別々であり、したがって、トンネルデザインと仕様で許容されるべきです。 調節を取引する、[2--、外側、]、パケット再命令に敏感なトンネルプロトコルと対話するかもしれません。 機能性を制限する、そのようなトンネルが、必要があるかもしれない[2--、外側、]、セクション5.1で、より詳しく、議論します。 感度を再命令することが不在のときどんな追加制限も必要であるべきではありません、交通ですが調節、[2--、外側、]、トンネルを堀られた交通が入る次のdiffservドメインと互換性があるように交通を述べさせるのに責任があるかもしれません。
In contrast, the [3 - Inner] location is difficult to utilize for traffic conditioning because it requires functionality that reaches inside the packet to operate on the inner IP header. This is impossible for IPSec tunnels and any other tunnels that are encrypted or employ cryptographic integrity checks. Hence traffic conditioning at [3 - Inner] can often only be performed as part of tunnel encapsulation processing, complicating both the encapsulation and traffic conditioning implementations. In many cases, the desired functionality can be achieved via a combination of traffic conditioners in the other two locations, both of which can be specified and implemented independently of tunnel encapsulation.
対照的に、[3--より多くのin]、内側のIPヘッダーを手術するのがパケットの中で達する機能性を必要とするので、位置は交通調節に利用するのが難しいです。 IPSecトンネルといかなる他のコード化されたトンネルか暗号の保全がチェックする雇用にも、これは不可能です。 したがって、調節を取引する、[3--より多くのin]、トンネルカプセル化処理の一部としてしばしば実行できるだけです、カプセル化と実現を条件とさせる交通の両方を複雑にして。 多くの場合、他の2つの位置での交通コンディショナーの組み合わせで必要な機能性を達成できます。トンネルカプセル化の如何にかかわらずその両方を指定されて、実行できます。
An exception for which traffic conditioning functionality is necessary at [3 - Inner] occurs when the DS-incapable tunnel egress discards the outer IP header as part of decapsulation processing, and hence the DSCP in the inner IP header must be compatible with the egress network. Setting the inner DSCP to 0 as part of encapsulation addresses most of these cases, and the class selector DCSP codepoint values are also useful for this purpose, as they are valid for networks that support IP precedence [RFC 791].
交通調節の機能性が必要である例外、[3--より多くのin]、DS不可能なトンネル出口が被膜剥離術処理の一部として外側のIPヘッダーを捨てて、したがって、内側のIPヘッダーのDSCPは出口ネットワークと互換性があるに違いないとき、起こります。 カプセル化の一部として内側のDSCPを0に設定すると、これらのケースの大部分は記述されます、そして、また、クラスセレクタDCSP codepoint値もこのために役に立ちます、IP先行[RFC791]を支持するネットワークに、それらが有効であるので。
The following table summarizes the achievable relationships among the before (B), outer (O), and inner (I) DSCP values and the corresponding locations of traffic conditioning logic.
以下のテーブルが達成可能な関係をまとめる、交通調節論理の(B)、外側の(O)、内側の(I)DSCP値、および対応する位置の前に。
Black Informational [Page 6] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[6ページ]のRFC2983DiffservとTunnels2000年10月
Relationship Traffic Conditioning Location(s)
------------ --------------------------------
B = I = O No traffic conditioning required
B != I = O [1 - Before]
B = I != O [2 - Outer]
B = O != I Limited support as part of encapsulation:
I can be set to 000000 or possibly one of
the class selector code points.
B != I != O Some combination of the above three scenarios.
関係交通調節位置------------ -------------------------------- Oいいえ交通B=私=調節がB!=私=Oを必要とした、[1--以前]、B=I!がOと等しい、[2--、外側、]、カプセル化の一部としてのI株式会社B=O!=サポート: 私はクラスセレクタコード・ポイントの000000かことによると1つに用意ができることができます。 B!= I!は○ 上の3つのシナリオのSome組み合わせと等しいです。
A combination of [1 - Before] and [2 - Outer] is applicable to many cases covered by the last two lines of the table, and may be preferable to deploying functionality at [3 - Inner]. Traffic conditioning may still be required for purposes such as rate and burst control even if DSCP values are not changed.
組み合わせ、[1--以前]、[2--、外側、]、配備するケースがテーブルの最後の2つの線をカバーしていて、機能性が望ましいかもしれない多くに適切である、[3--より多くのin] DSCP値が変えられないでも、交通調節は、レートなどの目的にまだ必要であり、コントロールを押し破くかもしれません。
4.1 Ingress DSCP Selection and Reordering
4.1 イングレスのDSCP選択とReordering
It may be necessary or desirable to limit the DS behavior aggregates that utilize an IP tunnel that is sensitive to packet reordering within the tunnel. The diffserv architecture allows packets to be reordered when they belong to behavior aggregates among which reordering is permitted; for example, reordering is allowed among behavior aggregates marked with different Class Selector DSCPs [RFC 2474]. IPSec [RFC 2401] and L2TP [RFC 2661] provide examples of tunnels that are sensitive to packet reordering. If IPSec's anti- replay support is configured, audit events are generated in response to packet reordering that exceeds certain levels, with the audit events indicating potential security issues. L2TP can be configured to restore the ingress ordering of packets at tunnel egress, not only undoing any differentiation based on reordering within the tunnel, but also negatively impacting the traffic (e.g., by increasing latency). The uniform model cannot be completely applied to such tunnels, as arbitrary mixing of traffic from different behavior aggregates can cause these undesirable interactions.
トンネルの中で再命令されるパケットに敏感なIPトンネルを利用するDS振舞い集合を制限するのは、必要であるか、または望ましいかもしれません。 再命令が受入れられる振舞い集合に属すとき、diffserv構造は、パケットが再命令されるのを許容します。 例えば、再命令は異なったClass Selector DSCPs[RFC2474]と共にマークされた振舞い集合の中で許されています。 IPSec[RFC2401]とL2TP[RFC2661]はパケット再命令に敏感なトンネルに関する例を提供します。 IPSecの反再生サポートが構成されるなら、監査出来事はあるレベルを超えているパケット再命令に対応して発生します、監査出来事が潜在的安全保障問題を示していて。 トンネル出口でパケットのイングレス注文を回復するためにL2TPを構成できます、トンネルの中で再命令することに基づいて少しの分化も元に戻すだけではなく、否定的に、交通(例えば、潜在を高めるのによる)に影響を与えもして。 完全に一定のモデルをそのようなトンネルに適用できるというわけではありません、異なった振舞い集合からの交通の任意の混合がこれらの望ましくない相互作用を引き起こす場合があるとき。
The simplest method of avoiding undesirable interactions of reordering with reordering-sensitive tunnel protocols and features is not to employ the reordering-sensitive protocols or features, but this is often not desirable or even possible. When such protocols or features are used, interactions can be avoided by ensuring that the aggregated flows through the tunnel are marked at [2 - Outer] to constitute a single ordered aggregate (i.e., the PHBs used share an ordering constraint that prevents packets from being reordered). Tunnel protocol specifications should indicate both whether and under what circumstances a tunnel should be restricted to a single ordered aggregate as well as the consequences of deviating from that restriction. For the IPSec and L2TP examples discussed above, the
再命令敏感なトンネルプロトコルと特徴で再命令する望ましくない相互作用を避ける最も簡単な方法が再命令敏感なプロトコルか特徴を使わないことですが、これは、しばしば望ましいというわけではありませんし、可能になりもしさえあります。 そのようなプロトコルか特徴が使用されている、いつトンネルを通る集められた流れが確実に著しくなるようにすることによって相互作用を避けることができるか、[2--、外側、]、シングルを構成するのは集合を注文しました(すなわち、使用されるPHBsはパケットが再命令されるのを防ぐ注文規制を共有します)。 トンネルプロトコル仕様が両方を示すべきである、そして、どんな状況で、トンネルはその制限から逸れる結果と同様にただ一つの規則正しい集合に制限されるべきですか? IPSecと上で議論したL2TPの例のために
Black Informational [Page 7] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[7ページ]のRFC2983DiffservとTunnels2000年10月
specifications should restrict each tunnel to a single ordered aggregate when protocol features sensitive to reordering are configured, and may adopt the approach of restricting all tunnels in order to avoid unexpected consequences of changes in protocol features or composition of tunneled traffic. Diffserv implementations should not attempt to look within such tunnels to provide reordering-based differentiation to the encapsulated microflows. If reordering-based differentiation is desired within such tunnels, multiple parallel tunnels between the same endpoints should be used. This enables reordering among packets in different tunnels to coexist with an absence of packet reordering within each individual tunnel. For IPSec and related security protocols, there is no cryptographic advantage to using a single tunnel for multiple ordered aggregates rather than multiple tunnels because any traffic analysis made possible by the use of multiple tunnels can also be performed based on the DSCPs in the outer headers of traffic in a single tunnel. In general, the additional resources required to support multiple tunnels (e.g., cryptographic contexts), and the impact of multiple tunnels on network management should be considered in determining whether and where to deploy them.
仕様は、再命令に機密のプロトコル機能が構成されるとき、各トンネルをただ一つの規則正しい集合に制限するべきであり、プロトコル機能における変化の予期していなかった結果かトンネルを堀られた交通の構成を避けるためにすべてのトンネルを制限するアプローチを取るかもしれません。 Diffserv実現は、再命令ベースの分化を要約のmicroflowsに供給するためにそのようなトンネルの中で見るのを試みるべきではありません。 再命令ベースの分化がそのようなトンネルの中で望まれているなら、同じ終点の間の複数の平行なトンネルが使用されるべきです。 これは、異なったトンネルのパケットの中で再命令するのがそれぞれの個々のトンネルの中のパケット再命令の不在と共存するのを可能にします。 IPSecと関連するセキュリティプロトコルのために、また、交通の外側のヘッダーのDSCPsに基づいて複数のトンネルの使用で可能にされたどんなトラヒック分析も実行できるので複数のトンネルよりむしろ複数の規則正しい集合に単一のトンネルを使用するどんな暗号の利点も単一のトンネルにありません。 一般に、追加リソースが複数のトンネル(例えば、暗号の文脈)を支えるのが必要であり、配備してどこでそれらを配備するかを決定する際に複数のトンネルのネットワークマネージメントへの影響は考えられるべきです。
4.2 Tunnel Selection
4.2 トンネル選択
The behavioral characteristics of a tunnel are an important consideration in determining what traffic should utilize the tunnel. This involves the service provisioning policies of all the participating domains, not just the PHBs and DSCPs marked on the traffic at [2 - Outer]. For example, while it is in general a bad idea to tunnel EF PHB traffic via a Default PHB tunnel, this can be acceptable if the EF traffic is the only traffic that utilizes the tunnel, and the tunnel is provisioned in a fashion adequate to preserve the behavioral characteristics required by the EF PHB.
どんな交通がトンネルを利用するべきであるかを決定することにおいてトンネルの行動の特性は重要な考慮すべき事柄です。 これが交通のときにマークされたPHBsとDSCPsだけではなく、すべての参加ドメインの方針に食糧を供給するサービスにかかわる、[2--、外側、] 例えば、それは一般にそうですが、トンネルEF PHB交通へのDefault PHBトンネルを通る悪い考えでありこれはEF交通がトンネルを利用する唯一の交通であるなら許容できる場合があります、そして、EF PHBによって必要とされた行動の特性を保存するために適切なファッションでトンネルは食糧を供給されます。
Service provisioning policies are responsible for preventing mismatches such as forwarding EF traffic via an inadequately provisioned Default tunnel. When multiple parallel tunnels with different behavioral characteristics are available, service provisioning policies are responsible for determining which flows should use which tunnels. Among the possibilities is a coarse version of the uniform tunnel model in which the inner DSCP value is used to select a tunnel that will forward the traffic using a behavioral aggregate that is compatible with the traffic's PHB.
サービス食糧を供給する方針は不十分に食糧を供給されたDefaultトンネルを通して交通をEFに送ることなどのミスマッチを防ぐのに原因となります。 異なった行動の特性がある複数の平行なトンネルが利用可能であるときに、どれが流れるかがどのトンネルを使用するべきであるかを決定するのにサービス食糧を供給する方針は原因となります。 可能性の中に、内側のDSCP値がトラフィックのPHBと互換性がある行動の集合を使用することで交通を進めるトンネルを選択するのに使用される一定のトンネルモデルの粗いバージョンがあります。
5. Egress Functionality
5. 出口の機能性
As described in Section 3 above, this analysis is based on an approach in which diffserv functionality and/or out-of-band communication paths are not placed in parallel with tunnel
セクション3で説明されるように、この分析はどのdiffservの機能性で上では、アプローチに基づいているか、そして、バンドの外に、通信路がトンネルと平行して置かれません。
Black Informational [Page 8] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[8ページ]のRFC2983DiffservとTunnels2000年10月
encapsulation processing. This allows three possible locations for traffic conditioners with respect to tunnel decapsulation processing, as shown in the following diagram that depicts the flow of IP headers through tunnel decapsulation:
カプセル化処理。 これはトンネル被膜剥離術処理に関して交通コンディショナーのための3つの可能な位置を許容します、それがトンネル被膜剥離術を通したIPヘッダーの流れについて表現するのが以下のダイヤグラムで示されるように:
>>----[5 - Outer]-------------+
\
\
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
>>。----[5--、外側、]-------------+ \\>>。----[4--より多くのin]--------- Decapsulate---- [6--後]、--、>>。
Traffic conditioning at [5 - Outer] and [6 - After] is logically separate from the tunnel, as it is not impacted by the presence of tunnel decapsulation. Tunnel designs and specifications should allow diffserv traffic conditioning at these locations. Such conditioning can be viewed as independent of the tunnel, i.e., [5 - Outer] is traffic conditioning that takes place prior to tunnel egress, and [6 - After] is traffic conditioning that takes place after egress decapsulation. An important exception is that the configuration of a tunnel (e.g., the absence of traffic conditioning at tunnel ingress) and/or the diffserv domains involved may require that all traffic exiting a tunnel pass through diffserv traffic conditioning to fulfill the diffserv edge node traffic conditioning responsibilities of the tunnel egress node. Tunnel designers are strongly encouraged to include the ability to require that all traffic exiting a tunnel pass through diffserv traffic conditioning in order to ensure that traffic exiting the node is compatible with the egress node's diffserv domain.
調節を取引する、[5--、外側、]、[6--後]、トンネルから論理的に分離してください、それがトンネル被膜剥離術の存在によって影響を与えられないとき。 トンネルデザインと仕様はこれらの位置でdiffserv交通調節を許すべきです。 そして、トンネルの如何にかかわらずすなわち、そのような調節を見ることができる、[5--、外側、]、交通がトンネル出口の前に行われる調節である、[6--後]、出口被膜剥離術の後に行われる交通調節はそうです。 重要な例外はトンネル(例えば、トンネルイングレスにおける交通調節の欠如)、そして/または、ドメインがかかわったdiffservの構成が、diffservを実現させるためにdiffserv交通調節でトンネルパスを出るすべての交通がトンネル出口ノードのノード交通調節責任を斜めに進ませるのを必要とするかもしれないということです。 トンネルのデザイナーがノードを出て、その交通を確実にするためにdiffserv交通調節でトンネルパスを出るすべての交通が出口ノードのdiffservドメインと互換性があるのが必要である能力を含んでいるよう強く奨励されます。
In contrast, the [4 - Inner] location is difficult to employ for traffic conditioning because it requires reaching inside the packet to operate on the inner IP header. Unlike the [3 - Inner] case for encapsulation, there is no need for functionality to be performed at [4- Inner], as diffserv traffic conditioning can be appended to the tunnel decapsulation (i.e., performed at [6 - After]).
対照的に、[4--より多くのin]、内側のIPヘッダーを手術するのが、パケットの中で達するのを必要とするので、位置は交通調節に使うのが難しいです。 すなわち、[3--より多くのin]、カプセル化のためのケース、機能性が実行される必要[4つより多くのin]は全くありません、diffserv交通調節をトンネル被膜剥離術に追加できるとき(実行されます[6--後])。
5.1 Egress DSCP Selection
5.1 出口DSCP選択
The elimination of parallel functionality and data paths from decapsulation causes a potential loss of information. As shown in the above diagram, decapsulation combines and reduces two DSCP values to one DSCP value, losing information in the most general case, even if arbitrary functionality is allowed. Beyond this, allowing arbitrary functionality poses a structural problem, namely that the DSCP value from the outer IP header would have to be presented as an out-of-band input to the traffic conditioning block at [6 - After], complicating the traffic conditioning model.
被膜剥離術からの平行な機能性とデータ経路の除去は情報の潜在的損失を引き起こします。 上のダイヤグラムで示されるように、被膜剥離術は、2つのDSCP値を1つのDSCP値まで結合して、減少させます、最も一般的なケースの中の情報を失って、任意の機能性が許容されていても。 任意の機能性を許容するとこれを超えて、すなわち、外側のIPヘッダーからのDSCP値がバンドで出ている入力として交通調節ブロックに提示されなければならないだろうという構造的な問題が引き起こされる、[6--後]、交通調節モデルを複雑にします。
Black Informational [Page 9] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[9ページ]のRFC2983DiffservとTunnels2000年10月
To avoid such complications, the simpler approach of statically selecting either the inner or outer DSCP value at decapsulation is recommended, leaving the full generality of traffic conditioning functionality to be implemented at [5 - Outer] and/or [6 - After]. Tunnels should support static selection of one or the other DSCP value at tunnel egress. The rationale for this approach is usually only one of the two DSCP values contains useful information. The conceptual model for the tunnel provides a strong indication of which one contains useful information; the outer DSCP value usually contains the useful information for tunnels based on the uniform model, and the inner DSCP value usually contains the useful information for tunnels based on the pipe model. IPSec tunnels are usually based on the pipe model, and for security reasons are currently required to select the inner DSCP value; they should not be configured to select the outer DSCP value in the absence of an adequate security analysis of the resulting risks and implications.
そのような複雑さを避けるために、静的に被膜剥離術における内側の、または、外側のDSCP値を選択するより簡単なアプローチはお勧めです、交通の完全な一般性を実行される調節の機能性に残して[5--、外側、]、[6--後] Tunnelsはトンネル出口で1の静的な選択か他のDSCP値を支持するべきです。 原理は、このアプローチが通常2つのDSCP値の1つにすぎないので、役に立つ情報を含んでいます。 トンネルへのどれの好材料が役に立つ情報を含む概念モデルは提供します。 通常、外側のDSCP値は一定のモデルに基づくトンネルのための役に立つ情報を含んでいます、そして、通常、内側のDSCP値はパイプモデルに基づくトンネルのための役に立つ情報を含んでいます。 IPSecトンネルは、通常、パイプモデルに基づいていて、現在、安全保障上の理由で内側のDSCP値を選択しなければなりません。 結果として起こるリスクと含意の十分な安全性分析がないとき外側のDSCP値を選択するためにそれらを構成するべきではありません。
5.2 Egress DSCP Selection Case Study
5.2 出口DSCP選択ケーススタディ
As a sanity check on the egress DSCP selection approach proposed above, this subsection considers a situation in which a more complex approach might be required. Statically choosing a single DSCP value may not work well when both DSCPs are carrying information that is relevant to traffic conditioning.
出口DSCP選択接近の健全度チェックが上で提案したように、この小区分は、より複雑なアプローチが必要であるかもしれない状況を考えます。 両方のDSCPsが交通調節に関連している情報を運ぶとき、静的にただ一つのDSCP値を選ぶのはうまくいかないかもしれません。
As an example, consider a situation in which different AF groups [RFC 2597] are used by the two domains at the tunnel endpoints, and there is an intermediate domain along the tunnel using RFC 791 IP precedences that is transited by setting the DSCP to zero. This situation is shown in the following IP header flow diagram where I is the tunnel ingress node, E is the tunnel egress node and the vertical lines are domain boundaries. The node at the left-hand vertical line sets the DSCP in the outer header to 0 in order to obtain compatibility with the middle domain:
例と、異なったAFグループ[RFC2597]がトンネル終点の2つのドメインによって使用される状況を考えてください。そうすれば、それがゼロに合わせるためにDSCPを設定することによって通過されるRFC791IP先行を使用するトンネルに沿って中間的ドメインがあります。 この状況は以下のIPヘッダーフローチャートに私がどこのトンネルイングレスノードであるかが示されます、そして、Eはトンネル出口ノードです、そして、縦線はドメイン境界です。 左手の縦線のノードは中央ドメインとの互換性を得るために0への外側のヘッダーにDSCPをはめ込みます:
| |
+-----|-------------------|------+
/ | | \
>>-----------I-------|-------------------|--------E---------->>
| |
Ingress DS Domain RFC 791 Egress DS domain
IP Precedence
Domain
| | +-----|-------------------|------+ / | | \>>。-----------I-------|-------------------|--------E---------->>|、| イングレスDS Domain RFC791Egress DSドメインIP Precedence Domain
In this situation, the DS edge node for the egress domain (i.e., the node at the right-hand vertical line) can select the appropriate AF group (e.g., via an MF classifier), but cannot reconstruct the drop precedence information that was removed from the outer header when it
この状況で、出口ドメイン(すなわち、右手の縦線のノード)のためのDS縁のノードは、適切なAFグループ(例えば、MFクラシファイアを通した)を選択できますが、それであるときに外側のヘッダーから取り除かれた低下先行情報を再建できません。
Black Informational [Page 10] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[10ページ]のRFC2983DiffservとTunnels2000年10月
transited the RFC 791 domain (although it can construct new information via metering and marking). The original drop precedence information is preserved in the inner IP header's DSCP, and could be combined at the tunnel egress with the AF class selection communicated via the outer IP header's DSCP. The marginal benefit of being able to reuse the original drop precedence information as opposed to constructing new drop precedence markings does not justify the additional complexity introduced into tunnel egress traffic conditioners by making both DSCP values available to traffic conditioning at [6 - After].
RFC791ドメイン(計量とマークを通して新情報を構成できますが)を通過しました。 オリジナルの低下先行情報を内側のIPヘッダーのDSCPに保存して、トンネル出口で外側のIPヘッダーのDSCPを通して伝えられるAFクラス選択に結合できました。 新しい低下先行印を構成することと対照的にオリジナルの低下先行情報を再利用できるマージンの利益が両方を調節を取引するために利用可能なDSCP値にすることによってトンネル出口交通コンディショナーに導入された追加複雑さを正当化しない、[6--後]
6. Diffserv and Protocol Translators
6. Diffservとプロトコル翻訳者
A related issue involves protocol translators, including those employing the Stateless IP/ICMP Translation Algorithm [RFC 2765]. These translators are not tunnels because they do not add or remove a second IP header to/from packets (e.g., in contrast to IPv6 over IPv4 tunnels [RFC 1933]) and hence do not raise concerns of information propagation between inner and outer IP headers. The primary interaction between translators and diffserv is that the translation boundary is likely to also be a diffserv domain boundary (e.g., the IPv4 and IPv6 domains may have different policies for traffic conditioning and DSCP usage), and hence such translators should allow the insertion of diffserv edge node processing (including traffic conditioning) both before and after the translation processing.
関連する問題はStateless IP/ICMP Translation Algorithm[RFC2765]を使うものを含むプロトコル翻訳者にかかわります。 これらの翻訳者は、パケット(例えば、IPv4トンネル[RFC1933]の上のIPv6と対照して)からの/に2番目のIPヘッダーを加えもしませんし、移しもしないのによるトンネルでなく、またしたがって、内側の、そして、外側のIPヘッダーの間の情報伝播の関心を高めません。 翻訳者とdiffservとの第一の相互作用は翻訳限界がまた、diffservドメイン境界である傾向があるという(例えば、IPv4とIPv6ドメインには、交通調節とDSCP用法のための異なった方針があるかもしれません)ことです、そして、したがって、そのような翻訳者はともに翻訳処理の前後にdiffserv縁のノード処理(交通調節を含んでいる)の挿入を許すべきです。
7. Security Considerations
7. セキュリティ問題
The security considerations for the diffserv architecture discussed in [RFC 2474, RFC 2475] apply when tunnels are present. One of the requirements is that a tunnel egress node in the interior of a diffserv domain is the DS ingress node for traffic exiting the tunnel, and is responsible for performing appropriate traffic conditioning. The primary security implication is that the traffic conditioning is responsible for dealing with theft- and denial-of- service threats posed to the diffserv domain by traffic exiting from the tunnel. The IPSec architecture [RFC 2401] places a further restriction on tunnel egress processing; the outer header is to be discarded unless the properties of the traffic conditioning to be applied are known and have been adequately analyzed for security vulnerabilities. This includes both the [5 - Outer] and [6 - After] traffic conditioning blocks on the tunnel egress node, if present, and may involve traffic conditioning performed by an upstream DS-edge node that is the DS domain ingress node for the encapsulated tunneled traffic.
トンネルが存在しているとき、構造が[RFC2474、RFC2475]で議論したdiffservのためのセキュリティ問題は適用されます。 要件の1つはdiffservドメインの内陸部のトンネル出口ノードがトンネルを出る交通のためのDSイングレスノードであり、適切な交通調節を実行するのに原因となるということです。 第一のセキュリティ含意は交通調節が窃盗と-サービスでは、脅威にdiffservドメインにトンネルから出る交通で引き起こされたという否定に対処するのに原因となるということです。 IPSec構造[RFC2401]はトンネル出口処理に関してさらなる制限を課します。 外側のヘッダーは、適用されるべき交通調節の特性が知られていない場合捨てられて、セキュリティの脆弱性のために適切に分析されることになっていました。 これが両方を含んでいる、[5--、外側、]、[6--後]、存在しているならトンネル出口ノードで調節ブロックを取引して、調節がDSドメインイングレスノードである上流のDS-縁のノードで実行した交通に要約のトンネルを堀られた交通にかかわるかもしれません。
Black Informational [Page 11] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[11ページ]のRFC2983DiffservとTunnels2000年10月
8. References
8. 参照
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。
[RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597. June 1999.
[RFC2597] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597 1999年6月。
[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC2598] ジェーコブソンとV.とニコルズとK.とK.Poduri、「完全優先転送PHB」、RFC2598 1999年6月。
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC
2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらわれます。 「層Twoのトンネリングプロトコル"L2TP"」、1999年8月のRFC2661。
[RFC 2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E.、「国がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、2000年2月。
Black Informational [Page 12] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[12ページ]のRFC2983DiffservとTunnels2000年10月
9. Acknowledgments
9. 承認
Some of this material is based on discussions with Brian Carpenter, and in particular his presentation on this topic to the diffserv WG during the summer 1999 IETF meeting in Oslo. Credit is also due to a number of people working on tunnel specifications who have discovered limitations of the diffserv architecture [RFC 2475] in the area of tunnels. Their patience with the time it has taken to address this set of issues is greatly appreciated. Finally, this material has benefited from discussions within the diffserv WG, both in meetings and on the mailing list -- the contributions of participants in those discussions are gratefully acknowledged.
この何らかの材料がオスロで会う1999年夏のIETFの間、ブライアンCarpenterとの議論、および特にdiffserv WGへのこの話題における彼のプレゼンテーションに基づいています。 クレジットはトンネルの領域でのdiffserv構造[RFC2475]の制限を発見したトンネル仕様に取り組んでいる多くの人々のもためです。 わざわざがあるそれがこのセットの問題を記述した彼らの忍耐に大いに感謝します。 最終的に、この材料はdiffserv WGの中で議論の利益を得ました、ミーティングとメーリングリストの上の両方--それらの議論における、関係者の貢献は感謝して承諾されます。
10. Author's Address
10. 作者のアドレス
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
南聖ホプキントン、デヴィッドL.黒のEMC社42のMA 01748
Phone: +1 (508) 435-1000 x75140 EMail: black_david@emc.com
以下に電話をしてください。 +1(508)435-1000x75140 EMail: black_david@emc.com
Black Informational [Page 13] RFC 2983 Diffserv and Tunnels October 2000
黒い情報[13ページ]のRFC2983DiffservとTunnels2000年10月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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 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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Black Informational [Page 14]
黒の情報です。[14ページ]
一覧
スポンサーリンク
