[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                             Thorsten Kurz
                                                     Jean-Yves Le Boudec
                                                 Hans Joachim Einsiedler
                                               LRC, DI-EPFL, Switzerland
                                                              April 1997


        Realizing the Benefits of Virtual LANs by Using IPv6
             <draft-kurz-virtual-lans-benefits-00.txt>



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


0. Abstract

   The benefits that Virtual LANs offer can be realized by using
   features of an IPv6 network along with small enhancements the IPv6
   and DHCPv6 protocol stacks.


1. Introduction

   Virtual LANs are a widespread special form of LANs (Local Area
   Networks) enhanced by support for workgroups. A LAN is a collections
   of hosts which communicate directly on layer 2 without a router
   between them. All hosts on a LAN share the same layer 3 subnet
   address, which means communication between the hosts of a LAN remains
   in the LAN. Thus the layer 3 subnet address forms a broadcast scope
   which contains all hosts on the LAN.

   The performance, security and broadcast scope offered by LANs are
   used to build workgroups i.e. groups of hosts sharing the same
   servers and resources. Therefore all hosts of a workgroup are
   attached to the same LAN segment, so that broadcasting can be used
   for server detection, name resolution and name reservation like as is
   done by B-nodes in the NetBIOS Protocol [17].


Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 1]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


   In order to overcome the limits of traditional LANs, switched LANs
   appeared, which use a switch infrastructure to connect several LAN
   segments even over high speed backbones. Switched LANs continue to
   share the same layer 3 subnet address, but offer an increased
   performance compared to traditional LANs, because not all hosts of a
   switched LAN have to share the bandwidth of the same LAN segment. The
   possibility to connect the LAN segments over backbones makes it
   feasible to distribute hosts over larger areas than a single LAN
   segment could cover.

   In environments with several different workgroups, running on
   different LANs, using traditional switched LANs requires a separate
   switch infrastructure for each LAN. Virtual LANs are switched LANs
   with a software configurable switch infrastructure. This makes it
   possible to operate several different LANs over the same switch
   infrastructure and to change easily the LAN membership of single
   segments. Workgroups can then be formed and maintained by a central
   administration.

   The disadvantage of virtual LANs is however, that a special switch
   infrastructure is needed and administration includes layer 2 as well
   as layer 3. A solution which offers the same features but involves
   only layer 3 and does not require special hardware is desirable.

   We show here that with the help of features of the new Internet
   Protocol version 6 (IPv6) [1] it is possible to form a flexible
   broadcast scope based on layer 3. The features used are multicast
   addressing, mobility support and the dynamic host configuration
   protocol for IPv6 (DHCPv6). These features exist also for the current
   Internet Protocol (IPv4), but as they are all optional for IPv4,
   their availability cannot be assumed in an IPv4 network. Another
   drawback of the IPv4 multicasting is, that it can only be scaled
   using the Time To Live field, whereas in IPv6 there are different
   multicast scopes [2].

   The focus of this proposal is to realize a flexible broadcast scope.
   Security can be achieved using authentication [13] and encryption
   [14] mechanisms for the Internet Protocol (IP). Regarding the
   performance of virtual LANs, it can be expected that there will be
   routers which rival the performance of switches. Tag switching [15]
   is one possible way to implement the packet forwarding of a router in
   hardware.












Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 2]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


