?????????????????????????? RADIUS Accounting
備忘錄狀態
?? 本文不是在制定一個Internet標準，只是向互聯網社區提供相關信息，本文可以不受限制地傳播。
版權說明
?? Copyright (C) The Internet Society (2000).? All Rights Reserved.

摘要
?? 本文描述了一個在網絡接入服務器（Network Access Server）和共享的計費服務器之間傳送計費信息的協議。

實現本協議的注意事項
?? 本備忘錄說明了RADIUS計費協議。早期開發的RADIUS記帳協議使用的是端口號為1646的UDP端口，但由于它和著名的"sa-msg-port"服務互相沖突。所以官方分配的RADIUS計費端口修改為1813。

目錄
?? 1.???? 簡介 ............................................??? 2
???? 1.1??? 描述文檔的約定 ........................??? 3
???? 1.2??? 術語 ..........................................??? 3
?? 2.???? 操作 ............................................??? 4
???? 2.1??? Proxy(代理) ...................................??? 4
?? 3.???? 報文格式 ........................................??? 5
?? 4.???? 報文類型 ........................................??? 7
???? 4.1??? Accounting-Request(計費請求) .......??? 8
???? 4.2??? Accounting-Response(計費回應) .....??? 9
?? 5.???? Attributes(屬性) ................................?? 10
???? 5.1??? Acct-Status-Type ............................?? 12
???? 5.2??? Acct-Delay-Time .............................?? 13
???? 5.3??? Acct-Input-Octets ...........................??? 14
???? 5.4??? Acct-Output-Octets ..........................?? 15
???? 5.5??? Acct-Session-Id ...............................?? 15
Rigney?????????????????????? Informational????????????????????? [Page 1]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

???? 5.6??? Acct-Authentic ................................?? 16
???? 5.7??? Acct-Session-Time ..........................?? 17
???? 5.8??? Acct-Input-Packets .........................?? 18
???? 5.9??? Acct-Output-Packets .......................?? 18
???? 5.10?? Acct-Terminate-Cause ....................?? 19
???? 5.11?? Acct-Multi-Session-Id ....................?? 21
???? 5.12?? Acct-Link-Count ...........................?? 22
???? 5.13?? 屬性列表 ....................................?? 23
?? 6.???? IANA事項 .....................................?? 25
?? 7.???? 安全事項 .......................................?? 25
?? 8.???? 更改記錄 .......................................?? 25
?? 9.???? 參考文獻 .......................................?? 26
?? 10.??? 致謝 .............................................?? 26
?? 11.??? AAA工作組主席地址 .....................?? 26
?? 12.??? 作者地址 .........................................?? 27
?? 13.??? 版權聲明 .........................................?? 28
1.? 簡介
?? 要經營為眾多的用戶提供的串口線路和modem池，這會帶來巨大的管理支持方面的需求。由于modem池是通向外部的鏈路，因此它對安全、認證、計費都提出了很高的要求。可以通過維護一個用戶數據庫來實現該需求，該數據庫包含了認證（驗證用戶的名字和密碼）以及為用戶提供的服務類型的詳細的配置信息（如SLIP,PPP,telnet,rlogin等）。
?? RADIUS(遠程用戶撥號認證系統)文檔[2]詳細說明了RADIUS協議中認證和授權的相關內容。本文擴展了RADIUS協議的應用，使其覆蓋了從NAS（Network Access Server）給RADIUS服務器傳遞計費信息的應用。本文廢棄了RFC 2139 [1]。它與RFC 2139之間的差別可以在附錄“更改記錄”中找到。

?? RADIUS計費協議的主要特性：
????? 客戶/服務器模式網絡接入服務器(NAS)是RADIUS計費服務器的客戶端。客戶端負責將用戶的計費信息傳遞給指定的RADIUS計費服務器。

Rigney?????????????????????? Informational????????????????????? [Page 2]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

????????? RADIUS計費服務器負責接收計費請求，并給客戶端返回一個回應信息，表示成功接收到了計費請求。
?????????
????????? RADIUS計費服務器也可以作為其他類型的計費服務器的代理。網絡安全客戶端與RADIUS計費服務器之間的交互是通過共享密鑰來進行相互認證的，共享密鑰不會通過網絡傳送。

????? 協議擴充性所有的報文交互都是由多個不同長度的屬性-長度-值三元組（Attribute-Length-Value 3-tuples）構成的。新的屬性值的加入不會影響到原有協議的實現。
1.1.? 描述文檔的約定
?? 本文中的關鍵詞"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及"OPTIONAL"的參見RFC 2119 [3]中的描述。這些關鍵詞意義與其是否大寫無關。

