RFC 8044 - Data Types in RADIUS 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8044
タイトル : RFC 8044 - RADIUSのデータ型
翻訳編集 : 自動生成

[要約] RFC 8044は、RADIUSプロトコルで使用されるデータ型に関する仕様です。このRFCの目的は、データ型の一貫性と相互運用性を確保することです。

Internet Engineering Task Force (IETF)                          A. DeKok
Request for Comments: 8044                                    FreeRADIUS
Updates: 2865, 3162, 4072, 6158, 6572, 7268                 January 2017
Category: Standards Track
ISSN: 2070-1721

Data Types in RADIUS

RADIUSのデータ型

Abstract

概要

RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.

RADIUS仕様では、管理対象エンティティとして定義することなく、20年にわたってデータタイプを使用しています。この間、RADIUS実装はデータ型に名前を付け、それらを属性定義で使用しました。このドキュメントは、確立された慣例にさらに従うように仕様を更新します。これは、RFC 6158で定義されているデータ型に名前を付けることによって行います。これは、少なくともRFC 2865の公開以降に使用されています。データ型のIANAレジストリを提供し、「RADIUS Attribute Types」レジストリを更新してデータ型フィールドを含めます属性ごとに。最後に、RADIUS仕様の作成者は、既存の方法よりもこれらのタイプを使用することをお勧めします。このドキュメントは、RFC 2865、3162、4072、6158、6572、および7268を更新します。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8044.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8044で入手できます。

著作権表示

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 ....................................................4
      1.1. Specification Problems with Data Types .....................4
      1.2. Implementation Problems with Data Types ....................5
      1.3. No Mandated Changes ........................................5
      1.4. Requirements Language ......................................5
   2. Use of Data Types ...............................................6
      2.1. Specification Use of Data Types ............................6
           2.1.1. Field Names for Attribute Values ....................6
           2.1.2. Attribute Definitions Using Data Types ..............7
           2.1.3. Format of Attribute Definitions .....................8
           2.1.4. Defining a New Data Type ............................9
      2.2. Implementation Use of Data Types ...........................9
   3. Data Type Definitions ..........................................10
      3.1. integer ...................................................12
      3.2. enum ......................................................12
      3.3. time ......................................................13
      3.4. text ......................................................14
      3.5. string ....................................................15
      3.6. concat ....................................................16
      3.7. ifid ......................................................17
      3.8. ipv4addr ..................................................18
      3.9. ipv6addr ..................................................18
      3.10. ipv6prefix ...............................................19
      3.11. ipv4prefix ...............................................20
      3.12. integer64 ................................................22
      3.13. tlv ......................................................23
      3.14. vsa ......................................................24
      3.15. extended .................................................26
      3.16. long-extended ............................................27
      3.17. evs ......................................................30
   4. Updated Registries .............................................31
      4.1. New "Data Type" Registry ..................................31
      4.2. Updates to the "RADIUS Attribute Types" Registry ..........32
   5. Security Considerations ........................................32
   6. IANA Considerations ............................................33
   7. References .....................................................33
      7.1. Normative References ......................................33
      7.2. Informative References ....................................34
   Acknowledgments ...................................................35
   Author's Address ..................................................35

1. Introduction

1. はじめに

RADIUS specifications have historically defined attributes in terms of name, value, and data type. Of these three pieces of information, the name is recorded by IANA in the "RADIUS Attribute Types" registry but is not otherwise managed or restricted, as discussed in [RFC6929], Section 2.7.1. The value is managed by IANA and recorded in that registry. The data type is not managed or recorded in the "RADIUS Attribute Types" registry. Experience has shown that there is a need to create well-known data types and have them managed by IANA.

RADIUS仕様には、名前、値、およびデータタイプの観点から歴史的に定義された属性があります。これらの3つの情報のうち、名前はIANAによって「RADIUS Attribute Types」レジストリに記録されますが、[RFC6929]のセクション2.7.1で説明されているように、その他の方法で管理または制限されることはありません。値はIANAによって管理され、そのレジストリに記録されます。データタイプは、「RADIUS属性タイプ」レジストリで管理または記録されていません。経験から、既知のデータ型を作成し、それらをIANAで管理する必要があることがわかっています。

This document defines an IANA RADIUS "Data Type" registry and updates the "RADIUS Attribute Types" registry to use those newly defined data types. It recommends how both specifications and implementations should use the data types. It extends the "RADIUS Attribute Types" registry to have a data type for each assigned attribute.

このドキュメントでは、IANA RADIUS「データタイプ」レジストリを定義し、新しく定義されたデータタイプを使用するように「RADIUS属性タイプ」レジストリを更新します。仕様と実装の両方でデータ型を使用する方法を推奨しています。「RADIUS Attribute Types」レジストリを拡張して、割り当てられた属性ごとにデータタイプを設定します。

In this section, we review the use of data types in specifications and implementations. We highlight ambiguities and inconsistencies. The rest of this document is devoted to resolving those problems.

このセクションでは、仕様と実装でのデータ型の使用について確認します。あいまいさと不整合を強調します。このドキュメントの残りの部分では、これらの問題の解決に取り組んでいます。

1.1. Specification Problems with Data Types

1.1. データ型に関する仕様の問題

When attributes are defined in the specifications, the terms "Value" and "String" are used to refer to the contents of an attribute. However, these names are used recursively and inconsistently. We suggest that defining a field to recursively contain itself is problematic.

仕様で属性が定義されている場合、「値」および「文字列」という用語は、属性の内容を指すために使用されます。ただし、これらの名前は再帰的に使用され、一貫性がありません。自分自身を再帰的に含むようにフィールドを定義することには問題があることをお勧めします。

A number of data type names and definitions are given in [RFC2865], Section 5, at the bottom of page 25. These data types are named and clearly defined. However, this practice was not continued in later specifications.

多くのデータ型の名前と定義は、25ページの下部にある[RFC2865]のセクション5に記載されています。これらのデータ型には名前が付けられ、明確に定義されています。ただし、この方法は後の仕様では継続されませんでした。

Specifically, [RFC2865] defines attributes of data type "address" to carry IPv4 addresses. Despite this definition, [RFC3162] defines attributes of data type "Address" to carry IPv6 addresses. We suggest that the use of the word "address" to refer to disparate data types is problematic.

具体的には、[RFC2865]は、IPv4アドレスを伝送するためのデータタイプ「アドレス」の属性を定義しています。この定義にもかかわらず、[RFC3162]はIPv6アドレスを伝送するためにデータタイプ「アドレス」の属性を定義しています。異種のデータ型を指すために「アドレス」という単語を使用することには問題があることをお勧めします。

Other failures are that [RFC3162] does not give a data type name and definition for the data types IPv6 address, Interface-Id, or IPv6 prefix. [RFC2869] defines Event-Timestamp to carry a time but does not reuse the "time" data type defined in [RFC2865]. Instead, it just repeats the "time" definition. [RFC6572] defines multiple attributes that carry IPv4 prefixes. However, an "IPv4 prefix" data type is not named, defined as a data type, or called out as an addition to RADIUS. Further, [RFC6572] does not follow the recommendations of [RFC6158] and does not explain why it fails to follow those recommendations.

他の失敗は、[RFC3162]がデータ型の名前とデータ型IPv6アドレス、インターフェイスID、またはIPv6プレフィックスの定義を提供しないことです。 [RFC2869]は、Event-Timestampが時間を伝送するように定義していますが、[RFC2865]で定義されている「time」データタイプを再利用しません。代わりに、「時間」の定義を繰り返すだけです。 [RFC6572]は、IPv4プレフィックスを運ぶ複数の属性を定義しています。ただし、「IPv4プレフィックス」データタイプは、名前が付けられていないか、データタイプとして定義されていないか、RADIUSへの追加として呼び出されていません。さらに、[RFC6572]は[RFC6158]の推奨事項に準拠しておらず、これらの推奨事項に準拠しない理由についても説明していません。

These ambiguities and inconsistencies need to be resolved.

これらのあいまいさと矛盾は解決する必要があります。

1.2. Implementation Problems with Data Types

1.2. データ型の実装の問題

RADIUS implementations often use "dictionaries" to map attribute names to type values and define data types for each attribute. The data types in the dictionaries are defined by each implementation but correspond to the "ad hoc" data types used in the specifications.

RADIUS実装では、多くの場合、「辞書」を使用して属性名を型の値にマップし、各属性のデータ型を定義します。辞書のデータ型は各実装によって定義されますが、仕様で使用される「アドホック」データ型に対応しています。

In effect, implementations have seen the need for well-defined data types and have created them. It is time for RADIUS specifications to follow this practice.

