IPv4與IPv6包頭中差分服務字段（DS Field）的定義

本備忘錄概況

本文為Inte.net團體制定了一個標準協議，并在此請求得到討論以使之得到完善。為得
到本協議的標準聲明與地位，請參考最新修訂的“Internet官方協議標準”（STD1）。本文的
分發是無限制的。
版權通知

版權屬于?theInternetSociety(1998)。版權所有。

摘要
差分業務作為互連網協議提出，目的在于：在不需要規定每一數據流的狀況以及每一跳
都要有所動作的情況下，使得能夠對可以升級的、有區別的要求進行區分對待。而不同的服
務類型可以從配置于網絡節點中的小的、已定義了的構造塊組中來構造。這些服務即可以是
端到端的，也可以是在整個與內（定義）的；他們包括那些能滿足一定性能的要求（如峰值
帶寬）也包括那些具有相對性的性能（如“等級”區分）。這些服務可由以下方式結合建立：
? 在網絡邊界處（自治區域邊界，內部管理邊界或各個主機）的IP包頭中設置特定
比特；
? 用這些比特來決定網絡內部的節點如何轉發這些包；
? 在網絡邊界處，調節帶有標記的包（的調度）使之與各個服務的要求或規則一致。
這些各種服務的要求與規則必須由管理策略機構來制定，而這超出了本文的范圍。一個適
用于差分服務的網絡節點包含有過濾器、緩沖管理與包調度機制。過濾器基于包頭的DS字
段的值來選擇包，協同緩沖管理與包調度機制按該值所對應的轉發方式來發送包。DS字段
的設置與帶有標志的包的調整訓練只需在網絡邊界進行，而且在復雜性問題上有很大的區
別。
本文定義了IP包頭一特定字段，我們稱之為DS(為差分服務而定)字段。實際上，這個
字段在IPv4定義為TOS及服務類型比特組，而在IPv6中則對應為流標簽字段。另外，本
文定義了一些基本的轉發方式，如“單段行為”（PHB）。
若想更完整的了解差分服務，請參閱“區分服務結構框架”[ARCH]。

目錄

1. 導言 2
2. 本文所用術語 4
3. DS字段的定義 5
4. 從前的碼值定義與PHB需求 6
4.1默認PHB 6
4.3總結 9
5. 單段行為的標準化指南 9
6. IANA考慮 10
7. 安全性考慮 11
7.1盜用與拒絕差分服務 11
7.2與IPsec和隧道技術的交互 11
8. 致謝 12
9. 參考資料 12
10. 作者地址 13
11. 版權陳述 14


1. 導言

