RFC2867 日本語訳

2867 RADIUS Accounting Modifications for Tunnel Protocol Support. G.Zorn, B. Aboba, D. Mitton. June 2000. (Format: TXT=51135 bytes) (Updates RFC2866) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                            G. Zorn
Request for Comments: 2867                           Cisco Systems, Inc.
Category: Informational                                         B. Aboba
Updates: 2866                                      Microsoft Corporation
                                                               D. Mitton
                                                         Nortel Networks
                                                               June 2000

コメントを求めるワーキンググループG.ゾルン要求をネットワークでつないでください: 2867年のシスコシステムズInc.カテゴリ: 情報のB.Abobaアップデート: マイクロソフト社D.ミットンノーテルが2000年6月にネットワークでつなぐ2866

      RADIUS Accounting Modifications for Tunnel Protocol Support

トンネルプロトコルサポートのための半径会計変更

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This document defines new RADIUS accounting Attributes and new values
   for the existing Acct-Status-Type Attribute [1] designed to support
   the provision of compulsory tunneling in dial-up networks.

このドキュメントは強制的なトンネリングのダイアルアップ・ネットワークへの支給をサポートするように設計された既存のAcct状態タイプAttribute[1]のために新しいRADIUS会計Attributesと新しい値を定義します。

Specification of Requirements

要件の仕様

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [2].

そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[2]で説明されるように解釈されることになっていてください、」であるべきです

1.  Introduction

1. 序論

   Many applications of tunneling protocols such as PPTP [5] and L2TP
   [4] involve dial-up network access.  Some, such as the provision of
   secure access to corporate intranets via the Internet, are
   characterized by voluntary tunneling: the tunnel is created at the
   request of the user for a specific purpose.  Other applications
   involve compulsory tunneling: the tunnel is created without any
   action from the user and without allowing the user any choice in the
   matter, as a service of the Internet service provider (ISP).
   Typically, ISPs providing a service want to collect data regarding
   that service for billing, network planning, etc.  One way to collect
   usage data in dial-up networks is by means of RADIUS  Accounting [1].
   The use of RADIUS Accounting allows dial-up usage data to be
   collected at a central location, rather than stored on each NAS.

PPTP[5]やL2TP[4]などのトンネリングプロトコルの多くの応用がダイアルアップ・ネットワークアクセサリーにかかわります。 企業イントラネットへのインターネットを通した安全なアクセスの支給などのいくつかが自発的のトンネリングによって特徴付けられます: トンネルはユーザの依頼である特定の目的で作成されます。 他のアプリケーションは強制的なトンネリングにかかわります: トンネルはユーザからのどんな動作なしでもその件に関してどんな選択もユーザに許すことなしで作成されます、インターネット接続サービス業者(ISP)のサービスとして。 通常、サービスを提供するISPは支払いのためのそのサービス、ネットワーク計画などに関するデータを集めたがっています。 ダイアルアップ・ネットワークで用法データを集める1つの方法がRADIUS Accounting[1]によってあります。 RADIUS Accountingの使用で、ダイヤルアップ用法データは各NASに保存されるより中心の位置にむしろ集まります。

Zorn, et al.                 Informational                      [Page 1]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [1ページ]情報のRFC2867半径トンネル会計サポート2000年6月

   In order to collect usage data regarding tunneling, new RADIUS
   attributes are needed; this document defines these attributes.  In
   addition, several new values for the Acct-Status-Type attribute are
   proposed.  Specific recommendations for, and examples of, the
   application of this attribute for the L2TP protocol can be found in
   RFC 2809.

トンネリングに関する用法データを集めるために、新しいRADIUS属性が必要です。 このドキュメントはこれらの属性を定義します。 さらに、Acct状態タイプ属性のためのいくつかの新しい値が提案されます。 特定の推薦、例、RFC2809でL2TPプロトコルのためのこの属性の法則を見つけることができます。

2.  Implementation Notes