実際、実装では、明確に定義されたデータ型の必要性を認識し、それらを作成しました。 RADIUS仕様でこの慣例に従う必要があります。

1.3. No Mandated Changes

1.3. 必須の変更はありません

This document mandates no changes to any past, present, or future RADIUS implementation. It instead documents existing practice in order to simplify the process of writing RADIUS specifications, clarify the interpretation of RADIUS standards, and improve the communication between specification authors and IANA.

このドキュメントでは、過去、現在、または将来のRADIUS実装への変更は義務付けられていません。代わりに、RADIUS仕様の作成プロセスを簡略化し、RADIUS標準の解釈を明確にし、仕様の作成者とIANA間の通信を改善するために、既存の慣行を文書化します。

This document suggests that implementations SHOULD use the data types defined here, in preference to any ad hoc data types currently in use. This suggestion should have a minimal effect on implementations, as most ad hoc data types are compatible with the ones defined here. Any difference will typically be limited to the name of the data type.

このドキュメントは、実装が現在使用されているアドホックデータ型に優先して、ここで定義されたデータ型を使用する必要があることを示唆しています。ほとんどのアドホックデータ型はここで定義されているものと互換性があるため、この提案は実装への影響が最小限になるはずです。違いは通常、データ型の名前に限定されます。

This document updates [RFC6158] to permit the data types defined in the "Data Type" registry as "basic data types", as per Section 2.1 of [RFC6158]. The recommendations of [RFC6158] are otherwise unchanged.

このドキュメントは、[RFC6158]のセクション2.1に従って、「基本データタイプ」として「データタイプ」レジストリで定義されたデータタイプを許可するように[RFC6158]を更新します。 [RFC6158]の推奨事項は、それ以外は変更されていません。

1.4. Requirements Language

1.4. 要件言語

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]で説明されているように解釈されます。

2. Use of Data Types

2. データ型の使用

The data types can be used in two places: specifications and implementations. This section discusses both uses and gives guidance on using the data types.

データ型は、仕様と実装の2つの場所で使用できます。このセクションでは、両方の使用法について説明し、データ型の使用に関するガイダンスを示します。

2.1. Specification Use of Data Types

2.1. データ型の仕様の使用

In this section, we give recommendations for how specifications should be written using data types. We first describe how attribute field names can be consistently named. We then describe how attribute definitions should use the data types and deprecate the use of "ASCII art" for attribute definitions. We suggest a format for new attribute definitions. This format includes recommended fields and suggestions for how those fields should be described.

このセクションでは、データ型を使用して仕様を記述する方法についての推奨事項を示します。最初に、属性フィールド名に一貫した名前を付ける方法について説明します。次に、属性定義でデータ型を使用する方法を説明し、属性定義での「ASCIIアート」の使用を廃止します。新しい属性定義の形式をお勧めします。このフォーマットには、推奨フィールドと、それらのフィールドをどのように説明するかについての提案が含まれています。

Finally, we make recommendations for how new data types should be defined.

最後に、新しいデータ型を定義する方法についての推奨事項を作成します。

2.1.1. Field Names for Attribute Values

2.1.1. 属性値のフィールド名

Previous specifications used inconsistent and conflicting names for the contents of RADIUS attributes. For example, the term "Value" is used in [RFC2865], Section 5 to define a field that carries the contents of an attribute. It is then used in later sections as the subfield of attribute contents. The result is that the field is defined as recursively containing itself. Similarly, "String" is used both as a data type and as a subfield of other data types.

以前の仕様では、RADIUS属性の内容に一貫性がなく競合する名前を使用していました。たとえば、「値」という用語は、[RFC2865]のセクション5で、属性の内容を保持するフィールドを定義するために使用されています。その後、属性コンテンツのサブフィールドとして後のセクションで使用されます。その結果、フィールドはそれ自体を再帰的に含むものとして定義されます。同様に、「文字列」は、データ型と他のデータ型のサブフィールドの両方として使用されます。

We correct this ambiguity by using context-specific names for various fields of attributes and data types. It then becomes clear that, for example, a field called "VSA-Data" must contain different data than a field called "EVS-Data". Each new name is defined where it is used.

属性とデータ型のさまざまなフィールドにコンテキスト固有の名前を使用して、このあいまいさを修正します。次に、たとえば、「VSA-Data」と呼ばれるフィールドには、「EVS-Data」と呼ばれるフィールドとは異なるデータが含まれている必要があることが明らかになります。新しい名前はそれぞれ、使用される場所で定義されます。

We also define the following term:

また、次の用語も定義します。

Attr-Data

属性データ

The Value field of an Attribute as defined in [RFC2865], Section 5. The contents of this field MUST be of a valid data type as defined in the RADIUS "Data Type" registry.

[RFC2865]のセクション5で定義されている属性の値フィールド。このフィールドの内容は、RADIUSの「データタイプ」レジストリで定義されている有効なデータタイプである必要があります。

We consistently use "Attr-Data" to refer to the contents of an attribute, instead of the more ambiguous name "Value". It is RECOMMENDED that new specifications follow this practice.

あいまいな名前「Value」の代わりに、一貫して「Attr-Data」を使用して属性の内容を参照します。新しい仕様はこの慣例に従うことが推奨されます。

We consistently use "Value" to refer to the contents of a data type, where that data type is simple. For example, an "integer" can have a "Value". In contrast, a Vendor-Specific Attribute carries complex information and thus cannot have a "Value".

一貫して「値」を使用して、データ型が単純なデータ型の内容を参照します。たとえば、「整数」は「値」を持つことができます。対照的に、ベンダー固有属性は複雑な情報を運ぶため、「値」を持つことはできません。

For data types that carry complex information, we name the fields based on the data type. For example, a Vendor-Specific Attribute is defined to carry a "vsa" data type, and the contents of that data type are described herein as "VSA-Data".

複雑な情報を含むデータ型の場合、データ型に基づいてフィールドに名前を付けます。たとえば、ベンダー固有属性は「vsa」データタイプを伝送するように定義されており、そのデータタイプの内容は「VSA-Data」としてここに記述されています。

These terms are used in preference to the term "String", which was previously used in ambiguous ways. It is RECOMMENDED that future specifications use type-specific names and the same naming scheme for new types. This use will maintain consistent definitions and help to avoid ambiguities.

これらの用語は、以前はあいまいな方法で使用されていた「文字列」という用語に優先して使用されます。将来の仕様では、タイプ固有の名前と新しいタイプに同じ命名スキームを使用することをお勧めします。この使用は、一貫した定義を維持し、あいまいさを回避するのに役立ちます。

2.1.2. Attribute Definitions Using Data Types

2.1.2. データ型を使用した属性定義

New RADIUS specifications MUST define attributes using data types from the RADIUS "Data Type" registry. The specification may, of course, define a new data type, update the "Data Type" registry, and use the new data type, all in the same document. The guidelines given in [RFC6929] MUST be followed when defining a new data type.

新しいRADIUS仕様では、RADIUSの「データタイプ」レジストリのデータタイプを使用して属性を定義する必要があります。もちろん、仕様では新しいデータ型を定義し、「データ型」レジストリを更新し、新しいデータ型をすべて同じドキュメントで使用できます。 [RFC6929]で与えられたガイドラインは、新しいデータ型を定義するときに従わなければなりません。

Attributes can usually be completely described via the Attribute Type value, name, and data type. The use of ASCII art is then limited only to the definition of new data types and for complex data types.

属性は通常、属性タイプの値、名前、およびデータタイプによって完全に記述できます。 ASCIIアートの使用は、新しいデータ型の定義と複雑なデータ型のみに限定されます。

Use of the new extended attributes [RFC6929] makes ASCII art even more problematic. An attribute can be allocated from any of the extended spaces, with more than one option for the attribute header format. This allocation decision is made after the specification has been accepted for publication. As the allocation affects the format of the attribute header, it is essentially impossible to create the correct ASCII art prior to final publication. Allocation from the different spaces also changes the value of the Length field, making it difficult to define it correctly prior to final publication of the document.

新しい拡張属性[RFC6929]を使用すると、ASCIIアートがさらに問題になります。属性は、任意の拡張スペースから割り当てることができ、属性ヘッダー形式には複数のオプションがあります。この割り当ての決定は、仕様が公開のために受け入れられた後に行われます。割り当ては属性ヘッダーの形式に影響を与えるため、最終的な公開前に正しいASCIIアートを作成することは基本的に不可能です。異なるスペースから割り当てると、Lengthフィールドの値も変更されるため、ドキュメントを最終的に発行する前に正しく定義することが困難になります。

It is therefore RECOMMENDED that ASCII art diagrams not be used for new RADIUS attribute specifications.

