Himanshu Shah
                                                            Prabhu Kavi
   PPVPN Working Group                                   Tenor Networks
   Internet Draft
   draft-shah-ppvpn-arp-mediation-00.txt                     Eric Rosen
                                                          Cisco Systems
   February 2002
   Expires: August 2002                               Waldemar Augustyn

                                                            Giles Heron

                                                        Sunil Khandekar
                                                          Vach Kompella
                                                       TiMetra Networks

                                                         Vijay Aggarwal
                                                        Gotham Networks

                                                         Jeremy Brayley
                                                         Rafael Francis
                                                        Laurel Networks

                                                      Arun Vishwanathan
                                                       Force10 Networks

                                                      Ashwin Moranganti
                                                  Appian Communications

             ARP Mediation for IP interworking of Layer 2 VPN

1.0 Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   Shah, et al.          Expires August 2002                        1

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   The list of Internet-Draft Shadow Directories can be accessed at

2.0 Abstract

   This draft addresses an issue in a particular kind of Layer 2 VPN,
   which provides point-to-point connectivity for IP traffic only.  In
   this kind of VPN it is possible to form heterogeneous point-to-point
   links, where the two ends of the link use different technologies,
   e.g., one end is Ethernet and the other is Frame Relay or ATM.  If
   two IP systems are connected via a heterogeneous point-to-point link,
   each may be using different address learning techniques, e.g., one is
   using ARP and the other Inverse ARP. It is up to the Provider Edge
   routers to make these different techniques interwork.  This draft
   specifies the procedures, which the Provider Edge routers should
   perform in order to allow correct operation across heterogeneous
   point-to-point links.

2.1 ID Summary


   This ID describes a mechanism by which PE devices learn the IP
   address of each locally attached CE device and distributes these to
   other PEs in order to mediate between the address resolution
   mechanisms used by the CE devices. The ID also points out
   difficulties, and in some cases, the inoperability of IGPs on the CE
   devices when interconnected by PE devices using IP L2 interworking
   VPN solution.



   Belongs in PPVPN


   This document describes a mechanism to assist in Provider-
   Provisioned Layer 2 VPNs.


   The IP L2 interworking VPN solution described in [L2VPN-Kompella]
   introduces the concept of Layer 2 IP interworking between disparate
   Layer 2 media (e.g. Ethernet and Frame Relay).  However, it does not

   Shah, et al.          Expires August 2002                        2

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   address how address resolution protocols should be handled between
   these disparate media types.  This document describes how the PEs
   should mediate between the different address resolution protocols
   that each CE device uses. Also, there are issues when IGP on a
   point-to-point link CE is interconnected with IGP on a multi-
   access/broadcast link CE. This document outlines these issues.

3.0 Overview

   A heterogeneous circuit is defined as a virtual circuit between two
   CE devices that consists of two disparate attachment VCs as the
   endpoints of an Emulated VC. For example, a CE device on Ethernet is
   attached to an emulated VC whose other end point is a CE device on
   frame relay. The attachment VC in this example could then be a VLAN
   tag on Ethernet interface emulated to the attachment VC of a frame
   relay DLCI on the other end. While such heterogeneous circuits do
   not work in general, they can be made to work on the assumption that
   all their traffic is IP traffic and the Emulated VC performs inter-
   working function for the IP data frames.

   The [L2VPN-Kompella] ID describes methodologies that allow
   heterogeneous layer 2 circuits to be mapped through MPLS tunnels to
   remote sites that belong to the same VPN. In this "IP L2
   interworking" scheme the inter-working functions consist of
   stripping layer 2 header (e.g. Ethernet MAC header) of the data
   packet at ingress, dispatching the raw IP packets to the egress, and
   prepending the appropriate Layer 2 header (e.g. RFC 2427 header for
   frame relay) before sending it to the attached CE device.

   The problem in such IP L2 Interworking scheme is that, for example,
   if a CE1 is an Ethernet-attached router, it expects to learn the IP
   address of its neighbor from a multicast routing control packet, and
   then expects to do ARP to learn the MAC address.  However, if CE2 is
   attached via frame relay, it expects to use Inverse ARP to learn the
   IP address of its neighbor, and it does not send, nor may it respond
   to ARP messages over the frame relay interface. For CE1 and CE2 to
   inter-work correctly, PE1 and PE2 will need to mediate the address
   learning and resolution process.

   One option would be to require each CE to have a static
   configuration of the IP addresses of all remote CEs.  However, this
   is unwieldy and should be avoided whenever possible.  A better
   approach would be to have the service provider network automatically
   mediate between the various ARP messages.  In this document, we
   propose that the PE devices capture the address resolution protocol
   messages sent by the CE, and use this information to perform a
   mediation function between different ARP message formats.  The
   methods of performing this mediation function are described in this
   document.  In some cases, this mediation may not be possible, and
   these situations are also detailed in this document.

   Note that the PEs are capturing the CEÆs IP addresses information
   solely for the purpose of mediating between different ARP formats.

   Shah, et al.          Expires August 2002                        3

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   The end-to-end service remains a point-to-point layer 2 service
   where forwarding decisions are solely based upon the circuit
   identifier (e.g. DLCI).