1.2.? 術語
?? 本文使用了以下的術語：
?? 服務????? NAS為撥入用戶提供的某種服務，如：PPP或者Telnet。
?? 會話????? NAS為撥入用戶提供的每一個服務都會建立一個會話。第一次開始提供服務做為會話的開始，服務終止做為會話的結束。如果NAS支持的話，一個用戶可以有多個并行或者串行的會話。對于每一個會話，都會產生一個獨立的計費開始和計費結束記錄，它們以不同的Acct-Session-ID屬性值區分。靜默丟棄
???????????? 應用程序不對包進行任何處理就直接丟棄。應用程序應該（SHOULD）有提供記錄錯誤的能力，其中包括被靜默丟棄的包的內容，而且應用程序應該（SHOULD）在一個統計計數器中記錄下該事件。
Rigney?????????????????????? Informational????????????????????? [Page 3]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

2.? 操作
?? 當一個客戶端被配置成采用RADIUS計費協議時，在開始提供服務的時候它會生成一個計費開始報文，報文描述了服務類型以及被服務的用戶的信息，該報文被發送到RADIUS計費服務器。計費服務器會返回應答，表示計費報文已經收到。服務終止時，客戶端會產生一個計費結束報文，該報文描述了服務類型以及一些可選的統計數據，譬如，服務總時長、輸入和輸出的字節數或者輸入和輸出報文數。該報文被發送到RADIUS計費服務器，計費服務器會返回應答，表示計費報文已經收到。
?? 計費請求（不管是計費開始報文還是計費結束報文）通過網絡發送給RADIUS計費服務器。本文推薦客戶端應該反復發送計費請求，直到收到回應消息為止。如果在一段時間內沒有收到回應消息，計費請求就會被重發幾次。如果主服務器宕機或者是無法到達，客戶端也可以向備用服務器轉發計費請求消息，可以在對主服務器重試失敗一定的次數之后客戶端將計費消息轉發到備用服務器上，也可以采用循環方式將計費消息轉發到備用服務器上。重試和放棄算法是目前正在研究的一個課題，在本文中就不再贅述了。
?? RADIUS計費服務器可以（MAY）向其他的服務器發送計費請求，這時該RADIUS服務器是一個客戶端。
?? 如果RADIUS計費服務器不能成功的記錄計費報文，服務器一定不能（MUST NOT）給客戶端發送計費回應報文。

2.1.? 代理
?? 參閱“RADIUS” RFC [2]中關于代理RADIUS的描述，代理RADIUS計費服務器的工作方式與代理RADIUS服務器是相同的，如下例所示：

?? 1.??? NAS向轉發服務器發送計費請求。
?? 2.??? 轉發服務器將計費請求記錄下來（如果必要的話），在所有其它的Proxy-State屬性之后添加自己的Proxy-State屬性（如果必要的話），并且更新請求Authenticator（認證字），然后將計費請求轉發給遠程服務器。

Rigney?????????????????????? Informational????????????????????? [Page 4]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? 3.??? 遠程服務器將計費請求記錄下（如果必要的話），將所有的Proxy-State屬性按順序原封不動的從請求數據報文復制到回應報文中，然后將計費回應報文發送給轉發服務器。
?
?? 4.??? 轉發服務器剝離最后一個Proxy-State屬性（如果在第2步添加了的話），更新回應Authenticator（認證字），然后將計費回應報文發送給NAS。
?? 轉發服務器一定不能（MUST not）更改當前報文中已經存在的Proxy-State或者Class屬性。
?? 轉發服務器可以（MAY）以通過（pass through）方式實現轉發功能，這樣，轉發服務器只要收到重發報文就將該報文轉發；或者轉發服務器可以（MAY）自身實現重發功能，例如：在轉發服務器和遠程服務器之間的網絡鏈路與NAS和轉發服務器之間的鏈路相比有很大不同的情況下。
?? 當代理服務器實現重發功能的時候，要特別的注意確保重發算法是健壯的和可擴展的。

3.? 報文格式
?? 準確地講，RADIUS計費報文被封裝在UDP報文的數據域[4]，它的UDP目的端口號是1813（十進制數）。

?? 當產生一個回應的時候，源端口和目的端口互換。

?? 本文定義了RADIUS計費協議。早期的RADIUS計費協議使用UDP端口1646，由于它和著名的"sa-msg-port"服務相沖突。官方為RADIUS計費協議重新分配的端口號是1813。

?? RADIUS報文格式如下所示。各個域的數據是從左向右傳輸的。
Rigney?????????????????????? Informational????????????????????? [Page 5]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Code????? |? Identifier?? |??????????? Length???????????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |?????????????????????????????????????????????????????????????? |
?? |???????????????????????? Authenticator???????????????????????? |
?? |?????????????????????????????????????????????????????????????? |
?? |?????????????????????????????????????????????????????????????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |? Attributes ...
?? +-+-+-+-+-+-+-+-+-+-+-+-+-