2. 実装注意

   Compulsory tunneling may be part of a package of services provided by
   one entity to another.  For example, a corporation might contract
   with an ISP to provide remote intranet access to its employees via
   compulsory tunneling.  In this case, the integration of RADIUS and
   tunnel protocols allows the ISP and the corporation to synchronize
   their accounting activities so that each side receives a record of
   the user's resource consumption.  This provides the corporation with
   the means to audit ISP bills.

強制的なトンネリングは1つの実体によって別のものに提供されたサービスのパッケージの一部であるかもしれません。 例えば、会社は、ISPで強制的なトンネリングで従業員へのリモートイントラネットアクセスを提供するのを契約するかもしれません。 この場合ISPと会社がRADIUSとトンネルプロトコルの統合で彼らの会計活動を同時にさせることができるので、それぞれの側はユーザのリソース消費に関する記録を受け取ります。 これはISP請求書を監査する手段を会社に提供します。

   In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-
   Endpoint and Tunnel-Server-Endpoint attributes are typically used to
   uniquely identify the call, allowing the Accounting-Request sent by
   the NAS to be reconciled with the corresponding Accounting-Request
   sent by the tunnel server.

監査、User-名前では、Acctは接続にトンネルを堀って、Tunnel-クライアント終点とTunnelサーバ終点属性は唯一呼び出しを特定するのに通常使用されます、NASによって送られたAccounting-要求がトンネルサーバで送られた対応するAccounting-要求と仲直りするのを許容して。

   When implementing RADIUS accounting for L2TP/PPTP tunneling, the
   Call-Serial-Number SHOULD be used in the Acct-Tunnel-Connection
   attribute.  In L2TP, the Call-Serial-Number is a 32-bit field and in
   PPTP it is a 16-bit field.  In PPTP the combination of IP Address and
   Call-Serial-Number SHOULD be unique, but this is not required.  In
   addition, no method for determining the Call-Serial-Number is
   specified, which leaves open the possibility of wrapping after a
   reboot.

RADIUSがL2TP/PPTPトンネリングのための会計、Callの連続の番号SHOULDであると実装するときには、Acctトンネル接続属性に使用されてください。 L2TPでは、Callの連続の番号は32ビットの分野です、そして、PPTPでは、それは16ビットの分野です。 ユニークであることで、これだけは必要でないというPPTP IP Addressの組み合わせとCallの連続の番号SHOULDでは、ことになってください。 さらに、Callの連続の番号を決定するためのメソッド(リブートの後にラッピングの可能性を残している)は全く指定されません。

   Note that a 16-bit Call-Serial-Number is not sufficient to
   distinguish a given call from all other calls over an extended time
   period.  For example, if the Call-Serial-Number is assigned
   monotonically, the NAS in question has 96 ports which are continually
   busy and the average call is of 20 minutes duration, then a 16-bit
   Call-Serial-Number will wrap within 65536/(96 * 3 calls/hour * 24
   hours/day) = 9.48 days.

16ビットのCall連続の番号が長時間にわたって他のすべての呼び出しと与えられた呼び出しを区別するために十分でないことに注意してください。 例えば、Callの連続の番号が単調に割り当てられるなら、問題のNASには96の絶えず忙しいポートがあります、そして、平均した呼び出しは20分の持続時間(16ビットのCall連続の番号が9.48/(24何時間もの/日96*3呼び出し/時間*)=日間65536の中で包装するその時)のものです。

3.  New Acct-Status-Type Values

3. 新しいAcct状態タイプ値

3.1.  Tunnel-Start

3.1. トンネル始め

      Value

         9

9

Zorn, et al.                 Informational                      [Page 2]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [2ページ]情報のRFC2867半径トンネル会計サポート2000年6月

      Description

記述

         This value MAY be used to mark the establishment of a tunnel
         with another node.  If this value is used, the following
         attributes SHOULD also be included in the Accounting-Request
         packet:

