[要約] RFC 2983は、異なるサービスとトンネルのためのプロトコル仕様です。その目的は、ネットワーク上で異なるサービス品質を提供するためのトンネル化技術を定義することです。
Network Working Group D. Black
Request for Comments: 2983 EMC Corporation
Category: Informational October 2000
Differentiated Services and 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 (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
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.
このドキュメントでは、Differentiated Services（diffserv）（RFC 2474、RFC 2475）とさまざまな形式のIPトンネルとの相互作用について検討します。 diffservアーキテクチャ（RFC 2475）でのトンネルの説明では、トンネルの設計者と実装者に十分なガイダンスを提供していません。このドキュメントでは、diffservとインターネットプロトコル（IP）トンネルの相互作用に関する2つの概念モデルについて説明し、それらを使用して、結果として生じる構成と機能の組み合わせを調査します。重要な考慮事項は、トンネルのカプセル化とカプセル化解除の存在下でdiffservトラフィック調整を実行する方法と場所です。トンネルがdiffservトラフィック調整モデルに追加する複雑さを制限するいくつかの単純なメカニズムも提案されています。 IPSecトンネルのセキュリティに関する考慮事項により、状況によっては可能な機能が制限されます。
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 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.
IPトンネルは、トンネルを通過するときに、IPトラフィックを別のIPヘッダーにカプセル化します。これらの2つのIPヘッダーの存在は、IPトンネルの定義特性ですが、2つのIPヘッダーの間に追加のヘッダーが挿入されている場合があります。内部IPヘッダーは元のトラフィックのヘッダーです。外部IPヘッダーは、トンネルエンドポイントでアタッチおよびデタッチされます。一般に、トンネルエンドポイント間の中間ネットワークノードは外部IPヘッダーのみで動作するため、diffserv対応の中間ノードは外部IPヘッダーのDSCPフィールドのみにアクセスして変更します。このドキュメントでは、「トンネル」と「IPトンネル」という用語は同じ意味で使用されています。簡略化のため、このドキュメントでは、MPLSパスや、レイヤー2（リンク）ヘッダーのカプセル化によって形成される「トンネル」など、IPトンネル以外のトンネル（つまり、カプセル化IPヘッダーがないトンネル）は考慮していませんが、概念モデルとここで説明するアプローチは、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ヘッダーの削除によってカプセル化解除される出口、およびトンネルされたトラフィックが通過する中間ノードで構成されます入力と出力の間。このドキュメントでは、トンネルトラフィックのルーティングと転送については何も想定していません。特に、ルートピン留めが存在することも存在しないことも想定していません。
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-in-IPトンネル[RFC 2003]から、IPSecトランスポートモードのL2TPのPPPのIP [RFC 1661、RFC 2401、RFC 2661]などのより複雑なマルチプロトコルトンネルまでさまざまです。最も一般的なトンネル構成は、トンネルがエンドツーエンドではない構成です。つまり、入口ノードと出口ノードは、トンネルによって伝送されるトラフィックの送信元ノードと宛先ノードではありません。このようなトンネルは、複数の送信元と宛先を持つトラフィックを運ぶ場合があります。入力ノードがトンネル内のすべてのトラフィックのエンドツーエンドの送信元である場合、結果は、このドキュメントの分析とガイダンスの多くを適用できる簡素化された構成になり、同様に出力ノードがエンドツーエンドの場合-終了先。
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ヘッダーでの差別化サービスコードポイント（DSCP）の使用です[RFC 2474、RFC 2475]。 diffservアーキテクチャでは、中間ノードがDSCPの値を調べて変更することができます。これにより、外部IPヘッダーのDSCP値がトンネルの入力と出力の間で変更される可能性があります。トンネルがエンドツーエンドではない場合、DSCPおよび/またはトンネルに含まれる情報の一部を入力の外部IPヘッダーに伝搬したり、内部のIPヘッダーに戻したりすることが望ましい場合があります。出口。トンネル実装者が直面している現在の状況は、[RFC 2475]が不完全なガイダンスを提供していることです。セクション3のガイドラインG.7は一例です。一部のPHB仕様では、トンネルトラフィックの外部IPヘッダーで使用できるPHBを明示的に指定しているためです。これは過度に制限的です。たとえば、仕様で内部IPヘッダーと外部IPヘッダーの両方で同じPHBを使用する必要がある場合、その仕様に準拠するトラフィックは、そのPHBをサポートしないドメインまたはネットワーク間でトンネリングできません。
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ヘッダーのDSCPに含まれているため、このアプローチでは、トンネルエンドポイントを介して情報を送信する追加のパスは作成されません。 IPSecアーキテクチャ[RFC 2401]では、IPSecトンネルの出口でセキュリティプロパティを維持する必要があるが、この方法では、帯域外入力を導入することにより、diffservトラフィック調整ブロックの複雑化も回避できます。このアプローチの結果、[RFC 2475]のセクション3のガイドラインG.7の最後の文は、内部と外部の両方のDSCPにアクセスできるトンネル出力diffservコンポーネントがないため、意味がなくなります。
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のような領域を作成できます。トラフィック調整はdiffservドメインの運用と管理の一部であるため、Diffservトラフィック調整は、このようなDMZのようなリージョンには適していません。
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で取り上げます。
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 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トンネルをトラフィック調整の観点からエンドツーエンドパスのアーティファクトと見なす統一モデルです。トンネルは、トラフィックを宛先に到達させるために必要なメカニズムですが、トラフィックの調整には大きな影響はありません。このモデルでは、どのパケットにも、任意の時点でトラフィック調整に使用される1つのDSフィールド、つまり最も外側のIPヘッダーのDSフィールドがあります。その他は無視されます。このモデルの実装では、カプセル化時にDSCP値を外部IPヘッダーにコピーし、カプセル化解除時に外部ヘッダーのDSCP値を内部IPヘッダーにコピーします。このモデルを使用すると、diffservトラフィック調整機能はIPトンネルの存在による影響を受けないため、diffservドメインの境界に関係なくIPトンネルを構成できます。
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ドメインにある場合、トラフィック調整の影響があります。このような状況では、出口ノードはトラフィック調整を実行して、トンネルを出るトラフィックが出力diffservドメインに受け入れられるDSCP値を持っていることを確認する必要があります（diffservアーキテクチャーのセクション6 [RFC 2475]を参照）。トンネルの入口ノードと出口ノードを含むdiffservドメイン間のドメイン間TCA（Traffic 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自体がトンネルを介して情報を伝送する状況にも適しています。たとえば、2つのドメイン間のトランジットがEF PHB [RFC 2598]を使用するパスを介して取得される場合、AF PHB DSCP値[RFC 2597]のドロップ優先情報は、それを保持するために何かが行われない限り失われます。 IPトンネルは、保存メカニズムの1つです。そのようなドメインと互換性のあるDSCPコードポイントの制限されたセットのためにトンネルが使用されない場合、DS対応のエンドポイント間で1つ以上の非diffservドメインを横断するパスで同様の情報損失現象が発生する可能性があります。
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対応である場合、[RFC 2475]は、ドメインの外部から入るトンネルトラフィックのためにdiffservドメインが必要とするエッジトラフィック調整を実行するように出力ノードに要求します。出力ノードがDSエッジノードでない場合、この要件を満たす1つの方法は、トンネル内の適切な上流DSエッジノードでエッジトラフィック調整を実行し、DSCP値を外部IPヘッダーから内部IPにコピーすることです。トンネルのカプセル化解除処理の一部としてのヘッダー。これにより、出力ノードの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対応である場合、[RFC 2475]は、トンネルから出るトラフィックがトンネル出口でネットワークと互換性があることを要求します。トンネルのカプセル化解除処理で、内部ヘッダーのDSCP値を変更せずに外部ヘッダーのDSCP値を破棄する場合、DS対応のトンネル入力ノードは、内部ヘッダーのDSCPをトンネル出口のネットワークと互換性のある値に設定する必要があります。値0（000000のDSCP）は、この目的のために、いくつかの既存のトンネル実装によって使用されます。 [RFC 791]で指定されているように出口ネットワークがIP precedenceを実装している場合、[RFC 2474]で定義されている8つのクラスセレクターDSCPコードポイントの一部またはすべてが使用できる場合があります。クラスセレクター以外のDSCPコードポイントは、通常、この目的には適していません。通常、正しい操作には、DS非対応のトンネル出力ノードでdiffserv機能が必要になるためです。
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機能および/または帯域外通信パスがトンネルカプセル化処理と並列に配置されないアプローチに基づいています。これにより、トンネルカプセル化を介したIPヘッダーのフローを示す次の図に示すように、トンネルカプセル化処理に関するトラフィック調整の3つの可能な場所が可能になります。
+--------- [2 - Outer] -->>
/
/
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
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-Outer]でのトラフィック調整は、パケットの並べ替えの影響を受けやすいトンネルプロトコルと相互作用する場合があります。セクション5.1でさらに説明するように、このようなトンネルは[2-Outer]で機能を制限する必要がある場合があります。並べ替えの感度がない場合、追加の制限は必要ありませんが、[2-Outer]でのトラフィック調整が、トンネルトラフィックが入る次の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-Inner]の場所は、内部IPヘッダーを操作するためにパケットの内部に到達する機能を必要とするため、トラフィックの調整に利用することは困難です。これは、IPSecトンネルや、暗号化されているか、暗号化の整合性チェックを採用しているその他のトンネルでは不可能です。したがって、[3-Inner]でのトラフィック調整は、トンネルカプセル化処理の一部としてのみ実行できることが多く、カプセル化とトラフィック調整の両方の実装が複雑になります。多くの場合、他の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-内部]でトラフィック調整機能が必要となる例外は、DS対応のトンネル出口がカプセル化解除処理の一部として外部IPヘッダーを破棄するため、内部IPヘッダーのDSCPが出力ネットワークと互換性がある必要があります。 。カプセル化の一部として内部DSCPを0に設定すると、これらのケースのほとんどに対応します。また、クラスセレクターのDCSPコードポイント値は、IP precedence [RFC 791]をサポートするネットワークに有効であるため、この目的にも役立ちます。
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値と、トラフィック調整ロジックの対応する場所の間で達成可能な関係をまとめたものです。
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.
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-内部]で機能をデプロイするよりも望ましい場合があります。 DSCP値が変更されていない場合でも、レートやバースト制御などの目的でトラフィック調整が必要になる場合があります。
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アーキテクチャでは、パケットが動作の集約に属していて、その中で並べ替えが許可されている場合に、パケットを並べ替えることができます。たとえば、異なるクラスセレクターDSCP [RFC 2474]でマークされた動作集約間で並べ替えが許可されます。 IPSec [RFC 2401]およびL2TP [RFC 2661]は、パケットの並べ替えの影響を受けやすいトンネルの例を示しています。 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 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.
並べ替えの影響を受けやすいトンネルプロトコルおよび機能を使用した並べ替えの望ましくない相互作用を回避する最も簡単な方法は、並べ替えの影響を受けやすいプロトコルまたは機能を使用しないことですが、これは多くの場合望ましくなく、不可能です。このようなプロトコルまたは機能を使用する場合、トンネルを通る集約されたフローが[2-外部]でマークされ、単一の順序付き集約を構成するようにすることで、相互作用を回避できます（つまり、使用されるPHBは、パケットが再注文）。トンネルプロトコルの仕様では、トンネルを単一の順序付き集約に制限する必要があるかどうか、またどのような状況で制限する必要があるか、およびその制限から逸脱した場合の結果を示す必要があります。上記のIPSecおよびL2TPの例の場合、仕様では、並べ替えの影響を受けやすいプロトコル機能が構成されている場合、各トンネルを単一の順序付き集約に制限する必要があり、プロトコル機能またはトンネルされたトラフィックの構成。 Diffservの実装では、このようなトンネル内を調べて、カプセル化されたマイクロフローに並べ替えベースの差別化を提供することはできません。このようなトンネル内で並べ替えに基づく区別が必要な場合は、同じエンドポイント間で複数の並列トンネルを使用する必要があります。これにより、異なるトンネル内のパケット間の並べ替えが、個々のトンネル内でのパケットの並べ替えの欠如と共存できるようになります。 IPSecおよび関連するセキュリティプロトコルの場合、複数のトンネルを使用することによって可能になったトラフィック分析は、外部ヘッダーのDSCPに基づいて実行することもできるため、複数のトンネルではなく、複数の順序付きアグリゲートに単一のトンネルを使用することには暗号上の利点はありません。単一のトンネル内のトラフィック。一般に、複数のトンネル（暗号化コンテキストなど）をサポートするために必要な追加のリソース、および複数のトンネルがネットワーク管理に与える影響は、それらを展開するかどうか、どこに展開するかを決定する際に考慮する必要があります。
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.
トンネルの動作特性は、どのトラフィックがトンネルを利用するかを決定する上で重要な考慮事項です。これには、[2-Outer]でトラフィックにマークされたPHBとDSCPだけでなく、参加しているすべてのドメインのサービスプロビジョニングポリシーが含まれます。たとえば、デフォルトのPHBトンネルを介してEF 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.
サービスプロビジョニングポリシーは、不適切にプロビジョニングされたデフォルトトンネルを介してEFトラフィックを転送するなどの不一致を防ぐ責任があります。動作特性が異なる複数の並列トンネルが使用可能な場合、サービスプロビジョニングポリシーは、どのフローがどのトンネルを使用するかを決定する責任があります。可能性の中には、内部DSCP値がトラフィックのPHBと互換性のある動作集約を使用してトラフィックを転送するトンネルを選択するために使用される、ユニフォームトンネルモデルの粗バージョンがあります。
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 conditioners with respect to tunnel decapsulation processing, as shown in the following diagram that depicts the flow of IP headers through tunnel decapsulation:
上記のセクション3で説明したように、この分析は、diffserv機能および/または帯域外通信パスがトンネルカプセル化処理と並列に配置されないアプローチに基づいています。これにより、トンネルのカプセル開放を介したIPヘッダーのフローを示す次の図に示すように、トンネルのカプセル開放処理に関してトラフィックコンディショナーの3つの可能な場所が可能になります。
>>----[5 - Outer]-------------+
\
\
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
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-Outer]および[6-After]でのトラフィック調整は、トンネルのカプセル開放の存在による影響を受けないため、トンネルから論理的に分離されています。トンネルの設計と仕様は、これらの場所での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-内部]の場所は、内部IPヘッダーを操作するためにパケットの内部に到達する必要があるため、トラフィックの調整に使用するのは困難です。カプセル化の[3-内部]の場合とは異なり、diffservトラフィック調整をトンネルのカプセル化解除に追加できるため（[6-後]で実行される）、[4-内部]で機能を実行する必要はありません。
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-After]のトラフィック調整ブロックへの帯域外入力として提示する必要があり、トラフィック調整が複雑になります。モデル。
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-変更後]で実装されるトラフィック調整機能の完全性はそのままにします。トンネルは、トンネルの出口で一方または他方のDSCP値の静的選択をサポートする必要があります。このアプローチの根拠は、通常、2つのDSCP値の1つだけが有用な情報を含んでいることです。トンネルの概念モデルは、どれが有用な情報を含んでいるかの強力な指標を提供します。通常、外側のDSCP値には、統一モデルに基づくトンネルに関する有用な情報が含まれ、内側のDSCP値には、通常、パイプモデルに基づくトンネルに関する有用な情報が含まれます。 IPSecトンネルは通常、パイプモデルに基づいており、セキュリティ上の理由から、現在、内部DSCP値を選択する必要があります。結果として生じるリスクと影響の適切なセキュリティ分析がない場合は、外部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選択アプローチの健全性チェックとして、このサブセクションでは、より複雑なアプローチが必要になる可能性がある状況を検討します。 1つのDSCP値を静的に選択しても、両方の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:
例として、トンネルエンドポイントで2つのドメインによって異なるAFグループ[RFC 2597]が使用されており、DSCPをゼロに設定することによって通過するRFC 791 IP precedenceを使用するトンネルに沿った中間ドメインがある状況を考えます。 。この状況を次のIPヘッダーフロー図に示します。ここで、Iはトンネル入口ノード、Eはトンネル出口ノード、縦線はドメイン境界です。左側の縦線のノードは、中間ドメインとの互換性を確保するために、外部ヘッダーのDSCPを0に設定します。
| |
+-----|-------------------|------+
/ | | \
>>-----------I-------|-------------------|--------E---------->>
| |
Ingress DS Domain RFC 791 Egress DS domain
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 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].
この状況では、出力ドメインのDSエッジノード（つまり、右側の垂直線にあるノード）は適切なAFグループを（MF分類子などを介して）選択できますが、削除されたドロップ優先情報を再構築できませんRFC 791ドメインを通過したときの外部ヘッダーから（メータリングとマーキングによって新しい情報を構築できますが）。元のドロップ優先情報は内部IPヘッダーのDSCPに保存され、トンネル出口で外部IPヘッダーのDSCPを介して通信されるAFクラス選択と組み合わせることができます。新しいドロップ優先順位マーキングを構築するのではなく、元のドロップ優先順位情報を再利用できるというわずかな利点は、両方のDSCP値を[6-After]でトラフィック調整に使用できるようにすることによってトンネル出力トラフィックコンディショナーに導入される追加の複雑さを正当化しません。
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.
関連する問題には、ステートレスIP / ICMP変換アルゴリズム[RFC 2765]を採用しているものを含む、プロトコルトランスレータが含まれます。これらのトランスレータは、2番目のIPヘッダーをパケットに追加したり、パケットから削除したりしないため（たとえば、IPv6 over IPv4トンネル[RFC 1933]とは対照的に）、トンネルではありません。したがって、内部IPヘッダーと外部IPヘッダー間の情報伝達の懸念はありません。 。トランスレータとdiffservの間の主な相互作用は、変換境界もdiffservドメイン境界である可能性が高いことです（たとえば、IPv4ドメインとIPv6ドメインは、トラフィック調整とDSCP使用に関して異なるポリシーを持っている可能性があります）。したがって、そのようなトランスレータは、変換処理前後のdiffservエッジノード処理（トラフィック調整を含む）。
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.
[RFC 2474、RFC 2475]で説明されているdiffservアーキテクチャのセキュリティに関する考慮事項は、トンネルが存在する場合に適用されます。要件の1つは、diffservドメインの内部にあるトンネル出力ノードが、トンネルを出るトラフィックのDS入力ノードであり、適切なトラフィック調整を実行することです。主要なセキュリティ上の意味は、トラフィックコンディショニングが、トンネルから出るトラフィックによってdiffservドメインにもたらされるサービスの盗難およびサービス拒否の脅威に対処することです。 IPSecアーキテクチャ[RFC 2401]は、トンネル出力処理にさらに制限を課します。適用されるトラフィック調整のプロパティが既知であり、セキュリティの脆弱性について適切に分析されていない限り、外部ヘッダーは破棄されます。これには、トンネル出口ノードの[5-外]および[6-後]トラフィック調整ブロックが含まれます（存在する場合）。また、カプセル化されたDSドメイン入力ノードである上流DSエッジノードによって実行されるトラフィック調整が含まれる場合があります。トンネルトラフィック。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1661] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 1933] Gilligan、R.およびE. Nordmark、「Transition Mechanisms for IPv6 Hosts and Routers」、RFC 1933、1996年4月。
[RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC 2003]パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2401]ケント、S。およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、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.
[RFC 2474] Nichols、K.、Blake、S.、Baker、F.、D。Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、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.
[RFC 2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597. June 1999.
[RFC 2597] Heinanen、J.、Baker、F.、Weiss、W。およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC2597。1999年6月。
[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[RFC 2598] Jacobson、V.、Nichols、K。およびK. Poduri、「An Expedited Forwarding PHB」、RFC 2598、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.
[RFC 2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター。 「レイヤ2トンネリングプロトコル "L2TP"」、RFC 2661、1999年8月。
[RFC 2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC 2765] Nordmark、E。、「Stateless IP / ICMP Translation Algorithm（SIIT）」、RFC 2765、2000年2月。
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会議中のこのトピックに関するdiffserv WGへの彼のプレゼンテーションに基づいています。クレジットはまた、トンネルの領域でdiffservアーキテクチャ[RFC 2475]の制限を発見したトンネル仕様に取り組んでいる多くの人々によるものです。この一連の問題に対処するのにかかった時間に対する彼らの忍耐は、非常に高く評価されています。最後に、この資料は、ミーティングとメーリングリストの両方でのdiffserv WG内での議論の恩恵を受けています。これらの議論への参加者の貢献は、ありがたく認められています。
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
デビッドL.ブラックEMCコーポレーション42 South St. Hopkinton、MA 01748
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。