4.0 Introduction

   In the traditional layer 2 VPNs, the customer facing links are
   required to be of the same data link type for each "circuit". The PE
   device is only responsible for shuttling the data traffic from the
   link connecting to the local CE, over an MPLS core, and to the link
   connecting to the remote CE. This requirement of homogenous data
   link type is somewhat restrictive in building various network
   topologies. In [L2VPN-Kompella], it is observed that if all the
   traffic is known to be IP traffic, it is possible to relax this
   restriction by decapsulating the IP packet from one data link
   encapsulation and simply reencapsulating it in the other.

    However, [L2VPN-Kompella] does not address all the issues. For
   example, consider a situation where the service provider network
   creates a ôcircuitö between an Ethernet VLAN tag and a Frame Relay
   DLCI.  Unless static ARP is used, the CE router connected to the
   Frame Relay interface precedes its IP activity with   discovery of
   its neighborÆs IP address using the inverse ARP protocol [INVARP].
   Similarly, the CE router on an Ethernet precedes its direct IP
   communication by binding its neighborÆs MAC address to its IP
   address via ARP protocol [ARP].  However, the Inverse ARP on a
   point-to-point link is seeking disjoint information from an ARP on a
   broadcast link.

   The PE router is a logical place to perform a mediation function
   between these related but incompatible address resolution protocols.
   Performing this function in the PE simplifies the operation of the
   CE, and keeps pseudo-wire interworking transparent to the CE.

   For each IP Layer 2 interworking circuit, there are three logical
   steps to performing this address mediation:

     1. Have the PEs discover the attached CEÆs IP addresses.
     2. Distribute this IP address to the PE at the remote end of the
     3. Notify the attached CE about the remote CEÆs IP address.

   In some cases these steps are disjoint while in other cases they
   could be part of a single step based on whether the IP address of
   the remote CE device was received along with the cross-connect

   It is important to note that the dynamic learning and distribution
   of the attached CEÆs IP addresses is possible only for some data
   link technologies. For other data links, static configuration cannot
   be avoided.  However, this ARP mediation addresses the most common

   Shah, et al.          Expires August 2002                        4

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   methods of creating Layer 2 VPNs, and therefore should be widely

5.0 IP address discovery of local CE device

   For each Layer 2 IP interworking circuit, the PE creates and fills
   in a tuple consisting of the following:

     1. Attached CEÆs IP address
     2. Circuit Info
     3. Remote CEÆs IP address

   This information is gathered using the mechanisms described below.

   The rest of this section describes how IP address of the locally
   attached CE is learned. Section 6 describes how the learned IP
   address may be distributed to the remote PE using the signaling
   mechanisms either of [L2VPN-KOMPELLA] or [MARTINI-TRANS]. Section 7
   describes how remote PEs process the received cross-connect
   information with or without IP address for IP address resolution
   purposes with local CE.

