RFC2868 日本語訳
2868 RADIUS Attributes for Tunnel Protocol Support. G. Zorn, D.Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. June 2000. (Format: TXT=42609 bytes) (Updates RFC2865) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループG.ゾルン要求をネットワークでつないでください: 2868のシスコシステムズInc.アップデート: RFC2865D.ライファーカテゴリ: 情報のA.ルーベンはコミュニケーションJ.シュライバーインテル社M.Holdrege ipVerse I.Goyretルーセントテクノロジーズ2000年6月に昇ります。
RADIUS Attributes for Tunnel Protocol Support
トンネルプロトコルサポートのための半径属性
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
このドキュメントは強制的なトンネリングのダイアルアップ・ネットワークへの支給をサポートするように設計された1セットのRADIUS属性を定義します。
1. Motivation
1. 動機
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サーバからトンネルエンドポイントまでトンネリング情報を運ぶのに必要です。 このドキュメントはそれらの属性を定義します。 特定の推薦、例、RFC2809でL2TPのためのこれらの属性の法則を見つけることができます。
Zorn, et al. Informational [Page 1] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [1ページ]情報のRFC2868半径トンネル認証属性2000年6月
2. Specification of Requirements
2. 要件の仕様
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [14].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[14]で説明されるように解釈されることになっていてください、」であるべきです
3. Attributes
3. 属性
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パケットに含まれるかもしれません。 この場合、どんな与えられたトンネルSHOULDにも適用されるべき属性はすべて、それらのそれぞれのTag分野に同じ値を保管しています。 さもなければ、TagはSHOULD NOTをさばきます。使用されます。
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がその時トンネルSHOULDにトンネルを堀るなら、代替手段とサーバSHOULDがそれぞれの代替のトンネルに関しながらAttributesのセットにTunnel-好みのAttributeのインスタンスを含んでいて、トンネル創始者によって解釈されてください。 同様に、RADIUSクライアントがAccess-リクエスト・パケットでトンネルAttributesの複数のセットを入れるなら、与えられたトンネルSHOULDに関係するすべてのAttributesが彼らのそれぞれのTag分野に同じ値を保管しています、そして、それぞれのセットSHOULDはTunnel-好みのAttributeの適切に評価されたインスタンスを含んでいます。
3.1. Tunnel-Type
3.1. トンネルタイプ
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.
このAttributeは使用されるべき(トンネル創始者の場合で)トンネリングプロトコルかトンネリングプロトコルを使用中(トンネルターミネータの場合で)に示します。 それはAccess-要求にAccess受け入れた状態で含まれるかもしれません。そして、Accounting-リクエスト・パケット。 AttributeはTunnel-タイプであるならトンネル創始者から送られたAccess-リクエスト・パケットに存在していて、それはSHOULDです。ヒントとして、トンネルエンドポイントによってサポートされたトンネルプロトコルに関してRADIUSサーバに取ってください。 しかしながら、RADIUSサーバはヒントを無視するかもしれません。トンネル創始者はこれらのトンネルタイプのどれかを実装するのに必要ではありません。 トンネル創始者が未知の、または、サポートされないTunnel-タイプだけを含むAccess受け入れているパケットを受けるなら、トンネル創始者はまるで代わりに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
AttributeはTunnel-タイプであるならトンネルターミネータから送られたAccess-リクエスト・パケットに存在していて、それはSHOULDです。取って、使用中のトンネルプロトコルを意味してください。 この場合、RADIUSサーバが、コミュニケートしているプロトコルの使用が認可されていないことを決定するなら、それはAccess-廃棄物パケットを返すかもしれません。 トンネルターミネータがAccess受け入れているパケットを受ける、どれ、含有
Zorn, et al. Informational [Page 2] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [2ページ]情報のRFC2868半径トンネル認証属性2000年6月
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.
1Tunnel-タイプAttributes、トンネルターミネータSHOULDはまるで代わりにAccess-廃棄物を受け取ったかのように振る舞います。そのいずれもトンネリングプロトコルを使用中に表しません。
A summary of the Tunnel-Type Attribute format is shown below. The fields are transmitted from left to right.
Tunnel-タイプAttribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| タグ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
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).
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 この分野への有効値は0x1Fを通した0×01です。包括的。 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.
Valueがさばく値は、3つの八重奏であり、以下の値の1つを含んでいます、始められるためにトンネルのタイプを示して。
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層Twoの推進(L2F)[2]3層Twoのトンネリングプロトコル(L2TP)[3]4がトンネルモード(ああ)[5]7IPにおけるIPカプセル化(IP-IP)[6]8の最小量のIPにおけるIPカプセル化でトンネル管理プロトコル(ATMP)[4]5の仮想のトンネリングプロトコル(VTP)6IP認証ヘッダーを昇る、(分IP IP、)、トンネルモード(超能力)[8]10ジェネリックルートカプセル化(GRE)[9]11の湾のダイヤルの仮想のサービスIPにおける(DVS)12IPトンネリングでセキュリティが有効搭載量であるとカプセル化する[7]9IP[10]
Zorn, et al. Informational [Page 3] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [3ページ]情報のRFC2868半径トンネル認証属性2000年6月
3.2. Tunnel-Medium-Type
3.2. トンネルの中くらいのタイプです。
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の中くらいのタイプAttributeは、複数の輸送の上で作動できるそれらのプロトコル(L2TPなどの)のためにトンネルを作成するとき、どの輸送培地を使用したらよいかを示します。 それはAccess-要求とAccess受け入れているパケットの両方に含まれるかもしれません。 それはAccess-リクエスト・パケットに存在していて、SHOULDです。トンネルメディアに関するRADIUSサーバへのヒントが、トンネルのそばで終わりがポイントであるとサポートしたので、取ってください。 しかしながら、RADIUSサーバはヒントを無視するかもしれません。
A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted left to right.
Tunnelの中くらいのタイプAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| タグ| 値| +++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
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).
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 この分野への有効値は0x1Fを通した0×01です。包括的。 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.
Valueがさばく値は、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)
1 IPv4(IPバージョン4)2IPv6(IPバージョン6)3NSAP4HDLC(8ビットのマルチドロップ)5BBN1822 6 802(すべての802のメディアとイーサネット「正準な形式」を含んでいる)7E.163(POTS)8E.164(SMDS、フレームリレー、気圧)
Zorn, et al. Informational [Page 4] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [4ページ]情報のRFC2868半径トンネル認証属性2000年6月
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
9 NSAP形式「副-アドレス」があるF.69(テレックス)10X.121(X.25、Frame Relay)11IPX12Appletalk13Decnet IV14Banyanバインズ15E.164
3.3. Tunnel-Client-Endpoint
3.3. トンネルクライアント終点
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.
このAttributeはトンネルの創始者端のアドレスを含んでいます。 両方に含まれていて、Access-要求とAccessが新しいトンネルが開始されることになっているアドレスを示すためにパケットを受け入れるということであるかもしれません。 Tunnelクライアント終点AttributeがAccess-リクエスト・パケットに含まれているなら、RADIUSサーバはヒントとして値をみなすべきです。 しかしながら、サーバがヒントを光栄に思うのが義務付けられません。このAttribute SHOULDがStartかStopのどちらかの値があるAcct状態タイプ属性を含むAccountingリクエスト・パケットに含まれていて、その場合、それはトンネルが開始されたアドレスを示します。 このAttributeは、会計学と会計監査学目的のためにトンネルを特定するグローバルにユニークな手段を提供するのにTunnelサーバ終点とAcct-トンネル接続ID属性と共に使用されるかもしれません。
A summary of the Tunnel-Client-Endpoint Attribute format is shown below. The fields are transmitted from left to right.
Tunnelクライアント終点Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
66 for Tunnel-Client-Endpoint.
トンネルクライアント終点に66をタイプしてください。
Length
>= 3
長さの>=3
Zorn, et al. Informational [Page 5] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [5ページ]情報のRFC2868半径トンネル認証属性2000年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. 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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 分野はTagであるなら0x1Fより大きく、それはSHOULDです。最初のバイトの以下のString分野として、解釈されます。
String
The format of the address represented by the String field depends
upon the value of the Tunnel-Medium-Type attribute.
アドレスの形式がString分野に表したストリングはTunnelの中くらいのタイプ属性の値に依存します。
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.
Tunnelの中くらいのタイプがIPv4(1)であるなら、このストリングはトンネルクライアントマシンに関する完全修飾ドメイン名(FQDN)であるかそれが「ドット付き10進法」IPアドレスです。 Conformant実装は、ドット付き10進法が形式であるとサポートしなければなりません、そして、SHOULDは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.
Tunnelの中くらいのタイプがIPv6(2)であるなら、このストリングはトンネルクライアントマシンのFQDNであるかそれが都合のよいか代替のフォーム[17]で、アドレスのテキスト表現です。 Conformant実装は好まれた形をサポートしなければならなくて、SHOULDは、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の中くらいのタイプがIPv4でなくてまたIPv6でないなら、このストリングはインタフェースについて説明するRADIUSクライアントにとっての、ローカルのコンフィギュレーション・データと使用する媒体特有のアドレスを示すタグです。
3.4. Tunnel-Server-Endpoint
3.4. トンネルサーバ終点
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.
このAttributeはトンネルのサーバ端のアドレスを示します。 Tunnelサーバ終点AttributeをAccess-リクエスト・パケットに含まれるかもしれなくて(RADIUSサーバへのヒントとして)、トンネルの開始が望まれているなら、Access受け入れているパケットに含まなければなりません。 それ、SHOULD、StartかStopのどちらかの値があるAcct状態タイプ属性を含んで、トンネルを堀られたセッションまで関係するAccounting-リクエスト・パケットで含められてください。 このAttributeは、会計学と会計監査学目的のためにトンネルを特定するグローバルにユニークな手段を提供するのにTunnelクライアント終点とAcctトンネル接続ID Attributes[11]と共に使用されるかもしれません。
Zorn, et al. Informational [Page 6] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [6ページ]情報のRFC2868半径トンネル認証属性2000年6月
A summary of the Tunnel-Server-Endpoint Attribute format is shown below. The fields are transmitted from left to right.
Tunnelサーバ終点Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 分野はTagであるなら0x1Fより大きく、それはSHOULDです。最初のバイトの以下のString分野として、解釈されます。
String
The format of the address represented by the String field depends
upon the value of the Tunnel-Medium-Type attribute.
アドレスの形式がString分野に表したストリングはTunnelの中くらいのタイプ属性の値に依存します。
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.
Tunnelの中くらいのタイプがIPv4(1)であるなら、このストリングはトンネルクライアントマシンに関する完全修飾ドメイン名(FQDN)であるかそれが「ドット付き10進法」IPアドレスです。 Conformant実装は、ドット付き10進法が形式であるとサポートしなければなりません、そして、SHOULDは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.
Tunnelの中くらいのタイプがIPv6(2)であるなら、このストリングはトンネルクライアントマシンのFQDNであるかそれが都合のよいか代替のフォーム[17]で、アドレスのテキスト表現です。 Conformant実装は好まれた形をサポートしなければならなくて、SHOULDは、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の中くらいのタイプがIPv4でなくて、またIPv6でもないなら、このストリングはインタフェースについて説明するRADIUSクライアントにとっての、ローカルのコンフィギュレーション・データと使用する媒体特有のアドレスを示すタグです。
Zorn, et al. Informational [Page 7] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [7ページ]情報のRFC2868半径トンネル認証属性2000年6月
3.5. Tunnel-Password
3.5. トンネルパスワード
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.
このAttributeはリモートサーバに認証するのに使用されるパスワードを含むかもしれません。それはAccess受け入れているパケットに含まれているだけであるかもしれません。
A summary of the Tunnel-Password Attribute format is shown below. The fields are transmitted from left to right.
Tunnel-パスワードAttribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| タグ| 塩の+++++++++++++++++++++++++++++++++塩(cont)| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 この分野への有効値は0x1Fを通した0×01です。包括的。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 さもなければ、TagはSHOULDをさばきます。無視されます。
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.
Saltがさばく塩は、長さにおける2つの八重奏であり、暗号化キーのユニークさが以前はよく与えられたAccess受け入れているパケットに起こるTunnel-パスワード属性の各インスタンスを暗号化していたのを保証するのに使用されます。 Salt分野の最も重要なビット(一番左)はセット(1)であるに違いない。 与えられたAccess受け入れているパケットのそれぞれのSalt分野のコンテンツはユニークであるに違いありません。
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
平文Stringがさばくストリングは3つの論理的なサブ分野から成ります: Data-長さ、Passwordサブ分野(それの両方が必要である)、および任意のPaddingサブ分野。 Data-長さのサブ分野は、長さにおける1つの八重奏であり、unencrypted Passwordサブ分野の長さを含んでいます。 サブ分野が含むPassword
Zorn, et al. Informational [Page 8] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [8ページ]情報のRFC2868半径トンネル認証属性2000年6月
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:
実際のトンネルパスワード。 unencrypted Data-長さとPasswordサブ分野の結合した長さ(八重奏における)が16の同等の倍数でないなら、Paddingサブ分野は存在していなければなりません。 それが存在しているなら、Paddingサブ分野の長さは変数、1〜15の八重奏です。 トランスミッションの前に以下の通りString分野を暗号化しなければなりません:
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.
Data-長さとPasswordサブ分野を連結することによって、String分野の平文バージョンを構成してください。 必要なら、長さ(八重奏における)が16の同等の倍数になるまで結果として起こるストリングを水増ししてください。 八重奏(0×00)が全く詰め物に使用されないのは、お勧めです。 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):
分野A.Break Pを共有秘密キーS、擬似ランダム128ビットのRequest Authenticator(対応するAccess-リクエスト・パケットからの)R、およびSaltのコンテンツに16八重奏塊p(1)に電話をしてください、p(2)…p(i)。(そこでは、iがlen(P)/16と等しいです)。 暗号文ブロックをc(1)、c(2)と呼んでください…c(i)と最終的な暗号文C.Intermediateは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).
結果として起こる暗号化されたString分野はc(1)+c(2)+を含むでしょう…+ c(i)。
On receipt, the process is reversed to yield the plaintext String.
領収書の上では、プロセスは、平文Stringをもたらすために逆にされます。
3.6. Tunnel-Private-Group-ID
3.6. トンネルの個人的なグループID
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
このAttributeは特定のトンネルを堀られたセッションのためにグループIDを示します。 トンネル創始者が、特定の接続から生じるグループとSHOULDがこのトンネルセッションが特定の民間のグループに属すとして扱われることであるならAccess受け入れているパケットに含まれているとあらかじめ決心できるなら、Tunnelの個人的なグループID AttributeはAccess-リクエスト・パケットに含まれるかもしれません。 民間のグループは、特定のユーザー層とのトンネルを堀られたセッションを関連づけるのに使用されるかもしれません。 例えば、それは、aを通して登録されていないIPアドレスのルーティングを容易にするのに使用されるかもしれません。
Zorn, et al. Informational [Page 9] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [9ページ]情報のRFC2868半径トンネル認証属性2000年6月
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.
特定のインタフェース。 それ、SHOULD、StartかStopのどちらかの値があるAcct状態タイプ属性を含んで、トンネルを堀られたセッションまで関係するAccounting-リクエスト・パケットで含められてください。
A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The fields are transmitted from left to right.
Tunnelの個人的なグループID Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
81 for Tunnel-Private-Group-ID.
トンネルの個人的なグループ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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 分野はTagであるなら0x1Fより大きく、それはSHOULDです。最初のバイトの以下のString分野として、解釈されます。
String
This field must be present. The group is represented by the
String field. There is no restriction on the format of group IDs.
ストリングThis分野は存在していなければなりません。 グループはString分野によって代表されます。 制限が全くグループIDの形式にありません。
3.7. Tunnel-Assignment-ID
3.7. トンネルAssignment 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.
このAttributeは、割り当てられるセッションがことである特定のトンネルをトンネル創始者に示すのに使用されます。 PPTPやL2TPなどのいくつかのトンネリングプロトコルが、それ自身の専用トンネルを利用するために同じ2つのトンネル終点の間のセッションが同じトンネルの上と、そして、与えられたセッションようにも多重送信されるのを許容します。 この属性は、RADIUSが多重送信されたトンネル、または、別々のトンネルにセッションを割り当てるかどうかをトンネル創始者(例えば、PAC、LAC)に知らせるのに使用されるためにメカニズムを提供します。 その上、それは、多重送信されたトンネルを共有するセッションが異なった多重送信されたトンネルに割り当てられるのを許容します。
Zorn, et al. Informational [Page 10] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [10ページ]情報のRFC2868半径トンネル認証属性2000年6月
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関連の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.
Tunnel Assignment 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.
含まれているコネがAccess受け入れたなら、この属性はそうするかもしれません。 この属性を受けるトンネル創始者は、必要な終点の間の任意の多重送信されたか非多重送信されたトンネルにそれを無視して、セッションを割り当てるのを選ぶかもしれません。 これはSHOULDを結果と考えます、また、StartかStopのどちらかの値があるAcct状態タイプ属性を含んで、トンネルを堀られたセッションまで関係するAccounting-リクエスト・パケットで含められてください。
If a tunnel initiator supports the Tunnel-Assignment-ID Attribute,
then it should assign a session to a tunnel in the following
manner:
トンネル創始者がTunnel Assignment ID Attributeをサポートするなら、以下の方法でセッションをトンネルに割り当てるべきです:
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).
この属性が存在していないなら、セッションは無名トンネルに割り当てられます。 無名トンネルが指定された終点の間にまだ存在していないなら、それは、Tunnel Assignment ID属性なしで確立されたこれとその後のセッションに、設立されて、使用されます。 トンネル創始者はTunnel Assignment ID Attributeが命名されたトンネル(すなわち、この属性を指定するセッションで開始されたもの)に指定されなかったセッションを割り当ててはいけません。
Zorn, et al. Informational [Page 11] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [11ページ]情報のRFC2868半径トンネル認証属性2000年6月
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 Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
82 for Tunnel-Assignment-ID.
トンネル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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 分野はTagであるなら0x1Fより大きく、それはSHOULDです。最初のバイトの以下のString分野として、解釈されます。
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.
ストリングThis分野は存在していなければなりません。 トンネルIDはString分野によって表されます。 制限が全くIDの形式にありません。
3.8. Tunnel-Preference
3.8. トンネル好み
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
1セットのトンネリング属性がトンネル創始者、このAttribute SHOULDへのRADIUSサーバによって返される以上が含まれているならそれぞれでは、セットして、各トンネルに割り当てられた相対的選好を示してください。 例えば、2つのトンネルについて説明するAttributesがサーバ、PPTPのTunnel-タイプがある1つともう片方によってL2TPのTunnel-タイプで返されると仮定してください。 トンネル創始者が返されたTunnel-タイプのひとりだけをサポートすると、それはそのタイプのトンネルを開始するでしょう。 しかしながら、両方をサポートするなら、プロトコルにトンネルを堀ってください、それ。SHOULDは、どのトンネルが出発するべきであるかを決めるのにTunnel-好みのAttributeの値を使用します。 数の上でこのAttribute SHOULDのValue分野で最も低い値に最も高い優先を与えるトンネル。 Tunnel-好みの2つ以上のインスタンスに割り当てられた値
Zorn, et al. Informational [Page 12] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [12ページ]情報のRFC2868半径トンネル認証属性2000年6月
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受け入れているパケットの中の属性は同じであるかもしれません。 この場合、SHOULDが局所的に使用するトンネル創始者は、どのセットの属性を使用するかを決めるために測定基準を構成しました。 このAttributeはAccess-リクエスト・パケットに含まれるかもしれませんが(サーバへのヒントとして)、RADIUSサーバは、このヒントを光栄に思うのに必要ではありません。
A summary of the Tunnel-Preference Attribute format is shown below. The fields are transmitted from left to right.
Tunnel-好みのAttribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| タグ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
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).
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 この分野への有効値は0x1Fを通した0×01です。包括的。 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.
Valueがさばく値は、それが参照されるトンネルに与えるために長さにおける3つの八重奏であり、好みを示します。 0×000000が最も好まれて、0xFFFFFFが最も最少に好まれている状態で値を下げるために、より高い優先を与えます。
3.9. Tunnel-Client-Auth-ID
3.9. トンネルクライアントAuth ID
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.
このAttributeはトンネル設立の認証段階の間、トンネル創始者で使用という名前を指定します。 TunnelクライアントAuth ID AttributeをAccess-リクエスト・パケットに含まれるかもしれなくて(RADIUSサーバへのヒントとして)、デフォルト以外の認証名が望まれているなら、Access受け入れているパケットに含まなければなりません。 このAttribute SHOULD、StartかStopのどちらかの値があるAcct状態タイプ属性を含んで、トンネルを堀られたセッションまで関係するAccounting-リクエスト・パケットで含められてください。
Zorn, et al. Informational [Page 13] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [13ページ]情報のRFC2868半径トンネル認証属性2000年6月
A summary of the Tunnel-Client-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
TunnelクライアントAuth ID Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
90 for Tunnel-Client-Auth-ID.
トンネルクライアント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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 分野はTagであるなら0x1Fより大きく、それはSHOULDです。最初のバイトの以下のString分野として、解釈されます。
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.
ストリングThis分野は存在していなければなりません。 String分野はトンネル創始者の認証名を含んでいます。 存在というUTF-8 charsetに表された認証名のSHOULD。
3.10. Tunnel-Server-Auth-ID
3.10. トンネルサーバAuth ID
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.
このAttributeはトンネル設立の認証段階の間、トンネルターミネータで使用という名前を指定します。 TunnelクライアントAuth ID AttributeをAccess-リクエスト・パケットに含まれるかもしれなくて(RADIUSサーバへのヒントとして)、デフォルト以外の認証名が望まれているなら、Access受け入れているパケットに含まなければなりません。 このAttribute SHOULD、StartかStopのどちらかの値があるAcct状態タイプ属性を含んで、トンネルを堀られたセッションまで関係するAccounting-リクエスト・パケットで含められてください。
A summary of the Tunnel-Server-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
TunnelサーバAuth ID Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Zorn, et al. Informational [Page 14] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [14ページ]情報のRFC2868半径トンネル認証属性2000年6月
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
Tagがさばくタグは、長さにおける1つの八重奏であり、同じトンネルについて言及する同じパケットで属性を分類する手段を提供することを意図します。 分野はTagの値であるなら0×00と、より0x1Fより大きく、それはSHOULDです。この属性がどのトンネル(いくつかの選択肢の)を関係させるかを示しながら、解釈されてください。 分野はTagであるなら0x1Fより大きく、それはSHOULDです。最初のバイトの以下のString分野として、解釈されます。
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.
ストリングThis分野は存在していなければなりません。 String分野はトンネルターミネータの認証名を含んでいます。 存在というUTF-8 charsetに表された認証名のSHOULD。
4. Table of Attributes
4. 属性のテーブル
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
廃棄物挑戦Acct-要求#属性0+0+0 0 0-1 64トンネルタイプ0+0+0 0 0-1 65トンネルの中くらいのタイプの0+0+0 0 0-1 66トンネルクライアント終点0+0+0 0 0-1 67トンネルサーバ終点0 0+0 0 0 69トンネルパスワード0+0+0 0 0-1 81トンネルの個人的なグループID0 0+0 0 0-1 82トンネルAssignment ID0+0+0 0 0 83トンネル好みの0+0+0 0 0-1 90トンネルクライアントAuth ID0 0 0-1 91トンネルサーバAuth0+0+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つのインスタンスがパケットに存在しているかもしれません。
Zorn, et al. Informational [Page 15] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [15ページ]情報のRFC2868半径トンネル認証属性2000年6月
5. Security Considerations
5. セキュリティ問題
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.
Tunnel-パスワードAttributeはトンネル終点に知られているだけであるべきである情報を含むかもしれません。 しかしながら、属性の値を隠すのに使用されるメソッドは介入しているRADIUSプロキシが心得があるくらいのコンテンツのそのようなものです。 この理由、TunnelパスワードAttribute SHOULD、通り抜けるかもしれないAccess受け入れているパケットで含められないでください、(比較的、)、信頼されていないRADIUSプロキシ。 追加、Tunnel-パスワードAttribute SHOULD NOT、非認証されたクライアントに返してください。 対応するAccess-リクエスト・パケットがSignature Attribute[15]の確かめられたインスタンスを含まなかったなら、Access受け入れているパケットSHOULD NOTはTunnel-パスワードAttributeのインスタンスを含んでいます。
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)まで様々なレベルのセキュリティを提供します。 しかしながら、強制的なトンネリング場合では、適所にあるどんな安全策もトンネル終点の間のトラフィックに適用されるだけであることに注意してください。 特に、エンドユーザSHOULD NOTは彼らのデータを保護するためにトンネルのセキュリティを当てにします。 終わりから終わりへのセキュリティとの交換であるとトンネルを堀られたトラフィックの暗号化、そして/または、保全保護をみなしてはいけません。
6. IANA Considerations
6. IANA問題
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によって使用されるように、このセクションは評価基準について説明します。 以下の小区分はほかの場所で本書では定義された名前空間のために課題方針を説明します。
6.1. Tunnel-Type Attribute Values
6.1. トンネルタイプ属性値
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].
Tunnel-タイプAttributeの値1-12はセクション5.1で定義されます。 残余価値はIETF Consensus[16]でIANAによる課題に利用可能です。
6.2. Tunnel-Medium-Type Attribute Values
6.2. トンネルの中くらいのタイプの属性値
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の中くらいのタイプAttributeの値1-15はセクション5.2で定義されます。 残余価値はIETF Consensus[16]でIANAによる課題に利用可能です。
7. References
7. 参照
[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)」、RFC2637、1999年7月。
Zorn, et al. Informational [Page 16] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [16ページ]情報のRFC2868半径トンネル認証属性2000年6月
[2] Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two
Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.
[2] バレンシア、A.、リトルウッド、M.、およびT.コラール(T.、「コクチマス層Twoの推進(プロトコル)'L2F'」RFC2341)は1998がそうするかもしれません。
[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.はあしらわれます、「層Twoはプロトコル(L2TP)にトンネルを堀っ」て、RFC2661、1999年8月。
[4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
2107, February 1997.
[4]Hamzeh、K.、「トンネル管理プロトコルを昇ってください--ATMP」、RFC2107、2月1997日
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[5] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[6] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[7] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
1827, August 1995.
[8] アトキンソン、R.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC1827、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)」、RFC1701 1994年10月。
[10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[10] シンプソン、1995年10月、W.、「IPトンネリングにおけるIP」RFC1853。
[11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for
Tunnel Protocol Support", RFC 2867, June 2000.
[11] ゾルンとG.とD.ミットン、「トンネルプロトコルサポートのための半径会計変更」、RFC2867、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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[13] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[14] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
2869, June 2000.
[15]RigneyとC.とWillatsとW.とP.カルフーン、「半径拡大」、RFC2869、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 Considerationsセクションに書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[17]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
Zorn, et al. Informational [Page 17] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [17ページ]情報のRFC2868半径トンネル認証属性2000年6月
8. Acknowledgements
8. 承認
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.
役に立つ入力とレビューをオリジナルのTunnel-パスワード属性定義における不快な円形の依存を指摘するためのデーヴ・ミットンと、そして、(特に決まった順番でなく)のコーリーHamzehと、バートランドBuclin、アンディ・バレンシア、ビル・ウェストフィールドKris Michielsenと、GurdeepシンPallと、Ranアトキンソンと、アイドゥンEdguerと、バーナードAbobaをありがとうございます。
9. Chair's Address
9. 議長のアドレス
The RADIUS Working Group can be contacted via the current chair:
現在のいすを通してRADIUS作業部会に連絡できます:
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Roadプレザントン、カールRigneyリビングストンエンタープライズ4464Willowカリフォルニア 94588
Phone: +1 510 426 0770 EMail: cdr@livingston.com
以下に電話をしてください。 +1 0770年の510 426メール: cdr@livingston.com
10. Authors' Addresses
10. 作者のアドレス
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
谷間ゾルンシスコシステムズInc.500第108アベニューの東北、Suite500ベルビュー、ワシントン98004米国
Phone: +1 425 438 8218 FAX: +1 425 438 1848 EMail: gwz@cisco.com
以下に電話をしてください。 +1 425 438、8218Fax: +1 1848年の425 438メール: gwz@cisco.com
Dory Leifer Ascend Communications 1678 Broadway Ann Arbor, MI 48105
ドーリー舟ライファーはBroadwayアナーバー、Communications1678MI 48105を昇ります。
Phone: +1 734 747 6152 EMail: leifer@del.com
以下に電話をしてください。 +1 6152年の734 747メール: leifer@del.com
Zorn, et al. Informational [Page 18] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [18ページ]情報のRFC2868半径トンネル認証属性2000年6月
John Shriver Intel Corporation 28 Crosby Drive Bedford, MA 01730
ジョンシュライバーインテル社28のクロズビー・Driveベッドフォード、MA 01730
Phone: +1 781 687 1329 EMail: John.Shriver@intel.com
以下に電話をしてください。 +1 1329年の781 687メール: John.Shriver@intel.com
Allan Rubens Ascend Communications 1678 Broadway Ann Arbor, MI 48105
アラン・ルーベンはBroadwayアナーバー、Communications1678MI 48105を昇ります。
Phone: +1 313 761 6025 EMail: acr@del.com
以下に電話をしてください。 +1 6025年の313 761メール: acr@del.com
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マットHoldrege ipVerse223Ximeno Ave。 ロングビーチ、カリフォルニア 90803
EMail: matt@ipverse.com
メール: matt@ipverse.com
Ignacio Goyret Lucent Technologies One Ascend Plaza 1701 Harbor Bay Parkway Alameda, CA 94502
イグナシオGoyretルーセントテクノロジーズ1はParkwayアラメダ、広場1701港Bayカリフォルニア 94502を昇ります。
Phone: +1 510 769 6001 EMail: igoyret@lucent.com
以下に電話をしてください。 +1 6001年の510 769メール: igoyret@lucent.com
Zorn, et al. Informational [Page 19] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
ゾルン、他 [19ページ]情報のRFC2868半径トンネル認証属性2000年6月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Zorn, et al. Informational [Page 20]
ゾルン、他 情報[20ページ]
一覧
スポンサーリンク
