この文書はRFC2474の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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ヘッダーでの
          サービス区分フィールド(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.

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),
   - ネットワーク境界線(自律システム境界線や、内部管理境界線や、ホスト)
     でビットをIPヘッダーフィールドにセットします、。
   - 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.
   - それぞれのサービス条件あるいは規則どおりにネットワーク境界線でマー
     クしたパケットを調整します。

   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オクテットに配置し、IPv
   6ではトラフィッククラスオクテットに配置します。加えて、パケット転送
   の扱いやホップ毎の動作の基本セットが定義されます。

   For a more complete understanding of differentiated services, see
   also the differentiated services architecture [ARCH].
   区分サービスのより完全な理解のために、区分サービスアーキテクチャ
   [ARCH]を見てください。

Table of Contents
目次

   1.  Introduction
   1.  はじめに
   2.  Terminology Used in This Document
   2.  この文書で使われる専門用語
   3.  Differentiated Services Field Definition
   3.  区分サービスフィールド定義
   4.  Historical Codepoint Definitions and PHB Requirements
   4.  歴史的コードポイント定義とPHB必要条件
      4.1  A Default PHB
      4.1  デフォルトPHB
      4.2  Once and Future IP Precedence Field Use
      4.2  過去と未来ののIP優先フィールドの使い方
         4.2.1  IP Precedence History and Evolution in Brief
         4.2.1  IPの優先の歴史と進展の手短な説明
         4.2.2  Subsuming IP Precedence into Class Selector
                Codepoints
         4.2.2  クラス選択コードポイントにIP優先を包括
            4.2.2.1  The Class Selector Codepoints
            4.2.2.1  クラス選択コードポイント
            4.2.2.2  The Class Selector PHB Requirements
            4.2.2.2  クラス選択PHB条件
            4.2.2.3  Using the Class Selector PHB Requirements
                     for IP Precedence Compatibility
            4.2.2.3  IP優先互換性のためのクラス選択PHB条件
            4.2.2.4  Example Mechanisms for Implementing Class
                     Selector Compliant PHB Groups
            4.2.2.4  クラス選択適合PHBグループを実装するため
                     のメカニズム例
      4.3  Summary
      4.3  まとめ
   5.  Per-Hop Behavior Standardization Guidelines
   5.  ホップ毎の動作の標準化ガイドライン
   6.  IANA Considerations
   6.  IANAの考慮
   7.  Security Considerations
   7.  セキュリティの考察
      7.1  Theft and Denial of Service
      7.1  盗みとサービス否定
      7.2  IPsec and Tunnelling Interactions
      7.2  IPsecとトンネルの相互作用
   8.  Acknowledgements
   8.  謝辞
   9.  References
   9.  参考文献
   Authors' Addresses
   著者のアドレス
   Full Copyright Statement
   著作権表示全文


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つの主要なコンポーネン
   トに分けられ、1つはかなりよく理解されて、他がちょうど理解され始めて
   いる。これは、転送とルーティングのコンポーネントを切り離すインターネッ
   トのオリジナルのデザインに従います。パケット転送は可能な限り速くパケッ
   トごとに行う必要がある比較的単純な仕事です。転送はパケットの出力イン
   タフェースを決定するルーティングテーブルで項目を見つけるためにパケッ
   トヘッダーを使います。ルーティングが項目をそのテーブルに設定して、中
   継とそのほかのポリシーを反映して経路障害を記録・追跡する必要がありま
   す。ルーティングテーブルが転送タスクのバックグラウンドプロセスとして
   保守されます。さらに、ルーティングはより複雑な仕事で、過去の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つは転送パスでかなりよく理解された行動で、他は転送パスで使
   われたパラメータを設定するいっそう複雑でまだ出現しているバックグラウ
   ンドポリシーと配分コンポーネントです。転送パス行動は、個々の受信パケッ
   トのキューサービスとキュー管理での異なる扱いを含みます。これらのホッ
   プ毎の動作は、そして、我々が端と端をつないでいるか、あるいはドメイン
   内のサービスを組み立てる方法はどんな方法であっても、配達するべきネッ
   トワークノードでパケットの区別される扱いを必要としました。我々のフォー
   カスは、これらの行動がメカニズムより低度に急速に進展するであろう時か
   ら、それらを実行するために使われた特定のメカニズムよりどちらかと言う
   と、行動の一般的な意味論の上にあります。

   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.
   ホップ毎の動作とパケット毎にそれを選択するメカニズムは今日ネットワー
   クノードに配置され、これは区分サービス機構の概要で、最初に扱われたも
   のです。加えて、転送パスは、ネットワークトラヒックに対して、特別な待
   遇の配達と結び付けられた必要条件を実施するために「特別な」待遇のため
   に、モニターし、ポリシーを適用し、シェーピングを必要とするかもしれま
   せん。この種類のトラフィックを左右するためのメカニズムはなりよく理解
   されます。このようなトラフィック調整の広い展開は、それらの、サービス
   を組み立てることにおいての実際の用途が長い時間にわたって進展するかも
   しれないけれども、同じくサービスの建設を可能にするために、重要です。

   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.
   この文書は転送パスコンポーネントに集中します。パケット転送パスで、区
   分サービスが、パス上の各ネットワークノードで特定の転送の扱いをするか
   ホップ毎の振る舞い(PHB)をするための、コードポイントをIPパケッ
   トのフィールドにマッピングすることで実現できます。コードポイントはこ
   の文書の後に定義する必須の値の集合から、または将来の文書で推薦された
   値からか、ローカルな意味から選ばれるかもしれません。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
   Compliant PHBs.  Sec. 5 presents guidelines for per-hop behavior
   standardization.  Sec. 6 discusses guidelines for allocation of
   codepoints.  Sec. 7 covers security considerations.
   この文書で使う専門用語が2章で定義されます。区分サービスフィールド定
   義(DSフィールド)は3章で与えられます。4章で、IPv4優先フィー
   ルドの現在の使用との部分的なバックワードコンパチビリティの希望を論じ
   ます。解決策として、我々はクラス選択コードポイントとクラス選択迎合P
   HBを紹介します。5章がホップ毎の行動標準化のガイドラインを示します。
   6章がコードポイントの割り当てのガイドラインを論じます。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.
   動作対象:リンクを同じ方向に移動する同じコードポイントのパケットの集
   合。用語「対象」と「動作対象」がこの文書で交換可能に使われます。

   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'の範囲の8つのコードポイントのどれ
   か('x'は'0'か'1')。クラス選択コードポイントが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 :ホップ毎のクラス選択PHB必要条件を満たしてい
   る行動は4.2.2.2章で指定します。

   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に投影してもよいです(MAY)。

   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追従と
   同じです。

   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.
   区分サービスフィールド:この文書で与えられた定義に従っている解釈され
   る時のIPv4ヘッダーや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).
   マイクロフロー:ソースアドレスと宛先アドレスとプロトコル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):区分サービスに従っているノードが、動作対象
   に適用する、対外的に守る転送処理の記述です。PHBの記述は[ARCH]で文
   書化されるように、予測可能なサービスの構築を許すために十分に詳述され
   るべきです(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の集合で、
   キューサービスやキュー管理の様な共通の制約が適用されます。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).
   トラフィック調整者:トラフィック調整機能を行うエンティティ、これは計
   測、ポリシー適用、シェーピング、マーク付けを含むかもしれません(MAY)。
   トラフィック調整者が典型的に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
   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を経験する動作対象を作
   るためにトラフィック条件を適用することで作られます。多数のサービスが、
   1つのホップ毎の動作を行動を広範囲のトラフィック調整者が協調させて実
   行できます。

   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ドメインで区別した処理を
   受け、トラフィック調整者がある条件に従うために対象の一時的な特徴を変
   えてもよいです(MAY)。パケットのDSフィールドはパケットの動作対象を指
   定するために使われ、パケットがどの転送扱いを受けか決定するためにその
   後使われます。DSフィールドのコードポイントに基づいて、例えば区分出
   力キューサービスといったPHBを選択する、動作対象分類者がDSドメイ
   ンの全てのネットワークノードに含められるべきです(SHOULD)。DS境界線
   での分類者とトラフィック調整者はあるサービス仕様書に従って設定され、
   管理ポリシーの問題はこの文書の範囲外です。

   Additional differentiated services definitions are given in [ARCH].
   追加の区分サービス定義が[ARCH]で与えられます。

