File: rfc3069.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (395 lines) | stat: -rw-r--r-- 14,891 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
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]