From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3069.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3069.txt (limited to 'doc/rfc/rfc3069.txt') 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 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] + -- cgit v1.2.3