Network Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-vpl-ip-00.txt February 2001 Category: Informational Port based Virtual Private LAN services for IP only data networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document presents a port based Virtual Private LAN services solution for IP only data networks. Address Resolution Protocol (ARP) is extended to discover the hardware addresses of the remote devices. The service provider edge (PE) devices perform packet forwarding using the Layer 2 addresses of the end stations. Senevirathne Informational- August 2001 1 draft-tsenevir-vpl-ip-00.txt February 2001 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Content Conventions used in this document.....................................2 Table of Content......................................................2 1.0 Introduction......................................................2 2.0 Interaction of Customer and Provider equipment....................3 3.0 Proxy ARP functionality...........................................5 4.0 Discovery ARP.....................................................5 4.0.1 IP Header Encapsulation.........................................8 4.0.2 Discovery ARP in MPLS based core................................9 5.0 Payload Encapsulation in MPLS core................................9 6.0 Issues...........................................................10 6.0.1 Address aging..................................................10 7.0 Security Considerations..........................................10 9.0 References.......................................................11 11.0 Author's Addresses..............................................11 Appendix A:..........................................................11 Full Copyright Statement.............................................15 1.0 Introduction Metropolitan Internetworks are emerging as a new class of public networks that provide Virtual Internetwork services to the customers. Traditional public networks were based on Wide area networking infrastructure such as Frame relay. However, with the recent advancement in the optical networking technology, there is an enormous bandwidth available in the Metropolitan Networks. On the other hand 10Gigabit Ethernet infrastructure is being deployed. 10- Gigabit infrastructure or optical Ethernet solutions, as it is commonly known provide a more flexible and manageable infrastructure than traditional Frame relay like networks. In the same time customers are exploring the possibility of virtual extension to their Local network with complete transparency to the end devices. In theory, when subscribing to such service, customers expect the devices on the other side of the MAN network to appear as they are attached to the Local Network. There are several solutions proposed to address this requirement to provide virtual LAN services across the Internetwork. Most of the solutions provided try to extend the Layer 2 networks across the Internetwork and attempt to preserve Layer 2 addresses (MAC DA and SA) when transporting such packets across the public network. Transporting the entire layer 2 payload is only required if the customers require to transport several different non-routable protocols that require bridging functionality. However, most Senevirathne Informational - August 2001 2 draft-tsenevir-vpl-ip-00.txt February 2001 networks today carry IP traffic and has become the de-facto protocol. The service provider infrastructure become significantly simpler, if the service required by the customer is Virtual LAN service for IP only payloads. In this document we propose a method to provide Virtual LAN services to customers who requires services for IP only payloads. In RFC 2547 [3], the service provider devices are required to maintain the routing tables of the customers. Each of the customers who subscribe to Virtual LAN services may use large routing tables, thus leading to serious scaling issues. Virtual LAN service offered by Metropolitan Internetwork service providers emulates a behavior of a Local Network. The customers require minimum configurations. The devices in the Local Are Network (LAN) discover other participating devices using Address Resolution Protocol (ARP). The packet forwarding takes place using the MAC addresses rather than IP address. In practice, there are relatively a lower number of devices in a LAN. Hence the number of MAC addresses the provider devices require to maintain is significantly lower than the Full routing tables the devices require to maintain when provisioning Virtual LAN services using 2547. In this document we propose to extend the mechanics of IP forwarding in a Local Subnetwork. As mentioned earlier, once the public Internetwork is treated as a LAN, the customer edge devices discover other participating devices using ARP. The forwarding in the core takes placed using MAC addresses. Providing pure layer 2 forwarding in the Internetwork give rise to serious scaling issues. Hence in this document we propose a forwarding method that combines Layer 2 MAC addresses and MPLS. The proposed method does not require the provider devices in the core of the network to learn MAC addresses. Only the Provider edge device maintain MAC addresses of the customer devices. Thereby providing a scalable transport mechanism. 2.0 Interaction of Customer and Provider equipment In this section we present, briefly, interaction of customer and provider equipment, in the context of providing virtual network services for IP only payloads. | % Proxy ARP <- | -> Discovery ------- |----a' | ARP | PE | o Proxy ARP % -----| B |--o-o--|----b' <- | / | | ARPo a-----| ------ / ------ <-|----c' o | PE | / | CE B b-----|-o-o-| A |--------- % o | | \ Senevirathne Informational - August 2001 3 draft-tsenevir-vpl-ip-00.txt February 2001 b-----| ARP ------ \ % -> | \ ------- |----x CE A % Discovery -----| PE | o | ARP | C |-o-o-- |----y -> | | ARP o ------- <- | ---z | -> CE C <- % Proxy ARP Discovery | ARP CE - Customer Edge (Represent one more Devices in a LAN) PE - Provider Edge -o- Physical Connection --- Logical Connection -%- Partition of Functionality Fig: Taxonomy of Virtual Network that provides virtual LAN services for IP only payloads. The above diagram depicts placement of various building blocks and interaction between the blocks. CE A requires connectivity to CE B and CE C. "a", "b" and "c" are end stations attached to the Local network at CE A. The devices at CE A are required to connected to devices in CE B, C and vise versa. The PE devices may not provide routing functionality based on the private address space of the customer. The end stations a-b, a'-b' and x-z are in the same local sub network. Hence, a-b, a'-b' and x-z use Address Resolution Protocol (ARP) [4] to discover the hardware addresses of the devices they wish to communicate. PE devices has virtual connectivity to the sites A,B and C. There is no common broadcast medium that could propagate the incoming ARP request to other devices. On the other hand customers address space is opaque to the provider and provider is required to provide complete isolation of a given customers address space from the providers and other customers address spaces. Hence, PE devices are required to perform proxy ARP functionality. The operation of the proxy ARP functionality at PE is similar to RFC 925[5] and explained in detail later in this document. As part of the proxy ARP functionality, PE device generates a Discovery ARP to all other PE devices that provide Virtual LAN services. The discovery ARP may be generated with multiple methods. RFC 2625 [6] provide one such method. One may choose variety of methods to discover MAC addresses of the remote devices. This may be either via static configuration or dynamic discovery. Any dynamic discovery must consider the requirement of overlapping address spaces of different customers and Senevirathne Informational - August 2001 4 draft-tsenevir-vpl-ip-00.txt February 2001 traffic isolation between different customer domains and other security requirements related to Virtual network services, [7] species some of such requirements. The section 4.0.2 below presents discovery ARP method when the provider infrastructure is based on MPLS. The receiving, device in response to a Discovery ARP request, generate a proxy ARP request (if the requested address is not already present in the database). Based on the proxy ARP response, appropriate Discovery ARP response is generated. The discovery ARP response must contain sufficient information to identify the response generator in addition to the end station MAC address. Identification of the remote PE is facilitates proper forwarding of traffic. Originating PE now generates a Proxy ARP response, with the MAC address of the remote device (not the local PE MAC address). The PE device add the remote MAC address in to the Forwarding Information Base (FIB) with the destination as the virtual port that the remote PE for this customer can be reached. The main advantage with the proposed method is that the service provider edge devices (PE) are not required to maintain the Internet routing tables, as required in [3]. However, they are required to maintain the MAC addresses of the devices in the virtual domain. In theory, a given Local Network has a limited set of end stations. Hence a limited set of MAC addresses. The amount of MAC addresses in the local network, in general, is proportionately less than the Internet routing tables. Hence providing a better scalability. On the other hand, with the solution presented in this document the providers may not required to implement complicated routing protocols to carry customer reachability information. Hence providing an easily manageable network. 3.0 Proxy ARP functionality The proxy ARP functionality presented in this document is different to RFC 925 [5] in two fronts, firstly [5] serves only the directly attached sub networks. Secondly [5] generates proxy ARP response with PE devices local interface MAC address. In the solution proposed in this document, the sub networks may not be directly attached, it may well be across another "ARP-bridge". On the other hand, the solution proposed in this paper suggest to generate Proxy ARP response with the MAC address of the remote device rather than the MAC address of the local interface. RFC 925 [5] serves as a good reference for the implementers of the solution proposed in this document. Here we present the required Virtual LAN services Proxy ARP functionality. The pseudo code presented below in Appendix A together with the RFC 925[5] defines the complete behavior of proposed Proxy ARP functionality. 4.0 Discovery ARP Senevirathne Informational - August 2001 5 draft-tsenevir-vpl-ip-00.txt February 2001 Discovery ARP facilitates "ARP-bridges" to extend the proxy ARP functionality beyond the locally attached interfaces. The transport of the Discovery ARP over the public network depends on the transport method used in the public network. Present day networks use IP in most of the public Internetworks. In this section we present encoding of the discovery ARP in IP payload. Section 4.0.1 present method of extending the discovery ARP presented in this section to MPLS based infrastructure. The discovery ARP is proposed as an extension to the NARP presented in RFC 1735 [6]. The NARP presented in RFC 1735, interacts with a central authority to resolve the incoming ARP request. In the discovery ARP presented in this document, we propose each PE device to perform the ARP resolution functionality by working as an ARP gateway between discovery ARP and Proxy ARP. We propose to define two new NARP types, DARP_REQUEST and DARP_RESPONSE. The remainder of the NARP payload is different for Discovery ARP and must be according to the format specified in this document. Type Value ---- ------ DARP_REQUEST 0x03 DARP_RESPONSE 0x04 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Hop Count | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subTypeVDI | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subTypeIPSrc| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Variable Length IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |subTypeIPDest| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Variable Length IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |subTypeSrcHwA| Length | HwType | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length HW Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |subTypeDesHwA| Length | HwType | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length HW Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational - August 2001 6 draft-tsenevir-vpl-ip-00.txt February 2001 |subTypeVSrc | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Tag Identity (Source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |subTypeVdest | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Tag Identity (Destination) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The NARP version number as specfied in RFC 1735 Hop Count Unused for the application specfied here Checksum As specified in RFC 1735. Type DARP_REQUEST is 3 and DARP_RESPONSE is 4. Code Unused in discovery ARP. SubType Sub Type defines information needed to fully resolve a discover ARP request or response Type Value ------- ---------- TYPE_VDI 0x01 TYPE_IP_SRC 0x02 TYPE_IP_DEST 0x03 TYPE_HW_SRC_ADD 0x04 TYPE_HW_DEST_ADD 0x05 TYPE_SRC_V_TAG 0x06 TYPE_DEST_V_TAG 0x07 TYPE_VDI Represent the virtual Domain where this Discover ARP applies TYPE_IP_SRC Represent the Source IP address of the end station that generated the request. Senevirathne Informational - August 2001 7 draft-tsenevir-vpl-ip-00.txt February 2001 TYPE_IP_DEST Represent the Destination IP address of the end station that ARP is requested TYPE_HW_SRC_ADD Represent the HW address of the end station that generated the request. TYPE_HW_DEST_ADD Represent the HW address of the end station that ARP is requested. In Discover ARP request, this field contain all zero. In the response this field contain a valid Hardware address. TYPE_SRC_V_TAG Carries a transport layer specific information that is needed identify the appropriate MAC layer source information. As an example, if MPLS is used as the transport protocol, this represents the last label that would be popped at the egress LSR. The last label facilitates the LSR to retrieve the proper destination MAC address, when the traffic is flowing back to this source. TYPE_DEST_V_TAG Carries a transport layer specific information that is needed to identify the appropriate MAC layer destination information. As an example, if MPLS is used as the transport protocol, this represents the last label that would be popped at the egress LSR. The last label facilitates the LSR to retrieve the proper destination MAC address. This field contain all zeros in Discover ARP request and a valid tag in the response Virtual Tag Identity This represents a tunneling protocol specific identifier. As an example, when MPLS is used as the tunneling protocol in the core, Virtual Tag Identity represents a Label. 4.0.1 IP Header Encapsulation The Discovery ARP (DARP) payload may be encapsulated in a regular IP header. In RFC 1735[6], NARP packets are forwarded to known unicast addresses. In the discovery ARP, Discovery ARP packets are tunneled to the remote PE devices. Hence, the destination IP address must be the remote PE device. However, if there are large number of remote PE devices, PE device may be required to replicate the ARP request with different PE destination IP addresses. This may lead to a Senevirathne Informational - August 2001 8 draft-tsenevir-vpl-ip-00.txt February 2001 scaling issue in large service providers. Hence we suggest encoding the destination address with either a broadcast or local multicast address. Since discovery ARP are tunneled to the remote PE device, use of such multicast or broadcast address does not restrict the Discovery ARP to the directly attached interfaces of the local PE device. 4.0.2 Discovery ARP in MPLS based core When MPLS is used as the transport method of the public Internetwork, the Discovery ARP payload in above 4.0 can be tunneled to the remote PE devices using the same LSP that are used to carry the customer data traffic. However discovery ARP packets must not be forwarded. In order to facilitate this behavior, we suggest using an extra pre-known label as the last label in the LSP. This label may be either statically configured, or allocated during LSP setup time or one of the well known, reserved label in the range 4-15. The action performed on the last label is similar to route alert label, where packet is copied to the processor. However, route alert label is an illegal label when inserted as the last label. To circumvent this we propose to use a label derived by some other method as described above. 5.0 Payload Encapsulation in MPLS core ------ ------ ------ ------- | |a a'| | | |b' b| | | CE A|-o-o-o-o-| PE A |-------------| PE B |-o-o-| CE B | | | | | | | | | ------ ------ ------ ------- 1 2 3 CE - Customer Edge Device PE - Provider Edge Device a,a',b,b' - represent MAC addresses of Local interface -o- Physical Connectivity --- Virtual Connectivity Let assume that Proxy ARP and Discovery ARP has resolved the address binding. Let assume label Lb at PE represent the Flow to CE B for MAC b. Let assume La at PE A reperesent Flow to CE A with MAC address a. Let assume Label Lb' at PEA represent LSP to PE B. Below we depict the encaspulation format of the Layer 2 packet, carrying IP, as it travers along 1,2 and 2. Encapsulation at Link 1 Senevirathne Informational - August 2001 9 draft-tsenevir-vpl-ip-00.txt February 2001 --------------------------------------------------- | DA=b |SA=a|0800| IP Payload |crc | | | | | | | ---------------------------------------------------- Transformation at PE A DA(b)->LSP(a-b) LSP(a-b)->Label(Lb'..Lb) Encapsulation at Link 2 --------------------------------------------------- | Lb'..Lb| IP Payload | | | | -------------------------------------------------- Encapsulation at Link 3 Transformation at PE B Label(Lb)-> DA(b), Port --------------------------------------------------- | DA=b |SA=b'|0800| IP Payload |crc | | | | | | | ---------------------------------------------------- Note: SA is now b' not a 6.0 Issues 6.0.1 Address aging The proposed solution provides a sub-IP like service. Most layer 2 entries are aged out based on activity. Over period of time, PE devices may age out proxy ARP entries. However, the end station may not have age out the corresponding ARP entries and may forward a packet with a Destination MAC address that is not in the local FIB. There may be transit traffic via the Virtual network, such traffic contain destination IP addresses that are outside the Sub network of the virtual LAN. Hence, the PE device may not be able to extract the IP Address from the packet and generate an ARP request. In order to accommodate this, PE device may use some sort of an Inverse ARP method to discover the edge PE device that service the unknown MAC address. 7.0 Security Considerations PE devices are required to provide sufficient protection against malicious attackers who may use Proxy ARP functionality to gain access to network or generate denial of service attack. Senevirathne Informational - August 2001 10 draft-tsenevir-vpl-ip-00.txt February 2001 9.0 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Rosen, E., and Rektar, Y., BGP/MPLS VPN, RFC 2547, March 1999. 4 Plummer, D., An Ethernet Address Resolution Protocol, RFC 826, November 1982. 5 Postel, J., Multi-LAN Address Resolution, RFC 925, October 925 6 Heinanen, J., and Govindan, R., NBMA Address Resolution Protocol (NARP), RFC 1735, December 1994. 7 Senevirathne, T, and et.al., A Framework for Virtual Metropolitan Internetwork (VMI), Work In Progress, February 2001. 11.0 Author's Addresses Tissa Senevirathne 3770 Flora Vista Ave, Apt 1102 Santa Clara, CA 95051 Phone: 408-244-7719 Email: tsenevir@hotmail.com Appendix A: Here we present the psuedo code interaction for ProxyARP and Discovery ARP. function processProxyArpRequest(request) if(request.port.type != PORT_TYPE_VLS) processNormalArp(request) return end if( !isRequestSameSubnet(request.ip.address, request.port.id)) return end if ((fib = getVLSFibForPort(request.port.id)) == NULL) return; end Senevirathne Informational - August 2001 11 draft-tsenevir-vpl-ip-00.txt February 2001 /* * we have a valid VLS port with VALID FIB and * the incoming ARP is for the Virtual subnet */ if (( arpCacheEntry = getFIBMatch(fib, request.ip.addr)) == NULL) addFibPendingEntry(fib, request, arpHnadle); SendDiscoveryArp(fib.domainID, request, arpHandle); else if (arpCacheEntry.state != ARP_READY) ; /* pending arp */ else /* * we have an entry in the ARP cache */ proxyArpSendReply(request, arpCacheEntry) /* * add the source address in to our local * cache so we could reply to discovery arps */ addFIBEntry(fib, request) end /* * other routines, such as stats etc */ return; end function function processDiscoveryArpRequest(request) if(request.port.type != PORT_TYPE_VIRTUAL_EXTENDED) processNormalArp(request) return end if( !isRequestSameSubnet(request.ip.address, request.port.id)) return end if ((fib = getVLSFibForPort(request.port.id)) == NULL) return; end /* * we have a valid virtual port with VALID FIB and * the incoming discovery ARP is for the Virtual subnet */ if (( arpCacheEntry = getFIBMatch(fib, request.ip.addr)) == NULL) Senevirathne Informational - August 2001 12 draft-tsenevir-vpl-ip-00.txt February 2001 addFibPendingEntry(fib, request, arpHnadle); SendProxyArpRequest(fib.VlsPortList, request, arpHandle); else if (arpCacheEntry.state != ARP_READY) ; /* pending arp */ else /* * we have an entry in the ARP cache */ DiscoveryArpSendReply(request, arpCacheEntry) /* * add the source address in to our local * cache so we could reply to ARP */ addFIBEntry(fib, request, arpHandle) end /* * other routines, such as stats etc */ return; end function function processDiscoveryArpResponse(response) if(request.port.type != PORT_TYPE_VIRTUAL_EXTENDED) if(request.port.type == PORT_TYPE_VLS) processProxyArpResponse(response) else processNormalArp(request) return end if( !isRequestSameSubnet(response.ip.address, request.port.id)) return end if ((fib = getVLSFibForPort(request.port.id)) == NULL) return; end /* * we have a valid virtual port with VALID FIB and * the incoming discovery ARP is for the Virtual subnet */ if (( arpCacheEntry = getFIBMatch(fib, request.ip.addr)) == NULL) /* * we may have aged out the pending ARP * add in to the fib in case we get a request */ Senevirathne Informational - August 2001 13 draft-tsenevir-vpl-ip-00.txt February 2001 addFIBEntry(fib, response, arpHandle) else if (arpCacheEntry.state != ARP_READY) addFIBEntry(fib, response, arpHandle) /* pending arp */ /* * ARP handle contain information needed * weher to send the response such as physical port */ SendProxyArpResponse(response, arpHandle); else /* * we have an entry in the ARP cache */ do nothing end /* * other routines, such as stats etc */ return; end function Senevirathne Informational - August 2001 14 draft-tsenevir-vpl-ip-00.txt February 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 Senevirathne Informational - August 2001 15