この値は、別のノードをトンネルの設立に付けるのに使用されるかもしれません。 この値が使用されているなら、以下はSHOULDを結果と考えます、また、Accounting-リクエスト・パケットに含まれてください、:

            User-Name (1)
            NAS-IP-Address (4)
            Acct-Delay-Time (41)
            Event-Timestamp (55)
            Tunnel-Type (64)
            Tunnel-Medium-Type (65)
            Tunnel-Client-Endpoint (66)
            Tunnel-Server-Endpoint (67)
            Acct-Tunnel-Connection (68)

トンネルの中くらいのタイプのユーザ名の(66)トンネルサーバ終点(67)Acctトンネル(1)NAS IPアドレス(4)Acct-遅延時間(41)イベントタイムスタンプ(55)トンネルタイプ(64)(65)トンネルクライアント終点接続(68)

3.2.  Tunnel-Stop

3.2. トンネル停止

      Value

         10

10

      Description

記述

         This value MAY be used to mark the destruction of a tunnel to
         or from another node.  If this value is used, the following
         attributes SHOULD also be included in the Accounting-Request
         packet:

この値は、ノードか別のノードからトンネルの破壊をマークするのに使用されるかもしれません。 この値が使用されているなら、以下はSHOULDを結果と考えます、また、Accounting-リクエスト・パケットに含まれてください、:

            User-Name (1)
            NAS-IP-Address (4)
            Acct-Delay-Time (41)
            Acct-Input-Octets (42)
            Acct-Output-Octets (43)
            Acct-Session-Id (44)
            Acct-Session-Time (46)
            Acct-Input-Packets (47)
            Acct-Output-Packets (48)
            Acct-Terminate-Cause (49)
            Acct-Multi-Session-Id (51)
            Event-Timestamp (55)
            Tunnel-Type (64)
            Tunnel-Medium-Type (65)
            Tunnel-Client-Endpoint (66)
            Tunnel-Server-Endpoint (67)
            Acct-Tunnel-Connection (68)
            Acct-Tunnel-Packets-Lost (86)

失われたAcctが原因を終えているトンネルの中くらいのタイプのユーザ名の(67)Acctトンネル接続(68)Acctトンネル(1)NAS IPアドレス(4)Acct-遅延時間(41)Acct入力八重奏(42)Acct出力八重奏(43)Acctセッションイド(44)Acctセッション時間(46)Acct-入力パケット(47)Acct-出力パケット(48)(49)Acctマルチセッションイド(51)イベントタイムスタンプ(55)トンネルタイプ(64)(65)トンネルクライアント終点(66)トンネルサーバ終点パケット(86)

Zorn, et al.                 Informational                      [Page 3]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [3ページ]情報のRFC2867半径トンネル会計サポート2000年6月

3.3.  Tunnel-Reject

3.3. トンネル廃棄物

      Value

         11

11

      Description

記述

         This value MAY be used to mark the rejection of the
         establishment of a tunnel with another node.  If this value is
         used, the following attributes SHOULD also be included in the
         Accounting-Request packet:

この値は、別のノードによるトンネルの設立の拒絶をマークするのに使用されるかもしれません。 この値が使用されているなら、以下はSHOULDを結果と考えます、また、Accounting-リクエスト・パケットに含まれてください、:

            User-Name (1)
            NAS-IP-Address (4)
            Acct-Delay-Time (41)
            Acct-Terminate-Cause (49)
            Event-Timestamp (55)
            Tunnel-Type (64)
            Tunnel-Medium-Type (65)
            Tunnel-Client-Endpoint (66)
            Tunnel-Server-Endpoint (67)
            Acct-Tunnel-Connection (68)

Acctが原因を終えているトンネルの中くらいのタイプのユーザ名の(66)トンネルサーバ終点(67)Acctトンネル(1)NAS IPアドレス(4)Acct-遅延時間(41)(49)イベントタイムスタンプ(55)トンネルタイプ(64)(65)トンネルクライアント終点接続(68)

3.4.  Tunnel-Link-Start

3.4. トンネルリンク始め

      Value

         12

12

      Description

