[要約] RFC 5176は、RADIUSに動的認証拡張を提供するための規格であり、要約すると以下のようになります。1. RADIUSに動的認証拡張を追加するための規格。 2. リモート認証ダイヤルインユーザーサービス（RADIUS）の機能を拡張する。 3. ユーザーの認証と認可をより柔軟に管理するための目的を持つ。
Network Working Group M. Chiba
Request for Comments: 5176 G. Dommety
Obsoletes: 3576 M. Eklund
Category: Informational Cisco Systems, Inc.
D. Mitton
RSA, Security Division of EMC
B. Aboba
Microsoft Corporation
January 2008
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
リモート認証への動的な認証拡張ユーザーサービス（RADIUS）のダイヤル
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.
このドキュメントでは、ネットワークアクセスサーバー製品によって実装されているように、ユーザーセッションに動的な変更を可能にする、ユーザーサービス（RADIUS）プロトコルのリモート認証ダイヤルへの現在展開されている拡張機能について説明します。これには、ユーザーの切断やユーザーセッションに適用される承認の変更のサポートが含まれます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Applicability ..............................................3
1.2. Requirements Language ......................................4
1.3. Terminology ................................................4
2. Overview ........................................................4
2.1. Disconnect Messages (DMs) ..................................5
2.2. Change-of-Authorization (CoA) Messages .....................5
2.3. Packet Format ..............................................6
3. Attributes .....................................................10
3.1. Proxy State ...............................................12
3.2. Authorize Only ............................................13
3.3. State .....................................................14
3.4. Message-Authenticator .....................................15
3.5. Error-Cause ...............................................16
3.6. Table of Attributes .......................................20
4. Diameter Considerations ........................................24
5. IANA Considerations ............................................26
6. Security Considerations ........................................26
6.1. Authorization Issues ......................................26
6.2. IPsec Usage Guidelines ....................................27
6.3. Replay Protection .........................................28
7. Example Traces .................................................28
8. References .....................................................29
8.1. Normative References ......................................29
8.2. Informative References ....................................30
9. Acknowledgments ................................................30
Appendix A ........................................................31
The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS).
[RFC2865]で定義されているRADIUSプロトコルは、RADIUSサーバーからネットワークアクセスサーバー（NAS）に送信された未承諾メッセージをサポートしていません。
However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for administrators to be able to terminate user session(s) in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from user session(s).
ただし、NASが交換を開始することを要求することなく、セッション特性に変更を加えることが望ましい多くの例があります。たとえば、管理者が進行中のユーザーセッションを終了できることが望ましい場合があります。または、ユーザーが認証レベルを変更する場合、これには、ユーザーセッションから承認属性を追加/削除する必要がある場合があります。
To overcome these limitations, several vendors have implemented additional RADIUS commands in order to enable unsolicited messages to be sent to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) packets. Disconnect packets cause user session(s) to be terminated immediately, whereas CoA packets modify session authorization attributes such as data filters.
これらの制限を克服するために、いくつかのベンダーがNASに送信される未承諾メッセージを有効にするために、追加のRADIUSコマンドを実装しています。これらの拡張コマンドは、切断および承認の変更（COA）パケットのサポートを提供します。パケットを切断すると、ユーザーセッションがすぐに終了しますが、COAパケットはデータフィルターなどのセッション承認属性を変更します。
This protocol is being recommended for publication as an Informational RFC rather than as a standards-track RFC because of problems that cannot be fixed without creating incompatibilities with deployed implementations. This includes security vulnerabilities, as well as semantic ambiguities resulting from the design of the Change-of-Authorization (CoA) commands. While fixes are recommended, they cannot be made mandatory since this would be incompatible with existing implementations.
このプロトコルは、展開された実装と非互換性を作成せずに修正できない問題のため、標準トラックRFCとしてではなく、情報RFCとして公開するために推奨されています。これには、セキュリティの脆弱性と、承認の変化（COA）コマンドの設計に起因する意味的なあいまいさが含まれます。修正は推奨されますが、これは既存の実装と互換性がないため、必須にすることはできません。
Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. In order to remedy this problem, a "Reverse Path Forwarding" check is described; see Section 6.1 for details.
このプロトコルの既存の実装は、認可チェックをサポートしていないため、ISPはNASを別のISPと共有することで、別のISPユーザーの認可を切断または変更する可能性があります。この問題を改善するために、「逆パス転送」チェックについて説明します。詳細については、セクション6.1を参照してください。
Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. To provide stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 6.2 for details.
既存の実装では、パケットごとの認証と整合性保護アルゴリズムが既知の弱点[MD5ATTACK]を使用します。より強力なパケット認証と整合性保護を提供するには、IPSECの使用をお勧めします。詳細については、セクション6.2を参照してください。
Existing implementations lack replay protection. In order to support replay detection, it is recommended that an Event-Timestamp Attribute be added to all packets in situations where IPsec replay protection is not employed. See Section 6.3 for details.
既存の実装には、リプレイ保護がありません。リプレイの検出をサポートするために、IPSECリプレイ保護が採用されていない状況で、すべてのパケットにイベントタイムスタンプ属性を追加することをお勧めします。詳細については、セクション6.3を参照してください。
The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving.
既存の実装でCOAコマンドで取られたアプローチは、セマンティックな曖昧さをもたらします。COA-Requestの既存の実装は、影響を受けるセッションを識別し、認可の変更を提供します。COA-Requestの既存の実装に含まれるRADIUS属性は、セッションの識別または承認の変更に使用できるため、特定の属性がどの機能を提供しているかは明らかではありません。
The problem does not exist within the Diameter protocol [RFC3588], in which server-initiated authorization change is initiated using a Re-Auth-Request (RAR) command identifying the session via User-Name and Session-Id Attribute Value Pairs (AVPs) and containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_ONLY". This results in initiation of a standard Request/Response sequence where authorization changes are supplied. As a result, in no command can Diameter AVPs have multiple potential meanings.
この問題は、直径プロトコル[RFC3588]内には存在しません。ここでは、ユーザー名とセッションID属性値ペア（AVP）を介してセッションを識別するReAuth-Request（RAR）コマンドを使用してサーバー開始の認証変更が開始されます。値「authorize_only」を備えたReAuth-Request-Type AVPを含む。これにより、承認の変更が提供される標準の要求/応答シーケンスの開始が行われます。その結果、COMMANDの直径はありませんAVPには複数の潜在的な意味があります。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document frequently uses the following terms:
このドキュメントは、頻繁に次の用語を使用します。
Dynamic Authorization Client (DAC) The entity originating Change of Authorization (CoA) Requests or Disconnect-Requests. While it is possible that the DAC is co-resident with a RADIUS authentication or accounting server, this need not necessarily be the case.
Dynamic Authorization Client（DAC）承認の変更（COA）リクエストまたは切断リケストのエンティティ。DACがRADIUS認証または会計サーバーの共同住宅である可能性はありますが、これは必ずしもそうである必要はありません。
Dynamic Authorization Server (DAS) The entity receiving CoA-Request or Disconnect-Request packets. The DAS may be a NAS or a RADIUS proxy.
Dynamic Authorization Server（DAS）COA-Requestまたは切断リケストパケットを受信するエンティティ。DASはNASまたは半径プロキシである可能性があります。
Network Access Server (NAS) The device providing access to the network.
ネットワークアクセスサーバー（NAS）ネットワークへのアクセスを提供するデバイス。
service The NAS provides a service to the user, such as IEEE 802 or Point-to-Point Protocol (PPP).
サービスNASは、IEEE 802やポイントツーポイントプロトコル（PPP）など、ユーザーにサービスを提供します。
session Each service provided by the NAS to a 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.
これは、実装がさらに処理せずにパケットを破棄することを意味します。実装は、静かに破棄されたパケットの内容を含むエラーを記録する機能を提供し、統計カウンターにイベントを記録する必要があります。
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization (CoA) packets.
このセクションでは、最も一般的に実装されている機能を切断および承認の変更（COA）パケットの機能について説明します。
A Disconnect-Request packet is sent by the Dynamic Authorization Client in order to terminate user session(s) on a NAS and discard all associated session context. The Disconnect-Request packet is sent to UDP port 3799, and identifies the NAS as well as the user session(s) to be terminated by inclusion of the identification attributes described in Section 3.
NASのユーザーセッションを終了し、関連するすべてのセッションコンテキストを破棄するために、Dynamic Authorization Clientによって切断パケットが送信されます。切断リケストパケットはUDPポート3799に送信され、セクション3で説明されている識別属性を含めることにより終了するユーザーセッションと同様に、NASとユーザーセッションを識別します。
+----------+ +----------+
| | Disconnect-Request | |
| | <-------------------- | |
| NAS | | DAC |
| | Disconnect-ACK/NAK | |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a Dynamic Authorization Client with a Disconnect-ACK if all associated session context is discarded and the user session(s) are no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect one or more sessions and discard all associated session context. A Disconnect-ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866] with the value set to 6 for Admin-Reset.
NASは、関連するすべてのセッションコンテキストが破棄され、ユーザーセッションが接続されなくなった場合、Dimantic Authorizationクライアントが切断されたCondonect-ackで送信したdesconnect-Requestパケットに応答します。1つ以上のセッションを切断し、関連するすべてのセッションコンテキストを破棄します。切断-CACKには、ACCTターミネート（49）属性[RFC2866]を含むACCTターミネート（49）属性が含まれ、admin-resetの値は6に設定されます。
CoA-Request packets contain information for dynamically changing session authorizations. Typically, this is used to change data filters. The data filters can be of either the ingress or egress kind, and are sent in addition to the identification attributes as described in Section 3. The port used and packet format (described in Section 2.3) are the same as those for Disconnect-Request packets.
COA-Requestパケットには、セッションの承認を動的に変更するための情報が含まれています。通常、これはデータフィルターを変更するために使用されます。データフィルターは、イングレスまたは出口種のいずれかであり、セクション3で説明されている識別属性に加えて送信されます。。
The following attributes MAY be sent in a CoA-Request:
次の属性は、COA-Requestで送信できます。
Filter-ID (11) - Indicates the name of a data filter list to be applied for the session(s) that the identification attributes map to.
Filter -ID（11） - 識別属性がマップするセッションに適用されるデータフィルターリストの名前を示します。
NAS-Filter-Rule (92) - Provides a filter list to be applied for the session(s) that the identification attributes map to [RFC4849].
NAS-Filter-Rule（92） - 識別属性が[RFC4849]にマップするというセッションに適用されるフィルターリストを提供します。
+----------+ +----------+
| | CoA-Request | |
| | <-------------------- | |
| NAS | | DAC |
| | CoA-ACK/NAK | |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a CoA-Request sent by a Dynamic Authorization Client with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session(s), or a CoA-NAK if the CoA-Request is unsuccessful. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with an unsupported value with a CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" SHOULD be included.
NASは、NASがユーザーセッションの承認をうまく変更できる場合、COA-ackを使用して動的な認証クライアントが送信したCOA-Requestに応答します。NASは、COA-NAKでサポートされていない値を持つサービスタイプの属性を含むCOA-Requestに応答する必要があります。値「サポートされていないサービス」を持つエラー（サポートされていないサービス」を含む属性を含める必要があります。
For either Disconnect-Request or CoA-Request packets UDP port 3799 is used as the destination port. For responses, the source and destination ports are reversed. Exactly one RADIUS packet is encapsulated in the UDP Data field.
切断されたRequestまたはCoA-Requestパケットのいずれかの場合、UDPポート3799は宛先ポートとして使用されます。応答のために、ソースと宛先ポートが逆転します。UDPデータフィールドには、正確に1つの半径パケットがカプセル化されています。
A summary of the data format is shown below. The fields are transmitted from left to right.
データ形式の概要を以下に示します。フィールドは左から右に送信されます。
The packet format consists of the following fields: Code, Identifier, Length, Authenticator, and Attributes in Type-Length-Value (TLV) format. All fields hold the same meaning as those described in RADIUS [RFC2865]. The Authenticator field MUST be calculated in the same way as is specified for an Accounting-Request in [RFC2866].
パケット形式は、次のフィールドで構成されています：型-Length-Value（TLV）形式のコード、識別子、長さ、認証器、および属性。すべてのフィールドは、半径[RFC2865]に記載されているフィールドと同じ意味を保持しています。[RFC2866]の会計要件に指定されているのと同じ方法で、認証器フィールドを計算する必要があります。
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. Packets received with an invalid Code field MUST be silently discarded. RADIUS codes (decimal) for this extension are assigned as follows:
コードフィールドは1オクテットで、RADIUSパケットのタイプを識別します。無効なコードフィールドで受信したパケットは、静かに破棄する必要があります。この拡張機能のRADIUSコード（小数）は次のように割り当てられます。
40 - Disconnect-Request [RFC3575]
41 - Disconnect-ACK [RFC3575]
42 - Disconnect-NAK [RFC3575]
43 - CoA-Request [RFC3575]
44 - CoA-ACK [RFC3575]
45 - CoA-NAK [RFC3575]
Identifier
識別子
The Identifier field is one octet, and aids in matching requests and replies. A Dynamic Authorization Server implementing this specification MUST be capable of detecting a duplicate request if it has the same source IP address, source UDP port, and Identifier within a short span of time.
識別子フィールドは1つのオクテットであり、リクエストと返信のマッチングに役立ちます。この仕様を実装する動的認証サーバーは、同じソースIPアドレス、ソースUDPポート、および識別子が短期間である場合、重複リクエストを検出できる必要があります。
The responsibility for retransmission of Disconnect-Request and CoA-Request packets lies with the Dynamic Authorization Client. If after sending these packets, the Dynamic Authorization Client does not receive a response, it will retransmit.
Disconnect-RequestおよびCOA-Requestパケットの再送信の責任は、動的な認証クライアントにあります。これらのパケットを送信した後、動的認証クライアントが応答を受信しない場合、再送信されます。
The Identifier field MUST be changed whenever the content of the Attributes field changes, or whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged.
識別子フィールドは、属性のコンテンツがフィールドが変更されたとき、または以前のリクエストに対して有効な返信を受信するたびに変更する必要があります。内容が同一である再送信の場合、識別子は変更されないままでなければなりません。
If the Dynamic Authorization Client is retransmitting a Disconnect-Request or CoA-Request to the same Dynamic Authorization Server as before, and the attributes haven't changed, the same Request Authenticator, Identifier, and source port MUST be used. If any attributes have changed, a new Authenticator and Identifier MUST be used.
動的認証クライアントが以前と同じ動的認証サーバーに切断リケストまたはCoA-Requestを再送信し、属性が変更されていない場合、同じリクエスト認証機、識別子、およびソースポートを使用する必要があります。属性が変更された場合、新しい認証器と識別子を使用する必要があります。
If the Request to a primary Dynamic Authorization Server fails, a secondary Dynamic Authorization Server must be queried, if available; issues relating to failover algorithms are described in [RFC3539]. Since this represents a new request, a new Request Authenticator and Identifier MUST be used. However, where the Dynamic Authorization Client is sending directly to the NAS, failover typically does not make sense, since CoA-Request or Disconnect-Request packets need to be delivered to the NAS where the session resides.
プライマリダイナミック認証サーバーへのリクエストが失敗した場合、利用可能な場合は二次的な動的認証サーバーを照会する必要があります。フェイルオーバーアルゴリズムに関連する問題は、[RFC3539]で説明されています。これは新しいリクエストを表すため、新しいリクエスト認証器と識別子を使用する必要があります。ただし、動的認証クライアントがNASに直接送信している場合、セッションが存在するNASに配信する必要があるため、フェールオーバーは通常意味がありません。
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オクテットです。コード、識別子、長さ、認証器、および属性フィールドを含むパケットの長さを示します。長さフィールドの範囲外のオクテットは、パディングとして扱われ、レセプションで無視する必要があります。パケットが長さのフィールドが示すよりも短い場合、静かに廃棄する必要があります。最小長は20で、最大長は4096です。
Authenticator
認証者
The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate packets between the Dynamic Authorization Client and the Dynamic Authorization Server.
Authenticatorフィールドは16個のオクテットです。最も重要なオクテットが最初に送信されます。この値は、Dynamic Authorizationクライアントと動的認証サーバーの間でパケットを認証するために使用されます。
Request Authenticator
Authenticatorをリクエストします
In Request packets, the Authenticator value is a 16-octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting-Request, specified in [RFC2866].
リクエストパケットでは、Authenticator値は、リクエストAuthenticatorと呼ばれる16オクテットMD5 [RFC1321]チェックサムです。リクエスト認証器は、[RFC2866]で指定された会計要因と同じ方法で計算されます。
Note that the Request Authenticator of a CoA-Request or Disconnect-Request cannot be computed the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password Attribute in a CoA-Request or Disconnect-Request.
COA-Requestまたは切断リケストのリクエスト認証機は、COA-Requestまたは切断要求にユーザーパスワード属性がないため、Radius Access-Requestのリクエスト認証者と同じ方法で計算できないことに注意してください。
Response Authenticator
応答認証器
The Authenticator field in a Response packet (e.g., Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of the Code, Identifier, Length, the Request Authenticator field from the packet being replied to, and the response attributes if any, followed by the shared secret. The resulting 16-octet MD5 hash value is stored in the Authenticator field of the Response packet.
応答パケット内の認証装置フィールド（例：切断、切断、nak、COA-ack、またはcoa-nak）は、応答認証者と呼ばれ、コード、識別子、長さ、返信されるパケットからのリクエスト認証機フィールド、および応答属性がある場合は、共有シークレットが続きます。結果として得られる16オクテットのMD5ハッシュ値は、応答パケットの認証器フィールドに保存されます。
Administrative note: As noted in [RFC2865], Section 3, the secret (password shared between the Dynamic Authorization Client and the Dynamic Authorization Server) SHOULD be at least as large and unguessable as a well-chosen password. The Dynamic Authorization Server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied.
管理ノート：[RFC2865]、セクション3に記載されているように、シークレット（動的認証クライアントと動的認証サーバーの間で共有されるパスワード）は、少なくとも選択されたパスワードと同じくらい大きく、調整できないはずです。Dynamic Authorization Serverは、RADIUS UDPパケットのソースIPアドレスを使用して、使用する共有シークレットを決定する必要があります。そうすることで、リクエストをプロにすることができます。
Attributes
属性
In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory. If one or more authorization changes specified in a CoA-Request cannot be carried out, the NAS MUST send a CoA-NAK. A NAS MUST respond to a CoA-Request containing one or more unsupported attributes or Attribute values with a CoA-NAK; an Error-Cause Attribute with value 401 (Unsupported Attribute) or 407 (Invalid Attribute Value) MAY be included. A NAS MUST respond to a Disconnect-Request containing one or more unsupported attributes or Attribute values with a Disconnect-NAK; an Error-Cause Attribute with value 401 (Unsupported Attribute) or 407 (Invalid Attribute Value) MAY be included.
COA-Requestおよび切断リケストパケットでは、すべての属性を必須として扱う必要があります。COA-Requestで指定された1つ以上の許可変更を実行できない場合、NASはCOA-NAKを送信する必要があります。NASは、1つ以上のサポートされていない属性または属性値をCOA-NAKで含むCOA-Requestに応答する必要があります。値401（サポートされていない属性）または407（無効な属性値）を備えたエラー（サポート属性）を含むエラー原因属性を含めることができます。NASは、1つまたは複数のサポートされていない属性または属性値を含む切断要求に応答する必要があります。値401（サポートされていない属性）または407（無効な属性値）を備えたエラー（サポート属性）を含むエラー原因属性を含めることができます。
State changes resulting from a CoA-Request MUST be atomic: if the CoA-Request is successful for all matching sessions, the NAS MUST send a CoA-ACK in reply, and all requested authorization changes MUST be made. If the CoA-Request is unsuccessful for any matching sessions, the NAS MUST send a CoA-NAK in reply, and the requested authorization changes MUST NOT be made for any of the matching sessions. Similarly, a state change MUST NOT occur as a result of a Disconnect-Request that is unsuccessful with respect to any of the matching sessions; a NAS MUST send a Disconnect-NAK in reply if any of the matching sessions cannot be successfully terminated. A NAS that does not support dynamic authorization changes applying to multiple sessions MUST send a CoA-NAK or Disconnect-NAK in reply; an Error-Cause Attribute with value 508 (Multiple Session Selection Unsupported) SHOULD be included.
COA-Requestに起因する状態の変更は原子でなければなりません。すべてのマッチングセッションでCOA-Requestが成功した場合、NASはCOA-ackを返信しなければならず、すべての要求された承認の変更を行う必要があります。COA-Requestが一致するセッションに失敗した場合、NASはCOA-NAKを返信して送信する必要があり、一致するセッションのいずれに対しても要求された承認の変更を加えてはなりません。同様に、一致するセッションのいずれかに関して失敗した切断要求の結果として、状態の変更が発生してはなりません。NASは、一致するセッションのいずれかが正常に終了できない場合、回答して切断されたものを送信する必要があります。複数のセッションに適用される動的な承認の変更をサポートしていないNASは、COA-NAKまたは切断されたNAKを返信する必要があります。値508（サポートされていない複数のセッション選択）を持つエラー（サポートされていない）属性を含める必要があります。
Within this specification, attributes can be used for identification, authorization, or other purposes. RADIUS Attribute specifications created after publication of this document SHOULD state whether an attribute can be included in CoA or Disconnect messages, and if so, which messages it can be included in and whether it serves as an identification or authorization attribute.
この仕様内では、属性を識別、承認、またはその他の目的に使用できます。このドキュメントの公開後に作成されたRADIUS属性仕様は、属性をCOAに含めるか、メッセージを切断できるかどうか、およびその場合、どのメッセージを含めることができるか、識別または承認属性として機能するかどうかを述べる必要があります。
Even if a NAS implements an attribute for use with RADIUS authentication and accounting, it is possible that it will not support inclusion of that attribute within CoA-Request and Disconnect-Request packets, given the difference in attribute semantics. This is true even for attributes specified as allowable within Access-Accept packets (such as those defined within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675], [RFC4818], and [RFC4849]).
NASがRADIUS認証と会計で使用する属性を実装していても、属性セマンティクスの違いを考えると、COA-Requestおよび切断リケストパケットにその属性を含めることをサポートしない可能性があります。これは、アクセスアセプトパケット内で許容されるものとして指定された属性（[RFC2865]、[RFC2868]、[RFC2869]、[RFC3162]、[RFC3579]、[RFC4372]、[RFC4372]、[RFC4675]、[RFC4818]、[RFC3579]、[RFC3579]、[RFC3579]、[RFC3579]、[RFC3579]でも指定されている属性にも当てはまります。]、および[RFC4849]）。
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as user session(s) on the NAS. The combination of NAS and session identification attributes included in a CoA-Request or Disconnect-Request packet MUST match at least one session in order for a Request to be successful; otherwise a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification attributes match, and more than one session matches all of the session identification attributes, then a CoA-Request or Disconnect-Request MUST apply to all matching sessions.
切断-RequestおよびCOA-Requestパケットでは、特定の属性を使用して、NASとNASのユーザーセッションを一意に識別します。NASとセッション識別属性の組み合わせは、リクエストを成功させるために、COA-Requestまたは切断のリクエストパケットに含まれる必要がある必要があります。それ以外の場合は、切断されたNAKまたはCOA-NAKを送信する必要があります。すべてのNAS識別属性が一致し、複数のセッションがすべてのセッション識別属性と一致する場合、COA-Requestまたは切断リケストはすべてのマッチングセッションに適用する必要があります。
Identification attributes include NAS and session identification attributes, as described below.
識別属性には、以下で説明するように、NASおよびセッション識別属性が含まれます。
NAS identification attributes
NAS識別属性
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Session identification attributes
セッション識別属性
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with one or
more sessions.
NAS-Port 5 [RFC2865] The port on which a
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with a session.
Vendor-Specific 26 [RFC2865] One or more vendor-specific
identification attributes.
Called-Station-Id 30 [RFC2865] The link address to which
a session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
one or more sessions are
connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying a session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Id 87 [RFC2869] String identifying the port
where a session is.
Chargeable-User- 89 [RFC4372] The CUI associated with one
Identity or more sessions. Needed
where a privacy Network
Access Identifier (NAI) is
used, since in this case the
User-Name (e.g., "anonymous")
may not identify sessions
belonging to a given user.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with a session,
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with a session, always sent
with Framed-Interface-Id.
To address security concerns described in Section 6.1, either the User-Name or Chargeable-User-Identity attribute SHOULD be present in Disconnect-Request and CoA-Request packets.
セクション6.1で説明されているセキュリティの懸念に対処するには、ユーザー名または課金可能なユーザーアイデンティティ属性のいずれかを、切断リケストおよびCOA-Requestパケットに存在する必要があります。
Where a Diameter client utilizes the same Session-Id for both authorization and accounting, inclusion of an Acct-Session-Id Attribute in a Disconnect-Request or CoA-Request can assist with Diameter/RADIUS translation, since Diameter RAR and ASR commands include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be included in Disconnect-Request and CoA-Request packets.
直径RARおよびASRコマンドには、ACCT-セッションID属性を切断またはCOA-Requestに含めると、承認と会計の両方に同じセッションIDを使用する場合、ACCT-セッションID属性が直径/半径の翻訳を支援できます。SESSION-ID AVP。ACCT-SESSION-ID属性は、切断リケストおよびCOA-Requestパケットに含める必要があります。
A NAS implementing this specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an Access-Request. Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included within an Access-Request, the Dynamic Authorization Client will not know the Acct-Session-Id or Acct-Multi-Session-Id of the session it is attempting to target, unless it also has access to the accounting data for that session.
この仕様を実装するNASは、Acct-Session-IDまたはACCT-Multi-Session-ID属性をAccess-Request内に送信する必要があります。ACCT-SESSION-IDまたはACCT-MULTI-SESSION-ID属性がAccess-Requestに含まれていない場合、Dynamic Authorizationクライアントは、セッションのACCT-Session-IDまたはACCT-Multi-Session-IDを知りませんそのセッションの会計データにもアクセスできる場合を除き、ターゲットをターゲットにしようとしています。
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, it is possible that the User-Name or Chargeable-User-Identity attributes will not be sufficient to uniquely identify a single session (e.g., if the same user has multiple sessions on the NAS, or if the privacy NAI is used). In this case, if it is desired to identify a single session, session identification MAY be performed by using one or more of the Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
ACCT-SESSION-IDまたはACCT-MULTI-SESSION-ID属性がCOA-Requestまたは切断リケストに存在しない場合、ユーザー名または課金可能なユーザーアイデンティティ属性が一意になるのに十分ではない可能性があります単一のセッションを特定します（たとえば、同じユーザーがNASに複数のセッションを持っている場合、またはプライバシーNAIが使用されている場合）。この場合、単一のセッションを識別することが望ましい場合、セッションの識別は、1つまたは複数のフレームIPアドレス、フレーム付きIPv6-Prefix/framed-interface-id、Station-id、framed-interface-idを使用して実行できます。Calling-Station-ID、NAS-Port、およびNas-Port-ID属性。
To assist RADIUS proxies in routing Request packets to their destination, one or more of the NAS-IP-Address or NAS-IPv6-Address attributes SHOULD be present in CoA-Request and Disconnect-Request packets; the NAS-Identifier Attribute MAY be present. Impersonation issues with NAS Identification attributes are discussed in [RFC3579], Section 4.3.7.
宛先へのルーティングリクエストパケットのRADIUSプロキシを支援するには、NAS-IP-AddressまたはNAS-IPV6-Addressの属性の1つ以上が、COA-Requestおよび切断リケストパケットに存在する必要があります。Nas-Identifier属性が存在する場合があります。NAS識別属性に関するなりすましの問題については、[RFC3579]、セクション4.3.7で説明しています。
A Disconnect-Request MUST contain only NAS and session identification attributes. If other attributes are included in a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
切断要件には、NASとセッション識別属性のみを含める必要があります。他の属性が切断リケストに含まれている場合、実装は切断されたものを送信する必要があります。値「サポートされていない属性」を持つエラー（サポートされていない属性」が含まれる場合があります。
The DAC may require access to data from RADIUS authentication or accounting packets. It uses this data to compose compliant CoA-Request or Disconnect-Request packets. For example, as described in Section 3.3, a CoA-Request packet containing a Service-Type Attribute with a value of "Authorize Only" is required to contain a State Attribute. The NAS will subsequently transmit this attribute to the RADIUS server in an Access-Request. In order for the DAC to include a State Attribute that the RADIUS server will subsequently accept, some coordination between the two parties may be required.
DACは、RADIUS認証または会計パケットからのデータへのアクセスが必要になる場合があります。このデータを使用して、準拠したCOA-Requestまたは切断リケストパケットを作成します。たとえば、セクション3.3で説明したように、「Authorizeのみ」の値を持つサービスタイプの属性を含むCOA-Requestパケットは、状態属性を含める必要があります。NASはその後、アクセスレクエストでこの属性をRADIUSサーバーに送信します。DACがRADIUSサーバーがその後受け入れる状態属性を含めるためには、2つの当事者間のいくつかの調整が必要になる場合があります。
This coordination can be achieved in multiple ways. The DAC may be co-located with a RADIUS server, in which case it is presumed to have access to the necessary data. The RADIUS server may also store that information in a common database. The DAC can then be separated from the RADIUS server, so long as it has access to that common database.
この調整は、複数の方法で達成できます。DACは、RADIUSサーバーと共同で配置される場合があります。この場合、必要なデータにアクセスできると推定されます。RADIUSサーバーは、その情報を共通のデータベースに保存することもできます。その後、DACは、その一般的なデータベースにアクセスできる限り、RADIUSサーバーから分離できます。
Where the DAC is not co-located with a RADIUS server, and does not have access to a common database, the DAC SHOULD send CoA-Request or Disconnect-Request packets to a RADIUS server acting as a proxy, rather than sending them directly to the NAS.
DACがRADIUSサーバーと共同住宅されておらず、共通のデータベースにアクセスできない場合、DACはCOA-Requestまたは切断パケットをプロキシとして動作するRADIUSサーバーに直接送信するのではなく、RADIUSサーバーに送信する必要があります。NAS。
A RADIUS server receiving a CoA-Request or Disconnect-Request packet from the DAC MAY then add or update attributes (such as adding NAS or session identification attributes or appending a State Attribute), prior to forwarding the packet. Having CoA/Disconnect-Requests forwarded by a RADIUS server can also enable upstream RADIUS proxies to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).
パケットを転送する前に、DACからCOA-Requestまたは切断リクエストパケットを受信するRADIUSサーバー（NASまたはセッション識別属性の追加や状態属性の追加など）を追加または更新することができます。RADIUSサーバーによって転送されたCOA/切断リケストを使用すると、上流のRADIUSプロキシが逆パス転送（RPF）チェックを実行できるようにすることもできます（セクション6.1を参照）。
If there are any Proxy-State attributes in a Disconnect-Request or CoA-Request received from the Dynamic Authorization Client, the Dynamic Authorization Server MUST include those Proxy-State attributes in its response to the Dynamic Authorization Client.
Dynamic Authorizationクライアントから受信した切断リケストまたはCOA-Requestにプロキシステート属性がある場合、動的認証サーバーは、動的認証クライアントへの応答にそれらのプロキシ状態属性を含める必要があります。
A forwarding proxy or NAS MUST NOT modify existing Proxy-State, State, or Class attributes present in the packet. The forwarding proxy or NAS 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 proxies. The forwarding proxy MUST NOT modify any other Proxy-State attributes that were in the packet; it may choose not to forward them, but it MUST NOT change their contents. If the forwarding proxy omits the Proxy-State attributes in the request, it MUST attach them to the response before sending it.
転送プロキシまたはNASは、パケットに存在する既存のプロキシ状態、状態、またはクラスの属性を変更してはなりません。転送プロキシまたはNASは、パケット内にすでに不透明なデータとして既にあるプロキシ状態属性を扱う必要があります。その操作は、以前のプロキシによって追加されたプロキシステート属性の内容に依存してはなりません。転送プロキシは、パケットに含まれていた他のプロキシ状態属性を変更してはなりません。それらを転送しないことを選択するかもしれませんが、コンテンツを変更してはなりません。転送プロキシがリクエスト内のプロキシステート属性を省略している場合、送信する前に応答に添付する必要があります。
When the proxy forwards a Disconnect-Request or CoA-Request, it MAY add a Proxy-State Attribute, but it MUST NOT add more than one. 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 forwarding proxy MUST NOT change the order of any attributes of the same type, including Proxy-State. Other attributes can be placed before, after, or even between the Proxy-State attributes.
プロキシが切断リケストまたはCOA-Requestを転送する場合、プロキシステート属性を追加する可能性がありますが、1つ以上追加してはなりません。パケットを転送するときにプロキシステート属性がパケットに追加される場合、既存のプロキシ状態属性の後にプロキシステート属性を追加する必要があります。転送プロキシは、プロキシステートを含む同じタイプの属性の順序を変更してはなりません。他の属性は、プロキシステート属性の前、後、または間に配置することができます。
When the proxy receives a response to a CoA-Request or Disconnect-Request, it MUST remove its own Proxy-State Attribute (the last Proxy-State in the packet) before forwarding the response. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check, so the proxy MUST recompute it.
プロキシがCOA-Requestまたは切断リケストに対する応答を受信した場合、応答を転送する前に、独自のプロキシ状態属性（パケットの最後のプロキシステート）を削除する必要があります。切断およびCOA応答はパケットコンテンツ全体で認証されるため、プロキシステート属性のストリッピングは整合性チェックを無効にするため、プロキシはそれを再計算する必要があります。
To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request; see Section 4 for details on Diameter considerations. Support for a CoA-Request including a Service-Type Attribute with value "Authorize Only" is OPTIONAL on the NAS and Dynamic Authorization Client. A Service-Type Attribute MUST NOT be included within a Disconnect-Request.
半径と直径の間の翻訳を簡素化するために、動的認証クライアントは、COA-Request内で「承認のみ」を持つサービスタイプの属性を含めることができます。直径の考慮事項の詳細については、セクション4を参照してください。値「承認のみ」を持つサービスタイプの属性を含むCOA-Requestのサポートは、NASおよびDynamic Authorizationクライアントでオプションです。Service-Type属性は、切断リケストに含めてはなりません。
A NAS MUST respond to a CoA-Request including a Service-Type Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. If the NAS does not support a Service-Type value of "Authorize Only", then it MUST respond with a CoA-NAK; an Error-Cause Attribute with a value of 405 (Unsupported Service) SHOULD be included.
NASは、COA-NAKで「承認のみ」を持つサービスタイプの属性を含むCOA-Requestに応答する必要があります。COA-ackを送信してはなりません。NASが「承認のみ」のサービスタイプの値をサポートしていない場合、COA-NAKで応答する必要があります。405の値（サポートされていないサービス）のエラー（サポートされていないサービス）を含める必要があります。
A CoA-Request containing a Service-Type Attribute with value "Authorize Only" MUST in addition contain only NAS or session identification attributes, as well as a State Attribute. If other attributes are included in such a CoA-Request, a CoA-NAK MUST be sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) SHOULD be included.
値「承認」のみを持つサービスタイプの属性を含むCOA-Requestには、NASまたはセッション識別属性のみ、および状態属性のみが含まれている必要があります。そのようなCOA-Requestに他の属性が含まれている場合、COA-NAKを送信する必要があります。値401（サポートされていない属性）を持つエラー（サポート属性）を含むエラー原因属性を含める必要があります。
If a CoA-Request packet including a Service-Type value of "Authorize Only" is successfully processed, the NAS MUST respond with a CoA-NAK containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value 507 (Request Initiated). The NAS then MUST send an Access-Request to the RADIUS server including a Service-Type Attribute with value "Authorize Only", along with a State Attribute. This Access-Request SHOULD contain the NAS identification attributes from the CoA-Request, as well as the session identification attributes from the CoA-Request permitted in an Access-Request; it also MAY contain other attributes permitted in an Access-Request.
「Authorizeのみ」のサービスタイプ値を含むCOA-Requestパケットが正常に処理された場合、NASは、値「Authorizeのみ」を持つサービスタイプの属性を含むCOA-NAKと、エラー（Value 507（リクエスト開始）。NASは、value型属性を「承認のみ」のサービス型属性とともに、状態属性を含む、RADIUSサーバーにアクセスリケストを送信する必要があります。このAccess-Requestには、COA-RequestのNAS識別属性と、アクセスリケストで許可されているCOA-Requestのセッション識別属性を含める必要があります。また、アクセスレクエストで許可されている他の属性を含める場合があります。
As noted in [RFC2869], Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password, or EAP-Message Attribute. The RADIUS server then will respond to the Access-Request with an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it.
[RFC2869]、セクション5.19に記載されているように、メッセージauthenticatorの属性は、ユーザーパスワード、チャップパスワード、ARAPパスワード、またはEAPメス属性を含まないアクセス要求に含める必要があります。その後、RADIUSサーバーは、Access-RequestにAccess-Acceptを（再）承認するか、Access-rejectが拒否して（再）承認を拒否します。
The State Attribute is available to be sent by the Dynamic Authorization Client to the NAS in a CoA-Request packet and MUST be sent unmodified from the NAS to the Dynamic Authorization Client in a subsequent ACK or NAK packet.
状態属性は、動的認証クライアントによってCOA-RequestパケットでNASに送信される可能性があり、その後のACKまたはNAKパケットでNASから動的認証クライアントに変更されていないように送信する必要があります。
[RFC2865], Section 5.44 states:
[RFC2865]、セクション5.44の状態：
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.
Access-Requestには、ユーザーパスワードまたはチャップパスワードまたは状態のいずれかを含める必要があります。Access-Requestには、ユーザーパスワードとチャップパスワードの両方を含めてはなりません。将来の拡張機能が他の種類の認証情報を伝達することを許可する場合、その属性はユーザーパスワードまたはチャップパスワードの代わりにアクセスリケストで使用できます。
In order to satisfy the requirements of [RFC2865], Section 5.44, an Access-Request with Service-Type Attribute with value "Authorize Only" MUST contain a State Attribute.
[RFC2865]、セクション5.44の要件を満たすために、値「承認のみ」を備えたサービスタイプの属性を備えたアクセスレクエストは、状態属性を含む必要があります。
In order to provide a State Attribute to the NAS, a Dynamic Authorization Client sending a CoA-Request with a Service-Type Attribute with a value of "Authorize Only" MUST include a State Attribute, and the NAS MUST send the State Attribute unmodified to the RADIUS server in the resulting Access-Request, if any. A NAS receiving a CoA-Request containing a Service-Type Attribute with a value of "Authorize Only" but lacking a State Attribute MUST send a CoA-NAK and SHOULD include an Error-Cause Attribute with a value of 402 (Missing Attribute).
NASに状態属性を提供するために、「承認のみ」の値を持つサービスタイプの属性を持つCOA-Requestを送信する動的な認証クライアントは、状態属性を含める必要があり、NASは状態属性を変更していないことを送信する必要があります。結果のAccess-RequestのRADIUSサーバー（ある場合）。「Authorizeのみ」の値を持つサービス型属性を含むCOA-Requestを受信するNASは、状態属性を欠く必要がある必要があり、402の値（属性の欠落）のエラー原因属性を含める必要があります。
The State Attribute is also available to be sent by the Dynamic Authorization Client to the NAS in a CoA-Request 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. In either usage, the Dynamic Authorization Server MUST NOT interpret the Attribute locally. A CoA-Request packet MUST have only zero or one State Attribute. Usage of the State Attribute is implementation dependent.
State属性は、Radius-Requestの値を持つ終端アクション属性も含むCOA-Requestで、動的認証クライアントによってNASに送信されることもできます。NASが現在のセッションの終了時に新しいアクセス要求を送信して終了アクションを実行する場合、そのアクセスレクエストに変更されていない状態属性を含める必要があります。どちらの使用法でも、動的認証サーバーは属性をローカルに解釈してはなりません。COA-Requestパケットには、ゼロまたは1つの状態属性のみが必要です。状態属性の使用は実装に依存します。
The Message-Authenticator Attribute MAY be used to authenticate and integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, Disconnect-ACK, and Disconnect-NAK packets in order to prevent spoofing.
メッセージ-Authenticator属性は、COA-Request、CoA-caCK、COA-NAK、disconnect-request、disconnect-cack、およびreduntnect-nakパケットを認証および整合性保護に使用して、スプーフィングを防ぐことができます。
A Dynamic Authorization Server receiving a CoA-Request or Disconnect-Request with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A Dynamic Authorization Client receiving a CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
存在するメッセージ-Authenticator属性を使用してCOA-Requestまたは切断リケストを受信する動的な認証サーバーは、メッセージ-Authenticatorの正しい値を計算し、送信された値と一致しない場合はパケットを静かに破棄する必要があります。coA/disconnect-ackまたはcoA/disconnect-nakを受信する動的な承認クライアントは、メッセージとauthenticatorの属性を備えている必要があります。
When a Message-Authenticator Attribute is included within a CoA-Request or Disconnect-Request, it is calculated as follows:
メッセージ-Authenticator属性がCOA-Requestまたは切断リケスト内に含まれている場合、次のように計算されます。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
message-authenticator = hmac-md5（タイプ、識別子、長さ、リクエスト認証者、属性）
When the HMAC-MD5 message integrity check is calculated the Request Authenticator field and Message-Authenticator Attribute MUST each be considered to be sixteen octets of zero. The Message-Authenticator Attribute is calculated and inserted in the packet before the Request Authenticator is calculated.
HMAC-MD5メッセージの整合性チェックが計算されると、リクエスト認証器のフィールドとメッセージauthenticator属性がそれぞれゼロの16オクテットと見なされる必要があります。Request Authenticator属性が計算され、パケットに挿入されますAuthenticatorが計算される前に挿入されます。
When a Message-Authenticator Attribute is included within a CoA-ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated as follows:
Message-authenticator属性がCOA-ack、coa-nak、disconnect-ack、またはdisconnect-nakに含まれる場合、次のように計算されます。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
message-authenticator = hmac-md5（タイプ、識別子、長さ、リクエスト認証者、属性）
When the HMAC-MD5 message integrity check is calculated, the Message-Authenticator Attribute MUST be considered to be sixteen octets of zero. The Request Authenticator is taken from the corresponding CoA/Disconnect-Request. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated.
HMAC-MD5メッセージの整合性チェックが計算される場合、メッセージauthenticator属性はゼロの16オクテットと見なされる必要があります。リクエスト認証機は、対応するCOA/切断要求から取得されます。応答認証者が計算される前に、メッセージauthenticatorがパケットに計算され、挿入されます。
Description
説明
It is possible that a Dynamic Authorization Server cannot honor Disconnect-Request or CoA-Request packets for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within CoA-NAK and Disconnect-NAK packets.
動的な認証サーバーは、何らかの理由で切断されたリケストまたはCOA-Requestパケットを尊重できない可能性があります。エラー原因属性は、問題の原因に関する詳細を提供します。COA-NAKおよび切断されたパケットに含まれる場合があります。
A summary of the Error-Cause 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
タイプ
101 for Error-Cause
エラー原因については101
Length
長さ
6
6
Value
価値
The Value field is four octets, containing an integer specifying the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so that these values may only be sent within CoA-ACK or Disconnect-ACK packets and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. Values 400-499 represent fatal errors committed by the Dynamic Authorization Client, so that they MAY be sent within CoA-NAK or Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or Disconnect-ACK packets. Values 500-599 represent fatal errors occurring on a Dynamic Authorization Server, so that they MAY be sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values SHOULD be logged by the Dynamic Authorization Client. Error-Code values (expressed in decimal) include:
値フィールドは4オクテットで、エラーの原因を指定する整数が含まれています。値0-199および300-399は予約されています。値200-299は正常な完了を表します。そのため、これらの値はCOA-ackまたは切断パケット内でのみ送信され、COA-NAKまたは切断NAKパケット内で送信されないようにします。Value 400-499は、動的認証クライアントが犯した致命的なエラーを表し、COA-NAKまたは切断されたパケット内で送信し、COA-ackまたはdisconnect-cackパケット内で送信してはなりません。Value 500-599は、動的な認証サーバーで発生する致命的なエラーを表し、COA-NAK内で送信してNAKを切断することができ、COA-ackまたは切断パケット内で送信してはなりません。動的な認証クライアントは、エラー原因値を記録する必要があります。エラーコード値（小数で表される）は次のとおりです。
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
407 Invalid Attribute Value
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
508 Multiple Session Selection Unsupported
"Residual Session Context Removed" is sent in response to a Disconnect-Request if one or more user sessions are no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK.
1つ以上のユーザーセッションがアクティブではなくなったが、残留セッションのコンテキストが見つかり、正常に削除された場合、「残留セッションコンテキスト削除」は切断要求に応じて送信されます。この値は、切断済みの範囲内でのみ送信され、COA-ack、disconnect-nak、またはcoa-nak内で送信してはなりません。
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification.
「無効なEAPパケット（無視）」は、この仕様の実装によって送信されてはならない致命的ではないエラーです。
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported.
「サポートされていない属性」は、リクエストにサポートされていない属性（ベンダー固有の属性やEAPメッセージ属性など）が含まれている場合に送信される致命的なエラーです。
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request.
「属性の欠落」は、リクエストから重要な属性（NASやセッション識別属性など）が欠落している場合に送信される致命的なエラーです。
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3) do not match the identity of the NAS receiving the Request.
「NAS識別の不一致」は、1つ以上のNAS識別属性（セクション3を参照）がリクエストを受けたNASのIDと一致しない場合に送信される致命的なエラーです。
"Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP-Message Attribute(s)) are not formatted properly.
「無効な要求」は、1つ以上の属性（EAPメッセージ属性など）が適切にフォーマットされていない場合など、リクエストの他の側面が無効である場合に送信される致命的なエラーです。
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value. This error cannot be sent in response to a Disconnect-Request.
「サポートされていないサービス」は、リクエストに含まれるサービスタイプの属性が無効またはサポートされていない値で送信された場合に送信される致命的なエラーです。このエラーは、切断要求に応じて送信できません。
"Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA packets. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a CoA-Request or Disconnect-Request to the NAS.
「サポートされていない拡張機能」は、切断やCOAパケットなどの拡張機能のサポートが不足しているために送信される致命的なエラーです。これは通常、NASにCOA-Requestまたは切断要求を転送しようとした後、ICMPポートの到達不可能なメッセージを受信するプロキシによって送信されます。
"Invalid Attribute Value" is a fatal error sent if a CoA-Request or Disconnect-Request contains an attribute with an unsupported value.
「無効な属性値」は、COA-Requestまたは切断要求にサポートされていない値を持つ属性が含まれている場合に送信される致命的なエラーです。
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of CoA-Request or Disconnect-Request packets for the specified session.
「管理上禁止」とは、指定されたセッションのCOA-Requestまたは切断リケストパケットの敬意を禁止するようにNASが設定されている場合、致命的なエラーが送信されます。
"Request Not Routable" is a fatal error that MAY be sent by a proxy and MUST NOT be sent by a NAS. It indicates that the proxy was unable to determine how to route a CoA-Request or Disconnect-Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table.
「ルーティングできない」は、プロキシによって送信される可能性のある致命的なエラーであり、NASによって送信されてはなりません。これは、プロキシがNASへのCOA-Requestまたは切断要求をルーティングする方法を決定できなかったことを示しています。たとえば、これは、必要なエントリがプロキシのレルムルーティングテーブルに存在しない場合に発生する可能性があります。
"Session Context Not Found" is a fatal error sent if the session context identified in the CoA-Request or Disconnect-Request does not exist on the NAS.
「セッションのコンテキストが見つかりません」は、NASにCOA-Requestまたは切断リケストで識別されたセッションコンテキストが存在しない場合に送信される致命的なエラーです。
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK, or Disconnect-ACK, only within a Disconnect-NAK.
「セッションのコンテキストがリムーブルではない」は、NASがセッションコンテキストを見つけることができたが、何らかの理由でそれを削除できなかった場合、切断要求に応じて送信された致命的なエラーです。COA-ack、coa-nak、またはdisconnect-cack内でのみ送信してはなりません。
"Other Proxy Processing Error" is a fatal error sent in response to a CoA or Disconnect-Request that could not be processed by a proxy, for reasons other than routing.
「その他のプロキシ処理エラー」は、ルーティング以外の理由で、プロキシによって処理できなかったCOAまたは切断リケストに応じて送信される致命的なエラーです。
"Resources Unavailable" is a fatal error sent when a CoA or Disconnect-Request could not be honored due to lack of available NAS resources (memory, non-volatile storage, etc.).
「リソースは利用できない」とは、利用可能なNASリソース（メモリ、不揮発性ストレージなど）が不足しているため、COAまたは切断要求を尊重できなかった場合に送信される致命的なエラーです。
"Request Initiated" is a fatal error sent by a NAS in response to a CoA-Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the CoA-Request has not been honored, but that the NAS is sending one or more RADIUS Access-Requests including a Service-Type Attribute with value "Authorize Only" to the RADIUS server.
「リクエスト開始」は、「承認のみ」の値を持つサービスタイプの属性を含むCOA-Requestに応じて、NASが送信した致命的なエラーです。これは、COA-Requestが尊重されていないことを示していますが、NASは、Radiusサーバーに「承認のみ」のValue-Type属性を含む1つ以上の半径アクセスリケストを送信していることを示しています。
"Multiple Session Selection Unsupported" is a fatal error sent by a NAS in response to a CoA-Request or Disconnect-Request whose session identification attributes match multiple sessions, where the NAS does not support Requests applying to multiple sessions.
「サポートされていない複数のセッションの選択」は、セッション識別属性が複数のセッションに一致するCOA-Requestまたは切断要求に応じてNASによって送信された致命的なエラーです。
The following table provides a guide to which attributes may be found in which packets, and in what quantity.
次の表には、どの属性がどのパケットで、どの量の属性が見つかるかについてのガイドを示します。
Change-of-Authorization Messages
承認メッセージの変更
Request ACK NAK # Attribute 0-1 0 0 1 User-Name (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 5 NAS-Port (Note 1) 0-1 0 0-1 6 Service-Type 0-1 0 0 7 Framed-Protocol (Note 3) 0-1 0 0 8 Framed-IP-Address (Notes 1, 6) 0-1 0 0 9 Framed-IP-Netmask (Note 3) 0-1 0 0 10 Framed-Routing (Note 3) 0+ 0 0 11 Filter-ID (Note 3) 0-1 0 0 12 Framed-MTU (Note 3) 0+ 0 0 13 Framed-Compression (Note 3) 0+ 0 0 14 Login-IP-Host (Note 3) 0-1 0 0 15 Login-Service (Note 3) 0-1 0 0 16 Login-TCP-Port (Note 3) 0+ 0 0 18 Reply-Message (Note 2) 0-1 0 0 19 Callback-Number (Note 3) 0-1 0 0 20 Callback-Id (Note 3) 0+ 0 0 22 Framed-Route (Note 3) 0-1 0 0 23 Framed-IPX-Network (Note 3) 0-1 0-1 0-1 24 State 0+ 0 0 25 Class (Note 3) 0+ 0 0 26 Vendor-Specific (Note 7) 0-1 0 0 27 Session-Timeout (Note 3) 0-1 0 0 28 Idle-Timeout (Note 3) 0-1 0 0 29 Termination-Action (Note 3) Request ACK NAK # Attribute Request ACK NAK # Attribute 0-1 0 0 30 Called-Station-Id (Note 1) 0-1 0 0 31 Calling-Station-Id (Note 1) 0-1 0 0 32 NAS-Identifier (Note 1) 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 34 Login-LAT-Service (Note 3) 0-1 0 0 35 Login-LAT-Node (Note 3) 0-1 0 0 36 Login-LAT-Group (Note 3) 0-1 0 0 37 Framed-AppleTalk-Link (Note 3) 0+ 0 0 38 Framed-AppleTalk-Network (Note 3) 0-1 0 0 39 Framed-AppleTalk-Zone (Note 3) 0-1 0 0 44 Acct-Session-Id (Note 1) 0-1 0 0 50 Acct-Multi-Session-Id (Note 1) 0-1 0-1 0-1 55 Event-Timestamp 0+ 0 0 56 Egress-VLANID (Note 3) 0-1 0 0 57 Ingress-Filters (Note 3) 0+ 0 0 58 Egress-VLAN-Name (Note 3) 0-1 0 0 59 User-Priority-Table (Note 3) 0-1 0 0 61 NAS-Port-Type (Note 3) 0-1 0 0 62 Port-Limit (Note 3) 0-1 0 0 63 Login-LAT-Port (Note 3) 0+ 0 0 64 Tunnel-Type (Note 5) 0+ 0 0 65 Tunnel-Medium-Type (Note 5) 0+ 0 0 66 Tunnel-Client-Endpoint (Note 5) 0+ 0 0 67 Tunnel-Server-Endpoint (Note 5) 0+ 0 0 69 Tunnel-Password (Note 5) 0-1 0 0 71 ARAP-Features (Note 3) 0-1 0 0 72 ARAP-Zone-Access (Note 3) 0+ 0 0 78 Configuration-Token (Note 3) 0+ 0-1 0 79 EAP-Message (Note 2) 0-1 0-1 0-1 80 Message-Authenticator 0+ 0 0 81 Tunnel-Private-Group-ID (Note 5) 0+ 0 0 82 Tunnel-Assignment-ID (Note 5) 0+ 0 0 83 Tunnel-Preference (Note 5) 0-1 0 0 85 Acct-Interim-Interval (Note 3) 0-1 0 0 87 NAS-Port-Id (Note 1) 0-1 0 0 88 Framed-Pool (Note 3) 0-1 0 0 89 Chargeable-User-Identity (Note 1) 0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5) 0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5) 0-1 0 0 92 NAS-Filter-Rule (Note 3) 0 0 0 94 Originating-Line-Info 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0-1 0 0 96 Framed-Interface-Id (Notes 1, 6) 0+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6) 0+ 0 0 98 Login-IPv6-Host (Note 3) 0+ 0 0 99 Framed-IPv6-Route (Note 3) Request ACK NAK # Attribute Request ACK NAK # Attribute 0-1 0 0 100 Framed-IPv6-Pool (Note 3) 0 0 0+ 101 Error-Cause 0+ 0 0 123 Delegated-IPv6-Prefix (Note 3) Request ACK NAK # Attribute
リクエストACK NAK＃属性0-1 0 0 1ユーザー名（注1）0-1 0 0 4 NAS-IP-Address（注1）0-1 0 0 NAS-ポート（注1）0-1 00-1 6 service-type 0-1 0 0 7 framed-protocol（note 3）0-1 0 0 8 framed-ip-address（注1、6）0-1 0 0 9 framed-ip-netmask（注3）0-1 0 0 10フレームルーティング（注3）0 0 0 11フィルターID（注3）0-1 00 0 0 14 LOGIN-IP-HOST（注3）0-1 0 0 15 LOGIN-SERVICE（注3）0-1 02）0-1 0 0 19コールバック番号（注3）0-1 0 0 20コールバックID（注3）0 0 2222額枠（注3）0-1 0 0 23 Framed-IPX-Network（注3）0-1 0-1 0-1 24状態0 0 0 25クラス（注3）0 0 0 26ベンダー固有（注7）0-1 0 2 27セッションタイムアウト（注3）0-1 0 0 28アイドルタイムアウト（注3）0-1 0-1 0 0 31 Calling-Station-ID（注1）0-1 0 0 32 Nas-Identifier（Note 1）0 0 0 33 Proxy-State 0-1 0 0 34 Login-Lat-Service（Note 3）0-1 0 0 35 LOGIN-LAT-NODE（注3）0-1 0AppleTalk-network（注3）0-1 0 0 39フレームアップルラークゾーン（注3）0-1 0 0 44 ACCT-SESSION-ID（注1）0-1 0 50 ACCT-MULTI-SESSION-ID（注1）0-1 0-1 0-1 55 Event-Timestamp 0 0 0 56 Egress-Vlanid（注3）0-1 0 57イングレスフィルター（注3）0 0 58 EGRESS-VLAN-NAME（注3）0-1 0 0 59ユーザー-Priority-Table（注3）0-1 0 0 61 NAS-PORT-TYPE（注3）0-1 0 0 62ポートリミット（注3）0-10 0 63 Login-Lat-Port（注3）0 0 0 64トンネルタイプ（注5）0 0 0 65トンネルメディウムタイプ（注5）0 0 0 66トンネルクライアントエンドポイント（注5）00 0 67トンネルサーバーエンドポイント（注5）0 0 69トンネルパスワード（注5）0-1 0 0 71アラップフィーチュア（注3）0-1 0 0 72 ARAP-ZONE-ACCESS（注3）0 0 0 78構成 - トークン（注3）0 0-1 0 79 EAP-Message（注2）0-1 0-1 0-1 80メッセージ-Authenticator 0 0 0 81 Tunnel-Private-Group-ID（注5）0 0 0 82トンネルアシグメント-ID（注5）0 0 83トンネルプレーファレンス（注5）0-1 0 0 85 ACCT-INTERIM-INTERVAL（注3）0-1 0 0 87 NAS-ポートID（注1）0-1 0 0 88フレームプール（注3）0-1 0 0 89課金可能ユーザーアイデンティティ（注1）0 0 0 90トンネルクライアント-Auth-ID（注5）0 0 0 91トンネルサーバー-Auth-ID（注5）0-1 0 0 92 NAS-FILTER-RULE（NOTE 3）0 0 0 94 ORIGINATION-LINE-INFO 0-1 0 0 95 NAS-IPV6-ADDRESS（注1）0-1 0 0 96フレームインタフェイスID（注1、6）0 0 0 97フレーム-IPV6-PREFIX（注1、6）0 0 0 98 LOGIN-IPV6-HOST（注3）00 0 99 framed-ipv6-route（注3）リクエストACK NAK＃属性要求ACK＃属性0-1 0 0 100フレーム-IPV6プール（注3）0 0 0 0 101エラー要件0 0 0 123委任 - IPv6-Prefix（注3）ACK nak＃属性を要求する
Disconnect Messages
メッセージを切断します
Request ACK NAK # Attribute 0-1 0 0 1 User-Name (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 5 NAS-Port (Note 1) 0 0 0 6 Service-Type 0 0 0 8 Framed-IP-Address (Note 1) 0+ 0 0 18 Reply-Message (Note 2) 0 0 0 24 State 0+ 0 0 25 Class (Note 4) 0+ 0 0 26 Vendor-Specific (Note 7) 0-1 0 0 30 Called-Station-Id (Note 1) 0-1 0 0 31 Calling-Station-Id (Note 1) 0-1 0 0 32 NAS-Identifier (Note 1) 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 44 Acct-Session-Id (Note 1) 0-1 0-1 0 49 Acct-Terminate-Cause 0-1 0 0 50 Acct-Multi-Session-Id (Note 1) 0-1 0-1 0-1 55 Event-Timestamp 0 0 0 61 NAS-Port-Type 0+ 0-1 0 79 EAP-Message (Note 2) 0-1 0-1 0-1 80 Message-Authenticator 0-1 0 0 87 NAS-Port-Id (Note 1) 0-1 0 0 89 Chargeable-User-Identity (Note 1) 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0 0 0 96 Framed-Interface-Id (Note 1) 0 0 0 97 Framed-IPv6-Prefix (Note 1) 0 0 0+ 101 Error-Cause Request ACK NAK # Attribute
ACK NAK＃属性0-1 0 0 1ユーザー名（注1）0-1 0 0 4 NAS-IP-Address（注1）0-1 0 0 NAS-PORT（注1）0 0 0 6 6Service-Type 0 0 0 8 Framed-IP-Address（Note 1）0 0 0 18 Reply-Message（Note 2）0 0 24 State 0 0 25クラス（注4）0 0 2 26ベンダー固有（注7）0-1 0 0 30コールステーション-ID（注1）0-1 0 0 31コールシュテーション-ID（注1）0-1 0 32 NAS-IDENTIFIER（NOTE 1）0 0 0 33 Proxy-STATE 0-1 0 0 44 ACCT-SESSION-ID（注1）0-1 0-1 0 49 ACCT-TERMINATE-COUSE 0-1 0 0 50 ACCT-MULTI-SESSION-ID（注1）0-10-1 0-1 55イベント - タメスタンプ0 0 0 61 NAS-PORT-TYPE 0 0-1 0 79 EAP-MESSAGE（注2）0-1 0-1 0-1 80メッセージ-Authenticator 0-1 0 0 087 NAS-PORT-ID（注1）0-1 0 0 89課金可能ユーザーアイデンティティ（注1）0-1 0 0 95 NAS-IPV6-アドレス（注1）0 0 0 96フレームインターフェイス-ID（注1）0 0 0 97フレーム-IPV6-PREFIX（注1）0 0 0 101エラーコースリクエストACK NAK＃属性
The following 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つのインスタンスがパケットに存在する必要があります。
(Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes).
（注1）NASまたはセッション識別属性が切断要件またはCOA-Requestパケットに含まれている場合、識別目的でのみ使用されます。これらの属性は、識別以外の目的に使用してはなりません（たとえば、COA-Requestパケット内で認可の変更を要求するため）。
(Note 2) The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where Extension Authentication Protocol (EAP) is used for authentication, an EAP-Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-Message/Notification-Response Attribute.
（注2）Reply-Message属性は、ユーザーに表示可能なメッセージを提示するために使用されます。このメッセージは、切断リケストまたはCOA-Requestが成功した結果としてのみ表示されます（その後、切断されたcoCACKまたはCOA-ackが送信されます）。拡張認証プロトコル（EAP）が認証に使用される場合、代わりにEAPメッセージ/通知 - レクエスト属性が送信され、切断されたパケットまたはCOA-ackパケットには、EAPメッセージ/通知 - 応答属性が含まれています。
(Note 3) When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing values of the same attribute(s).
（注3）COA-Requestに含まれる場合、これらの属性は認証変更リクエストを表します。これらの属性のいずれかがCOA-Requestから省略されると、NASは属性値が変更されていないと想定しています。COA-Requestに含まれる属性は、同じ属性のすべての既存の値を置き換えます。
(Note 4) When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the NAS to the RADIUS accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed.
（注4）成功した切断リケスト（その後の切断-CACKが送信される場合）に含まれる場合、クラス属性は、NASによって会計STOPパケットのRADIUSアカウンティングサーバーに変更されていないように送信する必要があります。切断リケストが失敗した場合、クラス属性は処理されません。
(Note 5) When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attributes are included within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s).
（注5）COA-Requestに含まれる場合、これらの属性は認証変更リクエストを表します。トンネル属性が成功したCOA-Requestに含まれる場合、既存のトンネル属性はすべて削除され、新しい属性に置き換えられます。
(Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and Framed-Interface-Id attributes are used for session identification, renumbering cannot be accomplished by including values of these attributes within a CoA-Request. Instead, a CoA-Request including a Service-Type Attribute with a value of "Authorize Only" is sent; new values can be supplied in an Access-Accept sent in response to the ensuing Access-Request. Note that renumbering will not be possible in all situations. For example, in order to change an IP address, IPCP or IPv6CP re-negotiation could be required, which is not supported by all PPP implementations.
（注6）フレーム付きIP-Address、Framed-IPv6-Prefix、およびFramed-interface-ID属性はセッション識別に使用されるため、COA-Requestにこれらの属性の値を含めることで変更を達成できません。代わりに、「Authorizeのみ」の値を持つサービスタイプの属性を含むCOA-Requestが送信されます。新しい値は、その後のアクセスリクエストに応じて送信されたアクセスacceptで提供できます。すべての状況では、変更は不可能であることに注意してください。たとえば、IPアドレスを変更するには、すべてのPPP実装ではサポートされていないIPCPまたはIPv6CPの再negotiationが必要になる可能性があります。
(Note 7) Within Disconnect-Request packets, Vendor-Specific Attributes (VSAs) MAY be used for session identification. Within CoA-Request packets, VSAs MAY be used for either session identification or authorization change. However, the same Attribute MUST NOT be used for both purposes simultaneously.
（注7）切断パケット内で、セッション識別にはベンダー固有の属性（VSA）が使用される場合があります。COA-Requestパケット内では、VSAをセッションの識別または承認の変更に使用できます。ただし、同じ属性を両方の目的に同時に使用してはなりません。
Due to differences in handling change-of-authorization requests in RADIUS and Diameter, it may be difficult or impossible for a Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example, since a CoA-Request only initiates an authorization change but does not initiate re-authentication, a RAR command containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be directly translated to a CoA-Request. A Diameter/RADIUS gateway receiving a CoA-Request containing authorization changes will need to translate this into two Diameter exchanges. First, the Diameter/RADIUS gateway will issue a RAR command including a Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing access request with a response including the authorization attributes gleaned from the CoA-Request. To enable translation, the CoA-Request SHOULD include a Acct-Session-Id Attribute. If the Diameter client uses the same Session-Id for both authorization and accounting, then the Diameter/RADIUS gateway can copy the contents of the Acct-Session-Id Attribute into the Session-Id AVP; otherwise, it will need to map the Acct-Session-Id value to an equivalent Session-Id for use within a RAR command.
半径と直径の承認の変化要求の処理の違いにより、直径/半径のゲートウェイが直径の再発行（RAR）をCOA-Requestに正常に変換し、その逆に正常に変換することは困難または不可能である可能性があります。たとえば、COA-Requestは承認の変更のみを開始するが、再認証を開始しないため、値「Authorize_Authenticate」を持つ再発行型AVPを含むRARコマンドをCOA-Requestに直接変換することはできません。認証変更を含むCOA-Requestを受信する直径/半径ゲートウェイは、これを2つの直径交換に変換する必要があります。まず、直径/RADIUSゲートウェイは、セッション-ID AVPおよび値「Authorizeのみ」を備えたReAuth-Request-Type AVPを含むRARコマンドを発行します。次に、直径/RADIUSゲートウェイは、COA-Requestから収集された承認属性を含む応答を含む、次のアクセス要求に応答します。翻訳を有効にするには、COA-RequestにACCT-Session-ID属性を含める必要があります。直径クライアントが認証と会計の両方に同じセッションIDを使用する場合、直径/RADIUSゲートウェイはACCT-Session-ID属性の内容をセッションID AVPにコピーできます。それ以外の場合、RARコマンド内で使用するには、ACCT-Session-ID値を同等のセッションIDにマッピングする必要があります。
Where an Acct-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, a Diameter/RADIUS gateway will either need to determine the appropriate Acct-Session-Id or, if it cannot do so, it can send a CoA-NAK or Disconnect-NAK in reply, possibly including an Error-Cause Attribute with a value of 508 (Multiple Session Selection Unsupported).
COA-Requestまたは切断リケストにACCT-Session-ID属性が存在しない場合、直径/半径のゲートウェイは適切なACCT-Session-IDを決定する必要があります。Coa-nakまたはdisconnect-nakは、おそらく508の値を持つエラー（複数のセッション選択）を含む誤差属性を含めます。
To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request, as described in Section 3.2. A Diameter/RADIUS gateway receiving a CoA-Request containing a Service-Type Attribute with a value "Authorize Only" translates this to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The received RAA is then translated to a CoA-NAK with a Service-Type Attribute with value "Authorize Only". If the Result-Code AVP in the RAA has a value in the success category, then an Error-Cause Attribute with value "Request Initiated" is included in the CoA-NAK. If the Result-Code AVP in the RAA has a value indicating a Protocol Error or a Transient or Permanent Failure, then an alternate Error-Cause Attribute is returned as suggested below.
半径と直径の間の翻訳を簡素化するために、動的認証クライアントは、セクション3.2で説明されているように、COA-Request内で「authorizeのみ」のサービス型属性を含めることができます。値「Authorizeのみ」を持つサービスタイプの属性を含むCOA-Requestを受信する直径/半径ゲートウェイは、値「認証のみ」を持つReAuth-Request-Type AVPを使用してこれをRARに変換します。受信したRAAは、値「Authorizeのみ」を持つサービスタイプの属性を持つCOA-NAKに翻訳されます。RAAの結果コードAVPが成功カテゴリに値を持っている場合、「リクエストが開始された」値「リクエスト」を持つエラー原因属性がCOA-NAKに含まれています。RAAの結果コードAVPに、プロトコルエラーまたは過渡または永続的な障害を示す値がある場合、以下に示唆する代替エラー原因属性が返されます。
Within Diameter, a server can request that a session be aborted by sending an Abort-Session-Request (ASR), identifying the session to be terminated using Session-ID and User-Name AVPs. The ASR command is translated to a Disconnect-Request containing Acct-Session-Id and User-Name attributes. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Session-ID AVP may be placed in the Acct-Session-Id Attribute; otherwise the value of the Session-ID AVP will need to be mapped to an appropriate Acct-Session-Id Attribute. To enable translation of a Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be present.
If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Acct-Session-Id Attribute may be placed into the Session-ID AVP within the ASR; otherwise the value of the Acct-Session-Id Attribute will need to be mapped to an appropriate Session-ID AVP.
直径クライアントが認証と会計の両方で同じセッションIDを使用している場合、ACCT-Session-ID属性の値をASR内のセッションID AVPに配置できます。それ以外の場合、ACCT-Session-ID属性の値を適切なセッションID AVPにマッピングする必要があります。
An Abort-Session-Answer (ASA) command is sent in response to an ASR in order to indicate the disposition of the request. A Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A Disconnect-NAK received from the NAS is translated to an ASA command with a Result-Code AVP that depends on the value of the Error-Cause Attribute. Suggested translations between Error-Cause Attribute values and Result-Code AVP values are included below:
リクエストの処分を示すために、ASRに応答して、中止セッションアンスワー（ASA）コマンドが送信されます。切断される直径/半径ゲートウェイは、「Diameter_success」の結果コードAVPを使用して、これをASAコマンドに変換します。NASから受け取った切断されたNAKは、エラー原因属性の値に依存する結果コードAVPを使用してASAコマンドに翻訳されます。エラー原因属性値と結果コードAVP値の間の推奨される翻訳を以下に示します。
# Error-Cause Attribute Value Result-Code AVP
--- --------------------------- ------------------------
201 Residual Session Context DIAMETER_SUCCESS
Removed
202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
(Ignored)
401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
402 Missing Attribute DIAMETER_MISSING_AVP
403 NAS Identification DIAMETER_REALM_NOT_SERVED
Mismatch
404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE
501 Administratively DIAMETER_AUTHORIZATION_REJECTED
Prohibited
502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER
503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
Removable
505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
Error
506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
507 Request Initiated DIAMETER_SUCCESS
Since both the ASR/ASA and Disconnect-Request/Disconnect-
NAK/Disconnect-ACK exchanges involve just a request and response,
inclusion of an "Authorize Only" Service-Type within a Disconnect-
Request is not needed to assist in Diameter/RADIUS translation, and
may make translation more difficult. As a result, as noted in
Section 3.2, the Service-Type Attribute MUST NOT be used within a
Disconnect-Request.
This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. In addition to the allocations already made in [RFC3575] and [RFC3576], this specification allocates additional values of the Error-Cause Attribute (101):
このドキュメントでは、RADIUS [RFC2865]名前空間を使用しています。<http://www.iana.org/assignments/radius-types>を参照してください。[RFC3575]および[RFC3576]ですでに行われた割り当てに加えて、この仕様には、エラー原因属性（101）の追加値が割り当てられます。
# Value
--- -----
407 Invalid Attribute Value
508 Multiple Session Selection Unsupported
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Requests or CoA-Requests affecting the sessions of another provider.
NASが複数のプロバイダーによって共有されている場合、あるプロバイダーが別のプロバイダーのセッションに影響を与える切断リケストまたはCOA要求を送信できることは望ましくありません。
A Dynamic Authorization Server MUST silently discard Disconnect-Request or CoA-Request packets from untrusted sources. In situations where the Dynamic Authorization Client is co-resident with a RADIUS authentication or accounting server, a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request packets relating to users within a set of realms.
動的な認証サーバーは、信頼できないソースからの切断 - レクエストまたはCOA-Requestパケットを静かに破棄する必要があります。ダイナミック認証クライアントがRADIUS認証または会計サーバーと共同居住している状況では、プロキシは「逆パス転送」（RPF）チェックを実行して、切断リケストまたはCOA-Requestが承認された動的認証に起因することを確認することができます。クライアント。さらに、特定のクラスのセッションに関連するdeconnect-requestまたはCOA-Requestパケットの追加のソースを明示的に許可することが可能です。たとえば、特定のソースは、一連のレルム内のユーザーに関連するCOA-Requestパケットを送信することを明示的に許可できます。
To perform the RPF check, the Dynamic Authorization Server uses the session identification attributes included in Disconnect-Request or CoA-Request packets, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the CoA-Request or Disconnect-Request is forwarded; otherwise it MUST be silently discarded.
RPFチェックを実行するために、Dynamic Authorization Serverは、同等のAccess-RequestをルーティングできるRADIUSサーバーを決定するために、Disconnect-RequestまたはCoA-Requestパケットに含まれるセッション識別属性を使用します。切断リケストまたはCOA-Requestのソースアドレスがこのセット内にある場合、COA-Requestまたは切断リケストが転送されます。それ以外の場合は、静かに廃棄する必要があります。
Typically, the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name or Chargeable-User-Identity Attribute, and determine the corresponding RADIUS servers in the realm routing tables. If the Dynamic Authorization Server maintains long-term session state, it MAY perform the authorization check based on the session identification attributes in the CoA-Request. The session identification attributes can be used to tie a session to a particular proxy or set of proxies, as with the NAI realm.
通常、動的承認サーバーは、ユーザー名または課金型ユーザーアイデンティティ属性内に含まれるネットワークアクセス識別子[RFC4282]から領域を抽出し、レルムルーティングテーブルの対応するRADIUSサーバーを決定します。動的承認サーバーが長期セッション状態を維持している場合、COA-Requestのセッション識別属性に基づいて承認チェックを実行できます。セッション識別属性を使用して、NAI領域と同様に、特定のプロキシまたはプロキシのセットにセッションを結び付けることができます。
Where no proxy is present, the RPF check can only be performed by the NAS if it maintains its own a realm routing table. If the NAS does not maintain a realm routing table (e.g., it selects forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check cannot be performed.
プロキシが存在しない場合、RPFチェックは、独自のAレルムルーティングテーブルを維持している場合にのみ実行できます。NASがレルムルーティングテーブルを維持していない場合（たとえば、プライマリ/セカンダリ構成および/またはlivenivesチェックに基づいてプロキシの転送を選択します）、RPFチェックは実行できません。
Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the Dynamic Authorization Server SHOULD configure a different shared secret for each Dynamic Authorization Client.
disconnect-requestまたはCOA-Requestを送信する許可は、ソースアドレスと対応する共有秘密に基づいて決定されるため、動的認証サーバーは、各動的認証クライアントに異なる共有秘密を構成する必要があります。
In addition to security vulnerabilities unique to Disconnect or CoA packets, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be employed to afford better security, utilizing the profile described in [RFC3579], Section 4.2.
切断またはCOAパケットに固有のセキュリティの脆弱性に加えて、このドキュメントで説明されているプロトコル交換は、半径と同じ脆弱性を受けやすい[RFC2865]。[RFC3579]、セクション4.2に記載されているプロファイルを利用して、より良いセキュリティを提供するためにIPSECを使用することをお勧めします。
For Dynamic Authorization Servers implementing this specification, the IPsec policy would be "Require IPsec, from any to me, destination port UDP 3799". This causes the Dynamic Authorization Server to require use of IPsec. If some Dynamic Authorization Clients do not support IPsec, then a more granular policy will be required: "Require IPsec, from IPsec-Capable-DAC to me".
この仕様を実装する動的な認証サーバーの場合、IPSECポリシーは「IPSECを必要とします。これにより、動的認証サーバーはIPSECの使用を要求します。一部の動的認証クライアントがIPSECをサポートしていない場合、より詳細なポリシーが必要になります。「IPSEC-Capable-DACから私へのIPSECが必要です」。
For Dynamic Authorization Clients implementing this specification, the IPsec policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the Dynamic Authorization Client to initiate IPsec when sending Dynamic Authorization traffic to any Dynamic Authorization Server. If some Dynamic Authorization Servers contacted by the Dynamic Authorization Client do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 3799".
この仕様を実装する動的な認証クライアントの場合、IPSECポリシーは「私から任意の宛先ポートUDP 3799までのIPSECを開始」になります。これにより、動的な認証トラフィックを動的承認トラフィックを送信するときに、動的認証クライアントがIPSECを開始します。動的認証クライアントが連絡したいくつかの動的な認証サーバーがIPSECをサポートしていない場合、「MEからIPSEC-Capable-Das、Destination Port UDP 3799までのIPSECを開始する」など、より詳細なポリシーが必要になります。
Where IPsec replay protection is not used, an Event-Timestamp (55) [RFC2869] Attribute SHOULD be included within CoA-Request and Disconnect-Request packets, and MAY be included within CoA-ACK, CoA-NAK, Disconnect-ACK, and Disconnect-NAK packets.
IPSECリプレイ保護が使用されていない場合、イベントタメスタンプ（55）[RFC2869]属性をCOA-Requestおよび切断リケストパケットに含める必要があり、COA-ack、coa-nak、disconnect-cack、およびNakパケットを切断します。
When the Event-Timestamp Attribute is present, both the Dynamic Authorization Server and the Dynamic Authorization Client MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the packet MUST be silently discarded. This implies the need for loose time synchronization within the network, which can be achieved by a variety of means, including Simple Network Time Protocol (SNTP), as described in [RFC4330]. Implementations SHOULD be configurable to discard CoA-Request or Disconnect-Request packets not containing an Event-Timestamp Attribute.
Event-Timestamp属性が存在する場合、動的承認サーバーと動的認証クライアントの両方が、イベントタンプ属性が許容可能な時間ウィンドウ内で最新であることを確認する必要があります。イベントタイムスタンプ属性が最新のものでない場合、パケットは静かに破棄する必要があります。これは、[RFC4330]で説明されているように、単純なネットワークタイムプロトコル（SNTP）を含むさまざまな手段で達成できるネットワーク内でのゆるい時間同期の必要性を意味します。実装は、イベント - タメスタンプ属性を含まないCOA-Requestまたは切断リケストパケットを破棄するために構成できる必要があります。
If the Event-Timestamp Attribute is included, it represents the time at which the original packet was sent, and therefore it SHOULD NOT be updated when the packet is retransmitted. If the Event-Timestamp Attribute is not updated, this implies that the Identifier is not changed in retransmitted packets. As a result, the ability to detect replay within the time window is dependent on support for duplicate detection within that same window. As noted in Section 2.3, duplicate detection is REQUIRED for Dynamic Authorization Servers implementing this specification.
イベントタイミスタンプ属性が含まれている場合、元のパケットが送信された時間を表します。したがって、パケットが再送信されたときに更新しないでください。Event-Timestamp属性が更新されていない場合、これは、再送信パケットで識別子が変更されないことを意味します。その結果、時間ウィンドウ内でリプレイを検出する機能は、同じウィンドウ内の重複検出のサポートに依存します。セクション2.3で述べたように、この仕様を実装する動的な認証サーバーには重複検出が必要です。
The time window used for duplicate detection MUST be the same as the window used to detect a stale Event-Timestamp Attribute. Since the RADIUS Identifier cannot be repeated within the selected time window, no more than 256 Requests can be accepted within the time window. As a result, the chosen time window will depend on the expected maximum volume of CoA/Disconnect-Requests, so that unnecessary discards can be avoided. A default time window of 300 seconds should be adequate in many circumstances.
重複検出に使用される時間ウィンドウは、古いイベント - タメスタンプ属性を検出するために使用されるウィンドウと同じでなければなりません。選択した時間ウィンドウ内で半径識別子を繰り返すことができないため、時間ウィンドウ内で256回以上のリクエストを受け入れることができません。その結果、選択された時間ウィンドウは、COA/切断要求の予想される最大体積に依存するため、不必要な廃棄を回避できます。多くの状況では、300秒のデフォルトのタイムウィンドウが適切である必要があります。
Disconnect Request with User-Name:
ユーザー名でリクエストを切断します：
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
ACCT-SESSION-IDでリクエストを切断します。
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
framed-ip-addressでリクエストを切断します：
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Rubens、A.、Simpson、W。およびS. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats W. and P. Calhoun、「Radius Extensions」、RFC 2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RadiusのIANAの考慮事項」、RFC 3575、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「拡張可能な認証プロトコル（EAP）の半径サポート」、RFC 3579、2003年9月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin、H。、「最近の攻撃後のMD5のステータス」、Cryptobytes Vol.2 No.2、1996年夏。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。and I. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B。およびJ. Wood、「認証、承認、会計輸送プロファイル」、RFC 3539、2003年6月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D。、およびB. Aboba、「リモート認証のダイヤルインユーザーサービス（RADIUS）へのダイナミック認証拡張」、RFC 3576、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 4330、2006年1月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] Adrangi、F.、Lior、A.、Korhonen、J。and J. Loughney、「chargeable user Identity」、RFC 4372、2006年1月。
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon、P.、Sanchez、M。and B. Aboba、「仮想LANおよび優先サポートの半径属性」、RFC 4675、2006年9月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818] Salowey、J。およびR. Droms、「Radius Delegated-IPv6-Prefix属性」、RFC 4818、2007年4月。
[RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.
[RFC4849] Congdon、P.、Sanchez、M。、およびB. Aboba、「Radius Filter Rule属性」、RFC 4849、2007年4月。
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit.
このプロトコルは、Ascend Communicationsによって最初に開発および配布されました。サンプルコードは、無料のサーバーキットに配布されました。
The authors would like to acknowledge valuable suggestions and feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, Russ Housley, Joe Salowey, Alan DeKok, and David Nelson.
著者は、Avi Lior、Randy Bush、Steve Bellovin、Glen Zorn、Mark Jones、Claudio Lapidus、Anurag Batta、Kuntal Chowdhury、Tim Moore、Russ Housley、Joe Salowey、Alan Dekok、David Nelsonononからの貴重な提案とフィードバックを認めたいと思います。。
This Appendix lists the major changes between [RFC3576] and this document. Minor changes, including style, grammar, spelling, and editorial changes, are not mentioned here.
この付録には、[RFC3576]とこのドキュメントの間の主要な変更がリストされています。ここでは、スタイル、文法、スペル、編集の変更を含む小さな変更は言及されていません。
o The term "Dynamic Authorization Client" is used instead of RADIUS server where it applies to the originator of CoA-Request and Disconnect-Request packets. The term "Dynamic Authorization Server" is used instead of NAS where it applies to the receiver of CoA-Request and Disconnect-Request packets. Definitions of these terms have been added (Section 1.3).
o 「Dynamic Authorizationクライアント」という用語は、COA-Requestおよび切断リケストパケットの発信者に適用されるRADIUSサーバーの代わりに使用されます。「Dynamic Authorization Server」という用語は、COA-Requestおよび切断リケストパケットの受信者に適用されるNASの代わりに使用されます。これらの用語の定義が追加されました（セクション1.3）。
o Added requirement for duplicate detection on the Dynamic Authorization Server (Section 2.3).
o 動的認証サーバーに重複した検出の要件が追加されました（セクション2.3）。
o Clarified expected behavior when session identification attributes match more than one session (Sections 2.3, 3, 3.5, 4).
o セッション識別属性が複数のセッションと一致する場合、予想される動作を明確にしました（セクション2.3、3、3.5、4）。
o Added Chargeable-User-Identity as a session identification attribute. Removed NAS-Port-Type as a session identification attribute (Section 3).
o セッション識別属性として充電可能ユーザーアイデンティティを追加しました。セッション識別属性としてNASポートタイプを削除しました（セクション3）。
o Added recommendation that an Acct-Session-Id or Acct-Multi-Session-Id Attribute be included in an Access-Request (Section 3).
o ACCT-Session-IDまたはACCT-Multi-Session-ID属性をアクセスリケスト（セクション3）に含めることを推奨しました。
o Added discussion of scenarios in which the "Dynamic Authorization Client" and RADIUS server are not co-located (Section 3).
o 「動的な認証クライアント」とRADIUSサーバーが共同住宅されていないシナリオの議論が追加されました（セクション3）。
o Added details relating to handling of the Proxy-State Attribute (Section 3.1).
o プロキシ状態属性の処理に関する詳細を追加しました（セクション3.1）。
o Added clarification that support for a Service-Type Attribute with value "Authorize Only" is optional on both the NAS and Dynamic Authorization Client (Section 3.2). Use of the Service-Type Attribute within a Disconnect-Request is prohibited (Sections 3.2, 3.6).
o NASと動的認証クライアントの両方で、「承認のみ」を持つサービスタイプの属性のサポートがオプションであるという明確化を追加しました（セクション3.2）。切断リケスト内でのサービスタイプの属性の使用は禁止されています（セクション3.2、3.6）。
o Added requirement for inclusion of the State Attribute in CoA-Request packets including a Service-Type Attribute with a value of "Authorize Only" (Section 3.3).
o 「Authorizeのみ」の値を持つサービスタイプの属性を含むCOA-Requestパケットに状態属性を含めるための要件が追加されました（セクション3.3）。
o Added clarification on the calculation of the Message-Authenticator Attribute (Section 3.4).
o Message-Authenticator属性の計算に関する明確化を追加しました（セクション3.4）。
o Additional Error-Cause Attribute values are allocated for Invalid Attribute Value (407) and Multiple Session Selection Identification (508) (Sections 3.5, 4).
o 追加のエラー原因属性値は、無効な属性値（407）および複数のセッション選択識別（508）に割り当てられます（セクション3.5、4）。
o Updated the CoA-Request Attribute Table to include Filter-Rule, Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, and User-Priority attributes (Section 3.6).
o COA-Request属性テーブルを更新して、フィルタールール、委任-IPv6-Prefix、Egress-Vlanid、Ingress-Filters、Egress-Vlan-Name、およびユーザー優先属性を含む（セクション3.6）。
o Added the Chargeable-User-Identity Attribute to both the CoA-Request and Disconnect-Request Attribute table (Section 3.6).
o COA-Requestおよび切断リケスト属性テーブル（セクション3.6）の両方に、充電可能ユーザーアイデンティティ属性を追加しました。
o Use of Vendor-Specific Attributes (VSAs) for session identification and authorization change has been clarified (Section 3.6).
o セッションの識別と承認の変更にベンダー固有の属性（VSA）の使用が明らかにされています（セクション3.6）。
o Added Note 6 on the use of the CoA-Request for renumbering, and Note 7 on the use of Vendor-Specific attributes (Section 3.6).
o NommumberingのCOA-Requestの使用に関する注6、およびベンダー固有の属性の使用に関する注7を追加しました（セクション3.6）。
o Added Diameter Considerations (Section 4).
o 直径の考慮事項を追加しました（セクション4）。
o Event-Timestamp Attribute should not be recalculated on retransmission. The implications for replay and duplicate detection are discussed (Section 6.3).
o Event-Timestamp属性は、再送信時に再計算されるべきではありません。リプレイと重複検出への影響について説明します（セクション6.3）。
o Operation of the Reverse Path Forwarding (RPF) check has been clarified. Use of the RPF check is optional rather than recommended by default (Section 6.1).
o 逆パス転送（RPF）チェックの操作が明確になりました。RPFチェックの使用は、デフォルトで推奨されるのではなく、オプションです（セクション6.1）。
o Text on impersonation (included in [RFC3579], Section 4.3.7) and IPsec operation (included in [RFC3579], Section 4.2) has been removed, and is now referenced.
o なりすましに関するテキスト（[RFC3579]、セクション4.3.7に含まれる）およびIPSEC操作（[RFC3579]、セクション4.2に含まれる）が削除され、現在参照されています。
Authors' Addresses
著者のアドレス
Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134
Murtaza Chiba Cisco Systems、Inc。170 West Tasman Dr. San Jose CA、95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
Gopal Dommety Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
Mark Eklund Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton RSA, Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730
David Mitton RSA、EMC 174 Middlesex Turnpike Bedford、MA 01730のセキュリティ部門
EMail: david@mitton.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。