?? Code(代碼)??????????????????????????????????????????????????????????? --------????????
????? Code域占位一個字節，它用來標識RADIUS報文類型。當收到的報文Code域非法時，該報文將會被靜默丟棄。
????? RADIUS計費報文Code域（十進制）分配如下：
?????????? 4????? 計費請求
?????????? 5????? 計費回應

?? Identifier（標識符）
????? Identifier域占位一個字節，用于匹配請求和回應報文。如果在一個很短的時間內接收到相同的源IP地址、源UDP端口號和相同的Identifier域的請求報文，RADIUS服務器就可以認為是重復的請求報文。

?? Length（長度）
????? Length域占位兩個字節。它包含了報文中的Code域，Identifier域，Length域，Authenticator域和屬性域的總長度。在長度域限定的范圍之外的字節必須（MUST）作為填充字節，在接收時不予處理。如果包的實際長度小于長度域中給出的值，該包必須（MUST）被靜默丟棄。報文的最小長度是20，最大長度是4095。
?? Authenticator（認證字）
????? Authenticator域占位16個字節。最重要的字節先傳輸。該域的值用來鑒別客戶端和RADIUS計費服務器之間的消息。

Rigney?????????????????????? Informational????????????????????? [Page 6]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? Request Authenticator（請求認證字）
????? 在計費請求報文中，認證字的值是一個占位16個字節的MD5 [5]校驗和，稱作請求認證字。
????? NAS和RADIUS計費服務器共享一個密鑰。計費請求報文中的認證字中包含對一個由Code+Identifier+Length+16個值為0的字節+請求屬性+共享密鑰（+表示將各個字符連接起來）所構成的字節流進行某種方式的MD5哈希計算得出的16個字節的hash值。這個占位16個字節的MD5哈希值被存儲到計費請求包的Authenticator域中。
????? 注意計費請求中的請求認證字不得與RADIUS接入請求的請求認證字的生成方式相同，因為在計費請求中沒有User-Password屬性。
?? Response Authenticator（回應認證字）
????? 在計費回應報文中的Authenticator域稱作回應認證字。它包含對一個由計費回應Code+Identifier+Length+對應的計費請求包的請求認證字+回應屬性（如果有的話）+共享密鑰構成的字節流進行某種方式的MD5哈希計算得出的16個字節的hash值。這個占位16個字節的MD5哈希值被存儲到計費回應報文的Authenticator域中。

?? 屬性
?? 屬性可以（may）包含多個實例，在這種情況下，同種類型的各個屬性應當（SHOULD）有一定的順序。但是，不同類型的各個屬性不需要有順序。

4.? 報文類型
?? RADIUS報文類型是由位于報文的第一個字節的Code域決定的。
Rigney?????????????????????? Informational????????????????????? [Page 7]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

4.1.? 計費請求
?? 描述
????? 計費請求報文是由客戶端（典型的情況是NAS或者代理服務器）發送到RADIUS計費服務器的，其中包含為用戶提供服務的計費的信息。客戶端發送一個Code域值為4（計費請求）的RADIUS數據報文。
????? 一旦接收到計費請求報文，如果服務器能夠成功地記錄下計費報文的話，必須（MUST）回應一個計費回應報文，但如果記錄計費報文失敗，則不能（MUST NOT）回應計費回應報文。
????? 除了User-Password, CHAP-Password, Reply-Message, State屬性外（MUST NOT），其它在接入請求和接入成功回應報文中有效的屬性，在計費請求報文中同樣有效。在RADIUS計費請求報文中必須（MUST）包含NAS-IP-Address或者NAS-Identifer屬性。在計費請求報文中還應當（SHOULD）包含NAS-port或者NAS-Port-Type屬性，或者兩者都包含，除非服務不涉及端口或者NAS不區分端口。

????? 如果計費請求報文包含Framed-IP-Address屬性，則該屬性必須（MUST）是用戶IP地址。如果接入成功回應報文中包含了有具體值的Framed-IP-Address屬性，告訴NAS需要給用戶分配或者與用戶協商一個IP地址，則計費請求報文中的Framed-IP-Address屬性（如果有的話）必須是分配的或者協商的實際的IP地址。
?? 計費請求報文格式如下所示。
?? 各個域是自左向右傳輸的。
??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Code????? |? Identifier?? |??????????? Length???????????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |?????????????????????????????????????????????????????????????? |
?? |???????????????????? Request Authenticator???????????????????? |
?? |?????????????????????????????????????????????????????????????? |
?? |?????????????????????????????????????????????????????????????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |? Attributes ...
?? +-+-+-+-+-+-+-+-+-+-+-+-+-

Rigney?????????????????????? Informational????????????????????? [Page 8]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? Code（代碼）
????? 4 代表計費請求報文
?? Identifier（標識符）
????? 當屬性域的內容發生改變或者是已經收到前一個請求的有效的回應，Identifier域必須（MUST）改變。如果僅僅是由于重傳而內容沒有變化時，標識符必須（MUST）保持不變。
????? 需要指出的是，如果計費請求報文中包含了Acct-Delay-Time屬性，則當該報文重傳時，Acct-Delay-Time屬性值將被更新，這導致了屬性域內容發生變化，這時需要一個新的Identifier域和Request Authenticator域。

