Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment
RFC 5517
Document | Type |
RFC - Informational
(February 2010; No errata)
Was draft-sanjib-private-vlan (int)
|
|
---|---|---|---|
Authors | Marco Foschiano , Sanjib HomChaudhuri | ||
Last updated | 2018-12-20 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5517 (Informational) | |
Telechat date | |||
Responsible AD | Mark Townsley | ||
Send notices to | (None) |
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 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. 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. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. 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. 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. HomChaudhuri & Foschiano Informational [Page 1] RFC 5517 Private VLANs February 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 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 1. Introduction 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. 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. HomChaudhuri & Foschiano Informational [Page 2] RFC 5517 Private VLANs February 2010 1.1. Security Concerns with Sharing a VLAN 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 easeShow full document text