组织：中国互动出版网（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