idnits 2.17.1 draft-mcpherson-vlan-ipagg-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 2119' on line 49 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Danny McPherson 2 INTERNET DRAFT Amber Networks, Inc. 3 Barry Dykes 4 December 2000 Onesecure, Inc. 6 VLAN Aggregation for Efficient IP Address Allocation 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 This document introduces the concept of VLAN [802.1Q] aggregation as 33 it relates to IPv4 address allocation. A mechanism is described by 34 which hosts that reside in the same physical switched infrastructure, 35 but separate virtual broadcast domains, are addressed from the same 36 IPv4 subnet and share a common default gateway IP address, thereby 37 removing the requirement of a dedicated IP subnet for each virtual 38 Local Area Network (LAN) or Metropolitan Area Network (MAN). 40 Employing such a mechanism significantly decreases IPv4 address 41 consumption in virtual LANs and MANs. It may also ease 42 administration overhead of IPv4 addresses within the network. 44 3. Specification of Requirements 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in [RFC 2119]. 50 4. Introduction 52 The VLAN aggregation technique described in this document provides a 53 mechanism by which hosts that reside within the same physical 54 switched infrastructure, but separate virtual broadcast domains, MAY 55 be addressed from the same IPv4 subnet and MAY share a common default 56 gateway IPv4 address. 58 Such a mechanism provides several advantages over traditional IPv4 59 addressing architectures employed in large switched LANs today. The 60 primary advantage, that of IPv4 address space conservation, can be 61 realized when considering the diagram in Figure 1: 63 Figure 1: 65 +------+ +------+ +------+ +------+ +------+ 66 | | | | | | | | | | 67 | A.1 | | A.2 | | B.1 | | C.1 | | B.2 | 68 | | | | | | | | | | 69 +------+ +------+ +------+ +------+ +------+ 70 | | | / 71 | | | / 72 +-----------------------------------+ / 73 | | 74 | Ethernet Switch(es) | 75 | | 76 +-----------------------------------+ 77 | 78 | 79 +--------+ 80 | | 81 | Router | 82 | | 83 +--------+ 85 In the Figure 1 hosts A.1 and A.2 belong to customer A, VLAN A. 86 Hosts B.1 and B.2 belong to customer B, VLAN B. Host C.1 belongs to 87 customer C and resides in it's own virtual LAN, VLAN C. 89 Traditionally, an IP subnet would be allocated for each customer, 90 based on initial IP requirements for address space utilization, as 91 well as on projections of future utilization. For example, a scheme 92 such as that illustrated in Table 1 may be used. 94 Table 1: 95 Gateway Usable Customer 96 Customer IP Subnet Address Hosts Hosts 97 ======== ============ ======= ====== ======== 98 A 1.1.1.0/28 1.1.1.1 14 13 99 B 1.1.1.16/29 1.1.1.17 6 5 100 C 1.1.1.24/30 1.1.1.25 2 1 102 Customer A's initial deployment consists of 2 hosts, though they 103 project growth of up to 10 hosts. As a result, they're allocated 104 the IP subnet 1.1.1.0/28 which provides 16 IP addresses. The first 105 IP address, 1.1.1.0, represents the subnetwork number. The last IP 106 address, 1.1.1.15, represents the directed broadcast address. The 107 first usable address of the subnet, 1.1.1.1, is assigned to the 108 router and serves as the default gateway IP address for the subnet. 109 The customer is left 13 IP addresses, even though their requirement 110 was only for 10 IP addresses. 112 Customer B's initial deployment consists of 2 hosts, though they 113 project growth of up to 5 hosts. As a result, they're allocated the 114 IP subnet 1.1.1.16/29 which provides 8 IP addresses. The first IP 115 address, 1.1.1.16, represents the subnetwork number. The last IP 116 address, 1.1.1.23, represents the directed broadcast address. The 117 first usable address of the subnet, 1.1.1.17, is assigned to the 118 router and serves as the default gateway IP address for the subnet. 119 The customer is left 5 with IP addresses. 121 Customer C's initial deployment consists of 1 host, and they have no 122 plans of deploying additional hosts. As a result, they're allocated 123 the IP subnet 1.1.1.24/30 which provides 4 IP addresses. The first 124 IP address, 1.1.1.24, represents the subnetwork number. The last IP 125 address, 1.1.1.27, represents the directed broadcast address. The 126 first usable address of the subnet, 1.1.1.25, is assigned to the 127 router and serves as the default gateway IP address for the subnet. 128 The customer is left 1 IP address. 130 The sum of address requirements for all three customers is 16. The 131 most optimal address allocation scheme here requires 28 IP addresses. 133 Now, if customer A only grows to use 3 of his available address, the 134 additional IP addresses can't be used for other customers. 136 Also, assume customer C determines the need to deploy one additional 137 host, and as such, requires one additional IP address. Because all 138 of the addresses within the existing IP subnet 1.1.1.24/30 are used, 139 and the following address space has been allocated to other 140 customers, a new subnet is required. Ideally, the customer would be 141 allocated a /29 and renumber host C.1 into the new subnet. However, 142 the customer is of the opinion that renumbering is not a viable 143 option. As such, another IP subnet is allocated to the customer, 144 this time perhaps a /29, providing two additional addresses for 145 future use. 147 As you can see, the number of IP addresses consumed by the subnetwork 148 number, directed broadcast address, and a unique gateway address for 149 each subnet is quite significant. Also, the inherent constraints of 150 the addressing architecture significantly reduce flexibility. 152 5. Discussion 154 If within the switched environment, on the routed side of the 155 network, we introduce the notion of sub-VLANs and super-VLANs, a much 156 more optimal approach to IP addressing can be realized. 158 Essentially, what occurs is that each sub-VLAN (customer) remains 159 within a separate broadcast domain. One or more sub-VLANs belong to 160 a super-VLAN, and utilize the default gateway IP address of the 161 super-VLAN. Hosts within the sub-VLANs are numbered out of IP 162 subnets associated with the super-VLAN, and their IP subnet masking 163 information reflects that of the super-VLAN subnet. 165 If desired, the super-VLAN router performs functions similar to Proxy 166 ARP to enable communication between hosts that are members of 167 different sub-VLANs. 169 This model results in a much more efficient address allocation 170 architecture. It also provides network operators with a mechanism to 171 provide standard default gateway address assignments. 173 Let's again consider Figure 1, now utilizing the super-VLAN sub-VLAN 174 model. Table 2 provides the new addressing model. 176 Table 2: 177 Gateway Usable Customer 178 Customer IP Subnet Address Hosts Hosts 179 ======== ============ ======= ====== ======== 180 A 1.1.1.0/24 1.1.1.1 10 .2-.11 181 B 1.1.1.0/24 1.1.1.1 5 .12-.16 182 C 1.1.1.0/24 1.1.1.1 1 .17 184 Customer A's initial deployment consists of 2 hosts, though they 185 project growth of up to 10 hosts. As a result, they're allocated 186 the IP address range 1.1.1.2 - 1.1.1.11. The gateway address for the 187 customer is 1.1.1.1, the subnet is 1.1.1.0/24. 189 Customer B's initial deployment consists of 2 hosts, though they 190 project growth of up to 5 hosts. As a result, they're allocated the 191 IP address range 1.1.1.12 - 1.1.1.16. The gateway address for the 192 customer is 1.1.1.1, the subnet is 1.1.1.0/24. 194 Customer C's initial deployment consists of 1 host, and they have no 195 plans of deploying additional hosts. As a result, they're allocated 196 the IP address 1.1.1.17. The gateway address for the customer is 197 1.1.1.1, the subnet is 1.1.1.0/24. 199 The sum of address requirements for all three customers is 16. As a 200 result, only 16 addresses are allocated within the subnet. These 16 201 addresses, combined with the global default gateway address of 202 1.1.1.1, as well as the subnetwork number of 1.1.1.0 and directed 203 broadcast of 1.1.1.255, result in a total of 19 addresses used. This 204 leaves 236 additional usable hosts address with the IP subnet. 206 Now, if customer A only grows to use 3 of his available addresses, 207 the additional IP addresses can be used for other customers. 209 Also, assume customer C determines the need to deploy one additional 210 host, and as such, requires one additional IP address. The customer 211 is simply allocated the next available IP address within the subnet, 212 their default gateway remains the same. 214 The benefits of such a model are obvious, especially when employed in 215 large LANs or MANs. 217 6. Use of Directed Broadcasts 219 This specification provides no support for directed broadcasts. 220 Specifically, the directed broadcast address can 221 only apply to one of the Layer 2 broadcast domains. 223 Though use of directed broadcast is frowned upon in the Internet 224 today, there remain a number of applications, primarily in the 225 enterprise arena, that continue to use them. As such, care should be 226 taken to understand the implications of using these applications in 227 conjunction with the addressing model outlined in this specification. 229 7. Multicast Considerations 231 It is assumed that the Layer 2 multicast domain will be the same as 232 the Layer 2 broadcast domain (i.e. VLAN). As such, this means that 233 for an IP multicast packet to reach all potential receivers in the IP 234 subnet the multicast router(s) attached to the IP subnet need to 235 employ something akin to IP host routes for the sender in order for 236 the Reverse Path Forwarding check to work. 238 8. Deployment Considerations 240 Extreme Networks has a working implementation of this model that has 241 been deployed in service provider data center environments for over a 242 year now. Other vendors are rumored to be developing similar 243 functionality. 245 9. Security Considerations 247 One obvious issue that does arise with this model is the 248 vulnerabilities created by permitting arbitrary allocation of 249 addresses across disparate broadcast domains. It is advised that 250 address space ranges be made sticky. That is, when an address or 251 range of addresses is allocated to a given sub-VLAN, reception of IP 252 or ARP packets on a sub-VLAN with a source IP address that isn't 253 allocated to the sub-VLAN should be discarded, and perhaps trigger a 254 logging message or other administrative event. 256 Implementation details are intentionally omitted as all functions in 257 this document should remain local to the super-VLAN router. As such, 258 no interoperability issues with existing protocols should result. 260 10. Acknowledgements 262 Thanks to Mike Hollyman and Erik Nordmark for their feedback. 264 11. References 266 [802.1Q] IEEE 802.1Q, "Virtual LANs". 268 12. Authors' Address 270 Danny McPherson 271 Amber Networks, Inc. 272 2465 Augustine Drive 273 Santa Clara, CA 95054 274 Phone: +1 408.486.6336 275 Email: danny@ambernetworks.com 277 Barry Dykes 278 OneSecure, Inc. 279 2000 S. Colorado Blvd Suite 2-1100 280 Denver, CO. 80222 281 Phone: +1 303-691-0104 282 Email: bdykes@onesecure.com 284 [/snip] 286 ------- End of Forwarded Message