差分服務的意圖在于在因特網中配置一種能夠對可以升級的、有區別的要求進行區分對
待的網絡框架與區塊構造。差分服務的目標是將整個構造系統分為兩個主要部分來加速這種
配置的展開。這兩部分一個相當容易理解，另一個我們才剛開始去理解。在這方面，我們以
一種起初構造因特網時的思想作為指導，即將轉發與路由部件分離。包轉發機制是一個相對
容易的工作，它只需要盡快的將每一個IP包轉發出去。轉發時，找到與包頭所指對應的路
由表項來決定該包的輸出接口。而路由要設置路由表中表項，而且要對一定范圍內的有關變
化與其他一些情況如跟蹤失敗路由作出反應。路由表的維護是作為轉發工作的背景程序進行
的。進一步說，路由這一復雜的問題今天已經解決了二十年，而且還在繼續發展。
類似的，差分服務的框架也包含兩個部分。一個是相當易于理解的在轉發途中的處理舉
措，另一個是十分復雜的、還是剛剛顯現出來的用來配置在轉發過程中所用參數的后臺程序
與配置部件。其中，轉發舉措包括對于接受到的不同的包的區別對待，就如同在隊列服務規
則與隊列管理規則中實現的一樣。這些“單段行為”是十分必要的，且不論我們怎樣構建端
到端或整個域內的服務，需要網絡中的節點能夠轉發我們區分對待了的包。我們的焦點在于
一般語義上的“行為”而非用來實現他們的特定機制。這是因為這些“行為”會比機制發展
的慢。
在每一個包的基礎上選擇它們的單段行為及其機制如今可以放置在網絡節點中，這也是
差分服務所最先強調的問題。另外，轉發所經的途徑也需要訓練、維護與整理來滿足某些包
所需要的“特殊對待”。這種類型的流調控機制也是相當易于理解的。這種調控的廣泛配置
在服務業務的構造中也是相當重要的，盡管它們的實際用途還要演化一段時間。
為使特定的包得到特定的對待而如何配置網絡組成部分與使用何種規則來應用資源是
不大好理解的。盡管如此，用簡單的策略與靜態的配置在網絡中展開差分服務還是可行的。
正如在[ARCH]中所描述的一般，構造單段行為與流邊界調節器來創建不同服務的方法由許
多種。而且在此過程中，會得到許多經驗來指導我們構建更復雜的策略與配置。當這一部件
演變發展之后，轉發途中的基本行為仍是不變的。構造這些服務的經驗會在相當一段時間內
繼續發展下去，所以我們在這里盡量避免在這個構造成熟之前就把它標準化。進一步說，許
多服務構造的細節問題是與不同的商業實體之間的法定協議相關的，我們也避開這個問題因
為它不在IETF的研究范圍內。
本文著重與轉發途徑上面的問題。在包轉發的過程中，差分服務通過包含于IP包頭的
一個字段的碼值來映射一種特定的轉發處理方式，即單段行為（PHB）,這是在轉發途中的
每一節點中都要進行的。而這之中的碼值，則可以從本文所定義的強制應用的值中選擇，也
可從未來的文檔所推薦的值中選擇，或僅僅只是本地的自定義值。PHB的實現方法是：在
網絡節點的輸出接口處使用一系列隊列服務或隊列管理規則，如加權輪詢(WRR)隊列服務或
丟包優先級隊列服務。
做標記的工作是由網絡邊界處的流調節器包括網絡邊緣節點（第一跳路由或源主機）與
有管理權限的邊界點完成的。調節器的工作包括粗糙的打標記、測量與整理（這些機制在
[ARCH]中描述）。而整個服務的完成時通過利用在邊界點上的特定包的分類與流調整機制再
加上在傳送途中一連串的單段行為來表現的。差分服務的目的之一就是考慮將來的擴展性來
規定這些構造區塊，包括區塊的數量與種類，也包括從中構建的服務。
本文眾說用道的術語在第二節中定義。差分業務字段的定義在第三節中給出。在第四屆
中我們討論它與IPv4優先級的向后兼容性。作為結論，我們介紹了類選擇碼值與類選擇下
的PHB。第五章是單段行為標準化指南。第六章是定義碼值的說明。第七章包含了一些有
關安全性的考慮。
本文只是簡明的描述了DS字段及其使用。它應該參照“差分服務框架”（ARCH）閱讀。
本文中用到的關鍵字“必須”、“不允許”、“需要”、“應該”、“不應該”、“可以”、“不可
以”、“建議”、“可能”、與“可選擇”將在RFC2112中解釋。
2. 本文所用術語

