As per Relevance of the word broadcast, we have this rfc below:
Network Working Group D.
Request for Comments: 3069 Amber Networks, Inc
Category: Informational B.
Onesecure, Inc
February 2001
VLAN Aggregation for Efficient IP Address
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document introduces the concept of Virtual Local Area
(VLAN) aggregation as it relates to IPv4 address allocation.
mechanism is described by which hosts that reside in the
physical switched infrastructure, but separate virtual
domains, are addressed from the same IPv4 subnet and share a
default gateway IP address, thereby removing the requirement of
dedicated IP subnet for each virtual Local Area Network (LAN)
Metropolitan Area Network (MAN).
Employing such a mechanism significantly decreases IPv4
consumption in virtual LANs and MANs. It may also
administration of IPv4 addresses within the network
1.
The VLAN [802.1Q] aggregation technique described in this
provides a mechanism by which hosts that reside within the
physical switched infrastructure, but separate virtual
domains, may be addressed from the same IPv4 subnet and may share
common default gateway IPv4 address
Such a mechanism provides several advantages over traditional IPv
addressing architectures employed in large switched LANs today.
primary advantage, that of IPv4 address space conservation, can
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
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,
well as on projections of future utilization. For example, a
such as that illustrated in Table 1 may be used
Table 1:
Gateway Usable
Customer IP Subnet Address 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
project growth of up to 10 hosts. As a result, they're allocated
IP subnet 1.1.1.0/28 which provides 16 IP addresses. The first
address, 1.1.1.0, represents the subnetwork number. The last
address, 1.1.1.15, represents the directed broadcast address.
first usable address of the subnet, 1.1.1.1, is assigned to
router and serves as the default gateway IP address for the subnet
The customer is left 13 IP addresses, even though their
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
project growth of up to 5 hosts. As a result, they're allocated
IP subnet 1.1.1.16/29 which provides 8 IP addresses. The first
address, 1.1.1.16, represents the subnetwork number. The last
address, 1.1.1.23, represents the directed broadcast address.
first usable address of the subnet, 1.1.1.17, is assigned to
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
plans of deploying additional hosts. As a result, they're
the IP subnet 1.1.1.24/30 which provides 4 IP addresses. The
IP address, 1.1.1.24, represents the subnetwork number. The last
address, 1.1.1.27, represents the directed broadcast address.
first usable address of the subnet, 1.1.1.25, is assigned to
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.
most optimal address allocation scheme here requires 28 IP addresses
Now, if customer A only grows to use 3 of his available address,
additional IP addresses can't be used for other customers
Also, assume customer C determines the need to deploy one
host, and as such, requires one additional IP address. Because
of the addresses within the existing IP subnet 1.1.1.24/30 are used
and the following address space has been allocated to
customers, a new subnet is required. Ideally, the customer would
allocated a /29 and renumber host C.1 into the new subnet. However
the customer is of the opinion that renumbering is not a
option. As such, another IP subnet is allocated to the customer
this time perhaps a /29, providing two additional addresses
future use
As you can see, the number of IP addresses consumed by the
number, directed broadcast address, and a unique gateway address
each subnet is quite significant. Also, the inherent constraints
the addressing architecture significantly reduce flexibility
2.
If within the switched environment, on the routed side of
network, we introduce the notion of sub-VLANs and super-VLANs, a
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)
within a separate broadcast domain. One or more sub-VLANs belong
a super-VLAN, and utilize the default gateway IP address of
super-VLAN. Hosts within the sub-VLANs are numbered out of
subnets associated with the super-VLAN, and their IP subnet
information reflects that of the super-VLAN subnet
If desired, the super-VLAN router performs functions similar to
ARP to enable communication between hosts that are members
different sub-VLANs
This model results in a much more efficient address
architecture. It also provides network operators with a mechanism
provide standard default gateway address assignments
Let's again consider Figure 1, now utilizing the super-VLAN sub-
model. Table 2 provides the new addressing model
Table 2:
Gateway Usable
Customer IP Subnet Address 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
project growth of up to 10 hosts. As a result, they're allocated
IP address range 1.1.1.2 - 1.1.1.11. The gateway address for
customer is 1.1.1.1, the subnet is 1.1.1.0/24.
Customer B's initial deployment consists of 2 hosts, though
project growth of up to 5 hosts. As a result, they're allocated
IP address range 1.1.1.12 - 1.1.1.16. The gateway address for
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
plans of deploying additional hosts. As a result, they're
the IP address 1.1.1.17. The gateway address for the customer
1.1.1.1, the subnet is 1.1.1.0/24.
The sum of address requirements for all three customers is 16. As
result, only 16 addresses are allocated within the subnet. These 16
addresses, combined with the global default gateway address
1.1.1.1, as well as the subnetwork number of 1.1.1.0 and
broadcast of 1.1.1.255, result in a total of 19 addresses used.
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
host, and as such, requires one additional IP address. The
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
large LANs or MANs
3. Use of Directed
This specification provides no support for directed broadcasts
Specifically, the directed broadcast address
only apply to one of the Layer 2 broadcast domains
Though use of directed broadcast is frowned upon in the
today, there remain a number of applications, primarily in
enterprise arena, that continue to use them. As such, care should
taken to understand the implications of using these applications
conjunction with the addressing model outlined in this specification
4. Multicast
It is assumed that the Layer 2 multicast domain will be the same
the Layer 2 broadcast domain (i.e., VLAN). As such, this means
for an IP multicast packet to reach all potential receivers in the
subnet the multicast router(s) attached to the IP subnet need
employ something akin to IP host routes for the sender in order
the Reverse Path Forwarding check to work
5. Deployment
Extreme Networks has a working implementation of this model that
been deployed in service provider data center environments for over
year now. Other vendors are rumored to be developing
functionality
6. Security
One obvious issue that does arise with this model is
vulnerabilities created by permitting arbitrary allocation
addresses across disparate broadcast domains. It is advised
address space ranges be made sticky. That is, when an address
range of addresses is allocated to a given sub-VLAN, reception of
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'
allocated to the sub-VLAN should be discarded, and perhaps trigger
logging message or other administrative event
Implementation details are intentionally omitted as all functions
this document should remain local to the super-VLAN router. As such
no interoperability issues with existing protocols should result
7.
Thanks to Mike Hollyman and Erik Nordmark for their feedback
8.
[802.1Q] IEEE 802.1Q, "Virtual LANs".
9. Authors'
Danny
Amber Networks, Inc
48664 Milmont
Fremont, CA 94538
EMail: danny@ambernetworks.
Barry
OneSecure, Inc
2000 S. Colorado Blvd Suite 2-1100
Denver, CO. 80222
EMail: bdykes@onesecure.
McPherson & Dykes Informational [Page 6]
RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
10. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
McPherson & Dykes Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