記述

         This value MAY be used to mark the creation of a tunnel link.
         Only some tunnel types (e.g., L2TP) support multiple links per
         tunnel.  This Attribute is intended to mark the creation of a
         link within a tunnel that carries multiple links.  For example,
         if a mandatory tunnel were to carry M links over its lifetime,
         2(M+1) RADIUS Accounting messages might be sent: one each
         marking the initiation and destruction of the tunnel itself and
         one each for the initiation and destruction of each link within
         the tunnel.  If only a single link can be carried in a given
         tunnel (e.g., IPsec in the tunnel mode), this Attribute need
         not be included in accounting packets, since the presence of
         the Tunnel-Start Attribute will imply the initiation of the
         (only possible) link.

この値は、トンネルのリンクの作成をマークするのに使用されるかもしれません。 トンネルタイプ(例えば、L2TP)の中には複数の1トンネルあたりのリンクを支える人もいます。 このAttributeが複数のリンクを運ぶトンネルの中でリンクの作成をマークすることを意図します。 例えば、義務的なトンネルが運ばれるつもりであったなら、Mは一生のうちにリンクされます、メッセージが送られるかもしれない2(M+1)RADIUS Accounting: トンネルの中のそれぞれのリンクの開始と破壊のためにそれぞれトンネル自体とそれぞれ1の開始と破壊をマークする1つ。 与えられたトンネル(例えば、トンネルモードによるIPsec)で単一のリンクしか運ぶことができないなら、このAttributeは会計パケットに含まれる必要はありません、Tunnel-スタートAttributeの存在が(可能だけの)のリンクの開始を含意するので。

Zorn, et al.                 Informational                      [Page 4]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [4ページ]情報のRFC2867半径トンネル会計サポート2000年6月

         If this value is used, the following attributes SHOULD also be
         included in the Accounting-Request packet:

この値が使用されているなら、以下はSHOULDを結果と考えます、また、Accounting-リクエスト・パケットに含まれてください、:

            User-Name (1)
            NAS-IP-Address (4)
            NAS-Port (5)
            Acct-Delay-Time (41)
            Event-Timestamp (55)
            Tunnel-Type (64)
            Tunnel-Medium-Type (65)
            Tunnel-Client-Endpoint (66)
            Tunnel-Server-Endpoint (67)
            Acct-Tunnel-Connection (68)

トンネルの中くらいのタイプのユーザ名の(66)トンネルサーバ終点(67)Acctトンネル(1)NAS IPアドレス(4)NAS-ポート(5)Acct-遅延時間(41)イベントタイムスタンプ(55)トンネルタイプ(64)(65)トンネルクライアント終点接続(68)

3.5.  Tunnel-Link-Stop

3.5. トンネルリンク停止

      Value

         13

13

      Description

記述

         This value MAY be used to mark the destruction of a tunnel
         link.  Only some tunnel types (e.g., L2TP) support multiple
         links per tunnel.  This Attribute is intended to mark the
         destruction of a link within a tunnel that carries multiple
         links.  For example, if a mandatory tunnel were to carry M
         links over its lifetime, 2(M+1) RADIUS Accounting messages
         might be sent: one each marking the initiation and destruction
         of the tunnel itself and one each for the initiation and
         destruction of each link within the tunnel.  If only a single
         link can be carried in a given tunnel (e.g., IPsec in the
         tunnel mode), this Attribute need not be included in accounting
         packets, since the presence of the Tunnel-Stop Attribute will
         imply the termination of the (only possible) link.

この値は、トンネルのリンクの破壊をマークするのに使用されるかもしれません。 トンネルタイプ(例えば、L2TP)の中には複数の1トンネルあたりのリンクを支える人もいます。 このAttributeが複数のリンクを運ぶトンネルの中でリンクの破壊をマークすることを意図します。 例えば、義務的なトンネルが運ばれるつもりであったなら、Mは一生のうちにリンクされます、メッセージが送られるかもしれない2(M+1)RADIUS Accounting: トンネルの中のそれぞれのリンクの開始と破壊のためにそれぞれトンネル自体とそれぞれ1の開始と破壊をマークする1つ。 与えられたトンネル(例えば、トンネルモードによるIPsec)で単一のリンクしか運ぶことができないなら、このAttributeは会計パケットに含まれる必要はありません、Tunnel-停止Attributeの存在が(可能だけの)のリンクの終了を含意するので。

         If this value is used, the following attributes SHOULD also be
         included in the Accounting-Request packet:

