IPv4およびIPv6ヘッダーのDiffServフィールド(DSフィールド)の定義

英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。

日本語訳

Network Working Group                                         K. Nichols
Request for Comments: 2474                                 Cisco Systems
Obsoletes: 1455, 1349                                           S. Blake
Category: Standards Track                Torrent Networking Technologies
                                                                F. Baker
                                                           Cisco Systems
                                                                D. Black
                                                         EMC Corporation
                                                           December 1998


    Definition of the Differentiated Services Field (DS Field)
                      in the IPv4 and IPv6 Headers

IPv4およびIPv6ヘッダーのDiffServフィールド(DSフィールド)の定義


Status of this Memo

このメモのステータス


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。 このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。 このメモの配布は無制限です。


Copyright Notice

著作権表示


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

Copyright(C)The Internet Society(1998)。 全著作権所有。


Abstract


   Differentiated services enhancements to the Internet protocol are
   intended to enable scalable service discrimination in the Internet
   without the need for per-flow state and signaling at every hop.  A
   variety of services may be built from a small, well-defined set of
   building blocks which are deployed in network nodes.  The services
   may be either end-to-end or intra-domain; they include both those
   that can satisfy quantitative performance requirements (e.g., peak
   bandwidth) and those based on relative performance (e.g., "class"
   differentiation).  Services can be constructed by a combination of:

インターネットプロトコルに対する差別化されたサービスの拡張は、フローごとの状態やすべてのホップでのシグナリングを必要とせずに、インターネットでスケーラブルなサービス識別を可能にすることを目的としています。 さまざまなサービスは、ネットワークノードに展開された、小さく、明確に定義されたビルディングブロックのセットから構築できます。 サービスは、エンドツーエンドまたはドメイン内のいずれかです。 これらには、定量的なパフォーマンス要件を満たすことができるもの(たとえば、ピーク帯域幅)と、相対的なパフォーマンスに基づくもの(たとえば、「クラス」の区別)の両方が含まれます。 サービスは、次の組み合わせで構成できます。


   - setting bits in an IP header field at network boundaries
     (autonomous system boundaries, internal administrative boundaries,
     or hosts),
   - using those bits to determine how packets are forwarded by the
     nodes inside the network, and
   - conditioning the marked packets at network boundaries in accordance
     with the requirements or rules of each service.

ネットワーク境界(自律システム境界、内部管理境界、またはホスト)でIPヘッダーフィールドにビットを設定する。
これらのビットを使用して、ネットワーク内のノードがパケットを転送する方法を決定します。
各サービスの要件またはルールに従って、ネットワーク境界でマークされたパケットを調整します。







Nichols, et. al.            Standards Track                     [Page 1]

RFC 2474             Differentiated Services Field         December 1998


   The requirements or rules of each service must be set through
   administrative policy mechanisms which are outside the scope of this
   document.  A differentiated services-compliant network node includes
   a classifier that selects packets based on the value of the DS field,
   along with buffer management and packet scheduling mechanisms capable
   of delivering the specific packet forwarding treatment indicated by
   the DS field value.  Setting of the DS field and conditioning of the
   temporal behavior of marked packets need only be performed at network
   boundaries and may vary in complexity.

各サービスの要件またはルールは、このドキュメントの範囲外の管理ポリシーメカニズムを通じて設定する必要があります。 差別化されたサービス準拠ネットワークノードには、DSフィールドの値に基づいてパケットを選択する分類子と、DSフィールド値で示される特定のパケット転送処理を配信できるバッファ管理およびパケットスケジューリングメカニズムが含まれています。 DSフィールドの設定とマークされたパケットの一時的な動作の調整は、ネットワーク境界でのみ実行する必要があり、複雑さが異なる場合があります。


   This document defines the IP header field, called the DS (for
   differentiated services) field.  In IPv4, it defines the layout of
   the TOS octet; in IPv6, the Traffic Class octet.  In addition, a base
   set of packet forwarding treatments, or per-hop behaviors, is
   defined.

このドキュメントでは、DS(差別化サービス用)フィールドと呼ばれるIPヘッダーフィールドを定義します。 IPv4では、TOSオクテットのレイアウトを定義します。 IPv6では、トラフィッククラスオクテット。 さらに、パケット転送処理の基本セット、つまりホップごとの動作が定義されています。


   For a more complete understanding of differentiated services, see
   also the differentiated services architecture [ARCH].

差別化サービスのより完全な理解については、差別化サービスアーキテクチャ[ARCH]も参照してください。


Table of Contents

   1.  Introduction .................................................  3
   2.  Terminology Used in This Document ............................  5
   3.  Differentiated Services Field Definition .....................  7
   4.  Historical Codepoint Definitions and PHB Requirements ........  9
     4.1  A Default PHB .............................................  9
     4.2  Once and Future IP Precedence Field Use ................... 10
       4.2.1  IP Precedence History and Evolution in Brief .......... 10
       4.2.2  Subsuming IP Precedence into Class Selector  .......... 11
              Codepoints
         4.2.2.1  The Class Selector Codepoints ..................... 11
         4.2.2.2  The Class Selector PHB Requirements ............... 11
         4.2.2.3  Using the Class Selector PHB Requirements ......... 12
                  for IP Precedence Compatibility
         4.2.2.4  Example Mechanisms for Implementing Class ......... 12
                  Selector Compliant PHB Groups
     4.3  Summary ................................................... 13
   5.  Per-Hop Behavior Standardization Guidelines .................. 13
   6.  IANA Considerations .......................................... 14
   7.  Security Considerations ...................................... 15
     7.1  Theft and Denial of Service ............................... 15
     7.2  IPsec and Tunneling Interactions .......................... 16
   8.  Acknowledgments .............................................. 17
   9.  References ................................................... 17
   Authors' Addresses ............................................... 19
   Full Copyright Statement ......................................... 20


   1.はじめに............................................... .. 3
   2.このドキュメントで使用されている用語............................ 5
   3.差別化サービスフィールドの定義..................... 7
   4.過去のコードポイント定義とPHB要件........ 9
     4.1デフォルトのPHB ............................................. 9
     4.2以前および将来のIP precedenceフィールドの使用................... 10
       4.2.1 IP優先順位の歴史と進化の概要.......... 10
       4.2.2 IP優先順位のクラスセレクタへの組み込み.......... 11
              コードポイント
         4.2.2.1クラスセレクタのコードポイント..................... 11
         4.2.2.2クラスセレクタPHB要件............... 11
         4.2.2.3クラスセレクターPHB要件の使用......... 12
                  IP優先順位の互換性
         4.2.2.4クラスを実装するためのメカニズムの例......... 12
                  セレクター準拠のPHBグループ
     4.3まとめ................................................ ... 13
   5.ホップごとの動作標準化ガイドライン.................. 13
   6. IANAの考慮事項.......................................... 14
   7.セキュリティに関する考慮事項................................................ 15
     7.1盗難とサービス拒否............................... 15
     7.2 IPsecとトンネリングの相互作用.......................... 16
   8.謝辞.............................................. 17
   9.参考資料......................................................... .... 17
   著者のアドレス............................................... 19
   完全な著作権表示......................................... 20



Nichols, et. al.            Standards Track                     [Page 2]

RFC 2474             Differentiated Services Field         December 1998


1.  Introduction

1.はじめに


   Differentiated services are intended  to provide a framework and
   building blocks to enable deployment of scalable service
   discrimination in the Internet.  The differentiated services approach
   aims to speed deployment by separating the architecture into two
   major components, one of which is fairly well-understood and the
   other of which is just beginning to be understood.  In this, we are
   guided by the original design of the Internet where the decision was
   made to separate the forwarding and routing components.  Packet
   forwarding is the relatively simple task that needs to be performed
   on a per-packet basis as quickly as possible.  Forwarding uses the
   packet header to find an entry in a routing table that determines the
   packet's output interface.  Routing sets the entries in that table
   and may need to reflect a range of transit and other policies as well
   as to keep track of route failures.  Routing tables are maintained as
   a background process to the forwarding task.  Further, routing is the
   more complex task and it has continued to evolve over the past 20
   years.

差別化されたサービスは、インターネットでのスケーラブルなサービス差別の展開を可能にするフレームワークとビルディングブロックを提供することを目的としています。 差別化されたサービスアプローチは、アーキテクチャを2つの主要なコンポーネントに分割することにより、展開を迅速化することを目的としています。一方はかなりよく理解されており、もう一方はまだ理解され始めています。 これは、転送コンポーネントとルーティングコンポーネントを分離することを決定したインターネットの元の設計に基づいています。 パケット転送は比較的単純なタスクであり、パケットごとにできるだけ迅速に実行する必要があります。 転送では、パケットヘッダーを使用して、パケットの出力インターフェイスを決定するルーティングテーブル内のエントリを検索します。 ルーティングはそのテーブルのエントリを設定し、ルートの障害を追跡するだけでなく、さまざまなトランジットおよびその他のポリシーを反映する必要がある場合があります。 ルーティングテーブルは、転送タスクのバックグラウンドプロセスとして維持されます。 さらに、ルーティングはより複雑なタスクであり、過去20年にわたって進化を続けてきました。


   Analogously, the differentiated services architecture contains two
   main components.  One is the fairly well-understood behavior in the
   forwarding path and the other is the more complex and still emerging
   background policy and allocation component that configures parameters
   used in the forwarding path.  The forwarding path behaviors include
   the differential treatment an individual packet receives, as
   implemented by queue service disciplines and/or queue management
   disciplines.  These per-hop behaviors are useful and required in
   network nodes to deliver differentiated treatment of packets no
   matter how we construct end-to-end or intra-domain services.  Our
   focus is on the general semantics of the behaviors rather than the
   specific mechanisms used to implement them since these behaviors will
   evolve less rapidly than the mechanisms.