分組聚合：積聚通過某一通向某一特定方向的鏈路的具有相同碼值的包?！熬酆稀迸c“分
組聚合”在本文中是等價交替使用的。
分類器：根據所定義的包頭的內容選擇包的一種實體。
類選擇碼值：在‘xxx000’（此處的‘x’可為‘0’或‘1’）之間的任意一個碼值。我
們在4.2.2中討論有關類選擇碼值的問題。
類選擇對應的PHB：滿足4.2.2.2中指定的類選擇PHB條件的單段行為。
碼值：DS字段中DS標記（DSCP）部分所指定的值。建議碼值應該映射于特定的、標
準化的單段行為。多個碼值可以對應同一PHB。
差分服務域邊界：DS與的邊緣。分類器與流定型器在此處配置。一個差分服務域邊界
可一細化分為兩種節點：入口節點與出口節點。它們分別對應在邊緣鏈路的指定方向的上行
/下行流。典型的差分服務域邊界位于包進入差分服務域的第一跳所對應的路由器（或網絡
節點），或包離開差分服務域邊界在到達目的之前所經過的最后一跳所對應的路由器（或網
絡節點）。這種情況通常叫“葉路由器上的邊界”，一個差分服務邊界可以根據本地需要配置
在主機中。差分服務域邊界也叫DS邊界。
滿足差分服務：與本文所指定的要求一致。
差分服務域：一系列協同滿足差分服務策略管理的、連續的英特網的一部分。一個差分
服務于可以包括不同的主機與路由器、管理區域、自治域，不同的信任域與不同的網絡技術
（比如信元或幀）等等。差分服務域也叫DS域。
差分服務字段：本文所給出定義的IP包頭字段。實際上是IPv4中的TOS和IPv6中的
流標簽八位組。也叫DS字段。
機制：特定算法所對應的一種或多種單段行為的實現方法。
微量流：應用程序到應用程序間的定義了源地址、目的地址、協議ID、源端口號、目
的端口號（當可用時）的流的一個實例。
單段行為（PHB）：有關DS節點對通過某一條鏈路的具有相同DSCP的分組集合所施
加的外部可見的轉發行為的描述。PHB的描述應該足夠詳細，使之如[ARCH]中所描述的一
樣可以構建可預見的服務。
PHB集合：一個或多個PHB組成的集合。這些PHB具有相同的指定意義，可以同時
完成，因為這些PHB具有相同的約束，比如隊列服務或隊列管理策略。
業務流定型：可用在分類聚合、應用業務流、或其他由意義的可操作的流的子集如路由
更新等方面的控制功能。這些功能可能包括計量、整形、丟棄、標記。業務流定型用來增強
域之間的協定，也可以通過在DS字段中作合適的標記與在必要時檢查、改變某個聚合的臨
時特性來在域中得到差分服務。詳情請參看[ARCH]。
業務流定型器：一個具有業務流定型功能的實體。具體功能可以包括計量、整形、丟棄、
標記。業務流定型器一般配置于DS邊界節點（也就是說，不在DS域的內部節點中）。
服務：對于客戶的通過一特定的域、通過一系列互連的DS域或只是端對端的業務流的
全部的（或一個子集）的處理。服務的描述由管理機制所表現。服務的構造是通過應用業務
量定型來得到分組聚合（分組聚合在DS域中的每個節點都經歷了特定的PHB）。多重服務
可以通過許多業務流定型器中所應用的同一單段行為來支持。
綜上所述，分類器與業務流定型器起選擇哪些包應該加入哪個分組聚合的作用。各個聚
合在DS域中由其差別而受到不同的服務，而業務流定型器可能會依照某些請求改變聚合的
短時特性。一個包的DS字段用來指定該報的分組聚合類別，從而達到決定這個包受到什么
樣的轉發處理。一個分組聚合分類器可以選擇一種PHB方式（比如說，用差分輸出對流服
務規則），這種選擇基于包含在該DS域中所有網絡節點中所定義的DS字段的碼值。DS邊
界的分類器于業務流定型器是按照特定的服務所設置的，而這種管理策略不在本文的討論范
圍之內。
與差分服務相關的一些附加定義在[ARCH]中給出。
3. DS字段的定義

我們定義DS字段來代表在[RFC791]中定義的IPv4包頭中的TOS八位組與[IPv6]中所
定義的流標簽八位組。
DS字段中的前六位定義為DS標記（碼值），它用來在每個節點中選擇包的PHB。剩下
的兩位目前未定義的比特為CU字段。這個字段的定義與解釋不在本文的討論范圍內。CU
位的值在差分服務節點對某一包進行單段行為時忽略。
DS字段的結構如下所示：
01234567
+---+---+---+---+---+---+---+---+---+---+
|DSCP|CU|
+---+---+---+---+---+---+---+---+---+---+

DSCP：差分服務碼值，即DS標記值
CU：目前未定義