5.1 Ethernet data link

   PE device attached to Ethernet data link is either cognizant or
   noncognizant of IEEE802.1Q based VLAN tagging. When practicing
   802.1Q based VLAN tagging, each VLAN tag could represent a circuit
   or a pseudo virtual wire that connects to exactly one remote
   endpoint through a pair of PE devices.

   Alternatively, the entire Ethernet port may be treated as a single
   endpoint that is connected to a single remote endpoint via a pair of
   PE devices.

   In either case, only one Ethernet IP end station (CE device) is
   presumed to be present for participation within the IP interworking
   based Layer 2 VPN.

   In order to learn the IP address of the CE device for a given
   Ethernet circuit (i.e. Ethernet port or Ethernet port + VLAN), PE
   device may execute router discovery protocol [RFC 1256] whereby a
   router discovery request (ICMP - router solicitation) message is
   sent on each circuit using source IP address as zero. The IP address
   of the CE device is extracted from the router discovery response
   (ICMP - router advertisement) message from the CE and associated
   with the circuit.

   The use of router discovery mechanism by the PE is optional. The
   alternatives could include gleaning source address field of any
   broadcasts to IP multicast or broadcast address and making sure that
   only one router on the local LAN is sending such broadcasts. It is
   also possible to simply wait for the local router to generate ARP

   Shah, et al.          Expires August 2002                        5

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   request for its neighbor. The Ethernet address and protocol address
   can then be gleaned from the request.

   Once IP address of the CE device is learned, PE periodically
   generates ARP request message as a mean to verify the existence of
   CEÆs IP address and itÆs binding to the Ethernet MAC address. The
   absence of response from the CE device for a given number of retries
   is used as a cause for a withdrawal of IP address advertisement to
   the remote PE and entering into the address resolution phase to
   rediscover the attached CEÆs IP address.

5.2 Frame Relay data link

   A frame relay attached CE device generates inverse ARP request to
   obtain the IP address of the neighbor when the associated DLCI
   becomes active. Traditionally, a DLCI becomes active when the DCE
   signals LMI status active message as a result of associated PVC path
   becoming operational.

   A PE device attached to a CE, connected either directly or through a
   set of frame relay switches, plays the role of an intermediate
   network node for cross-connect purposes. To a frame relay endnode
   (i.e. CE), presence of intermediate frame relay switches and pair of
   PE separated by MPLS cloud along with a remote CE on perhaps
   Ethernet, is transparent and appear as though Ethernet based CE is
   remote end point of frame relay PVC path.

   However, for IP L2 interworking VPN purposes, Ethernet CE and frame
   relay CE are two IP end stations and it becomes necessary for PE to
   play a role in address resolution to keep each end stations unaware
   of data link inconsistency.

   When processing frame relay inverse ARP request for a DLCI, if the
   PE does not have IP address associated with the cross-connect from
   the remote PE, it does not respond, but notes the IP address of the
   frame relay attached CE and the DLCI information. If the remote IP
   address were available, it responds with inverse ARP reply.
   Subsequently, when the IP address of the remote CE becomes
   available, PE may initiate the inverse ARP request as a mean to
   notify the neighbor of the IP address.

5.3 ATM data link

   A CE device attached to ATM data link treats each PVC as an IP
   subnet. PE participates in RFC 2225 defined inverse ATM ARP. When
   processing inATMARP request for a PVC, if the PE does not have IP
   address associated with the cross-connect from the remote PE, it
   does not respond, but notes the IP address of the ATM attached CE
   and the PVC information. If the remote IP address were available it
   would respond with inATMARP reply. Subsequently, when the IP address
   of the remote CE becomes available, PE may initiate the inATMARP
   request as a mean to notify the neighbor of the IP address.

   Shah, et al.          Expires August 2002                        6

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

6.0 IP address distribution between PE

   There are two cross-connect information distribution mechanisms
   defined each in [L2VPN-Kompella] and [MARTINI-TRAN]. Following
   sections discusses how these signaling protocols are extended to
   distribute the associated IP address information.

6.1 BGP based distribution [L2VPN-Kompella]

   The [L2VPN-Kompella] draft has defined the MP-BGP NLRI for the L2VPN
   cross-connect information. The NLRI contains label block offset,
   label base and the size (i.e. length of circuit status vector sub-
   TLV) tuple that provides a set of contiguous labels starting from
   label base to correspond to a set of remote CE-Ids starting from
   label block offset.

   We propose an IP address sub-TLV for this NLRI that accompany this
   tuple. The type value is TBD. The length is same as length of
   circuit status vector sub-TLV. The value field contains the length
   number of 4-byte fields where each field is an IP address that
   corresponds one-to-one with the labels represented by the label base
   and length field. The PE device should note the label to IP address
   association by iterating through each IP field value in order.

6.2 LDP based distribution [MARTINI-TRANS]

   The [MARTINI-TRANS] uses LDP transport to exchange layer-2 cross-
   connect information for a given VPN. The cross-connect information
   is represented as a VC FEC element that LDP protocol distributes to
   remote peer in downstream-unsolicited mode. This document proposes
   extensions to VC FEC element to support the IP L2 inteworking as a
   new VPN type and to include the IP address information.

