Network Working Group G. Zorn
Request for Comments: 2868 Cisco Systems, Inc.
Updates: RFC 2865 D. Leifer
Category: Informational A. Rubens
Ascend Communications
J. Shriver
Intel Corporation
M. Holdrege
ipVerse
I. Goyret
Lucent Technologies
June 2000
RADIUS Attributes for Tunnel Protocol Support
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
この文書では、ダイヤルアップネットワークに強制的トンネリングの提供をサポートするように設計されたRADIUS属性のセットを定義します。
Many applications of tunneling protocols such as L2TP involve dial-up network access. Some, such as the provision of 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. In order to provide this functionality, new RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points; this document defines those attributes. Specific recommendations for, and examples of, the application of these attributes for L2TP can be found in RFC 2809.
このようL2TPなどのトンネリングプロトコルの多くのアプリケーションでは、ダイヤルアップネットワークへのアクセスを必要とします。例えば、インターネットを介して企業のイントラネットへのアクセスの提供などのいくつかは、自発的トンネリングによって特徴付けられる：トンネルは特定の目的のために、ユーザの要求に応じて作成されます。他のアプリケーションが強制的トンネリングを伴う：トンネルは、ユーザーからの操作なしとユーザーが問題でどの選択肢を許可せずに作成されます。この機能を提供するために、新しいRADIUS属性は、トンネルエンドポイントにRADIUSサーバからトンネリング情報を搬送するために必要とされます。この文書では、それらの属性を定義します。特定のための推奨事項、およびL2TPのため、これらの属性のアプリケーションの例は、RFC 2809に記載されています。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [14].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[14]に記載されているように解釈されるべきです。
Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields; otherwise, the Tag field SHOULD NOT be used.
以下に定義された属性の各々の複数のインスタンスが単一のRADIUSパケットに含まれてもよいです。この場合には、任意のトンネルに適用される属性はすべて、それぞれのタグフィールドに同じ値が含まれているべきです。それ以外の場合は、タグフィールドを使用しないでください。
If the RADIUS server returns attributes describing multiple tunnels then the tunnels SHOULD be interpreted by the tunnel initiator as alternatives and the server SHOULD include an instance of the Tunnel-Preference Attribute in the set of Attributes pertaining to each alternative tunnel. Similarly, if the RADIUS client includes multiple sets of tunnel Attributes in an Access-Request packet, all the Attributes pertaining to a given tunnel SHOULD contain the same value in their respective Tag fields and each set SHOULD include an appropriately valued instance of the Tunnel-Preference Attribute.
RADIUSサーバは、複数のトンネルを記述した属性を返す場合、トンネルは、代替として、トンネル・イニシエータによって解釈されるべきであり、サーバは、各別のトンネルに関連する属性のセットにトンネル嗜好属性のインスタンスを含むべきです。 RADIUSクライアントがアクセス要求パケットにトンネル属性の複数のセットが含まれている場合、同様に、与えられたトンネルに関連するすべての属性は、それぞれのタグフィールドに同じ値が含まれている必要があり、各セットはTunnel-の適切価値インスタンスを含むべきです好みの属性。
Description
説明
This Attribute indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel initiator, it SHOULD be taken as a hint to the RADIUS server as to the tunnelling protocols supported by the tunnel end-point; the RADIUS server MAY ignore the hint, however. A tunnel initiator is not required to implement any of these tunnel types; if a tunnel initiator receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave as though an Access-Reject had been received instead.
この属性は、使用されるトンネリングプロトコル（単数または複数）（トンネル・イニシエータの場合）または（トンネル・ターミネータの場合）、使用中のトンネリングプロトコルを示しています。これは、アクセス要求、アクセス-受け入れ、アカウンティング要求パケットに含まれるかもしれません。トンネル-type属性は、トンネル・イニシエータから送信されたアクセス要求パケット内に存在する場合、それは、トンネルエンドポイントでサポートされているトンネリングプロトコルに関して、RADIUSサーバへのヒントとして解釈されるべきです。 RADIUSサーバは、しかし、ヒントを無視するかもしれません。トンネル・イニシエータは、これらのトンネルタイプのいずれかを実施するために必要とされません。トンネルイニシエータのみが不明またはサポートされていないトンネルの種類が含まれていたAccess-受け入れてパケットを受信した場合、トンネルイニシエータはアクセス拒否ではなく、受信されたかのように振る舞う必要があります。
If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel terminator, it SHOULD be taken to signify the tunnelling protocol in use. In this case, if the RADIUS server determines that the use of the communicated protocol is not authorized, it MAY return an Access-Reject packet. If a tunnel terminator receives an Access-Accept packet which contains one or more Tunnel-Type Attributes, none of which represent the tunneling protocol in use, the tunnel terminator SHOULD behave as though an Access-Reject had been received instead.
トンネル-type属性は、トンネル・ターミネータから送信されたアクセス要求パケット内に存在する場合、使用中のトンネリングプロトコルを意味するように解釈されるべきです。 RADIUSサーバが通信プロトコルの使用が許可されていないと判断した場合、この場合、それは、アクセス拒否パケットを返すことができます。トンネル・ターミネータは、使用中のトンネリングプロトコルを表しいずれも一つ以上のトンネルタイプの属性を含み、接続許可パケットを受信した場合、アクセスは拒否代わりに受信されたかのように、トンネル・ターミネータは振る舞うべき。
A summary of the Tunnel-Type Attribute format is shown below. The fields are transmitted from left to right.
トンネル型の属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64 for Tunnel-Type
トンネル型の型64
Length Always 6.
長さは常に6。
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。このフィールドの有効な値は、包括的0x1Fの通じ0x01で、です。 Tagフィールドを使用しない場合は、それが0（$ 00）でなければなりません。
Value The Value field is three octets and contains one of the following values, indicating the type of tunnel to be started.
値は、値フィールドが3つのオクテットであり、開始するトンネルの種類を示す、以下の値のいずれかを含有します。
1 Point-to-Point Tunneling Protocol (PPTP) [1] 2 Layer Two Forwarding (L2F) [2] 3 Layer Two Tunneling Protocol (L2TP) [3] 4 Ascend Tunnel Management Protocol (ATMP) [4] 5 Virtual Tunneling Protocol (VTP) 6 IP Authentication Header in the Tunnel-mode (AH) [5] 7 IP-in-IP Encapsulation (IP-IP) [6] 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7] 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8] 10 Generic Route Encapsulation (GRE) [9] 11 Bay Dial Virtual Services (DVS) 12 IP-in-IP Tunneling [10]
1ポイントツーポイントトンネリングプロトコル（PPTP）[1] 2レイヤつフォワーディング（L2F）[2] 3レイヤ2トンネリングプロトコル（L2TP）[3] 4昇順トンネル管理プロトコル（ATMP）[4] 5仮想トンネリングプロトコルトンネルモード（VTP）6 IP認証ヘッダ（AH）[5] 7 IP-in-IPカプセル化（IP-IP）[6] 8最小IP-in-IPカプセル化（MIN-IP-IP）[7 ]トンネルモードで9 IPカプセル化セキュリティペイロード（ESP）[8] 10ジェネリックルートのカプセル化（GRE）[9] 11ベイ[10を仮想サービス（DVS）12 IP-で-IPトンネリングをダイヤル]
Description
説明
The Tunnel-Medium-Type Attribute indicates which transport medium to use when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. It MAY be included in both Access-Request and Access-Accept packets; if it is present in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server as to the tunnel media supported by the tunnel end-point. The RADIUS server MAY ignore the hint, however.
Tunnel-Medium-Type属性は、複数のトランスポート上で動作することができる（例えば、L2TPのような）これらのプロトコルのためのトンネルを作成するときに使用するトランスポート媒体を示しています。これは、アクセス要求とアクセス - 受け入れパケットの両方に含まれるかもしれ。それはアクセス要求パケット内に存在する場合には、トンネルエンドポイントによってサポートされるトンネルメディアへとしてRADIUSサーバへのヒントとして解釈されるべきです。 RADIUSサーバは、しかし、ヒントを無視するかもしれません。
A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted left to right.
Tunnel-Medium-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 | Tag | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65 for Tunnel-Medium-Type
トンネルミディアム型の型65
Length 6
長さ6
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。このフィールドの有効な値は、包括的0x1Fの通じ0x01で、です。 Tagフィールドを使用しない場合は、それが0（$ 00）でなければなりません。
Value The Value field is three octets and contains one of the values listed under "Address Family Numbers" in [14]. For the sake of convenience, a relevant excerpt of this list is reproduced below.
値値フィールドは3つのオクテットで、[14]で「アドレスファミリ番号」の下にリストされている値のいずれかが含まれています。便宜上、このリストの関連抜粋を以下に再現されます。
1 IPv4 (IP version 4) 2 IPv6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 (POTS) 8 E.164 (SMDS, Frame Relay, ATM)
1のIPv4（IPバージョン4）2のIPv6（IPバージョン6）3 NSAP 4 HDLC（8ビットマルチドロップ）5 BBN 1822 6 802（全802の培地+イーサネット "標準形式" を含む）7 E.163（POTS）8 E 0.164（SMDS、フレームリレー、ATM）
9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress
NSAPフォーマットサブアドレスと9 F.69（テレックス）10 X.121（X.25、フレームリレー）11 IPX 12のAppletalk 13 DECNET IV 14のBanyan Vinesの15 E.164
Description
説明
This Attribute contains the address of the initiator end of the tunnel. It MAY be included in both Access-Request and Access-Accept packets to indicate the address from which a new tunnel is to be initiated. If the Tunnel-Client-Endpoint Attribute is included in an Access-Request packet, the RADIUS server should take the value as a hint; the server is not obligated to honor the hint, however. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop, in which case it indicates the address from which the tunnel was initiated. This Attribute, along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes.
この属性は、トンネルのイニシエータ側のアドレスが含まれています。新しいトンネルが開始される、そこからアドレスを示すために、アクセス要求とアクセス - 受け入れパケットの両方に含まれるかもしれません。トンネルクライアントエンドポイント属性がアクセス要求パケットに含まれている場合、RADIUSサーバは、ヒントとして値を取る必要があります。サーバーは、しかし、ヒントを尊重する義務を負いません。この属性は、アカウンティング・ステータス・タイプは、それがトンネルが開始されたアドレスを示し、その場合に開始]または[停止のいずれかの値と属性が含まれているアカウンティング要求パケットに含まれるべきです。この属性は、トンネル - サーバー - エンドポイントとACCT-トンネル接続-ID属性とともに、課金及び監査の目的のためにトンネルを識別するためのグローバルにユニークな手段を提供するために使用することができます。
A summary of the Tunnel-Client-Endpoint Attribute format is shown below. The fields are transmitted from left to right.
トンネルクライアントエンドポイント属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 66 for Tunnel-Client-Endpoint.
トンネルクライアントエンドポイントのために66を入力します。
Length >= 3
長さ> = 3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。タグフィールドの値が0x00でより大きい未満または0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。 Tagフィールドが0x1Fより大きい場合は、以下の文字列フィールドの最初のバイトとして解釈されるべきです。
String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute.
文字列の文字列フィールドによって表されるアドレスの形式はTunnel-Medium-Type属性の値に依存します。
If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses.
トンネルミディアムタイプがIPv4（1）である場合、この文字列は、トンネルクライアント・マシンの完全修飾ドメイン名（FQDN）のいずれかである、またはそれは「ドット区切り」のIPアドレスです。準拠実装は、ドット付き10進形式をサポートしなければならないし、IPアドレスのFQDN形式をサポートする必要があります。
If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [17]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses.
トンネルメディアタイプがIPv6である場合（2）は、この文字列は、いずれかのトンネルクライアントマシンのFQDNであり、またはそれは、好ましいまたは代替形態[17]のいずれかのアドレスのテキスト表現です。適合実装は好ましい形態をサポートしなければならない、代替テキスト形式とIPv6アドレスのFQDN形式の両方をサポートしなければなりません。
If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use.
トンネルミディアムタイプがIPv4もIPv6のでもない場合は、この文字列は、使用するインターフェイスとメディア固有のアドレスを記述RADIUSクライアントへのローカルコンフィギュレーションデータを参照するタグです。
Description
説明
This Attribute indicates the address of the server end of the tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if the initiation of a tunnel is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. This Attribute, along with the Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID Attributes [11], may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes.
この属性は、トンネルのサーバー側のアドレスを示しています。トンネル - サーバー - エンドポイント属性が含まれていてもよいアクセス要求パケットで（RADIUSサーバへのヒントとして）、トンネルの開始が望まれる場合は、アクセス受諾パケットに含まれなければなりません。これはアカウンティング・ステータス・タイプは、スタートのいずれかの値を持つ属性が含まれているか、停止して、トンネルセッションに関連アカウンティング要求パケットに含まれるべきです。この属性は、[11]トンネルクライアントエンドポイントに沿ってACCT-トンネル接続-ID属性、課金及び監査の目的のためにトンネルを識別するためのグローバルにユニークな手段を提供するために使用することができます。
A summary of the Tunnel-Server-Endpoint Attribute format is shown below. The fields are transmitted from left to right.
トンネル - サーバー - エンドポイント属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 67 for Tunnel-Server-Endpoint.
トンネル - サーバー - エンドポイントのために67を入力します。
Length >= 3
長さ> = 3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。タグフィールドの値が0x00でより大きい未満または0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。 Tagフィールドが0x1Fより大きい場合は、以下の文字列フィールドの最初のバイトとして解釈されるべきです。
String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute.
文字列の文字列フィールドによって表されるアドレスの形式はTunnel-Medium-Type属性の値に依存します。
If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses.
トンネルミディアムタイプがIPv4（1）である場合、この文字列は、トンネルクライアント・マシンの完全修飾ドメイン名（FQDN）のいずれかである、またはそれは「ドット区切り」のIPアドレスです。準拠実装は、ドット付き10進形式をサポートしなければならないし、IPアドレスのFQDN形式をサポートする必要があります。
If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [17]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses.
トンネルメディアタイプがIPv6である場合（2）は、この文字列は、いずれかのトンネルクライアントマシンのFQDNであり、またはそれは、好ましいまたは代替形態[17]のいずれかのアドレスのテキスト表現です。適合実装は好ましい形態をサポートしなければならない、代替テキスト形式とIPv6アドレスのFQDN形式の両方をサポートしなければなりません。
If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use.
トンネル中-TypeがIPv4またはIPv6でない場合は、この文字列は、使用するインタフェースと媒体固有のアドレスを記載しているRADIUSクライアントにローカルコンフィギュレーションデータを参照するタグです。
Description
説明
This Attribute may contain a password to be used to authenticate to a remote server. It may only be included in an Access-Accept packet.
この属性は、リモートサーバへの認証に使用するパスワードが含まれていてもよいです。それだけで、接続許可パケットに含まれていてもよいです。
A summary of the Tunnel-Password Attribute format is shown below. The fields are transmitted from left to right.
トンネルパスワード属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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 | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 69 for Tunnel-Password
トンネルパスワードのタイプ69
Length >= 5
長さ> = 5
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains; otherwise, the Tag field SHOULD be ignored.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。このフィールドの有効な値は、包括的0x1Fの通じ0x01で、です。タグフィールドの値が0x00でより大きく、より少ないまたは0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。それ以外の場合は、タグ・フィールドは無視されるべきです。
Salt The Salt field is two octets in length and is used to ensure the uniqueness of the encryption key used to encrypt each instance of the Tunnel-Password attribute occurring in a given Access-Accept packet. The most significant bit (leftmost) of the Salt field MUST be set (1). The contents of each Salt field in a given Access-Accept packet MUST be unique.
塩ザ・ソルトフィールドの長さは2つのオクテットで、与えられたアクセス・受け入れパケットで発生するトンネルパスワード属性の各インスタンスを暗号化するために使用される暗号化キーの一意性を保証するために使用されます。ソルトフィールドの最上位ビット（左端）は、（1）設定しなければなりません。与えられたアクセス・受け入れパケット内の各ソルトフィールドの内容は一意でなければなりません。
String The plaintext String field consists of three logical sub-fields: the Data-Length and Password sub-fields (both of which are required), and the optional Padding sub-field. The Data-Length sub-field is one octet in length and contains the length of the unencrypted Password sub-field. The Password sub-field contains the actual tunnel password. If the combined length (in octets) of the unencrypted Data-Length and Password sub-fields is not an even multiple of 16, then the Padding sub-field MUST be present. If it is present, the length of the Padding sub-field is variable, between 1 and 15 octets. The String field MUST be encrypted as follows, prior to transmission:
文字列は、平文の文字列フィールドには、3つの論理サブフィールドで構成さ：データ長とパスワードサブフィールド（どちらも必要とされる）、およびオプションのパディングサブフィールド。データ長のサブフィールドの長さは1つのオクテットで、暗号化されていないパスワードサブフィールドの長さが含まれています。パスワードサブフィールドは、実際のトンネルのパスワードが含まれています。暗号化されていないデータ長とパスワードサブフィールド（オクテットで）結合した長さが16の倍数でない場合、パディングサブフィールドが存在しなければなりません。それが存在する場合、パディングサブフィールドの長さは1と15オクテットの間に、可変です。次のように文字列フィールドは、送信前に、暗号化されなければなりません。
Construct a plaintext version of the String field by
concatenating the Data-Length and Password sub-fields. If
necessary, pad the resulting string until its length (in
octets) is an even multiple of 16. It is recommended that zero
octets (0x00) be used for padding. Call this plaintext P.
Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation):
（2）（1）、P 16のオクテットチャンクPに共有秘密Sを呼び出し、擬似ランダム128ビット要求認証（対応するアクセス要求パケットから）R、および塩フィールドA.ブレークPの内容... P（I）、I = LEN（P）/ 16。暗号文ブロックC（1）、C（2）、...、C（i）を呼び出して、最終的な暗号文Cの中間体は、B（1）、B（2）... C（i）が必要とされる値。暗号化は、（「+」は連結を示す）次のように行われます。
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
B（1）= MD5（S + R + A）C（1）= P（1）XOR Bを（1）のC = Cの（1）B（2）= MD5（S + C（1））、C（2 ）= P（2）のXOR B（2）C = C + C（2）。 。 。 。 。 。 B（I）= MD5（S + C（I-1））C（I）= P（I）のXOR B（I）C = C + C（I）
The resulting encrypted String field will contain c(1)+c(2)+...+c(i).
結果として暗号化された文字列フィールドは、c（1）+ C（2）+ ... + C（i）を含んでいます。
On receipt, the process is reversed to yield the plaintext String.
領収書には、プロセスは、平文の文字列を生成するために逆転されます。
Description
説明
This Attribute indicates the group ID for a particular tunneled session. The Tunnel-Private-Group-ID Attribute MAY be included in the Access-Request packet if the tunnel initiator can pre-determine the group resulting from a particular connection and SHOULD be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a particular interface. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
この属性は、特定のトンネルセッションのグループIDを示します。このトンネルセッションがあることがあればトンネル・イニシエータは、特定の接続に起因するグループを事前に決定することができ、アクセス受諾パケットに含まれるべきかトンネルプライベートグループID属性は、アクセス要求パケットに含まれるかもしれません特定のプライベートグループに属するものとして扱わ。プライベートグループは、特定のユーザーグループでのトンネリングセッションを関連付けるために使用することができます。例えば、特定のインタフェースを介して登録されていないIPアドレスのルーティングを容易にするために使用されてもよいです。これはアカウンティング・ステータス・タイプは、スタートのいずれかの値を持つ属性が含まれているか、停止して、トンネルセッションに関連アカウンティング要求パケットに含まれるべきです。
A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The fields are transmitted from left to right.
あるTunnel-Private-Group-ID属性形式の概要は以下の通りです。フィールドは左から右に送信されます。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 81 for Tunnel-Private-Group-ID.
あるTunnel-Private-Group-IDのために81を入力します。
Length >= 3
長さ> = 3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。タグフィールドの値が0x00でより大きい未満または0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。 Tagフィールドが0x1Fより大きい場合は、以下の文字列フィールドの最初のバイトとして解釈されるべきです。
String This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs.
文字列は、このフィールドが存在しなければなりません。グループは、Stringフィールドによって表されます。グループIDの形式に制限はありません。
Description
説明
This Attribute is used to indicate to the tunnel initiator the particular tunnel to which a session is to be assigned. Some tunneling protocols, such as PPTP and L2TP, allow for sessions between the same two tunnel endpoints to be multiplexed over the same tunnel and also for a given session to utilize its own dedicated tunnel. This attribute provides a mechanism for RADIUS to be used to inform the tunnel initiator (e.g. PAC, LAC) whether to assign the session to a multiplexed tunnel or to a separate tunnel. Furthermore, it allows for sessions sharing multiplexed tunnels to be assigned to different multiplexed tunnels.
この属性は、トンネル・イニシエータにセッションが割り当てされるべき特定のトンネルを示すために使用されます。そのようなPPTPとL2TPのようないくつかのトンネリングプロトコルは、同じトンネルを介して、また、それ自身の専用のトンネルを利用する特定のセッションのために多重化される同じ2つのトンネルエンドポイント間のセッションを可能にします。この属性は、多重化されたトンネルに又は別個トンネルにセッションを割り当てるかどうかをトンネル・イニシエータ（例えばPAC、LAC）を通知するために使用されるRADIUSためのメカニズムを提供します。また、セッションが異なる多重トンネルに割り当てられる多重トンネルを共有することを可能にします。
A particular tunneling implementation may assign differing characteristics to particular tunnels. For example, different tunnels may be assigned different QOS parameters. Such tunnels may be used to carry either individual or multiple sessions. The Tunnel-Assignment-ID attribute thus allows the RADIUS server to indicate that a particular session is to be assigned to a tunnel that provides an appropriate level of service. It is expected that any QOS-related RADIUS tunneling attributes defined in the future that accompany this attribute will be associated by the tunnel initiator with the ID given by this attribute. In the meantime, any semantic given to a particular ID string is a matter left to local configuration in the tunnel initiator.
特定のトンネリングの実装は、特定のトンネルに異なる特性を割り当てることができます。例えば、異なるトンネルが異なるQoSパラメータを割り当てることができます。このようなトンネルは、個々のまたは複数のどちらかのセッションを搬送するために使用されてもよいです。トンネル割り当て-ID属性は、このようにRADIUSサーバが特定のセッションサービスの適切なレベルを提供するトンネルに割り当てられることを示すことを可能にします。この属性を伴う将来的に定義された任意のQoS関連RADIUSトンネリング属性は、この属性によって指定されたIDを持つトンネル・イニシエータによって関連されることが期待されます。一方、特定のIDの文字列に与えられた意味論的には、トンネル・イニシエータ内のローカル構成に左問題です。
The Tunnel-Assignment-ID attribute is of significance only to RADIUS and the tunnel initiator. The ID it specifies is intended to be of only local use to RADIUS and the tunnel initiator. The ID assigned by the tunnel initiator is not conveyed to the tunnel peer.
トンネル割り当て-ID属性は、RADIUSとトンネル・イニシエータに重要です。それは指定IDは、ローカルRADIUSに使用するとトンネル・イニシエータであることが意図されています。トンネル・イニシエータによって割り当てられたIDは、トンネルピアに搬送されません。
This attribute MAY be included in the Access-Accept. The tunnel initiator receiving this attribute MAY choose to ignore it and assign the session to an arbitrary multiplexed or non-multiplexed tunnel between the desired endpoints. This attribute SHOULD also be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
この属性は、受け入れのアクセスに含まれるかもしれません。この属性を受信トンネル・イニシエータは、それを無視して、所望のエンドポイント間の任意の多重化又は非多重トンネルにセッションを割り当てることを選ぶかもしれ。この属性は、アカウンティング・ステータス・タイプは、スタートのいずれかの値を持つ属性が含まれているか、停止して、トンネルセッションに関連アカウンティング要求パケットに含まれるべきです。
If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, then it should assign a session to a tunnel in the following manner:
トンネル・イニシエータは、トンネル割り当て-ID属性をサポートしている場合、それは次のようにしてトンネルにセッションを割り当てる必要があります。
If this attribute is present and a tunnel exists between the specified endpoints with the specified ID, then the session should be assigned to that tunnel.
この属性が存在し、トンネルが指定されたIDの指定されたエンドポイントの間に存在する場合、そのセッションは、そのトンネルに割り当てられるべきです。
If this attribute is present and no tunnel exists between the specified endpoints with the specified ID, then a new tunnel should be established for the session and the specified ID should be associated with the new tunnel.
この属性が存在しないトンネルが指定されたIDを持つ指定のエンドポイント間に存在しない場合、新しいトンネルセッションのために確立されるべきであると指定されたIDは、新しいトンネルに関連付けられなければなりません。
If this attribute is not present, then the session is assigned to an unnamed tunnel. If an unnamed tunnel does not yet exist between the specified endpoints then it is established and used for this and subsequent sessions established without the Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT assign a session for which a Tunnel-Assignment-ID Attribute was not specified to a named tunnel (i.e. one that was initiated by a session specifying this attribute).
この属性が存在しない場合、セッションは名前トンネルに割り当てられます。名前トンネルがまだ指定されたエンドポイントの間に存在しない場合、それは確立され、このために使用され、以降のセッションは、トンネル割り当て-ID属性なしで確立されます。トンネル・イニシエータは、トンネル割り当て-ID属性が名前トンネル（この属性を指定するセッションが開始された、すなわち1）に指定されなかったセッションを割り当ててはいけません。
Note that the same ID may be used to name different tunnels if such tunnels are between different endpoints.
このようなトンネルは、異なるエンドポイント間にある場合には、同じIDが異なるトンネルに名前を付けるために使用されてもよいことに留意されたいです。
A summary of the Tunnel-Assignment-ID Attribute format is shown below. The fields are transmitted from left to right.
トンネル割り当て-ID属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 82 for Tunnel-Assignment-ID.
トンネル割り当て-IDのために82を入力します。
Length >= 3
長さ> = 3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。タグフィールドの値が0x00でより大きい未満または0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。 Tagフィールドが0x1Fより大きい場合は、以下の文字列フィールドの最初のバイトとして解釈されるべきです。
String This field must be present. The tunnel ID is represented by the String field. There is no restriction on the format of the ID.
文字列は、このフィールドが存在しなければなりません。トンネルIDは、文字列フィールドで表されます。 IDのフォーマットに制限はありません。
Description
説明
If more than one set of tunneling attributes is returned by the RADIUS server to the tunnel initiator, this Attribute SHOULD be included in each set to indicate the relative preference assigned to each tunnel. For example, suppose that Attributes describing two tunnels are returned by the server, one with a Tunnel-Type of PPTP and the other with a Tunnel-Type of L2TP. If the tunnel initiator supports only one of the Tunnel-Types returned, it will initiate a tunnel of that type. If, however, it supports both tunnel protocols, it SHOULD use the value of the Tunnel-Preference Attribute to decide which tunnel should be started. The tunnel having the numerically lowest value in the Value field of this Attribute SHOULD be given the highest preference. The values assigned to two or more instances of the Tunnel-Preference
トンネリング属性の複数のセットがトンネルイニシエータにRADIUSサーバによって返された場合、この属性は、各トンネルに割り当てられた相対的優先度を示すために、各セットに含まれるべきです。例えば、2つのトンネルは、サーバ、L2TPのトンネル型とPPTPのトンネル型および他とのいずれかによって返される記述属性と仮定する。トンネルイニシエータが返されたトンネルタイプを1つだけサポートしている場合、それはそのタイプのトンネルを開始します。しかし、それは両方のトンネルプロトコルをサポートしている場合、それが開始されるべきトンネルを決定するためにトンネル好みの属性の値を使用する必要があります。この属性の値フィールドに数値的に最も低い値を持つトンネルが最も高い優先度を与えられるべきです。トンネル嗜好の2つの以上のインスタンスに割り当てられた値
Attribute within a given Access-Accept packet MAY be identical. In this case, the tunnel initiator SHOULD use locally configured metrics to decide which set of attributes to use. This Attribute MAY be included (as a hint to the server) in Access-Request packets, but the RADIUS server is not required to honor this hint.
同一であってもよい特定のAccess-受け入れパケット内の属性。この場合、トンネル・イニシエータは、使用する属性のセットを決定するために、ローカルに設定メトリックを使用すべきです。この属性は、このヒントを称えるために必要とされていないのAccess-Requestパケットではなく、RADIUSサーバ（サーバへのヒントとして）含まれるかもしれません。
A summary of the Tunnel-Preference Attribute format is shown below. The fields are transmitted from left to right.
トンネル嗜好属性形式の概要は以下に示されています。フィールドは左から右に送信されます。
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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 83 for Tunnel-Preference
トンネル・プリファレンスのためのタイプ83
Length Always 6.
長さは常に6。
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。このフィールドの有効な値は、包括的0x1Fの通じ0x01で、です。 Tagフィールドを使用しない場合は、それが0（$ 00）でなければなりません。
Value The Value field is three octets in length and indicates the preference to be given to the tunnel to which it refers; higher preference is given to lower values, with 0x000000 being most preferred and 0xFFFFFF least preferred.
値は、値フィールドの長さは3つのオクテットであり、それが参照するトンネルに与えられる優先度を示しています。より高い優先が0×000000が最も好ましいと0xFFFFFFの少なくとも好適で、より低い値に与えられます。
Description
説明
This Attribute specifies the name used by the tunnel initiator during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet, and MUST be included in the Access-Accept packet if an authentication name other than the default is desired. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
この属性は、トンネル確立の認証フェーズ中にトンネル・イニシエータによって使用される名前を指定します。トンネルクライアント認証・ID属性は、アクセス要求パケットで（RADIUSサーバへのヒントとして）含まれるかもしれ、およびAccess-受け入れデフォルト以外の認証名を希望する場合は、パケットを含まなければなりません。この属性は、アカウンティング・ステータス・タイプは、スタートのいずれかの値を持つ属性が含まれているか、停止して、トンネルセッションに関連アカウンティング要求パケットに含まれるべきです。
A summary of the Tunnel-Client-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
トンネルクライアント-AUTH-ID属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 90 for Tunnel-Client-Auth-ID.
トンネルクライアント認証-IDのために90を入力します。
Length >= 3
長さ> = 3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。タグフィールドの値が0x00でより大きい未満または0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。 Tagフィールドが0x1Fより大きい場合は、以下の文字列フィールドの最初のバイトとして解釈されるべきです。
String This field must be present. The String field contains the authentication name of the tunnel initiator. The authentication name SHOULD be represented in the UTF-8 charset.
文字列は、このフィールドが存在しなければなりません。文字列フィールドは、トンネルイニシエータの認証名が含まれています。認証名はUTF-8文字セットで表現できるようにして下さい。
Description
説明
This Attribute specifies the name used by the tunnel terminator during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet, and MUST be included in the Access-Accept packet if an authentication name other than the default is desired. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
この属性は、トンネル確立の認証フェーズの間にトンネルターミネータで使用される名前を指定します。トンネルクライアント認証・ID属性は、アクセス要求パケットで（RADIUSサーバへのヒントとして）含まれるかもしれ、およびAccess-受け入れデフォルト以外の認証名を希望する場合は、パケットを含まなければなりません。この属性は、アカウンティング・ステータス・タイプは、スタートのいずれかの値を持つ属性が含まれているか、停止して、トンネルセッションに関連アカウンティング要求パケットに含まれるべきです。
A summary of the Tunnel-Server-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
トンネルサーバー-AUTH-ID属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 91 for Tunnel-Server-Auth-ID.
トンネルサーバー-AUTH-IDのために91を入力します。
Length >= 3
長さ> = 3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
タグ・フィールドの長さが1つのオクテットであり、同じトンネルを参照して同じパケットの属性をグループ化する手段を提供することを目的とするタグ。タグフィールドの値が0x00でより大きい未満または0x1Fのに等しい場合、この属性が関係（いくつかの選択肢の）どのトンネルを示すものとして解釈されるべきです。 Tagフィールドが0x1Fより大きい場合は、以下の文字列フィールドの最初のバイトとして解釈されるべきです。
String This field must be present. The String field contains the authentication name of the tunnel terminator. The authentication name SHOULD be represented in the UTF-8 charset.
文字列は、このフィールドが存在しなければなりません。文字列フィールドは、トンネルターミネータの認証名が含まれています。認証名はUTF-8文字セットで表現できるようにして下さい。
The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity.
以下の表は、上記の属性のパケットの種類のもので、どのような量で見出されてもよいためのガイドを提供します。
Request Accept Reject Challenge Acct-Request # Attribute 0+ 0+ 0 0 0-1 64 Tunnel-Type 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 0 0+ 0 0 0 69 Tunnel-Password 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 0+ 0+ 0 0 0 83 Tunnel-Preference 0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID 0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID
チャレンジアカウンティングリクエスト＃属性0+ 0+ 0 0 0-1 64トンネル型0+ 0+ 0 0 0-1 65トンネルミディアムタイプ0+ 0+ 0 0 0-1 66トンネルクライアントを拒否要求受け入れ-endpoint 0+ 0+ 0 0 0-1 67トンネル - サーバー - エンドポイント0 0+ 0 0 0 69トンネルパスワード0+ 0+ 0 0 0-1 81あるTunnel-Private-Group-ID 0 0+ 0 0 0 -1 82トンネル割り当て-ID 0+ 0+ 0 0 83トンネル好ましい0+ 0+ 0 0-1 90トンネルクライアント-AUTH-ID 0+ 0+ 0 0-1 91トンネルサーバー - AUTH-ID
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つのインスタンスがパケットに存在してもよいです。
The Tunnel-Password Attribute may contain information which should only be known to a tunnel endpoint. However, the method used to hide the value of the attribute is such that intervening RADIUS proxies will have knowledge of the contents. For this reason, the Tunnel-Password Attribute SHOULD NOT be included in Access-Accept packets which may pass through (relatively) untrusted RADIUS proxies. In addition, the Tunnel-Password Attribute SHOULD NOT be returned to an unauthenticated client; if the corresponding Access-Request packet did not contain a verified instance of the Signature Attribute [15], the Access-Accept packet SHOULD NOT contain an instance of the Tunnel-Password Attribute.
トンネルパスワード属性は、トンネルエンドポイントに知られなければならない情報を含んでいてもよいです。しかし、属性の値を隠すために使用される方法は、RADIUSプロキシを介在する内容の知識を持っているようなものです。このため、トンネルパスワード属性は（比較的）信頼されていないRADIUSプロキシを通過してもよいのAccess-受け入れパケットに含まれるべきではありません。また、トンネルパスワード属性は、認証されていないクライアントに返すべきではありません。対応するアクセス要求パケットが署名属性[15]の検証インスタンスを保持していなかった場合、アクセス-受け入れパケットがトンネルパスワード属性のインスタンスを含めることはできません。
Tunnel protocols offer various levels of security, from none (e.g., PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory tunneling case any security measures in place only apply to traffic between the tunnel endpoints. In particular, end-users SHOULD NOT rely upon the security of the tunnel to protect their data; encryption and/or integrity protection of tunneled traffic MUST NOT be considered as a replacement for end-to-end security.
トンネルプロトコルはどれも（例えば、PPTP）から強い（例えば、IPSec）のために、セキュリティのさまざまなレベルを提供します。強制的トンネリングの場合には代わりに任意のセキュリティ対策だけでトンネルエンドポイント間のトラフィックに適用されること、しかし、注意してください。具体的には、エンドユーザーが自分のデータを保護するために、トンネルのセキュリティに頼るべきではありません。トンネルトラフィックの暗号化および/または完全性保護は、エンドツーエンドのセキュリティのための代替として考えてはなりません。
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document.
この文書は、IANAによって維持される「マジック」番号の数を定義します。このセクションでは、これらの各リストに追加番号を割り当てるためにIANAによって使用される基準を説明しています。以下のサブセクションでは、この文書の他の場所で定義された名前空間の割り当てポリシーを記述する。
Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the remaining values are available for assignment by the IANA with IETF Consensus [16].
トンネル-type属性の値1-12は、セクション5.1で定義されています。残りの値は、IETFコンセンサス[16]とIANAによって割り当てのために利用可能です。
Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 5.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].
Tunnel-Medium-Type属性の値1-15は、セクション5.2で定義されています。残りの値は、IETFコンセンサス[16]とIANAによって割り当てのために利用可能です。
[1] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[1] Hamzeh、K.、ポール、G.、Verthein、W.、Taarud、J.、リトル、W.およびG.ゾルンを、 "ポイントツーポイントトンネリングプロトコル（PPTP）"、RFC 2637、1999年7月。
[2] Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.
[2]バレンシア、A.、リトルウッド、M.とT.コーラール、T.、 "シスコレイヤ二フォワーディング（プロトコル） 'L2F'"、RFC 2341、1998年5月。
[3] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, August 1999.
[3] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ゾルン、G.およびB. Palter、 "レイヤ2トンネリングプロトコル（L2TP）"、RFC 2661、1999年8月。
[4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[4] Hamzeh、K.、 "アセンドトンネル管理プロトコル - ATMP"、RFC 2107、1997年2月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[6]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[7]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[8]アトキンソン、R.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 1827、1995年8月。
[9] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[9]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[10]シンプソン、W.、 "IPトンネリングでIP"、RFC 1853、1995年10月。
[11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[11]ソーン、G。およびD.ミトン、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、RFC 2867、2000年6月。
[12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000.
[12] Rigney、C.、ウィレンス、S.、ルーベン、A.とW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）におけるリモート認証ダイヤル"。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[14]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[15] Rigney、C.、Willats、W.およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[16] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
Thanks to Dave Mitton for pointing out a nasty circular dependency in the original Tunnel-Password attribute definition and (in no particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and Bernard Aboba for useful input and review.
Kory Hamzeh、ベルトランBuclin、アンディ・バレンシア、ビル・ウェストフィールド、クリスMichielsen、ガーディープ・シンポールに（順不同）オリジナルのトンネル-Password属性定義で厄介な循環依存を指摘し、ためデイブミトンのおかげで、アトキンソン、アイディン蘭便利な入力とレビューのためEdguer、およびバーナードAboba。
The RADIUS Working Group can be contacted via the current chair:
RADIUSワーキンググループは、現在のいすを介して接触させることができます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
カールRigneyリビングストン企業4464ウィロー・ロードプレザントン、カリフォルニア94588
Phone: +1 510 426 0770 EMail: cdr@livingston.com
電話：+1 510 426 0770 Eメール：cdr@livingston.com
Questions about this memo can also be directed to:
このメモに関する質問も対象とすることができます。
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004 USA
グレンツォルンシスコシステムズ社500第108アベニューN.E.、スイート500ベルビュー、ワシントン98004 USA
Phone: +1 425 438 8218 FAX: +1 425 438 1848 EMail: gwz@cisco.com
電話：+1 425 438 8218 FAX：+1 425 438 1848 Eメール：gwz@cisco.com
Dory Leifer Ascend Communications 1678 Broadway Ann Arbor, MI 48105
ドーリーLeiferアセンド・コミュニケーションズ1678年ブロードウェイアナーバー、MI 48105
Phone: +1 734 747 6152 EMail: leifer@del.com
電話：+1 734 747 6152 Eメール：leifer@del.com
John Shriver Intel Corporation 28 Crosby Drive Bedford, MA 01730
ジョン・シュライバーインテルコーポレーション28クロスビー・ドライブベッドフォード、MA 01730
Phone: +1 781 687 1329 EMail: John.Shriver@intel.com
電話：+1 781 687 1329 Eメール：John.Shriver@intel.com
Allan Rubens Ascend Communications 1678 Broadway Ann Arbor, MI 48105
アランルーベンスアセンド・コミュニケーションズ1678年ブロードウェイアナーバー、MI 48105
Phone: +1 313 761 6025 EMail: acr@del.com
電話：+1 313 761 6025 Eメール：acr@del.com
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マット・ホールドレッジipVerse 223 Ximenoアベニュー。ロングビーチ、CA 90803
EMail: matt@ipverse.com
メールアドレス：matt@ipverse.com
Ignacio Goyret Lucent Technologies One Ascend Plaza 1701 Harbor Bay Parkway Alameda, CA 94502
イグナシオGoyretルーセント・テクノロジーの一つアセンドプラザ1701ハーバー・ベイ・パークウェイアラメダ、CA 94502
Phone: +1 510 769 6001 EMail: igoyret@lucent.com
電話：+1 510 769 6001 Eメール：igoyret@lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。