3.  Differentiated Services Field Definition
3.  区分サービスフィールド定義

   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.
   6ビットのDSフィールドはパケットが各ノードにおいて経験する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
        DSCP:区分サービスコードポイント。
        CU:   currently unused
        CU:  現在使われていません。

   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を選ばなくてはなりません(MUST)、例えば、フィールドの値をその装
   置に実装されたパケット処理メカニズムを選ぶために使うテーブルインデッ
   クスとして扱います。CUフィールドの値はPHB選択時に無視されなくて
   はなりません(MUST)。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へのマッピングは構成可
   能に違いありません(MUST)。DSに従うノードがコードポイントからPHB
   まで構成可能なマッピングテーブルの論理的同等物をサポートしなくてはな
   りません(MUST)。PHB仕様が推薦されたデフォルトコードポイントを含ま
   なくてはならず(MUST)、これは標準的な空間でユニークなコードポイントで
   す(MUST)(6章参照)。実装がデフォルト設定で推薦されたコードポイント
   から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章参照)
   のマークが付いたかのように転送されるべきで(SHOULD)、コードポイントは
   変更すべきではありません。このようなパケットはネットワークノードを誤
   作動させてはなりません(MUST NOT)。

   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オクテットの既存
   の定義と不適合です。DSドメインが境界線ノードで再マーク付けを実装す
   ることで自身を守ると仮定し、RFC791優先指定を使うネットワークもそうす
   るべきです。正しい使用可能な手続きが[RFC791]に従うべきで(SHOULD)、こ
   れは次の通り述べています:「これらの優先指定の実際の使用が個々のネッ
   トワークの問題で、もし使用するなら、優先指定のアクセスをコントロール
   するのは各ネットワークの責任です」。DS境界でDSフィールド値を有効
   にすることは、上流ノードが容易に任意の値を設定できるので、どんな場合
   ででも思慮があります。適切に設定された境界線ノードによって区切られて
   いないDSドメインでは予想できないサービスを配達するかもしれません。

   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フィールドを再設定する必要があるかもしれません(MAY)。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優先キュー
   イング条件を満たすもの)、そして我々はDSに従うノードでそれらの継続
   的な使用を認めることを望みます。加えて、IP優先フィールドの歴史的の
   使用に対応するあるコードポイントがあります、そして、特定の区分サービ
   スが追加の仕様書を持つかもしれない(MAY)が、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].
   「DTR」や、[RFC791]で定義されるIPv4のTOSオクテットの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
   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に従うノードで利用可能です(MUST)。これは
   [RFC1812]で標準化された既存のルーターで利用可能な共通のベストエフォの
   転送動作です。他のどのような規則もない時、パケットがこの対象に属する
   と想定されます。このようなパケットは特定の規則なしにネットワーク内に
   送られるかもしれず、ネットワークはできるだけ早く可能な限りこれらのパ
   ケットを多くを配達し、他のリソースポリシーを受けさせるでしょう。この
   PHBの合理的な実装は、出力リンクが他のPHBを満足させるように要求
   されない時はいつでも、このパケットを送るキー処理であるでしょう。サー
   ビスを組み立てるための合理的なポリシーがパケットが「欠乏」しないこと
   を保証するでしょう。これはデフォルト動作対象のためにある最小のリソー
   ス(つまりバッファやバンド幅)を確保するそれぞれのノードでメカニズム
   によって実施できます。これは区分サービスに気付いていない送り主が今と
   同じ方法でネットワークを使い続けるのを許します。顧客とピアのサービス
   の期待によるドメインへの区分サービスの導入の影響は、ドメインのポリシー
   決定を巻き込む複雑な問題で、この文書の範囲の外です。デフォルトPHB
   の推薦された(RECOMMENDED)コードポイントはビットパターン' 000000'です;
   値' 000000'はこれらの仕様書を満たすPHBにマッピングしなくてはなりま
   せん(MUST)。デフォルト行動のコードポイントは既存の[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ドメインの境界を通
   るために他のコードポイントのマークを付けられるかもしれません(MAY)、
   このため多分隣り合ったドメイン間で合意された何かによって異なるドメ
   インで異なるPHBを使って転送されるでしょう。

4.2  Once and Future IP Precedence Field Use
4.2  過去と未来ののIP優先フィールドの使い方

   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.
   我々はあるIP優先フィールドの現在の使い方とのバックワードコンパチビ
   リティを望みます:IPv4のTOSオクテットの0−2ビットです。IP
   優先フィールドを使用して、DSCPフィールドの目的同様に、異なるホッ
   プ毎の転送の扱いをするルーターが存在します。そこで、単純なプロトタイ
   プ区分サービスアーキテクチャは、これらのルーターの構成の設定で適切に
   すぐ動作できます。さらに、今日のIPシステムが、IP優先フィールドの
   位置と、これらのビットがDSに従っている装置の設定と同じ意味で使われ
   た場合、意味の違いはすばやい設定に好ましくありません。言い換えれば、
   DSCPフィールドのビット0−2が同様に使われているか、IP優先フィー
   ルドの使い方を包含しているなら、厳密なDSの遵守が1つのプロバイダー
   ネットワーク内であっても全面的に存在する必要がありません。

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優先フィールドはDSフィールドの原型です。IP優先とIP優先フィー
   ルドは[RFC791]で最初に定義されました。3ビットのIP優先フィールドが
   とるかもしれない値は、ネットワーク制御トラフィック、ルーティングトラ
   フィックを含めての、種々なレベルの特権の使用に割り当てられました。特
   権の最少のレベルは「定常トラフィック」と見なされました。[RFC791]での
   優先の考えはおおよそ「このデータグラムの重要性の独立した物差し」と定
   義されました。IP優先フィールドの全ての値が境界を超えて有効とは考え
   られてなく、「ネットワーク制御優先はネットワーク内のみで使われること
   を意図されます。実際の使い方と指定の制御はネットワーク次第です。」
   [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
   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優先はこの
   ようなフィルターが調べるオプションの一部です。

   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優先が、正確には[RFC791]が意図した方法ではないが、広く
   実装され、広く使われています。これは[RFC1122]で認識され、IP優先フィー
   ルドの使用は有効だが、[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優先フィールドで選ばれたパケット転送の扱いの仕様が非常に一
   般的で、恐らく区分サービス機構で予測可能なサービスをするのに十分なほ
   ど細かく指定しなければならないでしょう。将来の柔軟性を犠牲にせずに、
   IP優先フィールドの周知の現在の使用とのバックワードコンパチビリティ
   を維持するために、我々はIP優先フィールドによって選ばれて設定された
   転送処理の大部分と両立できるPHBのセットの最小必要条件を記述するア
   プローチをとりました。加えて、我々はこれらの最小条件を満たすPHBに
   マップする(MUST)コードポイントの集合を与えます。これらのコードポイン
   トにマップされたPHBは、ここで述べられた必要な仕様の他に、詳細なリ
   ストを持つかもしれません(MAY)。他のコードポイントをこれらの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はクラ
   ス選択PHB条件を満たさなければならず、加えてコードポイント'000000'
   はデフォルト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
   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つ
   の独立したトラヒックの転送たクラスをもたらし(MUST)、合理的な運用とト
   ラヒック下で、クラス選択コードポイントに選ばれたPHBが低い順位のク
   ラス選択コードポイントをマークされたパケットより多分タイムリーに転送
   されすべきです(SHOULD)。パケット廃棄がタイムリーでない転送の極端な場
   合と考えられます。加えて、ルーチングトラヒックのIP優先値'110'と
   '111'の値の一般的使用法を保存するため、コードポイント'11x000'によって
   選択されたPHBは、コードポイント'000000'によって選択されたPHBよ
   り優先の転送扱いをされなければなりません(MUST)。

   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は独立し
   て転送されるべきです(SHOULD);すなわち、異なったクラス選択コードポイ
   ントを指定したパケットの順序は変わるかもしれません(MAY)。ネットワーク
   ノードがこれらの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条件は4.1章のデフォルトPH
   Bでリストアップされたのと両立できます。

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の集合にマップしなくてはならないと述べます(MUST)。多
   数のコードポイントを同じPHBにマップすることが可能であるから、歴史
   的のIP優先と両立できるネットワークをもたらすため、DSCPフィール
   ドの3-5ビットにかかわらず、ベンダーあるいはネットワーク管理者がネッ
   トワークノードがコードポイントをPHBにマッピングするように設定する
   かもしれません(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]や、クラスベースキュー
   イングを含み、様々なメカニズムにより実現できます。PHBとメカニズム
   の間の区別は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
   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(標
   準化されてるか、されてない)を通して利用可能でかもしれないことを指摘
   することは重要である。例えば、将来の文書が推薦されたコードポイントの
   集合のために厳格な優先キューイング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メカニズムを使用するかも
   しれません。最小クラス選択PHB条件を満たさないPHBの集合で利用可
   能である広い機能を持ったクラス選択適合PHB集合と同様に、CBQメカ
   ニズムは厳密な優先キューイングを実装するために使う事が可能です。

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は4.2.2.2章で記述さ
   れたクラス選択PHB条件を満たさなくてはなりません(MUST)。これは将来
   の柔軟性を大きく制限することなく、インターネットでIP優先フィールド
   の現在の使い方との間のバックワードコンパチビリティを維持するためにさ
   れます。加えて、コードポイント'000000'がデフォルトPHB値としてイン
   ターネットで使われ、これは設定可能ではありません。残りの7つの非ゼロ
   のクラス選択コードポイントは、それらが4.2.2.2章の条件を満たすPH
   Bにマップする限りにおいてだけ、設定可能です。

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
   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グループが通常
   2つ以上のPHBから成り立ち、キューサービス提供やキュー管理ポリシー
   のようなグループ内の各PHBに当てはまっている公共の制約のために、P
   HBは意味だけを指定され同時に実行できます。PHBグループ仕様は、グ
   ループ内の他のPHBを選択するためにパケットのマークを変える状態を記
   述するべきです(SHOULD)。PHB実装がマイクロフロー内のパケットの順序
   を変えないことが勧められます(RECOMMENDED)。PHBグループ仕様はパケッ
   トの順序の変更の可能性を認識しなければなりません(MUST)、これは各PH
   Bで発生するかもしれないし、マイクロフロー内の異なるパケットに異なる
   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標準によって記述しなかったホップ毎の動作が、実
   装され、配置され、標準化すべき(SHOULD)であることが明らかになりました。
   区分サービスの現在の経験が非常に限定されているので、ホップ毎の正確な
   動作指定を仮定するのは時期尚早である。

   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のコードポイント(6章参照)
   から、推薦された(RECOMMENDED)コードポイントを割当てなければなりません
   (MUST)。この仕様書は発展を考慮してコードポイント空間の左に空領域を持
   ち、そのため定義された空間('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コードポ
   イントと結び付けられるかもしれず、ドメイン境界を超えて使用できます
   (6章参照)。これらのPHBは未来の標準化の候補です。

   It is RECOMMENDED that standardized PHBs be specified in accordance
   with the guidelines set out in [ARCH].
   標準化されたPHBが[ARCH]で明らかにされたガイドラインのとおりに指定
   されることは勧められます(RECOMMENDED)。

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
   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つのプールに分けられます:32の推薦(RECOMMENDED)コードポイ
   ント(Pool 1)は、[CONS]で定義されるように標準行動で割り当てられ、16
   のコードポイント(Pool 2)は、[CONS]で定義されるように実験かローカルな
   利用に予約され、16のコードポイント(Pool 3)は、当初は実験やローカル
   な利用に使えるが、Pool1が使い尽くされたら、標準割当てに優先的に使用さ
   れます。プールは次のテーブルで定義されます('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.
   この文書は上記Pool 1から8つの推薦(RECOMMENDED)コードポイント
   ('xxx000')を割り当てます。これらのコードポイントは、特定のPHBにマッ
   プするのではなく、しかし[RFC791]の定義と現在の装置で実装されているの
   との最小限のバックワードコンパチビリティを持つため、「少なくとも」
   4.2.2.2章の条件に一致するPHBにマップします(MUST)。

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コードポイントによって主に示されま
   す、それで敵が値が強化されたサービスに使われる動作を示すコードポイン
   トへ修正することで、あるいはこのようなコードポイント値のパケットを乗
   せかえることで、良いサービスを得ることが可能でかもしれません。これを
   制限すると、サービスを盗むことは、修正や注射されたトラフィックの転送
   によりアクセス可能なリソースが使い果たされる時、他のトラフィックスト
   リームに対して「サービスの否認」攻撃になります。

   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ドメイン境界ノードは、すべてのドメイ
   ンに入るトラヒックに適切なコードポイントを付けて、もし必要なら新しい
   コードポイント値をトラフィックに付けることを保証しなくてはなりません
   (MUST)。これらのDS境界線ノードは修正されたコードポイントに基づくサー
   ビス盗難とサービス否認攻撃に対しする主要な防衛線で、このような攻撃の
   成功は攻撃しているトラフィックにの使うコードポイントが不適当であった
   ことを示します。境界線ノードの重要な事実はDSドメインのトラフィック
   の出発点ノードは、そのトラフィックの最初の境界ノードだということです。
   DSドメインの内部のノードが、DSコードポイントでトラフィックを転送
   PHBと結び付ける前に、コードポイント値を検査するように要求されませ
   ん(NOT REQUIRED)。結果として、内部のノードは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
   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トンネルが区分サービスネットワークの上で(全部あるいは
   部分的に)実施されている時、中間ネットワークノードは外のヘッダーのD
   Sフィールドで動作します。トンネルの出口ノードが外のヘッダを削除して、
   IPsec処理が(もし必要なら)奥のヘッダーを使ってパケットを転送し
   ます。DSフィールドへの修正がIPsecトンネル終端の向こう側でサー
   ビス盗難やサービス否認攻撃の始動に使われないことを保証するために、
   IPsecプロトコルは奥のヘッダーのDSフィールドがカプセルを解く処
   理で変更されないことを要求します。この文書はその条件に対する変更をし
   ません。もし奥のIPヘッダーがトンネル出口ノードのDSドメインのDS
   境界線ノードによって処理されなかったなら、トンネル出口ノードはトンネ
   ルを出たトラフィックの境界線ノードであり、それ故結果として生じるトラ
   フィックが適切なDSコードポイントを持つことを保証しなくてはなりませ
   ん(MUST)。

   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.
   著者は区分サービスワークグループに対してこの文書を作るのに手伝った論
   議への感謝の意を表したいです。

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.

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

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

Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.
   著作権(C)インターネット学会(1998)。すべての権利は保留される。

   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.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Japanese translation by Ishida So