2. Flexible Broadcast Scope with IPv6

   IPv6 has enhanced the broadcast of IPv4 into scalable multicast [2].
   In IPv4 there is only one broadcast address for a particular scope
   and broadcasts are always received by all hosts in this scope. In
   IPv6, on the other hand, there is a special address range reserved
   for multicast addresses for each scope and a multicast is only
   received by those hosts in this scope, which are configured to listen
   to this specific multicast address. To address all hosts in a scope
   with a multicast, the multicast must be made to the predefined all
   nodes address [5], which all hosts must listen to. When existing
   software using IPv4 is migrated to IPv6 it is expected that the IPv4
   broadcasts are changed to multicasts to the all nodes address, as
   this is the simplest way to maintain the complete functionality of
   the software.

   We propose to use IPv6 multicasting to form the broadcast scope of a
   workgroup (WG). This means a workgroup is the multicast (MC) group,
   whose hosts listen all to the same multicast address, the workgroup
   address. Since a host can listen to several multicast addresses at
   the same time, a host can even be a member of several workgroups.

   While in a virtual LAN the workgroup membership of a host is
   determined by the configuration of the switches, in our proposal a
   host has to determine its workgroups and their corresponding
   addresses. The separation of different workgroups takes place on
   layer 3 since, with multicasting, each host has the possibility to
   address a specified subset of hosts of the network. Thus all hosts
   can be connected to routers directly, even members of different
   workgroups can share the same LAN segment.

   To make the administration of the workgroups easy, we propose that
   the correspondence between hosts and workgroups be stored in a
   central database and the information be distributed using the Dynamic
   Host Configuration Protocol version 6 (DHCPv6) [8].



















Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 3]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


      DHCP Server                 Host            MC Router / Group
           |                       |                      |
           |    DHCPv6 Request     |                      |
           |    DHCPv6 WG Addr Ext |                      |
           |<----------------------|                      |
           |                       |                      |
           | DHCPv6 Reply          |                      |
           | DHCPv6 WG Addr Ext    |                      |
           |---------------------->|                      |
           |                       | ICMPv6 Group         |
           |                       | Membership Report    |
           |                       |     (one for each    |
           |                       |     WG Address)      |
           |                       |--------------------->|
           |                       |--------------------->|
           |                       |--------------------->|
           |                       |                      |

         Figure 1: Configuration of Workgroup Addresses

   Figure 1 shows the proposed workgroup (WG) address configuration for
   a host. When starting up, the host must send a DHCP Request with a
   Workgroup Address Extension, as described in the following section,
   to its DHCP Server. The DHCP Server must reply with a Workgroup
   Address Extension containing all workgroup addresses assigned to this
   host. After receiving its workgroup addresses, the host has to send
   an ICMPv6 Group Membership Report [3] to each of its workgroup
   addresses to inform the multicast routers about its new membership in
   these multicast groups.

























Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 4]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


      +-------------------------+
      |   e.g. NetBIOS Stack    |
      +-------------------------+
          |
          |  MC all nodes address
          |  (Directed Group)
          V
      +-------------------------+
      |   e.g. UDP Stack        |
      +-------------------------+
          |
          |  MC all nodes address
          V
      +-------------------------+
      |   IPv6 Stack            |
      +-------------------------+
         |||
         ||| MCs to all WG Addresses
         VVV
      +-------------------------+
      |   Local Network Layer   |
      |    e.g. Ethernet        |
      +-------------------------+

         Figure 2: Translation to Workgroup Addresses

   After learning its workgroup (WG) addresses, the host also has to
   configure its interfaces to listen to these multicast (MC) addresses.
   Additionally it is required that all outgoing multicasts to the all
   nodes address, which are equivalent to broadcasts, are changed to
   multicasts to the workgroup addresses of the host. This is
   accomplished by  patching the IPv6 stack to intercept all outgoing
   multicasts to the all nodes address and to change this address to the
   workgroup addresses of the host as shown in figure 2. If the host is
   a member of several workgroups the multicast has to be sent to all
   workgroup addresses of the host.


3. DHCP Workgroup Address Extension

   The purpose of DHCP [8] is to provide hosts with addresses and other
   configuration information. DHCP delivers the configuration data in
   extensions [9] which are embedded in request, reply or reconfigure
   messages. The request message is used by the client to request
   configuration data from the server and the reply message is used by
   the server to return the requested information to the client. If
   there is a change in the DHCP database, the server uses the
   reconfigure message to notify the client about the change and to
   start a new request-reply cycle.

   We propose a DHCP Extension, shown in figure 3, in order to deliver
   to a host its workgroup addresses.


Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 5]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Ext Type    |  Ext Length   |   Reserved    |Workgroup Count|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                      Workgroup Addresses                      |
      +           (one for each Workgroup, 16 octets each)            +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Node Name (variable Length) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: DHCP Workgroup Address Extension

      Ext Type
         Identifier for the extension.

      Ext Length
         The length of the extension.

      Reserved
         Must be zero.

      Workgroup Count
         Number of workgroup multicast addresses contained in this
         extension. For each workgroup the client belongs to there is
         one multicast address.

      Workgroup Addresses
         The 16 octet multicast address of each workgroup the client is
         member of.

      Node Name
         The node name is the DNS domain name of the client which is
         used as an unique identifier to look up client specific
         information in the server databases.














Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 6]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


   The DHCP Workgroup Address Extension has to be used the following
   way:

      In a DHCP Request the client
         - must set the workgroup count to zero.
         - must not specify any workgroup addresses.
         - must specify its node name.

      In a DHCP Reply the server
         - must set the workgroup count to number of workgroup addresses
           existing for this client.
         - must include all workgroup addresses existing for this
           client.
         - must use the clients node name.

      In a DHCP Reconfigure the server
         - must set the workgroup count to zero.
         - must not specify any workgroup  addresses.
         - must use the clients node name.