同様に、差別化サービスアーキテクチャには2つの主要コンポーネントが含まれています。 1つは転送パスでかなりよく理解されている動作であり、もう1つは、転送パスで使用されるパラメーターを構成する、より複雑で現在も出現しているバックグラウンドポリシーおよび割り当てコンポーネントです。 転送パスの動作には、キューサービスの専門分野および/またはキュー管理の専門分野によって実装された、個々のパケットが受け取る異なる扱いが含まれます。 これらのホップごとの動作は、エンドツーエンドサービスやドメイン内サービスの構築方法に関係なく、パケットの差別化された処理を提供するために、ネットワークノードで有用かつ必要です。 これらの動作はメカニズムよりも速く進化しないため、これらの実装に使用される特定のメカニズムではなく、動作の一般的なセマンティクスに焦点を当てています。


   Per-hop behaviors and mechanisms to select them on a per-packet basis
   can be deployed in network nodes today and it is this aspect of the
   differentiated services architecture that is being addressed first.
   In addition, the forwarding path may require that some monitoring,
   policing, and shaping be done on the network traffic designated for
   "special" treatment in order to enforce requirements associated with
   the delivery of the special treatment.  Mechanisms for this kind of
   traffic conditioning are also fairly well-understood.  The wide
   deployment of such traffic conditioners is also important to enable
   the construction of services, though their actual use in constructing
   services may evolve over time.

パケット単位でそれらを選択するためのホップ単位の動作とメカニズムは、今日のネットワークノードに展開できます。これが、最初に対処されている差別化されたサービスアーキテクチャのこの側面です。 さらに、転送パスでは、特別な処理の配信に関連する要件を適用するために、「特別な」処理用に指定されたネットワークトラフィックに対して監視、ポリシング、およびシェーピングを行う必要がある場合があります。 この種のトラフィック調整のメカニズムも、かなりよく理解されています。 このようなトラフィックコンディショナーの幅広い展開は、サービスの構築を可能にするためにも重要ですが、サービス構築における実際の使用法は、時間とともに進化する可能性があります。







Nichols, et. al.            Standards Track                     [Page 3]

RFC 2474             Differentiated Services Field         December 1998


   The configuration of network elements with respect to which packets
   get special treatment and what kinds of rules are to be applied to
   the use of resources is much less well-understood.  Nevertheless, it
   is possible to deploy useful differentiated services in networks by
   using simple policies and static configurations.  As described in
   [ARCH], there are a number of ways to compose per-hop behaviors and
   traffic conditioners to create services.  In the process, additional
   experience is gained that will guide more complex policies and
   allocations.  The basic behaviors in the forwarding path can remain
   the same while this component of the architecture evolves.
   Experiences with the construction of such services will continue for
   some time, thus we avoid standardizing this construction as it is
   premature.  Further, much of the details of service construction are
   covered by legal agreements between different business entities and
   we avoid this as it is very much outside the scope of the IETF.

どのパケットが特別な扱いを受けるか、およびどのような種類のルールがリソースの使用に適用されるかに関するネットワーク要素の構成は、あまりよく理解されていません。 それにもかかわらず、単純なポリシーと静的構成を使用することにより、有用な差別化されたサービスをネットワークに展開することが可能です。 [ARCH]で説明されているように、サービスを作成するためにホップごとの動作とトラフィック調整を構成する方法はいくつかあります。 その過程で、より複雑なポリシーと割り当てを導く追加の経験が得られます。 アーキテクチャのこのコンポーネントが進化する間、転送パスの基本的な動作は同じままでかまいません。 このようなサービスの構築に関する経験はしばらく続くでしょう。したがって、この構築は時期尚早であるため、標準化を避けます。 さらに、サービス構築の詳細の多くは、さまざまなビジネスエンティティ間の法的合意によってカバーされており、IETFの範囲外であるため、これを回避します。


   This document concentrates on the forwarding path component.  In the
   packet forwarding path, differentiated services are realized by
   mapping the codepoint contained in a field in the IP packet header to
   a particular forwarding treatment, or per-hop behavior (PHB), at each
   network node along its path.  The codepoints may be chosen from a set
   of mandatory values defined later in this document, from a set of
   recommended values to be defined in future documents, or may have
   purely local meaning.  PHBs are expected to be implemented by
   employing a range of queue service and/or queue management
   disciplines on a network node's output interface queue: for example
   weighted round-robin (WRR) queue servicing or drop-preference queue
   management.

このドキュメントでは、転送パスコンポーネントに焦点を当てています。 パケット転送パスでは、IPパケットヘッダーのフィールドに含まれるコードポイントを、パスに沿った各ネットワークノードで特定の転送処理、つまりホップごとの動作(PHB)にマッピングすることにより、差別化されたサービスが実現されます。 コードポイントは、このドキュメントの後半で定義される一連の必須の値、将来のドキュメントで定義される一連の推奨値から選択するか、純粋にローカルな意味を持つ場合があります。 PHBは、ネットワークノードの出力インターフェイスキューで一連のキューサービスやキュー管理の規則を採用することで実装されることが期待されています。たとえば、重み付けラウンドロビン(WRR)キューサービスやドロップ優先キュー管理などです。


   Marking is performed by traffic conditioners at network boundaries,
   including the edges of the network (first-hop router or source host)
   and administrative boundaries.  Traffic conditioners may include the
   primitives of marking, metering, policing and shaping (these
   mechanisms are described in [ARCH]).  Services are realized by the
   use of particular packet classification and traffic conditioning
   mechanisms at boundaries coupled with the concatenation of per-hop
   behaviors along the transit path of the traffic.  A goal of the
   differentiated services architecture is to specify these building
   blocks for future extensibility, both of the number and type of the
   building blocks and of the services built from them.

マーキングは、ネットワークのエッジ(ファーストホップルーターまたはソースホスト)および管理境界を含むネットワーク境界でトラフィックコンディショナーによって実行されます。 トラフィックコンディショナーには、マーキング、メータリング、ポリシング、シェーピングのプリミティブが含まれる場合があります(これらのメカニズムは[ARCH]で説明されています)。 サービスは、トラフィックのトランジットパスに沿ったホップごとの動作の連結と結合された境界での特定のパケット分類およびトラフィック調整メカニズムの使用によって実現されます。 差別化されたサービスアーキテクチャの目標は、これらのビルディングブロックを、ビルディングブロックの数とタイプ、およびそれらから構築されるサービスの両方について、将来の拡張性のために指定することです。


   Terminology used in this memo is defined in Sec. 2.  The
   differentiated services field definition (DS field) is given in Sec.
   3.  In Sec. 4, we discuss the desire for partial backwards
   compatibility with current use of the IPv4 Precedence field.  As a
   solution, we introduce Class Selector Codepoints and Class Selector





Nichols, et. al.            Standards Track                     [Page 4]

RFC 2474             Differentiated Services Field         December 1998


   Compliant PHBs.  Sec. 5 presents guidelines for per-hop behavior
   standardization.  Sec. 6 discusses guidelines for allocation of
   codepoints.  Sec. 7 covers security considerations.

このメモで使用される用語は、Sec.2で定義されています。 差別化サービスフィールド定義(DSフィールド)は、Sec.3に記載されています。 Sec.4では、IPv4 Precedenceフィールドの現在の使用との部分的な下位互換性の要望について説明します。 ソリューションとして、クラスセレクターコードポイントとクラスセレクター準拠のPHBを紹介します。 Sec.5は、ホップごとの動作の標準化に関するガイドラインを示しています。 Sec.6では、コードポイントの割り当てに関するガイドラインについて説明しています。 Sec.7では、セキュリティに関する考慮事項について説明します。


   This document is a concise description of the DS field and its uses.
   It is intended to be read along with the differentiated services
   architecture [ARCH].

このドキュメントは、DSフィールドとその使用法の簡潔な説明です。 これは、差別化サービスアーキテクチャ[ARCH]とともに読むことを目的としています。


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。


2.  Terminology Used in This Document

2.このドキュメントで使用されている用語


   Behavior Aggregate: a collection of packets with the same codepoint
   crossing a link in a particular direction.  The terms "aggregate" and
   "behavior aggregate" are used interchangeably in this document.

Behavior Aggregate:特定の方向でリンクを通過する同じコードポイントを持つパケットのコレクション。 「集約」および「動作集約」という用語は、このドキュメントでは互換的に使用されます。


   Classifier: an entity which selects packets based on the content of
   packet headers according to defined rules.

分類子:定義されたルールに従ってパケットヘッダーの内容に基づいてパケットを選択するエンティティ。


   Class Selector Codepoint: any of the eight codepoints in the range '
   xxx000' (where 'x' may equal '0' or '1').  Class Selector Codepoints
   are discussed in Sec. 4.2.2.

クラスセレクターコードポイント: 'xxx000'( 'x'は '0'または '1'に等しい)の範囲の8つのコードポイントのいずれか。 クラスセレクターのコードポイントについては、セクション4.2.2で説明します。


   Class Selector Compliant PHB: a per-hop behavior satisfying the Class
   Selector PHB Requirements specified in Sec. 4.2.2.2.

クラスセレクター準拠のPHB:セクション4.2.2.2で指定されたクラスセレクターPHB要件を満たすホップごとの動作。


   Codepoint: a specific value of the DSCP portion of the DS field.
   Recommended codepoints SHOULD map to specific, standardized PHBs.
   Multiple codepoints MAY map to the same PHB.

