[要約] RFC 4675は、仮想LANと優先サポートのためのRADIUS属性に関する規格です。このRFCの目的は、ネットワーク管理者がRADIUSを使用して仮想LANと優先サポートを効果的に管理できるようにすることです。
Network Working Group P. Congdon
Request for Comments: 4675 M. Sanchez
Category: Standards Track Hewlett-Packard Company
B. Aboba
Microsoft Corporation
September 2006
RADIUS Attributes for Virtual LAN and Priority Support
仮想LANおよび優先サポートのRADIUS属性
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS or Diameter.
このドキュメントは、IEEE 802ローカルエリアネットワークへのアクセスの提供に使用するために、動的仮想LAN割り当てと優先順位付けのための追加のリモート認証ダイヤルインユーザーサービス（RADIUS）属性を提案します。これらの属性は、半径または直径内で使用可能です。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Requirements Language ......................................3
1.3. Attribute Interpretation ...................................3
2. Attributes ......................................................4
2.1. Egress-VLANID ..............................................4
2.2. Ingress-Filters ............................................6
2.3. Egress-VLAN-Name ...........................................7
2.4. User-Priority-Table ........................................8
3. Table of Attributes ............................................10
4. Diameter Considerations ........................................10
5. IANA Considerations ............................................11
6. Security Considerations ........................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................13
8. Acknowledgements ...............................................13
This document describes Virtual LAN (VLAN) and re-prioritization attributes that may prove useful for provisioning of access to IEEE 802 local area networks [IEEE-802] with the Remote Authentication Dial-In User Service (RADIUS) or Diameter.
このドキュメントでは、リモート認証ダイヤルインユーザーサービス（RADIUS）または直径を使用して、IEEE 802ローカルエリアネットワーク[IEEE-802]へのアクセスのプロビジョニングに役立つ可能性がある仮想LAN（VLAN）および再優先順位付け属性について説明します。
While [RFC3580] enables support for VLAN assignment based on the tunnel attributes defined in [RFC2868], it does not provide support for a more complete set of VLAN functionality as defined by [IEEE-802.1Q]. The attributes defined in this document provide support within RADIUS and Diameter analogous to the management variables supported in [IEEE-802.1Q] and MIB objects defined in [RFC4363]. In addition, this document enables support for a wider range of [IEEE-802.1X] configurations.
[RFC3580]は、[RFC2868]で定義されているトンネル属性に基づいたVLAN割り当てのサポートを可能にしますが、[IEEE-802.1Q]で定義されたより完全なVLAN機能セットのサポートは提供されません。このドキュメントで定義されている属性は、[IEEE-802.1Q]でサポートされている管理変数と[RFC4363]で定義されたMIBオブジェクトに類似した半径と直径内のサポートを提供します。さらに、このドキュメントにより、[IEEE-802.1x]構成の幅広い範囲のサポートが可能になります。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
Network Access Server (NAS) A device that provides an access service for a user to a network. Also known as a RADIUS client.
ネットワークアクセスサーバー（NAS）ユーザーにネットワークにアクセスサービスを提供するデバイス。RADIUSクライアントとも呼ばれます。
RADIUS server A RADIUS authentication server is an entity that provides an authentication service to a NAS.
RADIUSサーバーRADIUS認証サーバーは、NASに認証サービスを提供するエンティティです。
RADIUS proxy A RADIUS proxy acts as an authentication server to the NAS, and a RADIUS client to the RADIUS server.
RADIUSプロキシRADIUSプロキシは、NASの認証サーバーとして機能し、RADIUSサーバーのRADIUSクライアントとして機能します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The attributes described in this document apply to a single instance of a NAS port, or more specifically an IEEE 802.1Q bridge port. [IEEE-802.1Q], [IEEE-802.1D], and [IEEE-802.1X] do not recognize finer management granularity than "per port". In some cases, such as with IEEE 802.11 wireless LANs, the concept of a "virtual port" is used in place of the physical port. Such virtual ports are typically based on security associations and scoped by station, or Media Access Control (MAC) address.
このドキュメントで説明されている属性は、NASポートの単一インスタンス、またはより具体的にはIEEE 802.1Qブリッジポートに適用されます。[IEEE-802.1Q]、[IEEE-802.1D]、および[IEEE-802.1X]は、「ポートごと」よりも優れた管理の粒度を認識しません。場合によっては、IEEE 802.11ワイヤレスLANSなど、「仮想ポート」の概念が物理ポートの代わりに使用されます。このような仮想ポートは、通常、セキュリティ関連に基づいており、ステーションまたはメディアアクセス制御（MAC）アドレスによって範囲されています。
The attributes defined in this document are applied on a per-user basis and it is expected that there is a single user per port; however, in some cases that port may be a "virtual port". If a NAS implementation conforming to this document supports "virtual ports", it may be possible to provision those "virtual ports" with unique values of the attributes described in this document, allowing multiple users sharing the same physical port to each have a unique set of authorization parameters.
このドキュメントで定義されている属性は、ユーザーごとに適用され、ポートごとに単一のユーザーがいることが予想されます。ただし、場合によっては、そのポートが「仮想ポート」である場合があります。このドキュメントに準拠しているNASの実装が「仮想ポート」をサポートしている場合、これらの「仮想ポート」をこのドキュメントで説明した属性の一意の値にプロビジョニングすることができる場合があります。許可パラメーターの。
If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document that it cannot apply, it MUST act as though it had received an Access-Reject. [RFC3576] requires that a NAS receiving a Change of Authorization Request (CoA-Request) reply with a CoA-NAK if the Request contains an unsupported attribute. It is recommended that an Error-Cause attribute with the value set to "Unsupported Attribute" (401) be included in the CoA-NAK. As noted in [RFC3576], authorization changes are atomic so that this situation does not result in session termination and the preexisting configuration remains unchanged. As a result, no accounting packets should be generated.
この仕様に準拠しているNASが、このドキュメントで定義されている属性を含むアクセスacceptパケットを受け取った場合、適用できないと定義されている場合、Access-rejectを受信したかのように動作する必要があります。[RFC3576]は、リクエストにサポートされていない属性が含まれている場合、承認要求の変更（COA-Request）の返信をCOA-NAKで受信することを要求しています。「サポートされていない属性」（401）に設定された値を持つエラー（401）に設定された誤差（401）をCOA-NAKに含めることをお勧めします。[RFC3576]に記載されているように、承認の変更は原子的であるため、この状況がセッション終了につながることはなく、既存の構成は変更されません。その結果、会計パケットを生成する必要はありません。
Description
説明
The Egress-VLANID attribute represents an allowed IEEE 802 Egress VLANID for this port, indicating if the VLANID is allowed for tagged or untagged frames as well as the VLANID.
出口 - ヴラニド属性は、このポートに許可されたIEEE 802出力Vlanidを表します。
As defined in [RFC3580], the VLAN assigned via tunnel attributes applies both to the ingress VLANID for untagged packets (known as the PVID) and the egress VLANID for untagged packets. In contrast, the Egress-VLANID attribute configures only the egress VLANID for either tagged or untagged packets. The Egress-VLANID attribute MAY be included in the same RADIUS packet as [RFC3580] tunnel attributes; however, the Egress-VLANID attribute is not necessary if it is being used to configure the same untagged VLANID included in tunnel attributes. To configure an untagged VLAN for both ingress and egress, the tunnel attributes of [RFC3580] MUST be used.
[RFC3580]で定義されているように、トンネル属性を介して割り当てられたVLANは、未編成パケット（PVIDとして知られている）のイングレスVlanidと、攻撃されていないパケットの出力Vlanidの両方に適用されます。対照的に、Egress-Vlanid属性は、タグ付けされたパケットまたはタグ付きパケットのいずれかの出力Vlanidのみを構成します。出力-vlanid属性は、[RFC3580]トンネル属性と同じRADIUSパケットに含まれる場合があります。ただし、トンネル属性に含まれているのと同じ未凝固されたウラニドを構成するために使用されている場合、出口属性属性は必要ありません。イングレスと出口の両方に拡張されていないVLANを構成するには、[RFC3580]のトンネル属性を使用する必要があります。
Multiple Egress-VLANID attributes MAY be included in Access-Request, Access-Accept, CoA-Request, or Accounting-Request packets; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the specified VLAN to the list of allowed egress VLANs for the port.
複数の出力vlanid属性は、アクセスリクエスト、アクセスアセプト、COA-Request、または会計要求パケットに含まれる場合があります。この属性は、Access-Challenge、Access-Reject、disconnect-request、disconnect-nak、coa-ack、またはcoa-nak内で送信してはなりません。各属性は、指定されたVLANをポートの許可された出力VLANのリストに追加します。
The Egress-VLANID attribute is shown below. The fields are transmitted from left to right:
出力vlanid属性を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
56
56
Length
長さ
6
6
Value
価値
The Value field is four octets. The format is described below:
値フィールドは4オクテットです。形式については、以下に説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Indic. | Pad | VLANID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tag Indication field is one octet in length and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12 bits in length and MUST be 0 (zero). The VLANID is 12 bits in length and contains the [IEEE-802.1Q] VLAN VID value.
タグ表示フィールドの長さは1オクテットで、VLAN上のフレームのタグ付け（0x31）またはUntagged（0x32）のタグがあるかどうかを示します。パッドフィールドの長さは12ビットで、0（ゼロ）でなければなりません。Vlanidの長さは12ビットで、[IEEE-802.1Q] VLAN VID値が含まれています。
Description
説明
The Ingress-Filters attribute corresponds to the Ingress Filter per-port variable defined in [IEEE-802.1Q] clause 8.4.5. When the attribute has the value "Enabled", the set of VLANs that are allowed to ingress a port must match the set of VLANs that are allowed to egress a port. Only a single Ingress-Filters attribute MAY be sent within an Access-Request, Access-Accept, CoA-Request, or Accounting-Request packet; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.
Ingress-Filters属性は、[IEEE-802.1Q]条項8.4.5で定義されているイングレスフィルターごとの変数に対応しています。属性に値が「有効」されている場合、ポートを侵入できるVLANのセットは、ポートを脱出できるVLANのセットと一致する必要があります。Access-Request、Access-Accept、COA-Request、またはAccounting-Requestパケット内で送信できます。この属性は、Access-Challenge、Access-Reject、disconnect-request、disconnect-nak、coa-ack、またはcoa-nak内で送信してはなりません。
The Ingress-Filters attribute is shown below. The fields are transmitted from left to right:
Ingress-Filters属性を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
57
57
Length
長さ
6
6
Value
価値
The Value field is four octets. Supported values include:
値フィールドは4オクテットです。サポートされている値は次のとおりです。
1 - Enabled 2 - Disabled
1-有効になる2-無効
Description
説明
Clause 12.10.2.1.3 (a) in [IEEE-802.1Q] describes the administratively assigned VLAN Name associated with a VLAN-ID defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name attribute represents an allowed VLAN for this port. It is similar to the Egress-VLANID attribute, except that the VLAN-ID itself is not specified or known; rather, the VLAN name is used to identify the VLAN within the system.
[IEEE-802.1Q]の条項12.10.2.1.3（a）は、IEEE 802.1Qブリッジ内で定義されたVLAN-IDに関連付けられた管理上割り当てられたVLAN名を説明しています。出口-vlan-name属性は、このポートに許可されたVLANを表します。これは、VLAN-ID自体が指定または既知ではないことを除いて、出口vlanid属性に似ています。むしろ、VLAN名はシステム内のVLANを識別するために使用されます。
The tunnel attributes described in [RFC3580] and the Egress-VLAN-Name attribute both can be used to configure the egress VLAN for untagged packets. These attributes can be used concurrently and MAY appear in the same RADIUS packet. When they do appear concurrently, the list of allowed VLANs is the concatenation of the Egress-VLAN-Name and the Tunnel-Private-Group-ID (81) attributes. The Egress-VLAN-Name attribute does not alter the ingress VLAN for untagged traffic on a port (also known as the PVID). The tunnel attributes from [RFC3580] should be relied upon instead to set the PVID.
[rfc3580]で説明されているトンネル属性と出口vlan-name属性の両方を使用して、攻撃されていないパケットの出力VLANを構成できます。これらの属性は同時に使用でき、同じRADIUSパケットに表示される場合があります。それらが同時に表示される場合、許可されたVLANのリストは、Egress-Vlan-NameとTunnel-Private-Group-ID（81）属性の連結です。出口-VLAN-Name属性は、ポート上の攻撃されていないトラフィック（PVIDとも呼ばれます）のイングレスVLANを変更しません。[RFC3580]のトンネル属性は、代わりにPVIDを設定するために依存する必要があります。
The Egress-VLAN-Name attribute contains two parts; the first part indicates if frames on the VLAN for this port are to be represented in tagged or untagged format, the second part is the VLAN name.
出口-vlan-name属性には2つの部分が含まれています。最初の部分は、このポートのVLAN上のフレームがタグ付きまたは非編集された形式で表されるかどうかを示します。2番目の部分はVLAN名です。
Multiple Egress-VLAN-Name attributes MAY be included within an Access-Request, Access-Accept, CoA-Request, or Accounting-Request packet; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the named VLAN to the list of allowed egress VLANs for the port. The Egress-VLAN-Name attribute is shown below. The fields are transmitted from left to right:
複数の出力-vlan-name属性は、アクセス再クエスト、アクセスaccept、coa-request、または会計要求パケットに含めることができます。この属性は、Access-Challenge、Access-Reject、disconnect-request、disconnect-nak、coa-ack、またはcoa-nak内で送信してはなりません。各属性は、指定されたVLANをポートの許可された出力VLANのリストに追加します。出力-vlan-name属性を以下に示します。フィールドは左から右に送信されます。
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 | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
58
58
Length
長さ
>=4
> = 4
Tag Indication
タグの表示
The Tag Indication field is one octet in length and indicates whether the frames on the VLAN are tagged (0x31, ASCII '1') or untagged (0x32, ASCII '2'). These values were chosen so as to make them easier for users to enter.
タグ表示フィールドの長さは1オクテットで、VLAN上のフレームのタグ（0x31、ASCII '1'）またはUntagged（0x32、ASCII '2'）のタグが付けられているかどうかを示します。これらの値は、ユーザーが入力できるように選択されました。
String
弦
The String field is at least one octet in length and contains the VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a). [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a robust implementation SHOULD support the field as undistinguished octets.
文字列フィールドの長さは少なくとも1つのオクテットで、[IEEE-802.1Q]節12.10.2.1.3（a）で定義されているVLAN名が含まれています。[RFC3629] UTF-8エンコードされた10646文字が推奨されますが、堅牢な実装では、不具合のないオクテットとしてフィールドをサポートする必要があります。
Description
説明
[IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map) user priority on frames received at a port. This per-port configuration enables a bridge to cause the priority of received traffic at a port to be mapped to a particular priority. [IEEE-802.1D] clause 6.3.9 describes the use of remapping:
[IEEE-802.1d]条項7.5.1では、ポートで受信したフレームでユーザーの優先度を再生（または再マップする）方法について説明します。このポートごとの構成により、ブリッジは、ポートでの受信トラフィックの優先度を特定の優先度にマッピングできます。[IEEE-802.1d]条項6.3.9は、再マッピングの使用について説明しています。
The ability to signal user priority in IEEE 802 LANs allows user priority to be carried with end-to-end significance across a Bridged Local Area Network. This, coupled with a consistent approach to the mapping of user priority to traffic classes and of user priority to access_priority, allows consistent use of priority information, according to the capabilities of the Bridges and MACs in the transmission path...
IEEE 802 LANSでユーザーの優先度を信号する機能により、ユーザーの優先順位は、ブリッジ付きローカルエリアネットワーク全体でエンドツーエンドの有意性で運ばれることができます。これは、トラフィッククラスに対するユーザーの優先度とAccess_Priorityのユーザーの優先度のマッピングに対する一貫したアプローチと相まって、送信パスのブリッジとMacの機能に応じて、優先情報の一貫した使用を可能にします...
Under normal circumstances, user priority is not modified in transit through the relay function of a Bridge; however, network management can control how user priority is propagated. Table 7-1 provides the ability to map incoming user priority values on a per-Port basis. By default, the regenerated user priority is identical to the incoming user priority.
通常の状況では、ユーザーの優先順位は、ブリッジのリレー関数を介した輸送中に変更されません。ただし、ネットワーク管理は、ユーザーの優先度の伝播方法を制御できます。表7-1では、ポートごとに着信ユーザーの優先度値をマッピングする機能を示しています。デフォルトでは、再生されたユーザーの優先度は、着信ユーザーの優先度と同じです。
This attribute represents the IEEE 802 prioritization that will be applied to frames arriving at this port. There are eight possible user priorities, according to the [IEEE-802] standard. [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table as 8 values, each an integer in the range 0-7. The management variables are described in clause 14.6.2.2.
この属性は、このポートに到着するフレームに適用されるIEEE 802優先順位付けを表します。[IEEE-802]標準によると、ユーザーの優先順位が8つあります。[IEEE-802.1d]条項14.6.2.3.3は、再生テーブルを8値として指定し、それぞれ0〜7の範囲の整数を指定します。管理変数は、条項14.6.2.2で説明されています。
A single User-Priority-Table attribute MAY be included in an Access-Accept or CoA-Request packet; this attribute MUST NOT be sent within an Access-Request, Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA-NAK or Accounting-Request. Since the regeneration table is only maintained by a bridge conforming to [IEEE-802.1D], this attribute should only be sent to a RADIUS client supporting that specification.
単一のユーザー優先テーブル属性をAccess-AcceptまたはCOA-Requestパケットに含めることができます。この属性は、Access-Request、Access-Challenge、Access-Reject、disconnect-request、disconnect-nak、coa-ack、coa-nak、または会計要求内で送信してはなりません。再生テーブルは[IEEE-802.1D]に準拠するブリッジによってのみ維持されるため、この属性はその仕様をサポートするRADIUSクライアントにのみ送信する必要があります。
The User-Priority-Table attribute 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 | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
59
59
Length
長さ
10
10
String
弦
The String field is 8 octets in length and includes a table that maps the incoming priority (if it is set -- the default is 0) into one of eight regenerated priorities. The first octet maps to incoming priority 0, the second octet to incoming priority 1, etc. The values in each octet represent the regenerated priority of the frame.
文字列フィールドの長さは8オクテットで、着信優先度（設定されている場合、デフォルトは0）の8つの再生優先度の1つにマッピングするテーブルが含まれています。最初のオクテットは、着信優先度0へのマップ、2番目のオクテットから着信優先度1などです。各オクテットの値は、フレームの再生優先度を表します。
It is thus possible to either remap incoming priorities to more appropriate values; to honor the incoming priorities; or to override any incoming priorities, forcing them to all map to a single chosen priority.
したがって、より適切な値に着信優先順位を再マップすることは可能です。着信の優先順位を尊重する。または、着信の優先順位をオーバーライドし、すべてのマップを選択した単一の優先順位に強制します。
The [IEEE-802.1D] specification, Annex G, provides a useful description of traffic type - traffic class mappings.
[IEEE -802.1D]仕様であるAnnex Gは、トラフィックタイプ - トラフィッククラスマッピングの有用な説明を提供します。
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
次の表は、どの種類のパケットとどのような量の属性が見つかるかについてのガイドを示します。
Access- Access- Access- Access- CoA- Acct-
Request Accept Reject Challenge Req Req # Attribute
0+ 0+ 0 0 0+ 0+ 56 Egress-VLANID
0-1 0-1 0 0 0-1 0-1 57 Ingress-Filters
0+ 0+ 0 0 0+ 0+ 58 Egress-VLAN-Name
0 0-1 0 0 0-1 0 59 User-Priority-Table
The following table defines the meaning of the above table entries.
次の表は、上記のテーブルエントリの意味を定義しています。
0 This attribute MUST NOT be present in the packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.
0この属性はパケットに存在してはなりません。この属性の0ゼロ以上のインスタンスがパケットに存在する場合があります。この属性の0-1インスタンスまたは1つのインスタンスがパケットに存在する場合があります。
When used in Diameter, the attributes defined in this specification can be used as Diameter attribute-value pair (AVPs) from the Code space 1-255 (RADIUS attribute compatibility space). No additional Diameter Code values are therefore allocated. The data types and flag rules for the attributes are as follows:
直径で使用する場合、この仕様で定義されている属性は、コードスペース1-255（RADIUS属性互換性スペース）の直径属性値ペア（AVPS）として使用できます。したがって、追加の直径コード値は割り当てられていません。属性のデータ型とフラグルールは次のとおりです。
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
Egress-VLANID OctetString| M | P | | V | Y |
Ingress-Filters Enumerated | M | P | | V | Y |
Egress-VLAN-Name UTF8String | M | P | | V | Y |
User-Priority-Table OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
The attributes in this specification have no special translation requirements for Diameter to RADIUS or RADIUS to Diameter gateways; they are copied as is, except for changes relating to headers, alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] Section 9.
この仕様の属性には、直径または半径から直径ゲートウェイの特別な変換要件はありません。ヘッダー、アライメント、パディングに関連する変更を除いて、それらはそのままコピーされます。[RFC3588]セクション4.1および[RFC4005]セクション9も参照してください。
What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH.
RADIUS Access-Requestパケットの属性の適用性についてこの仕様が示すことは、AA-Request [RFC4005]またはAimeter-Eap-Request [RFC4072]に直径に適用されます。Access-Challengeについて言われていることは、AA-Answer [RFC4005]またはAimeter-Eap-Answer [RFC4072]に直径に適用され、結果コードAVPがdiameter_multi_round_authに設定されています。
What is said about Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate success. Similarly, what is said about RADIUS Access-Reject packets applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate failure.
Access-Acceptについて言われていることは、成功を示すAA-AnswerまたはAimeter-Eap-Answerメッセージに直径に適用されます。同様に、Radius Access-Rejectパケットについて言われていることは、障害を示すAA-AnswerまたはAimeter-Eap-Answerメッセージに直径に適用されます。
What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC4005].
COA-Requestについて言われていることは、直径が再発行に適用されます[RFC4005]。
What is said about Accounting-Request applies to Diameter Accounting-Request [RFC4005] as well.
アカウンティングレクエストについて言われていることは、直径のアカウンティングRequest [RFC4005]にも適用されます。
This specification does not create any new registries.
この仕様では、新しいレジストリは作成されません。
This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. Allocation of four updates for the section "RADIUS Attribute Types" has been made by the IANA. The RADIUS attributes are:
このドキュメントでは、RADIUS [RFC2865]名前空間を使用しています。<http://www.iana.org/assignments/radius-types>を参照してください。「RADIUS属性タイプ」セクションの4つの更新の割り当ては、IANAによって行われました。半径の属性は次のとおりです。
56 - Egress-VLANID 57 - Ingress-Filters 58 - Egress-VLAN-Name 59 - User-Priority-Table
56-Egress-Vlanid 57-Ingress-Filters 58-Egress-Vlan-Name 59-ユーザー-Priority-Table
This specification describes the use of RADIUS and Diameter for purposes of authentication, authorization, and accounting in IEEE 802 local area networks. RADIUS threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. For Diameter, the security issues relating to this application are described in [RFC4005] and [RFC4072].
この仕様では、IEEE 802ローカルエリアネットワークでの認証、承認、および会計の目的での半径と直径の使用について説明します。このアプリケーションの半径の脅威とセキュリティの問題は、[RFC3579]および[RFC3580]で説明されています。ローミングで発生したセキュリティの問題は、[RFC2607]で説明されています。直径の場合、このアプリケーションに関連するセキュリティの問題は[RFC4005]および[RFC4072]に記載されています。
This document specifies new attributes that can be included in existing RADIUS packets, which are protected as described in [RFC3579] and [RFC3576]. In Diameter, the attributes are protected as specified in [RFC3588]. See those documents for a more detailed description.
このドキュメントは、[RFC3579]および[RFC3576]で説明されているように保護されている既存のRADIUSパケットに含めることができる新しい属性を指定します。直径では、属性は[RFC3588]で指定されているように保護されています。より詳細な説明については、これらのドキュメントを参照してください。
The security mechanisms supported in RADIUS and Diameter are focused on preventing an attacker from spoofing packets or modifying packets in transit. They do not prevent an authorized RADIUS/Diameter server or proxy from inserting attributes with malicious intent.
半径と直径でサポートされているセキュリティメカニズムは、攻撃者がスプーフィングパケットのパケットのスプーフィングやパケットの変更を防ぐことに焦点を当てています。それらは、承認された半径/直径サーバーまたはプロキシが悪意を持って属性を挿入することを妨げません。
VLAN attributes sent by a RADIUS/Diameter server or proxy may enable access to unauthorized VLANs. These vulnerabilities can be limited by performing authorization checks at the NAS. For example, a NAS can be configured to accept only certain VLANIDs from a given RADIUS/Diameter server/proxy.
半径/直径サーバーまたはプロキシによって送信されるVLAN属性により、不正なVLANへのアクセスが可能になる場合があります。これらの脆弱性は、NASで承認チェックを実行することで制限できます。たとえば、NASは、特定の半径/直径サーバー/プロキシから特定のウラニドのみを受け入れるように構成できます。
Similarly, an attacker gaining control of a RADIUS/Diameter server or proxy can modify the user priority table, causing either degradation of quality of service (by downgrading user priority of frames arriving at a port), or denial of service (by raising the level of priority of traffic at multiple ports of a device, oversubscribing the switch or link capabilities).
同様に、Radius/Diameter ServerまたはProxyの制御を獲得する攻撃者は、ユーザーの優先順位テーブルを変更し、サービス品質の低下（ポートに到着するフレームのユーザーの優先度を格下げすることにより）またはサービスの拒否（レベルを上げることにより）を引き起こすことができます。デバイスの複数のポートでのトラフィックの優先度、スイッチまたはリンク機能をオーバーサブスクライブします）。
[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、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006.
[RFC4363] Levi、D。およびD. Harrington、「トラフィッククラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えた橋の管理されたオブジェクトの定義」、RFC 4363、2006年1月。
[IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE-802]地元および大都市圏ネットワークのIEEE標準：概要とアーキテクチャ、ANSI/IEEE STD 802、1990。
[IEEE-802.1D] IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges, IEEE Std 802.1D-2004, June 2004.
[IEEE-802.1D]地元および大都市圏ネットワークのIEEE標準：Media Access Control（Mac）Bridges、IEEE STD 802.1D-2004、2004年6月。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.1Q]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジ付きローカルエリアネットワークのドラフト標準、P802.1Q-2003、2003年1月。
[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, December 2004.
[IEEE-802.1x]地元および大都市圏ネットワークのIEEE標準：ポートベースのネットワークアクセス制御、IEEE STD 802.1x-2004、2004年12月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「ローミングにおけるプロキシチェーンと政策の実施」、RFC 2607、1999年6月。
[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属性」、RFC 2868、2000年6月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「リモート認証のダイヤルインユーザーサービス（RADIUS）への動的認証拡張」、RFC 3576、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、RFC 4072、2005年8月。
The authors would like to acknowledge Joseph Salowey of Cisco, David Nelson of Enterasys, Chuck Black of Hewlett-Packard, and Ashwin Palekar of Microsoft.
著者は、シスコのジョセフ・サロウィー、エンタージスのデビッド・ネルソン、ヒューレット・パッカードのチャック・ブラック、マイクロソフトのアシュウィン・ペレカーに感謝します。
Authors' Addresses
著者のアドレス
Paul Congdon Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747
Paul Congdon Hewlett-Packard Company HP Procurve Networking 8000 Foothills Blvd、M/S 5662 Roseville、CA 95747
Phone: +1 916 785 5753
Fax: +1 916 785 8478
EMail: paul.congdon@hp.com
Mauricio Sanchez Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5559 Roseville, CA 95747
Mauricio Sanchez Hewlett-Packard Company HP Procurve Networking 8000 Foothills Blvd、M/S 5559 Roseville、CA 95747
Phone: +1 916 785 1910
Fax: +1 916 785 1815
EMail: mauricio.sanchez@hp.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。