?? Request Authenticator（請求認證字）
????? 計費請求報文的請求認證字是一個占位16個字節的MD5哈希值，該值的計算
????? 方法已在上述的“Request Authenticator”中描述了。

?? Attributes（屬性）
????? 屬性域的長度是變化的，其中包含著一系列的屬性。

4.2.? 計費回應
?? 描述
????? 計費回應報文是由RADIUS計費服務器發送給客戶端的，用來通知客戶端計費請求報文已接收到，并且成功地記錄下來了。如果計費請求報文被成功地記錄下來，RADIUS計費服務器必須（MUST）發送一個Code域值為5（計費回應）的報文。客戶端收到計費回應報文后，其Identifier域需要能夠和一個等待回應的計費請求報文的Identifier域相匹配。回應認證字域必須（MUST）含有對等待回應的的計費請求的正確響應，而無效的數據包會被靜默丟棄。
????? RADIUS計費回應報文不要求包含屬性。

?? 計費回應報文格式如下所示。各個域是自左向右傳輸的。
Rigney?????????????????????? Informational????????????????????? [Page 9]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Code????? |? Identifier?? |??????????? Length???????????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |?????????????????????????????????????????????????????????????? |
?? |???????????????????? Response Authenticator??????????????????? |
?? |?????????????????????????????????????????????????????????????? |
?? |?????????????????????????????????????????????????????????????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |? Attributes ...
?? +-+-+-+-+-+-+-+-+-+-+-+-+-
?? Code（代碼）
????? 5 代表計費回應
?? Identifier（標識符）
????? Identifier域是對引起這次回應的計費請求的Identifier域的一個拷貝。

?? Response Authenticator（回應認證字）
????? 計費回應報文的Response Authenticator域是一個占位16個字節的MD5哈希值，該值的計算方法已在上述的“Response Authenticator”中描述了。

?? Attributes（屬性）
????? Attributes域的長度是變化的，其中包含了零個或者多個屬性。

5.? 屬性
?? RADIUS屬性通過請求報文和回應報文攜帶了關于的認證、授權和計費方面的信息細節。
?? 有些屬性可以（MAY）被多次包含。這通常有特別的目的，這種情況都會在每個屬性的描述中特別指出。
?? 是由RADIUS報文的Length域來決定屬性列表在何處結束。
?? 屬性域的格式如下所示。是自左向右傳輸的。
Rigney?????????????????????? Informational???????????????????? [Page 10]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |? Value ...
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?? Type（類型）
????? Type占位一個字節。到目前為止，在最新的“Assigned Number” RFC [6]中給出了RADIUS Type的值的詳細描述。值192-223是保留給實驗用的，值224-240是保留給特定實現用的，值241-255是預留的，而且不應該（should not）使用它們。本文中涉及到以下的Type值：
?????????? 1-39? （參見RADIUS文檔 [2]）
????????? 40????? Acct-Status-Type
????????? 41????? Acct-Delay-Time
????????? 42????? Acct-Input-Octets
????????? 43????? Acct-Output-Octets
????????? 44????? Acct-Session-Id
????????? 45????? Acct-Authentic
????????? 46????? Acct-Session-Time
????????? 47????? Acct-Input-Packets
????????? 48????? Acct-Output-Packets
????????? 49????? Acct-Terminate-Cause
????????? 50????? Acct-Multi-Session-Id
????????? 51????? Acct-Link-Count
????????? 60+ （參考RADIUS文檔 [2]）
????????

?? Length（長度）
????? Length域占位一個字節，表示包括Type、Length、Value域在內的屬性的長度。如果接受到的計費請求報文中的屬性長度無效，整個請求報文必須（MUST）靜默丟棄。

?? Value（值）
????? Value域占位零個或者更多字節，包含屬性信息的詳細描述。值域的格式和長度是由屬性的類型和長度決定的。
????? 需要指出的是，在RADIUS中沒有任何類型的屬性值是以NUL（十六進制的0x00）結束的。譬如，“text”和“string"類型的屬性值是不能以NUL結束。由于屬性具有長度域，因而不必使用結束符。“text”類型的屬性值包含UTF-8編碼的10646 [7]字符，而“string”類型的屬性值含有8位二進制

Rigney?????????????????????? Informational???????????????????? [Page 11]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