コードポイント:DSフィールドのDSCP部分の特定の値。 推奨されるコードポイントは、特定の標準化されたPHBにマップする必要があります(SHOULD)。 複数のコードポイントが同じPHBにマッピングされる場合があります。


   Differentiated Services Boundary: the edge of a DS domain, where
   classifiers and traffic conditioners are likely to be deployed.  A
   differentiated services boundary can be further sub-divided into
   ingress and egress nodes, where the ingress/egress nodes are the
   downstream/upstream nodes of a boundary link in a given traffic
   direction.  A differentiated services boundary typically is found at
   the ingress to the first-hop differentiated services-compliant router
   (or network node) that a host's packets traverse, or at the egress of
   the last-hop differentiated services-compliant router or network node
   that packets traverse before arriving at a host.  This is sometimes
   referred to as the boundary at a leaf router.  A differentiated
   services boundary may be co-located with a host, subject to local
   policy.  Also DS boundary.

差別化されたサービス境界:DSドメインのエッジ。分類子とトラフィックコンディショナーが展開される可能性があります。 差別化されたサービス境界は、入力ノードと出力ノードにさらに分割できます。ここで、入力/出力ノードは、所定のトラフィック方向の境界リンクのダウンストリーム/アップストリームノードです。 差別化サービスの境界は、通常、ホストのパケットが通過する最初のホップの差別化サービスに準拠したルーター(またはネットワークノード)への入口、または最後のホップの差別化サービスに準拠したルーターまたはネットワークノードのパケットの出口にあります。 ホストに到着する前にトラバースします。 これは、リーフルータの境界と呼ばれることもあります。 差別化されたサービス境界は、ローカルポリシーに従って、ホストと同じ場所に配置できます。 DS境界も。


   Differentiated Services-Compliant: in compliance with the
   requirements specified in this document.  Also DS-compliant.

差別化サービスに準拠:このドキュメントで指定されている要件に準拠しています。 DSにも対応。




Nichols, et. al.            Standards Track                     [Page 5]

RFC 2474             Differentiated Services Field         December 1998


   Differentiated Services Domain: a contiguous portion of the Internet
   over which a consistent set of differentiated services policies are
   administered in a coordinated fashion.  A differentiated services
   domain can represent different administrative domains or autonomous
   systems, different trust regions, different network technologies
   (e.g., cell/frame), hosts and routers, etc.  Also DS domain.

差別化サービスドメイン:一貫した一連の差別化サービスポリシーが調整された方法で管理されるインターネットの連続した部分。 差別化されたサービスドメインは、さまざまな管理ドメインや自律システム、さまざまな信頼領域、さまざまなネットワークテクノロジー(セル/フレームなど)、ホストやルーターなどを表すことができます。 DSドメイン。


   Differentiated Services Field: the IPv4 header TOS octet or the IPv6
   Traffic Class octet when interpreted in conformance with the
   definition given in this document.  Also DS field.

Differentiated Services Field:このドキュメントに記載されている定義に従って解釈された場合のIPv4ヘッダーTOSオクテットまたはIPv6トラフィッククラスオクテット。 DSフィールドも。


   Mechanism:  The implementation of one or more per-hop behaviors
   according to a particular algorithm.

メカニズム:特定のアルゴリズムに従った1つ以上のホップごとの動作の実装。


   Microflow: a single instance of an application-to-application flow of
   packets which is identified by source address, destination address,
   protocol id, and source port, destination port (where applicable).

Microflow:送信元アドレス、宛先アドレス、プロトコルID、および送信元ポート、宛先ポート(該当する場合)によって識別される、アプリケーション間のパケットフローの単一インスタンス。


   Per-hop Behavior (PHB): a description of the externally observable
   forwarding treatment applied at a differentiated services-compliant
   node to a behavior aggregate.  The description of a PHB SHOULD be
   sufficiently detailed to allow the construction of predictable
   services, as documented in [ARCH].

ホップごとの動作(PHB):差別化されたサービス準拠ノードで動作集計に適用される、外部から観察可能な転送処理の説明。 [ARCH]に記載されているように、PHBの説明は、予測可能なサービスの構築を可能にするために十分に詳細である必要があります(SHOULD)。


   Per-hop Behavior Group: a set of one or more PHBs that can only be
   meaningfully specified and implemented simultaneously, due to a
   common constraint applying to all PHBs in the set such as a queue
   servicing or queue management policy.  Also PHB Group.

ホップごとの動作グループ:キューサービスやキュー管理ポリシーなどのセット内のすべてのPHBに共通の制約が適用されるため、同時に意味のある指定と実装のみが可能な1つ以上のPHBのセット。 またPHBグループ。


   Traffic Conditioning: control functions that can be applied to a
   behavior aggregate, application flow, or other operationally useful
   subset of traffic, e.g., routing updates.  These MAY include
   metering, policing, shaping, and packet marking.  Traffic
   conditioning is used to enforce agreements between domains and to
   condition traffic to receive a differentiated service within a domain
   by marking packets with the appropriate codepoint in the DS field and
   by monitoring and altering the temporal characteristics of the
   aggregate where necessary.  See [ARCH].

トラフィックコンディショニング:動作集約、アプリケーションフロー、またはその他の操作上有用なトラフィックのサブセット(ルーティングの更新など)に適用できる制御機能。 これらには、メータリング、ポリシング、シェーピング、およびパケットマーキングが含まれる場合があります。 トラフィック調整は、ドメイン間の合意を強制し、ドメイン内の差別化されたサービスを受信するようにトラフィックを調整するために使用されます。DSフィールドで適切なコードポイントでパケットをマークし、必要に応じて集約の時間特性を監視および変更します。 [ARCH]を参照してください。


   Traffic Conditioner: an entity that performs traffic conditioning
   functions and which MAY contain meters, policers, shapers, and
   markers.  Traffic conditioners are typically deployed in DS boundary
   nodes (i.e., not in interior nodes of a DS domain).

トラフィックコンディショナー:トラフィックコンディショニング機能を実行するエンティティで、メーター、ポリサー、シェーパー、マーカーを含めることができます。 トラフィックコンディショナーは通常、DS境界ノードに配置されます(つまり、DSドメインの内部ノードには配置されません)。


   Service: a description of the overall treatment of (a subset of) a
   customer's traffic across a particular domain, across a set of
   interconnected DS domains, or end-to-end.  Service descriptions are
   covered by administrative policy and services are constructed by



Nichols, et. al.            Standards Track                     [Page 6]

RFC 2474             Differentiated Services Field         December 1998


   applying traffic conditioning to create behavior aggregates which
   experience a known PHB at each node within the DS domain.  Multiple
   services can be supported by a single per-hop behavior used in
   concert with a range of traffic conditioners.

サービス:特定のドメイン間、相互接続されたDSドメインのセット全体、またはエンドツーエンドでの顧客のトラフィック(のサブセット)の全体的な処理の説明。 サービスの説明は管理ポリシーによってカバーされ、DSドメイン内の各ノードで既知のPHBを経験する動作集約を作成するためにトラフィック調整を適用することによってサービスが構築されます。 さまざまなトラフィックコンディショナーと連携して使用される単一のホップごとの動作により、複数のサービスをサポートできます。


   To summarize, classifiers and traffic conditioners are used to select
   which packets are to be added to behavior aggregates.  Aggregates
   receive differentiated treatment in a DS domain and traffic
   conditioners MAY alter the temporal characteristics of the aggregate
   to conform to some requirements.  A packet's DS field is used to
   designate the packet's behavior aggregate and is subsequently used to
   determine which forwarding treatment the packet receives.  A behavior
   aggregate classifier which can select a PHB, for example a
   differential output queue servicing discipline, based on the
   codepoint in the DS field SHOULD be included in all network nodes in
   a DS domain.  The classifiers and traffic conditioners at DS
   boundaries are configured in accordance with some service
   specification, a matter of administrative policy outside the scope of
   this document.

要約すると、分類子とトラフィックコンディショナーを使用して、動作集約に追加するパケットを選択します。 アグリゲートはDSドメインで差別化された処理を受け取り、トラフィックコンディショナーは、いくつかの要件に準拠するようにアグリゲートの時間特性を変更する場合があります。 パケットのDSフィールドは、パケットの動作集約を指定するために使用され、その後、パケットが受信する転送処理を決定するために使用されます。 DSフィールドのコードポイントに基づいて、PHBを選択できる動作集約分類子、たとえば、差動出力キューサービスの規律は、DSドメインのすべてのネットワークノードに含める必要があります(SHOULD)。 DS境界の分類子とトラフィックコンディショナーは、このドキュメントの範囲外の管理ポリシーの問題であるサービス仕様に従って構成されます。


   Additional differentiated services definitions are given in [ARCH].

追加の差別化サービスの定義は、[ARCH]に記載されています。


3.  Differentiated Services Field Definition

3. DiffServフィールド定義


   A replacement header field, called the DS field, is defined, which is
   intended to supersede the existing definitions of the IPv4 TOS octet
   [RFC791] and the IPv6 Traffic Class octet [IPv6].

DSフィールドと呼ばれる置換ヘッダーフィールドが定義されています。これは、IPv4 TOSオクテット[RFC791]およびIPv6トラフィッククラスオクテット[IPv6]の既存の定義に取って代わることを目的としています。


   Six bits of the DS field are used as a codepoint (DSCP) to select the
   PHB a packet experiences at each node.  A two-bit currently unused
   (CU) field is reserved and its definition and interpretation are
   outside the scope of this document.  The value of the CU bits are
   ignored by differentiated services-compliant nodes when determining
   the per-hop behavior to apply to a received packet.

DSフィールドの6ビットは、各ノードでパケットが経験するPHBを選択するためのコードポイント(DSCP)として使用されます。 現在未使用の2ビット(CU)フィールドは予約されており、その定義と解釈はこのドキュメントの範囲外です。 CUビットの値は、受信したパケットに適用するホップごとの動作を決定するときに、差別化されたサービス準拠ノードによって無視されます。


   The DS field structure is presented below:

