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)
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プロトコルは、ネットワーク・アクセス・サーバ（NAS）にRADIUSサーバから送信される迷惑メールをサポートしていません。
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のリクエストの既存の実装では、影響を受けたセッションを識別、並びに許可の変更を供給する。 CoAのリクエストの既存の実装内に含まれる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.
問題は、サーバ起動許可の変更がユーザ名とセッションId属性値ペア（AVPの）を介してセッションを識別する再認証リクエスト（RAR）コマンドを使用して開始されたDiameterプロトコル[RFC3588]内に存在しませんそして「AUTHORIZE_ONLY」値で再認証リクエスト型AVPを含みます。これは、許可の変更が供給されている標準的な要求/応答シーケンスの開始になります。その結果、コマンドなしで直径の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
ダイナミックな承認クライアント（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.
ダイナミックな承認サーバー（DAS）のCoA-要求または外し-Requestパケットを受信エンティティ。 DASは、NASまたはRADIUSプロキシかもしれません。
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上のユーザセッション（複数可）を終了し、すべての関連するセッションコンテキストを破棄するために、動的認可クライアントによって送信されます。切断要求パケットは、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ができなかった場合、NASは、すべての関連するセッションコンテキストは破棄されず、ユーザセッション（複数可）は、もはや接続されている場合外し-ACKと動的認可クライアントによって送信された切断要求パケットに応答、または切断、NAK 1つ以上のセッションを切断し、すべての関連するセッションコンテキストを破棄します。切断-ACKは、管理・リセットのために6に設定された値とACCT-終了原因（49）項目[RFC2866]を含むかもしれません。
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ポートに記載されているように使用され（セクション2.3を参照）のパケットフォーマットは切断要求パケットのためのものと同じである属性。
The following attributes MAY be sent in a CoA-Request:
以下の属性は、CoAのリクエストで送信することができます。
Filter-ID (11) - Indicates the name of a data filter list to be applied for the session(s) that the identification attributes map to.
フィルタ-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-フィルタルール（92） - 識別は[RFC4849]にマップする属性ことセッション（S）のために適用するフィルタのリストを提供します。
+----------+ +----------+
| | 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要求が失敗した場合、正常ユーザセッション（複数可）、またはアシルCoA-NAKの権限を変更することができる場合のCoA-ACKとダイナミックな承認クライアントによって送信されたCoAのリクエストに応答します。 NASは、アシルCoA-NAKでサポートされていない値を持つservice-type属性を含むアシルCoA-要求に応答しなければなりません。値「サポートされていないサービス」とのエラー原因の属性が含まれるべきです。
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.
切断リクエスト又はアシルCoA-RequestパケットのUDPポート3799のいずれかの宛先ポートとして使用されます。応答のために、送信元と宛先ポートが逆になっています。正確に1つのRADIUSパケットがUDPデータフィールドにカプセル化されます。
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].
パケットフォーマットは、以下のフィールドから構成されていますコード、識別子、長さ、認証、およびType-Length-Value（TLV）の形式の属性。すべてのフィールドはRADIUS [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]
40 - 切断 - 要求[RFC3575] 41 - ディス-ACK [RFC3575] 42 - 切断 - NAK [RFC3575] 43 - アシルCoAリクエスト[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.
外しリクエストと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に直接送信された場合のCoA-要求または切断リクエストパケットはセッションが存在する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.
認証フィールドは、16（16）オクテットです。最も重要なオクテットが最初に送信されます。この値は、ダイナミックな承認クライアントおよびダイナミックな承認サーバー間でパケットを認証するために使用されます。
Request 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].
要求パケットで、認証値は、要求認証と呼ばれ、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のリクエストや、COA要求または切断し、要求にはユーザーパスワード属性が存在しないので、外し-要求は、RADIUSアクセス要求の要求認証と同じように計算することができないの要求認証ことに注意してください。
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.
Responseパケット（例えば、外し-ACK、外し-NAK、アシルCoA-ACK、またはアシルCoA-NAK）における認証フィールドはレスポンス認証と呼ばれ、から成る八重奏のストリームに関して計算一方向MD5ハッシュが含まれていますコード、識別子、長さ、要求認証フィールドに回答されたパケットから、そしてもしあれば応答は、共有秘密が続く、属性。得られた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
管理注：[RFC2865]で述べたように、第3、秘密（動的認可クライアントおよび動的認証サーバ間で共有されるパスワード）が適切に選択されたパスワードと少なくとも同じ大きさと推測できないであるべきです。ダイナミックな承認
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.
リクエストをプロキシすることができるように、サーバーは、使用する秘密を共有したかを決定するために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のリクエストおよび切断要求パケットでは、すべての属性が必須のものとして扱われなければなりません。 CoAのリクエストで指定された一つ以上の許可の変更を行うことができない場合、NASは、アシルCoA-NAKを送らなければなりません。 NASは、一つ以上のサポートされていないのCoA-NAKを持つ属性または属性値を含むアシルCoA-要求に応答しなければなりません。値401（サポートされていない項目）または407（無効属性値）でのエラー原因の項目を含んでいてもよいです。 NASは外し-NAKを有する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のリクエストから生じた状態の変化は、原子でなければならない：CoAのリクエストが一致するすべてのセッションのために成功した場合、NASは、返信でのCoA-ACKを送らなければなりませんし、すべての要求された許可の変更がなされなければなりません。 CoAのリクエストは、一致するセッションのために失敗した場合、NASは、応答でのCoA-NAKを送らなければなりませんし、要求された許可の変更は、マッチングセッションのいずれかのために作られてはなりません。同様に、状態変化は、マッチングセッションのいずれかに対して失敗した切断リクエストの結果として発生してはいけません。マッチングセッションのいずれかが正常に終了することができない場合、NASは、返信に外し-NAKを送らなければなりません。アシルCoA-NAKを送信したり、外し-NAKを返信にしなければならない複数のセッションに適用される動的な許可の変更をサポートしていないNAS。値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パケット内でその属性を含めることをサポートしていない可能性があります。これはあっても、[RFC2868]、[RFC2869]、[RFC3162]、[RFC3579]、[RFC4372]、[RFC4675]、[RFC4818例えば[RFC2865]内で定義されたもののような接続許可パケット（内許容ように指定された属性についても同様です]、および[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.
切断リクエストとCoA-Requestパケットでは、特定の属性が一意にNAS上のユーザセッション（複数可）、ならびにNASを識別するために使用されます。 CoAのリクエストまたは切断要求パケットに含まれるNASおよびセッション識別属性の組み合わせが成功する要求のために、少なくとも一つのセッションと一致しなければなりません。そうでない場合は外し-NAKまたはCoAの-NAKを送らなければなりません。すべてのNAS識別が一致する属性、および複数のセッションは、セッション識別属性の全てに一致その後のCoA - 要求または切断 - 要求をした場合、一致するすべてのセッションに適用しなければなりません。
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.
ACCT-マルチセッションID 50 [RFC2866]一意に関連するセッションを識別する識別子。セッションは、ポートを識別するNAS-ポートID 87 [RFC2869]列。有料-USER- 89 [RFC4372] 1人のアイデンティティ以上のセッションに関連付けられているCUI。プライバシーネットワークアクセス識別子（NAI）は、ユーザ名（例えば、「匿名」）指定されたユーザに属するセッションを識別しない場合があり、この場合のため、使用される必要がありました。フレーミング・インターフェイスID 96常に入り-のIPv6プレフィクスと一緒に送信セッションに関連付けられた[RFC3162] IPv6インタフェース識別子。フレームを選ぶ-のIPv6プレフィックス97 [RFC3162]セッションに関連付けられているIPv6プレフィックスは、常にフレームを選ぶ-インターフェイス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.
Diameterクライアントが同じセッションId許可およびアカウンティングの両方のために利用する場合直径RARおよびASRコマンドが含まれているため、接続解除 - 要求またはCoAのリクエストでのAcct-セッションID属性を含めることは、直径/ RADIUS翻訳を支援することができますセッションID AVP。アカウンティング・セッション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-セッションIdまたはのAcct-Multi-Session-Id属性を送るべきです。アカウンティング・セッションIdまたはのAcct-Multi-Session-Id属性がアクセス要求の中に含まれていない場合は、ダイナミックな承認クライアントがセッションのアカウンティング・セッション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.
アカウンティング・セッションIdまたはのAcct-Multi-Session-Id属性は、CoAのリクエストに存在しないか、外し-Requestをどこで、ユーザー名または有料-ユーザ識別属性を一意に十分ではない可能性があります（同じユーザーがNAS上の複数のセッションを持っている場合、またはプライバシーNAIが使用されている場合、例えば）単一のセッションを識別します。それは、単一のセッションを識別することが望まれる場合には、この場合には、セッション識別を入れるとIPアドレスの一つ以上、入れる-のIPv6プレフィックス/入れる-interface-idに、着信ステーション-IDを使用して行われてもよいです、呼び出し-駅-ID、NAS-ポート、およびNAS-ポート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アドレスまたはNAS-のIPv6アドレスの複数の属性は、CoAをリクエストおよび切断リクエストパケットの中に存在すべきです。 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とのセッション識別属性を含まなければなりません。他の属性を外し、要求に含まれている場合、実装は外し-NAKを送らなければなりません。値「サポートされていない属性」とのエラー原因の属性が含まれるかもしれません。
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で説明したように、例えば、「のみ承認」の値とサービスタイプ属性を含むのCoA-Requestパケットは、状態属性を含むことが要求されます。 NASは、その後、アクセス要求にRADIUSサーバへこの属性を送信します。 RADIUSサーバは、その後受け入れることを属性DACは、国家を含めるようにするためには、両者の間にいくつかの調整が必要になることがあります。
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を送るべきか、外し-Requestパケットを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 - 要求又は切断要求パケットを受信したRADIUSサーバは、パケットを転送する前に、（例えば、NASの追加やセッション識別属性または状態属性を付加するように）属性。 RADIUSサーバによって転送されるアシルCoA /切断 - 要求を持つことも、Reverse Path Forwarding（RPF）チェック（6.1節を参照）を実行するために、上流RADIUSプロキシを有効にすることができます。
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.
すべてのプロキシ・ステートは外しリクエストの属性やCoAのリクエストは、ダイナミックな承認クライアントから受信がある場合は、ダイナミックな承認サーバーは、これらのプロキシ状態がダイナミックな承認クライアントへの応答の属性を含まなければなりません。
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を転送するとき、それはプロキシ状態属性を追加するかもしれないが、それ以上のものを追加してはなりません。パケットを転送する際にプロキシ状態属性がパケットに付加されている場合は、既存のプロキシ状態属性の後に、プロキシ状態属性を追加する必要があります。転送プロキシはプロキシ状態を含む同じタイプのすべての属性の順序を変更しないでください。他の属性は、プロキシの状態属性の後に、あるいは間、前に配置することができます。
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要求または切断し、要求に対する応答を受信すると、応答を転送する前に、（パケットの最後のプロキシ州）独自のプロキシ状態属性を削除する必要があります。切断と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.
RADIUSと直径との間の変換を簡素化するために、ダイナミックな承認クライアントがCoAをリクエスト内「のみ認可」の値を持つservice-type属性を含めることができます。直径の考慮事項の詳細については、セクション4を参照してください。値のservice-type属性を含むCoAのリクエストのためのサポート「のみの認可」NASとダイナミックな承認クライアントではオプションです。 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を持つ値でservice-type属性「のみの認可」を含むアシルCoA-要求に応答しなければなりません。アシル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.
値のservice-type属性を含むアシルCoA-要求はほかにMUSTは唯一の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.
「唯一の認可」のサービスタイプ値を含むのCoA-Requestパケットが正常に処理されている場合は、NASは、アシルCoA-NAKは「オーサライズ時のみ」の値を持つservice-type属性を含むで応じなければなりませんし、エラー-原因と属性値507（要求開始）。 NASは、国家の属性とともに、値「のみ認可」とservice-type属性を含むRADIUSサーバへのアクセス要求を送らなければなりません。このアクセス要求はNASの識別のCoA-要求から属性、ならびにセッション識別は、アクセス要求に許可のCoA-要求から属性を含むべきです。それはまた、アクセス要求で許可他の属性を含むかもしれません。
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に述べたように、Message-Authenticatorアトリビュートは、ユーザーパスワード、CHAP-パスワード、ARAP - パスワード、またはEAP-メッセージ属性が含まれていないアクセス要求に含まれるべきです。 RADIUSサーバは、アクセス・受け入れ（再）セッションまたはアクセス拒否（再）、それを承認することを拒否することを承認するとアクセス要求に応答します。
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.
アクセス要求は、ユーザーのパスワードやCHAP - パスワードまたは状態のいずれかを含まなければなりません。アクセス要求は、ユーザーのパスワードやCHAP-パスワードの両方を含めることはできません。将来の拡張には、認証情報の他の種類を伝えることができるようにする場合は、そのための属性がアクセス要求の代わりに、ユーザーのパスワードやCHAP - パスワードに使用することができます。
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、値のservice-type属性とアクセス要求は、State属性を含まなければならない「のみ認可」。
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にState属性を提供するために、サービスタイプとのCoA-Requestを送信するダイナミックな承認クライアントは、State属性を含まなければならない、とNASはに変更されていない属性の状態を送らなければなりません「のみ認可」の値を持つ属性結果としてアクセス要求内のRADIUSサーバがあれば。 NASは「唯一認可」の値でservice-type属性を含むアシルCoA-Requestを受信したが、アシルCoA-NAKを送らなければなりません状態属性を欠いていると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.
状態属性はまたRADIUSリクエストの値と属性終了-アクションを含んでいるのCoA-RequestにNASへのダイナミックな承認クライアントによって送信できます。 NASは、現在のセッションの終了時に、新たなアクセス要求を送信することにより終了アクションを実行する場合、それは国家がそのアクセス要求に変わらない属性を含まなければなりません。いずれかの使用法では、ダイナミックな承認サーバーは、ローカルに属性を解釈してはいけません。 CoA-RequestパケットのState Attributeは0か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.
Message-Authenticatorアトリビュートを認証するために使用されるとCoA-Requestを整合性保護されるかもしれない、なりすましを防止するために、アシルCoA-ACK、アシルCoA-NAK、切り離しリクエスト、外し-ACK、および接続解除-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.
メッセージ認証でのCoA-要求または接続解除-Requestを受信したダイナミックな承認サーバーは、現在の属性メッセージ認証の正しい値を計算し、静かにそれが送信された値と一致しない場合、パケットを捨てなければなりません。メッセージオーセンティケータとのCoA /切断-ACK又はアシルCoA /切断-NAKを受信した動的認可クライアントは、本項目メッセージ認証の正しい値を計算し、静かにそれが送信された値と一致しない場合、パケットを破棄しなければなりません。
When a Message-Authenticator Attribute is included within a CoA-Request or Disconnect-Request, it is calculated as follows:
Message-AuthenticatorアトリビュートはCoAのリクエストまたは接続解除 - 要求の中に含まれている場合は、次のように計算されます。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
メッセージ認証= 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メッセージ整合性チェックが算出されると要求認証フィールドとMessage-Authenticatorアトリビュートは、それぞれがゼロの16個のオクテットであることを考えなければなりません。 Message-Authenticatorアトリビュートを計算し、要求認証が計算される前に、パケットに挿入されています。
When a Message-Authenticator Attribute is included within a CoA-ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated as follows:
メッセージ認証属性がアシルCoA-ACK、アシルCoA-NAK、切断-ACK、または切断-NAK内に含まれる場合、次のように計算されます。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
メッセージ認証= 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メッセージ整合性チェックが算出されると、Message-Authenticatorアトリビュートはゼロの16個のオクテットであることを考えなければなりません。要求認証は、対応するアシルCoA /切断リクエストから取られます。レスポンス認証が計算される前に、メッセージ認証が計算され、パケット内に挿入されています。
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と切り離し-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
６
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:
Valueフィールドは、エラーの原因を指定する整数を含む、4つのオクテットです。値0〜199と300〜399は予約されています。これらの値は唯一のCoA-ACKまたは切断-ACKをパケット内で送信されてもよいとCoA-NAKまたは切断-NAKパケット内で送信されてはならないことに200-299は、正常終了を表す値。値400-499は、それらがアシルCoA-NAKまたは外し-NAKパケット内で送信することができるように、ダイナミックな承認クライアントが犯した致命的なエラーを表し、とCoA-ACKまたは外し-ACKパケットの中に送ってはいけません。値500-599は、それらがアシルCoA-NAKと外し-NAKパケット内で送信することができるように、致命的なエラーが、ダイナミックな承認サーバー上で発生表し、とCoA-ACKまたは外し-ACKパケットの中に送ってはいけません。エラー原因値は、ダイナミックな承認クライアントでログインする必要があります。 （10進数で表される）エラーコード値は、次のとおり
# 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つ以上のユーザセッションは、もはや有効であれば外しリクエストに応答して送信されていないが、残留セッションのコンテキストが見つかり、正常に削除されました。この値は、接続解除-ACK内で送信されるとCoA-ACK、外し-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識別ミスマッチ」は、一つ以上の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.
「無効な要求」は、（例えば、EAP-メッセージ属性（複数可）のような）1つ以上の属性が正しくフォーマットされていない場合など、要求のいくつかの他の態様は、無効である場合に送信される致命的なエラーです。
"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.
「サポートされていないサービスは、」要求が無効またはサポートされていない値で送信されてservice-type属性が含まれている場合送信され、致命的なエラーです。このエラーは、切り離しリクエストに応答して送信することはできません。
"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のパケットなどの拡張のためのサポートの欠如に起因して送信された致命的なエラーです。これは、通常のCoA-要求またはNASに接続解除-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のリクエストや取り外し、要求がサポートされていない値を持つ属性が含まれている場合に送信され、致命的なエラーです。
"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.
「管理上禁止」NASは、指定されたセッションのためのCoA-要求または外し-Requestパケットの礼拝を禁止するように設定されている場合送信され、致命的なエラーです。
"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.
「セッション・コンテキストが見つかりません」のCoA-要求または接続解除リクエストで識別されるセッションコンテキストは、NAS上に存在しない場合は送信された致命的なエラーです。
"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は、セッションコンテキストを見つけることができた場合は外し、要求に応じて送信され、致命的なエラーですが、いくつかの理由のためにそれを削除することができませんでした。それだけ外し-NAKの中に、アシルCoA-ACK、アシルCoA-NAK、または外し-ACK以内に送ってはいけません。
"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.).
「リソース使用不可」のCoAまたは外し-Requestが、利用可能なNASリソース（メモリ、不揮発性ストレージなど）の不足に光栄することができなかったときに送信さ致命的なエラーです。
"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.
「開始された要求は、」「のみ認可」の値を持つservice-type属性を含むCoAをリクエストに応じて、NASによって送られた致命的なエラーです。これは、アシルCoA-Requestが表彰されていないことを示しますが、NASは、1つまたは複数の値を持つservice-type属性を含むRADIUSアクセス要求を送信していることをRADIUSサーバに「のみ認可します」。
"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のリクエストまたはそのセッション識別属性はNASが複数のセッションに適用する要求をサポートしていない複数のセッションを、一致外し、リクエストに応じて、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
要求ACK NAKの＃属性0-1 0 0 1ユーザ名0-1 0 0 4 NAS-IP-アドレス0-1 0 0 5 NAS-ポート（注1）（注1）（注1）0-1 0 （注3）0-1 0 0 8入れる-IPアドレス（注1、6）0-1 0 0 9入れる-IP-ネットマスク（注-プロトコル入れる0-1 6サービスタイプ0-1 0 0 7 3）0-1 0 0 10入れるルーティング（注3）0+ 0 0 11フィルタ-ID（注3）0-1 0 0 12入れる-MTU（注3）0+ 0 0 13入れる圧縮（注3）0+ 0 0 14ログイン-IP-ホスト（注3）0-1 0 0 15ログイン・サービス（注3）0-1 0 0 16ログイン-TCPポート（注3）0+ 0 0 18返信-message 0-1 0 0 19コールバック・ナンバー0-1 0 0 20コールバック-ID（注3）（注2）0+ 0 0 22入れる-ルート（注3）（注3）0-1 0 0 23 -IPX-ネットワーク入れる0-1 0-1 0-1 24の状態0+ 0 0 25クラス（注3）0+ 0 0 26ベンダー固有（注7）（注3）0-1 0 0 27セッション - タイムアウト0-1 0 0 28アイドルタイムアウト（注3）0-1 0 0 29終了アクション（注3）要求ACK NAK番号属性（注3）
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
要求ACK NAK位項目0-1 0 0 30着信ステーション-ID 0-1 0 0 31発呼ステーション-ID 0-1 0 0 32 NAS-識別子（注1）（注1）（注1）0+ 0+ 0+ 33プロキシステート0-1 0 0 34ログイン-LAT-サービス（注3）0-1 0 0 35ログイン-LATノード（注3）0-1 0 0 36ログイン-LAT-グループ（注3）0-1 0 0 37入れる-のAppleTalkリンク（注3）0+ 0 0 38入れる-のAppleTalk-ネットワーク（注3）0-1 0 0 39入れる-のAppleTalkゾーン（注3）0-1 0 0 44アカウンティング・セッションId 0-1 0 0 50 ACCT-マルチセッションId（注1）0-1 0-1 0-1 55イベントタイムスタンプ0+ 0 0 56出口-VLANID（注1） 0-1 0 0 57イングレス・フィルタ0+ 0 0 58出口-VLAN名0-1 0 0 59ユーザプライオリティテーブル（注3）（注3）（注3）（注3）0-1 0 0 61 NASポート型0-1 0 0 62ポートリミット（注3）0-1 0 0 63ログイン-LATポート0+ 0 0 64トンネル型（注3）（注3）（注5 ）0+ 0 0 65トンネルメディアタイプ（注5）0+ 0 0 66トンネルクライアントエンドポイント（注5）0+ 0 0 67トンネル - サーバー - エンドポイント（注5）0+ 0 0 69 Tunnel-パスワード（注5）0-1 0 0 71 ARAP-機能（注3）0-1 0 0 72 ARAP-ゾーンのAc目的税（注3）0+ 0 0 78の構成トークン（注3）0+ 0-1 0 79 EAP-メッセージ（注2）0-1 0-1 0-1 80メッセージ認証0+ 0 0 81トンネル-privateグループID 0+ 0 0 82トンネル割り当て-ID（注5）0+ 0 0 83トンネル好ましい0-1 0 0 85 ACCT-中間間隔（注5）（注5）（注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トンネル-client-AUTH-ID（注5）0+ 0 0 91トンネルサーバー-AUTH-ID（注5）0-1 0 0 92 NAS-FILTER-規則（注3）0 0 0 94発信ライン情報0-1 0 0 95 NAS-のIPv6アドレス（注1）0-1 0 0 96入れる-インタフェース-ID（注1、6）0+ 0 0 97入れる-のIPv6プレフィックス（注1、6）0+ 0 0 98ログイン・IPv6にホスト（注3）0+ 0 0 99入れる-のIPv6ルート要求ACK NAK番号属性（注3）
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 100入れる-IPv6のプール（注3）0 0 0 + 101、エラー原因0+ 0 123委任-のIPv6プレフィクスは、要求ACK NAK番号属性（注3）
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ユーザ名0-1 0 0 4 NAS-IP-アドレス0-1 0 0 5 NAS-ポート（注1）（注1）（注1）0 0 0 6サービスタイプ0 0 0 8入れるIPアドレスの0 + 0 18返信メッセージ（注1）0 0 24状態0+ 0 0 25クラス（注2）（注4）0+ 0 0 26ベンダー特定（注7） - 駅-IDと呼ばれる0-1 0 0 30（注1）（注1）0-1 0 0 32 NAS-識別子（注1） - 駅-ID呼び出し0-1 0 0 31 0+ 0+ 0+ 33プロキシステート0-1 0 0 44アカウンティング・セッションId（注1）0-1 0-1 0 49 ACCT-終了原因0-1 0 0 50 ACCT-マルチセッションID（注1）0-1 0-1 0-1 55イベントタイムスタンプ0 0 61 NASポート型0+ 0-1 0 79 EAP-メッセージ（注2）0-1 0-1 0-1 80メッセージ-Authenticator 0-1 0 0 87 NAS-ポートID（注1）0-1 0 0 89有償-ユーザ識別0-1 0 0 95 NAS-IPv6にアドレス（注1）（注1）0 0 0 96入れる-インタフェース-ID（注1）0 0 97入れる-のIPv6プレフィックス（注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).
NAS又はセッション識別属性が切断リクエスト又はアシルCoA-Requestパケットに含まれている（注1）は、それらが識別目的でのみ使用されています。これらの属性は、（例えば、アシル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）。メッセージのみ成功切断リクエストまたは（切断-ACK又はアシルCoA-ACKがその後送信される）のCoA-要求の結果として表示されます。拡張認証プロトコル（EAP）の認証に使用される場合、EAP-メッセージ/通知 - 要求属性が代わりに送信され、そして切断-ACK又はアシル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 - 要求内に含まれる場合、これらの属性は、承認変更要求を表します。これらの属性のいずれかがCoAをリクエストから省略された場合、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）（切断-ACKがその後送信される）成功切断 - 要求内に含まれる場合、クラス属性は会計停止パケットにRADIUSアカウンティングサーバにNASによって修飾されていない送信されるべきです。外しリクエストが失敗した場合には、クラス属性は処理されません。
(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 - 要求内に含まれる場合、これらの属性は、承認変更要求を表します。トンネル属性が成功したCoAのリクエストに含まれている場合、すべての既存のトンネル属性が削除され、新しい属性（複数可）に置き換えられます。
(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.
入れる-IPアドレス、入れる-のIPv6プレフィックス、及び入れる-インタフェース-ID属性はセッション識別のために使用されているので（注6）、リナンバリングはCoAをリクエスト内のこれらの属性の値を含むことによって達成することができません。代わりに、「唯一の認可」の値を持つservice-type属性を含むアシルCoA-Requestが送信されます。新しい値は、アクセス・受け入れその後のアクセス要求に応答して送信して供給することができます。リナンバリングは、すべての状況で可能ではないことに注意してください。たとえば、IPアドレスを変更するために、IPCPまたはIPV6CP再交渉は、すべてのPPPの実装によってサポートされていない、要求される可能性があります。
(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.
RADIUSおよび径の変化-の承認要求を処理の違いによる、それは成功したのCoA-要求とその逆に直径再認証リクエスト（RAR）を変換するための直径/ RADIUSゲートウェイのために困難または不可能であろう。 CoAのリクエストのみ承認の変更を開始しますが、再認証を開始しませんので、例えば、値「AUTHORIZE_AUTHENTICATE」で再認証リクエスト型AVPを含むRARコマンドが直接のCoA-要求に変換することはできません。許可の変更を含むのCoA-Requestを受信した直径/ RADIUSゲートウェイは、二つの直径交換にこれを変換する必要があります。まず、直径/ RADIUSゲートウェイは、「ONLY AUTHORIZE」値でセッションId AVPと再認証リクエスト型AVPを含むRARコマンドを発行します。その後、直径/ RADIUSゲートウェイは、COA要求から収集の許可属性を含む応答とその後のアクセス要求に応答します。翻訳を有効にするには、CoAのリクエストは、アカウンティング・セッションID属性を含めるべきです。 Diameterクライアントは、許可およびアカウンティングの両方に同じセッションIDを使用している場合、直径/ RADIUSゲートウェイは、セッションId AVPへのAcct-セッションID属性の内容をコピーすることができます。それ以外の場合は、RARコマンド内で使用するための同等のセッション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).
アカウンティング・セッションId属性は、COA要求または接続解除 - 要求に存在しない場合には、直径/ RADIUSゲートウェイは、適切なアカウンティング・セッションIdを決定する必要がありますいずれか、または、それがそうすることができない場合は、それが送ることができます返信でのCoA-NAKまたは切断-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.
RADIUSと直径との間の変換を簡素化するために、ダイナミックな承認のクライアントは、3.2節で説明したように、CoAをリクエスト内「のみ認可」の値を持つservice-type属性を含めることができます。サービスタイプは、値「ONLY AUTHORIZE」値を用いて再認証リクエストタイプAVPとRARにこれを変換する「のみ認可」と属性を含むのCoA-Requestを受信した直径/ RADIUSゲートウェイ。受信RAAは、「唯一の認可」の値を持つservice-type属性での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.
径内、サーバは、セッションは、アボート・セッション要求（ASR）を送信するセッションID及びユーザ名AVPを使用して終了するセッションを識別することによって中止されることを要求することができます。 ASRコマンドは、アカウンティング・セッションIdと属性ユーザー名を含む外し、リクエストに変換されます。 Diameterクライアントが同じセッションId許可およびアカウンティングの両方でを利用した場合、セッションID AVPの値は、アカウンティング・セッションId属性に配置することができます。それ以外の場合はセッションID AVPの値は、適切なアカウンティング・セッションID属性にマッピングする必要があります。 ASRに外しリクエストの翻訳を有効にするには、アカウンティング・セッションId属性が存在しなければなりません。
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.
Diameterクライアントが同じセッションId許可およびアカウンティングの両方でを利用している場合、アカウンティング・セッションID属性の値は、ASRの中にセッションID AVPの中に配置することができます。そうでない場合はアカウンティング・セッション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:
アボート・セッション応答（ASA）コマンドは、リクエストの配置を示すために、ASRに応答して送信されます。切断-ACKを受信した直径/ RADIUSゲートウェイは「DIAMETER_SUCCESS」の結果、コードAVPとASAコマンドにこれを変換します。外し-NAKがNASから受信した結果、コード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.
ASR / ASAおよび切断リクエスト双方/切断-NAK /切断-ACK交換は、単に要求および応答を含むため、切断リクエスト内の「のみ認可」サービスタイプを含めることは、直径/半径を支援するために必要とされません翻訳、翻訳をより困難にすることがあります。 3.2節で述べたようにその結果、service-type属性を外し、リクエストの中に使用してはいけません。
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は、複数のプロバイダによって共有されている場合は1つのプロバイダを外し、要求や別のプロバイダのセッションに影響を与えるの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のリクエストが認可ダイナミックな承認に由来することを確認するためにチェックを実行してもよい（MAY）クライアント。また、明示的に切断し、リクエストまたはセッションの特定のクラスに関係の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チェックを実行するために、動的認可サーバは、同等のアクセス要求をルーティングすることができるためにRADIUSサーバ（複数可）を決定するために、切断リクエスト又はアシルCoA-Requestパケットに含まれるセッション識別属性を使用します。切断リクエストまたはCoAをリクエストの送信元アドレスがこのセット内にある場合、その後のCoA - 要求又は切断リクエストが転送されます。それ以外の場合は静かに捨てなければなりません。
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サーバを決定します。ダイナミックな承認Serverは、長期的なセッション状態を維持した場合、それはCoAのリクエストでセッション識別属性に基づいて承認チェックを実行してもよいです。セッション識別属性は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チェックは、NASによって行うことができます。 NASはレルムルーティングテーブルを維持しない場合（例えば、それはプライマリ/セカンダリ構成および/または生存性チェックに基づいてプロキシを転送する選択）、その後、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.
外しリクエストまたはアシル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をパケットに加えて、本文書に記載のプロトコル交換はRADIUS [RFC2865]と同じ脆弱性の影響を受けやすいです。なお、IPsecは、[RFC3579]に記載されたプロファイル、セクション4.2を利用して、より高いセキュリティを得るために使用することが推奨されます。
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ポリシーは、「宛先ポートUDP 3799、いずれかからの私には、IPsecを要求する」だろう。これは、IPsecの使用を必要とするようにダイナミックな承認サーバーが発生します。いくつかのダイナミックな承認のクライアントがIPsecをサポートしていない場合は、よりきめ細かいポリシーが必要になります：「IPsecの対応-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をサポートしていない場合は、よりきめ細かいポリシーは、「私からのIPsec対応-DAS、宛先ポート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のリクエストおよび切断要求パケット内に含まれるべきである、とCoA-ACK内に含まれてもよい、アシルCoA-NAK、切断-ACK、及び外し-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.
イベント・タイムスタンプ属性が存在する場合、ダイナミックな承認サーバーとダイナミックな承認クライアントの両方がイベントタイムスタンプ属性が許容時間ウィンドウ内の現在であることをチェックしなければなりません。イベント・タイムスタンプ属性が最新でない場合、パケットは黙って捨てなければなりません。これは、[RFC4330]に記載されているように、簡易ネットワークタイムプロトコル（SNTP）を含む種々の手段によって達成することができるネットワーク内の緩い時間同期の必要性を暗示します。実装は、CoAのリクエストやイベントタイムスタンプ属性を含まない外し-Requestパケットを破棄するように設定すべきである（SHOULD）。
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.
イベント・タイムスタンプ属性が含まれている場合は、元のパケットが送信された時間を表しており、パケットが再送されたときに、したがって、それは更新しません。イベント・タイムスタンプ属性が更新されていない場合、これは識別子が再送パケットで変更されていないことを意味します。その結果、時間ウィンドウ内でリプレイを検出する能力は、同じウィンドウ内の重複を検出するための支援に依存しています。 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.
重複検出のために使用される時間窓は、古いイベント・タイムスタンプ属性を検出するために使用されるウィンドウと同じでなければなりません。 RADIUS識別子は、選択された時間ウィンドウ内で繰り返すことができないので、せいぜい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
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:
アカウンティング・セッション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
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:
フレームを選ぶ-IP-アドレスで接続解除要求：
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
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ルーベンス、A.、シンプソン、W.とS. Willens、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats W.およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.およびD.ミットン、 "RADIUSと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.カルフーン、 "拡張認証プロトコルのためのRADIUSサポート（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第2巻第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]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.及びI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B.、およびJ.ウッド、 "認証、認可およびアカウンティング交通プロファイル"、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]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.とB. Aboba、RFC 3576、2003年7月 "ダイナミックな承認拡張ユーザーサービス（RADIUS）でリモート認証ダイヤルします"。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（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.とJ. Loughney、 "有料ユーザーID"、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.、サンチェス、M.とB. Aboba、 "RADIUSは、仮想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委任-の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.、サンチェス、M.とB. Aboba、 "RADIUSフィルタルール属性"、RFC 4849、2007年4月。
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit.
このプロトコルは、最初の昇順通信によって開発され、配布されました。サンプルコードは、それらの自由サーバーキットで配布されました。
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.
著者はアビLIOR、ランディブッシュ、スティーブBellovin氏、グレン・ソーン、マーク・ジョーンズ、クラウディオLapidus、アヌラーグバッタ、Kuntalチョードリー、ティム・ムーア、ラスHousley、ジョーSalowey、アランDeKok、デビッドネルソンからの貴重な提案やフィードバックを確認したいと思います。
Appendix A. Changes from
付録A.からの変更点
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用語「ダイナミックな承認クライアントが」代わりに、それは、COA要求および接続解除要求パケットの発信元に適用されるRADIUSサーバを使用しています。用語「動的認証サーバは、」代わりに、それは、COA要求および接続解除要求パケットの受信機に適用されるNASの使用されています。これらの用語の定義は（セクション1.3）を追加されました。
o Added requirement for duplicate detection on the Dynamic Authorization Server (Section 2.3).
ダイナミックな承認サーバー（2.3節）の重複を検出するためのOを追加要件。
o Clarified expected behavior when session identification attributes match more than one session (Sections 2.3, 3, 3.5, 4).
セッション識別属性が複数のセッション（セクション2.3、3、3.5、4）と一致したときにO期待挙動を明らかにしました。
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).
アカウンティング・セッションIdまたはのAcct-Multi-Session-Id属性は、アクセス要求（第3節）に含まれるOを追加しました勧告。
o Added discussion of scenarios in which the "Dynamic Authorization Client" and RADIUS server are not co-located (Section 3).
（第3節）o「のダイナミックな承認クライアント」とは、シナリオの説明を追加しましたし、RADIUSサーバは、同じ場所に配置されていません。
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節）の両方で、オプションです。外しリクエスト内のservice-type属性を使用すると、（セクション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サービスタイプなどの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フィルター・ルール、委任-のIPv6プレフィックス、出口-VLANID、イングレス・フィルタ、出口-VLAN-名、およびユーザ・プライオリティ属性（セクション3.6）を含むように、COA要求属性の表を更新しました。
o Added the Chargeable-User-Identity Attribute to both the CoA-Request and Disconnect-Request Attribute table (Section 3.6).
O有料-ユーザアイデンティティは、COA要求および接続解除 - 要求属性テーブル（セクション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リナンバリングのためのCoAリクエストの使用に注意6を添加し、ベンダー固有の属性（セクション3.6）の使用に注7。
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イベントタイムスタンプ属性は、再送信に再計算するべきではありません。リプレイと重複検出のための含意は（セクション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 Reverse Path Forwarding（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千葉シスコシステムズ、株式会社170西タスマン博士サンノゼCA、95134
EMail: mchiba@cisco.com Phone: +1 408 525 7198
メールアドレス：mchiba@cisco.com電話：+1 408 525 7198
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
ゴパルDommetyシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134
EMail: gdommety@cisco.com Phone: +1 408 525 1404
メールアドレス：gdommety@cisco.com電話：+1 408 525 1404
Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
マーク・エクランドシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134
EMail: meklund@cisco.com Phone: +1 865 671 6255
メールアドレス：meklund@cisco.com電話：+1 865 671 6255
David Mitton RSA, Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730
デイビット・ミットンRSA、EMC 174ミドルターンパイクベッドフォード、MA 01730のセキュリティ部門
EMail: david@mitton.com
メールアドレス：david@mitton.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。