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
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).
著作権（C）インターネット協会（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.
この文書では、追加のリモート認証ダイヤルインユーザーサービス（RADIUS）は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）または直径で仮想LAN（VLAN）およびIEEE 802のローカル・エリア・ネットワークへのアクセスの提供のために有用であることを証明し得る再優先順位付け属性[IEEE-802]について説明します。
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機能のより完全なセットのためのサポートを提供しません。この文書で定義された属性は、RADIUSおよび[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サーバA RADIUS認証サーバは、NASに認証サービスを提供するエンティティです。
RADIUS proxy A RADIUS proxy acts as an authentication server to the NAS, and a RADIUS client to the RADIUS server.
RADIUSプロキシA RADIUSプロキシは、RADIUSサーバへのNASに認証サーバ、および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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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無線LANのようにいくつかのケースでは、「仮想ポート」の概念は、物理ポートの代わりに使用されます。そのような仮想ポートは、典型的には、セキュリティアソシエーションに基づいてステーション、またはメディアアクセス制御（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は、それが適用されないことを、この文書で定義された属性を含むアクセス-受け入れてパケットを受信した場合、それはアクセス拒否を受けたかのように、それが行動しなければなりません。 [RFC3576]はNAS要求がサポートされない属性が含まれている場合のCoA-NAKで応答許可要求（COA-要求）の変化を受けることを必要とします。 「サポートされていない属性」（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.
エグレスVLANID属性はVLANIDがタグ付き又はタグなしフレーム並びに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の両方に適用されます。対照的に、退出-VLANID属性は、タグ付き又はタグなしパケットのいずれかのためにのみ出口VLANIDを構成します。エグレスVLANID属性は[RFC3580]トンネル属性と同じRADIUSパケットに含まれていてもよいです。同じタグなしVLANIDがトンネル属性に含まれる構成するために使用されている場合は、退出-VLANID属性は不要です。入力と出力の両方のためのタグなし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,
複数の出口-VLANIDの属性は、アクセス要求、アクセス-受け入れ、CoAのリクエスト、またはアカウンティング要求パケットに含まれるかもしれ。この属性はアクセスチャレンジの中に送ってはいけません、アクセス拒否、外し-ACK-Requestを外し、
Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the specified VLAN to the list of allowed egress VLANs for the port.
外し-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
５６
Length
長さ
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つのオクテットであると（0x32の）VLAN上のフレームがタグ付けされているかどうかを示す（0x31）またはタグなし。パッドフィールドの長さは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.
イングレス・フィルタ属性[IEEE-802.1Q]節8.4.5で定義された進入フィルタポートごとの変数に対応します。属性が「有効」の値を持つ場合は、ポートを進入を許可されたVLANのセットは、出力ポートに許可されているVLANのセットと一致する必要があります。唯一のシングルイングレス・フィルタは属性アクセス要求、アクセス-受け入れ、CoAのリクエスト、またはアカウンティング要求パケット内で送信することができ、この属性はアクセスチャレンジの中に、アクセス拒否、外し-ACK-Requestを外し、アシルCoA-ACK、またはアシルCoA-NAK-NAKを外して送ってはいけません。
The Ingress-Filters 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
57
５７
Length
長さ
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を表します。これは、VLANID自体は、指定されたか知らされていないことを除いて、出口-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名の両方がタグなしパケットのための出力VLANを構成するために使用できる属性。これらの属性は、同時に使用することができ、同じRADIUSパケットに表示されることがあります。彼らが同時に表示されない場合は、許可されるVLANのリストが出力-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-名前の属性は、アクセス要求、アクセス-受け入れ、CoAのリクエスト、またはアカウンティング要求パケット内に含めることができます。この属性はアクセスチャレンジの中に、アクセス拒否、外し-ACK-Requestを外し、アシルCoA-ACK、またはアシルCoA-NAK-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
５８
Length
長さ
>=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つのオクテットであり、（0x31、ASCII「1」）またはタグなしVLAN上のフレームがタグ付けされているかどうかを示す（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 LANで、ユーザの優先順位を通知する機能は、ユーザの優先順位は、ブリッジローカルエリアネットワーク全体のエンド・ツー・エンドの意義を実施することができます。これは、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
この属性は、このポートに到着フレームに適用されるIEEE 802の優先順位付けを表します。 8つの可能なユーザの優先順位は[IEEE-802]規格によると、存在します。 [IEEE-802.1D]句14.6.2.3.3は、再生テーブルを指定します
as 8 values, each an integer in the range 0-7. The management variables are described in clause 14.6.2.2.
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.
シングルユーザー優先 - 表属性がアクセス-受け入れるかのCoA-Requestパケットに含まれるかもしれ。この属性は、アクセスチャレンジ、アクセス拒否、外し-ACK-Requestを外し、外し-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
５９
Length
長さ
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つの再生の優先度のいずれかに。着信優先0に最初のオクテットマップは、着信優先順位1、等への第2オクテットは、各オクテットの値はフレームの再生優先順位を表します。
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明細書、付属書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
Access- Access- Access- Access- CoA-アカウンティング - 要求受け入れチャレンジ必須必須位項目0+ 0+ 0 0+ 0+ 56出口-VLANID 0-1 0-1 0-1 0-1 0 0 57の進入を拒否-filters 0+ 0+ 0 0 0+ 0+ 58出口-VLAN-名0 0-1 0 0 0-1 0 59ユーザー優先-表
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属性互換空間）から（のAVP）直径の属性と値のペアとして使用することができます。追加直径コード値は、したがって、割り当てられていません。次のように属性のデータ型とフラグのルールは以下のとおりです。
+---------------------+
| 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.
この仕様の属性は、DiameterゲートウェイへのRADIUSまたはRADIUSの直径のための特別な翻訳要件を持っていません。彼らは、ヘッダー、位置合わせ、及びパディングに関連する変更点を除いて、そのままコピーされます。また、[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アクセス要求パケットの属性の適用可能性について言うことはAA-リクエスト[RFC4005]または直径-EAP-要求[RFC4072]に直径が適用されます。どのようなアクセスチャレンジについて語っていることの結果、コードAVPとAA-回答[RFC4005]または直径-EAP-回答[RFC4072]に直径が適用さ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.
言われて何成功を示すAA-回答または直径-EAP-回答メッセージに直径が適用されるアクセス - 受け入れます。失敗を示すAA-回答または直径-EAP-回答メッセージに直径が適用されるRADIUSパケットのアクセスが拒否について同様に、何を言われています。
What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC4005].
何COA-要求が再認証リクエスト[RFC4005]に直径が適用さについて語っています。
What is said about Accounting-Request applies to Diameter Accounting-Request [RFC4005] as well.
何アカウンティング要求は同様に直径アカウンティング要求[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>を参照してください。セクションのための4つの更新プログラムの割り当て「RADIUS属性の型は、」IANAによって行われています。 RADIUS属性は、次のとおりです。
56 - Egress-VLANID 57 - Ingress-Filters 58 - Egress-VLAN-Name 59 - User-Priority-Table
56 - 出力-VLANID 57 - 入フィルタ58 - 出力-VLAN名59 - ユーザプライオリティ表
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のローカルエリアネットワークでの認証、許可、アカウンティングの目的のためにRADIUSを使用すると直径を説明しています。このアプリケーションのためのRADIUSの脅威とセキュリティの問題は、[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.
RADIUS直径サポートされるセキュリティメカニズムは、なりすましパケットから攻撃を予防または輸送中のパケットを修正するに焦点を当てています。彼らは、悪意と属性を挿入するから認可RADIUS / Diameterサーバやプロキシを防ぐことはできません。
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.
RADIUS / Diameterサーバやプロキシによって送信されたVLANの属性は、不正のVLANへのアクセスを可能にすることができます。これらの脆弱性は、NASでの権限チェックを実行することにより制限することができます。例えば、NASは、所与のRADIUS / Diameterサーバ/プロキシからのみ特定VLANIDsを受け入れるように構成することができます。
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サーバまたはプロキシの制御を獲得する攻撃者は、（レベルを上げることによって、またはサービス拒否（ユーザポートに到着フレームの優先度をダウングレードすることによって）、サービスの質の低下のいずれかを引き起こす、ユーザ優先度テーブルを変更することができデバイスの複数のポート、スイッチまたはリンク機能をオーバーサブスクライブ）でのトラフィックの優先度。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[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]レビとD.とD.ハリントン、RFC 4363、2006年1月「トラフィッククラス、マルチキャストフィルタリング、および仮想LAN拡張機能を持つブリッジのための管理オブジェクトの定義」。
[IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
ローカルおよびメトロポリタンエリアネットワークの[IEEE-802] IEEE規格：概要とアーキテクチャ、ANSI / IEEE規格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標準：メディアアクセス制御（MAC）ブリッジ、IEEE 802.1D STD-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標準：2003年1月、仮想ブリッジローカルエリアネットワーク、P802.1Q-2003用標準案。
[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 802.1X STD-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]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.、およびI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[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.
、RFC 3576、2003年7月[RFC3576]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[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.カルフーン、 "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.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "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]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、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.、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（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.
著者は、シスコのジョセフSalowey、エンテラシスのデビッド・ネルソン、ヒューレット・パッカードのチャックブラック、およびマイクロソフトののAshwin Palekarを確認したいと思います。
Authors' Addresses
著者のアドレス
Paul Congdon Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747
ポールコングドン米国Hewlett-Packard Company HPのProCurveネットワーキング8000山麓ブルバード、M / S 5662ローズ、CA 95747
Phone: +1 916 785 5753 Fax: +1 916 785 8478 EMail: paul.congdon@hp.com
電話：+1 916 785 5753ファックス：+1 916 785 8478 Eメール：paul.congdon@hp.com
Mauricio Sanchez Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5559 Roseville, CA 95747
マウリシオ・サンチェス、米国Hewlett-Packard Company HPのProCurveネットワーキング8000山麓ブルバード、M / S 5559ローズ、CA 95747
Phone: +1 916 785 1910 Fax: +1 916 785 1815 EMail: mauricio.sanchez@hp.com
電話：+1 916 785 1910ファックス：+1 916 785 1815 Eメール：mauricio.sanchez@hp.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
電話：+1 425 706 6605ファックス：+1 425 936 7329 Eメール：bernarda@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。