6.2.1 IP L2 Interworking encapsulation

   The IP L2 interworking VPN type is advertised in the "VC-type" field
   of the VC FEC as the value 0x000C.

   The "interface parameter" field in the VC FEC is defined in
   [MARTINI-TRANS] as follows.

       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
      |  Parameter ID |    Length     |    Variable Length Value      |
      |                         Variable Length Value                 |
      |                             "                                 |

   Shah, et al.          Expires August 2002                        7

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

      The parameter ID is defined as follows:
      Parameter   ID Length    Description

          0x01         4       Interface MTU in octets.
          0x02         4       Maximum Number of concatenated ATM cells.
          0x03   up to 82      Optional Interface Description string.
          0x04         4       CEM [8] Payload Bytes.
          0x05         4       CEM options.

      The Length field is defined as the length of the interface
   parameter including the parameter id and length field itself.

   We propose additional parameter for the parameter ID.

          0x06         4       IP address of CE

   The IP address interface parameter contains the IP address
   associated with the advertised VC-id. If IP address is not known,
   this interface parameter may not be present in the advertisement. If
   present, it may contain the IP address value as In either
   case, receiving PE processes the information as IP address
   association unknown for the advertised VC-ID.

6.2.2 Data forwarding

   When participating in IP L2 interworking VPN, the receiving PE must
   check the received access VC type against the local access (or
   attachment) VC type for the matching cross-connect. When the access
   VC types are identical, IP L2 interworking aspects of the cross-
   connect should be ignored and revert to traditional data forwarding
   mechanisms as defined for such VC type in [MARTINI-ENCAP].

   However, when access VC types are different and the VC type field is
   IP L2 Interworking, the mechanisms defined in this document should
   be followed.

   The IP L2 Interworking permits only IP data packets to be exchanged
   over the emulated VC. The following description from [L2VPN-
   Kompella] shows how data packets are handled by the ingress and
   egress PE.

   At the ingress PE, an L2 frame's L2 header is completely stripped off
   and is carried over as an IP packet through a tunnel to the egress
   PE.  The forwarding decision is still based on the L2 circuit
   information of the incoming IP frame.  At the egress PE, the IP
   packet is encapsulated back in an L2 frame and transported over to
   the destination CE.  The forwarding decision at the egress PE is
   based on the VC label as discussed in [MARTINI-ENCAP].  The L2
   technology between egress PE and CE is independent of the L2
   technology between ingress PE and CE.

   Shah, et al.          Expires August 2002                        8

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