この値が使用されているなら、以下はSHOULDを結果と考えます、また、Accounting-リクエスト・パケットに含まれてください、:

            User-Name (1)
            NAS-IP-Address (4)
            NAS-Port (5)
            Acct-Delay-Time (41)
            Acct-Input-Octets (42)
            Acct-Output-Octets (43)
            Acct-Session-Id (44)
            Acct-Session-Time (46)
            Acct-Input-Packets (47)

ユーザ名(1)NAS IPアドレス(4)NAS-ポート(5)Acct-遅延時間(41)Acct入力八重奏(42)Acct出力八重奏(43)Acctセッションイド(44)Acctセッション時間(46)Acct-入力パケット(47)

Zorn, et al.                 Informational                      [Page 5]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [5ページ]情報のRFC2867半径トンネル会計サポート2000年6月

            Acct-Output-Packets (48)
            Acct-Terminate-Cause (49)
            Acct-Multi-Session-Id (51)
            Event-Timestamp (55)
            NAS-Port-Type (61)
            Tunnel-Type (64)
            Tunnel-Medium-Type (65)
            Tunnel-Client-Endpoint (66)
            Tunnel-Server-Endpoint (67)
            Acct-Tunnel-Connection (68)
            Acct-Tunnel-Packets-Lost (86)

失われたAcctが原因を終えているトンネルの中くらいのタイプのAcct-出力パケットの(67)Acctトンネル接続(68)Acctトンネル(48)(49)Acctマルチセッションイド(51)イベントタイムスタンプ(55)NASポートタイプ(61)トンネルタイプ(64)(65)トンネルクライアント終点(66)トンネルサーバ終点パケット(86)

3.6.  Tunnel-Link-Reject

3.6. トンネルリンク廃棄物

      Value

         14

14

      Description

記述

         This value MAY be used to mark the rejection of the
         establishment of a new link in an existing tunnel.  Only some
         tunnel types (e.g., L2TP) support multiple links per tunnel.
         If only a single link can be carried in a given tunnel (e.g.,
         IPsec in the tunnel mode), this Attribute need not be included
         in accounting packets, since in this case the Tunnel-Reject
         Attribute has the same meaning.

この値は、既存のトンネルへの新しいリンクの設立の拒絶をマークするのに使用されるかもしれません。 トンネルタイプ(例えば、L2TP)の中には複数の1トンネルあたりのリンクを支える人もいます。 与えられたトンネル(例えば、トンネルモードによるIPsec)で単一のリンクしか運ぶことができないなら、このAttributeは会計パケットに含まれる必要はありません、この場合、Tunnel-廃棄物Attributeには同じ意味があるので。

         If this value is used, the following attributes SHOULD also be
         included in the Accounting-Request packet:

この値が使用されているなら、以下はSHOULDを結果と考えます、また、Accounting-リクエスト・パケットに含まれてください、:

            User-Name (1)
            NAS-IP-Address (4)
            Acct-Delay-Time (41)
            Acct-Terminate-Cause (49)
            Event-Timestamp (55)
            Tunnel-Type (64)
            Tunnel-Medium-Type (65)
            Tunnel-Client-Endpoint (66)
            Tunnel-Server-Endpoint (67)
            Acct-Tunnel-Connection (68)

Acctが原因を終えているトンネルの中くらいのタイプのユーザ名の(66)トンネルサーバ終点(67)Acctトンネル(1)NAS IPアドレス(4)Acct-遅延時間(41)(49)イベントタイムスタンプ(55)トンネルタイプ(64)(65)トンネルクライアント終点接続(68)