4. Mobility for Multicast Group Members

   In the future we have to deal with more and more mobile hosts, some
   of which are members of workgroups. The Internet draft Mobility
   Support in IPv6 [10] proposes that a mobile host attached to a
   network segment other than its home segment keeps its home address on
   the home segment and forms a global care-of address for its new
   location. Then binding update options included in IPv6 packets are
   used to inform correspondent hosts as well as the home agent, a
   router which is on the same segment as the home address of the mobile
   host, about its new care-of address. After being informed about a new
   care-of address of the mobile host the home agent intercepts packets
   on the home segment addressed to the mobile host and tunnels [11]
   them to the care-of address of the mobile host. There is no specified
   way as to how a mobile host could send or receive multicast packets
   from its home network. We suggest the following enhancements to the
   Internet draft Mobility Support in IPv6 [10], so that mobile
   multicast group members can continue to participate in the multicast
   traffic of their group.

   If a mobile host leaves the scope of a multicast group it joined, the
   home agent must not only forward packets sent to the home address of
   the mobile host, but also all packets sent to the concerned multicast
   address.









Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 7]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


   Furthermore, the mobile host has to be able to send packets to the
   multicast address of its workgroup, even though it is outside the
   scope of this address. This can only be done by tunneling [11] the
   packets to a host inside the scope of the multicast address and
   resending them from there. Since the home agent is on the segment
   associated to the home address of the mobile host, the task of
   resending multicasts of a mobile host can also be taken over by the
   home agent.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|M|       Reserved        |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Care-of Address                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                    Home Link-Local Address                    |
      +                  (only present if L bit set)                  +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                       Multicast Address                       |
      +                  (only present if M bit set)                  +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 4: Enhanced Binding Update Option












Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 8]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


   The Internet draft Mobility Support in IPv6 [10] proposes a binding
   update option, which is used to notify the home agent and other hosts
   about a new care-of address of a mobile host. The original home
   address of the mobile host has to be specified in the source address
   field in the IP header of the packet containing the binding update
   option, but it is not allowed to specify a multicast address at this
   place. Hence there must be an optional field for a multicast address
   in the binding update option. Figure 4 shows the binding update
   option enhanced by a field for the workgroup address and an M-Bit.
   The M-bit is used to indicate that there is a multicast group address
   specified in the option.

   A mobile host, which has left the scope of one of its multicast
   groups, sends a binding update option to its home agent in order to
   inform it about a new care-of address and has to specify its
   multicast group address in the binding update option and set the
   M-bit in this option. In case the mobile host is a member of several
   multicast groups, it has to send a binding update option for each of
   its multicast groups.

      +------------------+
      | Src: Home Agent  |  \
      |      Address     |  |
      +------------------+   > Encapsulation done
      | Dst: Mobile Host |  |  by Home Agent
      |      Address     |  /
      +------------------+
      | Src: Host        |  \
      |      Address     |  |
      +------------------+  |
      | Dst: Multicast   |   > Multicastpacket from the home segment
      |      Site-local  |  |  of the Mobile Host
      +------------------+  |
      |      Original    |  |
      |      Data Packet |  /
      +------------------+

         Figure 5: Multicast send to Mobile Host

   A home agent notified by a binding update option about a multicast
   address for a mobile host must join this multicast group, if it has
   not already done so, and handle packets with this multicast address
   in the destination address field in the same way as packets with the
   home address of the mobile node in this field (Figure 5). See section
   7.3 of Mobility Support in IPv6 [10] for further details.

   The mobile host must treat a received  encapsulated multicast packet
   the same way as if it received the decapsulated packet directly. It
   must not send a binding update option to the address specified in the
   source address field of an encapsulated multicast packet.




Kurz, Le Boudec, Einsiedler        Expires October 1997         [Page 9]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


      +----------------------+
      | Src: Mobile Host     |  \
      |      Care-of Address |  |
      +----------------------+   > Encapsulation done
      | Dst: Home Agent      |  |  by Mobile Host
      |      Address         |  /
      +----------------------+
      | Src: Mobile Host     |  \
      |      Home Address    |  |
      +----------------------+  |
      | Dst: Multicast       |   > Multicast Packet
      |      Site-local      |  |  of the Mobile Host
      +----------------------+  |
      |      Original        |  |
      |      Data Packet     |  /
      +----------------------+

         Figure 6: Mobile Host sending Multicast

   When sending a multicast packet to its multicast group, the mobile
   host has to use its home address in the source address field of the
   multicast packet and tunnel this packet to its home agent (Figure 6).

   When a home agent receives an encapsulated multicast packet in which
   the source address field is the same as the home address of a mobile
   host served by it, then the home agent has to act like a router,
   receiving this multicast packet from the home segment of the mobile
   host and additionally forwarding it to the home segment of the mobile
   host.

   This way of providing mobile workgroup members with the possibility
   to leave the scope of the multicast address has the drawback that it
   might not scale very well in the case of broadcast intensive
   workgroup protocol stacks, since all the broadcasting traffic, which
   was intended to remain in a limited area, has to be forwarded to the
   mobile node. Assuming that a lot of workgroup members use the
   possibility of global mobility, there is a risk of overloading the
   Internet with workgroup broadcasting traffic.


