[要約] RFC 2865は、RADIUS（Remote Authentication Dial In User Service）プロトコルに関する仕様を定義しています。RADIUSは、ネットワーク上のリモートユーザーの認証と認可を提供するために使用されます。このRFCの目的は、RADIUSプロトコルの標準化とセキュリティの向上です。
Network Working Group C. Rigney
Request for Comments: 2865 S. Willens
Obsoletes: 2138 Livingston
Category: Standards Track A. Rubens
Merit
W. Simpson
Daydreamer
June 2000
Remote Authentication Dial In User Service (RADIUS)
リモート認証ダイヤルインユーザーサービス（RADIUS）
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
IESG Note:
IESG注：
This protocol is widely implemented and used. Experience has shown that it can suffer degraded performance and lost data when used in large scale systems, in part because it does not include provisions for congestion control. Readers of this document may find it beneficial to track the progress of the IETF's AAA working group, which may develop a successor protocol that better addresses the scaling and congestion control issues.
このプロトコルは広く実装され、使用されています。経験から、大規模システムで使用すると、輻輳制御の準備が含まれていないため、パフォーマンスが低下し、データが失われる可能性があることがわかっています。このドキュメントの読者は、IETFのAAAワーキンググループの進捗状況を追跡することが有益である場合があります。これにより、スケーリングと輻輳制御の問題により適切に対処する後継プロトコルが開発される場合があります。
Abstract
概要
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server.
このドキュメントでは、リンクを認証する必要があるネットワークアクセスサーバーと共有認証サーバーの間で認証、承認、および構成情報を伝送するためのプロトコルについて説明します。
Implementation Note
実装ノート
This memo documents the RADIUS protocol. The early deployment of RADIUS was done using UDP port number 1645, which conflicts with the "datametrics" service. The officially assigned port number for RADIUS is 1812.
このメモはRADIUSプロトコルを文書化します。 RADIUSの初期の展開は、UDPポート番号1645を使用して行われました。これは、「datametrics」サービスと競合します。 RADIUSに正式に割り当てられたポート番号は1812です。
Table of Contents
目次
1. Introduction .......................................... 3
1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 5
2. Operation ............................................. 5
2.1 Challenge/Response .............................. 7
2.2 Interoperation with PAP and CHAP ................ 8
2.3 Proxy ........................................... 8
2.4 Why UDP? ........................................ 11
2.5 Retransmission Hints ............................ 12
2.6 Keep-Alives Considered Harmful .................. 13
3. Packet Format ......................................... 13
4. Packet Types .......................................... 17
4.1 Access-Request .................................. 17
4.2 Access-Accept ................................... 18
4.3 Access-Reject ................................... 20
4.4 Access-Challenge ................................ 21
5. Attributes ............................................ 22
5.1 User-Name ....................................... 26
5.2 User-Password ................................... 27
5.3 CHAP-Password ................................... 28
5.4 NAS-IP-Address .................................. 29
5.5 NAS-Port ........................................ 30
5.6 Service-Type .................................... 31
5.7 Framed-Protocol ................................. 33
5.8 Framed-IP-Address ............................... 34
5.9 Framed-IP-Netmask ............................... 34
5.10 Framed-Routing .................................. 35
5.11 Filter-Id ....................................... 36
5.12 Framed-MTU ...................................... 37
5.13 Framed-Compression .............................. 37
5.14 Login-IP-Host ................................... 38
5.15 Login-Service ................................... 39
5.16 Login-TCP-Port .................................. 40
5.17 (unassigned) .................................... 41
5.18 Reply-Message ................................... 41
5.19 Callback-Number ................................. 42
5.20 Callback-Id ..................................... 42
5.21 (unassigned) .................................... 43
5.22 Framed-Route .................................... 43
5.23 Framed-IPX-Network .............................. 44
5.24 State ........................................... 45
5.25 Class ........................................... 46
5.26 Vendor-Specific ................................. 47
5.27 Session-Timeout ................................. 48
5.28 Idle-Timeout .................................... 49
5.29 Termination-Action .............................. 49
5.30 Called-Station-Id ............................... 50
5.31 Calling-Station-Id .............................. 51
5.32 NAS-Identifier .................................. 52
5.33 Proxy-State ..................................... 53
5.34 Login-LAT-Service ............................... 54
5.35 Login-LAT-Node .................................. 55
5.36 Login-LAT-Group ................................. 56
5.37 Framed-AppleTalk-Link ........................... 57
5.38 Framed-AppleTalk-Network ........................ 58
5.39 Framed-AppleTalk-Zone ........................... 58
5.40 CHAP-Challenge .................................. 59
5.41 NAS-Port-Type ................................... 60
5.42 Port-Limit ...................................... 61
5.43 Login-LAT-Port .................................. 62
5.44 Table of Attributes ............................. 63
6. IANA Considerations ................................... 64
6.1 Definition of Terms ............................. 64
6.2 Recommended Registration Policies ............... 65
7. Examples .............................................. 66
7.1 User Telnet to Specified Host ................... 66
7.2 Framed User Authenticating with CHAP ............ 67
7.3 User with Challenge-Response card ............... 68
8. Security Considerations ............................... 71
9. Change Log ............................................ 71
10. References ............................................ 73
11. Acknowledgements ...................................... 74
12. Chair's Address ....................................... 74
13. Authors' Addresses .................................... 75
14. Full Copyright Statement .............................. 76
This document obsoletes RFC 2138 [1]. A summary of the changes between this document and RFC 2138 is available in the "Change Log" appendix.
このドキュメントはRFC 2138 [1]を廃止します。このドキュメントとRFC 2138の間の変更点の概要は、付録の「変更ログ」にあります。
Managing dispersed serial line and modem pools for large numbers of users can create the need for significant administrative support. Since modem pools are by definition a link to the outside world, they require careful attention to security, authorization and accounting. This can be best achieved by managing a single "database" of users, which allows for authentication (verifying user name and password) as well as configuration information detailing the type of service to deliver to the user (for example, SLIP, PPP, telnet, rlogin).
多数のユーザーの分散したシリアル回線とモデムプールを管理すると、重要な管理サポートが必要になる場合があります。モデムプールは、定義により外界へのリンクであるため、セキュリティ、承認、およびアカウンティングに注意を払う必要があります。これは、認証（ユーザー名とパスワードの検証）と、ユーザーに提供するサービスのタイプ（SLIP、PPP、Telnetなど）を詳述する構成情報を可能にするユーザーの単一の「データベース」を管理することで最もよく達成できます。 、rlogin）。
Key features of RADIUS are:
RADIUSの主な機能は次のとおりです。
Client/Server Model
クライアント/サーバーモデル
A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned.
ネットワークアクセスサーバー（NAS）は、RADIUSのクライアントとして動作します。クライアントは、指定されたRADIUSサーバーにユーザー情報を渡し、返された応答を処理します。
RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user.
RADIUSサーバーは、ユーザー接続要求を受信し、ユーザーを認証し、クライアントがユーザーにサービスを提供するために必要なすべての構成情報を返します。
A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.
RADIUSサーバーは、他のRADIUSサーバーまたは他の種類の認証サーバーに対するプロキシクライアントとして機能できます。
Network Security
ネットワークセキュリティー
Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.
クライアントとRADIUSサーバー間のトランザクションは、ネットワーク経由で送信されることのない共有シークレットを使用して認証されます。さらに、ユーザーのパスワードはクライアントとRADIUSサーバー間で暗号化されて送信されるため、セキュリティで保護されていないネットワークで誰かがスヌーピングしてユーザーのパスワードを特定する可能性を排除できます。
Flexible Authentication Mechanisms
柔軟な認証メカニズム
The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms.
RADIUSサーバーは、ユーザーを認証するさまざまな方法をサポートできます。ユーザーが指定したユーザー名と元のパスワードを指定すると、PPP PAPまたはCHAP、UNIXログイン、およびその他の認証メカニズムをサポートできます。
Extensible Protocol
拡張可能なプロトコル
All transactions are comprised of variable length Attribute-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol.
すべてのトランザクションは、可変長のAttribute-Length-Value 3タプルで構成されています。プロトコルの既存の実装に影響を与えることなく、新しい属性値を追加できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [2]. These key words mean the same thing whether capitalized or not.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [2]で説明されているように解釈されます。これらのキーワードは、大文字でも小文字でも同じことを意味します。
An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant".
実装は、実装するプロトコルの必須または必須でない要件の1つ以上を満たすことができない場合、準拠していません。プロトコルのすべての必須、非必須、非必須の要件を満たす実装は、「無条件に準拠」していると言われます。プロトコルのすべての必須要件と必須要件を満たしていないが、プロトコルのすべての必須要件と必須要件を満たしていない要件は、「条件付きで準拠」と呼ばれます。
A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead.
特定のサービスを実装しないNASは、そのサービスのRADIUS属性を実装してはならない（MUST NOT）。たとえば、ARAPサービスを提供できないNASは、ARAPのRADIUS属性を実装してはなりません（MUST NOT）。 NASは、利用できないサービスを許可するRADIUSアクセス許可を代わりにアクセス拒否として扱う必要があります。
This document frequently uses the following terms:
このドキュメントでは、次の用語を頻繁に使用しています。
service The NAS provides a service to the dial-in user, such as PPP or Telnet.
サービスNASは、PPPやTelnetなどのサービスをダイヤルインユーザーに提供します。
session Each service provided by the NAS to a dial-in user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that.
セッションNASがダイヤルインユーザーに提供する各サービスはセッションを構成し、セッションの開始はサービスが最初に提供されるポイントとして定義され、セッションの終了はサービスが終了するポイントとして定義されます。 NASがサポートしている場合、ユーザーは複数のセッションを並行してまたは連続して実行できます。
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
サイレントに破棄これは、実装がそれ以上処理せずにパケットを破棄することを意味します。実装は、暗黙的に破棄されたパケットの内容を含むエラーをログに記録する機能を提供する必要があり（SHOULD）、統計カウンターにイベントを記録する必要があります（SHOULD）。
When a client is configured to use RADIUS, any user of the client presents authentication information to the client. This might be with a customizable login prompt, where the user is expected to enter their username and password. Alternatively, the user might use a link framing protocol such as the Point-to-Point Protocol (PPP), which has authentication packets which carry this information.
クライアントがRADIUSを使用するように構成されている場合、クライアントのすべてのユーザーが認証情報をクライアントに提示します。これは、ユーザーが自分のユーザー名とパスワードを入力することが期待されるカスタマイズ可能なログインプロンプトで発生する場合があります。または、ユーザーは、この情報を運ぶ認証パケットを持つポイントツーポイントプロトコル（PPP）などのリンクフレーミングプロトコルを使用する場合があります。
Once the client has obtained such information, it may choose to authenticate using RADIUS. To do so, the client creates an "Access-Request" containing such Attributes as the user's name, the user's password, the ID of the client and the Port ID which the user is accessing. When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5 [3].
クライアントがこのような情報を取得すると、RADIUSを使用した認証を選択できます。そのために、クライアントは、ユーザーの名前、ユーザーのパスワード、クライアントのID、ユーザーがアクセスしているポートIDなどの属性を含む「Access-Request」を作成します。パスワードが存在する場合、RSAメッセージダイジェストアルゴリズムMD5 [3]に基づく方法を使用して非表示にします。
The Access-Request is submitted to the RADIUS server via the network. If no response is returned within a length of time, the request is re-sent a number of times. The client can also forward requests to an alternate server or servers in the event that the primary server is down or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. Retry and fallback algorithms are the topic of current research and are not specified in detail in this document.
Access-Requestはネットワーク経由でRADIUSサーバーに送信されます。時間内に応答が返されない場合、要求は何度も再送信されます。プライマリサーバーがダウンしているか到達できない場合、クライアントは代替サーバーにリクエストを転送することもできます。代替サーバーは、プライマリサーバーへの試行が数回失敗した後、またはラウンドロビン方式で使用できます。再試行アルゴリズムとフォールバックアルゴリズムは現在の研究のトピックであり、このドキュメントでは詳しく説明していません。
Once the RADIUS server receives the request, it validates the sending client. A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded. If the client is valid, the RADIUS server consults a database of users to find the user whose name matches the request. The user entry in the database contains a list of requirements which must be met to allow access for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access.
RADIUSサーバーは要求を受信すると、送信クライアントを検証します。 RADIUSサーバーが共有シークレットを持たないクライアントからの要求は、黙って破棄されなければなりません（MUST）。クライアントが有効な場合、RADIUSサーバーはユーザーのデータベースを調べて、要求に一致する名前のユーザーを見つけます。データベースのユーザーエントリには、ユーザーのアクセスを許可するために満たす必要のある要件のリストが含まれています。これには常にパスワードの検証が含まれますが、ユーザーがアクセスを許可されるクライアントまたはポートを指定することもできます。
The RADIUS server MAY make requests of other servers in order to satisfy the request, in which case it acts as a client.
RADIUSサーバーは、要求を満たすために他のサーバーの要求を行うことができます。その場合、クライアントとして機能します。
If any Proxy-State attributes were present in the Access-Request, they MUST be copied unmodified and in order into the response packet. Other Attributes can be placed before, after, or even between the Proxy-State attributes.
Proxy-State属性がAccess-Requestに存在する場合、それらを変更せずに順番に応答パケットにコピーする必要があります。その他の属性は、Proxy-State属性の前、後、または間に配置できます。
If any condition is not met, the RADIUS server sends an "Access-Reject" response indicating that this user request is invalid. If desired, the server MAY include a text message in the Access-Reject which MAY be displayed by the client to the user. No other Attributes (except Proxy-State) are permitted in an Access-Reject.
条件が満たされない場合、RADIUSサーバーは、このユーザー要求が無効であることを示す「Access-Reject」応答を送信します。必要に応じて、サーバーはAccess-Rejectにテキストメッセージを含めることができます。これは、クライアントからユーザーに表示される場合があります。 Access-Rejectでは、他の属性（Proxy-Stateを除く）は許可されていません。
If all conditions are met and the RADIUS server wishes to issue a challenge to which the user must respond, the RADIUS server sends an "Access-Challenge" response. It MAY include a text message to be displayed by the client to the user prompting for a response to the challenge, and MAY include a State attribute.
すべての条件が満たされ、RADIUSサーバーがユーザーが応答する必要があるチャレンジを発行したい場合、RADIUSサーバーは「Access-Challenge」応答を送信します。チャレンジへの応答を求めるクライアントにユーザーに表示するテキストメッセージを含めることができます。また、State属性を含めることもできます。
If the client receives an Access-Challenge and supports challenge/response it MAY display the text message, if any, to the user, and then prompt the user for a response. The client then re-submits its original Access-Request with a new request ID, with the User-Password Attribute replaced by the response (encrypted), and including the State Attribute from the Access-Challenge, if any. Only 0 or 1 instances of the State Attribute SHOULD be present in a request. The server can respond to this new Access-Request with either an Access-Accept, an Access-Reject, or another Access-Challenge.
クライアントがAccess-Challengeを受信し、チャレンジ/レスポンスをサポートしている場合、クライアントにテキストメッセージがあればそれをユーザーに表示し、ユーザーに応答を促すことができます（MAY）。次にクライアントは、元のAccess-Requestを新しいリクエストIDで再送信します。User-PasswordAttributeはレスポンス（暗号化）に置き換えられ、Access-ChallengeのState Attributeがあればそれも含まれます。リクエストには、状態属性の0または1つのインスタンスのみが存在する必要があります（SHOULD）。サーバーは、この新しいAccess-Requestに、Access-Accept、Access-Reject、または別のAccess-Challengeのいずれかで応答できます。
If all conditions are met, the list of configuration values for the user are placed into an "Access-Accept" response. These values include the type of service (for example: SLIP, PPP, Login User) and all necessary values to deliver the desired service. For SLIP and PPP, this may include values such as IP address, subnet mask, MTU, desired compression, and desired packet filter identifiers. For character mode users, this may include values such as desired protocol and host.
すべての条件が満たされると、ユーザーの構成値のリストが「Access-Accept」応答に配置されます。これらの値には、サービスのタイプ（SLIP、PPP、ログインユーザーなど）と、目的のサービスを提供するために必要なすべての値が含まれます。 SLIPおよびPPPの場合、これにはIPアドレス、サブネットマスク、MTU、必要な圧縮、および必要なパケットフィルター識別子などの値が含まれる場合があります。キャラクターモードのユーザーの場合、これには必要なプロトコルやホストなどの値が含まれる場合があります。
In challenge/response authentication, the user is given an unpredictable number and challenged to encrypt it and give back the result. Authorized users are equipped with special devices such as smart cards or software that facilitate calculation of the correct response with ease. Unauthorized users, lacking the appropriate device or software and lacking knowledge of the secret key necessary to emulate such a device or software, can only guess at the response.
チャレンジ/レスポンス認証では、ユーザーに予測できない番号が与えられ、それを暗号化して結果を返すように要求されます。承認されたユーザーには、スマートカードやソフトウェアなどの特別なデバイスが装備されており、正しい応答の計算を簡単に行うことができます。適切なデバイスまたはソフトウェアがなく、そのようなデバイスまたはソフトウェアをエミュレートするために必要な秘密鍵がわからない、許可されていないユーザーは、応答を推測することしかできません。
The Access-Challenge packet typically contains a Reply-Message including a challenge to be displayed to the user, such as a numeric value unlikely ever to be repeated. Typically this is obtained from an external server that knows what type of authenticator is in the possession of the authorized user and can therefore choose a random or non-repeating pseudorandom number of an appropriate radix and length.
Access-Challengeパケットには通常、ユーザーに表示されるチャレンジを含むReply-Messageが含まれています。通常、これは、認証されたユーザーが所有している認証システムのタイプを知っている外部サーバーから取得されるため、適切な基数と長さのランダムまたは非反復の疑似乱数を選択できます。
The user then enters the challenge into his device (or software) and it calculates a response, which the user enters into the client which forwards it to the RADIUS server via a second Access-Request. If the response matches the expected response the RADIUS server replies with an Access-Accept, otherwise an Access-Reject.
次に、ユーザーは自分のデバイス（またはソフトウェア）にチャレンジを入力し、応答を計算します。ユーザーはそれをクライアントに入力し、2番目のAccess-Requestを介してRADIUSサーバーに転送します。応答が予想される応答と一致する場合、RADIUSサーバーはAccess-Acceptで応答します。それ以外の場合は、Access-Rejectです。
Example: The NAS sends an Access-Request packet to the RADIUS Server with NAS-Identifier, NAS-Port, User-Name, User-Password (which may just be a fixed string like "challenge" or ignored). The server sends back an Access-Challenge packet with State and a Reply-Message along the lines of "Challenge 12345678, enter your response at the prompt" which the NAS displays. The NAS prompts for the response and sends a NEW Access-Request to the server (with a new ID) with NAS-Identifier, NAS-Port, User-Name, User-Password (the response just entered by the user, encrypted), and the same State Attribute that came with the Access-Challenge. The server then sends back either an Access-Accept or Access-Reject based on whether the response matches the required value, or it can even send another Access-Challenge.
例：NASは、NAS-Identifier、NAS-Port、User-Name、User-Password（「challenge」などの固定文字列であるか、無視される可能性がある）を使用して、Access-RequestパケットをRADIUSサーバーに送信します。サーバーは、NASが表示する「Challenge 12345678、プロンプトに応答を入力してください」の行に沿って、状態と応答メッセージを含むAccess-Challengeパケットを送り返します。 NASは応答を求め、NAS-Identifier、NAS-Port、User-Name、User-Password（ユーザーが入力したばかりの応答、暗号化）を使用して、新しいAccess-Requestをサーバーに（新しいIDで）送信します。 Access-Challengeに付属していたのと同じ状態属性。次に、サーバーは、応答が必要な値と一致するかどうかに基づいて、Access-AcceptまたはAccess-Rejectを送信します。または、別のAccess-Challengeを送信することもできます。
For PAP, the NAS takes the PAP ID and password and sends them in an Access-Request packet as the User-Name and User-Password. The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected.
PAPの場合、NASはPAP IDとパスワードを受け取り、それらをユーザー名とユーザーパスワードとしてAccess-Requestパケットで送信します。 NASは、PPPサービスが期待されるRADIUSサーバーへのヒントとして、属性Service-Type = Framed-UserおよびFramed-Protocol = PPPを含めることができます。
For CHAP, the NAS generates a random challenge (preferably 16 octets) and sends it to the user, who returns a CHAP response along with a CHAP ID and CHAP username. The NAS then sends an Access-Request packet to the RADIUS server with the CHAP username as the User-Name and with the CHAP ID and CHAP response as the CHAP-Password (Attribute 3). The random challenge can either be included in the CHAP-Challenge attribute or, if it is 16 octets long, it can be placed in the Request Authenticator field of the Access-Request packet. The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected.
CHAPの場合、NASはランダムなチャレンジ（できれば16オクテット）を生成してユーザーに送信し、ユーザーはCHAP IDとCHAPユーザー名とともにCHAP応答を返します。次に、NASは、CHAPユーザー名をユーザー名として、CHAP IDとCHAP応答をCHAPパスワード（属性3）として、Access-RequestパケットをRADIUSサーバーに送信します。ランダムチャレンジは、CHAP-Challenge属性に含めるか、16オクテットの場合は、Access-RequestパケットのRequest Authenticatorフィールドに配置できます。 NASは、PPPサービスが期待されるRADIUSサーバーへのヒントとして、属性Service-Type = Framed-UserおよびFramed-Protocol = PPPを含めることができます。
The RADIUS server looks up a password based on the User-Name, encrypts the challenge using MD5 on the CHAP ID octet, that password, and the CHAP challenge (from the CHAP-Challenge attribute if present, otherwise from the Request Authenticator), and compares that result to the CHAP-Password. If they match, the server sends back an Access-Accept, otherwise it sends back an Access-Reject.
RADIUSサーバーは、ユーザー名に基づいてパスワードを検索し、CHAP IDオクテットでMD5を使用してチャレンジを暗号化し、そのパスワード、およびCHAPチャレンジ（存在する場合はCHAP-Challenge属性から、それ以外の場合はリクエスト認証システムから）を暗号化します。その結果をCHAP-Passwordと比較します。それらが一致する場合、サーバーはAccess-Acceptを送り返し、それ以外の場合はAccess-Rejectを送り返します。
If the RADIUS server is unable to perform the requested authentication it MUST return an Access-Reject. For example, CHAP requires that the user's password be available in cleartext to the server so that it can encrypt the CHAP challenge and compare that to the CHAP response. If the password is not available in cleartext to the RADIUS server then the server MUST send an Access-Reject to the client.
RADIUSサーバーが要求された認証を実行できない場合は、Access-Rejectを返す必要があります。たとえば、CHAPでは、CHAPチャレンジを暗号化してCHAP応答と比較できるように、ユーザーのパスワードをクリアテキストでサーバーに提供する必要があります。パスワードがクリアテキストでRADIUSサーバーに使用できない場合、サーバーはクライアントにAccess-Rejectを送信する必要があります。
With proxy RADIUS, one RADIUS server receives an authentication (or accounting) request from a RADIUS client (such as a NAS), forwards the request to a remote RADIUS server, receives the reply from the remote server, and sends that reply to the client, possibly with changes to reflect local administrative policy. A common use for proxy RADIUS is roaming. Roaming permits two or more administrative entities to allow each other's users to dial in to either entity's network for service.
プロキシRADIUSでは、1つのRADIUSサーバーがRADIUSクライアント（NASなど）から認証（またはアカウンティング）要求を受信し、その要求をリモートRADIUSサーバーに転送し、リモートサーバーから応答を受信し、その応答をクライアントに送信します、おそらく地方の行政政策を反映するための変更を伴う。プロキシRADIUSの一般的な用途はローミングです。ローミングでは、2つ以上の管理エンティティが互いのユーザーがどちらかのエンティティのネットワークにダイヤルインしてサービスを提供できるようにします。
The NAS sends its RADIUS access-request to the "forwarding server" which forwards it to the "remote server". The remote server sends a response (Access-Accept, Access-Reject, or Access-Challenge) back to the forwarding server, which sends it back to the NAS. The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called-Station-Id (a "numbered realm").
NASはRADIUSアクセス要求を「転送サーバー」に送信し、「転送サーバー」はそれを「リモートサーバー」に転送します。リモートサーバーは応答（Access-Accept、Access-Reject、またはAccess-Challenge）を転送サーバーに送り返し、転送サーバーはそれをNASに送り返します。 User-Name属性には、RADIUSプロキシ操作用のネットワークアクセス識別子[8]が含まれる場合があります。転送されたリクエストを受信するサーバーの選択は、認証「レルム」に基づく必要があります。認証領域は、ネットワークアクセス識別子（「名前付き領域」）の領域部分である場合があります。あるいは、転送されたリクエストを受信するサーバーの選択は、Called-Station-Id（「番号付きレルム」）など、転送サーバーが使用するように設定されている他の基準に基づく場合があります。
A RADIUS server can function as both a forwarding server and a remote server, serving as a forwarding server for some realms and a remote server for other realms. One forwarding server can act as a forwarder for any number of remote servers. A remote server can have any number of servers forwarding to it and can provide authentication for any number of realms. One forwarding server can forward to another forwarding server to create a chain of proxies, although care must be taken to avoid introducing loops.
RADIUSサーバーは、転送サーバーとリモートサーバーの両方として機能し、一部のレルムでは転送サーバーとして機能し、他のレルムではリモートサーバーとして機能します。 1つの転送サーバーは、任意の数のリモートサーバーのフォワーダーとして機能できます。リモートサーバーは、任意の数のサーバーに転送し、任意の数のレルムに認証を提供できます。 1つの転送サーバーは、別の転送サーバーに転送してプロキシのチェーンを作成できますが、ループが発生しないように注意する必要があります。
The following scenario illustrates a proxy RADIUS communication between a NAS and the forwarding and remote RADIUS servers:
次のシナリオは、NASと転送およびリモートRADIUSサーバー間のプロキシRADIUS通信を示しています。
1. A NAS sends its access-request to the forwarding server.
1. NASはそのアクセス要求を転送サーバーに送信します。
2. The forwarding server forwards the access-request to the remote server.
2. 転送サーバーは、アクセス要求をリモートサーバーに転送します。
3. The remote server sends an access-accept, access-reject or access-challenge back to the forwarding server. For this example, an access-accept is sent.
3. リモートサーバーは、アクセス許可、アクセス拒否、またはアクセスチャレンジを転送サーバーに送り返します。この例では、access-acceptが送信されます。
4. The forwarding server sends the access-accept to the NAS.
4. 転送サーバーは、access-acceptをNASに送信します。
The forwarding server MUST treat any Proxy-State attributes already in the packet as opaque data. Its operation MUST NOT depend on the content of Proxy-State attributes added by previous servers.
転送サーバーは、パケット内の既存のProxy-State属性を不透明なデータとして処理する必要があります。その操作は、以前のサーバーによって追加されたProxy-State属性の内容に依存してはなりません（MUST NOT）。
If there are any Proxy-State attributes in the request received from the client, the forwarding server MUST include those Proxy-State attributes in its reply to the client. The forwarding server MAY include the Proxy-State attributes in the access-request when it forwards the request, or MAY omit them in the forwarded request. If the forwarding server omits the Proxy-State attributes in the forwarded access-request, it MUST attach them to the response before sending it to the client.
クライアントから受信したリクエストにProxy-State属性がある場合、転送サーバーはそれらのProxy-State属性をクライアントへの応答に含める必要があります。転送サーバーは、リクエストを転送するときにAccess-RequestにProxy-State属性を含めるか、転送されたリクエストでそれらを省略してもよい（MAY）。転送サーバーが転送されたaccess-requestでProxy-State属性を省略した場合、クライアントに送信する前にそれらを応答に添付する必要があります。
We now examine each step in more detail.
ここで、各ステップをさらに詳しく調べます。
1. A NAS sends its access-request to the forwarding server. The forwarding server decrypts the User-Password, if present, using the shared secret it knows for the NAS. If a CHAP-Password attribute is present in the packet and no CHAP-Challenge attribute is present, the forwarding server MUST leave the Request-Authenticator untouched or copy it to a CHAP-Challenge attribute.
1. NASはそのアクセス要求を転送サーバーに送信します。転送サーバーは、NASで認識している共有シークレットを使用して、ユーザーパスワードがある場合はそれを復号化します。パケットにCHAP-Password属性があり、CHAP-Challenge属性がない場合、転送サーバーはRequest-Authenticatorをそのままにするか、CHAP-Challenge属性にコピーする必要があります。
'' The forwarding server MAY add one Proxy-State attribute to the packet. (It MUST NOT add more than one.) If it adds a Proxy-State, the Proxy-State MUST appear after any other Proxy-States in the packet. The forwarding server MUST NOT modify any other Proxy-States that were in the packet (it may choose not to forward them, but it MUST NOT change their contents). The forwarding server MUST NOT change the order of any attributes of the same type, including Proxy-State.
''転送サーバーは、1つのProxy-State属性をパケットに追加してもよい（MAY）。 （複数追加することはできません。）Proxy-Stateを追加する場合、Proxy-Stateはパケット内の他のProxy-Stateの後に表示する必要があります。転送サーバーは、パケットに含まれていた他のプロキシ状態を変更してはなりません（転送しないことを選択する場合がありますが、その内容を変更してはなりません）。転送サーバーは、Proxy-Stateを含め、同じタイプの属性の順序を変更してはなりません（MUST NOT）。
2. The forwarding server encrypts the User-Password, if present, using the secret it shares with the remote server, sets the Identifier as needed, and forwards the access-request to the remote server.
2. 転送サーバーは、リモートサーバーと共有するシークレットを使用してユーザーパスワードを暗号化し、必要に応じて識別子を設定して、アクセス要求をリモートサーバーに転送します。
3. The remote server (if the final destination) verifies the user using User-Password, CHAP-Password, or such method as future extensions may dictate, and returns an access-accept, access-reject or access-challenge back to the forwarding server. For this example, an access-accept is sent. The remote server MUST copy all Proxy-State attributes (and only the Proxy-State attributes) in order from the access-request to the response packet, without modifying them.
3. リモートサーバー（最終的な送信先の場合）は、User-Password、CHAP-Password、または将来の拡張機能によって要求される可能性のある方法を使用してユーザーを確認し、転送サーバーにAccess-Accept、Access-Reject、またはAccess-challengeを返します。この例では、access-acceptが送信されます。リモートサーバーは、すべてのProxy-State属性（およびProxy-State属性のみ）を、変更せずに、アクセス要求から応答パケットまで順にコピーする必要があります。
4. The forwarding server verifies the Response Authenticator using the secret it shares with the remote server, and silently discards the packet if it fails verification. If the packet passes verification, the forwarding server removes the last Proxy-State (if it attached one), signs the Response Authenticator using the secret it shares with the NAS, restores the Identifier to match the one in the original request by the NAS, and sends the access-accept to the NAS.
4. 転送サーバーは、リモートサーバーと共有するシークレットを使用して応答オーセンティケーターを検証し、検証に失敗した場合、パケットをサイレントに破棄します。パケットが検証に合格すると、転送サーバーは最後のProxy-State（接続されている場合）を削除し、NASと共有するシークレットを使用してResponse Authenticatorに署名し、NASによる元のリクエストのIDと一致するようにIDを復元します。そして、access-acceptをNASに送信します。
A forwarding server MAY need to modify attributes to enforce local policy. Such policy is outside the scope of this document, with the following restrictions. A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet.
転送サーバーは、ローカルポリシーを適用するために属性を変更する必要があります。このようなポリシーはこのドキュメントの範囲外ですが、次の制限があります。転送サーバーは、パケットに存在する既存のProxy-State、State、またはClass属性を変更してはなりません（MUST NOT）。
Implementers of forwarding servers should consider carefully which values it is willing to accept for Service-Type. Careful consideration must be given to the effects of passing along Service-Types of NAS-Prompt or Administrative in a proxied Access-Accept, and implementers may wish to provide mechanisms to block those or other service types, or other attributes. Such mechanisms are outside the scope of this document.
転送サーバーの実装者は、Service-Typeで受け入れる値を慎重に検討する必要があります。プロキシされたAccess-AcceptでNAS-PromptまたはAdministrativeのService-Typeを渡すことの影響については慎重に検討する必要があり、実装者はそれらまたは他のサービスタイプ、または他の属性をブロックするメカニズムを提供したい場合があります。このようなメカニズムは、このドキュメントの範囲外です。
A frequently asked question is why RADIUS uses UDP instead of TCP as a transport protocol. UDP was chosen for strictly technical reasons.
よくある質問は、RADIUSがトランスポートプロトコルとしてTCPではなくUDPを使用する理由です。 UDPは厳密に技術的な理由で選択されました。
There are a number of issues which must be understood. RADIUS is a transaction based protocol which has several interesting characteristics:
理解しなければならない問題がいくつかあります。 RADIUSはトランザクションベースのプロトコルで、いくつかの興味深い特徴があります。
1. If the request to a primary Authentication server fails, a secondary server must be queried.
1. プライマリ認証サーバーへのリクエストが失敗した場合は、セカンダリサーバーを照会する必要があります。
To meet this requirement, a copy of the request must be kept above the transport layer to allow for alternate transmission. This means that retransmission timers are still required.
この要件を満たすには、要求のコピーをトランスポート層の上に保持して、代替送信を可能にする必要があります。これは、再送信タイマーが引き続き必要であることを意味します。
2. The timing requirements of this particular protocol are significantly different than TCP provides.
2. この特定のプロトコルのタイミング要件は、TCPが提供するものとは大きく異なります。
At one extreme, RADIUS does not require a "responsive" detection of lost data. The user is willing to wait several seconds for the authentication to complete. The generally aggressive TCP retransmission (based on average round trip time) is not required, nor is the acknowledgement overhead of TCP.
極端な場合、RADIUSは失われたデータの「応答」検出を必要としません。ユーザーは、認証が完了するまで数秒待ちます。一般的に積極的なTCP再送信（平均往復時間に基づく）は不要であり、TCPの確認応答オーバーヘッドも不要です。
At the other extreme, the user is not willing to wait several minutes for authentication. Therefore the reliable delivery of TCP data two minutes later is not useful. The faster use of an alternate server allows the user to gain access before giving up.
反対に、ユーザーは認証を数分間待つことを望んでいません。したがって、2分後のTCPデータの信頼できる配信は役に立ちません。代替サーバーをより速く使用すると、ユーザーはあきらめる前にアクセス権を取得できます。
3. The stateless nature of this protocol simplifies the use of UDP.
3. このプロトコルのステートレスな性質により、UDPの使用が簡素化されます。
Clients and servers come and go. Systems are rebooted, or are power cycled independently. Generally this does not cause a problem and with creative timeouts and detection of lost TCP connections, code can be written to handle anomalous events. UDP however completely eliminates any of this special handling. Each client and server can open their UDP transport just once and leave it open through all types of failure events on the network.
クライアントとサーバーは行き来します。システムが再起動されるか、個別に電源が再投入されます。通常、これは問題を引き起こさず、クリエイティブタイムアウトと失われたTCP接続の検出により、異常なイベントを処理するコードを作成できます。ただし、UDPはこの特別な処理を完全に排除します。各クライアントとサーバーは、UDPトランスポートを一度だけ開くことができ、ネットワーク上のすべてのタイプの障害イベントを通じて開いたままにします。
4. UDP simplifies the server implementation.
4. UDPはサーバーの実装を簡素化します。
In the earliest implementations of RADIUS, the server was single threaded. This means that a single request was received, processed, and returned. This was found to be unmanageable in environments where the back-end security mechanism took real time (1 or more seconds). The server request queue would fill and in environments where hundreds of people were being authenticated every minute, the request turn-around time increased to longer than users were willing to wait (this was especially severe when a specific lookup in a database or over DNS took 30 or more seconds). The obvious solution was to make the server multi-threaded. Achieving this was simple with UDP. Separate processes were spawned to serve each request and these processes could respond directly to the client NAS with a simple UDP packet to the original transport of the client.
RADIUSの初期の実装では、サーバーはシングルスレッドでした。これは、単一の要求が受信され、処理され、返されたことを意味します。これは、バックエンドのセキュリティメカニズムにリアルタイム（1秒以上）がかかる環境では管理できないことがわかりました。サーバーリクエストキューがいっぱいになり、毎分数百人が認証されている環境では、リクエストのターンアラウンドタイムが、ユーザーが待機するよりも長くなりました（これは、データベースまたはDNSでの特定のルックアップが行われたときに特に深刻でした30秒以上）。明白な解決策は、サーバーをマルチスレッド化することでした。これを達成することはUDPで簡単でした。各要求を処理するために個別のプロセスが生成され、これらのプロセスはクライアントの元のトランスポートへの単純なUDPパケットでクライアントNASに直接応答できます。
It's not all a panacea. As noted, using UDP requires one thing which is built into TCP: with UDP we must artificially manage retransmission timers to the same server, although they don't require the same attention to timing provided by TCP. This one penalty is a small price to pay for the advantages of UDP in this protocol.
万能薬ではありません。前述のように、UDPを使用するには、TCPに組み込まれていることが1つ必要です。UDPでは、同じサーバーへの再送信タイマーを人工的に管理する必要がありますが、TCPが提供するタイミングに同じ注意を払う必要はありません。この1つのペナルティは、このプロトコルでのUDPの利点を支払うための小さな代償です。
Without TCP we would still probably be using tin cans connected by string. But for this particular protocol, UDP is a better choice.
TCPがなくても、おそらくストリングで接続された缶を使用することになります。ただし、この特定のプロトコルでは、UDPの方が適しています。
If the RADIUS server and alternate RADIUS server share the same shared secret, it is OK to retransmit the packet to the alternate RADIUS server with the same ID and Request Authenticator, because the content of the attributes haven't changed. If you want to use a new Request Authenticator when sending to the alternate server, you may.
RADIUSサーバーと代替RADIUSサーバーが同じ共有シークレットを共有している場合は、属性の内容が変更されていないため、同じIDと要求認証システムを使用してパケットを代替RADIUSサーバーに再送信しても問題ありません。代替サーバーに送信するときに新しいリクエスト認証システムを使用したい場合は、そうすることができます。
If you change the contents of the User-Password attribute (or any other attribute), you need a new Request Authenticator and therefore a new ID.
User-Password属性（またはその他の属性）の内容を変更する場合は、新しいリクエストオーセンティケーター、つまり新しいIDが必要です。
If the NAS is retransmitting a RADIUS request to the same server as before, and the attributes haven't changed, you MUST use the same Request Authenticator, ID, and source port. If any attributes have changed, you MUST use a new Request Authenticator and ID.
NASがRADIUS要求を以前と同じサーバーに再送信していて、属性が変更されていない場合は、同じ要求認証システム、ID、およびソースポートを使用する必要があります。属性が変更された場合は、新しいリクエスト認証システムとIDを使用する必要があります。
A NAS MAY use the same ID across all servers, or MAY keep track of IDs separately for each server, it is up to the implementer. If a NAS needs more than 256 IDs for outstanding requests, it MAY use additional source ports to send requests from, and keep track of IDs for each source port. This allows up to 16 million or so outstanding requests at one time to a single server.
NASはすべてのサーバーで同じIDを使用してもよいし、各サーバーのIDを個別に追跡してもよい（MAY）、それは実装者次第です。 NASが未処理の要求に256を超えるIDを必要とする場合、追加の送信元ポートを使用して要求を送信し、各送信元ポートのIDを追跡できます。これにより、一度に最大1600万個ほどの未処理の要求を単一のサーバーに許可できます。
Some implementers have adopted the practice of sending test RADIUS requests to see if a server is alive. This practice is strongly discouraged, since it adds to load and harms scalability without providing any additional useful information. Since a RADIUS request is contained in a single datagram, in the time it would take you to send a ping you could just send the RADIUS request, and getting a reply tells you that the RADIUS server is up. If you do not have a RADIUS request to send, it does not matter if the server is up or not, because you are not using it.
一部の実装者は、サーバーが稼働しているかどうかを確認するためにテストRADIUS要求を送信する方法を採用しています。この方法は、追加の有用な情報を提供せずに負荷を増大させ、スケーラビリティを損なうため、お勧めしません。 RADIUS要求は単一のデータグラムに含まれているため、pingを送信するのにかかる時間内にRADIUS要求を送信するだけで、応答を取得するとRADIUSサーバーが稼働していることがわかります。送信するRADIUS要求がない場合は、使用していないため、サーバーが稼働しているかどうかは関係ありません。
If you want to monitor your RADIUS server, use SNMP. That's what SNMP is for.
RADIUSサーバーを監視する場合は、SNMPを使用します。それがSNMPの目的です。
Exactly one RADIUS packet is encapsulated in the UDP Data field [4], where the UDP Destination Port field indicates 1812 (decimal).
正確に1つのRADIUSパケットがUDPデータフィールド[4]にカプセル化され、UDP宛先ポートフィールドは1812（10進数）を示します。
When a reply is generated, the source and destination ports are reversed.
応答が生成されると、送信元ポートと宛先ポートが逆になります。
This memo documents the RADIUS protocol. The early deployment of RADIUS was done using UDP port number 1645, which conflicts with the "datametrics" service. The officially assigned port number for RADIUS is 1812.
このメモはRADIUSプロトコルを文書化します。 RADIUSの初期の展開は、UDPポート番号1645を使用して行われました。これは、「datametrics」サービスと競合します。 RADIUSに正式に割り当てられたポート番号は1812です。
A summary of the RADIUS data format is shown below. The fields are transmitted from left to right.
RADIUSデータ形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
The Code field is one octet, and identifies the type of RADIUS packet. When a packet is received with an invalid Code field, it is silently discarded.
Codeフィールドは1オクテットで、RADIUSパケットのタイプを識別します。無効なコードフィールドを含むパケットが受信されると、それは通知なく破棄されます。
RADIUS Codes (decimal) are assigned as follows:
RADIUSコード（10進数）は次のように割り当てられます。
1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server (experimental) 13 Status-Client (experimental) 255 Reserved
1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server（実験的）13 Status-Client（実験的）255予約済み
Codes 4 and 5 are covered in the RADIUS Accounting document [5]. Codes 12 and 13 are reserved for possible use, but are not further mentioned here.
コード4および5は、RADIUSアカウンティングドキュメント[5]で説明されています。コード12と13は可能な使用のために予約されていますが、ここではこれ以上言及しません。
Identifier
識別する
The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.
Identifierフィールドは1オクテットで、要求と応答の照合に役立ちます。 RADIUSサーバーは、同じクライアントの送信元IPアドレス、送信元UDPポート、および識別子が短時間である場合に、重複する要求を検出できます。
Length
長さ
The Length field is two octets. It indicates the length of the packet including the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it MUST be silently discarded. The minimum length is 20 and maximum length is 4096.
長さフィールドは2オクテットです。これは、コード、識別子、長さ、オーセンティケーター、および属性フィールドを含むパケットの長さを示します。長さフィールドの範囲外のオクテットはパディングとして扱われ、受信時には無視されなければなりません（MUST）。パケットが長さフィールドが示すよりも短い場合、それは黙って破棄されなければなりません（MUST）。最小長は20、最大長は4096です。
Authenticator
オーセンティケーター
The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm.
Authenticatorフィールドは16オクテットです。最も重要なオクテットが最初に送信されます。この値は、RADIUSサーバーからの応答を認証するために使用され、パスワード非表示アルゴリズムで使用されます。
Request Authenticator
オーセンティケーターのリクエスト
In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness.
Access-Request Packetsでは、Authenticatorの値は16オクテットの乱数で、Request Authenticatorと呼ばれます。同じシークレットと一緒に要求値を繰り返すと攻撃者が以前に傍受した応答で応答できるため、値はシークレット（クライアントとRADIUSサーバー間で共有されるパスワード）の存続期間にわたって予測不可能で一意である必要があります（SHOULD）。異なる地理的領域にあるサーバーで認証するために同じシークレットが使用される可能性があることが予想されるため、リクエスト認証システムフィールドは、グローバルおよび一時的な一意性を示す必要があります。
The Request Authenticator value in an Access-Request packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Access-Request.
Access-RequestパケットのRequest Authenticator値も予測不可能であり、攻撃者がサーバーをだまして、予測された将来の要求に応答させないようにし、その応答を使用して、そのサーバーを将来のAccess-Requestに見せかけます。
Although protocols such as RADIUS are incapable of protecting against theft of an authenticated session via realtime active wiretapping attacks, generation of unique unpredictable requests can protect against a wide range of active attacks against authentication.
RADIUSなどのプロトコルは、リアルタイムのアクティブな盗聴攻撃による認証済みセッションの盗難から保護することはできませんが、独自の予測不可能な要求の生成により、認証に対する幅広いアクティブな攻撃から保護できます。
The NAS and RADIUS server share a secret. That shared secret followed by the Request Authenticator is put through a one-way MD5 hash to create a 16 octet digest value which is xored with the password entered by the user, and the xored result placed in the User-Password attribute in the Access-Request packet. See the entry for User-Password in the section on Attributes for a more detailed description.
NASとRADIUSサーバーはシークレットを共有します。その共有シークレットの後にリクエスト認証システムが続き、一方向MD5ハッシュが実行されて、16オクテットのダイジェスト値が作成されます。これは、ユーザーが入力したパスワードとxorされ、xorされた結果はAccess-のUser-Password属性に配置されます。要求パケット。詳細については、属性のセクションのユーザーパスワードのエントリを参照してください。
Response Authenticator
応答オーセンティケーター
The value of the Authenticator field in Access-Accept, Access-Reject, and Access-Challenge packets is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of: the RADIUS packet, beginning with the Code field, including the Identifier, the Length, the Request Authenticator field from the Access-Request packet, and the response Attributes, followed by the shared secret. That is, ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + denotes concatenation.
Access-Accept、Access-Reject、およびAccess-ChallengeパケットのAuthenticatorフィールドの値は、Response Authenticatorと呼ばれ、以下で構成されるオクテットのストリームで計算された一方向MD5ハッシュが含まれます。 Identifier、Length、Access-RequestパケットのRequest Authenticatorフィールド、応答属性を含むコードフィールド、および共有シークレット。つまり、ResponseAuth = MD5（Code + ID + Length + RequestAuth + Attributes + Secret）で、+は連結を示します。
Administrative Note
管理上の注意
The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged.
シークレット（クライアントとRADIUSサーバー間で共有されるパスワード）は、適切に選択されたパスワードと同じかそれ以上の大きさで、推測できないものにする必要があります（SHOULD）。シークレットは少なくとも16オクテットであることが望ましい。これは、シークレットが十分な範囲を確保して、徹底的な検索攻撃から保護するためです。シークレットを空にすることはできません（長さ0）。これにより、パケットを簡単に偽造できるようになります。
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUSサーバーは、RADIUS要求をプロキシできるように、使用する共有シークレットを決定するためにRADIUS UDPパケットのソースIPアドレスを使用する必要があります。
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction - when the proxy forwards the request, the proxy MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of attributes can be made. Since Access-Accept and Access-Reject replies are authenticated on the entire packet contents, the stripping of the Proxy-State attribute invalidates the signature in the packet - so the proxy has to re-sign it.
転送プロキシを使用する場合、プロキシはパケットが各方向に通過するときにパケットを変更できる必要があります-プロキシがリクエストを転送するとき、プロキシはProxy-State属性を追加できます（MAY）。プロキシが応答を転送するときはプロキシ状態属性を追加した場合は、それを削除します。 Proxy-Stateは常に他のProxy-Stateの後に追加または削除されますが、属性のリスト内でのその場所に関する他の仮定はできません。 Access-AcceptとAccess-Rejectの応答はパケットの内容全体で認証されるため、Proxy-State属性を取り除くと、パケットの署名が無効になるため、プロキシは再署名する必要があります。
Further details of RADIUS proxy implementation are outside the scope of this document.
RADIUSプロキシ実装の詳細は、このドキュメントの範囲外です。
The RADIUS Packet type is determined by the Code field in the first octet of the Packet.
RADIUSパケットタイプは、パケットの最初のオクテットのコードフィールドによって決定されます。
Description
説明
Access-Request packets are sent to a RADIUS server, and convey information used to determine whether a user is allowed access to a specific NAS, and any special services requested for that user. An implementation wishing to authenticate a user MUST transmit a RADIUS packet with the Code field set to 1 (Access-Request).
Access-RequestパケットはRADIUSサーバーに送信され、ユーザーが特定のNASへのアクセスを許可されているかどうかを判断するために使用される情報と、そのユーザーに要求された特別なサービスを伝達します。ユーザーを認証したい実装は、Codeフィールドを1（Access-Request）に設定してRADIUSパケットを送信する必要があります。
Upon receipt of an Access-Request from a valid client, an appropriate reply MUST be transmitted.
有効なクライアントからAccess-Requestを受け取ったら、適切な応答を送信する必要があります。
An Access-Request SHOULD contain a User-Name attribute. It MUST contain either a NAS-IP-Address attribute or a NAS-Identifier attribute (or both).
Access-Requestには、User-Name属性を含める必要があります（SHOULD）。 NAS-IP-Address属性またはNAS-Identifier属性（またはその両方）のいずれかが含まれている必要があります。
An Access-Request MUST contain either a User-Password or a CHAP-Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password.
Access-Requestには、User-PasswordまたはCHAP-PasswordまたはStateのいずれかが含まれている必要があります。 Access-Requestには、ユーザーパスワードとCHAPパスワードの両方を含めることはできません。将来の拡張で他の種類の認証情報の伝達が許可される場合は、その属性をUser-PasswordまたはCHAP-Passwordの代わりにAccess-Requestで使用できます。
An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type attribute or both unless the type of access being requested does not involve a port or the NAS does not distinguish among its ports.
アクセス要求には、NAS-PortまたはNAS-Port-Type属性、あるいはその両方が含まれている必要があります（要求されているアクセスのタイプにポートが含まれていないか、NASがそのポートを区別していない場合を除く）。
An Access-Request MAY contain additional attributes as a hint to the server, but the server is not required to honor the hint.
Access-Requestはサーバーへのヒントとして追加の属性を含むことができますが、サーバーはヒントを尊重する必要はありません。
When a User-Password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5 [3].
ユーザーパスワードが存在する場合、RSAメッセージダイジェストアルゴリズムMD5 [3]に基づく方法を使用して非表示にします。
A summary of the Access-Request packet format is shown below. The fields are transmitted from left to right.
Access-Requestパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
1 for Access-Request.
Access-Requestの場合は1。
Identifier
識別する
The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MUST remain unchanged.
Identifierフィールドは、Attributesフィールドの内容が変更された場合、および前の要求に対して有効な応答が受信された場合は必ず変更する必要があります。再送信の場合、識別子は変更しないでください。
Request Authenticator
オーセンティケーターのリクエスト
The Request Authenticator value MUST be changed each time a new Identifier is used.
新しいIDを使用するたびに、リクエスト認証子の値を変更する必要があります。
Attributes
の属性
The Attribute field is variable in length, and contains the list of Attributes that are required for the type of service, as well as any desired optional Attributes.
Attributeフィールドは可変長であり、サービスのタイプに必要な属性のリストと、必要なオプションの属性が含まれています。
Description
説明
Access-Accept packets are sent by the RADIUS server, and provide specific configuration information necessary to begin delivery of service to the user. If all Attribute values received in an Access-Request are acceptable then the RADIUS implementation MUST transmit a packet with the Code field set to 2 (Access-Accept).
Access-AcceptパケットはRADIUSサーバーによって送信され、ユーザーへのサービスの配信を開始するために必要な特定の構成情報を提供します。 Access-Requestで受信したすべての属性値が受け入れ可能である場合、RADIUS実装は、コードフィールドを2（Access-Accept）に設定してパケットを送信する必要があります。
On reception of an Access-Accept, the Identifier field is matched with a pending Access-Request. The Response Authenticator field MUST contain the correct response for the pending Access-Request. Invalid packets are silently discarded.
Access-Acceptを受信すると、Identifierフィールドは保留中のAccess-Requestと照合されます。 Response Authenticatorフィールドには、保留中のAccess-Requestに対する正しい応答を含める必要があります。無効なパケットは通知なく破棄されます。
A summary of the Access-Accept packet format is shown below. The fields are transmitted from left to right.
Access-Acceptパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
2 for Access-Accept.
Access-Acceptの場合は2。
Identifier
識別する
The Identifier field is a copy of the Identifier field of the Access-Request which caused this Access-Accept.
Identifierフィールドは、このAccess-Acceptの原因となったAccess-RequestのIdentifierフィールドのコピーです。
Response Authenticator
応答オーセンティケーター
The Response Authenticator value is calculated from the Access-Request value, as described earlier.
前述のように、応答認証値はAccess-Request値から計算されます。
Attributes
の属性
The Attribute field is variable in length, and contains a list of zero or more Attributes.
属性フィールドの長さは可変であり、ゼロ個以上の属性のリストが含まれています。
Description
説明
If any value of the received Attributes is not acceptable, then the RADIUS server MUST transmit a packet with the Code field set to 3 (Access-Reject). It MAY include one or more Reply-Message Attributes with a text message which the NAS MAY display to the user.
受信した属性の値が受け入れられない場合、RADIUSサーバーは、コードフィールドを3（Access-Reject）に設定してパケットを送信する必要があります。 NASがユーザーに表示するテキストメッセージに1つ以上の返信メッセージ属性を含めることができます。
A summary of the Access-Reject packet format is shown below. The fields are transmitted from left to right.
Access-Rejectパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
3 for Access-Reject.
Access-Rejectの場合は3。
Identifier
識別する
The Identifier field is a copy of the Identifier field of the Access-Request which caused this Access-Reject.
Identifierフィールドは、このAccess-Rejectの原因となったAccess-RequestのIdentifierフィールドのコピーです。
Response Authenticator
応答オーセンティケーター
The Response Authenticator value is calculated from the Access-Request value, as described earlier.
前述のように、応答認証値はAccess-Request値から計算されます。
Attributes
の属性
The Attribute field is variable in length, and contains a list of zero or more Attributes.
属性フィールドの長さは可変であり、ゼロ個以上の属性のリストが含まれています。
Description
説明
If the RADIUS server desires to send the user a challenge requiring a response, then the RADIUS server MUST respond to the Access-Request by transmitting a packet with the Code field set to 11 (Access-Challenge).
RADIUSサーバーがユーザーに応答を要求するチャレンジを送信することを望む場合、RADIUSサーバーは、コードフィールドを11（Access-Challenge）に設定してパケットを送信することにより、Access-Requestに応答する必要があります。
The Attributes field MAY have one or more Reply-Message Attributes, and MAY have a single State Attribute, or none. Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State attributes MAY also be included. No other Attributes defined in this document are permitted in an Access-Challenge.
属性フィールドには1つ以上の返信メッセージ属性が含まれる場合があり、単一の状態属性を持つ場合とない場合があります。ベンダー固有、アイドルタイムアウト、セッションタイムアウト、およびプロキシ状態の属性も含めることができます。このドキュメントで定義されている他の属性は、Access-Challengeでは許可されていません。
On receipt of an Access-Challenge, the Identifier field is matched with a pending Access-Request. Additionally, the Response Authenticator field MUST contain the correct response for the pending Access-Request. Invalid packets are silently discarded.
Access-Challengeを受信すると、Identifierフィールドは保留中のAccess-Requestと照合されます。さらに、Response Authenticatorフィールドには、保留中のAccess-Requestに対する正しい応答が含まれている必要があります。無効なパケットは通知なく破棄されます。
If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead.
NASがチャレンジ/レスポンスをサポートしない場合、NASは代わりにAccess-Rejectを受信したかのようにAccess-Challengeを処理する必要があります。
If the NAS supports challenge/response, receipt of a valid Access-Challenge indicates that a new Access-Request SHOULD be sent. The NAS MAY display the text message, if any, to the user, and then prompt the user for a response. It then sends its original Access-Request with a new request ID and Request Authenticator, with the User-Password Attribute replaced by the user's response (encrypted), and including the State Attribute from the Access-Challenge, if any. Only 0 or 1 instances of the State Attribute can be present in an Access-Request.
NASがチャレンジ/レスポンスをサポートしている場合、有効なAccess-Challengeを受信すると、新しいAccess-Requestを送信する必要があります（SHOULD）。 NASはテキストメッセージがあればそれをユーザーに表示し、ユーザーに応答を要求する場合があります。次に、元のAccess-Requestを新しい要求IDと要求オーセンティケーターで送信します。User-Password属性はユーザーの応答（暗号化）に置き換えられ、必要に応じてAccess-ChallengeからのState属性が含まれます。状態属性の0または1つのインスタンスのみがAccess-Requestに存在できます。
A NAS which supports PAP MAY forward the Reply-Message to the dialing client and accept a PAP response which it can use as though the user had entered the response. If the NAS cannot do so, it MUST treat the Access-Challenge as though it had received an Access-Reject instead.
PAPをサポートするNASは、応答メッセージをダイヤリングクライアントに転送し、ユーザーが応答を入力したかのように使用できるPAP応答を受け入れることができます。 NASがそうできない場合、NASはAccess-Challengeを、代わりにAccess-Rejectを受信したかのように処理する必要があります。
A summary of the Access-Challenge packet format is shown below. The fields are transmitted from left to right.
Access-Challengeパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
11 for Access-Challenge.
Access-Challengeの場合は11。
Identifier
識別する
The Identifier field is a copy of the Identifier field of the Access-Request which caused this Access-Challenge.
Identifierフィールドは、このAccess-Challengeの原因となったAccess-RequestのIdentifierフィールドのコピーです。
Response Authenticator
応答オーセンティケーター
The Response Authenticator value is calculated from the Access-Request value, as described earlier.
前述のように、応答認証値はAccess-Request値から計算されます。
Attributes
の属性
The Attributes field is variable in length, and contains a list of zero or more Attributes.
属性フィールドの長さは可変であり、0個以上の属性のリストが含まれます。
RADIUS Attributes carry the specific authentication, authorization, information and configuration details for the request and reply.
RADIUS属性には、要求と応答に関する特定の認証、承認、情報、および構成の詳細が含まれます。
The end of the list of Attributes is indicated by the Length of the RADIUS packet.
属性のリストの最後は、RADIUSパケットの長さで示されます。
Some Attributes MAY be included more than once. The effect of this is Attribute specific, and is specified in each Attribute description. A summary table is provided at the end of the "Attributes" section.
一部の属性は複数回含めることができます。この効果は属性固有であり、各属性の説明で指定されています。概要の表は、「属性」セクションの最後にあります。
If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of attributes of different types. A RADIUS server or client MUST NOT require attributes of the same type to be contiguous.
同じタイプの属性が複数存在する場合、同じタイプの属性の順序はプロキシによって保持されなければなりません（MUST）。異なるタイプの属性の順序を保持する必要はありません。 RADIUSサーバーまたはクライアントは、異なるタイプの属性の順序に依存してはいけません。 RADIUSサーバーまたはクライアントは、同じタイプの属性が連続していることを要求してはなりません（MUST NOT）。
Where an Attribute's description limits which kinds of packet it can be contained in, this applies only to the packet types defined in this document, namely Access-Request, Access-Accept, Access-Reject and Access-Challenge (Codes 1, 2, 3, and 11). Other documents defining other packet types may also use Attributes described here. To determine which Attributes are allowed in Accounting-Request and Accounting-Response packets (Codes 4 and 5) refer to the RADIUS Accounting document [5].
属性の説明によって、含まれる可能性のあるパケットの種類が制限される場合、これは、このドキュメントで定義されているパケットタイプ、つまりAccess-Request、Access-Accept、Access-Reject、およびAccess-Challenge（コード1、2、3 、および11）。他のパケットタイプを定義する他のドキュメントでも、ここで説明する属性を使用できます。 Accounting-RequestおよびAccounting-Responseパケット（コード4および5）で許可される属性を判別するには、RADIUSアカウンティングドキュメント[5]を参照してください。
Likewise where packet types defined here state that only certain Attributes are permissible in them, future memos defining new Attributes should indicate which packet types the new Attributes may be present in.
同様に、ここで定義されたパケットタイプが特定の属性のみが許可されると述べている場合、新しい属性を定義する将来のメモは、新しい属性がどのパケットタイプに存在するかを示す必要があります。
A summary of the Attribute format is shown below. The fields are transmitted from left to right.
属性フォーマットの要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
The Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [6]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used.
Typeフィールドは1オクテットです。 RADIUSタイプフィールドの最新の値は、最新の「割り当てられた番号」RFC [6]で指定されています。値192-223は実験的使用のために予約され、値224-240は実装固有の使用のために予約され、値241-255は予約されており、使用しないでください。
A RADIUS server MAY ignore Attributes with an unknown Type.
RADIUSサーバーは、不明なタイプの属性を無視してもよい（MAY）。
A RADIUS client MAY ignore Attributes with an unknown Type.
RADIUSクライアントは、不明なタイプの属性を無視してもよい（MAY）。
This specification concerns the following values:
この仕様は次の値に関係します。
1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34 Login-LAT-Service 35 Login-LAT-Node 36 Login-LAT-Group 37 Framed-AppleTalk-Link 38 Framed-AppleTalk-Network 39 Framed-AppleTalk-Zone 40-59 (reserved for accounting) 60 CHAP-Challenge 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port
1ユーザー名2ユーザーパスワード3 CHAPパスワード4 NAS-IPアドレス5 NASポート6サービスタイプ7フレームプロトコル8フレームIPアドレス9フレームIPネットマスク10フレームルーティング11フィルターID 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17（unassigned）18 Reply-Message 19 Callback-Number 20 Callback-Id 21（unassigned）22 Framed-Route 23 Framed -IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34 Login-LAT-Service 35 Login-LAT-Node 36 Login-LAT-Group 37 Framed-AppleTalk-Link 38 Framed-AppleTalk-Network 39 Framed-AppleTalk-Zone 40-59（accounting用に予約済み）60 CHAP-Challenge 61 NAS-Port-Type 62ポート-Limit 63ログイン-LAT-ポート
Length
長さ
The Length field is one octet, and indicates the length of this Attribute including the Type, Length and Value fields. If an Attribute is received in an Access-Request but with an invalid Length, an Access-Reject SHOULD be transmitted. If an Attribute is received in an Access-Accept, Access-Reject or Access-Challenge packet with an invalid length, the packet MUST either be treated as an Access-Reject or else silently discarded.
長さフィールドは1オクテットであり、タイプ、長さ、値フィールドを含むこの属性の長さを示します。属性がAccess-Requestで受信されたが、無効な長さの場合、Access-Rejectを送信する必要があります（SHOULD）。無効な長さの属性がAccess-Accept、Access-Reject、またはAccess-Challengeパケットで受信された場合、パケットはAccess-Rejectとして扱われるか、または黙って破棄されなければなりません（MUST）。
Value
値
The Value field is zero or more octets and contains information specific to the Attribute. The format and length of the Value field is determined by the Type and Length fields.
値フィールドは0オクテット以上であり、属性に固有の情報が含まれます。 「値」フィールドのフォーマットと長さは、「タイプ」フィールドと「長さ」フィールドによって決まります。
Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings.
RADIUSのどのタイプもNUL（16進00）で終了しないことに注意してください。特に、RADIUSのタイプ「テキスト」と「文字列」は、NUL（16進数00）で終了しません。属性には長さフィールドがあり、ターミネーターを使用しません。テキストにはUTF-8でエンコードされた10646 [7]文字が含まれ、文字列には8ビットのバイナリデータが含まれます。サーバーおよびサーバーとクライアントは、埋め込まれたnullを処理できなければなりません。 Cを使用するRADIUS実装者は、文字列を処理するときにstrcpy()を使用しないように注意してください。
The format of the value field is one of five data types. Note that type "text" is a subset of type "string".
値フィールドの形式は、5つのデータ型のうちの1つです。タイプ「テキスト」はタイプ「文字列」のサブセットであることに注意してください。
text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.
テキストUTF-8でエンコードされた10646 [7]文字を含む1〜253オクテット。長さがゼロ（0）のテキストは送信してはならない（MUST NOT）。代わりに、属性全体を省略してください。
string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead.
バイナリデータを含む文字列1-253オクテット（0〜255の10進数の値）。長さがゼロ（0）のストリングは送信してはなりません（MUST NOT）。代わりに、属性全体を省略してください。
address 32 bit value, most significant octet first.
アドレス32ビット値、最上位オクテットが最初。
integer 32 bit unsigned value, most significant octet first.
整数32ビット符号なし値、最上位オクテットが最初。
time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes.
時間32ビットの符号なし値、最上位オクテットが最初-1970年1月1日00:00:00 UTCからの秒数。標準属性はこのデータ型を使用しませんが、将来の属性で使用できるようにここに提示されています。
Description
説明
This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available.
この属性は、認証されるユーザーの名前を示します。可能な場合は、Access-Requestパケットで送信する必要があります。
It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session. If the Access-Accept includes Service-Type = Rlogin and the User-Name attribute, a NAS MAY use the returned User-Name when performing the Rlogin function.
Access-Acceptパケットで送信される場合があります。その場合、クライアントは、このセッションのすべてのAccounting-RequestパケットのAccess-Acceptパケットで返された名前を使用する必要があります（SHOULD）。 Access-AcceptにService-Type = RloginとUser-Name属性が含まれている場合、NASはRlogin機能を実行するときに返されたUser-Nameを使用できます（MAY）。
A summary of the User-Name Attribute format is shown below. The fields are transmitted from left to right.
ユーザー名属性の形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
1 for User-Name.
ユーザー名の場合は1。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets. The NAS may limit the maximum length of the User-Name but the ability to handle at least 63 octets is recommended.
文字列フィールドは1つ以上のオクテットです。 NASはユーザー名の最大長を制限する場合がありますが、少なくとも63オクテットを処理する機能が推奨されます。
The format of the username MAY be one of several forms:
ユーザー名の形式は、いくつかの形式のいずれかになります。
text Consisting only of UTF-8 encoded 10646 [7] characters.
テキストUTF-8でエンコードされた10646 [7]文字のみで構成されます。
network access identifier A Network Access Identifier as described in RFC 2486 [8].
ネットワークアクセス識別子RFC 2486 [8]で説明されているネットワークアクセス識別子。
distinguished name A name in ASN.1 form used in Public Key authentication systems.
識別名公開鍵認証システムで使用されるASN.1形式の名前。
Description
説明
This Attribute indicates the password of the user to be authenticated, or the user's input following an Access-Challenge. It is only used in Access-Request packets.
この属性は、認証されるユーザーのパスワード、またはAccess-Challengeに続くユーザーの入力を示します。 Access-Requestパケットでのみ使用されます。
On transmission, the password is hidden. The password is first padded at the end with nulls to a multiple of 16 octets. A one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the Request Authenticator. This value is XORed with the first 16 octet segment of the password and placed in the first 16 octets of the String field of the User-Password Attribute.
送信時に、パスワードは非表示になります。パスワードは最初に、16オクテットの倍数になるようにヌルで末尾が埋め込まれます。一方向のMD5ハッシュは、共有シークレットとそれに続く要求オーセンティケーターで構成されるオクテットのストリームに対して計算されます。この値は、パスワードの最初の16オクテットセグメントとXORされ、ユーザーパスワード属性の文字列フィールドの最初の16オクテットに配置されます。
If the password is longer than 16 characters, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first xor. That hash is XORed with the second 16 octet segment of the password and placed in the second 16 octets of the String field of the User-Password Attribute.
パスワードが16文字より長い場合、2番目の一方向MD5ハッシュは、共有シークレットとそれに続く最初のxorの結果で構成されるオクテットのストリームに対して計算されます。そのハッシュは、パスワードの2番目の16オクテットセグメントとXORされ、ユーザーパスワード属性の文字列フィールドの2番目の16オクテットに配置されます。
If necessary, this operation is repeated, with each xor result being used along with the shared secret to generate the next hash to xor the next segment of the password, to no more than 128 characters.
必要に応じて、この操作が繰り返され、各xor結果が共有シークレットと共に使用されて、パスワードの次のセグメントをxorする次のハッシュを生成し、128文字以下にします。
The method is taken from the book "Network Security" by Kaufman, Perlman and Speciner [9] pages 109-110. A more precise explanation of the method follows:
この方法は、Kaufman、Perlman、およびSpeciner [9]の109〜110ページの著書「Network Security」から引用されています。メソッドのより正確な説明は次のとおりです。
Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. Break the password into 16-octet chunks p1, p2, etc. with the last one padded at the end with nulls to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need intermediate values b1, b2, etc.
共有シークレットSと疑似ランダム128ビットリクエストオーセンティケーターRAを呼び出します。パスワードを16オクテットのチャンクp1、p2などに分割します。最後の1つは、16オクテットの境界までヌルで埋められます。暗号文ブロックc（1）、c（2）などを呼び出します。中間値b1、b2などが必要になります。
b1 = MD5(S + RA) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation.
文字列にはc（1）+ c（2）+ ... + c（i）が含まれ、+は連結を示します。
On receipt, the process is reversed to yield the original password.
受信すると、元のパスワードを生成するためにプロセスが逆になります。
A summary of the User-Password Attribute format is shown below. The fields are transmitted from left to right.
User-Password Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
2 for User-Password.
ユーザーパスワードの場合は2。
Length
長さ
At least 18 and no larger than 130.
18以上130以下。
String
ストリング
The String field is between 16 and 128 octets long, inclusive.
文字列フィールドは、16〜128オクテットの長さです。
Description
説明
This Attribute indicates the response value provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge. It is only used in Access-Request packets.
この属性は、チャレンジへの応答としてPPPチャレンジハンドシェイク認証プロトコル（CHAP）ユーザーによって提供される応答値を示します。 Access-Requestパケットでのみ使用されます。
The CHAP challenge value is found in the CHAP-Challenge Attribute (60) if present in the packet, otherwise in the Request Authenticator field.
CHAPチャレンジ値は、パケットに存在する場合はCHAP-Challenge Attribute（60）にあり、それ以外の場合はRequest Authenticatorフィールドにあります。
A summary of the CHAP-Password Attribute format is shown below. The fields are transmitted from left to right.
CHAP-Password Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
3 for CHAP-Password.
CHAP-Passwordの場合は3。
Length
長さ
19
１９
CHAP Ident
CHAP Ident
This field is one octet, and contains the CHAP Identifier from the user's CHAP Response.
このフィールドは1オクテットで、ユーザーのCHAP応答からのCHAP IDが含まれます。
String
ストリング
The String field is 16 octets, and contains the CHAP Response from the user.
文字列フィールドは16オクテットで、ユーザーからのCHAP応答が含まれます。
Description
説明
This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP-Address is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST be present in an Access-Request packet.
この属性は、ユーザーの認証を要求しているNASの識別IPアドレスを示し、RADIUSサーバーのスコープ内でNASに対して一意である必要があります。 NAS-IP-Addressは、Access-Requestパケットでのみ使用されます。 NAS-IP-AddressまたはNAS-IdentifierのいずれかがAccess-Requestパケットに存在する必要があります。
Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret.
NAS-IP-Addressは、リクエストの認証に使用される共有シークレットを選択するために使用してはならないことに注意してください。共有シークレットを選択するには、Access-RequestパケットのソースIPアドレスを使用する必要があります。
A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right.
NAS-IP-Address 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
4 for NAS-IP-Address.
NAS-IP-Addressの場合は4。
Length
長さ
6
６
Address
住所
The Address field is four octets.
アドレスフィールドは4オクテットです。
Description
説明
This Attribute indicates the physical port number of the NAS which is authenticating the user. It is only used in Access-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports.
この属性は、ユーザーを認証しているNASの物理ポート番号を示します。 Access-Requestパケットでのみ使用されます。これは、TCPまたはUDPポート番号の意味ではなく、NAS上の物理接続の意味で「ポート」を使用していることに注意してください。 NASがポート間で区別する場合、NAS-PortまたはNAS-Port-Type（61）のいずれか、または両方がAccess-Requestパケットに存在する必要があります（SHOULD）。
A summary of the NAS-Port Attribute format is shown below. The fields are transmitted from left to right.
NAS-Port 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5 for NAS-Port.
NASポートの場合は5。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
Description
説明
This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead.
この属性は、ユーザーが要求したサービスのタイプ、または提供されるサービスのタイプを示します。 Access-RequestパケットとAccess-Acceptパケットの両方で使用される場合があります。 NASはこれらのサービスタイプのすべてを実装する必要はなく、Access-Rejectが代わりに受信されたかのように、不明またはサポートされていないサービスタイプを処理する必要があります。
A summary of the Service-Type Attribute format is shown below. The fields are transmitted from left to right.
Service-Type 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6 for Service-Type.
Service-Typeの場合は6。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
1 Login 2 Framed 3 Callback Login 4 Callback Framed 5 Outbound 6 Administrative 7 NAS Prompt 8 Authenticate Only 9 Callback NAS Prompt 10 Call Check 11 Callback Administrative The service types are defined as follows when used in an Access-Accept. When used in an Access-Request, they MAY be considered to be a hint to the RADIUS server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint.
1ログイン2フレーム化3コールバックログイン4コールバックフレーム化5アウトバウンド6管理7 NASプロンプト8認証のみ9コールバックNASプロンプト10コールチェック11コールバック管理サービスタイプは、Access-Acceptで使用される場合、次のように定義されます。 Access-Requestで使用される場合、それらはRADIUSサーバーへのヒントであると見なされる場合があり、NASはユーザーが示された種類のサービスを好むと信じる理由がありますが、サーバーはヒントを尊重する必要はありません。
Login The user should be connected to a host.
ログインユーザーはホストに接続する必要があります。
Framed A Framed Protocol should be started for the User, such as PPP or SLIP.
フレーム化フレーム化プロトコルは、PPPやSLIPなどのユーザーに対して開始する必要があります。
Callback Login The user should be disconnected and called back, then connected to a host.
コールバックログインユーザーは切断され、コールバックされてから、ホストに接続する必要があります。
Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP.
フレーム化されたコールバックユーザーを切断してコールバックし、PPPやSLIPなどのフレーム化されたプロトコルをユーザーに対して開始する必要があります。
Outbound The user should be granted access to outgoing devices.
アウトバウンドユーザーには、アウトバウンドデバイスへのアクセスが許可されている必要があります。
Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed.
管理ユーザーは、特権コマンドを実行できるNASへの管理インターフェースへのアクセスを許可されている必要があります。
NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed.
NASプロンプトユーザーには、非特権コマンドを実行できるNASのコマンドプロンプトを提供する必要があります。
Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself).
Authenticate Only Authenticationが要求され、認証情報をAccess-Acceptで返す必要はありません（通常、NAS自体ではなくプロキシサーバーによって使用されます）。
Callback NAS Prompt The user should be disconnected and called back, then provided a command prompt on the NAS from which non-privileged commands can be executed.
NASプロンプトのコールバックユーザーは、切断されてコールバックされ、非特権コマンドを実行できるコマンドプロンプトをNASに提供します。
Call Check Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name.
NASがAccess-Requestパケットで使用するコールチェックは、コールが受信されており、RADIUSサーバーがAccess-Acceptを返信してコールに応答するか、Access-Rejectがコールを受け入れないことを示します。 Called-Station-Id属性またはCalling-Station-Id属性。このようなAccess-Requestでは、User-Nameの値としてCalling-Station-Idの値を使用することをお勧めします。
Callback Administrative The user should be disconnected and called back, then granted access to the administrative interface to the NAS from which privileged commands can be executed.
コールバック管理ユーザーは切断され、コールバックされてから、特権コマンドを実行できるNASへの管理インターフェースへのアクセスを許可されます。
Description
説明
This Attribute indicates the framing to be used for framed access. It MAY be used in both Access-Request and Access-Accept packets.
この属性は、フレーム化されたアクセスに使用されるフレーミングを示します。 Access-RequestパケットとAccess-Acceptパケットの両方で使用される場合があります。
A summary of the Framed-Protocol Attribute format is shown below. The fields are transmitted from left to right.
Framed-Protocol 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7 for Framed-Protocol.
Framed-Protocolの場合は7。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
1 PPP 2 SLIP 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 5 Xylogics proprietary IPX/SLIP 6 X.75 Synchronous
1 PPP 2 SLIP 3 AppleTalkリモートアクセスプロトコル（ARAP）4 Gandalf独自のSingleLink / MultiLinkプロトコル5 Xylogics独自のIPX / SLIP 6 X.75同期
Description
説明
This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint.
この属性は、ユーザーに構成するアドレスを示します。 Access-Acceptパケットで使用される場合があります。 NASからサーバーへのそのアドレスを優先するヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Framed-IP-Address Attribute format is shown below. The fields are transmitted from left to right.
Framed-IP-Address 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8 for Framed-IP-Address.
Framed-IP-Addressの場合は8。
Length
長さ
6
６
Address
住所
The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address.
アドレスフィールドは4オクテットです。値0xFFFFFFFFは、NASがユーザーにアドレスの選択を許可する必要があることを示します（例：交渉済み）。値0xFFFFFFFEは、NASがユーザーのアドレスを選択する必要があることを示します（例：NASが保持するアドレスのプールから割り当てられる）。他の有効な値は、NASがその値をユーザーのIPアドレスとして使用する必要があることを示します。
Description
説明
This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint.
この属性は、ユーザーがネットワークへのルーターである場合にユーザーに対して構成するIPネットマスクを示します。 Access-Acceptパケットで使用される場合があります。 NASからサーバーへのネットマスクを優先するヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Framed-IP-Netmask Attribute format is shown below. The fields are transmitted from left to right.
Framed-IP-Netmask 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
9 for Framed-IP-Netmask.
Framed-IP-Netmaskの場合は9。
Length
長さ
6
６
Address
住所
The Address field is four octets specifying the IP netmask of the user.
アドレスフィールドは、ユーザーのIPネットマスクを指定する4つのオクテットです。
Description
説明
This Attribute indicates the routing method for the user, when the user is a router to a network. It is only used in Access-Accept packets.
この属性は、ユーザーがネットワークへのルーターである場合の、ユーザーのルーティング方法を示します。 Access-Acceptパケットでのみ使用されます。
A summary of the Framed-Routing Attribute format is shown below. The fields are transmitted from left to right.
Framed-Routing 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
10 for Framed-Routing.
フレームルーティングの場合は10。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
0 None 1 Send routing packets 2 Listen for routing packets 3 Send and Listen
0なし1ルーティングパケットを送信2ルーティングパケットをリッスン3送信とリッスン
Description
説明
This Attribute indicates the name of the filter list for this user. Zero or more Filter-Id attributes MAY be sent in an Access-Accept packet.
この属性は、このユーザーのフィルターリストの名前を示します。 0個以上のFilter-Id属性がAccess-Acceptパケットで送信される場合があります。
Identifying a filter list by name allows the filter to be used on different NASes without regard to filter-list implementation details.
名前でフィルターリストを識別すると、フィルターリストの実装の詳細に関係なく、フィルターをさまざまなBASで使用できます。
A summary of the Filter-Id Attribute format is shown below. The fields are transmitted from left to right.
Filter-Id Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
11 for Filter-Id.
Filter-Idの場合は11。
Length
長さ
>= 3
＞＝ ３
Text
テキスト
The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters.
Textフィールドは1つ以上のオクテットであり、その内容は実装に依存します。それは人間が読めるように意図されており、プロトコルの操作に影響を与えてはなりません。メッセージには、UTF-8でエンコードされた10646 [7]文字を含めることをお勧めします。
Description
説明
This Attribute indicates the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that value, but the server is not required to honor the hint.
この属性は、他の手段（PPPなど）によってネゴシエートされない場合に、ユーザーに対して構成する最大転送単位を示します。 Access-Acceptパケットで使用される場合があります。 NASからサーバーへのヒントとしてその値を好むというヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Framed-MTU Attribute format is shown below. The fields are transmitted from left to right.
Framed-MTU 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
12 for Framed-MTU.
Framed-MTUの場合は12。
Length
長さ
6
６
Value
値
The Value field is four octets. Despite the size of the field, values range from 64 to 65535.
Valueフィールドは4オクテットです。フィールドのサイズにかかわらず、値の範囲は64〜65535です。
Description
説明
This Attribute indicates a compression protocol to be used for the link. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint.
この属性は、リンクに使用される圧縮プロトコルを示します。 Access-Acceptパケットで使用される場合があります。 NASがその圧縮を使用することを好むサーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
More than one compression protocol Attribute MAY be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic.
複数の圧縮プロトコル属性を送信できます。適切な圧縮プロトコルを適切なリンクトラフィックに適用するのは、NASの責任です。
A summary of the Framed-Compression Attribute format is shown below. The fields are transmitted from left to right.
Framed-Compression 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
13 for Framed-Compression.
Framed-Compressionの場合は13。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
0 None 1 VJ TCP/IP header compression [10] 2 IPX header compression 3 Stac-LZS compression
0なし1 VJ TCP / IPヘッダー圧縮[10] 2 IPXヘッダー圧縮3 Stac-LZS圧縮
Description
説明
This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint.
この属性は、Login-Service属性が含まれている場合に、ユーザーを接続するシステムを示します。 Access-Acceptパケットで使用される場合があります。 NASがそのホストを使用することを好むサーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Login-IP-Host Attribute format is shown below. The fields are transmitted from left to right.
Login-IP-Host 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
14 for Login-IP-Host.
Login-IP-Hostの場合は14。
Length
長さ
6
６
Address
住所
The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to.
アドレスフィールドは4オクテットです。値0xFFFFFFFFは、NASがユーザーにアドレスの選択を許可する必要があることを示します。値0は、NASがユーザーを接続するホストを選択する必要があることを示します。他の値は、NASがユーザーを接続する必要があるアドレスを示します。
Description
説明
This Attribute indicates the service to use to connect the user to the login host. It is only used in Access-Accept packets.
この属性は、ユーザーをログインホストに接続するために使用するサービスを示します。 Access-Acceptパケットでのみ使用されます。
A summary of the Login-Service Attribute format is shown below. The fields are transmitted from left to right.
Login-Service 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
15 for Login-Service.
ログインサービスの場合は15。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
0 Telnet 1 Rlogin 2 TCP Clear 3 PortMaster (proprietary) 4 LAT 5 X25-PAD 6 X25-T3POS 8 TCP Clear Quiet (suppresses any NAS-generated connect string)
0 Telnet 1 Rlogin 2 TCP Clear 3 PortMaster（独自仕様）4 LAT 5 X25-PAD 6 X25-T3POS 8 TCP Clear Quiet（NASで生成された接続文字列を抑制）
Description
説明
This Attribute indicates the TCP port with which the user is to be connected, when the Login-Service Attribute is also present. It is only used in Access-Accept packets.
この属性は、Login-Service属性も存在する場合に、ユーザーが接続するTCPポートを示します。 Access-Acceptパケットでのみ使用されます。
A summary of the Login-TCP-Port Attribute format is shown below. The fields are transmitted from left to right.
Login-TCP-Port 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
16 for Login-TCP-Port.
Login-TCP-Portの場合は16。
Length
長さ
6
６
Value
値
The Value field is four octets. Despite the size of the field, values range from 0 to 65535.
Valueフィールドは4オクテットです。フィールドのサイズにかかわらず、値の範囲は0〜65535です。
Description
説明
ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
属性タイプ17は割り当てられていません。
Description
説明
This Attribute indicates text which MAY be displayed to the user.
この属性は、ユーザーに表示できるテキストを示します。
When used in an Access-Accept, it is the success message.
Access-Acceptで使用される場合、これは成功メッセージです。
When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt.
Access-Rejectで使用される場合、それは失敗メッセージです。別のAccess-Requestを試行する前にユーザーにプロンプトを出すダイアログメッセージを示す場合があります。
When used in an Access-Challenge, it MAY indicate a dialog message to prompt the user for a response.
Access-Challengeで使用される場合、ユーザーに応答を求めるダイアログメッセージを示す場合があります。
Multiple Reply-Message's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet.
複数のReply-Messageが含まれる場合があり、表示される場合は、パケットに表示されるのと同じ順序で表示する必要があります。
A summary of the Reply-Message Attribute format is shown below. The fields are transmitted from left to right.
Reply-Message Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
18 for Reply-Message.
Reply-Messageの場合は18。
Length
長さ
>= 3
＞＝ ３
Text
テキスト
The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters.
Textフィールドは1つ以上のオクテットであり、その内容は実装に依存します。それは人間が読めるように意図されており、プロトコルの操作に影響を与えてはなりません。メッセージには、UTF-8でエンコードされた10646 [7]文字を含めることをお勧めします。
Description
説明
This Attribute indicates a dialing string to be used for callback. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that a Callback service is desired, but the server is not required to honor the hint.
この属性は、コールバックに使用されるダイヤル文字列を示します。 Access-Acceptパケットで使用される場合があります。これは、コールバックサービスが必要であることをサーバーへのヒントとしてAccess-Requestパケットで使用できますが、サーバーはヒントを受け入れる必要はありません。
A summary of the Callback-Number Attribute format is shown below. The fields are transmitted from left to right.
Callback-Number Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
19 for Callback-Number.
コールバック番号の場合は19。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute indicates the name of a place to be called, to be interpreted by the NAS. It MAY be used in Access-Accept packets.
この属性は、NASによって解釈される、呼び出される場所の名前を示します。 Access-Acceptパケットで使用される場合があります。
A summary of the Callback-Id Attribute format is shown below. The fields are transmitted from left to right.
Callback-Id Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
20 for Callback-Id.
Callback-Idの場合は20。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
属性タイプ21は割り当てられていません。
Description
説明
This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times.
この属性は、NASのユーザーに対して構成するルーティング情報を提供します。 Access-Acceptパケットで使用され、複数回出現する可能性があります。
A summary of the Framed-Route Attribute format is shown below. The fields are transmitted from left to right.
Framed-Route Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
22 for Framed-Route.
Framed-Routeの場合は22。
Length
長さ
>= 3
＞＝ ３
Text
テキスト
The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters.
Textフィールドは1つ以上のオクテットであり、その内容は実装に依存します。それは人間が読めるように意図されており、プロトコルの操作に影響を与えてはなりません。メッセージには、UTF-8でエンコードされた10646 [7]文字を含めることをお勧めします。
For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted, in which case it defaults to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
IPルートの場合、ドット付きクワッド形式の宛先接頭辞がオプションで含まれ、その後にスラッシュと、使用する接頭辞の上位ビット数を示す10進数の長さ指定子が続く必要があります（SHOULD）。その後にスペース、ドット付きクワッド形式のゲートウェイアドレス、スペース、スペースで区切られた1つ以上のメトリックが続きます。たとえば、「192.168.1.0/24 192.168.1.1 1 2 -1 3 400」です。長さ指定子は省略できます。その場合、デフォルトで、クラスAプレフィックスは8ビット、クラスBプレフィックスは16ビット、クラスCプレフィックスは24ビットになります。たとえば、「192.168.1.0 192.168.1.1 1」です。
Whenever the gateway address is specified as "0.0.0.0" the IP address of the user SHOULD be used as the gateway address.
ゲートウェイアドレスが「0.0.0.0」と指定されている場合は常に、ユーザーのIPアドレスをゲートウェイアドレスとして使用する必要があります（SHOULD）。
Description
説明
This Attribute indicates the IPX Network number to be configured for the user. It is used in Access-Accept packets.
この属性は、ユーザーに構成するIPXネットワーク番号を示します。 Access-Acceptパケットで使用されます。
A summary of the Framed-IPX-Network Attribute format is shown below. The fields are transmitted from left to right.
Framed-IPX-Network 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type
23 for Framed-IPX-Network.
Framed-IPX-Networkの場合は23。
Length
長さ
6
６
Value
値
The Value field is four octets. The value 0xFFFFFFFE indicates that the NAS should select an IPX network for the user (e.g. assigned from a pool of one or more IPX networks kept by the NAS). Other values should be used as the IPX network for the link to the user.
Valueフィールドは4オクテットです。値0xFFFFFFFEは、NASがユーザーのIPXネットワークを選択する必要があることを示します（たとえば、NASが保持する1つ以上のIPXネットワークのプールから割り当てられます）。他の値は、ユーザーへのリンクのIPXネットワークとして使用する必要があります。
Description
説明
This Attribute is available to be sent by the server to the client in an Access-Challenge and MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any.
この属性は、サーバーからクライアントにAccess-Challengeで送信するために使用でき、チャレンジがある場合は、その新しいAccess-Request応答でクライアントからサーバーに変更せずに送信する必要があります。
This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State attribute unchanged in that Access-Request.
この属性は、RADIUS-Requestの値を持つTermination-Action属性を含むAccess-Acceptでサーバーからクライアントに送信するために使用できます。 NASが現在のセッションの終了時に新しいAccess-Requestを送信してTermination-Actionを実行する場合、NASはそのAccess-Requestに変更されていないState属性を含める必要があります。
In either usage, the client MUST NOT interpret the attribute locally. A packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent.
どちらの使用法でも、クライアントは属性をローカルで解釈してはなりません（MUST NOT）。パケットには、ゼロまたは1つの状態属性のみが含まれている必要があります。状態属性の使用は実装に依存します。
A summary of the State Attribute format is shown below. The fields are transmitted from left to right.
状態属性フォーマットの要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
24 for State.
州の場合は24。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. The client MUST NOT interpret the attribute locally.
この属性は、サーバーからAccess-Acceptでクライアントに送信でき、アカウンティングがサポートされている場合は、アカウンティング要求パケットの一部としてクライアントからアカウンティングサーバーに変更されずに送信する必要があります。クライアントは属性をローカルで解釈してはいけません（MUST NOT）。
A summary of the Class Attribute format is shown below. The fields are transmitted from left to right.
クラス属性フォーマットの要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
25 for Class.
クラスの場合は25。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute is available to allow vendors to support their own extended Attributes not suitable for general usage. It MUST not affect the operation of the RADIUS protocol.
この属性を使用すると、ベンダーは、一般的な使用には適さない独自の拡張属性をサポートできます。 RADIUSプロトコルの動作に影響を与えてはなりません（MUST NOT）。
Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.
クライアントから送信されたベンダー固有の情報を解釈する機能を備えていないサーバーは、それを無視する必要があります（報告される場合があります）。必要なベンダー固有の情報を受信しないクライアントは、それなしで動作するように試みるべきです（SHOULD）。
A summary of the Vendor-Specific 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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
26 for Vendor-Specific.
ベンダー固有の場合は26。
Length
長さ
>= 7
＞＝ ７
Vendor-Id
ベンダーID
The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the "Assigned Numbers" RFC [6].
「Assigned Numbers」RFC [6]で定義されているように、上位オクテットは0で、下位3オクテットはベンダーのSMIネットワーク管理プライベートエンタープライズコードです。
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
It SHOULD be encoded as a sequence of vendor type / vendor length / value fields, as follows. The Attribute-Specific field is dependent on the vendor's definition of that attribute. An example encoding of the Vendor-Specific attribute using this method follows:
次のように、ベンダータイプ/ベンダー長さ/値フィールドのシーケンスとしてエンコードする必要があります。 [属性固有]フィールドは、ベンダーによるその属性の定義に依存しています。このメソッドを使用したベンダー固有属性のエンコードの例を次に示します。
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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Multiple subattributes MAY be encoded within a single Vendor-Specific attribute, although they do not have to be.
複数のサブ属性は、必ずしもそうである必要はないが、単一のベンダー固有属性内でエンコードされる場合があります。
Description
説明
This Attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge.
この属性は、セッションまたはプロンプトが終了するまでにユーザーに提供されるサービスの最大秒数を設定します。この属性は、サーバーからAccess-AcceptまたはAccess-Challengeでクライアントに送信するために使用できます。
A summary of the Session-Timeout 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
27 for Session-Timeout.
セッションタイムアウトの場合は27。
Length
長さ
6
６
Value
値
The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to remain connected by the NAS.
フィールドは4オクテットで、このユーザーがNASによる接続を維持できる最大秒数を持つ32ビットの符号なし整数が含まれています。
Description
説明
This Attribute sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge.
この属性は、セッションまたはプロンプトの終了前にユーザーに許可されるアイドル接続の最大連続秒数を設定します。この属性は、サーバーからAccess-AcceptまたはAccess-Challengeでクライアントに送信するために使用できます。
A summary of the Idle-Timeout Attribute format is shown below. The fields are transmitted from left to right.
Idle-Timeout 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
28 for Idle-Timeout.
アイドルタイムアウトの場合は28。
Length
長さ
6
６
Value
値
The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of consecutive seconds of idle time this user should be permitted before being disconnected by the NAS.
このフィールドは4オクテットで、NASによって切断される前にこのユーザーが許可されるアイドル時間の最大連続秒数を含む32ビットの符号なし整数を含みます。
Description
説明
This Attribute indicates what action the NAS should take when the specified service is completed. It is only used in Access-Accept packets.
この属性は、指定されたサービスが完了したときにNASが実行する必要があるアクションを示します。 Access-Acceptパケットでのみ使用されます。
A summary of the Termination-Action 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
29 for Termination-Action.
終了アクションの場合は29。
Length
長さ
6
６
Value
値
The Value field is four octets.
Valueフィールドは4オクテットです。
0 Default 1 RADIUS-Request
0デフォルト1 RADIUS-Request
If the Value is set to RADIUS-Request, upon termination of the specified service the NAS MAY send a new Access-Request to the RADIUS server, including the State attribute if any.
値がRADIUS-Requestに設定されている場合、指定されたサービスの終了時に、NASは新しいAccess-RequestをRADIUSサーバーに送信できます（状態属性がある場合）。
Description
説明
This Attribute allows the NAS to send in the Access-Request packet the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. It is only used in Access-Request packets.
この属性を使用すると、Dialed Number Identification（DNIS）または同様のテクノロジーを使用して、NASがAccess-Requestパケットでユーザーが呼び出した電話番号を送信できます。これは、電話がかかってきた電話番号とは異なる場合があることに注意してください。 Access-Requestパケットでのみ使用されます。
A summary of the Called-Station-Id Attribute format is shown below. The fields are transmitted from left to right.
Called-Station-Id Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
30 for Called-Station-Id.
Called-Station-Idの場合は30。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets, containing the phone number that the user's call came in on.
文字列フィールドは1つ以上のオクテットであり、ユーザーの通話が入った電話番号が含まれます。
The actual format of the information is site or application specific. UTF-8 encoded 10646 [7] characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets.
情報の実際の形式は、サイトまたはアプリケーションに固有です。 UTF-8でエンコードされた10646 [7]文字が推奨されますが、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute allows the NAS to send in the Access-Request packet the phone number that the call came from, using Automatic Number Identification (ANI) or similar technology. It is only used in Access-Request packets.
この属性により、NASは、自動番号識別（ANI）または同様のテクノロジーを使用して、呼び出しが送信された電話番号をAccess-Requestパケットで送信できます。 Access-Requestパケットでのみ使用されます。
A summary of the Calling-Station-Id Attribute format is shown below. The fields are transmitted from left to right.
Calling-Station-Id Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
31 for Calling-Station-Id.
Calling-Station-Idの場合は31。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets, containing the phone number that the user placed the call from.
Stringフィールドは1つ以上のオクテットであり、ユーザーが発信した電話番号が含まれます。
The actual format of the information is site or application specific. UTF-8 encoded 10646 [7] characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets.
情報の実際の形式は、サイトまたはアプリケーションに固有です。 UTF-8でエンコードされた10646 [7]文字が推奨されますが、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute contains a string identifying the NAS originating the Access-Request. It is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST be present in an Access-Request packet.
この属性には、アクセス要求を発信するNASを識別する文字列が含まれています。 Access-Requestパケットでのみ使用されます。 NAS-IP-AddressまたはNAS-IdentifierのいずれかがAccess-Requestパケットに存在する必要があります。
Note that NAS-Identifier MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret.
NAS-Identifierは、リクエストの認証に使用される共有秘密を選択するために使用してはならないことに注意してください。共有シークレットを選択するには、Access-RequestパケットのソースIPアドレスを使用する必要があります。
A summary of the NAS-Identifier Attribute format is shown below. The fields are transmitted from left to right.
NAS-Identifier Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
32 for NAS-Identifier.
NAS-Identifierの場合は32。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets, and should be unique to the NAS within the scope of the RADIUS server. For example, a fully qualified domain name would be suitable as a NAS-Identifier.
文字列フィールドは1つ以上のオクテットであり、RADIUSサーバーのスコープ内でNASに対して一意である必要があります。たとえば、完全修飾ドメイン名はNAS-Identifierとして適しています。
The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge. When the proxy server receives the response to its request, it MUST remove its own Proxy-State (the last Proxy-State in the packet) before forwarding the response to the NAS.
この属性は、Access-Requestを転送するときにプロキシサーバーから別のサーバーに送信でき、Access-Accept、Access-Reject、またはAccess-Challengeで変更せずに返す必要があります。プロキシサーバーがその要求への応答を受信すると、NASに応答を転送する前に自身のプロキシ状態（パケット内の最後のプロキシ状態）を削除する必要があります。
If a Proxy-State Attribute is added to a packet when forwarding the packet, the Proxy-State Attribute MUST be added after any existing Proxy-State attributes.
パケットの転送時にプロキシ状態属性がパケットに追加される場合、既存のプロキシ状態属性の後にプロキシ状態属性を追加する必要があります。
The content of any Proxy-State other than the one added by the current server should be treated as opaque octets and MUST NOT affect operation of the protocol.
現在のサーバーによって追加されたもの以外のすべてのProxy-Stateのコンテンツは、不透明なオクテットとして扱われるべきであり、プロトコルの操作に影響を与えてはなりません。
Usage of the Proxy-State Attribute is implementation dependent. A description of its function is outside the scope of this specification.
プロキシ状態属性の使用は実装に依存します。その機能の説明は、この仕様の範囲外です。
A summary of the Proxy-State Attribute format is shown below. The fields are transmitted from left to right.
プロキシ状態属性の形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
33 for Proxy-State.
プロキシ状態の場合は33。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute indicates the system with which the user is to be connected by LAT. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint.
この属性は、ユーザーがLATによって接続されるシステムを示します。 Access-Acceptパケットで使用できますが、LATがLogin-Serviceとして指定されている場合のみです。サーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
Administrators use the service attribute when dealing with clustered systems, such as a VAX or Alpha cluster. In such an environment several different time sharing hosts share the same resources (disks, printers, etc.), and administrators often configure each to offer access (service) to each of the shared resources. In this case, each host in the cluster advertises its services through LAT broadcasts.
管理者は、VAXやAlphaクラスターなどのクラスター化されたシステムを扱うときにservice属性を使用します。このような環境では、いくつかの異なるタイムシェアリングホストが同じリソース（ディスク、プリンターなど）を共有し、管理者はそれぞれの共有リソースへのアクセス（サービス）を提供するようにそれぞれを構成することがよくあります。この場合、クラスター内の各ホストは、LATブロードキャストを通じてサービスをアドバタイズします。
Sophisticated users often know which service providers (machines) are faster and tend to use a node name when initiating a LAT connection. Alternately, some administrators want particular users to use certain machines as a primitive form of load balancing (although LAT knows how to do load balancing itself).
洗練されたユーザーは、どのサービスプロバイダー（マシン）がより高速であるかをよく知っており、LAT接続を開始するときにノード名を使用する傾向があります。または、一部の管理者は、特定のユーザーが特定のマシンをロードバランシングの基本的な形式として使用することを望んでいます（ただし、LATはロードバランシング自体を行う方法を知っています）。
A summary of the Login-LAT-Service Attribute format is shown below. The fields are transmitted from left to right.
Login-LAT-Service Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
34 for Login-LAT-Service.
Login-LAT-Serviceの場合は34。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets, and contains the identity of the LAT service to use. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension [11]. All LAT string comparisons are case insensitive.
Stringフィールドは1つ以上のオクテットであり、使用するLATサービスのIDが含まれています。 LATアーキテクチャでは、この文字列に$（ドル）、-（ハイフン）、...を含めることができます。 （ピリオド）、_（アンダースコア）、数値、大文字と小文字のアルファベット、およびISO Latin-1文字セット拡張[11]。すべてのLAT文字列比較では、大文字と小文字が区別されません。
Description
説明
This Attribute indicates the Node with which the user is to be automatically connected by LAT. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint.
この属性は、ユーザーがLATによって自動的に接続されるノードを示します。 Access-Acceptパケットで使用できますが、LATがLogin-Serviceとして指定されている場合のみです。サーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Login-LAT-Node Attribute format is shown below. The fields are transmitted from left to right.
Login-LAT-Node Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
35 for Login-LAT-Node.
Login-LAT-Nodeの場合は35。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets, and contains the identity of the LAT Node to connect the user to. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive.
Stringフィールドは1つ以上のオクテットであり、ユーザーを接続するLATノードのIDが含まれています。 LATアーキテクチャでは、この文字列に$（ドル）、-（ハイフン）、...を含めることができます。 （ピリオド）、_（アンダースコア）、数値、大文字と小文字のアルファベット、およびISO Latin-1文字セット拡張。すべてのLAT文字列比較では、大文字と小文字が区別されません。
Description
説明
This Attribute contains a string identifying the LAT group codes which this user is authorized to use. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint.
この属性には、このユーザーが使用を許可されているLATグループコードを識別する文字列が含まれています。 Access-Acceptパケットで使用できますが、LATがLogin-Serviceとして指定されている場合のみです。サーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
LAT supports 256 different group codes, which LAT uses as a form of access rights. LAT encodes the group codes as a 256 bit bitmap.
LATは256の異なるグループコードをサポートし、LATはこれをアクセス権の形式として使用します。 LATは、グループコードを256ビットのビットマップとしてエンコードします。
Administrators can assign one or more of the group code bits at the LAT service provider; it will only accept LAT connections that have these group codes set in the bit map. The administrators assign a bitmap of authorized group codes to each user; LAT gets these from the operating system, and uses these in its requests to the service providers.
管理者は、LATサービスプロバイダーで1つ以上のグループコードビットを割り当てることができます。ビットマップでこれらのグループコードが設定されているLAT接続のみを受け入れます。管理者は、許可されたグループコードのビットマップを各ユーザーに割り当てます。 LATはこれらをオペレーティングシステムから取得し、サービスプロバイダーへの要求に使用します。
A summary of the Login-LAT-Group Attribute format is shown below. The fields are transmitted from left to right.
Login-LAT-Group Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
36 for Login-LAT-Group.
Login-LAT-Groupの場合は36。
Length
長さ
34
３４
String
ストリング
The String field is a 32 octet bit map, most significant octet first. A robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドは32オクテットのビットマップであり、最も重要なオクテットが最初です。堅牢な実装は、区別されないオクテットとしてフィールドをサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute indicates the AppleTalk network number which should be used for the serial link to the user, which is another AppleTalk router. It is only used in Access-Accept packets. It is never used when the user is not another router.
この属性は、ユーザーへのシリアルリンクに使用する必要があるAppleTalkネットワーク番号を示します。これは、別のAppleTalkルーターです。 Access-Acceptパケットでのみ使用されます。ユーザーが別のルーターでない場合は使用されません。
A summary of the Framed-AppleTalk-Link Attribute format is shown below. The fields are transmitted from left to right.
Framed-AppleTalk-Link 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
37 for Framed-AppleTalk-Link.
Framed-AppleTalk-Linkの場合は37。
Length
長さ
6
６
Value
値
The Value field is four octets. Despite the size of the field, values range from 0 to 65535. The special value of 0 indicates that this is an unnumbered serial link. A value of 1-65535 means that the serial line between the NAS and the user should be assigned that value as an AppleTalk network number.
Valueフィールドは4オクテットです。フィールドのサイズにかかわらず、値の範囲は0〜65535です。特別な値0は、これが番号なしのシリアルリンクであることを示します。 1〜65535の値は、NASとユーザー間のシリアル回線にAppleTalkネットワーク番号としてその値を割り当てる必要があることを意味します。
Description
説明
This Attribute indicates the AppleTalk Network number which the NAS should probe to allocate an AppleTalk node for the user. It is only used in Access-Accept packets. It is never used when the user is another router. Multiple instances of this Attribute indicate that the NAS may probe using any of the network numbers specified.
この属性は、NASがユーザーにAppleTalkノードを割り当てるためにプローブするAppleTalkネットワーク番号を示します。 Access-Acceptパケットでのみ使用されます。ユーザーが別のルーターの場合は使用されません。この属性の複数のインスタンスは、NASが指定されたネットワーク番号のいずれかを使用してプローブできることを示しています。
A summary of the Framed-AppleTalk-Network Attribute format is shown below. The fields are transmitted from left to right.
Framed-AppleTalk-Network 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
38 for Framed-AppleTalk-Network.
Framed-AppleTalk-Networkの場合は38。
Length
長さ
6
６
Value
値
The Value field is four octets. Despite the size of the field, values range from 0 to 65535. The special value 0 indicates that the NAS should assign a network for the user, using its default cable range. A value between 1 and 65535 (inclusive) indicates the AppleTalk Network the NAS should probe to find an address for the user.
Valueフィールドは4オクテットです。フィールドのサイズにかかわらず、値の範囲は0〜65535です。特別な値0は、デフォルトのケーブル範囲を使用して、NASがユーザーにネットワークを割り当てる必要があることを示します。 1〜65535の値は、NASがユーザーのアドレスを見つけるためにプローブするAppleTalkネットワークを示します。
Description
説明
This Attribute indicates the AppleTalk Default Zone to be used for this user. It is only used in Access-Accept packets. Multiple instances of this attribute in the same packet are not allowed.
この属性は、このユーザーに使用されるAppleTalkデフォルトゾーンを示します。 Access-Acceptパケットでのみ使用されます。同じパケット内のこの属性の複数のインスタンスは許可されていません。
A summary of the Framed-AppleTalk-Zone Attribute format is shown below. The fields are transmitted from left to right.
Framed-AppleTalk-Zone Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
39 for Framed-AppleTalk-Zone.
Framed-AppleTalk-Zoneの場合は39。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The name of the Default AppleTalk Zone to be used for this user. A robust implementation SHOULD support the field as undistinguished octets.
このユーザーに使用されるデフォルトのAppleTalkゾーンの名前。堅牢な実装は、区別されないオクテットとしてフィールドをサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Description
説明
This Attribute contains the CHAP Challenge sent by the NAS to a PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is only used in Access-Request packets.
この属性には、NASからPPPチャレンジハンドシェイク認証プロトコル（CHAP）ユーザーに送信されるCHAPチャレンジが含まれます。 Access-Requestパケットでのみ使用されます。
If the CHAP challenge value is 16 octets long it MAY be placed in the Request Authenticator field instead of using this attribute.
CHAPチャレンジ値が16オクテット長である場合、この属性を使用する代わりに、リクエスト認証子フィールドに配置することができます（MAY）。
A summary of the CHAP-Challenge Attribute format is shown below. The fields are transmitted from left to right.
CHAP-チャレンジ属性フォーマットの概要を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
60 for CHAP-Challenge.
CHAP-Challengeの場合は60。
Length
長さ
>= 7
＞＝ ７
String
ストリング
The String field contains the CHAP Challenge.
文字列フィールドには、CHAPチャレンジが含まれます。
Description
説明
This Attribute indicates the type of the physical port of the NAS which is authenticating the user. It can be used instead of or in addition to the NAS-Port (5) attribute. It is only used in Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports.
この属性は、ユーザーを認証しているNASの物理ポートのタイプを示します。 NAS-Port（5）属性の代わりに、またはそれに追加して使用できます。 Access-Requestパケットでのみ使用されます。 NASがポートを区別する場合、NAS-Port（5）またはNAS-Port-Typeのいずれか、あるいは両方がAccess-Requestパケットに存在する必要があります（SHOULD）。
A summary of the NAS-Port-Type Attribute format is shown below. The fields are transmitted from left to right.
NAS-Port-Type 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
61 for NAS-Port-Type.
NAS-Port-Typeの場合は61。
Length
長さ
6
６
Value
値
The Value field is four octets. "Virtual" refers to a connection to the NAS via some transport protocol, instead of through a physical port. For example, if a user telnetted into a NAS to authenticate himself as an Outbound-User, the Access-Request might include NAS-Port-Type = Virtual as a hint to the RADIUS server that the user was not on a physical port.
Valueフィールドは4オクテットです。 「仮想」とは、物理ポートを介するのではなく、何らかのトランスポートプロトコルを介したNASへの接続を指します。たとえば、ユーザーがNASにTelnetで接続して自分をOutbound-Userとして認証した場合、Access-Requestには、ユーザーが物理ポート上にいないことを示すRADIUSサーバーへのヒントとしてNAS-Port-Type = Virtualを含めることができます。
0 Async 1 Sync 2 ISDN Sync 3 ISDN Async V.120 4 ISDN Async V.110 5 Virtual 6 PIAFS 7 HDLC Clear Channel 8 X.25 9 X.75 10 G.3 Fax 11 SDSL - Symmetric DSL 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 14 IDSL - ISDN Digital Subscriber Line 15 Ethernet 16 xDSL - Digital Subscriber Line of unknown type 17 Cable 18 Wireless - Other 19 Wireless - IEEE 802.11
0非同期1同期2 ISDN同期3 ISDN非同期V.120 4 ISDN非同期V.110 5仮想6 PIAFS 7 HDLCクリアチャネル8 X.25 9 X.75 10 G.3 FAX 11 SDSL-対称DSL 12 ADSL-CAP-非対称DSL、キャリアレス振幅位相変調13 ADSL-DMT-非対称DSL、離散マルチトーン14 IDSL-ISDNデジタル加入者線15イーサネット16 xDSL-不明なタイプのデジタル加入者線17ケーブル18ワイヤレス-その他19ワイヤレス-IEEE 802.11
PIAFS is a form of wireless ISDN commonly used in Japan, and stands for PHS (Personal Handyphone System) Internet Access Forum Standard (PIAFS).
PIAFSは、日本で一般的に使用されているワイヤレスISDNの形式で、PHS（Personal Handyphone System）Internet Access Forum Standard（PIAFS）の略です。
Description
説明
This Attribute sets the maximum number of ports to be provided to the user by the NAS. This Attribute MAY be sent by the server to the client in an Access-Accept packet. It is intended for use in conjunction with Multilink PPP [12] or similar uses. It MAY also be sent by the NAS to the server as a hint that that many ports are desired for use, but the server is not required to honor the hint.
この属性は、NASによってユーザーに提供されるポートの最大数を設定します。この属性は、サーバーからクライアントにAccess-Acceptパケットで送信される場合があります。これは、マルチリンクPPP [12]または同様の用途と組み合わせて使用することを目的としています。また、NASからサーバーに、使用するために多くのポートが必要であるというヒントとして送信される場合がありますが、サーバーはそのヒントを受け入れる必要はありません。
A summary of the Port-Limit 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
62 for Port-Limit.
ポート制限の場合は62。
Length
長さ
6
６
Value
値
The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of ports this user should be allowed to connect to on the NAS.
このフィールドは4オクテットであり、このユーザーがNASに接続することを許可する必要があるポートの最大数を示す32ビットの符号なし整数が含まれています。
Description
説明
This Attribute indicates the Port with which the user is to be connected by LAT. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint.
この属性は、ユーザーがLATによって接続されるポートを示します。 Access-Acceptパケットで使用できますが、LATがLogin-Serviceとして指定されている場合のみです。サーバーへのヒントとしてAccess-Requestパケットで使用される場合がありますが、サーバーはヒントを尊重する必要はありません。
A summary of the Login-LAT-Port Attribute format is shown below. The fields are transmitted from left to right.
Login-LAT-Port Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
63 for Login-LAT-Port.
ログインLATポートの場合は63。
Length
長さ
>= 3
＞＝ ３
String
ストリング
The String field is one or more octets, and contains the identity of the LAT port to use. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive.
Stringフィールドは1つ以上のオクテットであり、使用するLATポートのIDが含まれています。 LATアーキテクチャでは、この文字列に$（ドル）、-（ハイフン）、...を含めることができます。 （ピリオド）、_（アンダースコア）、数値、大文字と小文字のアルファベット、およびISO Latin-1文字セット拡張。すべてのLAT文字列比較では、大文字と小文字が区別されません。
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
次の表は、どの種類のパケットで、どのような量の属性が見つかるかのガイドです。
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0-1 0 0 0 2 User-Password [Note 1]
0-1 0 0 0 3 CHAP-Password [Note 1]
0-1 0 0 0 4 NAS-IP-Address [Note 2]
0-1 0 0 0 5 NAS-Port
0-1 0-1 0 0 6 Service-Type
0-1 0-1 0 0 7 Framed-Protocol
0-1 0-1 0 0 8 Framed-IP-Address
0-1 0-1 0 0 9 Framed-IP-Netmask
0 0-1 0 0 10 Framed-Routing
0 0+ 0 0 11 Filter-Id
0-1 0-1 0 0 12 Framed-MTU
0+ 0+ 0 0 13 Framed-Compression
0+ 0+ 0 0 14 Login-IP-Host
0 0-1 0 0 15 Login-Service
0 0-1 0 0 16 Login-TCP-Port
0 0+ 0+ 0+ 18 Reply-Message
0-1 0-1 0 0 19 Callback-Number
0 0-1 0 0 20 Callback-Id
0 0+ 0 0 22 Framed-Route
0 0-1 0 0 23 Framed-IPX-Network
0-1 0-1 0 0-1 24 State [Note 1]
0 0+ 0 0 25 Class
0+ 0+ 0 0+ 26 Vendor-Specific
0 0-1 0 0-1 27 Session-Timeout
0 0-1 0 0-1 28 Idle-Timeout
0 0-1 0 0 29 Termination-Action
0-1 0 0 0 30 Called-Station-Id
0-1 0 0 0 31 Calling-Station-Id
0-1 0 0 0 32 NAS-Identifier [Note 2]
0+ 0+ 0+ 0+ 33 Proxy-State
0-1 0-1 0 0 34 Login-LAT-Service
0-1 0-1 0 0 35 Login-LAT-Node 0-1 0-1 0 0 36 Login-LAT-Group
0 0-1 0 0 37 Framed-AppleTalk-Link
0 0+ 0 0 38 Framed-AppleTalk-Network
0 0-1 0 0 39 Framed-AppleTalk-Zone
0-1 0 0 0 60 CHAP-Challenge
0-1 0 0 0 61 NAS-Port-Type
0-1 0-1 0 0 62 Port-Limit
0-1 0-1 0 0 63 Login-LAT-Port
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request MUST contain either a User-Password or a CHAP-Password or State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password.
[注1] Access-Requestには、User-PasswordまたはCHAP-PasswordまたはStateのいずれかが含まれている必要があります。 Access-Requestには、ユーザーパスワードとCHAPパスワードの両方を含めることはできません。将来の拡張で他の種類の認証情報の伝達が許可される場合は、その属性をUser-PasswordまたはCHAP-Passwordの代わりにAccess-Requestで使用できます。
[Note 2] An Access-Request MUST contain either a NAS-IP-Address or a NAS-Identifier (or both).
[注2] Access-Requestには、NAS-IP-AddressまたはNAS-Identifier（または両方）を含める必要があります。
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. 1 Exactly one instance of this attribute MUST be present in packet.
0この属性はパケットに存在してはなりません。 0+この属性のゼロ個以上のインスタンスがパケットに存在する場合があります。 0-1この属性のゼロまたは1つのインスタンスがパケットに存在する場合があります。 1この属性の正確に1つのインスタンスがパケットに存在する必要があります。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the RADIUS protocol, in accordance with BCP 26 [13].
このセクションでは、BCP 26 [13]に従って、RADIUSプロトコルに関連する値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。
There are three name spaces in RADIUS that require registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain Attributes).
RADIUSには、登録が必要な3つの名前空間があります。パケットタイプコード、属性タイプ、および属性値（特定の属性用）です。
RADIUS is not intended as a general-purpose Network Access Server (NAS) management protocol, and allocations should not be made for purposes unrelated to Authentication, Authorization or Accounting.
RADIUSは、汎用のネットワークアクセスサーバー（NAS）管理プロトコルとして意図されたものではなく、認証、承認、アカウンティングに関係のない目的で割り当てを行うことはできません。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
以下の用語は、BCP 26で定義された意味でここで使用されています：「名前空間」、「割り当てられた値」、「登録」。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action".
次のポリシーは、BCP 26で定義された意味でここで使用されます：「私用」、「先着順」、「専門家によるレビュー」、「必要な仕様」、「IETFコンセンサス」、「標準アクション」。
For registration requests where a Designated Expert should be consulted, the IESG Area Director for Operations should appoint the Designated Expert.
指定専門家に相談する必要のある登録要求については、運営のためのIESGエリアディレクターが指定専門家を指名する必要があります。
For registration requests requiring Expert Review, the ietf-radius mailing list should be consulted.
Expert Reviewを必要とする登録リクエストについては、ietf-radiusメーリングリストを参照してください。
Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have been allocated. Because a new Packet Type has considerable impact on interoperability, a new Packet Type Code requires Standards Action, and should be allocated starting at 14.
パケットタイプコードの範囲は1〜254で、そのうち1〜5、11〜13が割り当てられています。新しいパケットタイプは相互運用性に大きな影響を与えるため、新しいパケットタイプコードは標準アクションを必要とし、14から割り当てられる必要があります。
Attribute Types have a range from 1 to 255, and are the scarcest resource in RADIUS, thus must be allocated with care. Attributes 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated following Expert Review, with Specification Required. Release of blocks of Attribute Types (more than 3 at a time for a given purpose) should require IETF Consensus. It is recommended that attributes 17 and 21 be used only after all others are exhausted.
属性タイプの範囲は1〜255であり、RADIUSで最も希少なリソースであるため、注意して割り当てる必要があります。属性1〜53、55、60〜88、90〜91が割り当てられ、17および21を再利用できます。属性17、21、54、56-59、89、92-191は、仕様が必要なエキスパートレビューに続いて割り当てられます。属性タイプのブロックのリリース（特定の目的で一度に3つ以上）を行うには、IETFコンセンサスが必要です。属性17と21は、他のすべてを使い果たした後でのみ使用することをお勧めします。
Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.
RADIUSはベンダー固有の拡張機能（属性26）のメカニズムを定義し、相互運用性が役に立たないと見なされるRADIUSの1つのベンダーの実装にのみ固有の機能では、グローバル属性タイプの割り当てではなく、その使用を推奨する必要があることに注意してください。
As stated in the "Attributes" section above:
上記の「属性」セクションで述べたように：
"[Attribute Type] Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used."
「[属性タイプ]値192-223は実験用に予約されており、値224-240は実装固有の使用のために予約されています。値241-255は予約されているため、使用しないでください。」
Therefore Attribute values 192-240 are considered Private Use, and values 241-255 require Standards Action.
したがって、属性値192-240は私的使用と見なされ、値241-255は標準アクションが必要です。
Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Adding additional values to the list can be done on a First Come, First Served basis by the IANA.
RADIUSの特定の属性（たとえば、NAS-Port-Type）は、さまざまな意味に対応する値のリストを定義します。各属性には40億（2 ^ 32）の値が存在する可能性があります。リストに値を追加することは、IANAによって先着順で行うことができます。
A few examples are presented to illustrate the flow of packets and use of typical attributes. These examples are not intended to be exhaustive, many others are possible. Hexadecimal dumps of the example packets are given in network byte order, using the shared secret "xyzzy5461".
パケットのフローと一般的な属性の使用を説明するために、いくつかの例を示します。これらの例はすべてを網羅することを意図したものではなく、他の多くの例が可能です。サンプルパケットの16進ダンプは、共有シークレット「xyzzy5461」を使用して、ネットワークバイトオーダーで提供されます。
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named nemo logging in on port 3 with password "arctangent".
192.168.1.16にあるNASは、nemoという名前のユーザーがパスワード "arctangent"でポート3にログインするために、Access-Request UDPパケットをRADIUSサーバーに送信します。
The Request Authenticator is a 16 octet random number generated by the NAS.
Request Authenticatorは、NASによって生成される16オクテットの乱数です。
The User-Password is 16 octets of password padded at end with nulls, XORed with MD5(shared secret|Request Authenticator).
User-Passwordは、16オクテットのパスワードで、最後にヌルが埋め込まれ、MD5（共有秘密|要求認証）でXORされます。
01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 01 10 05 06 00 00 00 03
01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 01 10 05 06 00 00 00 03
1 Code = Access-Request (1) 1 ID = 0 2 Length = 56 16 Request Authenticator
1コード= Access-Request（1）1 ID = 0 2長さ= 56 16リクエスト認証
Attributes: 6 User-Name = "nemo" 18 User-Password 6 NAS-IP-Address = 192.168.1.16 6 NAS-Port = 3
属性：6ユーザー名= "nemo" 18ユーザーパスワード6 NAS-IP-Address = 192.168.1.16 6 NAS-Port = 3
The RADIUS server authenticates nemo, and sends an Access-Accept UDP packet to the NAS telling it to telnet nemo to host 192.168.1.3.
RADIUSサーバーはnemoを認証し、Access-Accept UDPパケットをNASに送信して、ホスト192.168.1.3へのtelnet nemoを指示します。
The Response Authenticator is a 16-octet MD5 checksum of the code (2), id (0), Length (38), the Request Authenticator from above, the attributes in this reply, and the shared secret.
応答オーセンティケーターは、コード（2）、ID（0）、長さ（38）、上からの要求オーセンティケーター、この応答の属性、および共有シークレットの16オクテットMD5チェックサムです。
02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 0e 06 c0 a8 01 03
02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 0e 06 c0 a8 01 03
1 Code = Access-Accept (2) 1 ID = 0 (same as in Access-Request) 2 Length = 38 16 Response Authenticator
1コード= Access-Accept（2）1 ID = 0（Access-Requestと同じ）2長さ= 38 16応答認証システム
Attributes: 6 Service-Type (6) = Login (1) 6 Login-Service (15) = Telnet (0) 6 Login-IP-Host (14) = 192.168.1.3
属性：6サービスタイプ（6）=ログイン（1）6ログインサービス（15）= Telnet（0）6ログインIPホスト（14）= 192.168.1.3
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named flopsy logging in on port 20 with PPP, authenticating using CHAP. The NAS sends along the Service-Type and Framed-Protocol attributes as a hint to the RADIUS server that this user is looking for PPP, although the NAS is not required to do so.
NASは192.168.1.16にあり、ポート20にPPPでログインし、CHAPを使用して認証するユーザーのflopsyという名前のユーザーに対して、Access-Request UDPパケットをRADIUSサーバーに送信します。 NASは、このユーザーがPPPを探していることを示すヒントとして、Service-Type属性とFramed-Protocol属性をRADIUSサーバーに送信しますが、NASはそうする必要はありません。
The Request Authenticator is a 16 octet random number generated by the NAS, and is also used as the CHAP Challenge.
Request Authenticatorは、NASによって生成される16オクテットの乱数であり、CHAPチャレンジとしても使用されます。
The CHAP-Password consists of a 1 octet CHAP ID, in this case 22, followed by the 16 octet CHAP response.
CHAP-Passwordは、1オクテットのCHAP ID、この場合は22で構成され、その後に16オクテットのCHAP応答が続きます。
01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00 02 07 06 00 00 00 01
01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00 02 07 06 00 00 00 01
1 Code = 1 (Access-Request) 1 ID = 1 2 Length = 71 16 Request Authenticator
1コード= 1（アクセス要求）1 ID = 1 2長さ= 71 16要求オーセンティケーター
Attributes: 8 User-Name (1) = "flopsy" 19 CHAP-Password (3) 6 NAS-IP-Address (4) = 192.168.1.16 6 NAS-Port (5) = 20 6 Service-Type (6) = Framed (2) 6 Framed-Protocol (7) = PPP (1)
属性：8ユーザー名（1）= "フロッピー" 19 CHAP-パスワード（3）6 NAS-IP-アドレス（4）= 192.168.1.16 6 NAS-ポート（5）= 20 6サービスタイプ（6）=フレーム付き（2）6フレーム付きプロトコル（7）= PPP（1）
The RADIUS server authenticates flopsy, and sends an Access-Accept UDP packet to the NAS telling it to start PPP service and assign an address for the user out of its dynamic address pool.
RADIUSサーバーはフロッピーを認証し、NASにAccess-Accept UDPパケットを送信してPPPサービスを開始し、動的アドレスプールからユーザーのアドレスを割り当てるように指示します。
The Response Authenticator is a 16-octet MD5 checksum of the code (2), id (1), Length (56), the Request Authenticator from above, the attributes in this reply, and the shared secret.
応答認証子は、コード（2）、ID（1）、長さ（56）、上からの要求認証子、この応答の属性、および共有秘密の16オクテットMD5チェックサムです。
02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00 00 01 0c 06 00 00 05 dc
02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0 3c 86 01 a4 06 06 00 00 02 07 06 00 00 00 01 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00 00 01 0c 06 00 00 05 dc
1 Code = Access-Accept (2) 1 ID = 1 (same as in Access-Request) 2 Length = 56 16 Response Authenticator
1コード= Access-Accept（2）1 ID = 1（Access-Requestと同じ）2長さ= 56 16応答認証システム
Attributes: 6 Service-Type (6) = Framed (2) 6 Framed-Protocol (7) = PPP (1) 6 Framed-IP-Address (8) = 255.255.255.254 6 Framed-Routing (10) = None (0) 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1) 6 Framed-MTU (12) = 1500
属性：6 Service-Type（6）= Framed（2）6 Framed-Protocol（7）= PPP（1）6 Framed-IP-Address（8）= 255.255.255.254 6 Framed-Routing（10）= None（0 ）6 Framed-Compression（13）= VJ TCP / IPヘッダー圧縮（1）6 Framed-MTU（12）= 1500
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named mopsy logging in on port 7. The user enters the dummy password "challenge" in this example. The challenge and response generated by the smart card for this example are "32769430" and "99101462".
192.168.1.16にあるNASは、ポート7にログインしているmopsyという名前のユーザーのAccess-Request UDPパケットをRADIUSサーバーに送信します。この例では、ユーザーはダミーのパスワード「challenge」を入力します。この例のスマートカードによって生成されるチャレンジとレスポンスは、「32769430」と「99101462」です。
The Request Authenticator is a 16 octet random number generated by the NAS.
Request Authenticatorは、NASによって生成される16オクテットの乱数です。
The User-Password is 16 octets of password, in this case "challenge", padded at the end with nulls, XORed with MD5(shared secret|Request Authenticator).
User-Passwordは16オクテットのパスワードで、この場合は「チャレンジ」で、最後にヌルが埋め込まれ、MD5（共有シークレット|リクエスト認証）でXORされます。
01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0 a8 01 10 05 06 00 00 00 07
01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0 a8 01 10 05 06 00 00 00 07
1 Code = Access-Request (1) 1 ID = 2 2 Length = 57 16 Request Authenticator
1コード=アクセス要求（1）1 ID = 2 2長さ= 57 16要求オーセンティケーター
Attributes: 7 User-Name (1) = "mopsy" 18 User-Password (2) 6 NAS-IP-Address (4) = 192.168.1.16 6 NAS-Port (5) = 7
属性：7ユーザー名（1）= "mopsy" 18ユーザーパスワード（2）6 NAS-IP-Address（4）= 192.168.1.16 6 NAS-Port（5）= 7
The RADIUS server decides to challenge mopsy, sending back a challenge string and looking for a response. The RADIUS server therefore and sends an Access-Challenge UDP packet to the NAS.
RADIUSサーバーは、モプシーにチャレンジすることを決定し、チャレンジ文字列を送り返し、応答を探します。したがって、RADIUSサーバーはAccess-Challenge UDPパケットをNASに送信します。
The Response Authenticator is a 16-octet MD5 checksum of the code (11), id (2), length (78), the Request Authenticator from above, the attributes in this reply, and the shared secret.
Response Authenticatorは、コード（11）、id（2）、長さ（78）、上からのRequest Authenticator、この応答の属性、および共有シークレットの16オクテットMD5チェックサムです。
The Reply-Message is "Challenge 32769430. Enter response at prompt."
返信メッセージは「Challenge32769430。プロンプトで応答を入力してください。」です。
The State is a magic cookie to be returned along with user's response; in this example 8 octets of data (33 32 37 36 39 34 33 30 in hex).
状態は、ユーザーの応答とともに返される魔法のcookieです。この例では8オクテットのデータ（16進数で33 32 37 36 39 34 33 30）。
0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
1 Code = Access-Challenge (11) 1 ID = 2 (same as in Access-Request) 2 Length = 78 16 Response Authenticator
1コード= Access-Challenge（11）1 ID = 2（Access-Requestと同じ）2長さ= 78 16応答認証システム
Attributes: 48 Reply-Message (18) 10 State (24)
属性：48応答メッセージ（18）10状態（24）
The user enters his response, and the NAS send a new Access-Request with that response, and includes the State Attribute.
ユーザーが自分の応答を入力すると、NASはその応答を含む新しいAccess-Requestを送信し、状態属性が含まれます。
The Request Authenticator is a new 16 octet random number.
リクエスト認証システムは、新しい16オクテットの乱数です。
The User-Password is 16 octets of the user's response, in this case "99101462", padded at the end with nulls, XORed with MD5(shared secret|Request Authenticator).
User-Passwordは、ユーザーの応答の16オクテット（この場合は "99101462"）で、末尾にヌルが埋め込まれ、MD5（共有シークレット|リクエスト認証）でXORされます。
The state is the magic cookie from the Access-Challenge packet, unchanged.
状態は、変更されていないAccess-Challengeパケットの魔法のCookieです。
01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07 c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0 a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39 34 33 30
01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07 c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0 a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39 34 33 30
1 Code = Access-Request (1) 1 ID = 3 (Note that this changes.) 2 Length = 67 16 Request Authenticator
1コード= Access-Request（1）1 ID = 3（これは変更されることに注意してください。）2長さ= 67 16要求オーセンティケーター
Attributes: 7 User-Name = "mopsy" 18 User-Password 6 NAS-IP-Address (4) = 192.168.1.16 6 NAS-Port (5) = 7 10 State (24)
属性：7 User-Name = "mopsy" 18 User-Password 6 NAS-IP-Address（4）= 192.168.1.16 6 NAS-Port（5）= 7 10 State（24）
The Response was incorrect (for the sake of example), so the RADIUS server tells the NAS to reject the login attempt.
応答が正しくなかったため（例として）、RADIUSサーバーはNASにログイン試行を拒否するように指示します。
The Response Authenticator is a 16 octet MD5 checksum of the code (3), id (3), length(20), the Request Authenticator from above, the attributes in this reply (in this case, none), and the shared secret.
Response Authenticatorは、コード（3）、id（3）、length（20）、上記のRequest Authenticator、この応答の属性（この場合はなし）、および共有秘密の16オクテットMD5チェックサムです。
03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f 9e 74 6a a0
03 03 00 14 ach 2f chf tsa 45 91 shts che 09 8 zch 0f yea shch sha a0
1 Code = Access-Reject (3) 1 ID = 3 (same as in Access-Request) 2 Length = 20 16 Response Authenticator
1コード= Access-Reject（3）1 ID = 3（Access-Requestと同じ）2長さ= 20 16応答認証システム
Attributes: (none, although a Reply-Message could be sent)
属性：（なし、ただしReply-Messageを送信できます）
Security issues are the primary topic of this document.
セキュリティの問題は、このドキュメントの主要なトピックです。
In practice, within or associated with each RADIUS server, there is a database which associates "user" names with authentication information ("secrets"). It is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set. Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct user names SHOULD be employed, each of which identifies exactly one authentication method.
実際には、各RADIUSサーバー内または各RADIUSサーバーに関連付けられているデータベースに、「ユーザー」名と認証情報（「シークレット」）を関連付けます。特定の指名ユーザーが複数の方法で認証されることは想定されていません。これにより、セットの中から最も安全性の低い方法をネゴシエートする攻撃に対してユーザーが脆弱になります。代わりに、指定されたユーザーごとに、そのユーザー名を認証するために使用された方法が1つだけ示されます。ユーザーがさまざまな状況でさまざまな認証方法を使用する必要がある場合は、異なるユーザー名を使用する必要があります（SHOULD）。それぞれが厳密に1つの認証方法を識別します。
Passwords and other secrets should be stored at the respective ends such that access to them is as limited as possible. Ideally, the secrets should only be accessible to the process requiring access in order to perform the authentication.
パスワードおよび他の秘密は、それらへのアクセスが可能な限り制限されるように、それぞれの端に保管する必要があります。理想的には、シークレットは、認証を実行するためにアクセスを必要とするプロセスにのみアクセス可能である必要があります。
The secrets should be distributed with a mechanism that limits the number of entities that handle (and thus gain knowledge of) the secret. Ideally, no unauthorized person should ever gain knowledge of the secrets. It is possible to achieve this with SNMP Security Protocols [14], but such a mechanism is outside the scope of this specification.
シークレットは、シークレットを処理する（したがって、その情報を取得する）エンティティの数を制限するメカニズムで配布する必要があります。理想的には、権限のない人が秘密の知識を得てはなりません。 SNMPセキュリティプロトコル[14]でこれを実現することは可能ですが、そのようなメカニズムはこの仕様の範囲外です。
Other distribution methods are currently undergoing research and experimentation. The SNMP Security document [14] also has an excellent overview of threats to network protocols.
他の配布方法は現在、研究と実験が行われています。 SNMPセキュリティドキュメント[14]には、ネットワークプロトコルに対する脅威の優れた概要もあります。
The User-Password hiding mechanism described in Section 5.2 has not been subjected to significant amounts of cryptanalysis in the published literature. Some in the IETF community are concerned that this method might not provide sufficient confidentiality protection [15] to passwords transmitted using RADIUS. Users should evaluate their threat environment and consider whether additional security mechanisms should be employed.
セクション5.2で説明されているユーザーパスワード非表示のメカニズムは、公開された文献では大量の暗号解読を受けていません。 IETFコミュニティの一部は、この方法ではRADIUSを使用して送信されるパスワードに十分な機密保護[15]が提供されない可能性があることを懸念しています。ユーザーは脅威環境を評価し、追加のセキュリティメカニズムを採用する必要があるかどうかを検討する必要があります。
The following changes have been made from RFC 2138:
RFC 2138から次の変更が行われました。
Strings should use UTF-8 instead of US-ASCII and should be handled as 8-bit data.
文字列はUS-ASCIIではなくUTF-8を使用し、8ビットデータとして処理する必要があります。
Integers and dates are now defined as 32 bit unsigned values.
整数と日付は、32ビットの符号なしの値として定義されるようになりました。
Updated list of attributes that can be included in Access-Challenge to be consistent with the table of attributes.
属性のテーブルと一致するようにAccess-Challengeに含めることができる属性の更新されたリスト。
User-Name mentions Network Access Identifiers.
User-Nameはネットワークアクセス識別子について言及しています。
User-Name may now be sent in Access-Accept for use with accounting and Rlogin.
User-Nameは、アカウンティングおよびRloginで使用するためにAccess-Acceptで送信できます。
Values added for Service-Type, Login-Service, Framed-Protocol, Framed-Compression, and NAS-Port-Type.
Service-Type、Login-Service、Framed-Protocol、Framed-Compression、およびNAS-Port-Typeに追加された値。
NAS-Port can now use all 32 bits.
NAS-Portは32ビットすべてを使用できるようになりました。
Examples now include hexadecimal displays of the packets.
例には、パケットの16進表示が含まれるようになりました。
Source UDP port must be used in conjunction with the Request Identifier when identifying duplicates.
重複を識別する場合は、送信元UDPポートを要求IDと組み合わせて使用する必要があります。
Multiple subattributes may be allowed in a Vendor-Specific attribute.
Vendor-Specific属性では、複数のサブ属性を使用できます。
An Access-Request is now required to contain either a NAS-IP-Address or NAS-Identifier (or may contain both).
NAS-IP-AddressまたはNAS-Identifier（または両方を含む場合があります）のいずれかを含めるために、Access-Requestが必要になりました。
Added notes under "Operations" with more information on proxy, retransmissions, and keep-alives.
プロキシ、再送信、およびキープアライブの詳細を含む「操作」の下にメモを追加しました。
If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies.
同じタイプの属性が複数存在する場合、同じタイプの属性の順序はプロキシによって保持されなければなりません（MUST）。
Clarified Proxy-State.
プロキシ状態を明確化。
Clarified that Attributes must not depend on position within the packet, as long as Attributes of the same type are kept in order.
同じタイプの属性が適切に保持されている限り、属性はパケット内の位置に依存してはならないことを明確にしました。
Added IANA Considerations section.
IANAに関する考慮事項のセクションを追加しました。
Updated section on "Proxy" under "Operations".
「操作」の「プロキシ」のセクションを更新しました。
Framed-MTU can now be sent in Access-Request as a hint.
Framed-MTUがヒントとしてAccess-Requestで送信できるようになりました。
Updated Security Considerations.
セキュリティに関する考慮事項の更新。
Text strings identified as a subset of string, to clarify use of UTF-8.
UTF-8の使用を明確にするために、文字列のサブセットとして識別されるテキスト文字列。
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[1] Rigney、C.、Rubens、A.、Simpson、W。、およびS. Willens、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2138、1997年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[2] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[3] Rivest、R。およびS. Dusse、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[4] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[5] リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[6] Reynolds、J.およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[7] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[8] Aboba、B.およびM. Beadles、「The Network Access Identifier」、RFC 2486、1999年1月。
[9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.
[9] Kaufman、C.、Perlman、R。、およびSpeciner、M。、「Network Security：Private Communications in a Public World」、Prentice Hall、1995年3月、ISBN 0-13-061466-1。
[10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[10] Jacobson、V。、「低速シリアルリンクのTCP / IPヘッダーの圧縮」、RFC 1144、1990年2月。
[11] ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.
[11] ISO8859。国際標準-情報処理-8ビットシングルバイトコード化グラフィック文字セット-パート1：ラテンアルファベットNo. 1、ISO 8859-1：1987。
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[12] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D. and T. Coradetti、 "The PPP Multilink Protocol（MP）"、RFC 1990、August 1996。
[13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[13] Alvestrand、H。およびT. Narten、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security Protocols", RFC 1352, July 1992.
[14] Galvin、J.、McCloghrie、K. and J. Davin、 "SNMP Security Protocols"、RFC 1352、July 1992。
[15] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[15] Dobbertin、H。、「最近の攻撃後のMD5のステータス」、CryptoBytes Vol.2 No.2、1996年夏。
RADIUS was originally developed by Steve Willens of Livingston Enterprises for their PortMaster series of Network Access Servers.
RADIUSは当初、リビングストンエンタープライズのスティーブウィレンスがネットワークアクセスサーバーのPortMasterシリーズ用に開発しました。
The working group can be contacted via the current chair:
ワーキンググループは、現在の議長を通じて連絡を取ることができます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
カールリグニーリビングストンエンタープライズ4464 Willow Road Pleasanton、California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Questions about this memo can also be directed to:
このメモに関する質問は、次の宛先にも送信できます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
カールリグニーリビングストンエンタープライズ4464 Willow Road Pleasanton、California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Allan C. Rubens Merit Network, Inc. 4251 Plymouth Road Ann Arbor, Michigan 48105-2785
Allan C.Rubens Merit Network、Inc. 4251 Plymouth Road Ann Arbor、Michigan 48105-2785
EMail: acr@merit.edu
William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアムアレンシンプソンDaydreamerコンピューターシステムコンサルティングサービス1384 Fontaine Madison Heights、Michigan 48071
EMail: wsimpson@greendragon.com
Steve Willens Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Steve Willens Livingston Enterprises 4464 Willow Road Pleasanton、California 94588
EMail: steve@livingston.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 Editor機能への資金提供は、現在Internet Societyから提供されています。