????? 數據。服務器和客戶端必須（MUST）能夠處理嵌入的null。使用C語言實現的RADIUS在處理字符串時需要注意不能使用strcpy()函數。
????? 值域有五種數據類型。注意：類型“text”是類型“string"的一個子集。
????? text???? 1-253個字節，包含UTF-8編碼的10646 [7]字符。長度為零的text類型的屬性不能（MUST NOT）被發送，而應該將整個屬性忽略。
????? string?? 1-253個字節，包含二進制數據（值從0到255，十進制）。長度為零的string類型的屬性不能（MUST NOT）發送，而應該將整個屬性忽略。
????? address? 32位的數值，最重要的字節優先傳輸。
????? integer? 32位的無符號數，最重要的字節優先傳輸。
????? time???? 32位的無符號數，最重要的字節優先。從格林威治時間1970年1月1日0時0分0秒時起的秒數。標準的屬性是不使用該數據類型的，在這里提到該數據類型主要是有可能在將來的屬性中使用。

5.1.? Acct-Status-Type
?? 描述
????? 該屬性表明當前的計費請求報文是表示用戶服務開始(Start)還是結束（Stop）。
????? 它可能（MAY）被客戶端通過指定計費開始（標志）的方式來表示開始計費（例如：在啟動的時候），或者通過指定計費結束（標志）的方式來表示結束計費（例如：在預定的重啟之前）。

?? Acct-Status-Type屬性的格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rigney?????????????????????? Informational???????????????????? [Page 12]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? Type（類型）
????? 40 表示Acct-Status-Type
?? Length（長度）
????? 6
?? Value（值）
????? 值域占位四個字節。
?????? 1????? Start（計費開始）
?????? 2????? Stop（計費結束）
?????? 3????? Interim-Update（計費更新）
?????? 7????? Accounting-On（計費開始）
?????? 8????? Accounting-Off（計費開始）
?????? 9-14?? Reserved for Tunnel Accounting（為隧道計費保留）
????? 15????? Reserved for Failed（為計費失敗保留）
5.2.? Acct-Delay-Time
?? 描述
????? 該屬性表明客戶端試圖發送該報文所延誤的秒數。用該報文到達服務器端的時間減去Acct-Delay-Time就可以知道生成該報文的大概時間（忽略網絡傳輸時間）。
????? 注意，Acct-Delay-Time的改變會引起Identifier域的變化，參見上面關于Identifier章節的討論。
?? Acct-Delay-Time屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rigney?????????????????????? Informational???????????????????? [Page 13]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? 類型
????? 41 代表Acct-Delay-Time
?? 長度
????? 6
?? 值
????? 值域占位四個字節
5.3.? Acct-Input-Octets
?? 描述
????? 該屬性表明在提供服務的過程中用戶從端口接收到的字節總數。該屬性只有在計費結束請求報文中出現。
?? Acct-Input-Octets屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 42 代表Acct-Input-Octets
?? 長度
????? 6
?? 值
????? 值域占位四個字節

Rigney?????????????????????? Informational???????????????????? [Page 14]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

5.4.? Acct-Output-Octets
?? 描述
????? 該屬性表明在提供服務的過程中用戶發送到端口的字節總數。該屬性只有在計費結束請求報文中出現。
?? Acct-Output-Octets屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 43 代表Acct-Output-Octets
?? 長度
????? 6
?? 值
????? 值域占位四個字節
5.5.? Acct-Session-Id
?? 描述
????? 該屬性是便于在日志文件中匹配計費開始和計費結束記錄的唯一的計費ID。對于一個給定的會話，計費開始和計費結束記錄必須（MUST）有相同的Acct-Session-Id。計費請求報文必須（MUST）有一個Acct-Session-Id。接入請求報文可以（MAY）包含有Acct-Session-Id，如果接入請求報文中包含Acct-Session-Id的話，在同一個會話中，NAS在計費請求報文中必須使用相同的Acct-Session-Id。
????? Acct-Session-Id應當（SHOULD）是一個含有UTF-8編碼的10646 [7]字符的字符串。

Rigney?????????????????????? Informational???????????????????? [Page 15]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

????? 例如：有一種實現方式是使用一個8個數字的大寫16進制數，該數的前兩位每次重新啟動后加1（重啟256次之后循環），后六位數字從0到2^24-1，大約一千六百萬個，用來計數重啟之后登錄的用戶的個數。當然其它編碼方式也可以采用。

?? Acct-Session-Id屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |? Text ...
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 44 代表Acct-Session-Id
?? 長度
????? >=3
?? 字符串
????? 字符串域應當（SHOULD）是一個含有UTF-8編碼的10646 [7]字符的字符
????? 串。
5.6.? Acct-Authentic
?? 描述
????? 該屬性可以（MAY）包含在計費請求報文中，用來說明用戶的認證方式，是RADIUS認證、NAS本地認證或者通過其它遠程認證協議認證。如果一個用戶不需要認證就能夠使用服務，就不應該（SHOULD NOT）生成計費記錄。
????? Acct-Authentic屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rigney?????????????????????? Informational???????????????????? [Page 16]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? 類型
????? 45 表示Acct-Authentic
?? 長度
????? 6
?? 值
????? 值域占位四個字節
????? 1????? RADIUS
????? 2????? Local
????? 3????? Remote
5.7.? Acct-Session-Time
?? 描述
????? 該屬性表明了用戶接受服務的時間。該屬性只能在計費結束報文中出現。
?? Acct-Session-Time屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 46 代表Acct-Session-Time
?? 長度
????? 6
?? 值
????? 值域占位四個字節
Rigney?????????????????????? Informational???????????????????? [Page 17]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