DSフィールドの構造を以下に示します。



        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |         DSCP          |  CU   |
      +---+---+---+---+---+---+---+---+

        DSCP: differentiated services codepoint
        CU:   currently unused

DSCP:差別化サービスコードポイント
CU:現在未使用







Nichols, et. al.            Standards Track                     [Page 7]

RFC 2474             Differentiated Services Field         December 1998


   In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1')
   used in this document, the left-most bit signifies bit 0 of the DS
   field (as shown above), and the right-most bit signifies bit 5.

このドキュメントで使用されているDSCP値の表記 'xxxxxx'( 'x'は '0'または '1'と等しい場合があります)では、左端のビットはDSフィールドのビット0を示し(上記のように)、右端のビットは ほとんどのビットはビット5を意味します。


   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire 6-bit
   DSCP field, e.g., by treating the value of the field as a table index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.  The value of the CU field MUST
   be ignored by PHB selection.  The DSCP field is defined as an
   unstructured field to facilitate the definition of future per-hop
   behaviors.

実装者は、DSCPフィールドが6ビット幅であることに注意する必要があります。 DS準拠のノードは、たとえばフィールドの値を、そのデバイスに実装されている特定のパケット処理メカニズムを選択するために使用されるテーブルインデックスとして扱うことにより、6ビットのDSCPフィールド全体と照合することでPHBを選択する必要があります。 CUフィールドの値は、PHB選択で無視する必要があります。 DSCPフィールドは、将来のホップごとの動作の定義を容易にするために、非構造化フィールドとして定義されます。


   With some exceptions noted below, the mapping of codepoints to PHBs
   MUST be configurable.  A DS-compliant node MUST support the logical
   equivalent of a configurable mapping table from codepoints to PHBs.
   PHB specifications MUST include a recommended default codepoint,
   which MUST be unique for codepoints in the standard space (see Sec.
   6).  Implementations should support the recommended codepoint-to-PHB
   mappings in their default configuration.  Operators may choose to use
   different codepoints for a PHB, either in addition to or in place of
   the recommended default.  Note that if operators do so choose, re-
   marking of DS fields may be necessary at administrative boundaries
   even if the same PHBs are implemented on both sides of the boundary.

以下に示すいくつかの例外を除いて、コードポイントのPHBへのマッピングは構成可能でなければなりません。 DS準拠のノードは、コードポイントからPHBへの構成可能なマッピングテーブルの論理的な同等物をサポートする必要があります。 PHB仕様には、推奨されるデフォルトのコードポイントが含まれている必要があります。これは、標準空間のコードポイントに対して一意である必要があります(Sec。 6)。 実装は、デフォルトの構成で推奨されるコードポイントからPHBへのマッピングをサポートする必要があります。 オペレーターは、推奨されるデフォルトに加えて、またはその代わりに、PHBに異なるコードポイントを使用することを選択できます。 オペレーターが選択した場合、同じPHBが境界の両側に実装されている場合でも、管理境界でDSフィールドの再マーキングが必要になる場合があることに注意してください。


   See [ARCH] for further discussion of re-marking.

再マーキングの詳細については、[ARCH]を参照してください。


   The exceptions to general configurability are for codepoints 'xxx000'
   and are noted in Secs. 4.2.2 and 4.3.

一般的な構成可能性の例外は、コードポイント「xxx000」であり、セクション4.2.2および4.3に記載されています。


   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

認識されないコードポイントで受信されたパケットは、デフォルトの動作としてマークされているかのように転送する必要があります(セクションを参照)。 4)、およびそれらのコードポイントは変更しないでください。 そのようなパケットはネットワークノードを誤動作させてはいけません。


   The structure of the DS field shown above is incompatible with the
   existing definition of the IPv4 TOS octet in [RFC791].  The
   presumption is that DS domains protect themselves by deploying re-
   marking boundary nodes, as should networks using the RFC 791
   Precedence designations.  Correct operational procedure SHOULD follow
   [RFC791], which states: "If the actual use of these precedence
   designations is of concern to a particular network, it is the
   responsibility of that network to control the access to, and use of,
   those precedence designations."  Validating the value of the DS field
   at DS boundaries is sensible in any case since an upstream node can
   easily set it to any arbitrary value.  DS domains that are not
   isolated by suitably configured boundary nodes may deliver
   unpredictable service.

上記のDSフィールドの構造は、[RFC791]のIPv4 TOSオクテットの既存の定義と互換性がありません。 RFC 791 Precedence指定を使用するネットワークと同様に、DSドメインは境界ノードの再マーキングを展開することで自分自身を保護することが前提です。 「これらの優先順位の指定の実際の使用が特定のネットワークに関係がある場合、それらの優先順位の指定へのアクセスと使用を制御するのはそのネットワークの責任です。 上流ノードは簡単に任意の値に設定できるため、DS境界でのDSフィールドの値の検証は、いずれの場合も賢明です。 適切に構成された境界ノードによって分離されていないDSドメインは、予測できないサービスを提供する可能性があります。




Nichols, et. al.            Standards Track                     [Page 8]

RFC 2474             Differentiated Services Field         December 1998


   Nodes MAY rewrite the DS field as needed to provide a desired local
   or end-to-end service.  Specifications of DS field translations at DS
   boundaries are the subject of service level agreements between
   providers and users, and are outside the scope of this document.
   Standardized PHBs allow providers to build their services from a
   well-known set of packet forwarding treatments that can be expected
   to be present in the equipment of many vendors.

ノードは、必要に応じてDSフィールドを書き換えて、目的のローカルサービスまたはエンドツーエンドサービスを提供できます。 DS境界でのDSフィールド変換の仕様は、プロバイダーとユーザー間のサービスレベル契約の対象であり、このドキュメントの範囲外です。 標準化されたPHBにより、プロバイダーは、多くのベンダーの機器に存在することが予想される、よく知られている一連のパケット転送処理からサービスを構築できます。


4.  Historical Codepoint Definitions and PHB Requirements

4.過去のコードポイント定義とPHB要件


   The DS field will have a limited backwards compatibility with current
   practice, as described in this section.  Backwards compatibility is
   addressed in two ways.  First, there are per-hop behaviors that are
   already in widespread use (e.g., those satisfying the IPv4 Precedence
   queueing requirements specified in [RFC1812]), and we wish to permit
   their continued use in DS-compliant nodes.  In addition, there are
   some codepoints that correspond to historical use of the IP
   Precedence field and we reserve these codepoints to map to PHBs that
   meet the general requirements specified in Sec. 4.2.2.2, though the
   specific differentiated services PHBs mapped to by those codepoints
   MAY have additional specifications.

このセクションで説明するように、DSフィールドは、現在のプラクティスとの限定的な下位互換性があります。 下位互換性は2つの方法で対処されます。 まず、すでに広く使用されているホップごとの動作([RFC1812]で指定されているIPv4 Precedenceキューイング要件を満たす動作など)があり、それらをDS準拠ノードで引き続き使用できるようにしたいと考えています。 さらに、IP Precedenceフィールドの過去の使用に対応するコードポイントがいくつかあります。これらのコードポイントは、Sec。で指定された一般的な要件を満たすPHBにマップするために予約されています。 4.2.2.2、ただし、それらのコードポイントによってマッピングされた特定の差別化サービスPHBには追加の仕様がある場合があります。


   No attempt is made to maintain backwards compatibility with the "DTR"
   or TOS bits of the IPv4 TOS octet, as defined in [RFC791].

[RFC791]で定義されているように、IPv4 TOSオクテットの「DTR」またはTOSビットとの下位互換性を維持する試みは行われません。


4.1  A Default PHB

4.1デフォルトのPHB


   A "default" PHB MUST be available in a DS-compliant node.  This is
   the common, best-effort forwarding behavior available in existing
   routers as standardized in [RFC1812].  When no other agreements are
   in place, it is assumed that packets belong to this aggregate.  Such
   packets MAY be sent into a network without adhering to any particular
   rules and the network will deliver as many of these packets as
   possible and as soon as possible, subject to other resource policy
   constraints.  A reasonable implementation of this PHB would be a
   queueing discipline that sends packets of this aggregate whenever the
   output link is not required to satisfy another PHB.  A reasonable
   policy for constructing services would ensure that the aggregate was
   not "starved".  This could be enforced by a mechanism in each node
   that reserves some minimal resources (e.g, buffers, bandwidth) for
   Default behavior aggregates.  This permits senders that are not
   differentiated services-aware to continue to use the network in the
   same manner as today.  The impact of the introduction of
   differentiated services into a domain on the service expectations of
   its customers and peers is a complex matter involving policy
   decisions by the domain and is outside the scope of this document.
   The RECOMMENDED codepoint for the Default PHB is the bit pattern '
   000000'; the value '000000' MUST map to a PHB that meets these



Nichols, et. al.            Standards Track                     [Page 9]

RFC 2474             Differentiated Services Field         December 1998


   specifications.  The codepoint chosen for Default behavior is
   compatible with existing practice [RFC791].  Where a codepoint is not
   mapped to a standardized or local use PHB, it SHOULD be mapped to the
   Default PHB.