在本文所示的DS標記中，標記‘xxxxxx’（此處‘x’可為‘0’或‘1’）的最左端比特位
代表DS字段的0比特位，而其最右端比特代表DS字段的第5比特位。
業務的提供者要注意DS標記字段寬度是6比特。提供DS服務的節點必須嚴格的以這
6比特的DS標記字段來選擇PHB。舉例來說，用這個字段中定義的值作為一個索引表來選
定應該對一個特定的包作何種處理（當然這種處理機制已經在該節點中實現了）。CU字段
的值必須在選擇PHB使被忽略（以便未來擴展功能）。，以便將來更加靈活的定義單端行為，
DS標記字段并未系統化定義。
由于以下所列出的問題，碼值到PHB的映射必須是可以配置的。一個DS服務節點必
須支持可配置的由碼值到PHB的映射表的邏輯等同性。PHB的定義必須包括所建議的默認
碼值，這個碼值必然是在對應的標準格式下（見第六節）獨一無二的。就是說，服務必須在
其默認設置下支持本文建議的碼值到PHB的映射。但相關操作可以對不同的碼值用同一個
PHB，不論這個PHB是不是建議默認的。要注意的是，如果做出了這樣的選擇，就可能需
要在DS管理域邊界對DS字段重新做標記，就算是邊界兩邊所執行的PHB相同也是一樣。
有關重新標記的深一步討論請參考[ARCH]。
對于與一般設置不同的例外即碼值為‘xxx000’的情況，我們將在4.2.2與4.3中討論。
節點接到的包的碼值若不能識別的話，節點應該把它當成作了默認標記的包而轉發出去
（詳見第四節），而且包的碼值不能被改變。這類包不可以讓網絡節點產生故障。
上面所講到的DS字段和現有的[RFC791]中的IPv4TOS八位組的定義是不同的。但正
如一個網段使用RFC791的指定優先級一樣，我們可以假設DS域可以通過配置重新做標記
的邊界節點來保護自己。正確的操作過程應當遵循[RFC791]，它指出：“如果這些指定優先
級只是在一特定網段中使用，那么這個網段就有責任控制接入與使用這些優先級?！痹谌魏?BR>情況下，DS邊界確認DS字段的值都是明智的。因為一個上行流處的節點可以將這個值設
成任意數。這樣，未做到獨立與未正確配置邊界節點的DS域可能會承擔不可預見的服務。
為了提供所希望的本地的或端到端的服務，節點可能要重設DS字段的值。DS邊界之間的
DS字段如何轉換事關業務提供者與用戶之間的業務性條約，不再本文的討論范圍之內。標
準的PHB使業務提供者可以從一系列眾所周知的包轉發策略中構建他們的服務。而這些策
略可能已經配置在用戶的設備中了。
4. 從前的碼值定義與PHB需求

正如本節將要討論的一樣，DS字段與現行協議的先后兼容性有一定的限制。我們強調
的“向后兼容性”有兩個含義。首先，有一些單段行為已經廣泛應用了（比方說，有一些滿
足[RFC1812]所指定的IPv4優先級隊列條件的行為），我們希望使他們在DS與節點中能夠
得到不變得服務。另外，有一些現行碼值滿足IP優先級字段的描述，我們保留這些碼值，
并將他們映射到滿足一般需要（在4.2.2.2中詳細說明）的PHB上，但注意這些碼值對應的
特定的差分服務PHB可能有一些附加的說明。
注意，我們并未在維護與“DTR”或IPv4服務類型八位組“TOS”的向后兼容性方面
做過努力。
4.1默認PHB

DS服務節點中必須有一個默認的PHB。而這個PHB就是現行路由器中普遍的盡力轉
發行為（見[RFC1812]）。但沒有達到其他共識時，節點就應該假設該包是屬于默認聚合的。
這種類型的包個能沒有進行任何處理（沒有要求服務）就發到網絡中，網絡應該盡可能多、
盡可能快的轉發這類包，當然這是受到其他一些運用資源的策略限制的了。對這種PHB的
一種合理的實現方式為：當輸出鏈路未被其他PHB要求所占用時，盡力法這個聚合中的包。
而構建服務的一個合理的策略應該是：不要讓聚合空閑。這種情況下的一種實現機制可以是：
每個節點預留一小部分資源（比如說緩沖、帶寬）來為默認聚合服務。這樣就可以是根本不
知道差分服務的用戶像今天一樣使用盡力轉發的網絡了。而一個域引入差分服務所給它的消
費者與旁觀者帶來的對服務質量期望的沖擊不在本文范圍之內。默認PHB的建議碼值的形
式為‘000000’；而‘000000’這個值必須映射到滿足這些規范的PHB上。這個默認碼值的
選擇是與現行的[RFC791]兼容的。但節點發現一個包的碼值沒有映射到標準的或本地定義的
PHB上時，因該將它映射到默認PHB。
一個開始時做了默認行為標記的包在它進入另一個DS域的邊界處可能會重新作另一個
標記，這樣它在這個域中的轉發會使用不同的PHB。這可能受制于域與域之間的合約。
4.2曾經和將來的IP優先級字段

