組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：徐永久（albertxu    albertxu@bigfoot.com）
譯文發布時間：2001-3-27
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。
Network Working Group                                   B. Volz
Request for Comments: 3074                             Ericsson 
Category: Standards Track                              S. Gonczi   
              Network Engines,Inc.                                                             T. Lemon
                                           Internet Engines, Inc.
                                                      R. Stevens
                                               Join Systems, Inc.
February 2001

RADIUS計費對于支持隧道協議的修正
備忘錄
這份備忘錄提供了有關互聯網通信的信息，它并未涉及任何一種互聯網標準，可以自由傳播此備忘錄。
版權聲明
    Copyright (C) The Internet Society (2000).  All Rights Reserved.
摘要
現有的計費狀態方式屬性是用來支持在撥號終端提供強迫通道建立，這份文檔為現有的計費狀態方式定義了RADIUS計費屬性極其新值。
規范要求
在這份文檔中，關鍵詞“可以”，“必須”，“禁止”，“可選的”，“推薦的”，“應該”，“不應該”，等應該被解釋成[2]中的描述。
目錄
備忘錄	1
版權聲明	1
摘要	1
規范要求	2
1．介紹	2
2實施注意	3
3．新的計費狀態方式值	4
3．1．通道開始	4
3．2．通道停止	4
3．3通道拒絕	5
3．4通道鏈接開始	6
3．5通道鏈接停止	6
3．6通道鏈接拒絕	8
4．屬性	8
4．1計費通道連結	8
4．2 計費通道丟包	9
5．屬性表	10
6安全性考慮	11
7．參考文獻	11
8．感謝	11
9．作者地址	12
10．全部版權聲明	13
致謝	13

1．介紹
    許多協議應用中都包括了撥號終端訪問。其中的一些，如提供通過互聯網的企業內部局域網的安全訪問，是定義成主動的通道建立：通道是在用戶為一個特定目的而發出請求時建立。另一些包括了強迫的通道建立：通道建立不需要任何的用戶響應，同時，不允許用戶做任何選擇，如同ISP的服務。
典型的，提供一項服務的ISP要為記賬，網絡計劃編制等收集數據。在撥號終端中收集有用數據的一種途徑是利用RADIUS計費[1]。利用RADIUS計費允許在一個中心位置收集有用數據而不是儲存在每一個NAS中。
    為了收集通道建立數據，需要新的RADIUS屬性；這篇文檔定義了這些屬性。另外，提出了幾個關于計費狀態方式屬性的新值。對這些屬性在L2TP協議的應用，RFC2809中給出了具體的建議和例子。
2實施注意
    強迫的通道建立可以是一個實體提供給另一個的服務包中的一部分。例如，一個公司可能和一個ISP簽訂協議通過強迫通道建立來為他的雇員提供遠程企業局域網訪問，在這種情況下嵌入RADIUS以及通道協議允許ISP和企業同步他們的計費活動事的雙方都收到一個用戶消費的紀錄。這給企業審計ISP的賬單提供了一種途徑。
在審核中，用戶名，計費通道連接，通道客戶端和通道服務器端的屬性通常被用來唯一的識別一個呼叫，允許NAS發出的計費請求與相應的通道服務器發出的請求保持一致。
在RADIUS計費應用于L2TP/PPTP通道建立時，呼叫序列號應該用在計費通道連接屬性中。在L2TP中，呼叫序列號是一個32位的域二在PPTP中，它是一個16位的域。在PPTP中，IP地址和呼叫序列號應該是唯一的，但不是必要的。另外，決定呼叫號碼的方法也不是確定的，這.....
需要注意的是，一個16位的呼叫序列號是不足以在一個擴展的時間周期從所有的呼叫中區分出一個給定的呼叫的。例如，如果呼叫序列號的分配是線性的，在查詢中的NAS有96個端口而且是持續忙的，平均的呼叫周期時20分鐘，這樣，一個16位的呼叫序列號將會在65536/（96*3呼叫/小時*24小時/天）=9.48天之內覆蓋。
3．新的計費狀態方式值
3．1．通道開始
值
9
描述
這個值可以被用來標志和另一個節點的通道建立。如果這個值被使用，下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
計費延遲時間（41）
時間時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
3．2．通道停止
值
10
描述
這個值可以被用來標志和另一個節點的通道消除。如果這個值被使用，下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
計費延遲時間（41）
計費輸入字節（42）
計費輸出字節（43）
計費通話ID（44）
計費通話時間（46）
計費輸入包（47）
計費輸出包（48）
計費終止原因（49）
計費多話路ID（51）
事件時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
機非通道丟包（86）
3．3通道拒絕
值
11
描述
這個值可以被用來標志和另一個節點的通道建立拒絕。如果這個值被使用，下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
計費延遲時間（41）
計費終斷原因（49）
時間時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
3．4通道鏈接開始
值
12
描述
這個值可以被用來標志一個通道鏈接的建立。只有一些通道類型（如L2TP）支持每通道多鏈接。這個屬性傾向于標志載一個有著多鏈接的通道內一個鏈接的建立。例如，如果一個強制的通道在生存期內要承載M個鏈接，那么2（M+1）RADIUS計費消息可能被發送：每一個消息代表在通道內的每一個鏈接的初始化和消除。只要一個單獨的鏈接能夠承載在一個給定的通道中（例如，通道模式下的第二個IP），這個屬性不需要包含在計費包中，因為通道開始屬性的存在會暗示（僅可能的）鏈接的初始化。
如果這個值被使用，下面的屬性也應該包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
NAS—端口（5）
計費延遲時間（41）
事件時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
3．5通道鏈接停止
值
13
描述
這個值可以用來標志一個通道鏈接的結束。只有一些類型（如L2TP）支持每通道的多鏈接。例如，如果一個強迫的通道在他的生存起立要承載M個鏈接，那么2（M+1）個RADIUS機非消息可能會被發送：每一個標志一個通道結束的初始化。如果只有一個單獨的鏈接可以承載在一個給定通道上，這個屬性就不需要包含在計費包中，因為現有的通道停止屬性會暗示這個（僅可能的）鏈接的終止。
如果這個值被使用下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
NAS端口（5）
計費延遲時間（41）
計費輸入字節（42）
計費輸出字節（43）
計費通話ID（44）
計費通話時間（46）
計費輸入包（47）
計費輸出包（48）
計費終止原因（49）
計費多話路ID（51）
事件時間標簽（55）
NAS端口類型（61）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
計費通道丟包（86）
3．6通道鏈接拒絕
值
14
描述
這個值可以用來標志在一個現存通道中建立一個新鏈接被拒絕。只有一些類型（如L2TP）支持每通道的多鏈接。只要一個單獨的鏈接可以承載在一個給定通道上（如在通道模式下的IPsec），這個屬性就不需要包含在計費包中，因為在這種情況下通道拒絕屬性有著同樣的意義。
如果這個值被使用下面的屬性應該也包含在計費請求包中：
用戶名（1）
NAS—IP地址（4）
NAS—端口（5）
計費延遲時間（41）
計費終止原因（49）
事件時間標簽（55）
通道類型（64）
通道媒體類型（65）
通道客戶端（66）
通道服務器端（67）
計費通道連接（68）
4．屬性
4．1計費通道連結
描述
這個屬性指出了分配給通道話路的標示符。它應該包含在計費請求包中，這個請求包包含了計費狀態類型屬性，包括開始值，結束值或任何上面描述的值。這個屬性，連同通道客戶端和通道服務器端屬性[3]，可以用來提供一個唯一的標識一個通道話路的手段來用于審核。
下面給出了計費通道連接格式的一個概要。這些域是從左向右傳輸。
0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      類型    |    長度     |    字符 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型
    68，用于計費通道連接
