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: [email protected]


  Barry Dykes
  OneSecure, Inc.
  2000 S. Colorado Blvd Suite 2-1100
  Denver, CO.  80222

  EMail:  [email protected]



















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]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.