我們希望在差分業務中可以維護與現行IP優先級字段即IPv4TOS八位組的0-2比特位
的向后兼容性?，F今的路由器在根據IP優先級字段選擇不同的單段轉發處理的操作與使用
我們所提議的DSCP字段是相同的。所以，適當的調整這些路由器就可以很快的構造出一個
簡單的差分服務框架原型。另外，當今的IP系統知道IP優先級字段的位置，所以當我們配
置了用于DS服務的設備之后以相同的方式運用這個字段，不會在網絡配置過程中出現重大
的錯誤。換句話說，就算在業務提供者的一個簡單的網絡中，若其DSCP字段的0-2比特與
其從前配置的IP優先級字段的配置方式相同或是包含于它的話，嚴格滿足DS條件的設備
并不需要普遍存在。

4.2.1IP優先級的歷史與演變簡述

從某種意義上說，IP優先級字段是DS字段的先驅，我們最初對IP優先級字段的定義
是在[RFC791]中。這個字段中的三個比特的值可能會指定起不同的作用，包括網絡控制流、
路由信息流、或不同級別的優先級。其中的最低優先級是“路由信息流”。在[RFC791]中，
優先級的概念被廣義的定義為“視數據流的重要程度而對其進行的獨立處理”。并不是所有
的IP優先級字段的值在包通過邊界節點時都被認為是有意義的，例如“網絡控制的優先級
指定只會用在一個網段中，使用與管理這個指定權是網段自己的事”([RFC791])。
盡管早期的BBNIMPs（路由器）就實現了這種優先級特性，但早期的商用路由器與
UNIXIP轉發機制不支持它。當網絡越來越復雜、用戶的要求越來越多時，上用路由器的賣
主們開始開發實現不同種類的排隊服務的方法，包括優先級排隊。優先級排隊一般來說基于
路由器的過濾其中所編制的策略，它檢查包的IP地址、IP端口號、TCP或UDP端口號與
其它字段。IP優先級字段就是過濾器可以檢查的內容的一項。
總之，IP優先級已經廣泛的配置與應用了，只不過它沒有準確的按[RFC791]的方式進
行。[RFC1122]認識到了這個問題，它指出，設定IP優先級字段是正確的，但是[RFC791]
中明確指定的優先級已經成為歷史。
4.2.2包含IP優先級的類選擇碼值

根據IP優先級字段來規范一個包的轉發策略在當今已經是十分普遍的了，但對于來構
建一個可預見服務質量的差分服務框架來說還不夠完善。為了在不犧牲對于未來擴展的靈活
性的前提下保留對于現存IP優先級字段的部分兼容性，我們的方法是：用一系列PHB描述
最小的要求來與盡可能多的IP優先級字段配置的轉發對策相對應。另外，我們給出了一系
列必須映射于滿足這些最小要求的PHB的碼值。注意，這些PHB可能在除了此處提到的條
件外還有一些詳細的規范。剩余的碼值可以映射的到這些PHB上。我們把這一系列碼值叫
做類選擇碼值，而這些碼值對應的PHB的最小需求叫類選擇PHB條件。
4.2.2.1類選擇碼值
由DS字段字為‘xxx000|xx’，或‘xxx000’加上未定義的CU自子段為保留類選擇碼
值。由這些碼值所映射的PHB除保留‘000000’所對應的默認PHB需求外必須滿足類選擇
PHB條件（見4.1）。
4.2.2.2類選擇PHB條件

我們所說的類選擇碼值的數字越大，其相對的地位就越高；碼值越小，其相對地位就越
低。八個類選擇碼所映射的一系列PHB至少要產生兩類獨立的流，而且在合理的操作情況
與業務負載下，一個類選擇碼值所規范的PHB應該給與對應包以不低于處于較低地位的類
選擇碼值所規范的、更及時的轉發服務。丟包現象是不及時轉發的極端情況。另外，碼值
‘11x000’所選擇的PHB必須要比碼值‘000000’所選擇的PHB優先，這是為了維護現行
的路由信息所對應的IP優先級值‘110’和‘111’的作用。
進一步說，明確的類選擇碼值選擇的PHB應該被獨立的轉發，也就是說，作了不同的
類選擇碼值記號的包可能會被重新排序。一個網絡節點可能會對每個PHB所需的節點資源
的量進行限制。
滿足這些規范的PHB集就是滿足類選擇的PHB。
碼值‘000000’的類選擇PHB條件與4.1中所列出的默認PHB一致。
4.2.2.3用類選擇PHB條件與IP優先級兼容