Zorn, et al.                 Informational                      [Page 6]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [6ページ]情報のRFC2867半径トンネル会計サポート2000年6月

4.  Attributes

4. 属性

4.1.  Acct-Tunnel-Connection

4.1. Acctトンネル接続

      Description

記述

         This Attribute indicates the identifier assigned to the tunnel
         session.  It SHOULD be included in Accounting-Request packets
         which contain an Acct-Status-Type attribute having the value
         Start, Stop or any of the values described above.  This
         attribute, along with the Tunnel-Client-Endpoint and Tunnel-
         Server-Endpoint attributes [3], may be used to provide a means
         to uniquely identify a tunnel session for auditing purposes.

このAttributeはトンネルセッションまで割り当てられた識別子を示します。 それ、SHOULDが値のStartを持っているAcct状態タイプ属性を含むAccounting-リクエスト・パケットに含まれていて、Stopか値のいずれも上について説明しました。 この属性は、唯一監査の目的のためのトンネルセッションを特定する手段を提供するのにTunnelクライアント終点とTunnelサーバ終点属性[3]と共に使用されるかもしれません。

      A summary of the Acct-Tunnel-Connection Attribute format is shown
      below.  The fields are transmitted from left to right.

Acctトンネル接続Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。

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

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

タイプ

         68 for Acct-Tunnel-Connection

68 Acctトンネル接続のために

      Length

長さ

         >= 3

>= 3

      String

ストリング

         The format of the identifier represented by the String field
         depends upon the value of the Tunnel-Type attribute [3].  For
         example, to fully identify an L2TP tunnel connection, the L2TP
         Tunnel ID and Call ID might be encoded in this field.  The
         exact encoding of this field is implementation dependent.

String分野によって表された識別子の形式はTunnel-タイプ属性[3]の値に依存します。 例えば、L2TPトンネル接続、L2TP Tunnel ID、およびCall IDを完全に特定するのはこの分野でコード化されるかもしれません。 この分野の正確なコード化は実装に依存しています。

4.2.  Acct-Tunnel-Packets-Lost

4.2. Acctトンネルパケットは損をしました。

      Description

記述

         This Attribute indicates the number of packets lost on a given
         link.  It SHOULD be included in Accounting-Request packets
         which contain an Acct-Status-Type attribute having the value
         Tunnel-Link-Stop.

このAttributeは、パケットの数が与えられたリンクを失ったのを示します。 それ、SHOULD、値のTunnelリンク停止を持っているAcct状態タイプ属性を含むAccounting-リクエスト・パケットで含められてください。

Zorn, et al.                 Informational                      [Page 7]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [7ページ]情報のRFC2867半径トンネル会計サポート2000年6月

      A summary of the Acct-Tunnel-Packets-Lost Attribute format is
      shown below.  The fields are transmitted from left to right.

Acctトンネルパケットが損をしているAttribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。

       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     |               Lost
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Lost (cont)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 無くなっている+++++++++++++++++++++++++++++++++は(cont)を失いました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

タイプ

         86 for Acct-Tunnel-Packets-Lost

86 失われたAcctトンネルパケットのために

      Length

長さ

         6

6

      Lost

失われています。

         The Lost field is 4 octets in length and represents the number
         of packets lost on the link.

Lost分野は、長さにおける4つの八重奏であり、リンクの上に失われたパケットの数を表します。

5.  Table of Attributes

5. 属性のテーブル

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No tunnel attributes should be found
   in Accounting-Response packets.

以下のテーブルは属性がAccounting-リクエスト・パケットで見つけられるかもしれないガイドを提供します。 Accounting-応答パケットでトンネル属性を全く見つけるべきではありません。

   Request        #       Attribute
     0-1          64      Tunnel-Type
     0-1          65      Tunnel-Medium-Type
     0-1          66      Tunnel-Client-Endpoint
     0-1          67      Tunnel-Server-Endpoint
     0-1          68      Acct-Tunnel-Connection
     0            69      Tunnel-Password
     0-1          81      Tunnel-Private-Group-ID
     0-1          82      Tunnel-Assignment-ID
     0            83      Tunnel-Preference
     0-1          86      Acct-Tunnel-Packets-Lost

