RFC4675 日本語訳
4675 RADIUS Attributes for Virtual LAN and Priority Support. P.Congdon, M. Sanchez, B. Aboba. September 2006. (Format: TXT=29751 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Congdon
Request for Comments: 4675 M. Sanchez
Category: Standards Track Hewlett-Packard Company
B. Aboba
Microsoft Corporation
September 2006
コメントを求めるワーキンググループP.コングドンの要求をネットワークでつないでください: 4675年のM.サンチェスカテゴリ: 標準化過程ヒューレット・パッカード会社B.Abobaマイクロソフト社2006年9月
RADIUS Attributes for Virtual LAN and Priority Support
バーチャルLANのための半径属性と優先権サポート
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはダイナミックなバーチャルLAN課題と優先順位づけのために追加中のRemote Authentication Dial User Service(RADIUS)属性を提案します、IEEE802ローカル・エリア・ネットワークへのアクセスの食糧を供給することにおける使用のために。 これらの属性はRADIUSかDiameterのどちらかの中で使用可能です。
Congdon, et al. Standards Track [Page 1] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[1ページ]RFC4675VLANと優先権属性2006年9月
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
1. 序論…3 1.1. 用語…3 1.2. 要件言語…3 1.3. 解釈を結果と考えてください…3 2. 属性…4 2.1. 出口-VLANID…4 2.2. イングレスフィルタ…6 2.3. 出口VLAN名…7 2.4. ユーザ優先権テーブル…8 3. 属性のテーブル…10 4. 直径問題…10 5. IANA問題…11 6. セキュリティ問題…11 7. 参照…12 7.1. 標準の参照…12 7.2. 有益な参照…13 8. 承認…13
Congdon, et al. Standards Track [Page 2] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[2ページ]RFC4675VLANと優先権属性2006年9月
1. Introduction
1. 序論
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.
このドキュメントはIEEE802ローカル・エリア・ネットワーク[IEEE-802]へのアクセスの食糧を供給するために中のRemote Authentication Dial User Service(RADIUS)かDiameterと共に有用であることが分かるかもしれないバーチャル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オブジェクトへの類似のRADIUSとDiameterの中でサポートを提供します。 さらに、このドキュメントは、より広い範囲の[IEEE-802.1X]構成のサポートを可能にします。
1.1. Terminology
1.1. 用語
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.
アクセス・サービスをユーザに提供するAccess Server(NAS)Aデバイスをネットワークにネットワークでつないでください。 また、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プロキシはNASへの認証サーバ、およびRADIUSサーバへのRADIUSクライアントとして務めます。
1.2. Requirements Language
1.2. 要件言語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Attribute Interpretation
1.3. 属性解釈
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]は「ポート」よりすばらしい管理粒状を認識しません。 いくつかでは、802.11の無線LAN、IEEEに伴う「仮想のポート」の概念などのケースは物理的なポートに代わって使用されます。 そのような仮想のポートは、ステーション、またはメディアAccess Control(MAC)アドレスによってセキュリティ協会に通常基づいていて、見られます。
Congdon, et al. Standards Track [Page 3] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[3ページ]RFC4675VLANと優先権属性2006年9月
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.
本書では定義された属性は1ユーザあたり1個のベースで申し込まれます、そして、1ポートあたり1人のシングルユーザーがいると予想されます。 しかしながら、いくつかの場合、そのポートは「仮想のポート」であるかもしれません。 このドキュメントに従う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がそれが適用できない本書では定義された属性を含むAccess受け入れているパケットを受けるなら、それはまるでAccess-廃棄物を受けたかのように行動しなければなりません。 [RFC3576]は、Requestがサポートされない属性を含んでいるならAuthorization Request(CoA-要求)のChangeを受けるNASがCoA-NAKと共に返答するのを必要とします。 「サポートされない属性」(401)への選択値群があるError-原因属性がCoA-NAKに含まれているのは、お勧めです。 承認変化が[RFC3576]に述べられるように原子であるので、この状況はセッション終了をもたらしません、そして、先在の構成は変わりがありません。 その結果、会計パケットを全く生成するべきではありません。
2. Attributes
2. 属性
2.1. Egress-VLANID
2.1. 出口-VLANID
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.
Egress-VLANID属性は許容IEEE802Egress VLANIDをこのポートに表します、VLANIDが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がパケットにタグ付けをしたか、または非タグ付けをしたのを構成します。 Egress-VLANID属性は[RFC3580]トンネル属性と同じRADIUSパケットに含まれるかもしれません。 しかしながら、それがトンネル属性に含まれていた同じuntagged VLANIDを構成するのに使用されるなら、Egress-VLANID属性は必要ではありません。 イングレスと出口の両方のためにuntagged 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,
複数のEgress-VLANID属性がAccess要求であって、Access受け入れているCoA-要求、またはAccounting-リクエスト・パケットに含まれるかもしれません。 Disconnect-ACK、Access挑戦、Access-廃棄物、Disconnect-要求の中でこの属性を送ってはいけません。
Congdon, et al. Standards Track [Page 4] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[4ページ]RFC4675VLANと優先権属性2006年9月
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。 各属性はポートのために許容出口VLANsのリストに指定されたVLANを追加します。
The Egress-VLANID attribute is shown below. The fields are
transmitted from left to right:
Egress-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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
56
56
Length
長さ
6
6
Value
値
The Value field is four octets. The format is described below:
Value分野は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグインドです。 | パッド| 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.
Tag Indication分野は、長さにおける1つの八重奏であり、VLANの上のフレームがタグ付けをされるか(0×31)、または非タグ付けをされるかを(0×32)示します。 Pad分野は、長さ12ビットであり、0が(ゼロ)であったならビットでなければなりません。 VLANIDは長さ12ビットであり、[IEEE-802.1Q]VLAN VID価値を含んでいます。
Congdon, et al. Standards Track [Page 5] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[5ページ]RFC4675VLANと優先権属性2006年9月
2.2. Ingress-Filters
2.2. イングレスフィルタ
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-フィルタ属性が[IEEE-802.1Q]節で定義された1ポートあたりのIngress Filter変数に対応している、8.4、.5 属性が、値が「可能にされること」を持っているとき、イングレスへのポートが許容されているVLANsのセットは出口へのポートが許容されているVLANsのセットに合わなければなりません。 Access-要求であって、Access受け入れているCoA-要求、またはAccounting-リクエスト・パケットの中でただ一つのIngress-フィルタ属性だけを送るかもしれません。 Access-挑戦、Access-廃棄物、Disconnect-要求、Disconnect-ACK、Disconnect-NAK、CoA-ACK、またはCoA-NAKの中でこの属性を送ってはいけません。
The Ingress-Filters attribute is shown below. The fields are
transmitted from left to right:
Ingress-フィルタ属性は以下に示されます。 野原は左から右まで伝えられます:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
57
57
Length
長さ
6
6
Value
値
The Value field is four octets. Supported values include:
Value分野は4つの八重奏です。 サポートしている値は:
1 - Enabled
2 - Disabled
1--2--身体障害者を可能にします。
Congdon, et al. Standards Track [Page 6] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[6ページ]RFC4675VLANと優先権属性2006年9月
2.3. Egress-VLAN-Name
2.3. 出口VLAN名
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 Nameについて説明します。 Egress-VLAN-名前属性は許容VLANをこのポートに表します。 VLAN-ID自体が指定もされませんし、知られてもいないのを除いて、それはEgress-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.
非タグ付けをされたパケットのために出口VLANを構成するのに[RFC3580]で説明されたトンネル属性と属性のEgress-VLAN名前両方を使用できます。 これらの属性は、同時に使用できて、同じRADIUSパケットに現れるかもしれません。 彼らが同時に現れるとき、許容VLANsのリストはEgress-VLAN-名前とTunnelの個人的なグループID(81)属性の連結です。 Egress-VLAN-名前属性は非タグ付けをされたトラフィックのためにポート(また、PVIDとして、知られている)の上でイングレスVLANを変更しません。 PVIDを設定するために代わりに[RFC3580]からのトンネル属性を当てにされるべきです。
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.
Egress-VLAN-名前属性は2つの部品を含んでいます。 最初の部分は、このポートへのVLANの上のフレームがタグ付けをされたか非タグ付けをされた形式で表されるつもりであるなら、第二部が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:
複数のEgress-VLAN-名前属性がAccess-要求であって、Access受け入れているCoA-要求、またはAccounting-リクエスト・パケットの中に含まれるかもしれません。 Access挑戦、Access-廃棄物、Disconnect-要求、Disconnect-ACK、Disconnect-NAK、CoA-ACK、またはCoA-NAKの中でこの属性を送ってはいけません。 各属性はポートのために許容出口VLANsのリストに命名されたVLANを追加します。 Egress-VLAN-名前属性は以下に示されます。 野原は左から右まで伝えられます:
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
58
58
Congdon, et al. Standards Track [Page 7] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[7ページ]RFC4675VLANと優先権属性2006年9月
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.
Tag Indication分野は、長さにおける1つの八重奏であり、VLANの上のフレームがタグ付けをされるか(0×31、ASCII'1')、または非タグ付けをされるかを(0×32、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.
String分野は、12.10番目の[IEEE-802.1Q]節.2.1.3(a)で定義されるように長さにおける少なくとも1つの八重奏であり、VLAN Nameを含んでいます。 [RFC3629]UTF-8 10646のコード化されたキャラクタがRECOMMENDEDですが、体力を要している実装SHOULDサポートは平凡な八重奏として分野です。
2.4. User-Priority-Table
2.4. ユーザ優先権テーブル
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、(または、再地図)ユーザ優先権をポートに受け取られたフレームに作り直す方法について議論します。 この1ポートあたりの構成は、ブリッジでポートの容認されたトラフィックの優先権を特定の優先に写像するのを可能にします。 6.3番目の[IEEE-802.1D]節.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...
IEEE802LANにおけるユーザ優先権に合図する能力は、ユーザ優先権がBridgedローカル・エリア・ネットワークの向こう側に終わりから終わりへの意味で運ばれるのを許容します。 ブリッジスとMACsの能力に従って、_優先権にアクセスするためにトラフィックのクラスのユーザ優先権に関するマッピングへの一貫したアプローチとユーザ優先権について結合されたこれはトランスミッション経路で優先権情報の一貫した使用を許します…
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.
通常の状況下で、ユーザ優先権はBridgeのリレー機能を通したトランジットで変更されません。 しかしながら、ネットワークマネージメントはユーザ優先権がどう伝播されるかを制御できます。 テーブル7-1は1ポートあたり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
この属性はこのポートに到着するフレームに適用されるIEEE802優先順位づけを表します。 [IEEE-802]規格に従って、8つの可能なユーザプライオリティがあります。 14.6番目の[IEEE-802.1D]節.2、.3、.3は再生テーブルを指定します。
Congdon, et al. Standards Track [Page 8] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[8ページ]RFC4675VLANと優先権属性2006年9月
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.
または、ただ一つのUser優先権テーブル属性が含まれるかもしれない、Access受け入れてください、CoA-リクエスト・パケット。 Access-要求、Access-挑戦、Access-廃棄物、Disconnect-要求、Disconnect-ACK、Disconnect-NAK、CoA-ACK、CoA- NAKまたはAccounting-要求の中でこの属性を送ってはいけません。 再生テーブルが[IEEE-802.1D]に従うブリッジによって維持されるだけであるので、その仕様をサポートするRADIUSクライアントにこの属性を送るだけであるべきです。
The User-Priority-Table attribute is shown below. The fields are
transmitted from left to right:
User優先権テーブル属性は以下に示されます。 野原は左から右まで伝えられます:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
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.
String分野が長さにおける8つの八重奏であり、入って来る優先権を写像するテーブルを含んでいる、(--それが設定されるならデフォルトは8つの作り直されたプライオリティの1つへの0です)。 入って来る優先権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.
その結果、どちらかに、以上へのremapの入って来るプライオリティが値を当てるのは、可能です。 入って来るプライオリティを光栄に思うために。 または、すべてにそれらを強制するどんな入って来るプライオリティもくつがえすには、選ばれた優先権をシングルに写像してください。
Congdon, et al. Standards Track [Page 9] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[9ページ]RFC4675VLANと優先権属性2006年9月
The [IEEE-802.1D] specification, Annex G, provides a useful
description of traffic type - traffic class mappings.
[IEEE-802.1D]仕様(Annex G)はトラフィックタイプの役に立つ記述を提供します--トラフィッククラスマッピング。
3. Table of Attributes
3. 属性のテーブル
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
アクセスアクセスアクセスアクセスCoA- Acct廃棄物挑戦Req Req#属性0+0+0 0 0+0+56出口-VLANID0-1 0-1 0 0 0-1 0-1 57イングレスフィルタ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つのインスタンスがパケットに存在しているかもしれません。
4. Diameter Considerations
4. 直径問題
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:
Diameterで使用されると、Diameter属性値組(AVPs)としてCodeスペース1-255(RADIUS属性互換性スペース)からこの仕様に基づき定義された属性は使用できます。 したがって、どんな追加Diameter Code値も割り当てません。 属性のためのデータ型と旗の規則は以下の通りです:
+---------------------+
| 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 |
-------------------------------|----+-----+----+-----|----|
+---------------------+ | AVP Flag規則| |----+-----+----+-----|----+ | | |SHLD| 必須| | 属性名前値のタイプ|必須| 5月| NOT| NOT|Encr| -------------------------------|----+-----+----+-----|----| 出口-VLANID OctetString| M| P| | V| Y| 数え上げられたイングレスフィルタ| M| P| | V| Y| 出口VLAN名のUTF8String| M| P| | V| Y| ユーザ優先権テーブル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.
この仕様による属性に、どんなRADIUSへのDiameterかDiameterゲートウェイへのRADIUSに、特別な翻訳要件もありません。 ヘッダー、整列、および詰め物に関連する変化を除いて、それらはそのままでコピーされます。 また、[RFC3588]セクション4.1と[RFC4005]セクション9を見てください。
Congdon, et al. Standards Track [Page 10] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[10ページ]RFC4675VLANと優先権属性2006年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-リクエスト・パケットのために属性の適用性に関して言うものはDiameterでAA-要求[RFC4005]かDiameter-EAP-要求[RFC4072]に適用されます。 Access-挑戦に関して言われているものはDiameterでAVPがDIAMETER_MULTI_ROUND_AUTHに設定するResult-コードでAA-答え[RFC4005]かDiameter-EAP-答え[RFC4072]に適用されます。
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受け入れるのに関して言われているものはDiameterで成功を示すAA-答えかDiameter-EAP-答えメッセージに適用されます。 同様に、RADIUS Access-廃棄物パケットに関して言われているものはDiameterで失敗を示すAA-答えかDiameter-EAP-答えメッセージに適用されます。
What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC4005].
COA-要求に関して言われているものはDiameterでRe-Auth-要求[RFC4005]に適用されます。
What is said about Accounting-Request applies to Diameter Accounting-Request [RFC4005] as well.
Accounting-要求に関して言われているものはまた、Diameter Accounting-要求[RFC4005]に適用されます。
5. IANA Considerations
5. IANA問題
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/課題/半径でタイプするのを確実にしてください。 「半径属性タイプ」というセクションへの4つのアップデートの配分はIANAによってされました。 RADIUS属性は以下の通りです。
56 - Egress-VLANID 57 - Ingress-Filters 58 - Egress-VLAN-Name 59 - User-Priority-Table
56--出口-VLANID57--イングレスフィルタ58--出口VLAN名の59--ユーザ優先権テーブル
6. Security Considerations
6. セキュリティ問題
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].
この仕様はRADIUSとDiameterの認証と、承認と、IEEEで802のローカル・エリア・ネットワークを説明する目的の使用について説明します。 このアプリケーションのためのRADIUSの脅威と安全保障問題は[RFC3579]と[RFC3580]で説明されます。 ローミングで遭遇する安全保障問題は[RFC2607]で説明されます。 Diameterに関しては、このアプリケーションに関連する安全保障問題は[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パケットに含むことができる新しい属性を指定します。 Diameterでは、属性は[RFC3588]で指定されるように保護されます。 より詳細な記述に関してそれらのドキュメントを見てください。
Congdon, et al. Standards Track [Page 11] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[11ページ]RFC4675VLANと優先権属性2006年9月
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とDiameterでサポートされたセキュリティー対策は集中しています。 彼らは、認可されたRADIUS/直径サーバかプロキシが悪意で属性を挿入するのを防ぎません。
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/直径サーバかプロキシによって送られたVLAN属性は権限のないVLANsへのアクセスを可能にするかもしれません。 NASで許可検査を実行することによって、これらの脆弱性を制限できます。 例えば、与えられたRADIUS/直径サーバ/プロキシからあるVLANIDsだけを受け入れるために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/直径サーバのコントロールを獲得する攻撃者かプロキシがユーザ優先権テーブルを変更できます、サービスの質の低下(ポートに到着するフレームのユーザ優先権を格下げするのによる)かサービスの否定(デバイスの複数のポートのトラフィックの優先権についてレベルを上げるか、スイッチを「過剰-申し込」むか、またはリンク能力による)のどちらかを引き起こして。
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, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[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.ハリントン、「トラフィックのクラス、マルチキャストフィルタリング、およびバーチャルLAN拡大とのブリッジのための管理オブジェクトの定義」RFC4363(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 Std802、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規格: メディアアクセスは2004年6月に(MAC)ブリッジ、IEEE Std 802.1D-2004を制御します。
Congdon, et al. Standards Track [Page 12] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[12ページ]RFC4675VLANと優先権属性2006年9月
[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の規格を作成してください。
7.2. Informative References
7.2. 有益な参照
[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規格: ポートは2004年12月にNetwork Access Control、IEEE Std 802.1X-2004を基礎づけました。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
[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.とライファーとD.とルーベンとA.とシュライバーとJ.とHoldrege、M.とI.Goyret、「トンネルプロトコルサポートのための半径属性」RFC2868(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] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな承認拡大はユーザでサービス(半径)にダイヤルします」、RFC3576、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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(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] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(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.ミットン、「直径ネットワークアクセス・サーバーアプリケーション」、RFC4005、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)アプリケーション」、RFC4072、2005年8月。
8. Acknowledgements
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、Enterasysのデヴィッド・ネルソン、ヒューレット・パッカードのチャックBlack、およびマイクロソフトのAshwin Palekarを承認したがっています。
Congdon, et al. Standards Track [Page 13] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[13ページ]RFC4675VLANと優先権属性2006年9月
Authors' Addresses
作者のアドレス
Paul Congdon Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747
ポールコングドンヒューレット・パッカード会社hp ProCurve Networking8000山麓の丘Blvd、M/S5662ローズビル、カリフォルニア 95747
Phone: +1 916 785 5753 Fax: +1 916 785 8478 EMail: paul.congdon@hp.com
以下に電話をしてください。 +1 916 785、5753Fax: +1 8478年の916 785メール: paul.congdon@hp.com
Mauricio Sanchez Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5559 Roseville, CA 95747
マウリシオサンチェスヒューレット・パッカード会社hp ProCurve Networking8000山麓の丘Blvd、M/S5559ローズビル、カリフォルニア 95747
Phone: +1 916 785 1910 Fax: +1 916 785 1815 EMail: mauricio.sanchez@hp.com
以下に電話をしてください。 +1 916 785、1910Fax: +1 1815年の916 785メール: 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、6605Fax: +1 7329年の425 936メール: bernarda@microsoft.com
Congdon, et al. Standards Track [Page 14] RFC 4675 VLAN and Priority Attributes September 2006
コングドン、他 標準化過程[14ページ]RFC4675VLANと優先権属性2006年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Congdon, et al. Standards Track [Page 15]
コングドン、他 標準化過程[15ページ]
一覧
スポンサーリンク