一個DS服務節點中可以配置一系列的單個或多個類選擇PHB集。本文已指出碼自己
和‘xxx000’必須映射到這樣的一系列PHB上。而由于多個碼值可能映射到一個PHB，網
絡的投資者或網絡管理者可以在不考慮DSCP字段的3-5比特的情況下配置網絡節點，這樣
產生的網絡必然與從前使用IP優先級的包兼容。比如說，碼值‘011010’與碼值‘011000’
在這種情況下受到的PHB是一樣的。
4.2.2.4實現滿足類選擇PHB集的機制舉例

滿足類選擇PHB可通過多種機制實現，包括嚴格的優先級排隊、加權公平排對（WFQ）、
WRR及其變種[RPS,HPFQA,DRR]、CBQ[CBQ]等等。這些機制及其對應PHB的區別將在第
五節中描述。
值得注意的是，這些機制可能會在某些的定賣主的設備中所可行的（標準或非標準的）
PHB中可行。舉個例子來說，未來的文檔可能會把嚴格優先級排隊的PHB集定義在一組建
議碼值上，而網絡管理員會將這些路由器設置為選擇碼值‘xxx000’的包進行嚴格優先級排
隊來滿足該文檔的要求。
再例如，某個賣主可能將CBQ機制做入了路由器，那么CBQ機制可能會被用來完成
嚴格優先級排隊。這正如有很多特性的一系列類選擇PHB在僅有最小的類選擇PHB條件特
性下可行一樣。
4.3總結

本文定義了碼值‘xxx000’來作為類選擇碼值，而由這些碼值選擇的PHB必須滿足4.2.2.2
中描述的類選擇PHB條件。這是為了保持當前所用的IP優先級字段的可用性的向后兼容性
且不影響未來的靈活性而指定的。另外，碼值‘000000’用作默認PHB值而不準任意配置。
剩下的七個非零類選擇碼值可進行配置，但要滿足4.2.2.2的要求。
5. 單段行為的標準化指南

此處要標準化的是PHB的操作特征，而不是具體的實現它們的特定算法與機制。一個
節點可能會有（相當大）一組參數來控制如何調度包，并將它們送到輸出接口（比方說，N
個獨立隊列參數，隊列長度，輪詢加權值，丟包算法，丟包優先加權與門限等等）。為了說
明PHB與其機制的區別，我們應該看到類選擇PHB可以為許多機制所實現，包括嚴格的優
先級排隊、加權公平排對（WFQ）、WRR及其變種[RPS,HPFQA,DRR]、CBQ[CBQ]等等。
它們可以單獨或混合使用。
PHB可以單獨的設定，也可以作為集合而指定（單獨的PHB是PHB集的特例）。PHB
集通常一個或多個PHB組成的集合。這些PHB具有相同的指定意義，可以同時完成，因為
這些PHB具有相同的約束，比如隊列服務或隊列管理策略。PHB集中有這樣的情況：一個
包可能會為了在包中選擇另一PHB而重新做了標記。在這里，建議完成PHB是不要對流中
包進行重新排序。還有，PHB集必須識別會發生在每個PHB上的包的重排序的任何可能，
以及在集合中一個微流中的不同的包做了不同的PHB標記的可能。
只有那些沒有在現存PHB標準中描述過的、而被實現、配置且表明是有效的單段行為
是應該被標準化的。但是由于當今的差分服務的經驗還十分有限，假定確切的單段行為的規
范是有欠成熟的。
任意一個標準化的PHB必須有一個對應的建議碼值，這個碼值是從32個值（見第六節）
中選擇分配的。這一條給將來的演化發展流出了碼值空間。這里定義的值（‘xxx000’）是有
意的定在了小范圍內。
網絡設備賣主可以提供它們認為有用的或由市場的任何參數和性能的設備。但一個節點
實現了特定的表準化PHB，買主可以在滿足標準定義的PHB的情況下使用任意算法。節點
的性能與其特定設置決定了處理包的不同方法。
業務提供者不需要在其網絡中使用不變的節點機制或配置來進行差分服務，他們可以任
意配置節點參數，只要它滿足服務要求與業務工程目標即可。一段時間之后，某些通用的單
段行為可能要演變（即那些對實現端到端服務有其有效的操作），他們可能會與DS字段的
特定EXP/LUPHB碼值有關，用來通過域邊界（見第六節）。這些PHB有待未來的標準化。
建議參照[ARCH]來指定標準化PHB。
6. IANA考慮

