[要約] RFC 2868は、トンネルプロトコルのサポートに関するRADIUS属性についての規格です。このRFCの目的は、ネットワーク上でのトンネル接続の管理と制御を向上させることです。
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
トンネルプロトコルサポートのRADIUS属性
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.
Copyright（c）The Internet Society（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].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はありません」は、[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クライアントにアクセスリケストパケットに複数のトンネル属性セットが含まれている場合、特定のトンネルに関連するすべての属性には、それぞれのタグフィールドに同じ値を含める必要があり、各セットにはトンネルの適切に価値のあるインスタンスを含める必要があります。優先属性。
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.
この属性は、使用するトンネルプロトコル（トンネルイニシエーターの場合）または使用中のトンネリングプロトコル（トンネルターミネーターの場合）を示しています。Access-Request、Access-Accept、Accounting-Requestパケットに含まれる場合があります。トンネルイニシエーターから送信されたアクセスリクエストパケットにトンネルタイプの属性が存在する場合、トンネルエンドポイントによってサポートされているトンネルプロトコルと同様に、RADIUSサーバーのヒントと見なされる必要があります。ただし、RADIUSサーバーはヒントを無視する場合があります。トンネルイニシエーターは、これらのトンネルタイプのいずれかを実装する必要はありません。トンネルイニシエーターが未知のトンネルタイプまたはサポートされていないトンネルタイプのみを含むアクセスアクセプトパケットを受信した場合、トンネルイニシエーターは、代わりにアクセス拒否を受信したかのように振る舞う必要があります。
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.
トンネルターミネーターから送信されたアクセスレクエストパケットにトンネルタイプの属性が存在する場合、使用中のトンネルプロトコルを意味するように使用する必要があります。この場合、RADIUSサーバーが通信プロトコルの使用が承認されていないと判断した場合、アクセス除去パケットを返す場合があります。トンネルターミネーターが1つ以上のトンネルタイプの属性を含むアクセスacceptパケットを受信した場合、どれも使用中のトンネルプロトコルを表すものではない場合、トンネルターミネーターは代わりにアクセス除去を受信したかのように動作するはずです。
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オクテットで、同じトンネルを参照する同じパケットに属性をグループ化する手段を提供することを目的としています。このフィールドの有効な値は、0x01〜0x1fです。タグフィールドが使用されていない場合、ゼロ（0x00）でなければなりません。
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]
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.
トンネルメディウム型属性は、複数の輸送で動作できるプロトコル（L2TPなど）のトンネルを作成するときに使用する輸送媒体を示します。Access-RequestとAccess-Acceptパケットの両方に含まれる場合があります。Access-Requestパケットに存在する場合は、トンネルエンドポイントでサポートされているトンネルメディアと同様に、RADIUSサーバーへのヒントとして使用する必要があります。ただし、RADIUSサーバーはヒントを無視する場合があります。
A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted 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 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オクテットで、同じトンネルを参照する同じパケットに属性をグループ化する手段を提供することを目的としています。このフィールドの有効な値は、0x01〜0x1fです。タグフィールドが使用されていない場合、ゼロ（0x00）でなければなりません。
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つが含まれています。便利なため、このリストの関連する抜粋を以下に再現します。
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) 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
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.164（SMDS、フレームリレー、ATM）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.
この属性には、トンネルのイニシエーターエンドのアドレスが含まれています。新しいトンネルが開始されるアドレスを示すために、アクセスリクエストとアクセスacceptの両方のパケットの両方に含まれている場合があります。Tunnel-Client-Endpoint属性がAccess-Requestパケットに含まれている場合、RADIUSサーバーは値をヒントとして取得する必要があります。ただし、サーバーはヒントを尊重する義務はありません。この属性は、startまたは停止のいずれかの値を持つacct-statusタイプの属性を含むアカウンティングレクエストパケットに含める必要があります。その場合、トンネルが開始されたアドレスを示します。この属性は、トンネルサーバーエンドポイントおよびACCT-Tunnel-Connection-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以下の場合、この属性が関連する（いくつかの代替の）トンネルを示すものとして解釈する必要があります。タグフィールドが0x1Fを超える場合、次の文字列フィールドの最初のバイトとして解釈する必要があります。
String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute.
文字列弦フィールドで表されるアドレスの形式は、トンネルメディウム型属性の値に依存します。
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アドレスです。コンフォーマントの実装は、点線の頻度形式をサポートする必要があり、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.
Tunnel-Medium-Typeが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サーバーへのヒントとして）アクセスリケストパケットに含めることができ、トンネルの開始が必要な場合はアクセスacceptパケットに含める必要があります。開始または停止のいずれかの値を持つACCT-STATUSタイプの属性を含み、トンネル付きセッションに関係するACCT-STATUSタイプの属性を含む会計Requestパケットに含める必要があります。この属性は、トンネルクライアントエンドポイントおよびACCT-Tunnel-Connection-ID属性[11]とともに、会計および監査目的でトンネルを特定するためのグローバルにユニークな手段を提供するために使用できます。
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以下の場合、この属性が関連する（いくつかの代替の）トンネルを示すものとして解釈する必要があります。タグフィールドが0x1Fを超える場合、次の文字列フィールドの最初のバイトとして解釈する必要があります。
String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute.
文字列弦フィールドで表されるアドレスの形式は、トンネルメディウム型属性の値に依存します。
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アドレスです。コンフォーマントの実装は、点線の頻度形式をサポートする必要があり、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.
Tunnel-Medium-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.
この属性には、リモートサーバーに認証するために使用するパスワードが含まれる場合があります。Access-Acceptパケットにのみ含めることができます。
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オクテットで、同じトンネルを参照する同じパケットに属性をグループ化する手段を提供することを目的としています。このフィールドの有効な値は、0x01〜0x1fです。タグフィールドの値が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オクテットで、特定のアクセスacceptパケットで発生するトンネルパスワード属性の各インスタンスを暗号化するために使用される暗号化キーの一意性を確保するために使用されます。塩フィールドの最も重要なビット（左端）を設定する必要があります（1）。特定のAccess-Acceptパケットの各塩フィールドの内容は一意でなければなりません。
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.
データの長さとパスワードのサブフィールドを連結することにより、文字列フィールドのプレーンテキストバージョンを作成します。必要に応じて、結果の文字列をその長さ（オクテット内）が16の倍数になるまでパッドします。パディングにゼロオクテット（0x00）を使用することをお勧めします。このプレーンテキスト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):
共有秘密S、擬似ランダム128ビットリクエスト認証機（対応するアクセスリケストパケットから）r、塩フィールドの内容を呼び出します。... p（i）、ここでi = len（p）/16。Ciphertextブロック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)
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を示します。トンネルイニシエーターが特定の接続に起因するグループを事前に決定できる場合、トンネルプライベート-Group-ID属性は、アクセスリクエストパケットに含めることができ、このトンネルセッションがある場合はアクセスアセプトパケットに含める必要があります。特定のプライベートグループに属するものとして扱われます。プライベートグループを使用して、トンネルセッションを特定のユーザーグループと関連付けることができます。たとえば、特定のインターフェイスを介して未登録のIPアドレスのルーティングを容易にするために使用できます。開始または停止のいずれかの値を持つACCT-STATUSタイプの属性を含み、トンネル付きセッションに関係するACCT-STATUSタイプの属性を含む会計Requestパケットに含める必要があります。
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以下の場合、この属性が関連する（いくつかの代替の）トンネルを示すものとして解釈する必要があります。タグフィールドが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.
文字列このフィールドは存在する必要があります。グループは文字列フィールドで表されます。グループ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）に通知するために半径を使用するメカニズムを提供します。さらに、多重化されたトンネルを共有するセッションを異なる多重化されたトンネルに割り当てることができます。
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パラメーターを割り当てることができます。このようなトンネルは、個人または複数のセッションのいずれかを運ぶために使用できます。したがって、Tunnel-Assignment-ID属性により、RADIUSサーバーは、特定のセッションが適切なレベルのサービスを提供するトンネルに割り当てられることを示すことができます。この属性に付随する将来定義されたQoS関連の半径トンネリング属性は、トンネルイニシエーターによってこの属性によって与えられた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属性は、半径とトンネルイニシエーターのみに重要です。それが指定する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.
この属性は、Access-Acceptに含まれる場合があります。この属性を受け取るトンネルイニシエーターは、それを無視し、目的のエンドポイント間の任意の多重化または非総移動トンネルにセッションを割り当てることを選択する場合があります。この属性は、開始または停止のいずれかの値を持つACCT-STATUSタイプの属性を含み、トンネル付きセッションに関係するACCT-STATUSタイプの属性を含む会計レクエストパケットにも含める必要があります。
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属性が名前付きトンネルに指定されていないセッションを割り当ててはなりません（つまり、この属性を指定するセッションで開始されたトンネル）。
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.
Tunnel-Assignment-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.
Tunnel-Assignment-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以下の場合、この属性が関連する（いくつかの代替の）トンネルを示すものとして解釈する必要があります。タグフィールドが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 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.
RADIUSサーバーによってトンネルサーバーによって複数のセットのトンネル属性がトンネルイニシエーターに返される場合、この属性を各セットに含めて、各トンネルに割り当てられた相対的な選好を示す必要があります。たとえば、2つのトンネルを記述する属性がサーバーによって返されると仮定します。1つはトンネルタイプのPPTPを使用し、もう1つはトンネルタイプのL2TPを使用します。トンネルイニシエーターが返されたトンネルタイプの1つのみをサポートする場合、そのタイプのトンネルを開始します。ただし、両方のトンネルプロトコルをサポートしている場合、トンネルプレファレンス属性の値を使用して、どのトンネルを開始するかを決定する必要があります。この属性の値フィールドで数値的に最も低い値を持つトンネルには、最高の優先権が与えられる必要があります。特定のAccess-Acceptパケット内のトンネルプレファレンス属性の2つ以上のインスタンスに割り当てられた値は同一である場合があります。この場合、トンネルイニシエーターは、ローカルで構成されたメトリックを使用して、使用する属性のセットを決定する必要があります。この属性は（サーバーへのヒントとして）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オクテットで、同じトンネルを参照する同じパケットに属性をグループ化する手段を提供することを目的としています。このフィールドの有効な値は、0x01〜0x1fです。タグフィールドが使用されていない場合、ゼロ（0x00）でなければなりません。
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オクテットであり、それが言及するトンネルに与えられる選好を示します。より低い値がより高い選好が与えられ、0x000000が最も優先され、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.
この属性は、トンネル設立の認証フェーズ中にトンネルイニシエーターが使用する名前を指定します。Tunnel-Client-Auth-ID属性は（RADIUSサーバーへのヒントとして）Access-Requestパケットに含めることができ、デフォルト以外の認証名が必要な場合は、アクセスアセプトパケットに含める必要があります。この属性は、STARTまたはSTOPの値を持つACCT-STATUSタイプの属性を含み、トンネル付きセッションに関係するACCT-STATUSタイプの属性を含む会計レクエストパケットに含める必要があります。
A summary of the Tunnel-Client-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
Tunnel-Client-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.
Tunnel-Client-Auth-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以下の場合、この属性が関連する（いくつかの代替の）トンネルを示すものとして解釈する必要があります。タグフィールドが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 charsetで表す必要があります。
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.
この属性は、トンネル確立の認証フェーズ中にトンネルターミネーターが使用する名前を指定します。Tunnel-Client-Auth-ID属性は（RADIUSサーバーへのヒントとして）Access-Requestパケットに含めることができ、デフォルト以外の認証名が必要な場合は、アクセスアセプトパケットに含める必要があります。この属性は、STARTまたはSTOPの値を持つACCT-STATUSタイプの属性を含み、トンネル付きセッションに関係するACCT-STATUSタイプの属性を含む会計レクエストパケットに含める必要があります。
A summary of the Tunnel-Server-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
Tunnel-Server-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.
Tunnel-Server-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以下の場合、この属性が関連する（いくつかの代替の）トンネルを示すものとして解釈する必要があります。タグフィールドが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 charsetで表す必要があります。
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
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.
トンネルパスワード属性には、トンネルエンドポイントにのみ知られるべき情報が含まれている場合があります。ただし、属性の値を非表示にするために使用される方法は、介在する半径プロキシが内容の知識を持つようなものです。このため、トンネルパスワード属性は、（比較的）信頼されていない半径プロキシを通過する可能性のあるアクセスacceptパケットに含めないでください。さらに、トンネルパスワード属性を認められていないクライアントに返さないでください。対応するAccess-Requestパケットに署名属性の検証済みインスタンスが含まれていない場合[15]、Access-Acceptパケットには、トンネルパスワード属性のインスタンスを含めるべきではありません。
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].
トンネルタイプの属性の値1〜12は、セクション5.1で定義されています。残りの値は、IETFコンセンサスを伴うIANAによる割り当てに利用できます[16]。
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].
トンネルメディウム型属性の値1〜15は、セクション5.2で定義されています。残りの値は、IETFコンセンサスを伴うIANAによる割り当てに利用できます[16]。
[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.、Pall、G.、Verthein、W.、Taarud、J.、Little、W。and G. Zorn、「ポイントツーポイントトンネルプロトコル（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] Valencia、A.、Littlewood、M。and T. Kolar、T。、「Cisco Layer Two Forwarding（Protocol） '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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Palter、「レイヤー2トンネルプロトコル（L2TP）」、RFC 2661、1999年8月。
[4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[4] Hamzeh、K。、「Ascend Tunnel Management Protocol -ATMP」、RFC 2107、1997年2月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[6] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[7] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[8] Atkinson、R。、「セキュリティペイロードのカプセル化（ESP）」、RFC 1827、1995年8月。
[9] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[9] Hanks、S.、Li、T.、Farinacci、D。およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[10] Simpson、W。、「IP In IP Tunneling」、RFC 1853、1995年10月。
[11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[11] Zorn、G。およびD. Mitton、「トンネルプロトコルサポートのための半径会計変更」、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.、Willens、S.、Rubens、A。and W. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[14] Reynolds、J。およびJ. Postel、「割り当てられた番号」、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。and P. Calhoun、「Radius Extensions」、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.
[16] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] Hinden、R。and S. Deering、「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.
元のトンネルパスワード属性の定義で厄介な円形依存関係を指摘してくれたDave Mittonに感謝します。Edguer、およびBernard Abobaは、有用な入力とレビューのために。
The RADIUS Working Group can be contacted via the current chair:
RADIUSワーキンググループは、現在の椅子から連絡できます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
カール・リグニー・リビングストン・エンタープライズ4464ウィロー・ロード・プレザントン、カリフォルニア94588
Phone: +1 510 426 0770
EMail: 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
Glen Zorn Cisco Systems、Inc。500 108th Avenue N.E.、Suite 500 Bellevue、Washington 98004 USA
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com
Dory Leifer Ascend Communications 1678 Broadway Ann Arbor, MI 48105
Dory Leifer Ascend Communications 1678 Broadway Ann Arbor、MI 48105
Phone: +1 734 747 6152 EMail: leifer@del.com John Shriver Intel Corporation 28 Crosby Drive Bedford, MA 01730
電話：1 734 747 6152メール：leifer@del.com John Shriver Intel Corporation 28 Crosby Drive Bedford、MA 01730
Phone: +1 781 687 1329
EMail: John.Shriver@intel.com
Allan Rubens Ascend Communications 1678 Broadway Ann Arbor, MI 48105
アラン・ルーベンスアセンダーコミュニケーション1678ブロードウェイアナーバー、ミシガン州48105
Phone: +1 313 761 6025
EMail: acr@del.com
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
MattRege Ipverse 223 Ximeno Ave. Long Beach、CA 90803
EMail: matt@ipverse.com
Ignacio Goyret Lucent Technologies One Ascend Plaza 1701 Harbor Bay Parkway Alameda, CA 94502
Ignacio Goyret Lucent Technologies One Ascend Plaza 1701 Harber Bay Parkway Alameda、CA 94502
Phone: +1 510 769 6001
EMail: igoyret@lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。