5.8.? Acct-Input-Packets
?? 描述
????? 該屬性表明在提供服務的過程中用戶從端口接收到的數據包總數。該屬性只有在計費結束請求報文中出現。
?? Acct-Input-Packets屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 47 代表Acct-Input-Packets
?? 長度
????? 6
?? 值
????? 值域占位四個字節
5.9.? Acct-Output-Packets
?? 描述
????? 該屬性表明在提供服務的過程中用戶發送到端口的數據包總數。該屬性只有在計費結束請求報文中出現。
?? Acct-Output-Packets屬性格式如下所示。各個域是按照自左向右的順序傳輸的。
Rigney?????????????????????? Informational???????????????????? [Page 18]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 48 代表Acct-Output-Packets
?? 長度
????? 6
?? 值
????? 值域占位四個字節

5.10.? Acct-Terminate-Cause
?? 描述
????? 該屬性表明會話如何被終止的。該屬性只有在計費結束請求報文中出現。
?? Acct-Terminate-Cause屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rigney?????????????????????? Informational???????????????????? [Page 19]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? 類型
????? 49 代表Acct-Terminate-Cause
?? 長度
????? 6
?? 值
????? 值域占位四個字節。包含一個表示計費會話終止原因的整數。對應關系如下：
????? 1?????? User Request（用戶請求）
????? 2?????? Lost Carrier
????? 3?????? Lost Service（服務丟失）
????? 4?????? Idle Timeout（閑置超時）
????? 5?????? Session Timeout（會話超時）
????? 6?????? Admin Reset（管理員重置）
????? 7?????? Admin Reboot（管理員重啟）
????? 8?????? Port Error（端口錯誤）
????? 9?????? NAS Error（NAS錯誤）
????? 10????? NAS Request（NAS請求）
????? 11????? NAS Reboot（NAS重啟）
????? 12????? Port Unneeded（端口不再需要）
????? 13????? Port Preempted（端口被搶占）
????? 14????? Port Suspended（端口掛起）
????? 15????? Service Unavailable（服務無法獲得）
????? 16????? Callback（回調）
????? 17????? User Error（用戶錯誤）
????? 18????? Host Request（主機請求）
????? 會話終止原因如下：
????? User Request???????? 用戶請求終止該項服務。例如：LCP終端或者用戶退出。
????? Lost Carrier???????? DCD在端口處掉線。
????? Lost Service???????? 無法再提供服務；例如：用戶與主機之間的連接中斷。
????? Idle Timeout???????? 閑置時間超時
????? Session Timeout????? 最大會話時長超時
????? Admin Reset????????? 管理員重置端口或者會話
Rigney?????????????????????? Informational???????????????????? [Page 20]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

????? Admin Reboot???????? 管理員終止在NAS上的服務，例如：在重新啟動NAS之前。
????? Port Error?????????? 由于NAS在端口上檢測到錯誤，所以要求中止會話。
????? NAS Error??????????? 由于NAS檢測到了錯誤（除了端口錯誤），所以要求終止會話。
????? NAS Request????????? NAS不是由于故障而要求中止會話，具體原因不在這里另外列舉。
????? NAS Reboot?????????? NAS終止會話，以進行非管理性的重啟（系統崩潰）。
????? Port Unneeded??????? 由于資源使用量低于最低水平線，NAS終止會話（例如：bandwidth-on-demand算法判定已經不再需要該端口了）。
????? Port Preempted?????? NAS終止會話以將端口分配給更高的優先級（服務）使用。
????? Port Suspended?????? NAS終止對話以掛起一個虛擬會話。
????? Service Unavailable? NAS無法提供要求的服務。
????? Callback???????????? 為了為新的會話執行回調操作，NAS終止當前的會話。
????? User Error?????????? 用戶的輸入有錯誤，導致中止會話。
????? Host Request???????? 登錄的主機正常終止會話。
5.11. Acct-Multi-Session-Id
?? 描述
????? 該屬性做為一個唯一計費會話ID，通過該ID能夠很容易將多個相互關聯的會話
????? 在日志文件中聯系起來。被關聯的每個會話都有各自唯一的
????? Acct-Session-Id，但它們有相同的Acct-Multi-Session-Id。強烈建議
????? （recommended）Acct-Multi-Session-Id包含UTF-8編碼的10646 [7]字
????? 符。
?? Acct-Multi-Session-Id屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