DS字段中的DSCP字段可以有64個不同的碼值。這個碼值空間劃分為三個部分（三個
池）：有32個建議碼值的池一用作[CONS]中定義的標準操作，有16個碼值的池二為[CONS]
中定義的實驗與本地使用（EXP/LU）預留，剩下的有16個池三的值開始四是用作實驗與本
地使用，但可能會在標準指定的池一耗盡后補充使用。這三個池的定義如下表（‘x’指‘0’
或‘1’）：
池碼值空間分配策略
------------------------------------

1xxxxx0標準操作
2xxxx11EXP/LU
3xxxx01EXP/LU(*)

（*）可能將來需要使用作標準操作

本文指定的八個建議碼值（‘xxx000’），是從上面所說的池一中取的。這些碼值必須被
映射，不是映射到特定的PHB，而是按先前4.2.2.2中所要求的最低要求來提供與[RFC791]
中定義的IP優先級（當今的一些設備所用）的最小限度的向后兼容性。
7. 安全性考慮

本節討論由差分服務的引入所帶來的安全性問題，主要問題在于拒絕訪問攻擊與未授權
的業務流的竊取服務的潛在可能性（7.1）。7.2節著重講在IPsec的情況下差分服務的操作，
還有它與IPsec隧道模式和其他隧道模式協議的交互。有關差分服務整個結構的安全性問題
的廣泛討論請參閱[ARCH]。
7.1盜用與拒絕差分服務

差分服務的最初目標在于在相同的網絡基礎結構下，為業務流提供不同級別的服務。許
多技術都可以用來達到這一目標，即最終一些包將受到與其它包不同的（比如說更好的）服
務。將網絡中的流映射于特定的轉發行為將最終得到不同（好或壞）的服務，而這個服務從
根本上說是由DS碼值所決定的。因此我們的對手可以通過改變碼值，使碼值代表增強服務，
或直接將有這種碼值的包注入網絡來得到更好的服務。作為這個問題的極端，當修改過的或
注入的流耗盡了用來轉發它與其它業務流的資源時，這種盜用服務就成了拒絕服務攻擊。對
于這種盜用與拒絕服務攻擊的防范措施在于DS域邊界的業務流整形與DS域網絡基礎構造
的安全性與整體性的結合。DS與邊界節點必須保證所有進入域中的流所作的標記碼值對本
地情況都是恰當的，且必要的話對流重新做標記。這些DS邊界節點是防范基于碼值修改的
盜用與拒絕服務攻擊的第一道防線，因為這種攻擊的成功表示攻擊流所用的碼值是不正確的
碼值。需要指出的是邊緣節點可以是DS域中任一流的源節點。DS域內的節點依靠DS碼
字來確定流轉發的PHB，不用再使用碼值之前檢查它。所以，內部節點可依賴DS域邊界節
點的正確操作來防止得到不正確碼值流或超出預備級別的服務而中斷域的正常工作。
7.2與IPsec和隧道技術的交互

在[ESP,AH]中定義的IPsec協議沒有對IP包頭的DS字段進行加密計算（在隧道模式中，
在外部的IP包頭的DS字段未加密）。網絡節點對DS字段的改變對于IPsec的端到端安全
性并沒有任何影響，因為它不能使任何IPsec的校驗失敗。作為結論，IPsec并不提供任何
用來防范我們對手改變DS字段（換句話說，是中間人攻擊）的方法，正如同我們對手對
DS字段的改變對IPsec的端到端安全性沒作用一樣。
IPsec的隧道模式對封裝了的IP頭中的DS字段提供安全保證。在隧道模式下的IPsec
包有兩個包頭：外部包頭由隧道入口節點提供，而封裝了的內部包頭由包的源提供。但差封
服務網絡（全部或部分）建立了IPsec隧道后，中間網絡節點只能在外部包頭的DS地段操
作了。在隧道的出口節點，IPsec的操作包括去掉外部包頭與按包的內部包頭轉發（如果要
求這樣的話）。IPsec協議要求內部包頭的DS字段在解封裝的過程中不改變，以次來保證在
IPsec隧道兩端之間對DS字段的修改不會達到盜用與拒絕服務攻擊的目的。本文對這一條
件沒有變動。如果內部IP由于隧道出口節點在域內而未被DS邊界節點處理的話，隧道的
出口節點就成為對于業務流出隧道的邊界節點，因此必須確保得到的業務流有正確的DS碼
值。
當在IPsec隧道出口的解封裝過程中包含足夠強度的對已封裝的包的密碼完整性的校驗
（此處的強度是由本地安全策略決定的）時，隧道的出口節點可以安全的假設內部包頭的
DS字段在與其到達隧道入口節點的值是相同。所以我們可以得到結論：DS域中的非安全鏈
路的安全性可以通過足夠強度的IPsec隧道來保證。這一結論及其含義適用于任何進行完整
性校驗的隧道協議技術，但內部包頭DS字段的安全程度還有賴于隧道協議所進行的校驗的
強度。在使用缺乏足夠信任度的、可能經過當前DS域外的節點（或是易受攻擊）的隧道的
情況下，封裝了的包必須被當作是從DS域外來到了域邊界來處理。
8. 致謝