6.3 IP address distribution operation

   A PE device advertises the IP address of the attached CE only when
   the encapsulation type of the VPN is IP L2 interworking. It is quite
   possible that the IP address of a CE device is not available at the
   time of advertisements. For example, in frame relay the CE device
   dispatches inverse ARP request only when the DLCI is active and if
   the PE signals DLCI to be active only when it has received the
   cross-connect information from the remote PE, a chicken and egg
   situation arises. In order to avoid such problems, the PE must
   advertise the cross-connect information with or without (i.e. no IP
   TLV or the corresponding IP address. When the IP address of
   the CE device does become available, a new advertisement is
   generated with updated IP address field value.

   Similarly, If PE detects invalidation of CEÆs IP address (by methods
   described above), PE may re-advertise the cross-connect information
   without IP address or with IP address as zero to denote the
   withdrawal of IP address. The receiving PE may then wait for the IP
   address information from the remote PE before enabling the unicast
   IP traffic flow.

7.0 How CE learns IP address of remote CE

   Once the PE has learned IP address to label association from the
   remote PEÆs cross-connect advertisement, it can either initiate the
   address resolution request or respond to the request from the
   attached CE device.

7.1 Ethernet data link

   When PE learns about remote CEÆs IP address from the layer 2 VPN
   advertisement (as described above), it may or may not know local
   CEÆs IP address. If local CEÆs IP address is not known, it must wait
   for the arrival of either IGP broadcast packet or RDP response or an
   ARP request from the local CE. If, however, local CEÆs IP address is
   already known, PE may choose to generate unsolicited ARP
   (gratuitous) message to notify the local CE about the association of
   remote CEÆs IP address and the PEÆs own MAC address.

   In either case, as and when an ARP request is generated by the local
   CE, PE must proxy ARP response using his own MAC address as the
   source hardware address and remote CEÆs IP address as source
   protocol address. PE must respond only to those ARP requests whose
   destination protocol address matches to remote CEÆs IP address.

   If two CE devices are locally attached to PE where one CE is
   connected to Ethernet data link and other to Frame relay data link
   for example, the IP addresses are learned in the same manner as
   described above. However, since the CE devices are local, the
   distribution of IP addresses for these CE devices is a local step.

   Shah, et al.          Expires August 2002                        9

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

7.2 Frame relay data link

   If a PE has received new cross-connect information from the remote
   PE, the corresponding local DLCI may not be active. PE should use
   the cross-connect information to activate the DLCI via LMI and
   schedule the inverse ARP request. The PE may choose to delay
   generation of inverse ARP request in order for attached CE to
   generate the request first. However, it is possible that PE may
   never get inverse ARP request nor may it get the response to its own
   request. This may be the result of IP protocol not being enabled on
   CE device at the time when DLCI was activated. This is not an issue
   since cross connect information exchange is not predicated on
   learning of CEÆs IP address. As and when the IP protocol is enabled
   on the CE device, an inverse ARP request would be forthcoming.

   It is also possible that CE router may never generate inverse ARP
   request as it may already be configured with IP address of the
   remote end point and/or inverse ARP is disabled or not supported. If
   inverse ARP protocol is supported (disabled or not), CE router would
   still respond to inverse ARP request even when it already knows the
   IP address of the remote end station. However, if inverse ARP
   protocol is not supported, PE is required to be configured with the
   IP address of the attached CE router in order for the PE to
   distribute the IP address as part of the cross-connect information
   to the remote PE.

7.3 ATM data link

   The PE device should generate the inAtmARP request when the IP
   address of the remote cross-connected CE device becomes available.
   The role of PE device in handling address resolution for the IP L2
   interworking cross-connect for local ATM PVC is similar to that of
   local frame relay PVC.

   It is also possible that ATM end station is participating in RFC
   1577 style dynamic ARP mechanisms using the ATM ARP server. This
   document leaves the option of participation with ATM ARP server to
   vendorÆs implementation. As always, static configuration of the
   local CEÆs IP address is another option that PE may use.

8.0 Multipoint IGP to point-to-point IGP issues

   In IP L2 interworking VPN, when an IGP on CE connected to a
   broadcast link is cross-connected with an IGP on CE connected to a
   point-to-point link, there are routing protocol related issues that
   must be addressed. The link state routing protocols are cognizant of
   the underlying link characteristics and behave accordingly when
   establishing neighbor adjacencies, representing the network topology
   and passing protocol packets.

8.1 OSPF

   Shah, et al.          Expires August 2002                       10

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   OSPF protocol treats broadcast link type with a special procedure
   that engages in neighbor discovery to elect a designated and a
   backup designated (DR and BDR respectively) router to form adjacency
   with. However, these procedures are neither applicable nor
   understood by OSPF running on a point-to-point link. By cross-
   connecting two neighbors with disparate link types in IP L2
   interworking VPN causes this confusion that must be avoided.

   Additionally, link type specified in router LSA would appear
   different for two routers that are supposedly to be present on the
   same link. Also, OSPF router generates network LSAs when connected
   to broadcast link such as Ethernet, receipt of which by an OSPF
   router on the point-to-point link adds to the confusion.

   Fortunately, OSPF protocol provides a configuration option
   (ospfIfType), whereby OSPF would treat the underlying physical
   broadcast link as a point-to-point link.

   It is strongly recommended that all OSPF protocols on CE devices
   connected to Ethernet data link must use this configuration when
   attached PE that is participating in IP L2 Interworking VPN.

8.2 IS-IS

   IS-IS protocol sends LAN Hello PDU (IIH packet) on Ethernet link
   with MAC address and IP address of the CE device. It expects
   neighbor to insert his own MAC and IP address in the response. If
   the neighbor is cross-connected to a point-to-point remote CE
   device, the LAN Hello PDU would be silently discarded. Similarly,
   Hello PDU on the point-to-point link does not contain any MAC
   address, which confuses the cross-connected neighbor on Ethernet

   Thus, IS-IS protocol on the CE devices presents problem when
   interconnected by disparate data link types in IP L2 interworking
   VPN environment.  There are some mechanisms defined in draft-ietf-
   isis-igp-p2p-over-lan-00.txt to accommodate point-to-point behavior
   over broadcast network. The feasibility of such technique to solve
   this problem is under review.

8.3 RIP

   RIP protocol broadcasts RIP advertisements every 30 seconds. If
   multicast snooping mechanism is used, PE can learn the advertising
   routerÆs IP address from the IP header of the advertisement. No
   special configuration is required for RIP in this type of layer 2 IP
   interworking VPN.

9.0 Conclusion

   The three step procedure; discovering IP address of local CE device,
   distribution of the IP address to remote PE and notifying the IP

   Shah, et al.          Expires August 2002                       11

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   address to the attached CE device; described in this document
   provides for reduced configuration of the PE devices used for IP-
   interworking solution.

   There are cases where the manual configuration of the IP address is
   not avoidable. These cases relate to either some of the data links
   like, Cisco HDLC, that do not support the address resolution
   protocol or that address resolution is disabled by, for example, use
   of unnumbered interface in the CE device.

   It is also important to note that IP address changes on the CE
   devices may require manual interventions (e.g. soft reset of the
   attached port) on the PE device.

   For most common cases, the procedure described in this document
   enhances the IP interworking solution of [L2VPN-Kompella].

10.0 Acknowledgements

   Authors would like to thank Tim Mancour, Bruce Lasley, Bill
   Townsend, Arnold Sodder and other folks within Tenor who
   participated in discussions related to this draft.

11.0 Security Considerations

   The security aspects of this solution will be discussed at a later

11.0 References

   [L2VPN-Kompella] Kompella et al., "MPLS based Layer 2 VPNs", draft-
   kompella-ppvpn-l2vpn-01.txt, November 2001.

   [L2VPN-ENCAP] Martini et al., "Encapsulation Methods for Transport
   of Layer 2 Frames over MPLS", draft-martini-l2circuit-encap-mpls-
   04.txt, November 2001, (work in progress).

   [L2VPN-TRANS] Martini et al., "Transport of Layer 2 frames over
   MPLS", draft-martini-l2circuit-trans-mpls-08.txt. November 2001,
   (work in progress)

   [INVARP] T.Bradley et al., "Inverse Address Resolution Protocol",
   RFC2390, September 1998.

   [ARP] Plummer, D., "An Ethernet Address Resolution Protocol:  Or
   Converting Network Protocol Addresses to 48.bit Ethernet
   Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826,
   November 1982.

   [PROXY-ARP] Postel, J., "Multi-LAN Address Resolution", RFC 925,
   October 1984.

   Shah, et al.          Expires August 2002                       12

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

Author's Address

   Himanshu Shah
   Tenor Networks
   100 Nagog Park
   Acton, MA 01720
   Email: hshah@tenornetworks.com

   Prabhu Kavi
   Tenor Networks
   100 Nagog Park
   Acton, MA 01720
   Email: Prabhu_kavi@tenornetworks.com

   Eric Rosen
   Cisco Systems
   300 Apollo Drive,
   Chelmsford, MA 01824
   Email: erosen@cisco.com

   Waldemar Augustyn
   Email: waldemar@nxp.com

   Giles Heron
   PacketExchange Ltd.
   The Truman Brewery
   91 Brick Lane
   United Kingdom
   Email: giles@packetexchange.net

   Sunil Khandekar and Vach Kompella
   TiMetra Networks
   274 Ferguson Dr.
   Mountain View, CA 94043
   Email: sunil@timetra.com
   Email: vkompella@timetra.com

   Vijay Aggarwal
   Gotham Networks
   15 Discovery Way
   Acton, MA 01720
   Email: vaggarwal@gothamnetworks.com

   Jeremy Brayley and Rafael Francis
   Laurel Networks
   Omega Corporate Center
   1300 Omega drive
   Pittsburgh, PA 15205
   Email: jbrayley@laurelnetworks.com
   Email: rfrancis@laurelnetworks.com

   Shah, et al.          Expires August 2002                       13

   Internet Draft  draft-shah-ppvpn-arp-mediation-00.txt

   Arun Vishwanathan
   Force10 Networks
   1440 McCarthy Blvd.,
   Milpitas, CA 95035
   Email: arun@force10networks.com

   Ashwin Mornaganti
   Appian Communications
   35 Nagog Park
   Acton, MA 01720
   Email: amoranganti@appiancom.com

   Shah, et al.          Expires August 2002                       14