Rigney?????????????????????? Informational???????????????????? [Page 21]

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |? String ...
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? 類型
????? 50 代表Acct-Multi-Session-Id
?? 長度
????? >=3
?? 字符串
????? 字符串域應當（SHOULD）是一個含有UTF-8編碼的10646 [7]字符的字符串。
5.12.? Acct-Link-Count
?? 描述
????? 該屬性給出計費記錄生成時該多鏈路會話的已經知道的鏈路個數。NAS在所有可能含有多條鏈路的計費請求報文中都可以（MAY）包含Acct-Link-Count屬性。
?? Acct-Link-Count屬性格式如下所示。各個域是按照自左向右的順序傳輸的。

??? 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
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
?? |???? Type????? |??? Length???? |???????????? Value
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
????????????? Value (cont)???????? |
?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rigney?????????????????????? Informational???????????????????? [Page 22]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

?? 類型
????? 51 代表Acct-Link-Count
?? 長度
????? 6
?? 值
????? 值域占位四個字節。表示在本多鏈路會話中目前所知道的鏈路的數目。
????? 它可以用來使計費服務器知道到何時為止給定的多鏈路會話的所有記錄都已經接收到了。當計費服務器收到具有相同的Acct-Multi-Session-Id屬性和唯一Acct-Session-Id屬性的計費結束請求報文個數等于所有這些計費結束請求報文中Acct-Link-Count屬性的最大值時，表示該多鏈路會話的所有計費結束請求報文都已經收到了。
????? 為了便于理解，下面給出一個8個計費請求報文的例子。為了清楚起見，只給出了相關的屬性，但是其他包含計費信息的屬性也是在計費請求中存在的。
????? Multi-Session-Id?? Session-Id?? Status-Type?? Link-Count
????? "10"?????????????? "10"???????? Start???????? 1
????? "10"?????????????? "11"???????? Start???????? 2
????? "10"?????????????? "11"???????? Stop????????? 2
????? "10"?????????????? "12"???????? Start???????? 3
????? "10"?????????????? "13"???????? Start???????? 4
????? "10"?????????????? "12"???????? Stop????????? 4
????? "10"?????????????? "13"???????? Stop????????? 4
????? "10"?????????????? "10"???????? Stop????????? 4

5.13.? 屬性列表
?? 下表中給出了計費請求報文中可能會包含的屬性。除了Proxy-State屬性以及（可能的）廠商自定義的屬性之外，計費回應報文不應該包含其它屬性。

????????????????????? #???? Attribute
????????????????????? 0-1?? User-Name
????????????????????? 0???? User-Password
????????????????????? 0???? CHAP-Password
Rigney?????????????????????? Informational???????????????????? [Page 23]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

????????????????????? 0-1?? NAS-IP-Address [Note 1]
????????????????????? 0-1?? NAS-Port
????????????????????? 0-1?? Service-Type
????????????????????? 0-1?? Framed-Protocol
????????????????????? 0-1?? Framed-IP-Address
????????????????????? 0-1?? Framed-IP-Netmask
????????????????????? 0-1?? Framed-Routing
????????????????????? 0+??? Filter-Id
????????????????????? 0-1?? Framed-MTU
????????????????????? 0+??? Framed-Compression
????????????????????? 0+??? Login-IP-Host
????????????????????? 0-1?? Login-Service
????????????????????? 0-1?? Login-TCP-Port
????????????????????? 0???? Reply-Message
????????????????????? 0-1?? Callback-Number
????????????????????? 0-1?? Callback-Id
????????????????????? 0+??? Framed-Route
????????????????????? 0-1?? Framed-IPX-Network
????????????????????? 0???? State
????????????????????? 0+??? Class
????????????????????? 0+??? Vendor-Specific
????????????????????? 0-1?? Session-Timeout
????????????????????? 0-1?? Idle-Timeout
????????????????????? 0-1?? Termination-Action
????????????????????? 0-1?? Called-Station-Id
????????????????????? 0-1?? Calling-Station-Id
????????????????????? 0-1?? NAS-Identifier [Note 1]
????????????????????? 0+??? Proxy-State
????????????????????? 0-1?? Login-LAT-Service
????????????????????? 0-1?? Login-LAT-Node
????????????????????? 0-1?? Login-LAT-Group
????????????????????? 0-1?? Framed-AppleTalk-Link
????????????????????? 0-1?? Framed-AppleTalk-Network
????????????????????? 0-1?? Framed-AppleTalk-Zone
????????????????????? 1???? Acct-Status-Type
????????????????????? 0-1?? Acct-Delay-Time
????????????????????? 0-1?? Acct-Input-Octets
????????????????????? 0-1?? Acct-Output-Octets
????????????????????? 1???? Acct-Session-Id
????????????????????? 0-1?? Acct-Authentic
????????????????????? 0-1?? Acct-Session-Time
????????????????????? 0-1?? Acct-Input-Packets
????????????????????? 0-1?? Acct-Output-Packets
????????????????????? 0-1?? Acct-Terminate-Cause
????????????????????? 0+??? Acct-Multi-Session-Id
????????????????????? 0+??? Acct-Link-Count
????????????????????? 0???? CHAP-Challenge

