[要約] 要約：RFC 5517は、Cisco SystemsのプライベートVLAN（PVLAN）に関する情報を提供し、マルチクライアント環境での拡張可能なセキュリティを実現します。目的：このRFCの目的は、PVLANの設計と実装に関するガイドラインを提供し、セキュリティを向上させるためにPVLANを使用する組織やネットワーク管理者を支援することです。
Independent Submission S. HomChaudhuri
Request for Comments: 5517 M. Foschiano
Category: Informational Cisco Systems
ISSN: 2070-1721 February 2010
Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment
シスコシステムズのプライベートVLAN：マルチクライアント環境でのスケーラブルなセキュリティ
Abstract
概要
This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.
このドキュメントでは、特別なレイヤ2転送制約を適用してデバイスを分離するメカニズムについて説明します。このようなメカニズムにより、エンドデバイスはレイヤ2で隔離された状態で同じIPサブネットを共有できるため、ネットワーク設計者はより大きなサブネットを使用でき、アドレス管理のオーバーヘッドを削減できます。
Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details.
前述のメカニズム（データセンターの設計からEthernet-to-the-home-basementネットワークまでの範囲）の多数の展開シナリオのいくつかを、メカニズムの可能な使用法を例示するために以下のテキストで説明します。ただし、このドキュメントは、そのようなすべての展開シナリオをカバーすることも、それらの詳細を掘り下げることも意図していません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5517.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5517で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Security Concerns with Sharing a VLAN ......................3
1.2. The Traditional Solution and Its Related Problems ..........3
2. Private VLANs Architecture ......................................4
2.1. VLAN Pairings and Their Port-Related Characteristics .......7
3. Extending Private VLANs across Switches .........................9
4. A More Flexible IP Addressing Scheme ............................9
5. Routing Considerations .........................................10
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
In an Ethernet switch, a VLAN is a broadcast domain in which hosts can establish direct communication with one another at Layer 2. If untrusted devices are introduced into a VLAN, security issues may arise because trusted and untrusted devices end up sharing the same broadcast domain.
イーサネットスイッチでは、VLANはブロードキャストドメインであり、ホストはレイヤ2で相互に直接通信を確立できます。信頼できないデバイスがVLANに導入されると、信頼できるデバイスと信頼できないデバイスが同じブロードキャストドメインを共有することになるため、セキュリティの問題が発生する可能性があります。
The traditional solution to this kind of problem is to assign a separate VLAN to each user concerned about Layer 2 security issues. However, the IEEE 802.1Q standard [802.1Q] specifies that the VLAN ID field in an Ethernet frame is 12 bits wide. That allows for a theoretical maximum of 4094 VLANs in an Ethernet network (VLAN numbers 0 and 4095 are reserved). If the network administrator assigns one VLAN per user, then that equates to a maximum of 4094 users that can be supported. The private VLANs technology described in this memo addresses this scalability problem by offering more granular and more flexible Layer 2 segregation, as explained in the following sections.
この種の問題に対する従来の解決策は、レイヤー2のセキュリティ問題を懸念する各ユーザーに個別のVLANを割り当てることです。ただし、IEEE 802.1Q標準[802.1Q]は、イーサネットフレームのVLAN IDフィールドが12ビット幅であることを規定しています。これにより、イーサネットネットワークで理論的に最大4094のVLANが可能になります（VLAN番号0および4095は予約されています）。ネットワーク管理者がユーザーごとに1つのVLANを割り当てる場合、それはサポートできる最大4094のユーザーに相当します。このメモで説明するプライベートVLANテクノロジーは、次のセクションで説明するように、より細かく柔軟なレイヤー2分離を提供することにより、このスケーラビリティの問題に対処します。
Companies who have Internet presence can either host their servers in their own premises or, alternatively, they can locate their servers at the Internet Service Provider's premises. A typical ISP would have a server farm that offers web-hosting functionality for a number of customers. Co-locating the servers in a server farm offers ease of management but, at the same time, may raise security concerns.
インターネットに接続している企業は、自社のサーバーを自社の敷地内でホストすることも、インターネットサービスプロバイダーの敷地内にサーバーを配置することもできます。一般的なISPには、多数の顧客にWebホスティング機能を提供するサーバーファームがあります。サーバーをサーバーファームに同じ場所に配置すると、管理が容易になりますが、同時にセキュリティ上の問題が発生する可能性があります。
Let us assume that the ISP puts all the servers in one big VLAN. Servers residing in the same VLAN can listen to Layer 2 broadcasts from other servers. Once a server learns the Media Access Control (MAC) address associated to the IP address of another computer in the same VLAN, it can establish direct Layer 2 communication with that device without having to go through a Layer 3 gateway/firewall. If, for example, an attacker gets access to one of the servers, he or she can use that compromised host to launch an attack on other servers in the server farm. To protect themselves from malicious attacks, ISP customers want their machines to be isolated from other machines in the same server farm.
ISPがすべてのサーバーを1つの大きなVLANに配置するとします。同じVLANにあるサーバーは、他のサーバーからのレイヤー2ブロードキャストをリッスンできます。サーバーが同じVLAN内の別のコンピューターのIPアドレスに関連付けられたメディアアクセス制御（MAC）アドレスを学習すると、レイヤー3ゲートウェイ/ファイアウォールを経由することなく、そのデバイスとの直接のレイヤー2通信を確立できます。たとえば、攻撃者がいずれかのサーバーにアクセスした場合、攻撃者はその侵害されたホストを使用して、サーバーファーム内の他のサーバーに攻撃を仕掛けることができます。 ISPの顧客は、悪意のある攻撃から身を守るために、マシンを同じサーバーファーム内の他のマシンから分離することを望んでいます。
The security concerns become even more apparent in metropolitan area networks. Metropolitan Service Providers may want to provide Layer 2 Ethernet access to homes, rental communities, businesses, etc. In this scenario, the subscriber next door could very well be a malicious network user.
セキュリティの問題は、メトロポリタンエリアネットワークでさらに顕著になります。メトロポリタンサービスプロバイダーは、家、賃貸コミュニティ、企業などへのレイヤー2イーサネットアクセスを提供したい場合があります。このシナリオでは、隣の加入者が悪意のあるネットワークユーザーである可能性があります。
It is therefore very important to offer Layer 2 traffic isolation among customers. Customer A would not want his Layer 2 frames being broadcast to customer B, who happens to be in the same VLAN. Also, customer A would not want customer B to bypass a router or a firewall and establish direct Layer 2 communication with him/her.
したがって、顧客間でレイヤー2トラフィックを分離することが非常に重要です。カスタマーAは、たまたま同じVLANにいるカスタマーBにレイヤ2フレームをブロードキャストすることを望んでいません。また、顧客Aは、顧客Bがルーターまたはファイアウォールをバイパスして、直接顧客とのレイヤー2通信を確立することを望まないでしょう。
The traditional solution would be to assign a separate VLAN to each customer. That way, each user would be assured of Layer 2 isolation from devices belonging to other users.
従来のソリューションは、各顧客に個別のVLANを割り当てることでした。このようにして、各ユーザーは、他のユーザーに属するデバイスからのレイヤー2分離が保証されます。
However, with the VLAN-per-customer model, if an ISP wanted to offer web-hosting services to, say, 4000 customers, it would consume 4000 VLANs. Theoretically, the maximum number of VLANs that an 802.1Q-compliant networking device can support is 4094. In reality, many devices support a much smaller number of active VLANs. Even if all devices supported all 4094 VLANs, there would still be a scalability problem when the 4095th customer signed up.
ただし、顧客ごとのVLANモデルでは、ISPがWebホスティングサービスをたとえば4000人の顧客に提供したい場合、4000個のVLANを消費します。理論的には、802.1Q準拠のネットワーキングデバイスがサポートできるVLANの最大数は4094です。実際には、多くのデバイスがサポートするアクティブVLANの数ははるかに少ないです。すべてのデバイスが4094のVLANをすべてサポートしていたとしても、4095番目の顧客がサインアップしたときにスケーラビリティの問題が発生します。
A second problem with assigning a separate VLAN per customer is management of IP addresses. Since each VLAN requires a separate subnet, there can be potential wastage of IP addresses in each subnet. This issue has been described by RFC 3069 [RFC3069] and will not be discussed in detail in this document.
顧客ごとに個別のVLANを割り当てる場合の2番目の問題は、IPアドレスの管理です。各VLANには個別のサブネットが必要であるため、各サブネットでIPアドレスが浪費される可能性があります。この問題はRFC 3069 [RFC3069]で説明されており、このドキュメントでは詳しく説明しません。
The private VLANs architecture is similar to but more elaborate than the aggregated VLAN model proposed in RFC 3069. The concepts of 'super VLAN' and 'sub VLAN' used in that RFC are functionally similar to the concepts of 'primary VLAN' and 'secondary VLAN' used in this document.
プライベートVLANアーキテクチャは、RFC 3069で提案されている集約VLANモデルに似ていますが、より複雑です。そのRFCで使用される「スーパーVLAN」と「サブVLAN」の概念は、「プライマリVLAN」と「セカンダリ」の概念と機能的に類似しています。このドキュメントで使用されているVLAN '。
On the other hand, the private VLANs technology differs from the mechanism described in [RFC4562] because instead of using a MAC-address-based 'forced forwarding' scheme it uses a VLAN-based one.
一方、プライベートVLANテクノロジーは、MACアドレスベースの「強制転送」スキームを使用する代わりにVLANベースのスキームを使用するため、[RFC4562]で説明されているメカニズムとは異なります。
A regular VLAN is a single broadcast domain. The private VLANs technology partitions a larger VLAN broadcast domain into smaller sub-domains. So far, two kinds of special sub-domains specific to the private VLANs technology have been defined: an 'isolated' sub-domain and a 'community' sub-domain. Each sub-domain is defined by assigning a proper designation to a group of switch ports.
通常のVLANは単一のブロードキャストドメインです。プライベートVLANテクノロジーは、大きなVLANブロードキャストドメインを小さなサブドメインに分割します。これまでに、プライベートVLANテクノロジーに固有の2種類の特別なサブドメインが定義されています。「分離された」サブドメインと「コミュニティ」サブドメインです。各サブドメインは、スイッチポートのグループに適切な指定を割り当てることによって定義されます。
Within a private VLAN domain, three separate port designations exist. Each port designation has its own unique set of rules, which regulate a connected endpoint's ability to communicate with other connected endpoints within the same private VLAN domain. The three port designations are promiscuous, isolated, and community.
プライベートVLANドメイン内には、3つの異なるポート指定があります。各ポートの指定には、独自の一意のルールセットがあり、同じプライベートVLANドメイン内の他の接続されたエンドポイントと通信する接続されたエンドポイントの機能を規制します。 3つのポート指定は、無差別、分離、およびコミュニティです。
An endpoint connected to a promiscuous port has the ability to communicate with any endpoint within the private VLAN. Multiple promiscuous ports may be defined within a single private VLAN domain. In most networks, Layer 3 default gateways or network management stations are commonly connected to promiscuous ports.
無差別ポートに接続されたエンドポイントは、プライベートVLAN内の任意のエンドポイントと通信できます。単一のプライベートVLANドメイン内で複数の無差別ポートを定義できます。ほとんどのネットワークでは、レイヤ3のデフォルトゲートウェイまたはネットワーク管理ステーションは、通常、無差別ポートに接続されています。
Isolated ports are typically used for those endpoints that only require access to a limited number of outgoing interfaces on a private-VLAN-enabled device. An endpoint connected to an isolated port will only possess the ability to communicate with those endpoints connected to promiscuous ports. Endpoints connected to adjacent isolated ports cannot communicate with one another. For example, within a web-hosting environment, isolated ports can be used to connect hosts that require access only to default gateways.
分離ポートは通常、プライベートVLAN対応デバイス上の限られた数の発信インターフェイスへのアクセスのみを必要とするエンドポイントに使用されます。隔離されたポートに接続されたエンドポイントは、無差別ポートに接続されたエンドポイントと通信する機能しか持っていません。隣接する分離ポートに接続されたエンドポイントは、相互に通信できません。たとえば、Webホスティング環境では、隔離されたポートを使用して、デフォルトゲートウェイへのアクセスのみを必要とするホストを接続できます。
A community port is a port that is part of a private VLAN community, which is a grouping of ports connected to devices belonging to the same entity (for example, a group of hosts of the same ISP customer or a pool of servers in a data center). Within a community, endpoints can communicate with one another and can also communicate with any configured promiscuous port. Endpoints belonging to one community cannot instead communicate with endpoints belonging to a different community or with endpoints connected to isolated ports.
コミュニティポートは、プライベートVLANコミュニティの一部であるポートです。これは、同じエンティティに属するデバイスに接続されたポートのグループです（たとえば、同じISPの顧客のホストのグループ、またはデータ内のサーバーのプール）。センター）。コミュニティ内では、エンドポイントは相互に通信でき、構成された任意の無差別ポートとも通信できます。代わりに、1つのコミュニティに属するエンドポイントは、別のコミュニティに属するエンドポイントや、独立したポートに接続されたエンドポイントと通信できません。
The aforementioned three port designations directly correspond to three different VLAN types (primary, isolated, and community) with well-defined, port-related characteristics, which are described in detail in Section 2.1 below.
前述の3つのポート指定は、明確に定義されたポート関連の特性を持つ3つの異なるVLANタイプ（プライマリ、分離、およびコミュニティ）に直接対応します。これらについては、以下のセクション2.1で詳しく説明します。
Figure 1 below illustrates the private VLAN model from a switch port classification perspective.
次の図1は、スイッチポート分類の観点からプライベートVLANモデルを示しています。
-----------
| R |
-----------
|
|
|
----------------------------------------
| p1 |
| |
=====| t1 |
| switch |
| |
| |
|i1 i2 c1 c2 |
----------------------------------------
| | | |
| | | |
| | | |
A B C D
A, B - Isolated devices C, D - Community devices R - Router (or other L4-L7 device) i1, i2 - Isolated switch ports c1, c2 - Community switch ports p1 - Promiscuous switch port t1 - Inter-switch link port (a VLAN-aware port)
A、B-分離デバイスC、D-コミュニティデバイスR-ルーター（またはその他のL4-L7デバイス）i1、i2-分離スイッチポートc1、c2-コミュニティスイッチポートp1-無差別スイッチポートt1-スイッチ間リンクポート（ VLAN対応ポート）
Figure 1. Private VLAN classification of switch ports
図1.スイッチポートのプライベートVLAN分類
With reference to Figure 1, each of the port types is described below.
図1を参照して、各ポートタイプについて以下に説明します。
Isolated ports: An isolated port, e.g., i1 or i2, cannot talk to any other port in the private VLAN domain except for promiscuous ports (e.g., p1). If a customer device needs to have access only to a gateway router, then it should be attached to an isolated port.
分離ポート：分離ポート（i1やi2など）は、混合ポート（p1など）を除いて、プライベートVLANドメイン内の他のポートと通信できません。お客様のデバイスがゲートウェイルーターにのみアクセスする必要がある場合は、隔離されたポートに接続する必要があります。
Community ports: A community port, e.g., c1 or c2, is part of a group of ports. The ports within a community can have Layer 2 communications with one another and can also talk to any promiscuous port. If an ISP customer has, say, 2 devices that he/she wants to be isolated from other customers' devices but to be able to communicate among themselves, then community ports should be used.
コミュニティポート：コミュニティポート（c1やc2など）は、ポートのグループの一部です。コミュニティ内のポートは、互いにレイヤ2通信を行うことができ、任意の無差別ポートと通信することもできます。たとえば、ISPの顧客が他の顧客のデバイスから分離したいが、それらの間で通信できるようにしたいデバイスが2つある場合は、コミュニティポートを使用する必要があります。
Promiscuous ports: As the name suggests, a promiscuous port (p1) can talk to all other types of ports. A promiscuous port can talk to isolated ports as well as community ports and vice versa. Layer 3 gateways, DHCP servers, and other 'trusted' devices that need to communicate with the customer endpoints are typically connected via promiscuous ports.
無差別ポート：名前が示すように、無差別ポート（p1）は他のすべてのタイプのポートと通信できます。プロミスキャスポートは、コミュニティポートと同様に隔離ポートと通信でき、その逆も可能です。レイヤ3ゲートウェイ、DHCPサーバー、および顧客のエンドポイントと通信する必要があるその他の「信頼できる」デバイスは、通常、無差別ポートを介して接続されます。
Please note that isolated, community, and promiscuous ports can either be access ports or hybrid/trunk ports (according to the terminology presented in Annex D of the IEEE 802.1Q specification, up to its 2004 revision).
分離、コミュニティ、および無差別のポートは、アクセスポートまたはハイブリッド/トランクポートのいずれかであることに注意してください（IEEE 802.1Q仕様の付録Dに記載されている用語によると、2004年の改訂まで）。
The table below summarizes the communication privileges between the different private VLAN port types.
次の表は、さまざまなプライベートVLANポートタイプ間の通信権限をまとめたものです。
---------------------------------------------------------------
| | isolat-| promis-| commu-| commu-| interswitch |
| | ted | cuous | nity1 | nity2 | link port |
---------------------------------------------------------------
| isolated | deny | permit | deny | deny | permit |
---------------------------------------------------------------
| promiscuous | permit | permit | permit| permit| permit |
---------------------------------------------------------------
| community1 | deny | permit | permit| deny | permit |
---------------------------------------------------------------
| community2 | deny | permit | deny | permit| permit |
---------------------------------------------------------------
| interswitch | | | | | |
| link port | deny(*)| permit | permit| permit| permit |
---------------------------------------------------------------
Table 1
表1
(*) Please note that this asymmetric behavior is for traffic traversing inter-switch link ports over an isolated VLAN only.
（*）この非対称動作は、隔離されたVLANを介してスイッチ間リンクポートを通過するトラフィックのみを対象としていることに注意してください。
Traffic from an inter-switch link port to an isolated port will be denied if it is in the isolated VLAN. Traffic from an inter-switch link port to an isolated port will be permitted if it is in the primary VLAN (see below for the different VLAN characteristics).
スイッチ間リンクポートから隔離ポートへのトラフィックは、隔離VLANにある場合は拒否されます。スイッチ間リンクポートから隔離ポートへのトラフィックは、それがプライマリVLANにある場合は許可されます（さまざまなVLAN特性については以下を参照してください）。
N.B.: An inter-switch link port is simply a regular port that connects two switches (and that happens to carry two or more VLANs).
注：スイッチ間リンクポートは、2つのスイッチを接続する（そしてたまたま2つ以上のVLANを運ぶ）通常のポートです。
In practice, the Layer 2 communication constraints described in the table above can be enforced by creating sub-domains within the same VLAN domain. However, a sub-domain within a VLAN domain cannot be easily implemented with only one VLAN ID. Instead, a mechanism of pairing VLAN IDs can be used to achieve this notion. Specifically, sub-domains can be represented by pairs of VLAN numbers:
実際には、上記の表で説明されているレイヤ2通信の制約は、同じVLANドメイン内にサブドメインを作成することで適用できます。ただし、VLANドメイン内のサブドメインは、1つのVLAN IDだけで簡単に実装することはできません。代わりに、VLAN IDをペアにするメカニズムを使用して、この概念を実現できます。具体的には、サブドメインはVLAN番号のペアで表すことができます。
<Vp,Vs> Vp is the primary VLAN ID ------
Vs is the secondary VLAN ID | Vp |
------
where Vs can be: / \
- Vi (an isolated VLAN) / \
- Vc (a community VLAN) / \
------ ------
| Vi | | Vc |
------ ------
<Vp,Vi> <Vp,Vc>
Figure 2. A private VLAN domain can be implemented with one or more VLAN ID pairs.
図2.プライベートVLANドメインは、1つ以上のVLAN IDペアで実装できます。
A private VLAN domain is built with at least one pair of VLAN IDs: one (and only one) primary VLAN ID (Vp) plus one or more secondary VLAN IDs (Vs). Secondary VLANs can be of two types: isolated VLANs (Vi) or community VLANs (Vc).
プライベートVLANドメインは、少なくとも1対のVLAN IDで構築されます。1つ（1つのみ）のプライマリVLAN ID（Vp）と1つ以上のセカンダリVLAN ID（Vs）です。セカンダリVLANには、独立VLAN（Vi）またはコミュニティVLAN（Vc）の2つのタイプがあります。
A primary VLAN is the unique and common VLAN identifier of the whole private VLAN domain and of all its VLAN ID pairs.
プライマリVLANは、プライベートVLANドメイン全体とそのすべてのVLAN IDペアの一意かつ共通のVLAN識別子です。
An isolated VLAN is a secondary VLAN whose distinctive characteristic is that all hosts connected to its ports are isolated at Layer 2. Therefore, its primary quality is that it allows a design based on private VLANs to use a total of only two VLAN identifiers (i.e., a single private VLAN pairing) to provide port isolation and serve any number of end users (vs. a traditional design in which one separate plain VLAN ID would be assigned to each port).
分離VLANは、ポートに接続されたすべてのホストがレイヤー2で分離されているという特徴があるセカンダリVLANです。したがって、その主な品質は、プライベートVLANに基づく設計で合計2つのVLAN識別子のみを使用できることです（つまり、 、単一のプライベートVLANペア）でポートを分離し、任意の数のエンドユーザーにサービスを提供します（従来の設計では、1つの個別のプレーンVLAN IDが各ポートに割り当てられていました）。
A community VLAN is a secondary VLAN that is associated to a group of ports that connect to a certain "community" of end devices with mutual trust relationships.
コミュニティVLANは、相互信頼関係を持つエンドデバイスの特定の「コミュニティ」に接続するポートのグループに関連付けられているセカンダリVLANです。
While only one isolated VLAN is allowed in a private VLAN domain, there can be multiple distinct community VLANs.
プライベートVLANドメインでは1つの分離VLANのみが許可されていますが、複数の異なるコミュニティVLANが存在する場合があります。
Please note that this VLAN pairing scheme simply requires that all traffic transported within primary and secondary VLANs be tagged according to the IEEE 802.1Q standard (see for example [802.1Q], Section B.1.3), with at most a single standard VLAN tag. No special double-tagging is necessary due to the 1:1 correspondence between a secondary VLAN and its associated primary VLAN.
このVLANペアリングスキームでは、プライマリVLANとセカンダリVLAN内で転送されるすべてのトラフィックに、IEEE 802.1Q標準（[802.1Q]のセクションB.1.3などを参照）に従ってタグを付け、最大で1つの標準VLANタグを付ける必要があることに注意してください。 。セカンダリVLANとそれに関連付けられたプライマリVLANは1：1で対応しているため、特別な二重タグ付けは必要ありません。
(Also note that this document makes use of the "traditional" VLAN terminology, whereas the IEEE 802.1ag standard [802.1ag] amends key sections of IEEE 802.1Q-2005 to make the distinction between "VLANs" and "VLAN IDs" so that every "VLAN" can be assigned one or more VLAN IDs, similarly to the pairing scheme described in this document.)
（また、このドキュメントでは「従来の」VLAN用語を使用しているのに対し、IEEE 802.1ag標準[802.1ag]は、IEEE 802.1Q-2005の主要セクションを修正して、「VLAN」と「VLAN ID」を区別するようにしています。このドキュメントで説明されているペアリングスキームと同様に、すべての「VLAN」には1つ以上のVLAN IDを割り当てることができます。
The ports in a private VLAN domain derive their special characteristics (as described in Section 2) from the VLAN pairing(s) they are configured with. In particular, a promiscuous port is a port that can communicate with all other private VLAN port types via the primary VLAN and any associated secondary VLANs, whereas isolated or community ports can communicate over their respective secondary VLANs only.
プライベートVLANドメイン内のポートは、（セクション2で説明されているように）構成されているVLANペアからそれらの特別な特性を引き出します。特に、混合ポートは、プライマリVLANおよび関連するセカンダリVLANを介して他のすべてのプライベートVLANポートタイプと通信できるポートですが、独立ポートまたはコミュニティポートは、それぞれのセカンダリVLANを介してのみ通信できます。
For example, with reference to Figure 1, a router R connected to the promiscuous port can have Layer 2 communication with a device A connected to an isolated port and also with a device C connected to a community port. Devices C and D can also have Layer 2 communication between themselves since they are part of the same community VLAN. However, devices A and B cannot communicate at Layer 2 due to the special port segregation property of the isolated VLAN. Also, devices A and C cannot communicate at Layer 2 since they belong to different secondary VLANs.
たとえば、図1を参照すると、プロミスキャスポートに接続されたルータRは、隔離ポートに接続されたデバイスAと、コミュニティポートに接続されたデバイスCとのレイヤ2通信を行うことができます。デバイスCとDは、同じコミュニティVLANの一部であるため、デバイス間でレイヤ2通信を行うこともできます。ただし、デバイスAとBは、隔離されたVLANの特別なポート分離プロパティのため、レイヤー2で通信できません。また、デバイスAとCは異なるセカンダリVLANに属しているため、レイヤー2で通信できません。
The impact of these enforced forwarding restrictions is two-fold. Firstly, service providers can assign multiple customers to the same isolated VLAN, thereby conserving VLAN IDs. Secondly, end users can be assured that their Layer 2 traffic cannot be sniffed by other end users sharing the same isolated VLAN or connected to a different secondary VLAN.
これらの強制転送制限の影響は2つあります。まず、サービスプロバイダーは複数の顧客を同じ隔離されたVLANに割り当てることができるため、VLAN IDを節約できます。第2に、エンドユーザーは、同じ分離VLANを共有している、または別のセカンダリVLANに接続されている他のエンドユーザーがレイヤー2トラフィックを傍受できないことを保証できます。
Some switch vendors have attempted to provide a port isolation feature within a VLAN by implementing special logic at the port level. However, when implemented at the port level, the isolation behavior is restricted to a single switch.
一部のスイッチベンダーは、ポートレベルで特別なロジックを実装することにより、VLAN内にポート分離機能を提供しようとしました。ただし、ポートレベルで実装した場合、分離動作は単一のスイッチに制限されます。
When a VLAN spans multiple switches, there is no standard mechanism to propagate port-level isolation information to other switches and, consequently, the isolation behavior fails in other switches.
VLANが複数のスイッチにまたがっている場合、ポートレベルの分離情報を他のスイッチに伝達する標準的なメカニズムがないため、他のスイッチでは分離動作が失敗します。
In this document, the proposal is to implement the port isolation information implicitly at the VLAN level. A particular VLAN ID can be configured to be the isolated VLAN. All switches in the network would give special "isolated VLAN" treatment to frames tagged with this particular VLAN ID. Thereby, the isolated VLAN behavior can be maintained consistently across all switches in a Layer 2 network.
このドキュメントでは、ポート分離情報を暗黙的にVLANレベルで実装することが提案されています。特定のVLAN IDを隔離VLANとして構成できます。ネットワーク内のすべてのスイッチは、この特定のVLAN IDでタグ付けされたフレームに特別な「隔離されたVLAN」の扱いを与えます。これにより、レイヤー2ネットワーク内のすべてのスイッチにわたって、分離されたVLANの動作を一貫して維持できます。
In general, isolated, community, and primary VLANs can all span multiple switches, just like regular VLANs. Inter-switch link ports need not be aware of the special VLAN type and will carry frames tagged with these VLANs just like they do any other frames.
一般に、独立VLAN、コミュニティVLAN、およびプライマリVLANは、通常のVLANと同様に、すべて複数のスイッチにまたがることができます。スイッチ間リンクポートは、特別なVLANタイプを認識する必要がなく、他のフレームと同様に、これらのVLANでタグ付けされたフレームを伝送します。
One of the objectives of the private VLANs architecture is to ensure that traffic from an isolated port in one switch does not reach another isolated or community port in a different switch even after traversing an inter-switch link. By implicitly embedding the isolation information at the VLAN level and by transporting it along with the packet, it is possible to maintain a consistent behavior throughout the network. Therefore, the mechanism discussed in Section 2, which will restrict Layer 2 communication between two isolated ports in the same switch, will also restrict Layer 2 communication between two isolated ports in two different switches.
プライベートVLANアーキテクチャの目的の1つは、スイッチ間リンクを通過した後でも、あるスイッチの分離ポートからのトラフィックが別のスイッチの別の分離ポートまたはコミュニティポートに到達しないようにすることです。 VLANレベルで分離情報を暗黙的に埋め込み、それをパケットとともに転送することにより、ネットワーク全体で一貫した動作を維持することが可能です。したがって、同じスイッチ内の2つの分離ポート間のレイヤー2通信を制限するセクション2で説明したメカニズムは、2つの異なるスイッチ内の2つの分離ポート間のレイヤー2通信も制限します。
The common practice of deploying multiple VLANs in a network for security reasons and of allocating a subnet to each VLAN has led to a certain number of inefficiencies in network designs, such as the suboptimal utilization of the IP addressing space (as exemplified in the introduction of RFC 3069 [RFC3069]). Moreover, each subnet requires addresses to be set aside for internetworking purposes (a subnetwork address, a directed broadcast address, default gateway address(es), etc.). So a high number of used VLANs traditionally translates into a significant number of special addresses to be consumed.
セキュリティ上の理由でネットワークに複数のVLANを展開し、各VLANにサブネットを割り当てるという一般的な慣習により、IPアドレッシングスペースの最適化されていない利用など、ネットワーク設計に一定の非効率性が生じました（ RFC 3069 [RFC3069]）。さらに、各サブネットには、インターネットワーキングのためにアドレスを確保しておく必要があります（サブネットワークアドレス、ダイレクトブロードキャストアドレス、デフォルトゲートウェイアドレスなど）。したがって、多数の使用済みVLANは従来、大量の特別なアドレスに変換されて消費されます。
On the other hand, in a private VLAN domain, all members can share a common address space that is part of a single subnet associated to the primary VLAN. An end device can be assigned an IP address statically or by using a DHCP server connected to a promiscuous port. Since IP addresses are no longer allocated on a smaller subnet basis but are assigned from a larger address pool shared by all members in the private VLAN domain, address allocation becomes much more efficient: fewer addresses are consumed for internetworking purposes, while most of the address space is allotted to end devices, leaving ample flexibility in the way available addresses are (re-)assigned.
一方、プライベートVLANドメインでは、すべてのメンバーが、プライマリVLANに関連付けられた単一のサブネットの一部である共通アドレススペースを共有できます。エンドデバイスには、静的に、または無差別ポートに接続されたDHCPサーバーを使用して、IPアドレスを割り当てることができます。 IPアドレスは、より小さなサブネットベースでは割り当てられなくなり、プライベートVLANドメインのすべてのメンバーによって共有されるより大きなアドレスプールから割り当てられるため、アドレス割り当てはより効率的になります。インターネットワーキングの目的で消費されるアドレスは少なく、ほとんどのアドレスはスペースはエンドデバイスに割り当てられ、使用可能なアドレスが（再）割り当てられる方法に十分な柔軟性を残します。
The entire private VLANs architecture confines secondary VLANs within the 2nd layer of the OSI model. With reference to Figure 2, the secondary VLANs are internal to a private VLAN domain. Layer 3 entities are not directly aware of their existence: to them it appears as if all the end devices are part of the primary VLAN.
プライベートVLANアーキテクチャ全体が、セカンダリVLANをOSIモデルの第2レイヤー内に限定します。図2を参照すると、セカンダリVLANはプライベートVLANドメインの内部にあります。レイヤ3エンティティは、それらの存在を直接認識していません。まるですべてのエンドデバイスがプライマリVLANの一部であるかのように見えます。
With reference to Figure 1, the isolation behavior between devices A and B is at the Layer 2 level only. Devices A and B can still communicate at the Layer 3 level via the router R. Since A and B are part of the same subnet, the router assumes that they should be able to talk directly to each other. That however is prevented by the isolated VLAN's specific behavior. So, in order to enable A and B to communicate via the router, a proxy-ARP-like functionality needs to be supported on the router interface.
図1を参照すると、デバイスAとデバイスBの間の分離動作は、レイヤー2レベルのみです。デバイスAとBは、引き続きルーターRを介してレイヤー3レベルで通信できます。AとBは同じサブネットの一部であるため、ルーターは互いに直接通信できると想定します。ただし、これは分離されたVLANの特定の動作によって防止されます。したがって、AとBがルーター経由で通信できるようにするには、ルーターインターフェイスでプロキシARPのような機能をサポートする必要があります。
With regard to the specific version of the IP protocol in use, all routing considerations apply to both IPv4 and IPv6 for the case of unicast traffic. On the other hand, due to their complexity, considerations about multicast bridging and routing within a private VLAN domain transcend the scope of this introductory document, and are therefore omitted.
使用中のIPプロトコルの特定のバージョンに関して、ユニキャストトラフィックの場合、ルーティングに関するすべての考慮事項がIPv4とIPv6の両方に適用されます。一方、その複雑さのため、プライベートVLANドメイン内でのマルチキャストブリッジングとルーティングに関する考慮事項は、この紹介ドキュメントの範囲を超えているため、省略されています。
In a heterogeneous Layer 2 network that is built with switches from multiple vendors, the private VLAN feature should be supported and configured on all the switches. If a switch S in that network does not support this feature, then there may be undesired forwarding of packets, including permanent flooding of Layer 2 unicast frames. That is because switch S is not aware of the association between primary and secondary VLANs and consequently cannot apply the segregation rules and constraints characteristic of the private VLANs architecture (an example of one such constraint is explained in [802.1Q], Section B.1.3). This impact is limited to traffic within
複数のベンダーのスイッチで構築された異種レイヤー2ネットワークでは、プライベートVLAN機能をサポートし、すべてのスイッチで構成する必要があります。そのネットワークのスイッチSがこの機能をサポートしていない場合、レイヤ2ユニキャストフレームの永続的なフラッディングなど、パケットの望ましくない転送が発生する可能性があります。これは、スイッチSがプライマリVLANとセカンダリVLAN間の関連付けを認識していないため、プライベートVLANアーキテクチャに特徴的な分離ルールと制約を適用できないためです（そのような制約の例については、[802.1Q]のセクションB.1.3で説明しています。 ）。この影響は、
the private VLAN domain and will not affect the regular Layer 2 forwarding behavior on other VLANs.
プライベートVLANドメインであり、他のVLANでの通常のレイヤ2転送動作には影響しません。
If the private VLAN feature is properly deployed, it can be used at Layer 2 to segregate individual users or groups of users from each other: this segregation allows a network designer to more effectively constrain Layer 2 forwarding so as to, for instance, block or contain unwanted inter-device communication like port scans or Address Resolution Protocol (ARP) poisoning attacks.
プライベートVLAN機能が適切に展開されている場合、レイヤー2で使用して、個々のユーザーまたはユーザーのグループを互いに分離できます。この分離により、ネットワーク設計者は、レイヤー2転送をより効果的に抑制して、たとえば、ブロックまたはポートスキャンやアドレス解決プロトコル（ARP）ポイズニング攻撃などの不要なデバイス間通信が含まれています。
Many people have contributed to the private VLANs architecture. We would particularly like to thank, in alphabetical order, Senthil Arunachalam, Jason Chen, Tom Edsall, Michael Fine, Herman Hou, Kannan Kothandaraman, Milind Kulkarni, Heng-Hsin Liao, Tom Nosella, Prasanna Parthasarathy, Ramesh Santhanakrishnan, Mukundan Sudarsan, Charley Wen, and Zhong Xu for their significant contributions.
多くの人々がプライベートVLANアーキテクチャに貢献しています。 Senthil Arunachalam、Jason Chen、Tom Edsall、Michael Fine、Herman Hou、Kannan Kothandaraman、Milind Kulkarni、Heng-Hsin Liao、Tom Nosella、Prasanna Parthasarathy、Ramesh Santhanakrishnan、Mukundan Sudarsan、Charley Wen、Zhong Xuの多大な貢献に感謝します。
[802.1Q] Institute of Electrical and Electronics Engineers, "Virtual Bridged Local Area Networks", IEEE Standard 802.1Q, 2005 Edition, May 2006.
[802.1Q] Institute of Electrical and Electronics Engineers、「Virtual Bridged Local Area Networks」、IEEE Standard 802.1Q、2005 Edition、2006年5月。
[802.1ag] Institute of Electrical and Electronics Engineers, "Connectivity Fault Management", IEEE Standard 802.1ag, 2007 Edition, December 2007.
[802.1ag] Institute of Electrical and Electronics Engineers、「Connectivity Fault Management」、IEEE Standard 802.1ag、2007 Edition、2007年12月。
[RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for Efficient IP Address Allocation", RFC 3069, February 2001.
[RFC3069]マクファーソン、D。およびB.ダイクス、「VLAN Aggregation for Efficient IP Address Allocation」、RFC 3069、2001年2月。
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006.
[RFC4562] Melsen、T。およびS. Blake、「MAC-Forced Forwarding：A Method for Subscriber Separation on an Ethernet Access Network」、RFC 4562、2006年6月。
Authors' Addresses
著者のアドレス
Marco Foschiano Cisco Systems, Inc. Via Torri Bianche 7 Vimercate, MI, 20059, Italy EMail: foschia@cisco.com; mfoschiano@gmail.com
Marco Foschiano Cisco Systems、Inc. Via Torri Bianche 7 Vimercate、MI、20059、Italy EMail：foschia@cisco.com; mfoschiano@gmail.com
Sanjib HomChaudhuri EMail: sanjibhc@gmail.com
Sanjeev Homchowdhuryメール：SanjeevK：Gmail.com