「デフォルト」のPHBは、DS準拠のノードで使用できる必要があります。 これは、[RFC1812]で標準化されている既存のルーターで利用できる一般的なベストエフォート転送動作です。 他の合意がない場合、パケットはこの集約に属していると想定されます。 このようなパケットは、特定のルールに準拠することなくネットワークに送信できます。ネットワークは、他のリソースポリシーの制約を受けて、これらのパケットをできるだけ多く、できるだけ早く配信します。 このPHBの合理的な実装は、出力リンクが別のPHBを満たす必要がない場合は常に、この集約のパケットを送信するキューイング規則です。 サービスを構築するための合理的なポリシーは、集合体が「不足」しないことを保証します。 これは、デフォルトの動作の集約のために最小限のリソース(バッファー、帯域幅など)を予約する各ノードのメカニズムによって適用できます。 これにより、差別化されたサービスに対応していない送信者は、現在と同じ方法でネットワークを引き続き使用できます。 ドメインへの差別化サービスの導入が顧客や同業者のサービスへの期待に与える影響は、ドメインによるポリシー決定を伴う複雑な問題であり、このドキュメントの範囲外です。 デフォルトPHBの推奨コードポイントは、ビットパターン '000000'です。値「000000」は、これらの仕様を満たすPHBにマップする必要があります。 デフォルトの動作に選択されたコードポイントは、既存のプラクティス[RFC791]と互換性があります。 コードポイントが標準化またはローカルで使用されるPHBにマッピングされていない場合、デフォルトのPHBにマッピングする必要があります(SHOULD)。


   A packet initially marked for the Default behavior MAY be re-marked
   with another codepoint as it passes a boundary into a DS domain so
   that it will be forwarded using a different PHB within that domain,
   possibly subject to some negotiated agreement between the peering
   domains.

最初にデフォルトの動作としてマークされたパケットは、DSドメインに境界を渡すときに別のコードポイントで再マークされ、そのドメイン内の別のPHBを使用して転送される可能性があります。


4.2  Once and Future IP Precedence Field Use

4.2以前および将来のIP precedenceフィールドの使用


   We wish to maintain some form of backward compatibility with present
   uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet.
   Routers exist that use the IP Precedence field to select different
   per-hop forwarding treatments in a similar way to the use proposed
   here for the DSCP field.  Thus, a simple prototype differentiated
   services architecture can be quickly deployed by appropriately
   configuring these routers.  Further, IP systems today understand the
   location of the IP Precedence field, and thus if these bits are used
   in a similar manner as DS-compliant equipment is deployed,
   significant failures are not likely during early deployment.  In
   other words, strict DS-compliance need not be ubiquitous even within
   a single service provider's network if bits 0-2 of the DSCP field are
   employed in a manner similar to, or subsuming, the deployed uses of
   the IP Precedence field.

IPv4 TOSオクテットのビット0~2であるIP Precedenceフィールドの現在の使用との何らかの下位互換性を維持したいと考えています。 IP Precedenceフィールドを使用して、ここで提案されているDSCPフィールドの使用と同様の方法で、ホップごとの異なる転送処理を選択するルーターが存在します。 したがって、これらのルーターを適切に構成することにより、シンプルなプロトタイプの差別化されたサービスアーキテクチャを迅速に展開できます。 さらに、今日のIPシステムはIP Precedenceフィールドの場所を理解しているため、これらのビットがDS準拠の機器の展開と同様の方法で使用される場合、初期の展開中に重大な障害が発生する可能性は低くなります。 つまり、DSCPフィールドのビット0~2が、IP Precedenceフィールドの展開された使用法と同様の方法で、または包含されて使用される場合、単一のサービスプロバイダーのネットワーク内であっても、厳密なDS準拠は遍在する必要はありません。


4.2.1  IP Precedence History and Evolution in Brief

4.2.1 IP優先順位の履歴と進化の概要


   The IP Precedence field is something of a forerunner of the DS field.
   IP Precedence, and the IP Precedence Field, were first defined in
   [RFC791].  The values that the three-bit IP Precedence Field might
   take were assigned to various uses, including network control
   traffic, routing traffic, and various levels of privilege.  The least
   level of privilege was deemed "routine traffic".  In [RFC791], the
   notion of Precedence was defined broadly as "An independent measure
   of the importance of this datagram."  Not all values of the IP
   Precedence field were assumed to have meaning across boundaries, for
   instance "The Network Control precedence designation is intended to
   be used within a network only.  The actual use and control of that
   designation is up to each network." [RFC791]

IP Precedenceフィールドは、DSフィールドの前身のようなものです。 IP PrecedenceとIP Precedenceフィールドは、最初に[RFC791]で定義されました。 3ビットのIP Precedenceフィールドが取る可能性のある値は、ネットワーク制御トラフィック、ルーティングトラフィック、さまざまなレベルの特権など、さまざまな用途に割り当てられました。 最小レベルの特権は「通常のトラフィック」と見なされました。 [RFC791]では、優先順位の概念は「このデータグラムの重要性の独立した測定値」として広く定義されていました。 IP Precedenceフィールドのすべての値が境界を越えて意味を持つとは限りませんでした。たとえば、「ネットワーク制御優先順位の指定は、ネットワーク内でのみ使用されることを意図しています。 その指定の実際の使用と制御は、各ネットワークに依存します。 [RFC791]


   Although early BBN IMPs implemented the Precedence feature, early
   commercial routers and UNIX IP forwarding code generally did not.  As
   networks became more complex and customer requirements grew,
   commercial router vendors developed ways to implement various kinds
   of queueing services including priority queueing, which were



Nichols, et. al.            Standards Track                    [Page 10]

RFC 2474             Differentiated Services Field         December 1998


   generally based on policies encoded in filters in the routers, which
   examined IP addresses, IP protocol numbers, TCP or UDP ports, and
   other header fields.  IP Precedence was and is among the options such
   filters can examine.

初期のBBN IMPは優先機能を実装していましたが、初期の商用ルーターとUNIX IP転送コードは一般に実装していませんでした。 ネットワークがより複雑になり、顧客の要件が高まるにつれ、商用ルーターベンダーは、一般にルーターのフィルターにエンコードされたポリシーに基づいた、優先キューイングを含むさまざまな種類のキューイングサービスを実装する方法を開発し、IPアドレス、IPプロトコル番号、TCPまたは UDPポート、およびその他のヘッダーフィールド。 IP Precedenceは、そのようなフィルターが検査できるオプションの1つでした。


   In short, IP Precedence is widely deployed and widely used, if not in
   exactly the manner intended in [RFC791].  This was recognized in
   [RFC1122], which states that while the use of the IP Precedence field
   is valid, the specific assignment of the priorities in [RFC791] were
   merely historical.

要するに、IP Precedenceは、[RFC791]で意図された方法とまったく同じではないにしても、広く展開され、広く使用されています。 これは[RFC1122]で認識され、IP Precedenceフィールドの使用は有効ですが、[RFC791]での優先順位の特定の割り当ては単に歴史的なものであると述べています。


4.2.2  Subsuming IP Precedence into Class Selector Codepoints

4.2.2 IP優先順位のクラスセレクターコードポイントへの包含


   A specification of the packet forwarding treatments selected by the
   IP Precedence field today would have to be quite general; probably
   not specific enough to build predictable services from in the
   differentiated services framework.  To preserve partial backwards
   compatibility with known current uses of the IP Precedence field
   without sacrificing future flexibility, we have taken the approach of
   describing minimum requirements on a set of PHBs that are compatible
   with most of the deployed forwarding treatments selected by the IP
   Precedence field.  In addition, we give a set of codepoints that MUST
   map to PHBs meeting these minimum requirements.  The PHBs mapped to
   by these codepoints MAY have a more detailed list of specifications
   in addition to the required ones stated here.  Other codepoints MAY
   map to these same PHBs.  We refer to this set of codepoints as the
   Class Selector Codepoints, and the minimum requirements for PHBs that
   these codepoints may map to are called the Class Selector PHB
   Requirements.

今日のIP Precedenceフィールドで選択されたパケット転送処理の仕様は、非常に一般的なものでなければなりません。おそらく、差別化されたサービスフレームワークから予測可能なサービスを構築するのに十分具体的ではありません。 将来の柔軟性を犠牲にすることなく、IP Precedenceフィールドの既知の現在の使用との部分的な下位互換性を維持するために、IP Precedenceフィールドによって選択されたほとんどの展開された転送処理と互換性のあるPHBのセットの最小要件を説明するアプローチを採用しました。 さらに、これらの最小要件を満たすPHBにマップする必要があるコードポイントのセットを提供します。 これらのコードポイントによってマップされたPHBには、ここで述べられている必要なものに加えて、より詳細な仕様のリストが含まれている場合があります。 他のコードポイントはこれらの同じPHBにマップしてもよい(MAY)。 このコードポイントのセットをクラスセレクターコードポイントと呼び、これらのコードポイントがマッピングできるPHBの最小要件をクラスセレクターPHB要件と呼びます。


4.2.2.1  The Class Selector Codepoints

4.2.2.1クラスセレクターのコードポイント


   A specification of the packet forwarding treatments selected by the
   The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU
   subfield unspecified, are reserved as a set of Class Selector
   Codepoints.  PHBs which are mapped to by these codepoints MUST
   satisfy the Class Selector PHB requirements in addition to preserving
   the Default PHB requirement on codepoint '000000' (Sec. 4.1).

DSフィールド値「xxx000 | xx」、またはDSCP = 'xxx000'およびCUサブフィールド未指定で選択されたパケット転送処理の仕様は、クラスセレクターコードポイントのセットとして予約されています。 これらのコードポイントによってマップされるPHBは、コードポイント '000000'(Sec.4.1)のデフォルトPHB要件を維持することに加えて、クラスセレクターPHB要件を満たさなければなりません(MUST)。


4.2.2.2  The Class Selector PHB Requirements

4.2.2.2クラスセレクターのPHB要件


   We refer to a Class Selector Codepoint with a larger numerical value
   than another Class Selector Codepoint as having a higher relative
   order while a Class Selector Codepoint with a smaller numerical value
   than another Class Selector Codepoint is said to have a lower
   relative order.  The set of PHBs mapped to by the eight Class
   Selector Codepoints MUST yield at least two independently forwarded
   classes of traffic, and PHBs selected by a Class Selector Codepoint