5. Conclusion

   Under the described conditions equivalent features of a Virtual LAN
   can be realized by using IPv6. Today the latency and the throughput
   of routers are still a deterrent to a solution based on layer 3
   routing, but tag switching [15] for example can increase the
   performance of routers considerably. The IPv6 flowlabel field can be
   used to place the tag information [16].

   Nevertheless, the use of authentication and encryption mechanisms in
   the end nodes raises the latency and possibly also impacts the
   throughput of the end nodes.


Kurz, Le Boudec, Einsiedler        Expires October 1997        [Page 10]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


   Considering the usage of Virtual LANs and IPv6, VLANs enhance the
   flexibility of currently available software without requiring any
   changes of the software. Software, which is being adapted to the new
   IPv6 address space in the future, can be changed to use the all nodes
   multicast address instead of IPv4 broadcast. Using IPv6 no special
   VLAN protocols and hardware is required and only small enhancements
   in the IPv6 protocol stack must be done. IPv6 can offer a viable
   software alternative to Virtual LANs as soon as faster solutions for
   routing are available.


6. Abbreviations

   DHCP     Dynamic Host Configuration Protocol.
   ICMPv6   Internet Control Message Protocol for IPv6.
   IGMP     Internet Group Management Protocol.
   IPv4     Internet Protocol version 4.
   IPv6     Internet Protocol version 6.
   LAN      Local Area Network.
   MC       MultiCast
   WG       WorkGroup

































Kurz, Le Boudec, Einsiedler        Expires October 1997        [Page 11]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


7. References

    [1] S. Deering, R. Hinden, Internet Protocol Version 6, RFC 1883,
        December 1995.

    [2] R. Hinden, S. Deering, IP Version 6 Addressing Architecture,
        RFC 1884, December 1995.

    [3] A. Conta, S. Deering, Internet Control Message Protocol
        version 6, RFC 1885, December 1995.

    [4] S. Deering, Host Extensions for IP Multicasting, RFC 1112,
        August 1989.

    [5] R. Hinden, IPv6 Multicast Address Assignments,
        draft-ietf-ipngwg-multicast-assgn-01.txt, November 1996.

    [6] T. Narten, E. Nordmark, Neighbor Discovery for IPv6, RFC 1970,
        August 1996.

    [7] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration,
        RFC 1971, August 1996.

    [8] J. Bound, C. Perkins, Dynamic Host Configuration Protocol
        for IPv6, draft-ietf-dhc-dhcpv6-08.txt, November 1996.

    [9] C. Perkins, Extensions for DHCPv6, draft-ietf-dhc-v6exts-04.txt,
        November 1996.

   [10] C. Perkins, D. Johnson, Mobility Support in IPv6,
        draft-ietf-mobileip-ipv6-02.txt, November 1996.

   [11] A. Conta, S. Deering, Generic Packet Tunneling in IPv6,
        draft-ietf-ipngwg-ipv6-tunnel-05.txt, November 1996.

   [12] R. Atkinson, Security Architecture for the Internet Protocol,
        RFC 1825, August 1995.

   [13] R. Atkinson, IP Authentication Header, RFC 1826, August 1995.

   [14] R. Atkinson, IP Encapsulation Security Payload, RFC 1827,
        August 1995.

   [15] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow,
        Tag Switching Architecture Overview,
        draft-rfced-info-rekhter-00.txt, September 1996.

   [16] F. Baker, Y. Rekhter, Use of Flow Label for Tag Switching,
        draft-baker-flow-label-00.txt, October 1996.

   [17] IBM PC Network Technical Reference, Document Number 6322916,
        September 1984.


Kurz, Le Boudec, Einsiedler        Expires October 1997        [Page 12]


INTERNET-DRAFT     Benefits of Virtual LANs by Using IPv6     April 1997


8. Authors' Address

   Thorsten Kurz,
   Jean-Yves Le Boudec,
   Hans Joachim Einsiedler

   Laboratoire de Reseaux de Communication
   Swiss Federal Institute of Technology (EPFL)
   1015 Lausanne
   Switzerland

   email: {tkurz, leboudec, einsiedl}@lrc.epfl.ch










































Kurz, Le Boudec, Einsiedler        Expires October 1997        [Page 13]