作者在此感謝差分服務工作組，謝謝你們有助于定型本文的的討論。
9. 參考資料

[AH]Kent,S.andR.Atkinson,"IPAuthenticationHeader",
RFC2402,November1998.

[ARCH]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.
andW.Weiss,"AnArchitectureforDifferentiated
Services",RFC2475,December1998.

[CBQ]S.FloydandV.Jacobson,"Link-sharingandResource
ManagementModelsforPacketNetworks",IEEE/ACM
TransactionsonNetworking,Vol.3no.4,pp.365-386,
August1995.

[CONS]Narten,T.andH.Alvestrand,"GuidelinesforWritingan
IANAConsiderationsSectioninRFCs",RFC2434,October
1998.

[DRR]M.ShreedharandG.Varghese,"EfficientFairQueueing
usingDeficitRoundRobin",Proc.ACMSIGCOMM95,1995.

[ESP]Kent,S.andR.Atkinson,"IPEncapsulatingSecurity
Payload(ESP)",RFC2406,November1998.

[HPFQA]J.BennettandHuiZhang,"HierarchicalPacketFair
QueueingAlgorithms",Proc.ACMSIGCOMM96,August1996.

[IPv6]Deering,S.andR.Hinden,"InternetProtocol,Version6
(IPv6)Specification",RFC2460,December1998.

[RFC791]Postel,J.,Editor,"InternetProtocol",STD5,RFC791,
September1981.

[RFC1122]Braden,R.,"RequirementsforInternethosts-
communicationlayers",STD3,RFC1122,October1989.

[RFC1812]Baker,F.,Editor,"RequirementsforIPVersion4
Routers",RFC1812,June1995.

[RFC2119]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.

[RPS]D.StiliadisandA.Varma,"Rate-ProportionalServers:A
DesignMethodologyforFairQueueingAlgorithms",IEEE/
ACMTrans.onNetworking,April1998.

10. 作者地址
KathleenNichols
CiscoSystems
170WestTasmanDrive
SanJose,CA95134-1706

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


StevenBlake
TorrentNetworkingTechnologies
3000AerialCenter,Suite140
Morrisville,NC27560

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


FredBaker
CiscoSystems
519LadoDrive
SantaBarbara,CA93111

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


DavidL.Black
EMCCorporation
35ParkwoodDrive
Hopkinton,MA01748

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

11. 版權陳述
版權?theInternetSociety(1998)。版權所有。
本文和它的翻譯可能被復制和提供給別人，并且引出一些評論或者解釋它或援助它執行
可能被準備，拷貝，出版和分配，不管是整體的還是局部的，沒有任何限制，提供這上面的
版權告示和包含所有拷貝和起源工作的章節。但是，這個文章它自己本身不能以任何方式修
改，例如通過移走版權告示或因特網團體或別的因特網組織的參考書目，除了發展因特網標
準的需要，在這種情況下，定義在因特網標準過程中的版權程序應該要有，或者需要翻譯成
不同于英語的別的語言。
這個受限的許可同意以上的聲明是永久的，并且它將不會被因特網團體或它的繼任者或
設計者廢除。
包含在這兒的這個文件和通知作為一個基礎來提供。這個因特網團體和這個因特網工程
任務迫使它宣布所有的授權，表達或隱含，包括但是不限制任何授權，在這兒信息的用途不
破壞任何權利或任何隱含的購買授權或一個特別的目的。