[要約] RFC 6929は、RADIUSプロトコルの拡張に関するものであり、要約すると以下のようになります。1. RADIUSプロトコルの機能を拡張し、新しい認証および認可機能を提供する。 2. ネットワーク上のユーザーの認証と認可を効率的かつ安全に行うための手段を提供する。 3. RADIUSサーバーとネットワークデバイス間の通信を改善し、セキュリティと信頼性を向上させる。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 6929 Network RADIUS
Updates: 2865, 3575, 6158 A. Lior
Category: Standards Track April 2013
ISSN: 2070-1721
Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions
リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコル拡張機能
Abstract
概要
The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.
リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルは、現在の8ビット属性タイプスペースの枯渇に近づいています。さらに、経験上、253オクテットを超えるデータを伝送できる属性とともに、複雑なグループ化の必要性が高まっています。このドキュメントでは、上記の問題すべてに対処するRADIUSの変更を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6929.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6929で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Caveats and Limitations ....................................5
1.1.1. Failure to Meet Certain Goals .......................5
1.1.2. Implementation Recommendations ......................5
1.2. Terminology ................................................6
1.3. Requirements Language ......................................7
2. Extensions to RADIUS ............................................7
2.1. Extended Type ..............................................8
2.2. Long Extended Type .........................................9
2.3. TLV Data Type .............................................12
2.3.1. TLV Nesting ........................................14
2.4. EVS Data Type .............................................14
2.5. Integer64 Data Type .......................................16
2.6. Vendor-Id Field ...........................................16
2.7. Attribute Naming and Type Identifiers .....................17
2.7.1. Attribute and TLV Naming ...........................17
2.7.2. Attribute Type Identifiers .........................18
2.7.3. TLV Identifiers ....................................18
2.7.4. VSA Identifiers ....................................18
2.8. Invalid Attributes ........................................19
3. Attribute Definitions ..........................................21
3.1. Extended-Type-1 ...........................................21
3.2. Extended-Type-2 ...........................................22
3.3. Extended-Type-3 ...........................................23
3.4. Extended-Type-4 ...........................................24
3.5. Long-Extended-Type-1 ......................................25
3.6. Long-Extended-Type-2 ......................................26
4. Vendor-Specific Attributes .....................................27
4.1. Extended-Vendor-Specific-1 ................................28
4.2. Extended-Vendor-Specific-2 ................................29
4.3. Extended-Vendor-Specific-3 ................................30
4.4. Extended-Vendor-Specific-4 ................................31
4.5. Extended-Vendor-Specific-5 ................................32
4.6. Extended-Vendor-Specific-6 ................................34
5. Compatibility with Traditional RADIUS ..........................35
5.1. Attribute Allocation ......................................35
5.2. Proxy Servers .............................................36
6. Guidelines .....................................................37
6.1. Updates to RFC 6158 .......................................37
6.2. Guidelines for Simple Data Types ..........................38
6.3. Guidelines for Complex Data Types .........................38
6.4. Design Guidelines for the New Types .......................39
6.5. TLV Guidelines ............................................40
6.6. Allocation Request Guidelines .............................40
6.7. Allocation Request Guidelines for TLVs ....................41
6.8. Implementation Guidelines .................................42
6.9. Vendor Guidelines .........................................42
7. Rationale for This Design ......................................42
7.1. Attribute Audit ...........................................43
8. Diameter Considerations ........................................44
9. Examples .......................................................44
9.1. Extended Type .............................................46
9.2. Long Extended Type ........................................47
10. IANA Considerations ...........................................50
10.1. Attribute Allocations ....................................50
10.2. RADIUS Attribute Type Tree ...............................50
10.3. Allocation Instructions ..................................52
10.3.1. Requested Allocation from the Standard Space ......52
10.3.2. Requested Allocation from the Short
Extended Space ....................................52
10.3.3. Requested Allocation from the Long
Extended Space ....................................52
10.3.4. Allocation Preferences ............................52
10.3.5. Extending the Type Space via the TLV Data Type ....53
10.3.6. Allocation within a TLV ...........................53
10.3.7. Allocation of Other Data Types ....................54
11. Security Considerations .......................................54
12. References ....................................................54
12.1. Normative References .....................................54
12.2. Informative References ...................................55
13. Acknowledgments ...............................................55
Appendix A. Extended Attribute Generator Program ..................56
Under current allocation pressure, we expect that the RADIUS Attribute Type space will be exhausted by 2014 or 2015. We therefore need a way to extend the type space so that new specifications may continue to be developed. Other issues have also been shown with RADIUS. The attribute grouping method defined in [RFC2868] has been shown to be impractical, and a more powerful mechanism is needed. Multiple Attributes have been defined that transport more than the 253 octets of data originally envisioned with the protocol. Each of these attributes is handled as a "special case" inside of RADIUS implementations, instead of as a general method. We therefore also need a standardized method of transporting large quantities of data. Finally, some vendors are close to allocating all of the Attributes within their Vendor-Specific Attribute space. It would be useful to leverage changes to the base protocol for extending the Vendor-Specific Attribute space.
現在の割り当て圧力の下では、RADIUS Attribute Typeスペースは2014年または2015年までに使い果たされると予想されます。したがって、新しい仕様が引き続き開発されるようにタイプスペースを拡張する方法が必要です。その他の問題もRADIUSで示されています。 [RFC2868]で定義されている属性のグループ化方法は実用的でないことが示されているため、より強力なメカニズムが必要です。最初にプロトコルで想定されていた253オクテットを超えるデータを転送する複数の属性が定義されています。これらの各属性は、一般的な方法としてではなく、RADIUS実装内で「特殊なケース」として処理されます。したがって、大量のデータを転送する標準化された方法も必要です。最後に、一部のベンダーはベンダー固有の属性スペース内ですべての属性を割り当てようとしています。ベンダー固有の属性スペースを拡張するために、ベースプロトコルへの変更を活用すると便利です。
We satisfy all of these requirements through the following changes given in this document:
このドキュメントに記載されている次の変更により、これらの要件をすべて満たしています。
* Defining an "Extended Type" format, which adds 8 bits of "Extended Type" to the RADIUS Attribute Type space, by using one octet of the "Value" field. This method gives us a general way of extending the Attribute Type space (Section 2.1).
* 「値」フィールドの1オクテットを使用して、RADIUS属性タイプスペースに8ビットの「拡張タイプ」を追加する「拡張タイプ」フォーマットを定義します。このメソッドは、属性タイプスペースを拡張する一般的な方法を提供します（セクション2.1）。
* Allocating 4 attributes as using the format of "Extended Type". This allocation extends the RADIUS Attribute Type space by approximately 1000 values (Sections 3.1, 3.2, 3.3, and 3.4).
* 「拡張タイプ」のフォーマットを使用して4つの属性を割り当てます。この割り当てにより、RADIUS属性タイプスペースが約1000値拡張されます（セクション3.1、3.2、3.3、および3.4）。
* Defining a "Long Extended Type" format, which inserts an additional octet between the "Extended Type" octet and the "Value" field. This method gives us a general way of adding more functionality to the protocol (Section 2.2).
* 「拡張タイプ」オクテットと「値」フィールドの間に追加のオクテットを挿入する「ロング拡張タイプ」フォーマットを定義します。この方法は、プロトコルに機能を追加する一般的な方法を提供します（セクション2.2）。
* Defining a method that uses the additional octet in the "Long Extended Type" to indicate data fragmentation across multiple Attributes. This method provides a standard way for an Attribute to carry more than 253 octets of data (Section 2.2).
* 「Long Extended Type」の追加オクテットを使用して、複数の属性にわたるデータの断片化を示すメソッドを定義します。このメソッドは、属性が253オクテットを超えるデータを運ぶための標準的な方法を提供します（セクション2.2）。
* Allocating 2 attributes as using the format "Long Extended Type". This allocation extends the RADIUS Attribute Type space by an additional 500 values (Sections 3.5 and 3.6).
* 「Long Extended Type」のフォーマットを使用して2つの属性を割り当てます。この割り当てにより、RADIUS Attribute Typeスペースがさらに500値拡張されます（セクション3.5および3.6）。
* Defining a new "Type-Length-Value" (TLV) data type. This data type allows an attribute to carry TLVs as "sub-Attributes", which can in turn encapsulate other TLVs as "sub-sub-Attributes". This change creates a standard way to group a set of Attributes (Section 2.3).
* 新しい "Type-Length-Value"（TLV）データ型を定義します。このデータ型により、属性はTLVを「サブ属性」として運ぶことができます。これにより、他のTLVを「サブサブ属性」としてカプセル化できます。この変更により、一連の属性をグループ化する標準的な方法が作成されます（セクション2.3）。
* Defining a new "Extended-Vendor-Specific" (EVS) data type. This data type allows an attribute to carry Vendor-Specific Attributes (VSAs) inside of the new Attribute formats (Section 2.4).
* 新しい "Extended-Vendor-Specific"（EVS）データ型を定義します。このデータ型により、属性は新しい属性形式（セクション2.4）内でベンダー固有属性（VSA）を保持できます。
* Defining a new "integer64" data type. This data type allows counters that track more than 2^32 octets of data (Section 2.5).
* 新しい「integer64」データ型を定義します。このデータ型では、2 ^ 32オクテットを超えるデータを追跡するカウンターを使用できます（セクション2.5）。
* Allocating 6 attributes using the new EVS data type. This allocation extends the Vendor-Specific Attribute Type space by over 1500 values (Sections 4.1 through 4.6).
* 新しいEVSデータ型を使用して6つの属性を割り当てます。この割り当てにより、ベンダー固有の属性タイプスペースが1500以上の値に拡張されます（セクション4.1〜4.6）。
* Defining the "Vendor-Id" for Vendor-Specific Attributes to encompass the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth octet being zero (Section 2.6).
* ベンダーフィールドの4オクテット全体を含むようにベンダー固有属性の「ベンダーID」を定義する。 [RFC2865]セクション5.26は、これを3オクテットと定義し、4番目のオクテットはゼロです（セクション2.6）。
* Describing compatibility with existing RADIUS systems (Section 5).
* 既存のRADIUSシステムとの互換性について説明する（セクション5）。
* Defining guidelines for the use of these changes for IANA, implementations of this specification, and for future RADIUS specifications (Section 6).
* IANAのこれらの変更の使用、この仕様の実装、および将来のRADIUS仕様のためのガイドラインの定義（セクション6）。
As with any protocol change, the changes defined here are the result of a series of compromises. We have tried to find a balance between flexibility, space in the RADIUS message, compatibility with existing deployments, and difficulty of implementation.
他のプロトコル変更と同様に、ここで定義されている変更は一連の妥協の結果です。柔軟性、RADIUSメッセージ内のスペース、既存の展開との互換性、実装の難しさの間のバランスを見つけることを試みました。
This section describes some caveats and limitations of the proposal.
このセクションでは、提案のいくつかの警告と制限について説明します。
One goal that was not met by the above modifications is to have an incentive for standards to use the new space. That incentive is being provided by the exhaustion of the standard space.
上記の変更によって達成されなかった1つの目標は、標準が新しいスペースを使用するインセンティブを持つことです。そのインセンティブは、標準スペースの枯渇によって提供されています。
It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that new specifications use the formats defined in this specification.
実装がこの仕様をサポートすることが推奨されます。新しい仕様では、この仕様で定義されている形式を使用することをお勧めします。
The alternative to the above recommendations is a circular argument of not implementing this specification because no other standards reference it, and also not defining new standards referencing this specification because no implementations exist.
上記の推奨事項の代替案は、他の標準がそれを参照していないためにこの仕様を実装しないこと、および実装が存在しないためにこの仕様を参照する新しい標準を定義しないことの循環的な議論です。
As noted earlier, the standard space is almost entirely allocated. Ignoring the looming crisis benefits no one.
前述のように、標準スペースはほぼ完全に割り当てられています。迫り来る危機を無視することは誰にも利益をもたらしません。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
Silently discard
静かに捨てる
This means the implementation discards the packet without further processing. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
これは、実装がそれ以上処理せずにパケットを破棄することを意味します。実装は、黙って破棄されたパケットの内容を含むエラーをログに記録する機能を提供してもよい（MAY）、統計カウンタにイベントを記録する必要があります（SHOULD）。
Invalid attribute
無効な属性
This means that the Length field of an Attribute is valid (as per [RFC2865], Section 5, top of page 25) but the contents of the Attribute do not follow the correct format, for example, an Attribute of type "address" that encapsulates more than four, or less than four, octets of data. See Section 2.8 for a more complete definition.
つまり、属性の長さフィールドは有効ですが（[RFC2865]、セクション5、25ページの上部）、属性のコンテンツは正しい形式に従っていません。たとえば、「アドレス」タイプの属性は4オクテット以上、または4オクテット未満のデータをカプセル化します。より完全な定義については、セクション2.8を参照してください。
Standard space
標準スペース
This refers to codes in the RADIUS Attribute Type space that are allocated by IANA and that follow the format defined in Section 5 of [RFC2865].
これは、IANAによって割り当てられ、[RFC2865]のセクション5で定義されたフォーマットに従うRADIUS Attribute Typeスペースのコードを参照します。
Extended space
拡張スペース
This refers to codes in the RADIUS Attribute Type space that require the extensions defined in this document and are an extension of the standard space, but that cannot be represented within the standard space.
これは、このドキュメントで定義されている拡張を必要とし、標準スペースの拡張であるが、標準スペース内で表すことができないRADIUS属性タイプスペースのコードを指します。
Short extended space
短い拡張スペース
This refers to codes in the extended space that use the "Extended Type" format.
これは、「拡張タイプ」フォーマットを使用する拡張スペース内のコードを指します。
Long extended space
長い拡張スペース
This refers to codes in the extended space that use the "Long Extended Type" format.
これは、「Long Extended Type」形式を使用する拡張スペース内のコードを指します。
The following terms are used here with the meanings defined in BCP 26 [RFC5226]: "namespace", "assigned value", "registration", "Private Use", "Reserved", "Unassigned", "IETF Review", and "Standards Action".
次の用語は、BCP 26 [RFC5226]で定義されている意味でここで使用されています：「名前空間」、「割り当てられた値」、「登録」、「プライベート使用」、「予約済み」、「未割り当て」、「IETFレビュー」、標準アクション」。
In this document, several words are used to signify the requirements of the specification. 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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section defines two new Attribute formats: "Extended Type" and "Long Extended Type". It defines a new Type-Length-Value (TLV) data type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 data type. It defines a new method for naming attributes and identifying Attributes using the new Attribute formats. It finally defines the new term "invalid attribute" and describes how it affects implementations.
このセクションでは、「拡張タイプ」と「長い拡張タイプ」という2つの新しい属性フォーマットを定義します。新しいType-Length-Value（TLV）データ型、Extended-Vendor-Specific（EVS）データ型、およびInteger64データ型を定義します。新しい属性フォーマットを使用して属性に名前を付け、属性を識別するための新しいメソッドを定義します。最後に、「無効な属性」という新しい用語を定義し、それが実装にどのように影響するかについて説明します。
The new Attribute formats are designed to be compatible with the Attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields are unchanged from that specification. This reuse allows the new formats to be compatible with RADIUS implementations that do not implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim.
新しい属性形式は、[RFC2865]セクション5に記載されている属性形式と互換性があるように設計されています。タイプおよび長さフィールドの意味と解釈は、その仕様から変更されていません。この再利用により、新しい形式は、この仕様を実装していないRADIUS実装と互換性があります。これらの実装では、属性の「値」フィールドを単に無視するか、そのまま転送することができます。
The changes to the Attribute format come about by "stealing" one or more octets from the "Value" field. This change has the effect that the "Value" field of [RFC2865] Section 5 contains both the new octets given here and any attribute-specific Value. The result is that "Value"s in this specification are limited to less than 253 octets in size. This limitation is overcome through the use of the "Long Extended Type" format.
属性形式への変更は、「値」フィールドから1つ以上のオクテットを「盗む」ことによって行われます。この変更により、[RFC2865]セクション5の「値」フィールドに、ここで指定した新しいオクテットと属性固有の値の両方が含まれるようになります。その結果、この仕様の「値」のサイズは253オクテット未満に制限されます。この制限は、「Long Extended Type」フォーマットを使用することで克服されます。
We reiterate that the formats given in this document do not insert new data into an attribute. Instead, we "steal" one octet of Value, so that the definition of the Length field remains unchanged. The new Attribute formats are designed to be compatible with the Attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields is unchanged from that specification. This reuse allows the new formats to be compatible with RADIUS implementations that do not implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim.
このドキュメントに記載されている形式では、属性に新しいデータが挿入されないことを繰り返します。代わりに、1オクテットの値を「盗む」ため、Lengthフィールドの定義は変更されません。新しい属性形式は、[RFC2865]セクション5に記載されている属性形式と互換性があるように設計されています。タイプおよび長さフィールドの意味と解釈は、その仕様から変更されていません。この再利用により、新しい形式は、この仕様を実装していないRADIUS実装と互換性があります。これらの実装では、属性の「値」フィールドを単に無視するか、そのまま転送することができます。
This section defines a new Attribute format, called "Extended Type". A summary of the 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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5.
このフィールドは、[RFC2865]セクション5で定義されている属性形式のタイプフィールドと同じです。
Length
長さ
The Length field is one octet and indicates the length of this Attribute, including the Type, Length, "Extended-Type", and "Value" fields. Permitted values are between 4 and 255. If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below.
長さフィールドは1オクテットであり、タイプ、長さ、「拡張タイプ」、および「値」フィールドを含む、この属性の長さを示します。許可される値は4〜255です。クライアントまたはサーバーが長さ2または3の拡張属性を受信した場合、その属性は「無効な属性」と見なされ、以下のセクション2.8に従って処理される必要があります。
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in Section 10. Unlike the Type field defined in [RFC2865] Section 5, no values are allocated for experimental or implementation-specific use. Values 241-255 are reserved and MUST NOT be used.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って指定されます。[RFC2865]セクション5で定義されているタイプフィールドとは異なり、実験的または実装固有の使用のために値は割り当てられません。値241-255は予約されており、使用してはなりません（MUST NOT）。
The Extended-Type is meaningful only within a context defined by the Type field. That is, this field may be thought of as defining a new type space of the form "Type.Extended-Type". See Section 3.5, below, for additional discussion.
Extended-Typeは、Typeフィールドで定義されたコンテキスト内でのみ意味があります。つまり、このフィールドは、 "Type.Extended-Type"という形式の新しいタイプスペースを定義していると考えることができます。詳細については、以下のセクション3.5を参照してください。
A RADIUS server MAY ignore Attributes with an unknown "Type.Extended-Type".
RADIUSサーバーは、不明な "Type.Extended-Type"を持つ属性を無視してもよい（MAY）。
A RADIUS client MAY ignore Attributes with an unknown "Type.Extended-Type".
RADIUSクライアントは、未知の "Type.Extended-Type"を持つ属性を無視してもよい（MAY）。
Value
値
This field is similar to the "Value" field of the Attribute format defined in [RFC2865] Section 5. The format of the data MUST be a valid RADIUS data type.
このフィールドは、[RFC2865]セクション5で定義されている属性形式の「値」フィールドに似ています。データの形式は、有効なRADIUSデータタイプである必要があります。
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
The addition of the Extended-Type field decreases the maximum length for attributes of type "text" or "string" from 253 to 252 octets. Where an Attribute needs to carry more than 252 octets of data, the "Long Extended Type" format MUST be used.
Extended-Typeフィールドの追加により、タイプ「テキスト」または「ストリング」の属性の最大長が253オクテットから252オクテットに減少します。属性が252オクテットを超えるデータを伝送する必要がある場合は、「Long Extended Type」形式を使用する必要があります。
Experience has shown that the "experimental" and "implementation-specific" attributes defined in [RFC2865] Section 5 have had little practical value. We therefore do not continue that practice here with the Extended-Type field.
[RFC2865]セクション5で定義されている「実験的」および「実装固有」の属性は、実用的な価値がほとんどないことが経験からわかっています。したがって、ここでは、Extended-Typeフィールドを使用したその練習を続けません。
This section defines a new Attribute format, called "Long Extended Type". It leverages the "Extended Type" format in order to permit the transport of attributes encapsulating more than 253 octets of data. A summary of the Attribute format is shown below. The fields are transmitted from left to right.
このセクションでは、「Long Extended Type」と呼ばれる新しい属性形式を定義します。 253オクテットを超えるデータをカプセル化する属性の転送を可能にするために、「拡張タイプ」フォーマットを活用します。属性フォーマットの要約を以下に示します。フィールドは左から右に送信されます。
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5.
このフィールドは、[RFC2865]セクション5で定義されている属性形式のタイプフィールドと同じです。
Length
長さ
The Length field is one octet and indicates the length of this Attribute, including the Type, Length, Extended-Type, and "Value" fields. Permitted values are between 5 and 255. If a client or server receives a "Long Extended Type" with a Length of 2, 3, or 4, then that Attribute MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below.
長さフィールドは1オクテットで、タイプ、長さ、拡張タイプ、および「値」フィールドを含む、この属性の長さを示します。許可される値は5〜255です。クライアントまたはサーバーが長さ2、3、または4の「Long Extended Type」を受信した場合、その属性は「無効な属性」と見なされ、セクション2.8に従って処理される必要があります。 、 未満。
Note that this Length is limited to the length of this fragment. There is no field that gives an explicit value for the total size of the fragmented attribute.
この長さは、このフラグメントの長さに制限されることに注意してください。フラグメント化された属性の合計サイズの明示的な値を提供するフィールドはありません。
Extended-Type
拡張タイプ
This field is identical to the Extended-Type field defined above in Section 2.1.
このフィールドは、セクション2.1で定義したExtended-Typeフィールドと同じです。
M (More)
M（もっと）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. The More field MUST be clear (0) if the Length field has a value of less than 255. The More field MAY be set (1) if the Length field has a value of 255.
Moreフィールドは長さが1ビットで、現在の属性に251オクテットを超えるデータが含まれているかどうかを示します。長さフィールドの値が255未満の場合、詳細フィールドはクリア（0）でなければなりません。長さフィールドの値が255の場合、詳細フィールドを設定できます（1）。
If the More field is set (1), it indicates that the "Value" field has been fragmented across multiple RADIUS attributes. When the More field is set (1), the Attribute MUST have a Length field of value 255, there MUST be an attribute following this one, and the next attribute MUST have both the same Type and "Extended Type". That is, multiple fragments of the same value MUST be in order and MUST be consecutive attributes in the packet, and the last attribute in a packet MUST NOT have the More field set (1).
Moreフィールドが設定されている場合（1）は、「Value」フィールドが複数のRADIUS属性にわたってフラグメント化されていることを示します。 Moreフィールドが設定されている場合（1）、属性には値255の長さフィールドがなければならず、これに続く属性がなければならず、次の属性は同じタイプと「拡張タイプ」の両方を持っている必要があります。つまり、同じ値の複数のフラグメントが順番に並んでいる必要があり、パケット内の連続した属性である必要があります。また、パケット内の最後の属性にはMoreフィールドが設定されていてはなりません（1）。
That is, a packet containing a fragmented attribute needs to contain all fragments of the Attribute, and those fragments need to be contiguous in the packet. RADIUS does not support inter-packet fragmentation, which means that fragmenting an attribute across multiple packets is impossible.
つまり、フラグメント化された属性を含むパケットには、属性のすべてのフラグメントが含まれている必要があり、それらのフラグメントはパケット内で連続している必要があります。 RADIUSはパケット間フラグメンテーションをサポートしていません。つまり、複数のパケット間で属性をフラグメント化することは不可能です。
If a client or server receives an attribute fragment with the "More" field set (1) but for which no subsequent fragment can be found, then the fragmented attribute is considered to be an "invalid attribute" and handled as per Section 2.8, below.
クライアントまたはサーバーが "More"フィールドセット（1）を持つ属性フラグメントを受信したが、後続のフラグメントが見つからない場合、フラグメント化された属性は "無効な属性"と見なされ、以下のセクション2.8に従って処理されます。 。
Reserved
予約済み
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
このフィールドは7ビット長で、将来の使用のために予約されています。実装は、パケットを送信するための属性をエンコードするときに、ゼロ（0）に設定する必要があります。内容は受信時に無視する必要があります。
Future specifications may define additional meaning for this field. Implementations therefore MUST NOT treat this field as invalid if it is non-zero.
将来の仕様では、このフィールドの追加の意味が定義される可能性があります。したがって、実装では、このフィールドがゼロ以外の場合は無効として扱わないでください。
Value
値
This field is similar to the "Value" field of the Attribute format defined in [RFC2865] Section 5. It may contain a complete set of data (when the Length field has a value of less than 255), or it may contain a fragment of data.
このフィールドは、[RFC2865]セクション5で定義されている属性形式の「値」フィールドに似ています。データの完全なセットが含まれる場合（長さフィールドの値が255未満の場合）、またはフラグメントが含まれる場合があります。データの。
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Any interpretation of the resulting data MUST occur after the fragments have been reassembled. The length of the data MUST be taken as the sum of the lengths of the fragments (i.e., "Value" fields) from which it is constructed. The format of the data SHOULD be a valid RADIUS data type. If the reassembled data does not match the expected format, all fragments MUST be treated as "invalid attributes", and the reassembled data MUST be discarded.
結果のデータの解釈は、フラグメントが再構成された後に発生する必要があります。データの長さは、それが構成されているフラグメント（つまり、「値」フィールド）の長さの合計として解釈する必要があります。データの形式は、有効なRADIUSデータタイプである必要があります（SHOULD）。再構成されたデータが予期された形式と一致しない場合、すべてのフラグメントは「無効な属性」として扱われなければならず、再構成されたデータは破棄されなければなりません（MUST）。
We note that the maximum size of a fragmented attribute is limited only by the RADIUS packet length limitation (i.e., 4096 octets, not counting various headers and overhead). Implementations MUST be able to handle the case where one fragmented attribute completely fills the packet.
フラグメント化された属性の最大サイズは、RADIUSパケット長の制限（つまり、4096オクテットで、さまざまなヘッダーとオーバーヘッドをカウントしない）によってのみ制限されることに注意してください。実装は、1つの断片化された属性がパケットを完全に埋める場合を処理できなければなりません（MUST）。
This definition increases the RADIUS Attribute Type space as above but also provides for transport of Attributes that could contain more than 253 octets of data.
この定義は、上記のようにRADIUS Attribute Typeスペースを増やしますが、253オクテットを超えるデータを含む可能性のある属性の転送も提供します。
Note that [RFC2865] Section 5 says:
[RFC2865]セクション5には次のように記載されています。
If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of attributes of different types. A RADIUS server or client MUST NOT require attributes of the same type to be contiguous.
同じタイプの属性が複数存在する場合、同じタイプの属性の順序はプロキシによって保持されなければなりません（MUST）。異なるタイプの属性の順序を保持する必要はありません。 RADIUSサーバーまたはクライアントは、異なるタイプの属性の順序に依存してはいけません。 RADIUSサーバーまたはクライアントは、同じタイプの属性が連続していることを要求してはなりません（MUST NOT）。
These requirements also apply to the "Long Extended Type" Attribute, including fragments. Implementations MUST be able to process non-contiguous fragments -- that is, fragments that are mixed together with other attributes of a different Type. This will allow them to accept packets, so long as the Attributes can be correctly decoded.
これらの要件は、フラグメントを含む「Long Extended Type」属性にも適用されます。実装は、連続していないフラグメント、つまり、異なるタイプの他の属性と混合されているフラグメントを処理できる必要があります。これにより、属性を正しくデコードできる限り、パケットを受け入れることができます。
We define a new data type in RADIUS, called "tlv". The "tlv" data type is an encapsulation layer that permits the "Value" field of an Attribute to contain new sub-Attributes. These sub-Attributes can in turn contain "Value"s of data type TLV. This capability both extends the Attribute space and permits "nested" attributes to be used. This nesting can be used to encapsulate or group data into one or more logical containers.
RADIUSで「tlv」と呼ばれる新しいデータタイプを定義します。 「tlv」データ型は、属性の「値」フィールドに新しいサブ属性を含めることを許可するカプセル化レイヤーです。これらのサブ属性には、データ型TLVの「値」を含めることができます。この機能により、属性スペースが拡張され、「ネストされた」属性を使用できるようになります。このネストは、データを1つ以上の論理コンテナーにカプセル化またはグループ化するために使用できます。
The "tlv" data type reuses the RADIUS Attribute format, as given below:
「tlv」データ型は、以下に示すように、RADIUS属性形式を再利用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV-Type
TLVタイプ
The TLV-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in Section 10. Values 254-255 are "Reserved" for use by future extensions to RADIUS. The value 26 has no special meaning and MUST NOT be treated as a Vendor-Specific Attribute.
TLV-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って指定されます。値254-255は、RADIUSの将来の拡張で使用するために「予約」されています。値26には特別な意味はなく、ベンダー固有属性として扱われてはいけません。
As with the Extended-Type field defined above, the TLV-Type is meaningful only within the context defined by "Type" fields of the encapsulating Attributes. That is, the field may be thought of as defining a new type space of the form "Type.Extended-Type.TLV-Type". Where TLVs are nested, the type space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.
上記で定義されたExtended-Typeフィールドと同様に、TLV-Typeは、カプセル化する属性の「Type」フィールドによって定義されたコンテキスト内でのみ意味があります。つまり、フィールドは「Type.Extended-Type.TLV-Type」という形式の新しいタイプスペースを定義していると考えることができます。 TLVがネストされている場合、タイプスペースは「Type.Extended-Type.TLV-Type.TLV-Type」などの形式になります。
A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".
RADIUSサーバーは、「TLV-Type」が不明な属性を無視してもよい（MAY）。
A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".
RADIUSクライアントは、「TLV-Type」が不明な属性を無視してもよい（MAY）。
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-Type" verbatim.
RADIUSプロキシは、不明な「TLV-Type」をそのまま属性に転送する必要があります（SHOULD）。
TLV-Length
TLV-長さ
The TLV-Length field is one octet and indicates the length of this TLV, including the TLV-Type, TLV-Length, and TLV-Value fields. It MUST have a value between 3 and 255. If a client or server receives a TLV with an invalid TLV-Length, then the Attribute that encapsulates that TLV MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below.
TLV-Lengthフィールドは1オクテットで、TLV-Type、TLV-Length、およびTLV-Valueフィールドを含む、このTLVの長さを示します。これは3から255の間の値を持つ必要があります。クライアントまたはサーバーが無効なTLV-Lengthを持つTLVを受信した場合、そのTLVをカプセル化する属性は「無効な属性」と見なされ、以下のセクション2.8に従って処理される必要があります。 。
TLV-Value
TLV値
The TLV-Value field is one or more octets and contains information specific to the Attribute. The format and length of the TLV-Value field are determined by the TLV-Type and TLV-Length fields.
TLV-Valueフィールドは1つ以上のオクテットであり、属性に固有の情報が含まれています。 TLV-Valueフィールドの形式と長さは、TLV-TypeフィールドとTLV-Lengthフィールドによって決まります。
The TLV-Value field SHOULD encapsulate a standard RADIUS data type. Non-standard data types SHOULD NOT be used within TLV-Value fields. We note that the TLV-Value field MAY also contain one or more attributes of data type TLV; data type TLV allows for simple grouping and multiple layers of nesting.
TLV値フィールドは、標準のRADIUSデータタイプをカプセル化する必要があります（SHOULD）。非標準のデータ型は、TLV値フィールド内では使用しないでください。 TLV値フィールドには、データ型TLVの1つ以上の属性も含まれる場合があることに注意してください。データ型TLVを使用すると、単純なグループ化と複数階層のネストが可能になります。
The TLV-Value field is limited to containing 253 or fewer octets of data. Specifications that require a TLV to contain more than 253 octets of data are incompatible with RADIUS and need to be redesigned. Specifications that require the transport of empty "Value"s (i.e., Length = 2) are incompatible with RADIUS and need to be redesigned.
TLV値フィールドは、253オクテット以下のデータを含むように制限されています。 TLVに253オクテットを超えるデータを含める必要がある仕様は、RADIUSと互換性がなく、再設計する必要があります。空の「値」（つまり、長さ= 2）の転送を必要とする仕様は、RADIUSと互換性がなく、再設計する必要があります。
The TLV-Value field MUST NOT contain data using the "Extended Type" formats defined in this document. The base Extended Attributes format allows for sufficient flexibility that nesting them inside of a TLV offers little additional value.
TLV-Valueフィールドには、このドキュメントで定義されている「拡張タイプ」フォーマットを使用したデータを含めてはなりません（MUST NOT）。基本の拡張属性形式では、TLV内にそれらをネストしても、追加の値がほとんどないほどの柔軟性が得られます。
This TLV definition is compatible with the suggested format of the "String" field of the Vendor-Specific Attribute, as defined in [RFC2865] Section 5.26, though that specification does not discuss nesting.
このTLV定義は、[RFC2865]セクション5.26で定義されているベンダー固有属性の「文字列」フィールドの推奨フォーマットと互換性がありますが、その仕様ではネストについて説明していません。
Vendors MAY use attributes of type "TLV" in any Vendor-Specific Attribute. It is RECOMMENDED to use type "TLV" for VSAs, in preference to any other format.
ベンダーは、ベンダー固有の属性でタイプ「TLV」の属性を使用できます。 VSAには、他の形式よりも「TLV」タイプを使用することをお勧めします。
If multiple TLVs with the same TLV-Type are present, the order of TLVs with the same TLV-Type MUST be preserved by any proxies. The order of TLVs of different TLV-Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of TLVs of different TLV-Types. A RADIUS server or client MUST NOT require TLVs of the same TLV-Type to be contiguous.
同じTLV-Typeを持つTLVが複数存在する場合、同じTLV-Typeを持つTLVの順序は、プロキシによって維持されなければなりません（MUST）。異なるTLVタイプのTLVの順序を維持する必要はありません。 RADIUSサーバーまたはクライアントは、異なるTLVタイプのTLVの順序に依存してはいけません。 RADIUSサーバーまたはクライアントは、同じTLVタイプのTLVが連続していることを要求してはなりません（MUST NOT）。
The interpretation of multiple TLVs of the same TLV-Type MUST be that of a logical "and", unless otherwise specified. That is, multiple TLVs are interpreted as specifying an unordered set of values. Specifications SHOULD NOT define TLVs to be interpreted as a logical "or". Doing so would mean that a RADIUS client or server would make an arbitrary and non-deterministic choice among the values.
同じTLVタイプの複数のTLVの解釈は、特に指定されていない限り、論理「and」の解釈でなければなりません。つまり、複数のTLVは、順序付けられていない値のセットを指定するものとして解釈されます。仕様では、論理「または」として解釈されるTLVを定義しないでください。そうすることは、RADIUSクライアントまたはサーバーが値の中から任意の非決定論的な選択を行うことを意味します。
TLVs may contain other TLVs. When this occurs, the "container" TLV MUST be completely filled by the "contained" TLVs. That is, the "container" TLV-Length field MUST be exactly two (2) more than the sum of the "contained" TLV-Length fields. If the "contained" TLVs overfill the "container" TLV, the "container" TLV MUST be considered to be an "invalid attribute" and handled as described in Section 2.8, below.
TLVには他のTLVが含まれる場合があります。これが発生した場合、「コンテナー」TLVは「コンテナー」TLVによって完全に満たされなければなりません（MUST）。つまり、「container」TLV-Lengthフィールドは、「contained」TLV-Lengthフィールドの合計よりも2倍大きくなければなりません。 「contained」TLVが「container」TLVを超える場合、「container」TLVは「無効な属性」と見なされ、以下のセクション2.8で説明されているように処理される必要があります。
The depth of TLV nesting is limited only by the restrictions on the TLV-Length field. The limit of 253 octets of data results in a limit of 126 levels of nesting. However, nesting depths of more than 4 are NOT RECOMMENDED. They have not been demonstrated to be necessary in practice, and they appear to make implementations more complex. Reception of packets with such deeply nested TLVs may indicate implementation errors or deliberate attacks. Where implementations do not support deep nesting of TLVs, it is RECOMMENDED that the unsupported layers are treated as "invalid attributes".
TLVネストの深さは、TLV-Lengthフィールドの制限によってのみ制限されます。データの253オクテットの制限により、ネストのレベルは126レベルに制限されます。ただし、ネストの深さが4を超えることはお勧めしません。それらは実際に必要であることが実証されておらず、実装をより複雑にするように見えます。このような深くネストされたTLVを持つパケットの受信は、実装エラーまたは意図的な攻撃を示している可能性があります。実装がTLVの深い入れ子をサポートしていない場合、サポートされていない層を「無効な属性」として扱うことをお勧めします。
We define a new data type in RADIUS, called "evs", for "Extended-Vendor-Specific". The "evs" data type is an encapsulation layer that permits the EVS-Value field of an Attribute to contain a Vendor-Id, followed by an EVS-Type, and then vendor-defined data. This data can in turn contain valid RADIUS data types or any other data as determined by the vendor.
RADIUSでは、「Extended-Vendor-Specific」の「evs」と呼ばれる新しいデータタイプを定義します。 「evs」データタイプは、属性のEVS-ValueフィールドにVendor-Id、次にEVS-Type、次にベンダー定義のデータを含めることを許可するカプセル化レイヤーです。このデータには、ベンダーが決定した有効なRADIUSデータタイプまたはその他のデータを含めることができます。
This data type is intended for use in attributes that carry vendor-specific information, as is done with the Vendor-Specific Attribute (Attribute number 26). It is RECOMMENDED that this data type be used by a vendor only when the Vendor-Specific Attribute Type space has been fully allocated.
このデータ型は、ベンダー固有の属性（属性番号26）で行われるように、ベンダー固有の情報を運ぶ属性での使用を目的としています。ベンダー固有の属性タイプスペースが完全に割り当てられている場合にのみ、ベンダーがこのデータタイプを使用することをお勧めします。
Where [RFC2865] Section 5.26 makes a recommendation for the format of the data following the Vendor-Id, we give a strict definition. Experience has shown that many vendors have not followed the [RFC2865] recommendations, leading to interoperability issues. We hope here to give vendors sufficient flexibility as to meet their needs while minimizing the use of non-standard VSA formats.
[RFC2865]セクション5.26がVendor-Idに続くデータの形式を推奨している場合、厳密な定義を行います。経験上、多くのベンダーが[RFC2865]の推奨事項に従っていないため、相互運用性の問題が発生しています。ここでは、非標準のVSA形式の使用を最小限に抑えながら、ベンダーのニーズを満たすのに十分な柔軟性をベンダーに提供したいと考えています。
The "evs" data type MAY be used in Attributes having the format of "Extended Type" or "Long Extended Type". It MUST NOT be used in any other Attribute definition, including standard RADIUS attributes, TLVs, and VSAs.
「evs」データタイプは、「拡張タイプ」または「長い拡張タイプ」の形式の属性で使用できます。標準のRADIUS属性、TLV、VSAなど、他の属性定義では使用しないでください。
A summary of the "evs" data type format is shown below. The fields are transmitted from left to right.
「evs」データ型フォーマットの要約を以下に示します。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVS-Type | EVS-Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
EVS-Type
EVSタイプ
The EVS-Type field is one octet. Values are assigned at the sole discretion of the vendor.
EVS-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
EVS-Value
EVS値
The EVS-Value field is one or more octets. It SHOULD encapsulate a standard RADIUS data type. Using non-standard data types is NOT RECOMMENDED. We note that the EVS-Value field may be of data type TLV. However, it MUST NOT be of data type "evs", as the use cases are unclear for one vendor delegating Attribute Type space to another vendor.
EVS-Valueフィールドは1つ以上のオクテットです。標準のRADIUSデータ型をカプセル化する必要があります。非標準のデータ型を使用することはお勧めしません。 EVS-ValueフィールドはTLVデータ型である可能性があることに注意してください。ただし、あるタイプのベンダーが属性タイプのスペースを別のベンダーに委任する場合のユースケースは不明確であるため、データタイプは「evs」であってはなりません。
The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. While we recognize that vendors have complete control over the contents and format of the EVS-Value field, we recommend that good practices be followed.
情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。ベンダーはEVS-Valueフィールドの内容と形式を完全に制御できることを認識していますが、適切な慣行に従うことをお勧めします。
Further codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの許可された使用法の範囲をさらに体系化することは、この仕様の範囲外です。
Note that unlike the format described in [RFC2865] Section 5.26, this data type has no "Vendor-Length" field. The length of the EVS-Value field is implicit and is determined by taking the "Length" of the encapsulating RADIUS attribute and then subtracting the length of the Attribute header (2 octets), the "Extended Type" (1 octet), the Vendor-Id (4 octets), and the EVS-Type (1 octet). That is, for "Extended Type" Attributes the length of the EVS-Value field is eight (8) less than the value of the Length field, and for "Long Extended Type" Attributes the length of the EVS-Value field is nine (9) less than the value of the Length field.
[RFC2865]セクション5.26で説明されている形式とは異なり、このデータ型には「Vendor-Length」フィールドがないことに注意してください。 EVS値フィールドの長さは暗黙的であり、カプセル化RADIUS属性の「長さ」を取得し、次に属性ヘッダーの長さ（2オクテット）、「拡張タイプ」（1オクテット）、ベンダーを差し引くことによって決定されます。 -Id（4オクテット）、およびEVS-Type（1オクテット）。つまり、「拡張タイプ」属性の場合、EVS値フィールドの長さは「長さ」フィールドの値よりも8短く、「拡張タイプ」属性の場合、EVS値フィールドの長さは9（ 9）長さフィールドの値より小さい。
We define a new data type in RADIUS, called "integer64", which carries a 64-bit unsigned integer in network byte order.
RADIUSで「integer64」と呼ばれる新しいデータタイプを定義します。これは、ネットワークバイトオーダーで64ビットの符号なし整数を伝送します。
This data type is intended to be used in any situation where there is a need to have counters that can count past 2^32. The expected use of this data type is within Accounting-Request packets, but this data type SHOULD be used in any packet where 32-bit integers are expected to be insufficient.
このデータ型は、2 ^ 32を超えてカウントできるカウンターが必要な状況で使用することを目的としています。このデータ型の予想される使用はAccounting-Requestパケット内にありますが、このデータ型は、32ビット整数では不十分であると予想されるすべてのパケットで使用する必要があります（SHOULD）。
The "integer64" data type can be used in Attributes of any format, standard space, extended attributes, TLVs, and VSAs.
「integer64」データ型は、任意の形式の属性、標準スペース、拡張属性、TLV、およびVSAで使用できます。
A summary of the "integer64" data type format is shown below. The fields are transmitted from left to right.
「integer64」データ型フォーマットの要約を以下に示します。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length field set to eight more than the length of the Attribute header. For standard space Attributes and TLVs, this means that the Length field MUST be set to ten (10). For "Extended Type" Attributes, the Length field MUST be set to eleven (11). For "Long Extended Type" Attributes, the Length field MUST be set to twelve (12).
データ型が「integer64」の属性では、関連する長さフィールドを属性ヘッダーの長さよりも8大きく設定する必要があります。標準スペースの属性とTLVの場合、これは長さフィールドを10に設定する必要があることを意味します。 「拡張タイプ」属性の場合、長さフィールドは11に設定する必要があります。 「Long Extended Type」属性の場合、Lengthフィールドは12に設定する必要があります。
We define the Vendor-Id field of Vendor-Specific Attributes to encompass the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth octet being zero. This change has no immediate impact on RADIUS, as the maximum Private Enterprise Code defined is still within 16 bits.
Vendor-Specific AttributesのVendor-Idフィールドを定義して、Vendorフィールドの4オクテット全体を包含します。 [RFC2865]セクション5.26では、4オクテットがゼロである3オクテットと定義されています。定義されている最大のプライベートエンタープライズコードが16ビット以内であるため、この変更はRADIUSに直接影響を与えません。
However, it is best to make advance preparations for changes in the protocol. As such, it is RECOMMENDED that all implementations support four (4) octets for the Vendor-Id field, instead of three (3).
ただし、プロトコルの変更に備えて事前に準備することをお勧めします。そのため、すべての実装でVendor-Idフィールドの3つの代わりに4つのオクテットをサポートすることをお勧めします。
Attributes have traditionally been identified by a unique name and number. For example, the Attribute "User-Name" has been allocated number one (1). This scheme needs to be extended in order to be able to refer to attributes of "Extended Type", and to TLVs. It will also be used by IANA for allocating RADIUS Attribute Type values.
属性は従来、一意の名前と番号で識別されていました。たとえば、属性「ユーザー名」には1番が割り当てられています。 「拡張タイプ」の属性とTLVを参照できるようにするには、このスキームを拡張する必要があります。また、RADIUS属性タイプの値を割り当てるためにIANAによって使用されます。
The names and identifiers given here are intended to be used only in specifications. The system presented here may not be useful when referring to the contents of a RADIUS packet. It imposes no requirements on implementations, as implementations are free to reference RADIUS attributes via any method they choose.
ここに記載されている名前と識別子は、仕様でのみ使用することを目的としています。ここで紹介するシステムは、RADIUSパケットの内容を参照する場合には役に立たない場合があります。実装は、任意の方法でRADIUS属性を自由に参照できるため、実装に要件はありません。
RADIUS specifications traditionally use names consisting of one or more words, separated by hyphens, e.g., "User-Name". However, these names are not allocated from a registry, and there is no restriction other than convention on their global uniqueness.
RADIUS仕様では、伝統的に、「ユーザー名」のように、ハイフンで区切られた1つ以上の単語で構成される名前を使用します。ただし、これらの名前はレジストリから割り当てられるものではなく、グローバルな一意性に関する規則以外の制限はありません。
Similarly, vendors have often used their company name as the prefix for VSA names, though this practice is not universal. For example, for a vendor named "Example", the name "Example-Attribute-Name" SHOULD be used instead of "Attribute-Name". The second form can conflict with attributes from other vendors, whereas the first form cannot.
同様に、ベンダーはVSA名のプレフィックスとして会社名を使用することがよくありますが、これは一般的なことではありません。たとえば、「Example」という名前のベンダーの場合、「Attribute-Name」の代わりに「Example-Attribute-Name」という名前を使用する必要があります（SHOULD）。 2番目の形式は他のベンダーの属性と競合する可能性がありますが、最初の形式は競合できません。
It is therefore RECOMMENDED that specifications give names to Attributes that attempt to be globally unique across all RADIUS Attributes. It is RECOMMENDED that a vendor use its name as a unique prefix for attribute names, e.g., Livingston-IP-Pool instead of IP-Pool. It is RECOMMENDED that implementations enforce uniqueness on names; not doing so would lead to ambiguity and problems.
したがって、仕様では、すべてのRADIUS属性全体でグローバルに一意となるように属性に名前を付けることをお勧めします。ベンダーがその名前を属性名の一意のプレフィックスとして使用することをお勧めします（例：IP-PoolではなくLivingston-IP-Pool）。実装は名前に一意性を強制することが推奨されます。そうしないと、あいまいさと問題が発生します。
We recognize that these suggestions may sometimes be difficult to implement in practice.
これらの提案は、実際に実装するのが難しい場合があることを認識しています。
TLVs SHOULD be named with a unique prefix that is shared among related attributes. For example, a specification that defines a set of TLVs related to time could create attributes called "Time-Zone", "Time-Day", "Time-Hour", "Time-Minute", etc.
TLVには、関連する属性間で共有される一意のプレフィックスを付けて名前を付ける必要があります（SHOULD）。たとえば、時間に関連する一連のTLVを定義する仕様では、「Time-Zone」、「Time-Day」、「Time-Hour」、「Time-Minute」などと呼ばれる属性を作成できます。
The RADIUS Attribute Type space defines a context for a particular "Extended-Type" field. The "Extended-Type" field allows for 256 possible type code values, with values 1 through 240 available for allocation. We define here an identification method that uses a "dotted number" notation similar to that used for Object Identifiers (OIDs), formatted as "Type.Extended-Type".
RADIUS属性タイプスペースは、特定の「拡張タイプ」フィールドのコンテキストを定義します。 「Extended-Type」フィールドでは、256の可能なタイプコード値を使用でき、1〜240の値を割り当てに使用できます。ここでは、「Type.Extended-Type」としてフォーマットされた、オブジェクト識別子（OID）に使用されるものと同様の「ドット付き番号」表記を使用する識別方法を定義します。
For example, an attribute within the Type space of 241, having Extended-Type of one (1), is uniquely identified as "241.1". Similarly, an attribute within the Type space of 246, having Extended-Type of ten (10), is uniquely identified as "246.10".
たとえば、タイプスペース241内の属性は、Extended-Typeが1で、「24.1」として一意に識別されます。同様に、Type-spaceが246で、Extended-Typeが10の属性は、「246.10」として一意に識別されます。
We can extend the Attribute reference scheme defined above for TLVs. This is done by leveraging the "dotted number" notation. As above, we define an additional TLV Type space, within the "Extended Type" space, by appending another "dotted number" in order to identify the TLV. This method can be repeated in sequence for nested TLVs.
上記で定義したTLVの属性参照スキーマを拡張できます。これは、「ドット付き番号」表記を活用することによって行われます。上記のように、TLVを識別するために別の「ドット番号」を追加することにより、「拡張タイプ」スペース内に追加のTLVタイプスペースを定義します。この方法は、ネストされたTLVに対して順番に繰り返すことができます。
For example, let us say that "245.1" identifies RADIUS Attribute Type 245, containing an "Extended Type" of one (1), which is of type "TLV". That attribute will contain 256 possible TLVs, one for each value of the TLV-Type field. The first TLV-Type value of one (1) can then be identified by appending a ".1" to the number of the encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, the sequence "245.2.3.4" identifies RADIUS attribute 245, containing an "Extended Type" of two (2), which is of type "TLV", which in turn contains a TLV with TLV-Type number three (3), which in turn contains another TLV, with TLV-Type number four (4).
たとえば、「245.1」がRADIUSアトリビュートタイプ245を識別し、タイプ「TLV」である「拡張タイプ」が1であるとします。この属性には、TLV-Typeフィールドの値ごとに1つずつ、256の可能なTLVが含まれます。 1の最初のTLV-Type値は、カプセル化属性の番号（「241.1」）に「.1」を追加して「241.1.1」を生成することで識別できます。同様に、シーケンス「245.2.3.4」は、RADIUS属性245を識別し、「拡張タイプ」2を含みます。これは、タイプ「TLV」であり、TLVタイプ番号3のTLVを含みます。次に、TLVタイプ番号4の別のTLVが含まれます。
There has historically been no method for numerically addressing VSAs. The "dotted number" method defined here can also be leveraged to create such an addressing scheme. However, as the VSAs are completely under the control of each individual vendor, this section provides a suggested practice but does not define a standard of any kind.
VSAを数値的に扱う方法はこれまでありませんでした。ここで定義されている「ドット付き番号」方式を利用して、このようなアドレッシング方式を作成することもできます。ただし、VSAは完全に各ベンダーの管理下にあるため、このセクションでは推奨される方法を示しますが、いかなる種類の標準も定義していません。
The Vendor-Specific Attribute has been assigned the Attribute number 26. It in turn carries a 32-bit Vendor-Id, and possibly additional VSAs. Where the VSAs follow the format recommended by [RFC2865] Section 5.26, a VSA can be identified as "26.Vendor-Id.Vendor-Type".
ベンダー固有属性には、属性番号26が割り当てられています。次に、32ビットのベンダーIDと、場合によっては追加のVSAが含まれます。 VSAが[RFC2865]セクション5.26で推奨されている形式に従っている場合、VSAは「26.Vendor-Id.Vendor-Type」として識別できます。
For example, Livingston has Vendor-Id 307 and has defined an attribute "IP-Pool" as number 6. This VSA can be uniquely identified as 26.307.6, but it cannot be uniquely identified by name, as other vendors may have used the same name.
たとえば、LivingstonにはVendor-Id 307があり、属性「IP-Pool」を番号6として定義しています。このVSAは26.307.6として一意に識別できますが、他のベンダーが使用している可能性があるため、名前で一意に識別できません。同名。
Note that there are few restrictions on the size of the numerical values in this notation. The Vendor-Id is a 32-bit number, and the VSA may have been assigned from a 16-bit Vendor-Specific Attribute Type space. Implementations SHOULD be capable of handling 32-bit numbers at each level of the "dotted number" notation.
この表記では、数値のサイズにいくつかの制限があることに注意してください。ベンダーIDは32ビットの数値であり、VSAは16ビットのベンダー固有属性タイプスペースから割り当てられている可能性があります。実装は、「ドット付き数値」表記の各レベルで32ビットの数値を処理できる必要があります（SHOULD）。
For example, the company USR has historically used Vendor-Id 429 and has defined a "Version-Id" attribute as number 32768. This VSA can be uniquely identified as 26.429.32768 but again cannot be uniquely identified by name.
たとえば、USR社は歴史的にVendor-Id 429を使用しており、「Version-Id」属性を番号32768として定義しています。このVSAは26.429.32768として一意に識別できますが、名前で一意に識別することはできません。
Where a VSA is a TLV, the "dotted number" notation can be used as above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3, where the "TLVn" values are the numerical values assigned by the vendor to the different nested TLVs.
VSAがTLVの場合、「ドット番号」表記は上記のように使用できます。26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3。ここで、「TLVn」値は、ベンダーによって割り当てられた数値です。異なるネストされたTLV。
The term "invalid attribute" is new to this specification. It is defined to mean that the Length field of an Attribute permits the packet to be accepted as not being "malformed". However, the "Value" field of the Attribute does not follow the format required by the data type defined for that Attribute, and therefore the Attribute is "malformed". In order to distinguish the two cases, we refer to "malformed" packets and "invalid attributes".
「無効な属性」という用語は、この仕様では新しいものです。これは、属性の長さフィールドにより、パケットが「不正な形式」ではないものとして受け入れられることを意味すると定義されています。ただし、属性の「値」フィールドは、その属性に定義されたデータ型で必要な形式に従っていないため、属性は「不正な形式」です。 2つのケースを区別するために、「不正な」パケットと「無効な属性」を参照します。
For example, an implementation receives a packet that is well formed. That packet contains an Attribute allegedly of data type "address" but that has Length not equal to four. In that situation, the packet is well formed, but the Attribute is not. Therefore, it is an "invalid attribute".
たとえば、実装は整形式のパケットを受信します。そのパケットには、データタイプ「アドレス」の属性が含まれているが、長さが4に等しくありません。その状況では、パケットは整形式ですが、属性は整形式ではありません。したがって、「無効な属性」です。
A similar analysis can be performed when an attribute carries TLVs. The encapsulating attribute may be well formed, but the TLV may be an "invalid attribute". The existence of an "invalid attribute" in a packet or attribute MUST NOT result in the implementation discarding the entire packet or treating the packet as a negative acknowledgment. Instead, only the "invalid attribute" is treated specially.
属性にTLVが含まれる場合も、同様の分析を実行できます。カプセル化属性は正しい形式である可能性がありますが、TLVは「無効な属性」である可能性があります。パケットまたは属性に「無効な属性」が存在すると、実装がパケット全体を破棄したり、パケットを否定応答として処理したりしてはなりません（MUST NOT）。代わりに、「無効な属性」のみが特別に扱われます。
When an implementation receives an "invalid attribute", it SHOULD be silently discarded, except when the implementation is acting as a proxy (see Section 5.2 for discussion of proxy servers). If it is
実装が「無効な属性」を受け取った場合、その実装がプロキシとして機能している場合を除いて、暗黙的に破棄する必要があります（プロキシサーバーについては、セクション5.2を参照）。もしそれが
not discarded, it MUST NOT be handled in the same manner as a well-formed attribute. For example, receiving an Attribute of data type "address" containing either less than four octets or more than four octets of data means that the Attribute MUST NOT be treated as being of data type "address". The reason here is that if the Attribute does not carry an IPv4 address, the receiver has no idea what format the data is in, and it is therefore not an IPv4 address.
破棄されないため、整形式の属性と同じ方法で処理してはなりません（MUST NOT）。たとえば、4オクテット未満または4オクテットを超えるデータを含むデータタイプ「アドレス」の属性を受け取ると、その属性をデータタイプ「アドレス」として扱うことはできません。これは、属性にIPv4アドレスが含まれていない場合、受信者はデータの形式がわからないため、IPv4アドレスではないためです。
For Attributes of type "Long Extended Type", an Attribute is considered to be an "invalid attribute" when it does not match the criteria set out in Section 2.2, above.
タイプ「Long Extended Type」の属性の場合、上記のセクション2.2で設定された基準に一致しない属性は「無効な属性」と見なされます。
For Attributes of type "TLV", an Attribute is considered to be an "invalid attribute" when the TLV-Length field allows the encapsulating Attribute to be parsed but the TLV-Value field does not match the criteria for that TLV. Implementations SHOULD NOT treat the "invalid attribute" property as being transitive. That is, the Attribute encapsulating the "invalid attribute" SHOULD NOT be treated as an "invalid attribute". That encapsulating Attribute might contain multiple TLVs, only one of which is an "invalid attribute".
タイプ「TLV」の属性の場合、TLV-Lengthフィールドでカプセル化属性の解析が許可されているが、TLV-ValueフィールドがそのTLVの基準に一致しない場合、属性は「無効な属性」と見なされます。実装では、「無効な属性」プロパティを推移的として扱うべきではありません（SHOULD NOT）。つまり、「無効な属性」をカプセル化する属性は、「無効な属性」として扱われるべきではありません。そのカプセル化属性には複数のTLVが含まれる場合があり、そのうちの1つだけが「無効な属性」です。
However, a TLV definition may require particular sub-TLVs to be present and/or to have specific values. If a sub-TLV is missing or contains incorrect value(s), or if it is an "invalid attribute", then the encapsulating TLV SHOULD be treated as an "invalid attribute". This requirement ensures that strongly connected TLVs are either handled as a coherent whole or ignored entirely.
ただし、TLV定義では、特定のサブTLVが存在すること、および/または特定の値を持つことが必要な場合があります。サブTLVが欠落しているか、不正な値が含まれている場合、または「無効な属性」である場合、カプセル化TLVは「無効な属性」として扱われる必要があります（SHOULD）。この要件により、強く接続されたTLVが一貫した全体として処理されるか、完全に無視されることが保証されます。
It is RECOMMENDED that Attributes with unknown Type, Extended-Type, TLV-Type, or EVS-Type are treated as "invalid attributes". This recommendation is compatible with the suggestion in [RFC2865] Section 5 that implementations "MAY ignore Attributes with an unknown Type".
タイプ、拡張タイプ、TLVタイプ、またはEVSタイプが不明な属性は、「無効な属性」として扱われることをお勧めします。この推奨事項は、[RFC2865]セクション5の「不明なタイプの属性を無視してもよい」という提案と互換性があります。
We define four (4) attributes of "Extended Type", which are allocated from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. We also define two (2) attributes of "Long Extended Type", which are allocated from the "Reserved" Attribute Type codes of 245 and 246.
「拡張」タイプの4つの属性を定義します。これは、「予約済み」属性タイプコード241、242、243、および244から割り当てられます。「拡張タイプ」の2つの属性も定義します。 245および246の「予約済み」属性タイプコードから割り当てられます。
Type Name
---- ----
241 Extended-Type-1
242 Extended-Type-2
243 Extended-Type-3
244 Extended-Type-4
245 Long-Extended-Type-1
246 Long-Extended-Type-2
The rest of this section gives detailed definitions for each Attribute based on the above summary.
このセクションの残りの部分では、上記の要約に基づいて各属性の詳細な定義を示します。
Description
説明
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 241.{1-255}.
この属性は、241。{1-255}のRADIUS属性タイプスペースで、「拡張タイプ」形式の属性をカプセル化します。
A summary of the Extended-Type-1 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Type-1 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
241 for Extended-Type-1.
Extended-Type-1の場合は241。
Length
長さ
>= 4
＞＝ ４
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 241.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って、241。{1-255} RADIUS属性タイプスペースで指定されています。このフィールドの詳細な定義は、上記のセクション2.1で説明されています。
Value
値
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 242.{1-255}.
この属性は、242。{1-255}のRADIUS属性タイプスペースで、「拡張タイプ」形式の属性をカプセル化します。
A summary of the Extended-Type-2 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Type-2 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
242 for Extended-Type-2.
拡張タイプ2の場合は242。
Length
長さ
>= 4
＞＝ ４
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 242.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って、242。{1-255} RADIUS属性タイプスペースで指定されます。このフィールドの詳細な定義は、上記のセクション2.1で説明されています。
Value
値
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 243.{1-255}.
この属性は、「拡張タイプ」フォーマットの属性を243. {1-255}のRADIUS属性タイプスペースにカプセル化します。
A summary of the Extended-Type-3 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Type-3 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
243 for Extended-Type-3.
Extended-Type-3の場合は243。
Length
長さ
>= 4
＞＝ ４
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 243.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って、243。{1-255} RADIUS属性タイプスペースで指定されています。このフィールドの詳細な定義は、上記のセクション2.1で説明されています。
Value
値
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 244.{1-255}.
この属性は、244。{1-255}のRADIUS属性タイプスペースで、「拡張タイプ」形式の属性をカプセル化します。
A summary of the Extended-Type-4 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Type-4 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
244 for Extended-Type-4.
Extended-Type-4の場合は244。
Length
長さ
>= 4
＞＝ ４
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 244.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って、244。{1-255} RADIUS属性タイプスペースで指定されます。このフィールドの詳細な定義は、上記のセクション2.1で説明されています。
Value
値
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the Value Field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、値フィールドの解釈を決定する必要があります。
Description
説明
This attribute encapsulates attributes of the "Long Extended Type" format, in the RADIUS Attribute Type space of 245.{1-255}.
この属性は、「Long Extended Type」フォーマットの属性を、245。{1-255}のRADIUS Attribute Typeスペースにカプセル化します。
A summary of the Long-Extended-Type-1 Attribute format is shown below. The fields are transmitted from left to right.
Long-Extended-Type-1 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
245 for Long-Extended-Type-1
Long-Extended-Type-1の場合は245
Length
長さ
>= 5
＞＝ ５
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 245.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って、245。{1-255} RADIUS属性タイプスペースで指定されます。このフィールドの詳細な定義は、上記のセクション2.1で説明されています。
M (More)
M（もっと）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
Moreフィールドは長さが1ビットで、現在の属性に251オクテットを超えるデータが含まれているかどうかを示します。このフィールドの詳細な定義については、上記のセクション2.2を参照してください。
Reserved
予約済み
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
このフィールドは7ビット長で、将来の使用のために予約されています。実装は、パケットを送信するための属性をエンコードするときに、ゼロ（0）に設定する必要があります。内容は受信時に無視する必要があります。
Value
値
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute encapsulates attributes of the "Long Extended Type" format, in the RADIUS Attribute Type space of 246.{1-255}.
この属性は、246。{1-255}のRADIUS属性タイプスペースで、「Long Extended Type」形式の属性をカプセル化します。
A summary of the Long-Extended-Type-2 Attribute format is shown below. The fields are transmitted from left to right.
Long-Extended-Type-2 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
246 for Long-Extended-Type-2
Long-Extended-Type-2の場合は246
Length
長さ
>= 5
＞＝ ５
Extended-Type
拡張タイプ
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 246.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
Extended-Typeフィールドは1オクテットです。このフィールドの最新の値は、セクション10で説明されているポリシーとルールに従って、246。{1-255} RADIUS属性タイプスペースで指定されています。このフィールドの詳細な定義は、上記のセクション2.1で説明されています。
M (More)
M（もっと）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
Moreフィールドは長さが1ビットで、現在の属性に251オクテットを超えるデータが含まれているかどうかを示します。このフィールドの詳細な定義については、上記のセクション2.2を参照してください。
Reserved
予約済み
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
このフィールドは7ビット長で、将来の使用のために予約されています。実装は、パケットを送信するための属性をエンコードするときに、ゼロ（0）に設定する必要があります。内容は受信時に無視する必要があります。
Value
値
The "Value" field is one or more octets.
「値」フィールドは1つ以上のオクテットです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
We define six new attributes that can carry vendor-specific information. We define four (4) attributes of the "Extended Type" format, with Type codes (241.26, 242.26, 243.26, 244.26), using the "evs" data type. We also define two (2) attributes using "Long Extended Type" format, with Type codes (245.26, 246.26), which are of the "evs" data type.
ベンダー固有の情報を伝えることができる6つの新しい属性を定義します。 「evs」データタイプを使用して、タイプコード（241.26、242.26、243.26、244.26）で「拡張タイプ」フォーマットの4つの属性を定義します。また、「Long Extended Type」フォーマットを使用して、タイプコード（245.26、246.26）の2つの属性を定義します。これらは「evs」データタイプです。
Type.Extended-Type Name
------------------ ----
241.26 Extended-Vendor-Specific-1
242.26 Extended-Vendor-Specific-2
243.26 Extended-Vendor-Specific-3
244.26 Extended-Vendor-Specific-4
245.26 Extended-Vendor-Specific-5
246.26 Extended-Vendor-Specific-6
The rest of this section gives detailed definitions for each Attribute based on the above summary.
このセクションの残りの部分では、上記の要約に基づいて各属性の詳細な定義を示します。
Description
説明
This attribute defines a RADIUS Type Code of 241.26, using the "evs" data type.
この属性は、「evs」データタイプを使用して、RADIUSタイプコード241.26を定義します。
A summary of the Extended-Vendor-Specific-1 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Vendor-Specific-1 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
241.26 for Extended-Vendor-Specific-1
Extended-Vendor-Specific-1の場合は241.26
Length
長さ
>= 9
＞＝ ９
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
Vendor-Type
ベンダータイプ
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
Vendor-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
Value
値
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
「値」フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
The length of the "Value" field is eight (8) less than the value of the Length field.
「値」フィールドの長さは、長さフィールドの値よりも8短いです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type.Vendor-Id.Vendor-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute defines a RADIUS Type Code of 242.26, using the "evs" data type.
この属性は、「evs」データタイプを使用して、RADIUSタイプコード242.26を定義します。
A summary of the Extended-Vendor-Specific-2 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Vendor-Specific-2 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
242.26 for Extended-Vendor-Specific-2
Extended-Vendor-Specific-2の242.26
Length
長さ
>= 9
＞＝ ９
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
Vendor-Type
ベンダータイプ
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
Vendor-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
Value
値
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
「値」フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
The length of the "Value" field is eight (8) less than the value of the Length field.
「値」フィールドの長さは、長さフィールドの値よりも8短いです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type.Vendor-Id.Vendor-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute defines a RADIUS Type Code of 243.26, using the "evs" data type.
この属性は、「evs」データタイプを使用して、RADIUSタイプコード243.26を定義します。
A summary of the Extended-Vendor-Specific-3 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Vendor-Specific-3 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
243.26 for Extended-Vendor-Specific-3
243.26（Extended-Vendor-Specific-3）
Length
長さ
>= 9
＞＝ ９
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
Vendor-Type
ベンダータイプ
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
Vendor-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
Value
値
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
「値」フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
The length of the "Value" field is eight (8) less than the value of the Length field.
「値」フィールドの長さは、長さフィールドの値よりも8短いです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type.Vendor-Id.Vendor-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute defines a RADIUS Type Code of 244.26, using the "evs" data type.
この属性は、「evs」データタイプを使用して、RADIUSタイプコード244.26を定義します。
A summary of the Extended-Vendor-Specific-4 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Vendor-Specific-4 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
244.26 for Extended-Vendor-Specific-4
244.26（Extended-Vendor-Specific-4）
Length
長さ
>= 9
＞＝ ９
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
Vendor-Type
ベンダータイプ
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
Vendor-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
Value
値
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
「値」フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
The length of the "Value" field is eight (8) less than the value of the Length field.
「値」フィールドの長さは、長さフィールドの値よりも8短いです。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type.Vendor-Id.Vendor-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute defines a RADIUS Type Code of 245.26, using the "evs" data type.
この属性は、「evs」データタイプを使用して、245.26のRADIUSタイプコードを定義します。
A summary of the Extended-Vendor-Specific-5 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Vendor-Specific-5 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
245.26 for Extended-Vendor-Specific-5
拡張ベンダー固有5の場合は245.26
Length
長さ
>= 10 (first fragment)
>= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the first Attribute contains the Vendor-Id and Vendor-Type fields. Subsequent Attributes contain fragments of the "Value" field only.
VSAが複数の属性にまたがってフラグメント化されている場合、最初の属性のみにVendor-IdおよびVendor-Typeフィールドが含まれます。後続の属性には、「値」フィールドのフラグメントのみが含まれます。
M (More)
M（もっと）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
Moreフィールドは長さが1ビットで、現在の属性に251オクテットを超えるデータが含まれているかどうかを示します。このフィールドの詳細な定義については、上記のセクション2.2を参照してください。
Reserved
予約済み
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
このフィールドは7ビット長で、将来の使用のために予約されています。実装は、パケットを送信するための属性をエンコードするときに、ゼロ（0）に設定する必要があります。内容は受信時に無視する必要があります。
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
Vendor-Type
ベンダータイプ
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
Vendor-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
Value
値
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
「値」フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type.Vendor-Id.Vendor-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
Description
説明
This attribute defines a RADIUS Type Code of 246.26, using the "evs" data type.
この属性は、「evs」データタイプを使用して、246.26のRADIUSタイプコードを定義します。
A summary of the Extended-Vendor-Specific-6 Attribute format is shown below. The fields are transmitted from left to right.
Extended-Vendor-Specific-6 Attribute形式の要約を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
246.26 for Extended-Vendor-Specific-6
拡張ベンダー固有6の246.26
Length
長さ
>= 10 (first fragment)
>= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the first Attribute contains the Vendor-Id and Vendor-Type fields. Subsequent Attributes contain fragments of the "Value" field only.
VSAが複数の属性にまたがってフラグメント化されている場合、最初の属性のみにVendor-IdおよびVendor-Typeフィールドが含まれます。後続の属性には、「値」フィールドのフラグメントのみが含まれます。
M (More)
M（もっと）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
Moreフィールドは長さが1ビットで、現在の属性に251オクテットを超えるデータが含まれているかどうかを示します。このフィールドの詳細な定義については、上記のセクション2.2を参照してください。
Reserved
予約済み
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
このフィールドは7ビット長で、将来の使用のために予約されています。実装は、パケットを送信するための属性をエンコードするときに、ゼロ（0）に設定する必要があります。内容は受信時に無視する必要があります。
Vendor-Id
ベンダーID
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Idフィールドの4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。
Vendor-Type
ベンダータイプ
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
Vendor-Typeフィールドは1オクテットです。値はベンダーの独自の裁量で割り当てられます。
Value
値
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
「値」フィールドは1つ以上のオクテットです。情報の実際の形式はサイトまたはアプリケーションに固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
この仕様をサポートする実装は、「Type.Extended-Type.Vendor-Id.Vendor-Type」の識別子を使用して、「Value」フィールドの解釈を決定する必要があります。
There are a number of potential compatibility issues with traditional RADIUS, as defined in [RFC6158] and earlier. This section describes them.
[RFC6158]以前で定義されているように、従来のRADIUSには潜在的な互換性の問題がいくつかあります。このセクションでは、それらについて説明します。
Some vendors have used Attribute Type codes from the "Reserved" space as part of vendor-defined dictionaries. This practice is considered antisocial behavior, as noted in [RFC6158]. These vendor definitions conflict with the Attributes in the RADIUS Attribute Type space. The conflicting definitions may make it difficult for implementations to support both those Vendor Attributes, and the new Extended Attribute formats.
一部のベンダーは、ベンダー定義の辞書の一部として「予約済み」スペースの属性タイプコードを使用しています。 [RFC6158]に記載されているように、この習慣は反社会的行動と見なされます。これらのベンダー定義は、RADIUS Attribute Typeスペースの属性と競合します。矛盾する定義により、実装がこれらのベンダー属性と新しい拡張属性形式の両方をサポートすることが困難になる場合があります。
We RECOMMEND that RADIUS client and server implementations delete all references to these improperly defined attributes. Failing that, we RECOMMEND that RADIUS server implementations have a per-client configurable flag that indicates which type of attributes are being sent from the client. If the flag is set to "Non-Standard Attributes", the conflicting attributes can be interpreted as being improperly defined Vendor-Specific Attributes. If the flag is set to
RADIUSクライアントとサーバーの実装では、これらの不適切に定義された属性への参照をすべて削除することをお勧めします。それができない場合は、RADIUSサーバーの実装に、クライアントから送信される属性のタイプを示すクライアントごとの構成可能なフラグがあることをお勧めします。フラグが「非標準属性」に設定されている場合、競合する属性は、不適切に定義されたベンダー固有属性であると解釈される可能性があります。フラグがに設定されている場合
"IETF Attributes", the Attributes MUST be interpreted as being of the Extended Attributes format. The default SHOULD be to interpret the Attributes as being of the Extended Attributes format.
「IETF属性」、属性は拡張属性形式であると解釈されなければなりません。デフォルトは、属性を拡張属性形式であると解釈する必要があります（SHOULD）。
Other methods of determining how to decode the Attributes into a "correct" form are NOT RECOMMENDED. Those methods are likely to be fragile and prone to error.
属性を「正しい」形式にデコードする方法を決定する他の方法は推奨されません。これらのメソッドは壊れやすく、エラーが発生しやすい傾向があります。
We RECOMMEND that RADIUS server implementations reuse the above flag to determine which types of attributes to send in a reply message. If the request is expected to contain the improperly defined attributes, the reply SHOULD NOT contain Extended Attributes. If the request is expected to contain Extended Attributes, the reply MUST NOT contain the improper Attributes.
RADIUSサーバーの実装では、上記のフラグを再利用して、応答メッセージで送信する属性のタイプを決定することをお勧めします。リクエストに不適切に定義された属性が含まれることが予想される場合、応答には拡張属性が含まれてはいけません（SHOULD NOT）。リクエストに拡張属性が含まれることが予想される場合、応答に不適切な属性を含めてはなりません（MUST NOT）。
RADIUS clients will have fewer issues than servers. Clients MUST NOT send improperly defined Attributes in a request. For replies, clients MUST interpret attributes as being of the Extended Attributes format, instead of the improper definitions. These requirements impose no change in the RADIUS specifications, as such usage by vendors has always been in conflict with the standard requirements and the standards process.
RADIUSクライアントはサーバーよりも問題が少ないでしょう。クライアントは、リクエストで不適切に定義された属性を送信してはいけません。返信の場合、クライアントは、属性を不適切な定義ではなく、拡張属性形式であると解釈する必要があります。これらの要件は、RADIUS仕様に変更を課しません。ベンダーによるそのような使用法は、常に標準要件および標準プロセスと矛盾していたためです。
Existing clients that send these improperly defined attributes usually have a configuration setting that can disable this behavior. We RECOMMEND that vendors ship products with the default set to "disabled". We RECOMMEND that administrators set this flag to "disabled" on all equipment that they manage.
これらの不適切に定義された属性を送信する既存のクライアントには、通常、この動作を無効にできる構成設定があります。ベンダーは、デフォルトが「無効」に設定された製品を出荷することをお勧めします。管理者が管理するすべての機器でこのフラグを「無効」に設定することをお勧めします。
RADIUS proxy servers will need to forward Attributes having the new format, even if they do not implement support for the encoding and decoding of those attributes. We remind implementers of the following text in [RFC2865] Section 2.3:
RADIUSプロキシサーバーは、属性のエンコードとデコードのサポートを実装していない場合でも、新しい形式の属性を転送する必要があります。 [RFC2865]セクション2.3の次のテキストを実装者に思い出させます。
The forwarding server MUST NOT change the order of any attributes of the same type, including Proxy-State.
転送サーバーは、Proxy-Stateを含め、同じタイプの属性の順序を変更してはなりません（MUST NOT）。
This requirement solves some of the issues related to proxying of the new format, but not all. The reason is that proxy servers are permitted to examine the contents of the packets that they forward. Many proxy implementations not only examine the Attributes, but they refuse to forward attributes that they do not understand (i.e., attributes for which they have no local dictionary definitions).
この要件は、新しいフォーマットのプロキシに関連する問題の一部を解決しますが、すべてを解決するわけではありません。その理由は、プロキシサーバーが転送するパケットの内容を検査することが許可されているためです。多くのプロキシ実装は属性を調べるだけでなく、理解できない属性（つまり、ローカルディクショナリ定義がない属性）の転送を拒否します。
This practice is NOT RECOMMENDED. Proxy servers SHOULD forward attributes, even attributes that they do not understand or that are not in a local dictionary. When forwarded, these attributes SHOULD be sent verbatim, with no modifications or changes. This requirement includes "invalid attributes", as there may be some other system in the network that understands them.
この方法はお勧めしません。プロキシサーバーは、属性を理解する必要があるか、ローカルディクショナリにない属性であっても転送する必要があります（SHOULD）。転送されるとき、これらの属性は修正または変更なしで逐語的に送信されるべきです（SHOULD）。この要件には、「無効な属性」が含まれています。これは、ネットワーク内にそれらを理解する他のシステムが存在する可能性があるためです。
The only exception to this recommendation is when local site policy dictates that filtering of attributes has to occur. For example, a filter at a visited network may require removal of certain authorization rules that apply to the home network but not to the visited network. This filtering can sometimes be done even when the contents of the Attributes are unknown, such as when all Vendor-Specific Attributes are designated for removal.
この推奨事項の唯一の例外は、ローカルサイトのポリシーで属性のフィルタリングを行う必要があると定められている場合です。たとえば、訪問先ネットワークのフィルタでは、訪問先ネットワークではなくホームネットワークに適用される特定の承認ルールを削除する必要がある場合があります。このフィルタリングは、すべてのベンダー固有属性が削除対象として指定されている場合など、属性の内容が不明な場合でも実行できることがあります。
As seen during testing performed in 2010 via the EDUcation ROAMing (EDUROAM) service (A. DeKok, unpublished data), many proxies do not follow these practices for unknown Attributes. Some proxies filter out unknown attributes or attributes that have unexpected lengths (24%, 17/70), some truncate the Attributes to the "expected" length (11%, 8/70), some discard the request entirely (1%, 1/70), and the rest (63%, 44/70) follow the recommended practice of passing the Attributes verbatim. It will be difficult to widely use the Extended Attributes format until all non-conformant proxies are fixed. We therefore RECOMMEND that all proxies that do not support the Extended Attributes (241 through 246) define them as being of data type "string" and delete all other local definitions for those attributes.
EDUcation ROAMing（EDUROAM）サービス（A. DeKok、非公開データ）を介して2010年に実行されたテスト中に見られるように、多くのプロキシは未知の属性に対してこれらのプラクティスに従っていません。一部のプロキシは不明な属性または予期しない長さ（24％、17/70）を持つ属性を除外し、一部は属性を「予期された」長さに切り捨て（11％、8/70）、一部は要求を完全に破棄します（1％、1 / 70）、および残り（63％、44/70）は、属性を逐語的に渡すという推奨される慣例に従います。すべての非準拠プロキシが修正されるまで、拡張属性形式を広く使用することは困難です。したがって、拡張属性（241から246）をサポートしないすべてのプロキシは、それらをデータ型「文字列」として定義し、それらの属性の他のすべてのローカル定義を削除することをお勧めします。
This last change should enable wider usage of the Extended Attributes format.
This last change should enable wider usage of the Extended Attributes format.
This specification proposes a number of changes to RADIUS and therefore requires a set of guidelines, as has been done in [RFC6158]. These guidelines include suggestions related to design, interaction with IANA, usage, and implementation of attributes using the new formats.
[RFC6158]で行われているように、この仕様はRADIUSにいくつかの変更を提案しているため、一連のガイドラインが必要です。これらのガイドラインには、設計、IANAとの相互作用、使用法、および新しい形式を使用した属性の実装に関する提案が含まれています。
This specification updates [RFC6158] by adding the data types "evs", "tlv", and "integer64"; defining them to be "basic" data types; and permitting their use subject to the restrictions outlined below.
This specification updates [RFC6158] by adding the data types "evs", "tlv", and "integer64"; defining them to be "basic" data types; and permitting their use subject to the restrictions outlined below.
The recommendations for the use of the new data types and Attribute formats are given below.
新しいデータ型と属性形式の使用に関する推奨事項を以下に示します。
[RFC6158] Section A.2.1 says in part:
[RFC6158]セクションA.2.1は部分的に言っています：
* Unsigned integers of size other than 32 bits. SHOULD be replaced by an unsigned integer of 32 bits. There is insufficient justification to define a new size of integer.
* 32ビット以外のサイズの符号なし整数。 32ビットの符号なし整数で置き換える必要があります（SHOULD）。整数の新しいサイズを定義するための十分な正当化がありません。
We update that specification to permit unsigned integers of 64 bits, for the reasons defined above in Section 2.5. The updated text is as follows:
セクション2.5で定義した理由により、64ビットの符号なし整数を許可するようにその仕様を更新します。更新されたテキストは次のとおりです。
* Unsigned integers of size other than 32 or 64 bits. SHOULD be replaced by an unsigned integer of 32 or 64 bits. There is insufficient justification to define a new size of integer.
* 32ビットまたは64ビット以外のサイズの符号なし整数。 32ビットまたは64ビットの符号なし整数で置き換える必要があります（SHOULD）。整数の新しいサイズを定義するための十分な正当化がありません。
That section later continues with the following list item:
そのセクションは後で、次のリスト項目に続きます。
* Nested attribute-value pairs (AVPs). Attributes should be defined in a flat typespace.
* ネストされた属性と値のペア（AVP）。属性はフラットタイプスペースで定義する必要があります。
We update that specification to permit nested TLVs, as defined in this document:
このドキュメントで定義されているように、ネストされたTLVを許可するようにその仕様を更新します。
* Nested attribute-value pairs (AVPs) using the extended Attribute format MAY be used. All other nested AVP or TLV formats MUST NOT be used.
* 拡張属性フォーマットを使用するネストされた属性値ペア（AVP）を使用してもよい（MAY）。他のすべてのネストされたAVPまたはTLV形式は使用してはなりません（MUST NOT）。
The [RFC6158] recommendations for "basic" data types apply to the three types listed above. All other recommendations given in [RFC6158] for "basic" data types remain unchanged.
「基本」データ型に関する[RFC6158]の推奨事項は、上記の3つの型に適用されます。 [基本]データ型について[RFC6158]で提供されている他のすべての推奨事項は変更されていません。
[RFC6158] Section 2.1 says:
[RFC6158]セクション2.1は言う：
Complex data types MAY be used in situations where they reduce complexity in non-RADIUS systems or where using the basic data types would be awkward (such as where grouping would be required in order to link related attributes).
複雑なデータタイプは、RADIUS以外のシステムの複雑さを軽減する状況や、基本的なデータタイプを使用することが厄介な状況（関連する属性をリンクするためにグループ化が必要になる場合など）で使用できます（MAY）。
Since the extended Attribute format allows for grouping of complex types via TLVs, the guidelines for complex data types need to be updated as follows:
Since the extended Attribute format allows for grouping of complex types via TLVs, the guidelines for complex data types need to be updated as follows:
[RFC6158], Section 3.2.4, describes situations in which complex data types might be appropriate. They SHOULD NOT be used even in those situations, without careful consideration of the described limitations. In all other cases not covered by the complex data type exceptions, complex data types MUST NOT be used. Instead, complex data types MUST be decomposed into TLVs.
[RFC6158]のセクション3.2.4では、複雑なデータ型が適切である可能性がある状況について説明しています。記述された制限を注意深く考慮せずに、それらの状況でも使用しないでください。複合データ型の例外でカバーされていない他のすべてのケースでは、複合データ型を使用してはなりません（MUST NOT）。代わりに、複雑なデータ型をTLVに分解する必要があります。
The checklist in [RFC6158] Appendix A.2.2 is similarly updated to add a new requirement at the top of that section, as follows:
[RFC6158]付録A.2.2のチェックリストも同様に更新され、次のようにそのセクションの上部に新しい要件が追加されます。
Does the Attribute
属性はありますか
* define a complex type that can be represented via TLVs?
* TLVで表現できる複合型を定義しますか？
If so, this data type MUST be represented via TLVs.
その場合、このデータ型はTLVを介して表現する必要があります。
Note that this requirement does not override [RFC6158] Appendix A.1, which permits the transport of complex types in certain situations.
この要件は、[RFC6158]付録A.1を上書きしないことに注意してください。これにより、特定の状況で複合型の転送が許可されます。
All other recommendations given in [RFC6158] for "complex" data types remain unchanged.
[RFC6158]で「複雑な」データ型について与えられた他のすべての推奨事項は変更されていません。
This section gives design guidelines for specifications defining attributes using the new format. The items listed below are not exhaustive. As experience is gained with the new formats, later specifications may define additional guidelines.
このセクションでは、新しい形式を使用して属性を定義する仕様の設計ガイドラインを示します。以下の項目はすべてを網羅しているわけではありません。新しい形式で経験を積むにつれて、後の仕様で追加のガイドラインが定義される場合があります。
* The data type "evs" MUST NOT be used for standard RADIUS Attributes, or for TLVs, or for VSAs.
* データタイプ「evs」は、標準のRADIUS属性、TLV、またはVSAに使用してはなりません。
* The data type TLV SHOULD NOT be used for standard RADIUS attributes.
* The data type TLV SHOULD NOT be used for standard RADIUS attributes.
* [RFC2866] "tagged" attributes MUST NOT be defined in the Extended-Type space. The "tlv" data type should be used instead to group attributes.
* [RFC2866] "tagged" attributes MUST NOT be defined in the Extended-Type space. The "tlv" data type should be used instead to group attributes.
* The "integer64" data type MAY be used in any RADIUS attribute. The use of 64-bit integers was not recommended in [RFC6158], but their utility is now evident.
* 「integer64」データタイプは、任意のRADIUS属性で使用できます。 [RFC6158]では64ビット整数の使用は推奨されていませんでしたが、その実用性は明白です。
* Any attribute that is allocated from the long extended space of data type "text", "string", or "tlv" can potentially carry more than 251 octets of data. Specifications defining such attributes SHOULD define a maximum length to guide implementations.
* データタイプ「テキスト」、「文字列」、または「tlv」の長い拡張スペースから割り当てられる属性は、潜在的に251オクテットを超えるデータを運ぶことができます。そのような属性を定義する仕様は、実装をガイドする最大長を定義する必要があります。
All other recommendations given in [RFC6158] for attribute design guidelines apply to attributes using the short extended space and long extended space.
[RFC6158]で属性設計ガイドラインとして提供されている他のすべての推奨事項は、短い拡張スペースと長い拡張スペースを使用する属性に適用されます。
The following items give design guidelines for specifications using TLVs.
次の項目は、TLVを使用する仕様の設計ガイドラインを示しています。
* When multiple Attributes are intended to be grouped or managed together, the use of TLVs to group related attributes is RECOMMENDED.
* 複数の属性を一緒にグループ化または管理することを意図している場合、TLVを使用して関連する属性をグループ化することをお勧めします。
* More than 4 layers (depth) of TLV nesting is NOT RECOMMENDED.
* 4層（深さ）を超えるTLVネストは推奨されません。
* Interpretation of an attribute depends only on its type definition (e.g., Type.Extended-Type.TLV-Type) and not on its encoding or location in the RADIUS packet.
* 属性の解釈は、そのタイプ定義（Type.Extended-Type.TLV-Typeなど）にのみ依存し、RADIUSパケット内のエンコーディングや場所には依存しません。
* Where a group of TLVs is strictly defined, and not expected to change, and totals less than 247 octets of data, the specifications SHOULD request allocation from the short extended space.
* TLVのグループが厳密に定義されており、変更されることが予期されておらず、データの合計が247オクテット未満の場合、仕様は、短い拡張スペースからの割り当てを要求する必要があります（SHOULD）。
* Where a group of TLVs is loosely defined or is expected to change, the specifications SHOULD request allocation from the long extended space.
* TLVのグループが大まかに定義されているか、変更が予想される場合、仕様は長い拡張スペースからの割り当てを要求する必要があります（SHOULD）。
All other recommendations given in [RFC6158] for attribute design guidelines apply to attributes using the TLV format.
[RFC6158]で指定されている属性設計ガイドラインに関する他のすべての推奨事項は、TLV形式を使用する属性に適用されます。
The following items give guidelines for allocation requests made in a RADIUS specification.
次の項目は、RADIUS仕様で行われる割り当て要求のガイドラインを示しています。
* Discretion is recommended when requesting allocation of attributes. The new space is much larger than the old one, but it is not infinite.
* Discretion is recommended when requesting allocation of attributes. The new space is much larger than the old one, but it is not infinite.
* Specifications that allocate many attributes MUST NOT request that allocation be made from the standard space. That space is under allocation pressure, and the extended space is more suitable for large allocations. As a guideline, we suggest that one specification allocating twenty percent (20%) or more of the standard space would meet the above criteria.
* Specifications that allocate many attributes MUST NOT request that allocation be made from the standard space. That space is under allocation pressure, and the extended space is more suitable for large allocations. As a guideline, we suggest that one specification allocating twenty percent (20%) or more of the standard space would meet the above criteria.
* Specifications that allocate many related attributes SHOULD define one or more TLVs to contain related attributes.
* 多くの関連属性を割り当てる仕様では、1つ以上のTLVを定義して、関連属性を含める必要があります（SHOULD）。
* Specifications SHOULD request allocation from a specific space. The IANA considerations given in Section 10, below, give instructions to IANA, but authors should assist IANA where possible.
* 仕様は、特定のスペースからの割り当てを要求する必要があります。以下のセクション10に記載されているIANAの考慮事項は、IANAに指示を与えていますが、著者は可能な限りIANAを支援する必要があります。
* Specifications of an attribute that encodes 252 octets or less of data MAY request allocation from the short extended space.
* 252オクテット以下のデータをエンコードする属性の仕様は、短い拡張スペースからの割り当てを要求する場合があります。
* Specifications of an attribute that always encode less than 253 octets of data MUST NOT request allocation from the long extended space. The standard space or the short extended space MUST be used instead.
* Specifications of an attribute that always encode less than 253 octets of data MUST NOT request allocation from the long extended space. The standard space or the short extended space MUST be used instead.
* Specifications of an attribute that encodes 253 octets or more of data MUST request allocation from the long extended space.
* 253オクテット以上のデータをエンコードする属性の仕様は、長い拡張スペースからの割り当てを要求する必要があります。
* When the extended space is nearing exhaustion, a new specification will have to be written that requests allocation of one or more RADIUS attributes from the "Reserved" portion of the standard space, values 247-255, using an appropriate format ("Short Extended Type", or "Long Extended Type").
* 拡張スペースが使い果たされそうになると、適切なフォーマット（ "Short Extended Type"を使用して、標準スペースの "予約"部分の値247-255から1つまたは複数のRADIUS属性の割り当てを要求する新しい仕様を作成する必要があります。 "、または" Long Extended Type "）。
An allocation request made in a specification SHOULD use one of the following formats when allocating an attribute type code:
仕様で作成された割り当て要求は、属性タイプコードを割り当てるときに、次のいずれかの形式を使用する必要があります。
* TBDn - request allocation of an attribute from the standard space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* TBDn-標準スペースからの属性の割り当てを要求します。割り当てられる個々の属性を追跡するには、値「n」を1以上にする必要があります。
* SHORT-TBDn - request allocation of an attribute from the short extended space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* SHORT-TBDn - request allocation of an attribute from the short extended space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* LONG-TBDn - request allocation of an attribute from the long extended space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* LONG-TBDn-長い拡張スペースからの属性の割り当てを要求します。割り当てられる個々の属性を追跡するには、値「n」を1以上にする必要があります。
These guidelines should help specification authors and IANA communicate effectively and clearly.
These guidelines should help specification authors and IANA communicate effectively and clearly.
Specifications may allocate a new attribute of type TLV and at the same time allocate sub-Attributes within that TLV. These specifications SHOULD request allocation of specific values for the sub-TLV. The "dotted number" notation MUST be used.
仕様では、タイプTLVの新しい属性を割り当てると同時に、そのTLV内にサブ属性を割り当てることができます。これらの仕様は、サブTLVの特定の値の割り当てを要求する必要があります（SHOULD）。 「ドット番号」表記を使用する必要があります。
For example, a specification may request allocation of a TLV as SHORT-TBD1. Within that attribute, it could request allocation of three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3.
たとえば、仕様では、TLVの割り当てをSHORT-TBD1として要求する場合があります。その属性内で、SHORT-TBD1.1、SHORT-TBD1.2、およびSHORT-TBD1.3の3つのサブTLVの割り当てを要求できます。
Specifications may request allocation of additional sub-TLVs within an existing attribute of type TLV. Those specifications SHOULD use the "TBDn" format for every entry in the "dotted number" notation.
Specifications may request allocation of additional sub-TLVs within an existing attribute of type TLV. Those specifications SHOULD use the "TBDn" format for every entry in the "dotted number" notation.
For example, a specification may request allocation within an existing TLV, with "dotted number" notation MM.NN. Within that attribute, the specification could request allocation of three sub-TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3.
For example, a specification may request allocation within an existing TLV, with "dotted number" notation MM.NN. Within that attribute, the specification could request allocation of three sub-TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3.
* RADIUS client implementations SHOULD support this specification in order to permit the easy deployment of specifications using the changes defined herein.
* RADIUSクライアントの実装は、ここで定義された変更を使用して仕様を簡単に展開できるようにするために、この仕様をサポートする必要があります（SHOULD）。
* RADIUS server implementations SHOULD support this specification in order to permit the easy deployment of specifications using the changes defined herein.
* RADIUSサーバーの実装は、ここで定義された変更を使用して仕様を簡単に展開できるように、この仕様をサポートする必要があります（SHOULD）。
* RADIUS proxy servers MUST follow the specifications in Section 5.2.
* RADIUS proxy servers MUST follow the specifications in Section 5.2.
* Vendors SHOULD use the existing Vendor-Specific Attribute Type space in preference to the new Extended-Vendor-Specific Attributes, as this specification may take time to become widely deployed.
* Vendors SHOULD use the existing Vendor-Specific Attribute Type space in preference to the new Extended-Vendor-Specific Attributes, as this specification may take time to become widely deployed.
* Vendors SHOULD implement this specification. The changes to RADIUS are relatively small and are likely to quickly be used in new specifications.
* ベンダーはこの仕様を実装する必要があります（SHOULD）。 RADIUSへの変更は比較的小さく、新しい仕様ですぐに使用される可能性があります。
The path to extending the RADIUS protocol has been long and arduous. A number of proposals have been made and discarded by the RADEXT working group. These proposals have been judged to be either too bulky, too complex, too simple, or unworkable in practice. We do not otherwise explain here why earlier proposals did not obtain working group consensus.
RADIUSプロトコルを拡張する方法は長く困難でした。 RADEXTワーキンググループによって、多くの提案がなされ、破棄されています。これらの提案は、かさばる、複雑すぎる、単純すぎる、または実際には機能しないと判断されています。以前の提案ではワーキンググループの合意が得られなかった理由をここでは説明しません。
The changes outlined here have the benefit of being simple, as the "Extended Type" format requires only a one-octet change to the Attribute format. The downside is that the "Long Extended Type" format is awkward, and the 7 Reserved bits will likely never be used for anything.
The changes outlined here have the benefit of being simple, as the "Extended Type" format requires only a one-octet change to the Attribute format. The downside is that the "Long Extended Type" format is awkward, and the 7 Reserved bits will likely never be used for anything.
An audit of almost five thousand publicly available attributes [ATTR] (2010) shows the statistics summarized below. The Attributes include over 100 Vendor dictionaries, along with the IANA-assigned attributes:
一般に入手可能な約5000の属性の監査[ATTR]（2010）は、以下に要約されている統計を示しています。属性には、IANAによって割り当てられた属性とともに、100を超えるベンダー辞書が含まれます。
Count Data Type
----- ---------
2257 integer
1762 text
273 IPv4 Address
225 string
96 other data types
35 IPv6 Address
18 date
10 integer64
4 Interface Id
3 IPv6 Prefix
4683 Total
4683合計
The entries in the "Data Type" column are data types recommended by [RFC6158], along with "integer64". The "other data types" row encompasses all other data types, including complex data types and data types transporting opaque data.
「データタイプ」列のエントリーは、「integer64」とともに、[RFC6158]が推奨するデータタイプです。 「その他のデータタイプ」行には、複雑なデータタイプや不透明なデータを転送するデータタイプなど、その他すべてのデータタイプが含まれます。
We see that over half of the Attributes encode less than 16 octets of data. It is therefore important to have an extension mechanism that adds as little as possible to the size of these attributes. Another result is that the overwhelming majority of attributes use simple data types.
属性の半分以上が16オクテット未満のデータをエンコードしていることがわかります。したがって、これらの属性のサイズにできるだけ追加しない拡張メカニズムを持つことが重要です。もう1つの結果は、圧倒的多数の属性が単純なデータ型を使用することです。
Of the Attributes defined above, 177 were declared as being inside of a TLV. This is approximately 4% of the total. We did not investigate whether additional attributes were defined in a flat namespace but could have been defined as being inside of a TLV. We expect that the number could be as high as 10% of attributes.
上記で定義された属性のうち、177はTLV内にあると宣言されました。これは全体の約4％です。追加の属性がフラットな名前空間で定義されているかどうかは調査しませんでしたが、TLV内にあると定義できた可能性があります。この数は、属性の10％にもなると予想されます。
Manual inspection of the dictionaries shows that approximately 20 (or 0.5%) attributes have the ability to transport more than 253 octets of data. These attributes are divided between VSAs and a small number of standard Attributes such as EAP-Message.
辞書を手動で検査すると、約20（または0.5％）の属性が253オクテットを超えるデータを転送できることがわかります。これらの属性は、VSAとEAP-Messageなどの少数の標準属性の間で分割されます。
The results of this audit and analysis are reflected in the design of the extended attributes. The extended format has minimal overhead, permits TLVs, and has support for "long" attributes.
この監査と分析の結果は、拡張属性の設計に反映されます。拡張形式はオーバーヘッドが最小限で、TLVを許可し、「長い」属性をサポートしています。
The Attribute formats defined in this specification need to be transported in Diameter. While Diameter supports attributes longer than 253 octets and grouped attributes, we do not use that functionality here. Instead, we define the simplest possible encapsulation method.
この仕様で定義されている属性形式は、Diameterで転送する必要があります。 Diameterは253オクテットより長い属性とグループ化された属性をサポートしますが、ここではその機能を使用しません。代わりに、最も簡単なカプセル化方法を定義します。
The new formats MUST be treated the same as traditional RADIUS attributes when converting from RADIUS to Diameter, or vice versa. That is, the new attribute space is not converted to any "extended" Diameter attribute space. Fragmented attributes are not converted to a single long Diameter attribute. The new EVS data types are not converted to Diameter attributes with the "V" bit set.
新しい形式は、RADIUSからDiameterに、またはその逆に変換するときに、従来のRADIUS属性と同じように扱われる必要があります。つまり、新しい属性スペースは、「拡張された」Diameter属性スペースに変換されません。断片化された属性は、単一の長いDiameter属性に変換されません。新しいEVSデータ型は、「V」ビットが設定されたDiameter属性に変換されません。
In short, this document mandates no changes for existing RADIUS-to-Diameter or Diameter-to-RADIUS gateways.
つまり、このドキュメントでは、既存のRADIUS-to-DiameterまたはDiameter-to-RADIUSゲートウェイの変更を義務付けていません。
A few examples are presented here in order to illustrate the encoding of the new Attribute formats. These examples are not intended to be exhaustive, as many others are possible. For simplicity, we do not show complete packets, but only attributes.
ここでは、新しい属性フォーマットのエンコーディングを説明するために、いくつかの例を示します。他の多くの例が可能であるため、これらの例はすべてを網羅することを意図したものではありません。簡単にするために、完全なパケットではなく、属性のみを示しています。
The examples are given using a domain-specific language implemented by the program given in Appendix A of this document. The language is line oriented and composed of a sequence of lines matching the ABNF grammar ([RFC5234]) given below:
例は、このドキュメントの付録Aに示されているプログラムによって実装されるドメイン固有の言語を使用して示されています。言語は行指向であり、以下に示すABNF文法（[RFC5234]）に一致する一連の行で構成されています。
Identifier = 1*DIGIT *( "." 1*DIGIT )
HEXCHAR = HEXDIG HEXDIG
STRING = DQUOTE 1*CHAR DQUOTE
STRING = DQUOTE 1 * CHAR DQUOTE
TLV = "{" SP 1*DIGIT SP DATA SP "}"
DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING
LINE = Identifier SP DATA
The program has additional restrictions on its input that are not reflected in the above grammar. For example, the portions of the identifier that refer to Type and Extended-Type are limited to values between 1 and 255. We trust that the source code in Appendix A is clear and that these restrictions do not negatively affect the comprehensibility of the examples.
プログラムには、上記の文法に反映されていない追加の入力制限があります。たとえば、TypeとExtended-Typeを参照する識別子の部分は、1〜255の値に制限されます。付録Aのソースコードが明確であり、これらの制限が例の理解に悪影響を及ぼさないことを確信しています。
The program reads the input text and interprets it as a set of instructions to create RADIUS attributes. It then prints the hex encoding of those attributes. It implements the minimum set of functionality that achieves that goal. This minimalism means that it does not use attribute dictionaries; it does not implement support for RADIUS data types; it can be used to encode attributes with invalid data fields; and there is no requirement for consistency from one example to the next. For example, it can be used to encode a User-Name attribute that contains non-UTF8 data or a Framed-IP-Address that contains 253 octets of ASCII data. As a result, it MUST NOT be used to create RADIUS attributes for transport in a RADIUS message.
The program reads the input text and interprets it as a set of instructions to create RADIUS attributes. It then prints the hex encoding of those attributes. It implements the minimum set of functionality that achieves that goal. This minimalism means that it does not use attribute dictionaries; it does not implement support for RADIUS data types; it can be used to encode attributes with invalid data fields; and there is no requirement for consistency from one example to the next. For example, it can be used to encode a User-Name attribute that contains non-UTF8 data or a Framed-IP-Address that contains 253 octets of ASCII data. As a result, it MUST NOT be used to create RADIUS attributes for transport in a RADIUS message.
However, the program correctly encodes the RADIUS attribute fields of "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data types "evs" and "tlv". It can therefore be used to encode example attributes from inputs that are human readable.
ただし、プログラムは、「タイプ」、「長さ」、「拡張タイプ」、「その他」、「予約済み」、「ベンダーID」、「ベンダータイプ」、および「ベンダー長」のRADIUS属性フィールドを正しくエンコードします。 」 RADIUS属性データタイプ「evs」と「tlv」をエンコードします。したがって、人間が読める入力からのサンプル属性をエンコードするために使用できます。
We do not give examples of "invalid attributes". We also note that the examples show format, rather than consistent meaning. A particular Attribute Type code may be used to demonstrate two different formats. In real specifications, attributes have a static definitions based on their type code.
「無効な属性」の例は示しません。また、例は一貫した意味ではなく形式を示していることに注意してください。特定の属性タイプコードを使用して、2つの異なる形式を示すことができます。実際の仕様では、属性にはタイプコードに基づく静的な定義があります。
The examples given below are strictly for demonstration purposes only and do not provide a standard of any kind.
以下に示す例は、あくまでもデモ目的のものであり、いかなる種類の標準も提供していません。
The following is a series of examples of the "Extended Type" format.
以下は、「拡張タイプ」フォーマットの一連の例です。
Attribute encapsulating textual data:
テキストデータをカプセル化する属性：
241.1 "bob" -> f1 06 01 62 6f 62
241.1 "bob"-> f1 06 01 62 6f 62
Attribute encapsulating a TLV with TLV-Type of one (1):
TLVタイプが1のTLVをカプセル化する属性：
241.2 { 1 23 45 }
-> f1 07 02 01 04 23 45
Attribute encapsulating two TLVs, one after the other:
2つのTLVを次々にカプセル化する属性：
241.2 { 1 23 45 } { 2 67 89 }
-> f1 0b 02 01 04 23 45 02 04 67 89
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating a TLV:
2つのTLVをカプセル化する属性。2番目のTLV自体がTLVをカプセル化します。
241.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f1 0d 02 01 04 23 45 03 06 01 04 ab cd
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating two TLVs:
2つのTLVをカプセル化する属性。2番目のTLV自体が2つのTLVをカプセル化します。
241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a depth of 5 nestings:
TLVをカプセル化する属性は、TLVをカプセル化し、ネストの深さを5にします。
241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates textual data:
拡張ベンダー固有の属性をカプセル化する属性。ベンダーIDは1、ベンダータイプは4で、テキストデータをカプセル化します。
241.26.1.4 "test" -> f1 0c 1a 00 00 00 01 04 74 65 73 74
241.26.1.4 "test"-> f1 0c 1a 00 00 00 01 04 74 65 73 74
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV with TLV-Type of 3, which encapsulates textual data:
拡張ベンダー固有の属性をカプセル化する属性。ベンダーIDは1、ベンダータイプは5で、TLVタイプ3のTLVをカプセル化し、テキストデータをカプセル化します。
241.26.1.5 { 3 "test" }
-> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74
The following is a series of examples of the "Long Extended Type" format.
以下は、「Long Extended Type」フォーマットの一連の例です。
Attribute encapsulating textual data:
テキストデータをカプセル化する属性：
245.1 "bob" -> f5 07 01 00 62 6f 62
245.1 "bob"-> f5 07 01 00 62 6f 62
Attribute encapsulating a TLV with TLV-Type of one (1):
TLVタイプが1のTLVをカプセル化する属性：
245.2 { 1 23 45 }
-> f5 08 02 00 01 04 23 45
Attribute encapsulating two TLVs, one after the other:
2つのTLVを次々にカプセル化する属性：
245.2 { 1 23 45 } { 2 67 89 }
-> f5 0c 02 00 01 04 23 45 02 04 67 89
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating a TLV:
2つのTLVをカプセル化する属性。2番目のTLV自体がTLVをカプセル化します。
245.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating two TLVs:
2つのTLVをカプセル化する属性。2番目のTLV自体が2つのTLVをカプセル化します。
245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a depth of 5 nestings:
TLVをカプセル化する属性は、TLVをカプセル化し、ネストの深さを5にします。
245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates textual data:
拡張ベンダー固有の属性をカプセル化する属性。ベンダーIDは1、ベンダータイプは4で、テキストデータをカプセル化します。
245.26.1.4 "test" -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74
245.26.1.4 "test"-> f5 0d 1a 00 00 00 00 01 04 74 65 73 74
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV with TLV-Type of 3, which encapsulates textual data:
拡張ベンダー固有の属性をカプセル化する属性。ベンダーIDは1、ベンダータイプは5で、TLVタイプ3のTLVをカプセル化し、テキストデータをカプセル化します。
245.26.1.5 { 3 "test" }
-> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74
Attribute encapsulating more than 251 octets of data. The "Data" portions are indented for readability:
251オクテットを超えるデータをカプセル化する属性。 「データ」の部分は読みやすいようにインデントされています。
245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc ccccccccccc" -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc ccccccccccc" - 04 80のAA AA AA AAのAAのAAのAAのAA AA AAのAAのAAのAAのAA AA AAのAAのAAのAAのAA AA AAのAAのAAのAAのAA AA AAのAAのAAのAA FF> F5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab aa aa aa aa bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
Below is an example of an attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 6, which in turn encapsulates more than 251 octets of data.
以下は、Vendor-Idが1、Vendor-Typeが6の拡張ベンダー固有属性をカプセル化する属性の例です。これにより、251オクテットを超えるデータがカプセル化されます。
As the VSA encapsulates more than 251 octets of data, it is split into two RADIUS attributes. The first attribute has the More field set, and it carries the Vendor-Id and Vendor-Type. The second attribute has the More field clear and carries the rest of the data portion of the VSA. Note that the second attribute does not include the Vendor-Id ad Vendor-Type fields.
VSAは251オクテットを超えるデータをカプセル化するため、2つのRADIUS属性に分割されます。最初の属性にはMoreフィールドセットがあり、Vendor-IdとVendor-Typeが含まれています。 2番目の属性にはMoreフィールドがあり、VSAの残りのデータ部分が含まれています。 2番目の属性にはVendor-IdおよびVendor-Typeフィールドが含まれていないことに注意してください。
The "Data" portions are indented for readability:
「データ」の部分は読みやすいようにインデントされています。
245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc ccccccccccccccccc" -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc ccccccccccccccccc" - > F5 FF 1A 80 00 00 00 01 06のAA、AA、AAのAAのAAのAA、AA、AAのAAのAAのAAのAA、AA、AAのAAのAAのAAのAA、AA、AAのAAのAA、AAのAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA aa ab bb bb bb bb bb bb bb bb bb bb bb bb bb b bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb bb bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
This document updates [RFC3575] in that it adds new IANA considerations for RADIUS attributes. These considerations modify and extend the IANA considerations for RADIUS, rather than replacing them.
このドキュメントは、RADIUS属性に関する新しいIANAの考慮事項を追加する点で[RFC3575]を更新します。これらの考慮事項は、RADIUSのIANAの考慮事項を置き換えるのではなく、変更および拡張します。
The IANA considerations of this document are limited to the "RADIUS Attribute Types" registry. Some Attribute Type values that were previously marked "Reserved" are now allocated, and the registry is extended from a simple 8-bit array to a tree-like structure, up to a maximum depth of 125 nodes. Detailed instructions are given below.
このドキュメントのIANAの考慮事項は、「RADIUS Attribute Types」レジストリに限定されています。以前は「予約済み」とマークされていた一部の属性タイプ値が割り当てられ、レジストリは単純な8ビット配列からツリーのような構造に、最大125ノードまで拡張されます。詳細な手順を以下に示します。
IANA has moved the following Attribute Type values from "Reserved" to "Allocated" with the corresponding names:
IANAは、次の属性タイプの値を、対応する名前で「予約済み」から「割り当て済み」に移動しました。
* 241 Extended-Type-1 * 242 Extended-Type-2 * 243 Extended-Type-3 * 244 Extended-Type-4 * 245 Long-Extended-Type-1 * 246 Long-Extended-Type-2
* 241 Extended-Type-1 * 242 Extended-Type-2 * 243 Extended-Type-3 * 244 Extended-Type-4 * 245 Long-Extended-Type-1 * 246 Long-Extended-Type-2
These values serve as an encapsulation layer for the new RADIUS Attribute Type tree.
これらの値は、新しいRADIUS属性タイプツリーのカプセル化レイヤーとして機能します。
Each of the Attribute Type values allocated above extends the "RADIUS Attribute Types" to an N-ary tree, via a "dotted number" notation. Allocation of an Attribute Type value "TYPE" using the new "Extended Type" format results in allocation of 255 new Attribute Type values of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through "TYPE.255" are marked "Reserved". All other values are "Unassigned".
上記で割り当てられた各属性タイプ値は、「ドット番号」表記を介して、「RADIUS属性タイプ」をN-aryツリーに拡張します。新しい「拡張タイプ」フォーマットを使用して属性タイプ値「TYPE」を割り当てると、フォーマット「TYPE.1」から「TYPE.255」までの255個の新しい属性タイプ値が割り当てられます。値26は「Extended-Vendor-Specific- *」として割り当てられます。 「TYPE.241」から「TYPE.255」までの値は「予約済み」とマークされています。他のすべての値は「未割り当て」です。
The initial set of Attribute Type values and names assigned by this document is given below.
このドキュメントによって割り当てられた属性タイプの値と名前の初期セットを以下に示します。
* 241 Extended-Attribute-1
* 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned
* 241.{241-255} Reserved
* 242 Extended-Attribute-2
* 242.{1-25} Unassigned
* 242.26 Extended-Vendor-Specific-2
* 242.{27-240} Unassigned
* 242.{241-255} Reserved
* 243 Extended-Attribute-3
* 243.{1-25} Unassigned
* 243.26 Extended-Vendor-Specific-3
* 243.{27-240} Unassigned
* 243.{241-255} Reserved
* 244 Extended-Attribute-4
* 244.{1-25} Unassigned
* 244.26 Extended-Vendor-Specific-4
* 244.{27-240} Unassigned
* 244.{241-255} Reserved
* 245 Extended-Attribute-5
* 245.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-5
* 245.{27-240} Unassigned
* 245.{241-255} Reserved
* 246 Extended-Attribute-6
* 246.{1-25} Unassigned
* 246.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned
* 246.{241-255} Reserved
As per [RFC5226], the values marked "Unassigned" above are available for assignment by IANA in future RADIUS specifications. The values marked "Reserved" are reserved for future use.
[RFC5226]に従って、上記の「未割り当て」とマークされた値は、将来のRADIUS仕様でIANAによる割り当てに使用できます。 「予約済み」とマークされている値は、将来の使用のために予約されています。
The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, and allocations are not managed by IANA.
拡張ベンダー固有のスペース（TYPE.26）は私用で、割り当てはIANAによって管理されません。
Allocation of Reserved entries in the extended space requires Standards Action.
拡張スペースでの予約済みエントリーの割り当てには、標準アクションが必要です。
All other allocations in the extended space require IETF Review.
拡張スペースでの他のすべての割り当てには、IETFレビューが必要です。
This section defines what actions IANA needs to take when allocating new attributes. Different actions are required when allocating attributes from the standard space, attributes of the "Extended Type" format, attributes of the "Long Extended Type" format, preferential allocations, attributes of data type TLV, attributes within a TLV, and attributes of other data types.
このセクションでは、新しい属性を割り当てるときにIANAが実行する必要があるアクションを定義します。標準スペースから属性、「拡張タイプ」フォーマットの属性、「ロング拡張タイプ」フォーマットの属性、優先割り当て、データタイプTLVの属性、TLV内の属性、および他のデータの属性を割り当てる場合、さまざまなアクションが必要です。タイプ。
Specifications can request allocation of an Attribute from within the standard space (e.g., Attribute Type Codes 1 through 255), subject to the considerations of [RFC3575] and this document.
仕様では、[RFC3575]およびこのドキュメントの考慮事項に従って、標準スペース（たとえば、属性タイプコード1〜255）内から属性の割り当てを要求できます。
Specifications can request allocation of an Attribute that requires the format "Extended Type", by specifying the short extended space. In that case, IANA should assign the lowest Unassigned number from the Attribute Type space with the relevant format.
仕様では、短い拡張スペースを指定することにより、「拡張タイプ」の形式を必要とする属性の割り当てを要求できます。その場合、IANAは、属性タイプスペースから関連する形式で最小の未割り当て番号を割り当てる必要があります。
Specifications can request allocation of an Attribute that requires the format "Long Extended Type", by specifying the extended space (long). In that case, IANA should assign the lowest Unassigned number from the Attribute Type space with the relevant format.
仕様では、拡張スペース（long）を指定することにより、「Long Extended Type」形式を必要とする属性の割り当てを要求できます。その場合、IANAは、属性タイプスペースから関連する形式で最小の未割り当て番号を割り当てる必要があります。
Specifications that make no request for allocation from a specific type space should have Attributes allocated using the following criteria:
特定のタイプスペースからの割り当てを要求しない仕様では、次の基準を使用して属性を割り当てます。
* When the standard space has no more Unassigned attributes, all allocations should be performed from the extended space.
* 標準スペースに未割り当て属性がなくなると、すべての割り当ては拡張スペースから実行されます。
* Specifications that allocate a small number of attributes (i.e., less than ten) should have all allocations made from the standard space.
* 少数の属性（つまり、10未満）を割り当てる仕様では、すべての割り当てを標準スペースから行う必要があります。
* Specifications that would allocate more than twenty percent of the remaining standard space attributes should have all allocations made from the extended space.
* 残りの標準スペース属性の20％以上を割り当てる仕様では、すべての割り当てを拡張スペースから行う必要があります。
* Specifications that request allocation of an attribute of data type TLV should have that attribute allocated from the extended space.
* データ型TLVの属性の割り当てを要求する仕様では、拡張スペースから割り当てられた属性が必要です。
* Specifications that request allocation of an attribute that can transport 253 or more octets of data should have that attribute allocated from within the long extended space. We note that Section 6.5 above makes recommendations related to this allocation.
* 253オクテット以上のデータを転送できる属性の割り当てを要求する仕様では、長い拡張スペース内からその属性を割り当てる必要があります。上記のセクション6.5は、この割り当てに関連する推奨事項を作成することに注意してください。
There is otherwise no requirement that all attributes within a specification be allocated from one type space or another. Specifications can simultaneously allocate attributes from both the standard space and the extended space.
それ以外の場合は、仕様内のすべての属性を1つのタイプスペースまたは別のタイプスペースから割り当てる必要はありません。仕様では、標準スペースと拡張スペースの両方から属性を同時に割り当てることができます。
When specifications request allocation of an attribute of data type TLV, that allocation extends the Attribute Type tree by one more level. Allocation of an Attribute Type value "TYPE.TLV", with data type TLV, results in allocation of 255 new Attribute Type values, of format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are marked "Reserved". All other values are "Unassigned". Value 26 has no special meaning.
仕様がデータタイプTLVの属性の割り当てを要求すると、その割り当ては属性タイプツリーをもう1レベル拡張します。属性タイプ値「TYPE.TLV」をデータ型TLVで割り当てると、「TYPE.TLV.1」から「TYPE.TLV.255」までの形式の255個の新しい属性タイプ値が割り当てられます。値254-255は「予約済み」とマークされています。他のすべての値は「未割り当て」です。値26には特別な意味はありません。
For example, if a new attribute "Example-TLV" of data type TLV is assigned the identifier "245.1", then the extended tree will be allocated as below:
たとえば、データ型TLVの新しい属性「Example-TLV」に識別子「24.5.1」が割り当てられている場合、拡張ツリーは次のように割り当てられます。
* 245.1 Example-TLV
* 245.1.{1-253} Unassigned
* 245.1.{254-255} Reserved
Note that this example does not define an "Example-TLV" attribute.
この例では「Example-TLV」属性を定義していないことに注意してください。
The Attribute Type tree can be extended multiple levels in one specification when the specification requests allocation of nested TLVs, as discussed below.
以下で説明するように、仕様がネストされたTLVの割り当てを要求する場合、1つの仕様で属性タイプツリーを複数のレベルに拡張できます。
Specifications can request allocation of Attribute Type values within an Attribute of data type TLV. The encapsulating TLV can be allocated in the same specification, or it can have been previously allocated.
仕様では、データタイプTLVの属性内の属性タイプ値の割り当てを要求できます。カプセル化TLVは、同じ仕様で割り当てることも、事前に割り当てておくこともできます。
Specifications need to request allocation within a specific Attribute Type value (e.g., "TYPE.TLV.*"). Allocations are performed from the smallest Unassigned value, proceeding to the largest Unassigned value.
仕様では、特定の属性タイプ値（「TYPE.TLV。*」など）内での割り当てを要求する必要があります。割り当ては、最小の未割り当て値から実行され、最大の未割り当て値に進みます。
Where the Attribute being allocated is of data type TLV, the Attribute Type tree is extended by one level, as given in the previous section. Allocations can then be made within that level.
割り当てられる属性がTLVデータ型である場合、前のセクションで説明したように、属性タイプツリーは1レベル拡張されます。その後、そのレベル内で割り当てを行うことができます。
Attribute Type value allocations are otherwise allocated from the smallest Unassigned value, proceeding to the largest Unassigned value, e.g., starting from 241.1, proceeding through 241.255, then to 242.1, through 242.255, etc.
それ以外の場合、属性タイプの値の割り当ては、最小の未割り当ての値から割り当てられ、最大の未割り当ての値に進みます。たとえば、241.1から始まり、241.255に進み、次に242.1、242.255に続きます。
This document defines new formats for data carried inside of RADIUS but otherwise makes no changes to the security of the RADIUS protocol.
このドキュメントでは、RADIUS内で伝送されるデータの新しい形式を定義していますが、それ以外の場合はRADIUSプロトコルのセキュリティに変更を加えません。
Attacks on cryptographic hashes are well known and are getting better with time, as discussed in [RFC4270]. The security of the RADIUS protocol is dependent on MD5 [RFC1321], which has security issues as discussed in [RFC6151]. It is not known if the issues described in [RFC6151] apply to RADIUS. For other issues, we incorporate by reference the security considerations of [RFC6158] Section 5.
暗号化ハッシュへの攻撃はよく知られており、[RFC4270]で説明されているように、時間とともに改善されます。 RADIUSプロトコルのセキュリティはMD5 [RFC1321]に依存しており、[RFC6151]で説明されているようにセキュリティの問題があります。 [RFC6151]で説明されている問題がRADIUSに適用されるかどうかは不明です。その他の問題については、[RFC6158]セクション5のセキュリティに関する考慮事項を参照により組み込んでいます。
As with any protocol change, code changes are required in order to implement the new features. These code changes have the potential to introduce new vulnerabilities in the software. Since the RADIUS server performs network authentication, it is an inviting target for attackers. We RECOMMEND that access to RADIUS servers be kept to a minimum.
プロトコルの変更と同様に、新機能を実装するにはコードの変更が必要です。これらのコード変更は、ソフトウェアに新しい脆弱性をもたらす可能性があります。 RADIUSサーバーはネットワーク認証を実行するため、攻撃者にとって魅力的なターゲットです。 RADIUSサーバーへのアクセスは最小限に抑えることをお勧めします。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（リモート認証ダイヤルインユーザーサービス）に関するIANAの考慮事項」、RFC 3575、2003年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158] DeKok、A.、Ed。、およびG. Weber、「RADIUS Design Guidelines」、BCP 158、RFC 6158、2011年3月。
[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://www.iana.org/assignments/enterprise-numbers>.
[ペン] IANA、「プライベートエンタープライズ番号」、<http://www.iana.org/assignments/enterprise-numbers>。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「RADIUS Attributes for Tunnel Protocol Support」、RFC 2868、2000年6月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
[ATTR] "alandekok/freeradius-server", available from GitHub, data retrieved September 2010, <http://github.com/alandekok/ freeradius-server/tree/master/share/>.
[ATTR]「alandekok / freeradius-server」、GitHubから入手可能、2010年9月に取得したデータ<http://github.com/alandekok/ freeradius-server / tree / master / share />。
This document is the result of long discussions in the IETF RADEXT working group. The authors would like to thank all of the participants who contributed various ideas over the years. Their feedback has been invaluable and has helped to make this specification better.
このドキュメントは、IETF RADEXTワーキンググループでの長い議論の結果です。著者は、長年にわたってさまざまなアイデアを提供してくれた参加者全員に感謝したいと思います。彼らのフィードバックは非常に貴重であり、この仕様をより良くするのに役立ちました。
This section contains "C" program source code that can be used for testing. It reads a line-oriented text file, parses it to create RADIUS formatted attributes, and prints the hex version of those attributes to standard output.
このセクションには、テストに使用できる「C」プログラムのソースコードが含まれています。行指向のテキストファイルを読み取り、それを解析してRADIUS形式の属性を作成し、それらの属性の16進数バージョンを標準出力に出力します。
The input accepts grammar similar to that given in Section 9, with some modifications for usability. For example, blank lines are allowed, lines beginning with a '#' character are interpreted as comments, numbers (RADIUS Types, etc.) are checked for minimum/ maximum values, and RADIUS attribute lengths are enforced.
入力は、使いやすさのためにいくつかの変更を加えて、セクション9で与えられたものと同様の文法を受け入れます。たとえば、空白行が許可され、「＃」文字で始まる行がコメントとして解釈され、数値（RADIUSタイプなど）の最小値/最大値がチェックされ、RADIUS属性の長さが適用されます。
The program is included here for demonstration purposes only, and does not define a standard of any kind.
このプログラムは、デモ目的でのみここに含まれており、いかなる種類の標準も定義していません。
------------------------------------------------------------
/*
* Copyright (c) 2013 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* Author: Alan DeKok <aland@networkradius.com>
*/
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <errno.h>
#include <ctype.h>
static int encode_tlv(char *buffer, uint8_t *output, size_t outlen);
static const char *hextab = "0123456789abcdef";
static int encode_data_string(char *buffer,
uint8_t *output, size_t outlen)
{
int length = 0;
char *p;
p = buffer + 1;
while (*p && (outlen > 0)) {
if (*p == '"') {
return length;
}
if (*p != '\\') {
*(output++) = *(p++);
outlen--;
length++;
continue;
}
switch (p[1]) {
default:
*(output++) = p[1];
break;
case 'n':
*(output++) = '\n';
break;
case 'r':
*(output++) = '\r';
break;
case 't':
*(output++) = '\t';
break;
}
outlen--;
length++;
}
fprintf(stderr, "String is not terminated\n");
return 0;
}
static int encode_data_tlv(char *buffer, char **endptr,
uint8_t *output, size_t outlen)
{
int depth = 0;
int length;
char *p;
for (p = buffer; *p != '\0'; p++) {
if (*p == '{') depth++;
if (*p == '}') {
depth--;
if (depth == 0) break;
}
}
if (*p != '}') {
fprintf(stderr, "No trailing '}' in string starting "
"with \"%s\"\n",
buffer);
return 0;
}
*endptr = p + 1;
*p = '\0';
p = buffer + 1;
while (isspace((int) *p)) p++;
length = encode_tlv(p, output, outlen);
if (length == 0) return 0;
return length;
}
static int encode_data(char *p, uint8_t *output, size_t outlen)
{
int length;
if (!isspace((int) *p)) {
fprintf(stderr, "Invalid character following attribute "
"definition\n");
return 0;
}
while (isspace((int) *p)) p++;
if (*p == '{') {
int sublen;
char *q;
length = 0;
長さ= 0;
do {
while (isspace((int) *p)) p++;
if (!*p) {
if (length == 0) {
fprintf(stderr, "No data\n");
return 0;
}
break;
}
sublen = encode_data_tlv(p, &q, output, outlen);
if (sublen == 0) return 0;
length += sublen;
output += sublen;
outlen -= sublen;
p = q;
} while (*q);
return length;
}
if (*p == '"') {
length = encode_data_string(p, output, outlen);
return length;
}
length = 0;
while (*p) {
char *c1, *c2;
while (isspace((int) *p)) p++;
if (!*p) break;
if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) ||
!(c2 = memchr(hextab, tolower((int) p[1]), 16))) {
fprintf(stderr, "Invalid data starting at "
"\"%s\"\n", p);
return 0;
}
*output = ((c1 - hextab) << 4) + (c2 - hextab);
output++;
length++;
p += 2;
outlen--;
if (outlen == 0) {
fprintf(stderr, "Too much data\n");
return 0;
}
}
if (length == 0) {
fprintf(stderr, "Empty string\n");
return 0;
}
return length;
}
static int decode_attr(char *buffer, char **endptr)
{
long attr;
attr = strtol(buffer, endptr, 10);
if (*endptr == buffer) {
fprintf(stderr, "No valid number found in string "
"starting with \"%s\"\n", buffer);
return 0;
}
if (!**endptr) {
fprintf(stderr, "Nothing follows attribute number\n");
return 0;
}
if ((attr <= 0) || (attr > 256)) {
fprintf(stderr, "Attribute number is out of valid "
"range\n");
return 0;
}
return (int) attr;
}
static int decode_vendor(char *buffer, char **endptr)
{
long vendor;
if (*buffer != '.') {
fprintf(stderr, "Invalid separator before vendor id\n");
return 0;
}
vendor = strtol(buffer + 1, endptr, 10);
if (*endptr == (buffer + 1)) {
fprintf(stderr, "No valid vendor number found\n");
return 0;
}
if (!**endptr) {
fprintf(stderr, "Nothing follows vendor number\n");
return 0;
}
if ((vendor <= 0) || (vendor > (1 << 24))) {
fprintf(stderr, "Vendor number is out of valid range\n");
return 0;
}
if (**endptr != '.') {
fprintf(stderr, "Invalid data following vendor number\n");
return 0;
}
(*endptr)++;
return (int) vendor;
}
static int encode_tlv(char *buffer, uint8_t *output, size_t outlen)
{
int attr;
int length;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
output[0] = attr;
output[1] = 2;
if (*p == '.') {
p++;
length = encode_tlv(p, output + 2, outlen - 2);
} else {
length = encode_data(p, output + 2, outlen - 2);
}
if (length == 0) return 0;
if (length > (255 - 2)) {
fprintf(stderr, "TLV data is too long\n");
return 0;
}
output[1] += length;
return length + 2;
}
static int encode_vsa(char *buffer, uint8_t *output, size_t outlen)
{
int vendor;
int attr;
int length;
char *p;
vendor = decode_vendor(buffer, &p);
if (vendor == 0) return 0;
output[0] = 0;
output[1] = (vendor >> 16) & 0xff;
output[2] = (vendor >> 8) & 0xff;
output[3] = vendor & 0xff;
length = encode_tlv(p, output + 4, outlen - 4);
if (length == 0) return 0;
if (length > (255 - 6)) {
fprintf(stderr, "VSA data is too long\n");
return 0;
}
return length + 4;
}
static int encode_evs(char *buffer, uint8_t *output, size_t outlen)
{
int vendor;
int attr;
int length;
char *p;
vendor = decode_vendor(buffer, &p);
if (vendor == 0) return 0;
attr = decode_attr(p, &p);
if (attr == 0) return 0;
output[0] = 0;
output[1] = (vendor >> 16) & 0xff;
output[2] = (vendor >> 8) & 0xff;
output[3] = vendor & 0xff;
output[4] = attr;
length = encode_data(p, output + 5, outlen - 5);
if (length == 0) return 0;
return length + 5;
}
static int encode_extended(char *buffer,
uint8_t *output, size_t outlen)
{
int attr;
int length;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
output[0] = attr;
output [0] = attr;
if (attr == 26) {
length = encode_evs(p, output + 1, outlen - 1);
} else {
length = encode_data(p, output + 1, outlen - 1);
}
if (length == 0) return 0;
if (length > (255 - 3)) {
fprintf(stderr, "Extended Attr data is too long\n");
return 0;
}
return length + 1;
}
static int encode_extended_flags(char *buffer,
uint8_t *output, size_t outlen)
{
int attr;
int length, total;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
/* output[0] is the extended attribute */
output[1] = 4;
output[2] = attr;
output[3] = 0;
if (attr == 26) {
length = encode_evs(p, output + 4, outlen - 4);
if (length == 0) return 0;
output[1] += 5;
length -= 5;
} else {
length = encode_data(p, output + 4, outlen - 4);
}
if (length == 0) return 0;
total = 0;
while (1) {
int sublen = 255 - output[1];
if (length <= sublen) {
output[1] += length;
total += output[1];
break;
}
length -= sublen;
memmove(output + 255 + 4, output + 255, length);
memcpy(output + 255, output, 4);
output[1] = 255;
output [1] = 255;
output[3] |= 0x80;
output [3] | = 0x80;
output += 255;
output[1] = 4;
total += 255;
}
return total;
}
static int encode_rfc(char *buffer, uint8_t *output, size_t outlen)
{
int attr;
int length, sublen;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
length = 2;
output[0] = attr;
output[1] = 2;
if (attr == 26) {
sublen = encode_vsa(p, output + 2, outlen - 2);
} else if ((*p == ' ') || ((attr < 241) || (attr > 246))) {
sublen = encode_data(p, output + 2, outlen - 2);
} else {
if (*p != '.') {
fprintf(stderr, "Invalid data following "
"attribute number\n");
return 0;
}
if (attr < 245) {
sublen = encode_extended(p + 1,
output + 2, outlen - 2);
} else {
/*
* Not like the others!
*/
return encode_extended_flags(p + 1, output, outlen);
}
}
if (sublen == 0) return 0;
if (sublen > (255 -2)) {
fprintf(stderr, "RFC Data is too long\n");
return 0;
}
output[1] += sublen;
return length + sublen;
}
int main(int argc, char *argv[])
{
int lineno;
size_t i, outlen;
FILE *fp;
char input[8192], buffer[8192];
uint8_t output[4096];
if ((argc < 2) || (strcmp(argv[1], "-") == 0)) {
fp = stdin;
} else {
fp = fopen(argv[1], "r");
if (!fp) {
fprintf(stderr, "Error opening %s: %s\n",
argv[1], strerror(errno));
exit(1);
}
}
lineno = 0;
while (fgets(buffer, sizeof(buffer), fp) != NULL) {
char *p = strchr(buffer, '\n');
lineno++;
if (!p) {
if (!feof(fp)) {
fprintf(stderr, "Line %d too long in %s\n",
lineno, argv[1]);
exit(1);
}
} else {
*p = '\0';
}
p = strchr(buffer, '#');
if (p) *p = '\0';
p = buffer;
p =バッファ。
while (isspace((int) *p)) p++;
if (!*p) continue;
strcpy(input, p);
outlen = encode_rfc(input, output, sizeof(output));
if (outlen == 0) {
fprintf(stderr, "Parse error in line %d of %s\n",
lineno, input);
exit(1);
}
printf("%s -> ", buffer);
for (i = 0; i < outlen; i++) {
printf("%02x ", output[i]);
}
printf("\n");
}
if (fp != stdin) fclose(fp);
return 0;
}
------------------------------------------------------------
Authors' Addresses
著者のアドレス
Alan DeKok Network RADIUS SARL 57bis blvd des Alpes 38240 Meylan France
Alan DeKok Network RADIUS SARL 57bis blvd des Alpes 38240 Meylan France
EMail: aland@networkradius.com
URI: http://networkradius.com
Avi Lior
avi Lior
EMail: avi.ietf@lior.org