Nichols, et. al.            Standards Track                    [Page 11]

RFC 2474             Differentiated Services Field         December 1998


   SHOULD give packets a probability of timely forwarding that is not
   lower than that given to packets marked with a Class Selector
   codepoint of lower relative order, under reasonable operating
   conditions and traffic loads.  A discarded packet is considered to be
   an extreme case of untimely forwarding.  In addition, PHBs selected
   by codepoints '11x000' MUST give packets a preferential forwarding
   treatment by comparison to the PHB selected by codepoint '000000' to
   preserve the common usage of IP Precedence values '110' and '111' for
   routing traffic.

他のクラスセレクターコードポイントよりも数値が大きいクラスセレクターコードポイントを相対的な順序が高いと呼び、他のクラスセレクターコードポイントよりも数値が小さいクラスセレクターコードポイントは相対的な順序が低いといいます。 8つのクラスセレクターコードポイントによってマップされたPHBのセットは、少なくとも2つの独立して転送されるトラフィッククラスを生成する必要があり、クラスセレクターコードポイントによって選択されたPHBは、でマークされたパケットに与えられたものよりも低くないタイムリーな転送の確率をパケットに与える必要があります(SHOULD)。適切な動作条件とトラフィック負荷の下で、相対的に低い次数のクラスセレクタコードポイント。 破棄されたパケットは、早すぎる転送の極端なケースと見なされます。 さらに、コードポイント「11x000」で選択されたPHBは、コードポイント「000000」で選択されたPHBと比較して、パケットに優先的な転送処理を与えて、トラフィックのルーティングに対するIP Precedence値「110」と「111」の一般的な使用を維持する必要があります。


   Further, PHBs selected by distinct Class Selector Codepoints SHOULD
   be independently forwarded; that is, packets marked with different
   Class Selector Codepoints MAY be re-ordered.  A network node MAY
   enforce limits on the amount of the node's resources that can be
   utilized by each of these PHBs.

さらに、別個のクラスセレクタコードポイントによって選択されたPHBは、独立して転送する必要があります。 つまり、異なるクラスセレクタコードポイントでマークされたパケットは、並べ替えられる場合があります。 ネットワークノードは、これらの各PHBで利用できるノードのリソースの量に制限を適用できます(MAY)。


   PHB groups whose specification satisfy these requirements are
   referred to as Class Selector Compliant PHBs.

これらの要件を満たす仕様を持つPHBグループは、クラスセレクター準拠のPHBと呼ばれます。


   The Class Selector PHB Requirements on codepoint '000000' are
   compatible with those listed for the Default PHB in Sec. 4.1.

コードポイント '000000'のクラスセレクターPHB要件は、Sec.4.1のデフォルトPHBにリストされているものと互換性があります。


4.2.2.3  Using the Class Selector PHB Requirements for IP Precedence
         Compatibility

4.2.2.3 IP優先順位の互換性のためのクラスセレクターPHB要件の使用


   A DS-compliant network node can be deployed with a set of one or more
   Class Selector Compliant PHB groups.  This document states that the
   set of codepoints 'xxx000' MUST map to such a set of PHBs.  As it is
   also possible to map multiple codepoints to the same PHB, the vendor
   or the network administrator MAY configure the network node to map
   codepoints to PHBs irrespective of bits 3-5 of the DSCP field to
   yield a network that is compatible with historical IP Precedence use.
   Thus, for example, codepoint '011010' would map to the same PHB as
   codepoint '011000'.

DS準拠のネットワークノードは、1つ以上のクラスセレクター準拠のPHBグループのセットで展開できます。 このドキュメントでは、コードポイントのセット「xxx000」は、そのようなPHBのセットにマップする必要があると述べています。 同じPHBに複数のコードポイントをマップすることも可能であるため、ベンダーまたはネットワーク管理者は、DSCPフィールドのビット3~5に関係なくコードポイントをPHBにマップして、履歴IPと互換性のあるネットワークを生成するようにネットワークノードを構成できます(MAY)。 優先使用。 したがって、たとえば、コードポイント '011010'は、コードポイント '011000'と同じPHBにマップされます。


4.2.2.4  Example Mechanisms for Implementing Class Selector Compliant
         PHB Groups

4.2.2.4クラスセレクターに準拠したPHBグループを実装するためのメカニズムの例


   Class Selector Compliant PHBs can be realized by a variety of
   mechanisms, including strict priority queueing, weighted fair
   queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based
   Queuing [CBQ].  The distinction between PHBs and mechanisms is
   described in more detail in Sec. 5.

クラスセレクターに準拠したPHBは、完全優先キューイング、加重均等化キューイング(WFQ)、WRR、バリアント[RPS、HPFQA、DRR]、クラスベースキューイング[CBQ]など、さまざまなメカニズムで実現できます。 PHBとメカニズムの違いについては、Sec.5で詳しく説明します。


   It is important to note that these mechanisms might be available
   through other PHBs (standardized or not) that are available in a
   particular vendor's equipment.  For example, future documents may
   standardize a Strict Priority Queueing PHB group for a set of



Nichols, et. al.            Standards Track                    [Page 12]

RFC 2474             Differentiated Services Field         December 1998


   recommended codepoints.  A network administrator might configure
   those routers to select the Strict Priority Queueing PHBs with
   codepoints 'xxx000' in conformance with the requirements of this
   document.

これらのメカニズムは、特定のベンダーの機器で利用可能な他のPHB(標準化されているかどうかにかかわらず)を通じて利用できる場合があることに注意することが重要です。 たとえば、将来のドキュメントでは、一連の推奨コードポイントのStrict Priority Queuing PHBグループを標準化する可能性があります。 ネットワーク管理者は、このドキュメントの要件に準拠して、コードポイント「xxx000」の厳密優先キューPHBを選択するようにこれらのルーターを構成する場合があります。


   As a further example, another vendor might employ a CBQ mechanism in
   its routers.  The CBQ mechanism could be used to implement the Strict
   Priority Queueing PHBs as well as a set of Class Selector Compliant
   PHBs with a wider range of features than would be available in a set
   of PHBs that did no more than meet the minimum Class Selector PHB
   requirements.

さらなる例として、別のベンダーがルーターにCBQメカニズムを採用している場合があります。 CBQメカニズムを使用して、完全優先キューイングPHBと、クラスセレクターの最小PHB要件を超えない一連のPHBで利用可能な機能よりも幅広い機能を備えたクラスセレクター準拠のPHBのセットを実装できます。 。


4.3  Summary

4.3まとめ


   This document defines codepoints 'xxx000' as the Class Selector
   codepoints, where PHBs selected by these codepoints MUST meet the
   Class Selector PHB Requirements described in Sec. 4.2.2.2.  This is
   done to preserve a useful level of backward compatibility with
   current uses of the IP Precedence field in the Internet without
   unduly limiting future flexibility.  In addition, codepoint '000000'
   is used as the Default PHB value for the Internet and, as such, is
   not configurable.  The remaining seven non-zero Class Selector
   codepoints are configurable only to the extent that they map to PHBs
   that meet the requirements in Sec. 4.2.2.2.

このドキュメントでは、コードポイント「xxx000」をクラスセレクタのコードポイントとして定義しています。これらのコードポイントによって選択されたPHBは、「セクション」で説明されているクラスセレクタのPHB要件を満たしている必要があります。 4.2.2.2。 これは、将来の柔軟性を過度に制限することなく、インターネットにおけるIP Precedenceフィールドの現在の使用との下位互換性の有用なレベルを維持するために行われます。 さらに、コードポイント「000000」はインターネットのデフォルトのPHB値として使用されるため、構成できません。 残りの7つの非ゼロクラスセレクターコードポイントは、Sec。の要件を満たすPHBにマップする範囲でのみ構成可能です。 4.2.2.2。


5.  Per-Hop Behavior Standardization Guidelines

5.ホップごとの動作の標準化ガイドライン


   The behavioral characteristics of a PHB are to be standardized, and
   not the particular algorithms or the mechanisms used to implement
   them.  A node may have a (possibly large) set of parameters that can
   be used to control how packets are scheduled onto an output interface
   (e.g., N separate queues with settable priorities, queue lengths,
   round-robin weights, drop algorithm, drop preference weights and
   thresholds, etc).  To illustrate the distinction between a PHB and a
   mechanism, we point out that Class Selector Compliant PHBs might be
   implemented by several mechanisms, including: strict priority
   queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in
   isolation or in combination.

PHBの動作特性は標準化されるものであり、特定のアルゴリズムやそれらを実装するために使用されるメカニズムではありません。 ノードには、パケットが出力インターフェイス上でどのようにスケジュールされるかを制御するために使用できる(おそらく大きな)パラメータセットがある場合があります(たとえば、設定可能な優先度を持つN個の個別のキュー、キューの長さ、ラウンドロビンの重み、ドロップアルゴリズム、ドロップ設定の重み およびしきい値など)。 PHBとメカニズムの違いを説明するために、クラスセレクターに準拠したPHBは、完全優先キューイング、WFQ、WRR、またはバリアント[HPFQA、RPS、DRR]、またはCBQ [CBQ ]、単独で、または組み合わせて。


   PHBs may be specified individually, or as a group (a single PHB is a
   special case of a PHB group).  A PHB group usually consists of a set
   of two or more PHBs that can only be meaningfully specified and
   implemented simultaneously, due to a common constraint applying to
   each PHB within the group, such as a queue servicing or queue
   management policy.  A PHB group specification SHOULD describe
   conditions under which a packet might be re-marked to select another
   PHB within the group.  It is RECOMMENDED that PHB implementations do
   not introduce any packet re-ordering within a microflow.  PHB group



Nichols, et. al.            Standards Track                    [Page 13]

