summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3069.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3069.txt')
-rw-r--r--doc/rfc/rfc3069.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3069.txt b/doc/rfc/rfc3069.txt
new file mode 100644
index 0000000..166fb6f
--- /dev/null
+++ b/doc/rfc/rfc3069.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group D. McPherson
+Request for Comments: 3069 Amber Networks, Inc.
+Category: Informational B. Dykes
+ Onesecure, Inc.
+ February 2001
+
+
+ VLAN Aggregation for Efficient IP Address Allocation
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document introduces the concept of Virtual Local Area Network
+ (VLAN) aggregation as it relates to IPv4 address allocation. A
+ mechanism is described by which hosts that reside in the same
+ physical switched infrastructure, but separate virtual broadcast
+ domains, are addressed from the same IPv4 subnet and share a common
+ default gateway IP address, thereby removing the requirement of a
+ dedicated IP subnet for each virtual Local Area Network (LAN) or
+ Metropolitan Area Network (MAN).
+
+ Employing such a mechanism significantly decreases IPv4 address
+ consumption in virtual LANs and MANs. It may also ease
+ administration of IPv4 addresses within the network.
+
+1. Introduction
+
+ The VLAN [802.1Q] aggregation technique described in this document
+ provides a mechanism by which hosts that reside within the same
+ physical switched infrastructure, but separate virtual broadcast
+ domains, may be addressed from the same IPv4 subnet and may share a
+ common default gateway IPv4 address.
+
+ Such a mechanism provides several advantages over traditional IPv4
+ addressing architectures employed in large switched LANs today. The
+ primary advantage, that of IPv4 address space conservation, can be
+ realized when considering the diagram in Figure 1:
+
+
+
+
+
+McPherson & Dykes Informational [Page 1]
+
+RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
+
+
+ Figure 1:
+
+ +------+ +------+ +------+ +------+ +------+
+ | | | | | | | | | |
+ | A.1 | | A.2 | | B.1 | | C.1 | | B.2 |
+ | | | | | | | | | |
+ +------+ +------+ +------+ +------+ +------+
+ \ | | | /
+ \ | | | /
+ \ +-----------------------------------+ /
+ | |
+ | Ethernet Switch(es) |
+ | |
+ +-----------------------------------+
+ |
+ |
+ +--------+
+ | |
+ | Router |
+ | |
+ +--------+
+
+ In the Figure 1 hosts A.1 and A.2 belong to customer A, VLAN A.
+ Hosts B.1 and B.2 belong to customer B, VLAN B. Host C.1 belongs to
+ customer C and resides in it's own virtual LAN, VLAN C.
+
+ Traditionally, an IP subnet would be allocated for each customer,
+ based on initial IP requirements for address space utilization, as
+ well as on projections of future utilization. For example, a scheme
+ such as that illustrated in Table 1 may be used.
+
+ Table 1:
+ Gateway Usable Customer
+ Customer IP Subnet Address Hosts Hosts
+ ======== ============ ======= ====== ========
+ A 1.1.1.0/28 1.1.1.1 14 13
+ B 1.1.1.16/29 1.1.1.17 6 5
+ C 1.1.1.24/30 1.1.1.25 2 1
+
+ Customer A's initial deployment consists of 2 hosts, though they
+ project growth of up to 10 hosts. As a result, they're allocated the
+ IP subnet 1.1.1.0/28 which provides 16 IP addresses. The first IP
+ address, 1.1.1.0, represents the subnetwork number. The last IP
+ address, 1.1.1.15, represents the directed broadcast address. The
+ first usable address of the subnet, 1.1.1.1, is assigned to the
+ router and serves as the default gateway IP address for the subnet.
+ The customer is left 13 IP addresses, even though their requirement
+ was only for 10 IP addresses.
+
+
+
+McPherson & Dykes Informational [Page 2]
+
+RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
+
+
+ Customer B's initial deployment consists of 2 hosts, though they
+ project growth of up to 5 hosts. As a result, they're allocated the
+ IP subnet 1.1.1.16/29 which provides 8 IP addresses. The first IP
+ address, 1.1.1.16, represents the subnetwork number. The last IP
+ address, 1.1.1.23, represents the directed broadcast address. The
+ first usable address of the subnet, 1.1.1.17, is assigned to the
+ router and serves as the default gateway IP address for the subnet.
+ The customer is left 5 with IP addresses.
+
+ Customer C's initial deployment consists of 1 host, and they have no
+ plans of deploying additional hosts. As a result, they're allocated
+ the IP subnet 1.1.1.24/30 which provides 4 IP addresses. The first
+ IP address, 1.1.1.24, represents the subnetwork number. The last IP
+ address, 1.1.1.27, represents the directed broadcast address. The
+ first usable address of the subnet, 1.1.1.25, is assigned to the
+ router and serves as the default gateway IP address for the subnet.
+ The customer is left 1 IP address.
+
+ The sum of address requirements for all three customers is 16. The
+ most optimal address allocation scheme here requires 28 IP addresses.
+
+ Now, if customer A only grows to use 3 of his available address, the
+ additional IP addresses can't be used for other customers.
+
+ Also, assume customer C determines the need to deploy one additional
+ host, and as such, requires one additional IP address. Because all
+ of the addresses within the existing IP subnet 1.1.1.24/30 are used,
+ and the following address space has been allocated to other
+ customers, a new subnet is required. Ideally, the customer would be
+ allocated a /29 and renumber host C.1 into the new subnet. However,
+ the customer is of the opinion that renumbering is not a viable
+ option. As such, another IP subnet is allocated to the customer,
+ this time perhaps a /29, providing two additional addresses for
+ future use.
+
+ As you can see, the number of IP addresses consumed by the subnetwork
+ number, directed broadcast address, and a unique gateway address for
+ each subnet is quite significant. Also, the inherent constraints of
+ the addressing architecture significantly reduce flexibility.
+
+2. Discussion
+
+ If within the switched environment, on the routed side of the
+ network, we introduce the notion of sub-VLANs and super-VLANs, a much
+ more optimal approach to IP addressing can be realized.
+
+
+
+
+
+
+McPherson & Dykes Informational [Page 3]
+
+RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
+
+
+ Essentially, what occurs is that each sub-VLAN (customer) remains
+ within a separate broadcast domain. One or more sub-VLANs belong to
+ a super-VLAN, and utilize the default gateway IP address of the
+ super-VLAN. Hosts within the sub-VLANs are numbered out of IP
+ subnets associated with the super-VLAN, and their IP subnet masking
+ information reflects that of the super-VLAN subnet.
+
+ If desired, the super-VLAN router performs functions similar to Proxy
+ ARP to enable communication between hosts that are members of
+ different sub-VLANs.
+
+ This model results in a much more efficient address allocation
+ architecture. It also provides network operators with a mechanism to
+ provide standard default gateway address assignments.
+
+ Let's again consider Figure 1, now utilizing the super-VLAN sub-VLAN
+ model. Table 2 provides the new addressing model.
+
+ Table 2:
+ Gateway Usable Customer
+ Customer IP Subnet Address Hosts Hosts
+ ======== ============ ======= ====== ========
+ A 1.1.1.0/24 1.1.1.1 10 .2-.11
+ B 1.1.1.0/24 1.1.1.1 5 .12-.16
+ C 1.1.1.0/24 1.1.1.1 1 .17
+
+ Customer A's initial deployment consists of 2 hosts, though they
+ project growth of up to 10 hosts. As a result, they're allocated the
+ IP address range 1.1.1.2 - 1.1.1.11. The gateway address for the
+ customer is 1.1.1.1, the subnet is 1.1.1.0/24.
+
+ Customer B's initial deployment consists of 2 hosts, though they
+ project growth of up to 5 hosts. As a result, they're allocated the
+ IP address range 1.1.1.12 - 1.1.1.16. The gateway address for the
+ customer is 1.1.1.1, the subnet is 1.1.1.0/24.
+
+ Customer C's initial deployment consists of 1 host, and they have no
+ plans of deploying additional hosts. As a result, they're allocated
+ the IP address 1.1.1.17. The gateway address for the customer is
+ 1.1.1.1, the subnet is 1.1.1.0/24.
+
+ The sum of address requirements for all three customers is 16. As a
+ result, only 16 addresses are allocated within the subnet. These 16
+ addresses, combined with the global default gateway address of
+ 1.1.1.1, as well as the subnetwork number of 1.1.1.0 and directed
+ broadcast of 1.1.1.255, result in a total of 19 addresses used. This
+ leaves 236 additional usable hosts address with the IP subnet.
+
+
+
+
+McPherson & Dykes Informational [Page 4]
+
+RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
+
+
+ Now, if customer A only grows to use 3 of his available addresses,
+ the additional IP addresses can be used for other customers.
+
+ Also, assume customer C determines the need to deploy one additional
+ host, and as such, requires one additional IP address. The customer
+ is simply allocated the next available IP address within the subnet,
+ their default gateway remains the same.
+
+ The benefits of such a model are obvious, especially when employed in
+ large LANs or MANs.
+
+3. Use of Directed Broadcasts
+
+ This specification provides no support for directed broadcasts.
+ Specifically, the <net, subnet, -1> directed broadcast address can
+ only apply to one of the Layer 2 broadcast domains.
+
+ Though use of directed broadcast is frowned upon in the Internet
+ today, there remain a number of applications, primarily in the
+ enterprise arena, that continue to use them. As such, care should be
+ taken to understand the implications of using these applications in
+ conjunction with the addressing model outlined in this specification.
+
+4. Multicast Considerations
+
+ It is assumed that the Layer 2 multicast domain will be the same as
+ the Layer 2 broadcast domain (i.e., VLAN). As such, this means that
+ for an IP multicast packet to reach all potential receivers in the IP
+ subnet the multicast router(s) attached to the IP subnet need to
+ employ something akin to IP host routes for the sender in order for
+ the Reverse Path Forwarding check to work.
+
+5. Deployment Considerations
+
+ Extreme Networks has a working implementation of this model that has
+ been deployed in service provider data center environments for over a
+ year now. Other vendors are rumored to be developing similar
+ functionality.
+
+6. Security Considerations
+
+ One obvious issue that does arise with this model is the
+ vulnerabilities created by permitting arbitrary allocation of
+ addresses across disparate broadcast domains. It is advised that
+ address space ranges be made sticky. That is, when an address or
+ range of addresses is allocated to a given sub-VLAN, reception of IP
+
+
+
+
+
+McPherson & Dykes Informational [Page 5]
+
+RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
+
+
+ or ARP packets on a sub-VLAN with a source IP address that isn't
+ allocated to the sub-VLAN should be discarded, and perhaps trigger a
+ logging message or other administrative event.
+
+ Implementation details are intentionally omitted as all functions in
+ this document should remain local to the super-VLAN router. As such,
+ no interoperability issues with existing protocols should result.
+
+7. Acknowledgements
+
+ Thanks to Mike Hollyman and Erik Nordmark for their feedback.
+
+8. References
+
+ [802.1Q] IEEE 802.1Q, "Virtual LANs".
+
+9. Authors' Addresses
+
+ Danny McPherson
+ Amber Networks, Inc.
+ 48664 Milmont Drive
+ Fremont, CA 94538
+
+ EMail: danny@ambernetworks.com
+
+
+ Barry Dykes
+ OneSecure, Inc.
+ 2000 S. Colorado Blvd Suite 2-1100
+ Denver, CO. 80222
+
+ EMail: bdykes@onesecure.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson & Dykes Informational [Page 6]
+
+RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson & Dykes Informational [Page 7]
+