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 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]