Rigney?????????????????????? Informational???????????????????? [Page 24]

?

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

????????????????????? 0-1?? NAS-Port-Type
????????????????????? 0-1?? Port-Limit
????????????????????? 0-1?? Login-LAT-Port
?? [Note 1]計費請求報文中必須（MUST）包含NAS-IP-Address屬性或者NAS-Identifier（或者兩者都有）。
?? 下表中給出了上面的表格的說明：
????? 0???? 該屬性不能（MUST NOT）出現。
????? 0+??? 該屬性可以（MAY）出現0次或者多次。
????? 0-1?? 該屬性可以（MAY）出現0次或者1次。
????? 1???? 該屬性只能且必須（MUST）出現1次。
6.? IANA事項
?? 在本文中給出的報文類型代碼、屬性類型、屬性值的定義都已經被IANA注冊在RADIUS名稱空間，這已經在RFC 2865 [2]的“IANA事項”章節給出了詳細的描
?? 述。
7.? 安全事項
?? 安全問題已經在計費請求和計費回應中的關于認證字的章節中討論過了。它采用了一個從不在網絡上傳輸的共享密鑰。

8.? 更改記錄
?? 用UTF-8編碼代替US-ASCII編碼。
?? 增加了關于代理的注釋。
?? 要求Framed-IP-Address屬性應當（should）包含用戶的真正的IP地址。
?? 如果接入請求報文中包含了Acct-Session-ID屬性，那么也必須（must）包含在該會話的計費請求報文中。
?? 在Acct-Status-Type屬性中的添加了一些新值。
?? 增加一個IANA事項的章節。
?? 更新了參考文獻。
?? 將文本字符串定義成字符串的字集，更加明確了UTF-8編碼的使用。
Rigney?????????????????????? Informational???????????????????? [Page 25]

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

9.? 參考文獻
?? [1]? Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
?? [2]? Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
??????? Authentication Dial In User Service (RADIUS)", RFC 2865, June
??????? 2000.
?? [3]? Bradner, S., "Key words for use in RFCs to Indicate Requirement
??????? Levels", BCP 14, RFC 2119, March, 1997.
?? [4]? Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
??????? 1980.
?? [5]? Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
??????? 1321, April 1992.
?? [6]? Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
??????? October 1994.
?? [7]? Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
??????? 2279, January 1998.
?? [8]? Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
??????? Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10.? Acknowledgements
?? RADIUS and RADIUS Accounting were originally developed by Steve
?? Willens of Livingston Enterprises for their PortMaster series of
?? Network Access Servers.
11.? Chair's Address
?? The RADIUS working group can be contacted via the current chair:
?? Carl Rigney
?? Livingston Enterprises
?? 4464 Willow Road
?? Pleasanton, California? 94588
?? Phone: +1 925 737 2100
?? EMail: cdr@telemancy.com

Rigney?????????????????????? Informational???????????????????? [Page 26]

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

12.? Author's Address
?? Questions about this memo can also be directed to:
?? Carl Rigney
?? Livingston Enterprises
?? 4464 Willow Road
?? Pleasanton, California? 94588
?? EMail: cdr@telemancy.com
Rigney?????????????????????? Informational???????????????????? [Page 27]

RFC 2866?????????????????? RADIUS Accounting?????????????????? June 2000

13.? Full Copyright Statement
?? Copyright (C) The Internet Society (2000).? All Rights Reserved.
?? This document and translations of it may be copied and furnished to
?? others, and derivative works that comment on or otherwise explain it
?? or assist in its implementation may be prepared, copied, published
?? and distributed, in whole or in part, without restriction of any
?? kind, provided that the above copyright notice and this paragraph are
?? included on all such copies and derivative works.? However, this
?? document itself may not be modified in any way, such as by removing
?? the copyright notice or references to the Internet Society or other
?? Internet organizations, except as needed for the purpose of
?? developing Internet standards in which case the procedures for
?? copyrights defined in the Internet Standards process must be
?? followed, or as required to translate it into languages other than
?? English.
?? The limited permissions granted above are perpetual and will not be
?? revoked by the Internet Society or its successors or assigns.
?? This document and the information contained herein is provided on an
?? "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
?? TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
?? BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
?? HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
?? MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
?? Funding for the RFC Editor function is currently provided by the
?? Internet Society.
Rigney?????????????????????? Informational???????????????????? [Page 28]

總結

以上是生活随笔為你收集整理的RADIUS Accounting的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。