RFC 2474             Differentiated Services Field         December 1998


   specifications MUST identify any possible packet re-ordering
   implications which may occur for each individual PHB, and which may
   occur if different packets within a microflow are marked for
   different PHBs within the group.

PHBは個別に、またはグループとして指定できます(単一のPHBは、PHBグループの特殊なケースです)。 キューサービスやキュー管理ポリシーなど、グループ内の各PHBに共通の制約が適用されるため、PHBグループは通常、意味のある指定と実装のみが同時に可能な2つ以上のPHBのセットで構成されます。 PHBグループ仕様は、グループ内の別のPHBを選択するためにパケットが再マーキングされる可能性がある条件を記述する必要があります(SHOULD)。 PHB実装では、マイクロフロー内でパケットの並べ替えを導入しないことをお勧めします。 PHBグループ仕様は、個々のPHBごとに発生する可能性のある、また、マイクロフロー内の異なるパケットがグループ内の異なるPHBにマークされている場合に発生する可能性がある、パケットの順序変更の可能性を特定する必要があります。


   Only those per-hop behaviors that are not described by an existing
   PHB standard, and have been implemented, deployed, and shown to be
   useful, SHOULD be standardized.  Since current experience with
   differentiated services is quite limited, it is premature to
   hypothesize the exact specification of these per-hop behaviors.

既存のPHB標準で説明されておらず、実装、展開、および有用であることが示されているホップごとの動作のみが標準化されている必要があります。 差別化サービスの現在の経験はかなり限られているため、これらのホップごとの動作の正確な仕様を仮定するのは時期尚早です。


   Each standardized PHB MUST have an associated RECOMMENDED codepoint,
   allocated out of a space of 32 codepoints (see Sec. 6).  This
   specification has left room in the codepoint space to allow for
   evolution, thus the defined space ('xxx000') is intentionally sparse.

標準化された各PHBには、32個のコードポイントのスペースから割り当てられた、関連するRECOMMENDEDコードポイントが必要です(セクションを参照)。 6)。 この仕様は、進化を可能にするためにコードポイント空間に余裕を残しているため、定義された空間( 'xxx000')は意図的に疎です。


   Network equipment vendors are free to offer whatever parameters and
   capabilities are deemed useful or marketable.  When a particular,
   standardized PHB is implemented in a node, a vendor MAY use any
   algorithm that satisfies the definition of the PHB according to the
   standard.  The node's capabilities and its particular configuration
   determine the different ways that packets can be treated.

ネットワーク機器ベンダーは、有用または市場性があると思われるパラメーターおよび機能を自由に提供できます。 特定の標準化されたPHBがノードに実装されている場合、ベンダーは、標準に従ってPHBの定義を満たす任意のアルゴリズムを使用できます(MAY)。 ノードの機能とその特定の構成により、パケットを処理するさまざまな方法が決まります。


   Service providers are not required to use the same node mechanisms or
   configurations to enable service differentiation within their
   networks, and are free to configure the node parameters in whatever
   way that is appropriate for their service offerings and traffic
   engineering objectives.  Over time certain common per-hop behaviors
   are likely to evolve (i.e., ones that are particularly useful for
   implementing end-to-end services) and these MAY be associated with
   particular EXP/LU PHB codepoints in the DS field, allowing use across
   domain boundaries (see Sec. 6).  These PHBs are candidates for future
   standardization.

サービスプロバイダーは、ネットワーク内でサービスを差別化するために同じノードメカニズムまたは構成を使用する必要はありません。サービスプロバイダーおよびトラフィックエンジニアリングの目的に適した方法でノードパラメーターを自由に構成できます。 時間の経過とともに、特定の一般的なホップごとの動作(つまり、エンドツーエンドサービスの実装に特に役立つ動作)が進化する可能性があり、これらはDSフィールドの特定のEXP / LU PHBコードポイントに関連付けられ、ドメイン全体で使用できるようになります(MAY) 境界(セクション6を参照)。 これらのPHBは、将来の標準化の候補です。


   It is RECOMMENDED that standardized PHBs be specified in accordance
   with the guidelines set out in [ARCH].

[ARCH]に記載されているガイドラインに従って、標準化されたPHBを指定することをお勧めします。


6.  IANA Considerations

6. IANAに関する考慮事項


   The DSCP field within the DS field is capable of conveying 64
   distinct codepoints.  The codepoint space is divided into three pools
   for the purpose of codepoint assignment and management: a pool of 32
   RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as
   defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved
   for experimental or Local Use (EXP/LU) as defined in [CONS], and a
   pool of 16 codepoints (Pool 3) which are initially available for
   experimental or local use, but which should be preferentially




Nichols, et. al.            Standards Track                    [Page 14]

RFC 2474             Differentiated Services Field         December 1998


   utilized for standardized assignments if Pool 1 is ever exhausted.
   The pools are defined in the following table (where 'x' refers to
   either '0' or '1'):

DSフィールド内のDSCPフィールドは、64の異なるコードポイントを伝達できます。 コードポイントスペースは、コードポイントの割り当てと管理のために3つのプールに分割されます。[CONS]で定義されているように、標準アクションによって割り当てられる32の推奨コードポイント(プール1)のプール、16のコードポイント(プール2)のプール [CONS]で定義されている実験的または局所的使用(EXP / LU)、および最初は実験的または局所的使用に使用可能であるが、プールの場合は標準化された割り当てに優先的に使用される16のコードポイント(プール3)のプールのために予約される 1は使い果たされます。 プールは次の表で定義されています(「x」は「0」または「1」のいずれかを指します)。


   Pool        Codepoint space          Assignment Policy
   ----        ---------------          -----------------

    1            xxxxx0                 Standards Action
    2            xxxx11                 EXP/LU
    3            xxxx01                 EXP/LU (*)

   (*) may be utilized for future Standards Action allocations as
       necessary

(*)必要に応じて、将来の標準アクションの割り当てに使用できます


   This document assigns eight RECOMMENDED codepoints ('xxx000') which
   are drawn from Pool 1 above.  These codepoints MUST be mapped, not to
   specific PHBs, but to PHBs that meet "at least" the requirements set
   forth in Sec. 4.2.2.2 to provide a minimal level of backwards
   compatibility with IP Precedence as defined in [RFC791] and as
   deployed in some current equipment.

このドキュメントは、上記のプール1から取得された8つの推奨コードポイント( 'xxx000')を割り当てます。 これらのコードポイントは、特定のPHBではなく、「少なくとも」セクションに記載されている要件を満たすPHBにマップする必要があります。 4.2.2.2 [RFC791]で定義され、一部の現在の機器に導入されているIP Precedenceとの最小レベルの下位互換性を提供する。


7.  Security Considerations

7.セキュリティに関する考慮事項


   This section considers security issues raised by the introduction of
   differentiated services, primarily the potential for denial-of-
   service attacks, and the related potential for theft of service by
   unauthorized traffic (Section 7.1).  Section 7.2 addresses the
   operation of differentiated services in the presence of IPsec
   including its interaction with IPsec tunnel mode and other tunnelling
   protocols.  See [ARCH] for more extensive treatment of the security
   concerns raised by the overall differentiated services architecture.

このセクションでは、差別化されたサービスの導入によって引き起こされるセキュリティの問題、主にサービス拒否攻撃の可能性、および不正なトラフィックによるサービスの盗用の可能性について考察します(セクション7.1)。 セクション7.2では、IPsecトンネルモードや他のトンネリングプロトコルとの相互作用を含め、IPsecが存在する場合の差別化サービスの操作について説明します。 差別化されたサービスアーキテクチャ全体によって引き起こされるセキュリティの懸念のより広範な扱いについては、[ARCH]を参照してください。


7.1  Theft and Denial of Service

7.1盗難およびサービス拒否


   The primary goal of differentiated services is to allow different
   levels of service to be provided for traffic streams on a common
   network infrastructure.  A variety of techniques may be used to
   achieve this, but the end result will be that some packets receive
   different (e.g., better) service than others.  The mapping of network
   traffic to the specific behaviors that result in different (e.g.,
   better or worse) service is indicated primarily by the DS codepoint,
   and hence an adversary may be able to obtain better service by
   modifying the codepoint to values indicating behaviors used for
   enhanced services or by injecting packets with such codepoint values.
   Taken to its limits, such theft-of-service becomes a denial-of-
   service attack when the modified or injected traffic depletes the
   resources available to forward it and other traffic streams.

差別化サービスの主な目的は、共通のネットワークインフラストラクチャ上のトラフィックストリームにさまざまなレベルのサービスを提供できるようにすることです。 これを達成するためにさまざまな手法を使用できますが、最終的には、一部のパケットが他のパケットとは異なる(たとえば、より良い)サービスを受け取ることになります。 異なる(たとえば、より良いまたはより悪い)サービスをもたらす特定の動作へのネットワークトラフィックのマッピングは、主にDSコードポイントによって示されます。したがって、攻撃者は、コードポイントを使用する動作を示す値に変更することにより、より良いサービスを取得できる可能性があります。 拡張サービス、またはそのようなコードポイント値を持つパケットを挿入することによって。 限界に達すると、このようなサービスの盗難は、変更または挿入されたトラフィックが、そのトラフィックや他のトラフィックストリームを転送するために利用可能なリソースを使い果たすと、サービス拒否攻撃になります。





Nichols, et. al.            Standards Track                    [Page 15]