長度
    〉=3
字符
    標識符的格式在字符域描述，他依賴于通道類型屬性[3]的值。例如，為了充分的標識一個L2TP通道連結，L2TP通道ID和主叫ID可能在這個域編碼。這個域嚴格的編碼是非獨立執行的。
4．2 計費通道丟包
描述
這個屬性指出在一個給定的鏈接上丟包的數目。它應該包含在計費請求包中，這個包包括了計費狀態類型屬性，包括通道鏈接停止值。
下面給出了計費通道丟包屬性格式的一個概要。這些域是從左向右傳輸的。
  0                 1             2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      類型     |    長度    |              丟包
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 丟包 (計數)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型
86，用于計費通道丟包
長度
6
丟包
丟包域是4個字節長度域，表示在鏈接上丟失的包數。
5．屬性表
下面的表給出一個向導，其中的屬性可以在計費請求包中找到。在計費響應包中應該沒有通道屬性。

    請求         #        屬性
     0-1          64      通道類型
     0-1          65      通道媒體類型
     0-1          66      通道客戶端
     0-1          67      通道服務器端
     0-1          68      計費通道鏈接
     0            69      通道密碼
     0-1          81      通道獨立組ID
     0-1          82      通道分配ID
     0            83      通道優先選擇
     0-1          86      計費通道丟包

 下面的標定義了上表部分含義。
0 這個屬性禁止在包中出現。
0+    這個屬性的0或更多的情況可以在包中出現。
0--1   這個屬性的0或1的情況可以在包中出現。

6安全性考慮
    通過偵聽RADIUS計費包，可能給一個偷聽者機會進行被動的通道鏈接分析。
7．參考文獻

   [1]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

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

   [3]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
        I.  Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
        2868, June 2000.

   [4]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B.  Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
        August 1999.

   [5]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
        G.  Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
        July 1999.
8．感謝
    感謝Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall輸入校對。
9．作者地址
Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, Washington 98004
   USA

   Phone: +1 425 438 8218
   FAX:   +1 425 438 1848
   EMail: gwz@cisco.com

   Dave Mitton
   Nortel Networks
   880 Technology Park Drive
   Billerica, MA 01821

   Phone: +1 978 288 4570
   Fax:   +1 978 288 3030
   EMail: dmitton@nortelnetworks.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone: +1 425 936 6605
   Fax:   +1 425 936 7329
   EMail: aboba@internaut.com
10．全部版權聲明
Copyright (C) The Internet Society (2000).  All Rights Reserved.
    這份文檔極其譯文可以拷貝及提供給他人，對它的延伸，解釋，或幫助它的執行，都可以部分或全部的準備、拷貝、印刷出版以及傳播，沒有任何的限制，只要以上的版權聲明和這一段話包括在這些拷貝及延伸上。可是，這個文檔本身不可以以任何形式修改，如去掉版權注意或者是互聯網組織的參考書目，或是其他組織的參考文獻，除非是發展互聯網標準目的需要，在這種情況下，互聯網標準的處理程序中的版權說明必須要有，或者按照要求把它翻譯成英語以外的語言。
以上有限制的給以許可是永久的而且不能被互聯網組織及其繼承者撤銷或分配。
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.
致謝
Funding for the RFC