したがって、ASCIIアート図を新しいRADIUS属性仕様に使用しないことをお勧めします。

2.1.3. Format of Attribute Definitions

2.1.3. 属性定義のフォーマット

When defining a new attribute, the following fields SHOULD be given:

新しい属性を定義するときは、次のフィールドを指定する必要があります（SHOULD）。

Description

説明

A description of the meaning and interpretation of the attribute.

属性の意味と解釈の説明。

Type

タイプ

The Attribute Type value, given in the "dotted number" notation from [RFC6929]. Specifications can often leave this as "TBD" (to be determined) and request that IANA fill in the allocated values.

[RFC6929]の「ドット付き番号」表記で与えられる属性タイプの値。仕様では、これを「TBD」（未定）のままにして、IANAに割り当てられた値を入力するよう要求することがよくあります。

Length

長さ

A description of the length of the attribute. For attributes of variable length, a maximum length SHOULD be given. Since the Length value may depend on the Type value, the definition of Length may be affected by IANA allocations.

属性の長さの説明。可変長の属性の場合、最大長を指定する必要があります（SHOULD）。長さの値はタイプの値に依存する可能性があるため、長さの定義はIANA割り当ての影響を受ける可能性があります。

Data Type

データ・タイプ

One of the named data types from the RADIUS "Data Type" registry.

RADIUS "データタイプ"レジストリからの名前付きデータタイプの1つ。

Value

値

A description of any attribute-specific limitations on the values carried by the specified data type. If there are no attribute-specific limitations, then the description of this field can be omitted, so long as the Description field is sufficiently explanatory.

指定されたデータ型によって運ばれる値に対する属性固有の制限の説明。属性固有の制限がない場合、「説明」フィールドが十分に説明的である限り、このフィールドの説明は省略できます。

Where the values are limited to a subset of the possible range, valid range(s) MUST be defined.

値が可能な範囲のサブセットに制限されている場合、有効な範囲を定義する必要があります。

For attributes of data type "enum", a list of enumerated values and names MUST be given, as shown in [RFC2865], Section 5.6.

[RFC2865]のセクション5.6に示すように、データ型が「列挙型」の属性の場合、列挙値と名前のリストを指定する必要があります。

Using a consistent format for attribute definitions helps to make the definitions clearer.

属性定義に一貫したフォーマットを使用すると、定義がより明確になります。

2.1.4. Defining a New Data Type

2.1.4. 新しいデータ型の定義

When a specification needs to define a new data type, it SHOULD follow the format used by the definitions in Section 3 of this document. The text at the start of the data type definition MUST describe the data type, including the expected use, and why a new data type is required. That text SHOULD include limits on expected values and why those limits exist. The fields "Name", "Value", "Length", and "Format" MUST be given, along with values.

仕様で新しいデータ型を定義する必要がある場合は、このドキュメントのセクション3の定義で使用されている形式に従う必要があります。データ型定義の最初のテキストは、予想される使用法を含むデータ型と、新しいデータ型が必要な理由を記述しなければなりません（MUST）。そのテキストには、期待値の制限とそれらの制限が存在する理由を含める必要があります（SHOULD）。「名前」、「値」、「長さ」、「形式」の各フィールドは、値とともに指定する必要があります。

The Name field SHOULD be a single name, all lowercase.

[名前]フィールドは、すべて小文字の単一の名前にする必要があります（SHOULD）。

Contractions such as "ipv4addr" are RECOMMENDED where they add clarity.

「ipv4addr」などの短縮形は、明確にするために推奨されます。

We note that the use of "Value" in the RADIUS "Data Type" registry can be confusing. That name is also used in attribute definitions, but with a different meaning. We trust that the meaning here is clear from the context.

RADIUSの「データタイプ」レジストリで「値」を使用すると混乱を招く可能性があることに注意してください。その名前は属性定義でも使用されますが、意味が異なります。ここでの意味は文脈から明らかであると信じています。

The Value field SHOULD be given as "TBD" in specifications. That number is assigned by IANA.

値フィールドは、仕様では「未定」として指定する必要があります。その番号はIANAによって割り当てられます。

The Format field SHOULD be defined with ASCII art in order to have a precise definition. Machine-readable formats are also RECOMMENDED.

正確な定義を行うために、フォーマットフィールドはASCIIアートで定義する必要があります（SHOULD）。機械可読形式も推奨されます。

The definition of a new data type should be done only when absolutely necessary. We do not expect a need for a large number of new data types. When defining a new data type, the guidelines of [RFC6929] with respect to data types MUST be followed.

新しいデータ型の定義は、どうしても必要な場合にのみ行ってください。多数の新しいデータ型が必要になるとは考えていません。新しいデータ型を定義するときは、データ型に関する[RFC6929]のガイドラインに従う必要があります。

It is RECOMMENDED that vendors not define "vendor-specific" data types. As discussed in [RFC6929], those data types are rarely necessary and can cause interoperability problems.

ベンダーが「ベンダー固有の」データ型を定義しないことをお勧めします。 [RFC6929]で説明されているように、これらのデータ型が必要になることはめったになく、相互運用性の問題を引き起こす可能性があります。

Any new data type MUST have a unique name in the RADIUS "Data Type" registry. The number of the data type will be assigned by IANA.

新しいデータタイプには、RADIUSの「データタイプ」レジストリで一意の名前を付ける必要があります。データ型の番号はIANAによって割り当てられます。

2.2. Implementation Use of Data Types

2.2. データ型の実装の使用

Implementations not supporting a particular data type MUST treat attributes of that data type as being of data type "string", as defined in Section 3.5. It is RECOMMENDED that such attributes be treated as "invalid attributes", as defined in [RFC6929], Section 2.8.

特定のデータ型をサポートしない実装は、セクション3.5で定義されているように、そのデータ型の属性を「文字列」のデータ型として扱う必要があります。 [RFC6929]のセクション2.8で定義されているように、そのような属性は「無効な属性」として扱うことをお勧めします。

Where the contents of a data type do not match the definition, implementations MUST treat the enclosing attribute as being an invalid attribute. This requirement includes, but is not limited to, the following situations:

データ型の内容が定義と一致しない場合、実装は囲んでいる属性を無効な属性として扱う必要があります。この要件には、次の状況が含まれますが、これらに限定されません。

* Attributes with values outside of the allowed range(s) for the data type, e.g., as given in the data types "integer", "ipv4addr", "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum".

* データタイプの許容範囲外の値を持つ属性。たとえば、データタイプ「integer」、「ipv4addr」、「ipv6addr」、「ipv4prefix」、「ipv6prefix」、または「enum」で指定されています。

* "text" attributes where the contents do not match the required format.

* 内容が必要な形式と一致しない「テキスト」属性。

* Attributes where the length is shorter or longer than the allowed length(s) for the given data type.

* 長さが指定されたデータ型で許可されている長さより短いか長い属性。

The requirements for Reserved fields are more difficult to quantify. Implementations SHOULD be able to receive and process attributes where Reserved fields are non-zero. We do not, however, define any "correct" processing of such attributes. Instead, specifications that define one or more new meanings for Reserved fields SHOULD describe how each new meaning is compatible with older implementations. We expect that such descriptions are derived from practical experience with implementations. Implementations MUST set Reserved fields to zero when creating attributes.

予約フィールドの要件を数値化するのはより困難です。実装は、予約済みフィールドがゼロ以外の属性を受信して処理できる必要があります（SHOULD）。ただし、そのような属性の「正しい」処理は定義していません。代わりに、予約済みフィールドの1つ以上の新しい意味を定義する仕様は、各新しい意味が古い実装とどのように互換性があるかを記述してください。このような記述は、実装に関する実際の経験から得られるものと期待しています。実装では、属性を作成するときに予約済みフィールドをゼロに設定する必要があります。

3. Data Type Definitions

3. データ型定義

This section defines the new data types. For each data type, it gives a definition, a name, a number, a length, and an encoding format. Where relevant, it describes subfields contained within the data type. These definitions have no impact on existing RADIUS implementations. There is no requirement that implementations use these names.

このセクションでは、新しいデータ型を定義します。各データ型について、定義、名前、数、長さ、およびエンコード形式を示します。関連する場合は、データ型に含まれるサブフィールドについて説明します。これらの定義は、既存のRADIUS実装に影響を与えません。実装でこれらの名前を使用する必要はありません。

Where possible, the name of each data type has been taken from previous specifications. In some cases, a different name has been chosen. The change of name is sometimes required to avoid ambiguity (i.e., "address" versus "Address"). Otherwise, the new name has been chosen to be compatible with [RFC2865] or with usage in common implementations. In some cases, new names are chosen to clarify the interpretation of the data type.