RFC 2474             Differentiated Services Field         December 1998


   The defense against this class of theft- and denial-of-service
   attacks consists of the combination of traffic conditioning at DS
   domain boundaries with security and integrity of the network
   infrastructure within a DS domain.  DS domain boundary nodes MUST
   ensure that all traffic entering the domain is marked with codepoint
   values appropriate to the traffic and the domain, remarking the
   traffic with new codepoint values if necessary.  These DS boundary
   nodes are the primary line of defense against theft- and denial-of-
   service attacks based on modified codepoints, as success of any such
   attack indicates that the codepoints used by the attacking traffic
   were inappropriate.  An important instance of a boundary node is that
   any traffic-originating node within a DS domain is the initial
   boundary node for that traffic.  Interior nodes in a DS domain rely
   on DS codepoints to associate traffic with the forwarding PHBs, and
   are NOT REQUIRED to check codepoint values before using them.  As a
   result, the interior nodes depend on the correct operation of the DS
   domain boundary nodes to prevent the arrival of traffic with
   inappropriate codepoints or in excess of provisioned levels that
   would disrupt operation of the domain.

このクラスの盗難およびサービス拒否攻撃に対する防御は、DSドメイン境界でのトラフィック調整と、DSドメイン内のネットワークインフラストラクチャのセキュリティおよび整合性の組み合わせで構成されます。 DSドメイン境界ノードは、ドメインに入るすべてのトラフィックが、トラフィックとドメインに適切なコードポイント値でマークされていることを確認し、必要に応じて新しいコードポイント値でトラフィックを再マークする必要があります。 これらのDS境界ノードは、変更されたコードポイントに基づく盗難およびサービス拒否攻撃に対する主要な防御線です。そのような攻撃が成功すると、攻撃トラフィックが使用するコードポイントが不適切であったことが示されます。 境界ノードの重要なインスタンスは、DSドメイン内のトラフィック発信ノードがそのトラフィックの最初の境界ノードであることです。 DSドメインの内部ノードは、DSコードポイントに依存してトラフィックを転送PHBに関連付け、使用する前にコードポイント値を確認する必要はありません。 その結果、内部ノードはDSドメイン境界ノードの正しい動作に依存して、ドメインの動作を妨害する不適切なコードポイントまたはプロビジョニングされたレベルを超えるトラフィックの到着を防ぎます。


7.2  IPsec and Tunnelling Interactions

7.2 IPsecとトンネリングの相互作用


   The IPsec protocol, as defined in [ESP, AH], does not include the IP
   header's DS field in any of its cryptographic calculations (in the
   case of tunnel mode, it is the outer IP header's DS field that is not
   included).  Hence modification of the DS field by a network node has
   no effect on IPsec's end-to-end security, because it cannot cause any
   IPsec integrity check to fail.  As a consequence, IPsec does not
   provide any defense against an adversary's modification of the DS
   field (i.e., a man-in-the-middle attack), as the adversary's
   modification will also have no effect on IPsec's end-to-end security.

[ESP、AH]で定義されているIPsecプロトコルは、暗号化計算のいずれにもIPヘッダーのDSフィールドを含みません(トンネルモードの場合、含まれていないのは外部IPヘッダーのDSフィールドです)。 したがって、ネットワークノードによるDSフィールドの変更は、IPsecの整合性チェックが失敗することはないため、IPsecのエンドツーエンドのセキュリティには影響しません。 結果として、IPsecは、敵対者の変更がIPsecのエンドツーエンドのセキュリティに影響を与えないため、敵対者のDSフィールドの変更(つまり、中間者攻撃)に対する防御を提供しません。


   IPsec's tunnel mode provides security for the encapsulated IP
   header's DS field.  A tunnel mode IPsec packet contains two IP
   headers: an outer header supplied by the tunnel ingress node and an
   encapsulated inner header supplied by the original source of the
   packet.  When an IPsec tunnel is hosted (in whole or in part) on a
   differentiated services network, the intermediate network nodes
   operate on the DS field in the outer header.  At the tunnel egress
   node, IPsec processing includes removing the outer header and
   forwarding the packet (if required) using the inner header.  The
   IPsec protocol REQUIRES that the inner header's DS field not be
   changed by this decapsulation processing to ensure that modifications
   to the DS field cannot be used to launch theft- or denial-of-service
   attacks across an IPsec tunnel endpoint.  This document makes no
   change to that requirement.  If the inner IP header has not been
   processed by a DS boundary node for the tunnel egress node's DS




Nichols, et. al.            Standards Track                    [Page 16]

RFC 2474             Differentiated Services Field         December 1998


   domain, the tunnel egress node is the boundary node for traffic
   exiting the tunnel, and hence MUST ensure that the resulting traffic
   has appropriate DS codepoints.

IPsecのトンネルモードは、カプセル化されたIPヘッダーのDSフィールドにセキュリティを提供します。 トンネルモードのIPsecパケットには2つのIPヘッダーが含まれています。トンネル入力ノードによって提供される外部ヘッダーと、パケットの元のソースによって提供されるカプセル化された内部ヘッダーです。 IPsecトンネルが(全体または一部)差別化サービスネットワークでホストされている場合、中間ネットワークノードは外部ヘッダーのDSフィールドで動作します。 トンネル出口ノードでのIPsec処理には、外部ヘッダーの削除と、内部ヘッダーを使用したパケット(必要な場合)の転送が含まれます。 IPsecプロトコルでは、このカプセル化解除処理によって内部ヘッダーのDSフィールドが変更されないようにして、DSフィールドへの変更を使用して、IPsecトンネルエンドポイント全体での盗難またはサービス拒否攻撃を開始できないようにする必要があります。 このドキュメントでは、その要件は変更されません。 内部IPヘッダーがトンネル出口ノードのDSドメインのDS境界ノードによって処理されていない場合、トンネル出口ノードはトンネルを出るトラフィックの境界ノードであり、したがって、結果のトラフィックに適切なDSコードポイントがあることを確認する必要があります。


   When IPsec tunnel egress decapsulation processing includes a
   sufficiently strong cryptographic integrity check of the encapsulated
   packet (where sufficiency is determined by local security policy),
   the tunnel egress node can safely assume that the DS field in the
   inner header has the same value as it had at the tunnel ingress node.
   An important consequence is that otherwise insecure links within a DS
   domain can be secured by a sufficiently strong IPsec tunnel.  This
   analysis and its implications apply to any tunnelling protocol that
   performs integrity checks, but the level of assurance of the inner
   header's DS field depends on the strength of the integrity check
   performed by the tunnelling protocol.  In the absence of sufficient
   assurance for a tunnel that may transit nodes outside the current DS
   domain (or is otherwise vulnerable), the encapsulated packet MUST be
   treated as if it had arrived at a boundary from outside the DS
   domain.

IPsecトンネル出力カプセル化解除処理に、カプセル化されたパケットの十分な強度の暗号整合性チェックが含まれている場合(十分性はローカルセキュリティポリシーによって決定されます)、トンネル出力ノードは、内部ヘッダーのDSフィールドがそれと同じ値であると安全に想定できます トンネル入口ノードで。 重要な結果は、DSドメイン内の安全でないリンクは、十分に強力なIPsecトンネルによって保護できることです。 この分析とその影響は、整合性チェックを実行するすべてのトンネリングプロトコルに適用されますが、内部ヘッダーのDSフィールドの保証レベルは、トンネリングプロトコルによって実行される整合性チェックの強度に依存します。 現在のDSドメイン外のノードを通過する可能性がある(またはその他の点で脆弱である)トンネルが十分に保証されていない場合、カプセル化されたパケットは、DSドメイン外から境界に到達したかのように扱わなければなりません(MUST)。


8.  Acknowledgements

8.謝辞


   The authors would like to acknowledge the Differentiated Services
   Working Group for discussions which helped shape this document.

著者は、この文書を形作る助けとなった議論について、Differentiated Services Working Groupを認めたいと思います。


9.  References

9.リファレンス


   [AH]        Kent, S. and R. Atkinson, "IP Authentication Header",
               RFC 2402, November 1998.

   [ARCH]      Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
               and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

   [CBQ]       S. Floyd and V. Jacobson, "Link-sharing and Resource
               Management Models for Packet Networks", IEEE/ACM
               Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
               August 1995.

   [CONS]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", RFC 2434, October
               1998.

   [DRR]       M. Shreedhar and G. Varghese, Efficient Fair Queueing
               using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.






Nichols, et. al.            Standards Track                    [Page 17]

RFC 2474             Differentiated Services Field         December 1998


   [ESP]       Kent, S. and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998.

   [HPFQA]     J. Bennett and Hui Zhang, "Hierarchical Packet Fair
               Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.

   [IPv6]      Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

   [RFC791]    Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC1122]   Braden, R., "Requirements for Internet hosts -
               communication layers", STD 3, RFC 1122, October 1989.

   [RFC1812]   Baker, F., Editor, "Requirements for IP Version 4
               Routers", RFC 1812, June 1995.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RPS]       D. Stiliadis and A. Varma, "Rate-Proportional Servers:  A
               Design Methodology for Fair Queueing Algorithms", IEEE/
               ACM Trans. on Networking, April 1998.



























Nichols, et. al.            Standards Track                    [Page 18]

RFC 2474             Differentiated Services Field         December 1998


Authors' Addresses

   Kathleen Nichols
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134-1706

   Phone:  +1-408-525-4857
   EMail: kmn@cisco.com


   Steven Blake
   Torrent Networking Technologies
   3000 Aerial Center, Suite 140
   Morrisville, NC  27560

   Phone:  +1-919-468-8466 x232
   EMail: slblake@torrentnet.com


   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, CA  93111

   Phone:  +1-408-526-4257
   EMail: fred@cisco.com


   David L. Black
   EMC Corporation
   35 Parkwood Drive
   Hopkinton, MA  01748

   Phone:  +1-508-435-1000 x76140
   EMail: black_david@emc.com















Nichols, et. al.            Standards Track                    [Page 19]

RFC 2474             Differentiated Services Field         December 1998


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or 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.
























Nichols, et. al.            Standards Track                    [Page 20]