失われたトンネルの中くらいのタイプの#属性0-1 64のトンネルAssignment ID0 83トンネル好みのトンネルタイプ0-1 65 0-1 66トンネルクライアント終点0-1 67トンネルサーバ終点0-1 68Acctトンネル接続0 69トンネルパスワード0-1 81トンネルの個人的なグループID0-1 82 0-1 86Acctトンネルパケットを要求してください。

Zorn, et al.                 Informational                      [Page 8]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [8ページ]情報のRFC2867半径トンネル会計サポート2000年6月

   The following table defines the meaning of the above table entries.

以下のテーブルは上のテーブル項目の意味を定義します。

   0     This attribute MUST NOT be present in packet.
   0+    Zero or more instances of this attribute MAY be present in
         packet.
   0-1   Zero or one instance of this attribute MAY be present in
         packet.

0 この属性はパケットに存在しているはずがありません。 0+ゼロかこの属性の、より多くのインスタンスがパケットに存在しているかもしれません。 0-1 この属性のゼロか1つのインスタンスがパケットに存在しているかもしれません。

6.  Security Considerations

6. セキュリティ問題

   By "sniffing" RADIUS Accounting packets, it might be possible for an
   eavesdropper to perform a passive analysis of tunnel connections.

「スニフィング」RADIUS Accountingパケットで、立ち聞きする者がトンネル接続の受け身の分析を実行するのは、可能であるかもしれません。

7.  References

7. 参照

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

[1]Rigney、C.、「半径会計」、RFC2866、2000年6月。

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

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[3]ゾルン、G.、ライファー、D.、ルーベン、A.、シュライバー、J.、Holdrege、M.、およびI.Goyret、「トンネルへの半径属性はサポートについて議定書の中で述べます」、RFC2868、2000年6月。

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

[4] Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらわれます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。

   [5]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
        G.  Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
        July 1999.

[5]HamzehとK.と祭服とG.とVertheinとW.とTaarudとJ.と少しとw.とG.ゾルン、「二地点間トンネリングプロトコル(PPTP)」、RFC2637、1999年7月。

8.  Acknowledgments

8. 承認

   Thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall
   for salient input and review.

顕著な入力とレビューをアイドゥンEdguer、Lyロイ、マットHoldrege、およびGurdeepシンPallをありがとうございます。

Zorn, et al.                 Informational                      [Page 9]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [9ページ]情報のRFC2867半径トンネル会計サポート2000年6月

9.  Authors' Addresses

9. 作者のアドレス

   Questions about this memo can be directed to:

このメモに関する質問による以下のことよう指示できます。

   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, Washington 98004
   USA

谷間ゾルンシスコシステムズInc.500第108アベニューの東北、Suite500ベルビュー、ワシントン98004米国

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

以下に電話をしてください。 +1 425 438、8218Fax: +1 1848年の425 438メール: gwz@cisco.com

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

Driveビルリカ、デーヴミットンノーテルネットワーク880技術Park MA 01821

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

以下に電話をしてください。 +1 978 288、4570Fax: +1 3030年の978 288メール: dmitton@nortelnetworks.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052

   Phone: +1 425 936 6605
   Fax:   +1 425 936 7329
   EMail: aboba@internaut.com

以下に電話をしてください。 +1 425 936、6605Fax: +1 7329年の425 936メール: aboba@internaut.com

Zorn, et al.                 Informational                     [Page 10]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000

ゾルン、他 [10ページ]情報のRFC2867半径トンネル会計サポート2000年6月

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Zorn, et al.                 Informational                     [Page 11]

ゾルン、他 情報[11ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ブロック要素化したbr要素をテーブル内で使用するとセル幅が異常になる

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る