可能な場合、各データ型の名前は以前の仕様から取られています。場合によっては、別の名前が選択されています。あいまいさを避けるために、名前の変更が必要になる場合があります（つまり、「アドレス」と「アドレス」）。それ以外の場合、新しい名前は[RFC2865]と互換性があるか、一般的な実装での使用法と互換性があるように選択されています。場合によっては、データ型の解釈を明確にするために新しい名前が選択されます。

The numbers assigned herein for the data types have no meaning other than to permit them to be tracked by IANA. As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet. It is RECOMMENDED that new implementations use the names defined in this document in order to avoid confusion. Existing implementations may choose to use the names defined here, but that is not required.

ここでデータ型に割り当てられた番号は、IANAによる追跡を許可する以外の意味はありません。 RADIUSはパケット内のデータタイプに関する情報をエンコードしないため、データタイプに割り当てられた番号がパケット内で発生することはありません。混乱を避けるために、新しい実装ではこのドキュメントで定義されている名前を使用することをお勧めします。既存の実装では、ここで定義された名前を使用することを選択できますが、これは必須ではありません。

The encoding of each data type is taken from previous specifications. The fields are transmitted from left to right.

各データ型のエンコーディングは、以前の仕様から取得されます。フィールドは左から右に送信されます。

Where the data types have interdependencies, the simplest data type is given first, and dependent ones are given later.

データ型に相互依存関係がある場合、最も単純なデータ型が最初に示され、依存型が後で示されます。

We do not create specific data types for the "tagged" attributes (i.e., attributes containing a Tag field) defined in [RFC2868]. That specification defines the tagged attributes as being backwards compatible with pre-existing data types. In addition, [RFC6158], Section 2.1 says that tagged attributes should not be used. There is therefore no benefit to defining additional data types for these attributes. We trust that implementors will be aware that tagged attributes must be treated differently from non-tagged attributes of the same data type.

[RFC2868]で定義されている「タグ付けされた」属性（つまり、タグフィールドを含む属性）の特定のデータタイプは作成しません。この仕様では、タグ付き属性を既存のデータ型と下位互換性があると定義しています。また、[RFC6158]のセクション2.1では、タグ付き属性は使用しないでください。したがって、これらの属性に追加のデータ型を定義してもメリットはありません。タグ付けされた属性は、同じデータ型のタグ付けされていない属性とは異なる方法で処理する必要があることを実装者が認識していると確信しています。

Similarly, we do not create data types for some attributes having a complex structure, such as CHAP-Password, ARAP-Features, or Location-Information. ("CHAP" refers to the Challenge Handshake Authentication Protocol, and "ARAP" refers to the Apple Remote Access Protocol.) We need to strike a balance between correcting earlier mistakes and making this document more complex. In some cases, it is better to treat complex attributes as being of type "string", even though they need to be interpreted by RADIUS implementations. The guidelines given in Section 6.3 of [RFC6929] were used to make this determination.

同様に、CHAP-Password、ARAP-Features、Location-Informationなど、複雑な構造を持つ一部の属性のデータ型は作成しません。（「CHAP」はチャレンジハンドシェイク認証プロトコルを指し、「ARAP」はApple Remote Access Protocolを指します。）以前の間違いを修正することと、このドキュメントをより複雑にすることの間でバランスを取る必要があります。場合によっては、RADIUS実装で解釈する必要がある場合でも、複雑な属性を「文字列」タイプとして扱う方がよい場合があります。この決定には、[RFC6929]のセクション6.3に記載されているガイドラインが使用されました。

3.1. integer

3.1. 整数

The "integer" data type encodes a 32-bit unsigned integer in network byte order. Where the range of values for a particular attribute is limited to a subset of the values, specifications MUST define the valid range. Attributes with Values outside of the allowed ranges SHOULD be treated as invalid attributes.

「整数」データ型は、32ビットの符号なし整数をネットワークバイトオーダーでエンコードします。特定の属性の値の範囲が値のサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許容範囲外の値を持つ属性は、無効な属性として扱われる必要があります。

Name

名前

integer

整数

Value

値

１

Length

長さ

Four octets

4オクテット

Format

フォーマット

       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                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2. enum

3.2. 列挙型

The "enum" data type encodes a 32-bit unsigned integer in network byte order. It differs from the "integer" data type only in that it is used to define enumerated types, such as Service-Type (Section 5.6 of [RFC2865]). Specifications MUST define a valid set of enumerated values, along with a unique name for each value. Attributes with Values outside of the allowed enumerations SHOULD be treated as invalid attributes.

「enum」データ型は、32ビットの符号なし整数をネットワークバイトオーダーでエンコードします。「整数」データタイプとは、Service-Typeなどの列挙型の定義に使用される点のみが異なります（[RFC2865]のセクション5.6）。仕様では、列挙された値の有効なセットと、各値の一意の名前を定義する必要があります。許可された列挙の外の値を持つ属性は、無効な属性として扱われる必要があります。

Name

名前

enum

列挙型

Value

値

２

Length

長さ

Four octets

4オクテット

Format

フォーマット

       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                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3. time

3.3. 時間

The "time" data type encodes time as a 32-bit unsigned value in network byte order and in seconds since 00:00:00 UTC, January 1, 1970. We note that dates before the year 2017 are likely to indicate configuration errors or lack of access to the correct time.

「time」データ型は、1970年1月1日00:00:00 UTC以降の秒数で、ネットワークバイトオーダーの32ビット符号なし値として時刻をエンコードします。2017年より前の日付は、設定エラーまたは正しい時間へのアクセスの欠如。

Note that the "time" attribute is defined to be unsigned, which means that it is not subject to a signed integer overflow in the year 2038.

「time」属性は符号なしとして定義されていることに注意してください。これは、2038年に符号付き整数オーバーフローが発生しないことを意味します。

Name

名前

time

時間

Value

値

３

Length

長さ

Four octets

4オクテット

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Time                                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.4. text

3.4. テキスト

The "text" data type encodes UTF-8 text [RFC3629]. The maximum length of the text is given by the encapsulating attribute. Where the range of lengths for a particular attribute is limited to a subset of possible lengths, specifications MUST define the valid range(s). Attributes with lengths outside of the allowed values SHOULD be treated as invalid attributes.

「テキスト」データ型は、UTF-8テキストをエンコードします[RFC3629]。テキストの最大長は、encapsulating属性によって指定されます。特定の属性の長さの範囲が可能な長さのサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許可された値以外の長さを持つ属性は、無効な属性として扱われる必要があります。

Attributes of type "text" that are allocated in the standard space (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of data. Attributes of type "text" that are allocated in the extended space can be longer. In both cases, these limits are reduced when the data is encapsulated inside of another attribute.

標準スペース（[RFC6929]のセクション1.2）に割り当てられている「テキスト」タイプの属性は、253オクテット以下のデータに制限されています。拡張スペースに割り当てられるタイプ「テキスト」の属性は、長くなる可能性があります。どちらの場合も、データが別の属性の内部にカプセル化されると、これらの制限が緩和されます。

Where the text is intended to carry data in a particular format (e.g., Framed-Route), the format MUST be given. The specification SHOULD describe the format in a machine-readable way, such as via the Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with Values not matching the defined format SHOULD be treated as invalid attributes.

テキストが特定の形式（例、Framed-Route）でデータを運ぶことを意図している場合、形式を指定する必要があります。仕様は、拡張バッカスナウアフォーム（ABNF）[RFC5234]などを介して、機械で読み取り可能な方法で形式を記述する必要があります（SHOULD）。定義されたフォーマットと一致しない値を持つ属性は、無効な属性として扱われる必要があります。

Note that the "text" data type does not terminate with a NUL octet (hex 00). The Attribute has a Length field and does not use a terminator. Texts of length zero (0) MUST NOT be sent; omit the entire attribute instead.

「テキスト」データ型はNULオクテット（16進数00）で終了しないことに注意してください。属性には長さフィールドがあり、ターミネータを使用しません。長さがゼロ（0）のテキストは送信してはならない（MUST NOT）。代わりに、属性全体を省略してください。

Name

名前

text

テキスト

Value

値

４

Length

長さ

One or more octets

1つ以上のオクテット

Format

フォーマット

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Value    ...
      +-+-+-+-+-+-+-+-

3.5. string

3.5. ストリング

The "string" data type encodes binary data as a sequence of undistinguished octets. Where the range of lengths for a particular attribute is limited to a subset of possible lengths, specifications MUST define the valid range(s). Attributes with lengths outside of the allowed values SHOULD be treated as invalid attributes.

「string」データ型は、バイナリデータを一連の区別されないオクテットとしてエンコードします。特定の属性の長さの範囲が可能な長さのサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許可された値以外の長さを持つ属性は、無効な属性として扱われる必要があります。

Attributes of type "string" that are allocated in the standard space (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of data. Attributes of type "string" that are allocated in the extended space can be longer. In both cases, these limits are reduced when the data is encapsulated inside of another attribute.

標準スペース（[RFC6929]のセクション1.2）に割り当てられる「文字列」タイプの属性は、253オクテット以下のデータに制限されます。拡張スペースに割り当てられる「string」タイプの属性は、長くなる可能性があります。どちらの場合も、データが別の属性の内部にカプセル化されると、これらの制限が緩和されます。

Note that the "string" data type does not terminate with a NUL octet (hex 00). The Attribute has a Length field and does not use a terminator. Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. Where there is a need to encapsulate complex data structures and TLVs cannot be used, the "string" data type MUST be used. This requirement includes encapsulation of data structures defined outside of RADIUS that are opaque to the RADIUS infrastructure. It also includes encapsulation of some data structures that are not opaque to RADIUS, such as the contents of CHAP-Password.

「string」データ型は、NULオクテット（16進数00）で終了しないことに注意してください。属性には長さフィールドがあり、ターミネータを使用しません。長さがゼロ（0）のストリングは送信してはなりません（MUST NOT）。代わりに、属性全体を省略してください。複雑なデータ構造をカプセル化する必要があり、TLVを使用できない場合は、「文字列」データタイプを使用する必要があります。この要件には、RADIUSインフラストラクチャに対して不透明な、RADIUS外で定義されたデータ構造のカプセル化が含まれます。また、CHAP-Passwordのコンテンツなど、RADIUSに不透明ではない一部のデータ構造のカプセル化も含まれます。

There is little reason to define a new RADIUS data type for only one attribute. However, where the complex data type cannot be represented as TLVs and is expected to be used in many attributes, a new data type SHOULD be defined.

1つの属性に対してのみ新しいRADIUSデータタイプを定義する理由はほとんどありません。ただし、複合データ型をTLVとして表すことができず、多くの属性で使用されることが予想される場合は、新しいデータ型を定義する必要があります（SHOULD）。

These requirements are stronger than [RFC6158], which makes the above encapsulation a "SHOULD". This document defines data types for use in RADIUS, so there are few reasons to avoid using them.

これらの要件は、上記のカプセル化を「SHOULD」にする[RFC6158]よりも強力です。このドキュメントでは、RADIUSで使用するデータタイプを定義しているため、それらを使用しない理由はいくつかあります。

Name

名前

string

ストリング

Value

値

５

Length

長さ

One or more octets

1つ以上のオクテット

Format

フォーマット

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...
      +-+-+-+-+-+-+-+-

3.6. concat

3.6. 連結

The "concat" data type permits the transport of more than 253 octets of data in a "standard space" [RFC6929] attribute. It is otherwise identical to the "string" data type.

「concat」データ型は、「標準スペース」[RFC6929]属性で253オクテットを超えるデータの転送を許可します。それ以外は「文字列」データ型と同じです。

If multiple attributes of this data type are contained in a packet, all attributes of the same type code MUST be in order, and they MUST be consecutive attributes in the packet.

このデータ型の複数の属性がパケットに含まれている場合、同じ型コードのすべての属性が正しい必要があり、それらはパケット内の連続した属性でなければなりません。

The amount of data transported in a "concat" data type can be no more than the RADIUS packet size. In practice, the requirement to transport multiple attributes means that the limit may be substantially smaller than one RADIUS packet. As a rough guide, it is RECOMMENDED that this data type transport no more than 2048 octets of data.

「concat」データタイプで転送されるデータの量は、RADIUSパケットサイズを超えることはできません。実際には、複数の属性をトランスポートする要件は、制限が1つのRADIUSパケットよりも大幅に小さくなる可能性があることを意味します。大まかなガイドとして、このデータ型は2048オクテット以下のデータを転送することをお勧めします。

The "concat" data type MAY be used for "standard space" attributes. It MUST NOT be used for attributes in the "short extended space" or the "long extended space". It MUST NOT be used in any field or subfields of the following data types: "tlv", "vsa", "extended", "long-extended", or "evs".

「concat」データ型は、「標準スペース」属性に使用される場合があります。「短い拡張スペース」または「長い拡張スペース」の属性には使用しないでください。「tlv」、「vsa」、「extended」、「long-extended」、または「evs」のデータタイプのフィールドまたはサブフィールドでは使用しないでください。

Name

名前

concat

連結

Value

値

６

Length

長さ

One or more octets

1つ以上のオクテット

Format

フォーマット

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...
      +-+-+-+-+-+-+-+-

3.7. ifid

The "ifid" data type encodes an Interface-Id as an 8-octet IPv6 Interface Identifier in network byte order.

「ifid」データ型は、ネットワークバイトオーダーで8オクテットIPv6インターフェース識別子としてインターフェースIDをエンコードします。

Name

名前

ifid

Value

値

７

Length

長さ

Eight octets

8オクテット

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Interface-Id ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Interface-Id                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.8. ipv4addr

The "ipv4addr" data type encodes an IPv4 address in network byte order. Where the range of addresses for a particular attribute is limited to a subset of possible addresses, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.

「ipv4addr」データタイプは、IPv4アドレスをネットワークバイトオーダーでエンコードします。特定の属性のアドレスの範囲が可能なアドレスのサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許容範囲外のアドレス値を持つ属性は、無効な属性として扱われる必要があります。

Name

名前

ipv4addr

Value

値

８

Length

長さ

Four octets

4オクテット

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Address                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.9. ipv6addr

The "ipv6addr" data type encodes an IPv6 address in network byte order. Where the range of addresses for a particular attribute is limited to a subset of possible addresses, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.

「ipv6addr」データタイプは、IPv6アドレスをネットワークバイトオーダーでエンコードします。特定の属性のアドレスの範囲が可能なアドレスのサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許容範囲外のアドレス値を持つ属性は、無効な属性として扱われる必要があります。

Name

名前

ipv6addr

Value

値

９

Length

長さ

Sixteen octets

16オクテット

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address                                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.10. ipv6prefix

The "ipv6prefix" data type encodes an IPv6 prefix, using both a prefix length and an IPv6 address in network byte order. Where the range of prefixes for a particular attribute is limited to a subset of possible prefixes, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.

「ipv6prefix」データタイプは、ネットワークバイトオーダーでプレフィックス長とIPv6アドレスの両方を使用して、IPv6プレフィックスをエンコードします。特定の属性の接頭辞の範囲が可能な接頭辞のサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許容範囲外のアドレス値を持つ属性は、無効な属性として扱われる必要があります。

Attributes with a Prefix-Length field having a value greater than 128 MUST be treated as invalid attributes.

128より大きい値を持つPrefix-Lengthフィールドを持つ属性は、無効な属性として扱われる必要があります。

Name

名前

ipv6prefix

Value

値

１０

Length

長さ

At least two, and no more than eighteen, octets

少なくとも2つ、18以下のオクテット

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   | Prefix-Length |  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

Reserved

予約済み

This field, which is reserved and MUST be present, is always set to zero. This field is one octet in length.

このフィールドは予約されており、存在する必要がありますが、常にゼロに設定されています。このフィールドの長さは1オクテットです。

Prefix-Length

プレフィックス長

The length of the prefix, in bits. At least 0 and no larger than 128. This field is one octet in length.

接頭辞の長さ（ビット単位）。 0以上、128以下。このフィールドの長さは1オクテット。

Prefix

接頭辞

The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, MUST be zero.

プレフィックスフィールドの長さは最大16オクテットです。含まれている場合、Prefix-Lengthの外側のビットはゼロでなければなりません。

The Prefix field SHOULD NOT contain more octets than necessary to encode the Prefix field.

Prefixフィールドは、Prefixフィールドをエンコードするために必要な数よりも多くのオクテットを含むべきではありません（SHOULD NOT）。

3.11. ipv4prefix

The "ipv4prefix" data type encodes an IPv4 prefix, using both a prefix length and an IPv4 address in network byte order. Where the range of prefixes for a particular attribute is limited to a subset of possible prefixes, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.

「ipv4prefix」データタイプは、ネットワークバイトオーダーでプレフィックス長とIPv4アドレスの両方を使用して、IPv4プレフィックスをエンコードします。特定の属性の接頭辞の範囲が可能な接頭辞のサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許容範囲外のアドレス値を持つ属性は、無効な属性として扱われる必要があります。

Attributes with a Prefix-Length field having a value greater than 32 MUST be treated as invalid attributes.

32より大きい値を持つPrefix-Lengthフィールドを持つ属性は、無効な属性として扱われる必要があります。

Name

名前

ipv4prefix

Value

値

１１

Length

長さ

Six octets

6バイト

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   | Prefix-Length |  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

Reserved

予約済み

This field, which is reserved and MUST be present, is always set to zero. This field is one octet in length.

このフィールドは予約されており、存在する必要がありますが、常にゼロに設定されています。このフィールドの長さは1オクテットです。

Note that this definition differs from that given in [RFC6572]. See "Prefix-Length", below, for an explanation.

この定義は[RFC6572]で与えられたものとは異なることに注意してください。説明については、以下の「Prefix-Length」を参照してください。

Prefix-Length

プレフィックス長

The length of the prefix, in bits. The values MUST be no larger than 32. This field is one octet in length. Note that this definition differs from that given in [RFC6572].

接頭辞の長さ（ビット単位）。値は32以下にする必要があります。このフィールドの長さは1オクテットです。この定義は[RFC6572]で与えられたものとは異なることに注意してください。

As compared to [RFC6572], the Prefix-Length field has increased in size by two bits, both of which must be zero. The Reserved field has decreased in size by two bits. The result is that both fields are aligned on octet boundaries, which removes the need for bit masking of the fields.

[RFC6572]と比較して、Prefix-Lengthフィールドのサイズが2ビット増加しましたが、どちらもゼロでなければなりません。予約済みフィールドのサイズが2ビット減少しました。その結果、両方のフィールドがオクテット境界に配置されるため、フィールドのビットマスキングが不要になります。

Since [RFC6572] required the Reserved field to be zero, the definition here is compatible with the definition in the original specification.

[RFC6572]では予約フィールドをゼロにする必要があったため、ここでの定義は元の仕様の定義と互換性があります。

Prefix

接頭辞

The Prefix field is 4 octets in length. Bits outside of the Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, this field is fixed length. If the address is all zeros (i.e., "0.0.0.0"), then the Prefix-Length MUST be set to 32.

プレフィックスフィールドの長さは4オクテットです。 Prefix-Lengthの外側のビットはゼロでなければなりません。「ipv6prefix」データタイプとは異なり、このフィールドは固定長です。アドレスがすべてゼロ（つまり、「0.0.0.0」）の場合、Prefix-Lengthを32に設定する必要があります。

3.12. integer64

The "integer64" data type encodes a 64-bit unsigned integer in network byte order. Where the range of values for a particular attribute is limited to a subset of the values, specifications MUST define the valid range(s). Attributes with Values outside of the allowed range(s) SHOULD be treated as invalid attributes.

「integer64」データ型は、64ビットの符号なし整数をネットワークバイトオーダーでエンコードします。特定の属性の値の範囲が値のサブセットに制限されている場合、仕様は有効な範囲を定義する必要があります。許容範囲外の値を持つ属性は、無効な属性として扱われる必要があります。

Name

名前

integer64

Value

値

１２

Length

長さ

Eight octets

8オクテット

Format

フォーマット

       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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ... Value                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.13. tlv

The "tlv" data type encodes a Type-Length-Value, as defined in [RFC6929], Section 2.3.

「tlv」データ型は、[RFC6929]のセクション2.3で定義されているように、Type-Length-Valueをエンコードします。

Name

名前

tlv

Value

値

１３

Length

長さ

Three or more octets

3オクテット以上

Format

フォーマット

       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-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

TLV-Type

TLVタイプ

This field is one octet. Up-to-date values of this field are specified according to the policies and rules described in [RFC6929], Section 10. Values of 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.

このフィールドは1オクテットです。このフィールドの最新の値は、[RFC6929]のセクション10で説明されているポリシーとルールに従って指定されます。値254-255は、RADIUSの将来の拡張で使用するために予約されています。値26には特別な意味はなく、ベンダー固有属性として扱われてはいけません。

The TLV-Type is meaningful only within the context defined by Type fields of the encapsulating Attributes, using the dotted-number notation introduced in [RFC6929].

TLV-Typeは、[RFC6929]で導入されたドット付き数表記を使用して、カプセル化属性の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 is handled as per [RFC6929], Section 2.8.

TLV-Lengthフィールドは1オクテットで、TLV-Type、TLV-Length、およびTLV-Valueフィールドを含む、このTLVの長さを示します。これは3から255の間の値を持つ必要があります。クライアントまたはサーバーが無効なTLV-Lengthを持つTLVを受信した場合、そのTLVをカプセル化する属性は無効な属性と見なされなければならず、[RFC6929]のセクションに従って処理されます。 2.8。

TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the entire TLV instead.

TLV-Lengthが2のTLVは送信してはなりません（MUST NOT）。代わりにTLV全体を省略してください。

TLV-Data

TLVデータ

The TLV-Data field is one or more octets and contains information specific to the attribute. The format and length of the TLV-Data field are determined by the TLV-Type and TLV-Length fields.

TLV-Dataフィールドは1つ以上のオクテットであり、属性に固有の情報が含まれています。 TLV-Dataフィールドのフォーマットと長さは、TLV-TypeフィールドとTLV-Lengthフィールドによって決まります。

The TLV-Data field MUST contain only known RADIUS data types. The TLV-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs".

TLV-Dataフィールドには、既知のRADIUSデータタイプのみを含める必要があります。 TLV-Dataフィールドには、「concat」、「vsa」、「extended」、「long-extended」、「evs」のいずれかのデータ型を含めることはできません。

3.14. vsa

3.14. すべて

The "vsa" data type encodes vendor-specific data, as given in [RFC2865], Section 5.26. It is used only in the Attr-Data field of a Vendor-Specific Attribute. It MUST NOT appear in the contents of any other data type.

[vsa]データタイプは、[RFC2865]、セクション5.26に記載されているように、ベンダー固有のデータをエンコードします。これは、ベンダー固有属性のAttr-Dataフィールドでのみ使用されます。他のデータ型のコンテンツに現れてはいけません。

Where an implementation determines that an attribute of data type "vsa" contains data that does not match the expected format, it SHOULD treat that attribute as being an invalid attribute.

データ型「vsa」の属性に予期される形式と一致しないデータが含まれていると実装が判断した場合、その属性を無効な属性として扱う必要があります。

Name

名前

vsa

すべて

Value

値

１４

Length

長さ

Five or more octets

5オクテット以上

Format

フォーマット

       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                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VSA-Data ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

Vendor-Id

ベンダーID

The 4 octets are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.

4オクテットは、ネットワークバイトオーダーでのベンダーのNetwork Management Private Enterprise Code [PEN]です。

VSA-Data

The VSA-Data field is one or more octets. The actual format of the information is site specific or application specific, and a robust implementation SHOULD support the field as undistinguished octets.

VSA-Dataフィールドは1つ以上のオクテットです。情報の実際の形式は、サイト固有またはアプリケーション固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。

The codification of the range of allowed usage of this field is outside the scope of this specification.

このフィールドの使用許可の範囲の体系化は、この仕様の範囲外です。

The "vsa" data type SHOULD contain a sequence of "tlv" data types. The interpretation of the TLV-Type and TLV-Data fields is dependent on the vendor's definition of that attribute.

"vsa"データ型には、一連の "tlv"データ型を含める必要があります（SHOULD）。 TLV-TypeおよびTLV-Dataフィールドの解釈は、ベンダーによるその属性の定義に依存します。

The "vsa" data type MUST be used as the contents of the Attr-Data field of the Vendor-Specific Attribute. The "vsa" data type MUST NOT appear in the contents of any other data type.

「vsa」データタイプは、ベンダー固有属性のAttr-Dataフィールドのコンテンツとして使用する必要があります。「vsa」データタイプは、他のデータタイプのコンテンツに表示してはなりません。

3.15. extended

3.15. 拡張

The "extended" data type encodes the "Extended Type" format, as given in [RFC6929], Section 2.1. It is used only in the Attr-Data field of an attribute allocated from the standard space. It MUST NOT appear in the contents of any other data type.

[拡張]データタイプは、[RFC6929]のセクション2.1で規定されているように、「拡張タイプ」フォーマットをエンコードします。これは、標準スペースから割り当てられた属性のAttr-Dataフィールドでのみ使用されます。他のデータ型のコンテンツに現れてはいけません。

Name

名前

extended

拡張

Value

値

１５

Length

長さ

Two or more octets

2オクテット以上

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extended-Type | Ext-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

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 [RFC6929], 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オクテットです。このフィールドの最新の値は、[RFC6929]、セクション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 [RFC6929], Section 2.1 for additional discussion.

Extended-Typeは、Typeフィールドで定義されたコンテキスト内でのみ意味があります。つまり、このフィールドは、 "Type.Extended-Type"という形式の新しいタイプスペースを定義していると考えることができます。詳細については、[RFC6929]のセクション2.1をご覧ください。

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）。

Ext-Data

外部データ

The Ext-Data field is one or more octets.

Ext-Dataフィールドは1つ以上のオクテットです。

The contents of this field MUST be a valid data type as defined in the RADIUS "Data Type" registry. The Ext-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs".

このフィールドの内容は、RADIUSの「データタイプ」レジストリで定義されている有効なデータタイプである必要があります。 Ext-Dataフィールドには、「concat」、「vsa」、「extended」、「long-extended」、または「evs」のデータ型を含めることはできません。

Implementations supporting this specification MUST use the Identifier of "Type.Extended-Type" to determine the interpretation of the Ext-Data field.

この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、Ext-Dataフィールドの解釈を決定する必要があります。

3.16. long-extended

3.16. 長期延長

The "long-extended" data type encodes the "Long Extended Type" format, as given in [RFC6929], Section 2.2. It is used only in the Attr-Data field of an attribute. It MUST NOT appear in the contents of any other data type.

[long-extended]データ型は、[RFC6929]のセクション2.2にあるように、「Long Extended Type」形式をエンコードします。これは、属性のAttr-Dataフィールドでのみ使用されます。他のデータ型のコンテンツに現れてはいけません。

Name

名前

long-extended

長期延長

Value

値

１６

Length

長さ

Three or more octets

3オクテット以上

Format

フォーマット

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extended-Type |M|T| Reserved  | Ext-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

Extended-Type

拡張タイプ

This field is identical to the Extended-Type field defined above in Section 3.15.

このフィールドは、上記のセクション3.15で定義されたExtended-Typeフィールドと同じです。

M (More)

M（もっと）

The More field (M flag) 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 less than 255. The More field MAY be set (1) if the Length field has a value of 255.

Moreフィールド（Mフラグ）は1ビット長で、現在の属性に251オクテットを超えるデータが含まれているかどうかを示します。長さフィールドの値が255未満の場合、詳細フィールドはクリア（0）でなければなりません。長さフィールドの値が255の場合、詳細フィールドを設定できます（1）。

If the More field is set (1), it indicates that the Ext-Data field has been fragmented across multiple RADIUS attributes.

Moreフィールドが設定されている場合（1）、Ext-Dataフィールドが複数のRADIUS属性にわたってフラグメント化されていることを示します。

When the More field is set (1), the Attribute MUST have a Length field value of 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）、属性には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 is handled as per [RFC6929], Section 2.8.

クライアントまたはサーバーがMoreフィールドセット（1）の属性フラグメントを受信しても、後続のフラグメントが見つからない場合、フラグメント化された属性は無効な属性と見なされ、[RFC6929]のセクション2.8に従って処理されます。。

T (Truncation)

T（切り捨て）

This field is one bit in size and is called "T" for Truncation. It indicates that the attribute is intentionally truncated in this chunk and is to be continued in the next chunk of the sequence. The combination of the M flag and the T flag indicates that the attribute is fragmented (M flag) but that all of the fragments are not available in this chunk (T flag). Proxies implementing [RFC6929] will see these attributes as invalid (they will not be able to reconstruct them), but they will still forward them, as Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown attributes anyway.

このフィールドのサイズは1ビットで、切り捨ての場合は「T」と呼ばれます。これは、属性がこのチャンクで意図的に切り捨てられ、シーケンスの次のチャンクで継続されることを示しています。 MフラグとTフラグの組み合わせは、属性がフラグメント化されている（Mフラグ）が、このチャンクではすべてのフラグメントが使用可能ではない（Tフラグ）ことを示します。 [RFC6929]を実装するプロキシはこれらの属性を無効と見なします（再構築できません）が、[RFC6929]のセクション5.2は未知の属性を転送する必要があることを示しているため、引き続き転送します。

Please see [RFC7499] for further discussion of the uses of this flag.

このフラグの使用の詳細については、[RFC7499]を参照してください。

Reserved

予約済み

This field is six 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.

このフィールドは6ビット長で、将来の使用のために予約されています。実装は、パケットを送信するための属性をエンコードするときに、ゼロ（0）に設定する必要があります。内容は受信時に無視する必要があります。

Future specifications may define one or more additional meanings for this field. Implementations therefore MUST NOT treat this field as invalid if it is non-zero.

将来の仕様では、このフィールドに1つ以上の追加の意味が定義される可能性があります。したがって、実装では、このフィールドがゼロ以外の場合は無効として扱わないでください。

Ext-Data

外部データ

The Ext-Data field is one or more octets.

Implementations supporting this specification MUST use the Identifier of "Type.Extended-Type" to determine the interpretation of the Ext-Data field.

この仕様をサポートする実装は、「Type.Extended-Type」の識別子を使用して、Ext-Dataフィールドの解釈を決定する必要があります。

The length of the data MUST be taken as the sum of the lengths of the fragments (i.e., Ext-Data fields) from which it is constructed. Any interpretation of the resulting data MUST occur after the fragments have been reassembled. If the reassembled data does not match the expected format, each fragment MUST be treated as an invalid attribute, and the reassembled data MUST be discarded.

データの長さは、それが構成されているフラグメント（つまり、Ext-Dataフィールド）の長さの合計と見なさなければなりません（MUST）。結果のデータの解釈は、フラグメントが再構成された後に発生する必要があります。再構成されたデータが予期された形式と一致しない場合、各フラグメントは無効な属性として扱われなければならず、再構成されたデータは破棄されなければなりません（MUST）。

We note that the maximum size of a fragmented attribute is limited only by the RADIUS packet length limitation. Implementations MUST be able to handle the case where one fragmented attribute completely fills the packet.

フラグメント化された属性の最大サイズは、RADIUSパケット長の制限によってのみ制限されることに注意してください。実装は、1つの断片化された属性がパケットを完全に埋める場合を処理できなければなりません（MUST）。

3.17. evs

The "evs" data type encodes an Extended-Vendor-Specific Attribute, as given in [RFC6929], Section 2.4. The "evs" data type is used solely to extend the vendor-specific space. It MAY appear inside of an "extended" data type or a "long-extended" data type. It MUST NOT appear in the contents of any other data type.

[evs]データ型は、[RFC6929]のセクション2.4に記載されているように、拡張ベンダー固有の属性をエンコードします。「evs」データ型は、ベンダー固有のスペースを拡張するためにのみ使用されます。「拡張」データ型または「長い拡張」データ型の内部に表示される場合があります。他のデータ型のコンテンツに現れてはいけません。

Where an implementation determines that an attribute of data type "evs" contains data that does not match the expected format, it SHOULD treat that attribute as being an invalid attribute.

データ型「evs」の属性に予期される形式と一致しないデータが含まれていると実装が判断した場合、実装はその属性を無効な属性として扱う必要があります。

Name

evs

EVS

Value

値

１７

Length

長さ

Six or more octets

6オクテット以上

Format

フォーマット

       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                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vendor-Type   |  EVS-Data ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subfields

サブフィールド

Vendor-Id

ベンダーID

The 4 octets are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.

Vendor-Type

ベンダータイプ

The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.

EVS-Data

The EVS-Data field is one or more octets. It SHOULD encapsulate a previously defined RADIUS data type. Non-standard data types SHOULD NOT be used. We note that the EVS-Data field may be of data type "tlv".

EVS-Dataフィールドは1つ以上のオクテットです。以前に定義されたRADIUSデータ型をカプセル化する必要があります。非標準のデータ型は使用しないでください。 EVS-Dataフィールドのデータ型は「tlv」である可能性があることに注意してください。

The actual format of the information is site specific or application specific, and a robust implementation SHOULD support the field as undistinguished octets. We recognize that vendors have complete control over the contents and format of the Ext-Data field; at the same time, we recommend that good practices be followed.

情報の実際の形式は、サイト固有またはアプリケーション固有であり、堅牢な実装では、フィールドを区別されないオクテットとしてサポートする必要があります（SHOULD）。ベンダーはExt-Dataフィールドの内容と形式を完全に制御できることを認識しています。同時に、優れたプラクティスに従うことをお勧めします。

Further codification of the range of allowed usage of this field is outside the scope of this specification.

このフィールドの許可された使用法の範囲をさらに体系化することは、この仕様の範囲外です。

4. Updated Registries

4. 更新されたレジストリ

This section defines a new IANA registry for RADIUS data types and then updates the existing "RADIUS Attribute Types" registry to use the data types from the new registry.

このセクションでは、RADIUSデータ型の新しいIANAレジストリを定義し、既存の「RADIUS Attribute Types」レジストリを更新して、新しいレジストリのデータ型を使用します。

4.1. New "Data Type" Registry

4.1. 新しい「データタイプ」レジストリ

This section defines a new registry located under "RADIUS Types", called "Data Type". The registration procedures for the "Data Type" registry are "Standards Action" [RFC5226].

このセクションでは、「データタイプ」と呼ばれる「RADIUSタイプ」の下にある新しいレジストリを定義します。「Data Type」レジストリの登録手順は「Standards Action」[RFC5226]です。

The "Data Type" registry contains three columns of data, as follows.

「データタイプ」レジストリには、次の3つのデータ列が含まれています。

Value

The number of the data type. The Value field is an artifact of the registry and has no on-the-wire meaning.

データ型の数。値フィールドはレジストリのアーティファクトであり、ネットワーク上の意味はありません。

Description

The name of the data type. This field is used only for the registry and has no on-the-wire meaning.

データ型の名前。このフィールドはレジストリにのみ使用され、ネットワーク上の意味はありません。

Reference

参照

The specification where the data type was defined.

データ型が定義された仕様。

The initial contents of the registry are as follows.

      Value  Description    Reference
      -----  -----------    -------------------
          1  integer        [RFC2865], RFC 8044
          2  enum           [RFC2865], RFC 8044
          3  time           [RFC2865], RFC 8044
          4  text           [RFC2865], RFC 8044
          5  string         [RFC2865], RFC 8044
          6  concat         RFC 8044
          7  ifid           [RFC3162], RFC 8044
          8  ipv4addr       [RFC2865], RFC 8044
          9  ipv6addr       [RFC3162], RFC 8044
         10  ipv6prefix     [RFC3162], RFC 8044
         11  ipv4prefix     [RFC6572], RFC 8044
         12  integer64      [RFC6929], RFC 8044
         13  tlv            [RFC6929], RFC 8044
         14  vsa            [RFC2865], RFC 8044
         15  extended       [RFC6929], RFC 8044
         16  long-extended  [RFC6929], RFC 8044
         17  evs            [RFC6929], RFC 8044

4.2. Updates to the "RADIUS Attribute Types" Registry

4.2. 「RADIUS Attribute Types」レジストリの更新

This section updates the "RADIUS Attribute Types" registry to have a new column, which is inserted between the existing "Description" and "Reference" columns. The new column is named "Data Type". The contents of that column are the name of a data type, corresponding to the attribute in that row, or blank if the Attribute Type is unassigned. The name of the data type is taken from the RADIUS "Data Type" registry, as defined above.

このセクションでは、「RADIUS Attribute Types」レジストリを更新して、既存の「Description」列と「Reference」列の間に挿入される新しい列を追加します。新しい列の名前は「データタイプ」です。その列の内容は、その行の属性に対応するデータ型の名前、または属性型が割り当てられていない場合は空白です。データタイプの名前は、上記で定義したように、RADIUSの「データタイプ」レジストリから取得されます。

The existing registration requirements for the "RADIUS Attribute Types" registry are otherwise unchanged.

「RADIUS Attribute Types」レジストリの既存の登録要件は、それ以外は変更されていません。

5. Security Considerations

This specification is concerned solely with updates to IANA registries. As such, there are no security considerations with the document itself.

この仕様は、IANAレジストリの更新にのみ関係しています。したがって、ドキュメント自体に関するセキュリティ上の考慮事項はありません。

However, the use of inconsistent names and poorly defined entities in a protocol is problematic. Inconsistencies in specifications can lead to security and interoperability problems in implementations. Further, having one canonical source for the definition of data types means that an implementor has fewer specifications to read. The implementation work is therefore simpler and more likely to be correct.

ただし、プロトコルで一貫性のない名前や定義が不十分なエンティティを使用すると問題が発生します。仕様の不整合は、実装におけるセキュリティと相互運用性の問題につながる可能性があります。さらに、データ型を定義するための1つの標準的なソースを持つことは、実装者が読み取る仕様が少なくなることを意味します。したがって、実装作業はより簡単で、正しい可能性が高くなります。

The goal of this specification is to reduce ambiguities in the RADIUS protocol, which we believe will lead to more robust and more secure implementations.

この仕様の目標は、RADIUSプロトコルのあいまいさを減らすことです。これにより、より堅牢でより安全な実装につながると信じています。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has created one new registry, as described in Section 4.1.

セクション4.1で説明されているように、IANAは1つの新しいレジストリを作成しました。

IANA has updated the "RADIUS Attribute Types" registry, as described in Section 4.2.

セクション4.2で説明されているように、IANAは「RADIUS Attribute Types」レジストリを更新しました。

IANA requires that all allocation requests in the "RADIUS Attribute Types" registry contain a Data Type field, which is required to contain one of the "Data Type" names contained in the RADIUS "Data Type" registry.

IANAでは、「RADIUS Attribute Types」レジストリ内のすべての割り当てリクエストに、RADIUS「Data Type」レジストリに含まれる「Data Type」名のいずれかを含める必要があるData Typeフィールドが含まれている必要があります。

IANA requires that updates to the RADIUS "Data Type" registry contain the following fields, with the associated instructions:

* Value. IANA is instructed to assign the next unused integer in sequence to new data type definitions.

* 値。 IANAは、次の未使用の整数を新しいデータ型定義に順に割り当てるように指示されます。

* Name. IANA is instructed to require that this name be unique in the registry.

* 名前。 IANAは、この名前がレジストリ内で一意であることを要求するように指示されています。

* Reference. IANA is instructed to update this field with a reference to the document that defines the data type.

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.

[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, DOI 10.17487/RFC3162, August 2001, <http://www.rfc-editor.org/info/rfc3162>.

[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「RADIUS and IPv6」、RFC 3162、DOI 10.17487 / RFC3162、2001年8月、<http://www.rfc-editor.org/info/ rfc3162>。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。

[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <http://www.rfc-editor.org/info/rfc4072>.

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。

[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, <http://www.rfc-editor.org/info/rfc6158>.

[RFC6158] DeKok、A.、Ed。、およびG. Weber、「RADIUS Design Guidelines」、BCP 158、RFC 6158、DOI 10.17487 / RFC6158、2011年3月、<http://www.rfc-editor.org/info / rfc6158>。

[RFC6572] Xia, F., Sarikaya, B., Korhonen, J., Ed., Gundavelli, S., and D. Damic, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, DOI 10.17487/RFC6572, June 2012, <http://www.rfc-editor.org/info/rfc6572>.

[RFC6572] Xia、F.、Sarikaya、B.、Korhonen、J.、Ed。、Gundavelli、S。、およびD. Damic、「RADIUS Support for Proxy Mobile IPv6」、RFC 6572、DOI 10.17487 / RFC6572、June 2012 、<http://www.rfc-editor.org/info/rfc6572>。

[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015, <http://www.rfc-editor.org/info/rfc7499>.

[RFC7499] Perez-Mendez、A.、Ed。、Marin-Lopez、R.、Pereniguez-Garcia、F.、Lopez-Millan、G.、Lopez、D。、およびA. DeKok、「RADIUSのフラグメンテーションのサポートパケット」、RFC 7499、DOI 10.17487 / RFC7499、2015年4月、<http://www.rfc-editor.org/info/rfc7499>。

7.2. Informative References

7.2. 参考引用

[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://www.iana.org/assignments/enterprise-numbers/>.

[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, DOI 10.17487/RFC2868, June 2000, <http://www.rfc-editor.org/info/rfc2868>.

[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRADIUS属性」、RFC 2868、DOI 10.17487 / RFC2868、 2000年6月、<http://www.rfc-editor.org/info/rfc2868>。

[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000, <http://www.rfc-editor.org/info/rfc2869>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。

[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.

[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、RFC 6929、DOI 10.17487 / RFC6929、2013年4月、<http://www.rfc-editor.org/ info / rfc6929>。

[RFC7268] Aboba, B., Malinen, J., Congdon, P., Salowey, J., and M. Jones, "RADIUS Attributes for IEEE 802 Networks", RFC 7268, DOI 10.17487/RFC7268, July 2014, <http://www.rfc-editor.org/info/rfc7268>.

[RFC7268] Aboba、B.、Malinen、J.、Congdon、P.、Salowey、J。、およびM. Jones、「IEEE 802ネットワークのRADIUS属性」、RFC 7268、DOI 10.17487 / RFC7268、2014年7月、<http ：//www.rfc-editor.org/info/rfc7268>。

Acknowledgments

謝辞

Thanks to the RADEXT WG participants for their patience and reviews of this document.

RADEXT WGの参加者の忍耐とこのドキュメントのレビューに感謝します。

Author's Address

著者のアドレス

Alan DeKok The FreeRADIUS Server Project

   Email: aland@freeradius.org