Himanshu Shah
                                                            Prabhu Kavi
   PPVPN Working Group                                   Tenor Networks
   Internet Draft
   Draft-shah-ppvpn-arp-mediation-01.txt                     Eric Rosen
                                                          Cisco Systems
   October 2002
   Expires: April 2003                                Waldemar Augustyn

   Sunil Khandekar                                          Giles Heron
   Vach Kompella                                     PacketExchange,Ltd
   TiMetra Networks
                                                      Arun Vishwanathan
   Toby Smith                                          Force10 Networks
   Laurel Networks
                                                      Ashwin Moranganti
   Steven Wright                                   Appian Communication
   Bell South
                                                           Andrew Malis
   Vasile Radoaca                                       Vivace Networks
   Nortel Networks

             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
   The list of Internet-Draft Shadow Directories can be accessed at

   Shah, et al.           Expires April 2003                         1
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

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, for
   instance, one using ARP on Ethernet and the other using Inverse ARP
   on Frame Relay. It is up to the Provider Edge routers to make these
   different techniques inter-work.  This draft specifies the procedures
   which the Provider Edge (PE) 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 Customer Edge (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
   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

   Shah, et al.           Expires April 2003                         2
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   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 Circuits (AC)
   as the endpoints of a pseudowire. For example, a CE device on
   Ethernet is attached to a pseudowire whose other end point is a CE
   device on Frame Relay. The Attachment Circuit in this example could
   then be a VLAN tag on Ethernet interface emulated to the Attachment
   Circuit of a Frame Relay DLCI on the other end. Any attempt to make
   use of such heterogeneous circuits faces the following problems:

     1. Different encapsulations may be used on the two Attachment
        Circuits. Frames from one Attachment Circuit can not just be
        forwarded unchanged on the other; rather the frames must be
        processed by some sort of interworking function.
     2. A CE device may execute procedures which are specific to a
        particular type of Attachment Circuit (AC), and it may
        presuppose that the CE at the other end of the CE-CE circuit is
        executing those same procedures. Therefore, if the two CEs are
        attached via different types of Attachment Circuits, and are
        executing different AC-specific procedures, some means of
        mediating between those different procedures is needed.

   The [L2VPN-Kompella] specifies procedures for dealing with problem
   1, above. In the proposed scheme, the interworking functions strip
   the Layer 2 header of the data packet at ingress and prepend the
   appropriate Layer 2 header at the egress.

   However, [L2VPN-Kompella] draft does not specify any procedures for
   dealing with the problem 2 above. 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 or ATM, it may use Inverse ARP to learn the IP address of
   its neighbor. Similarly, if CE2 is attached to PPP, it may seek the
   IP address of its neighbor during IPCP negotiations. Note that in
   either case, CE2 is seeking the IP address of its neighbor (i.e.,
   CE1) while CE1 is seeking MAC address of its neighbor (i.e., CE2) for
   the IP address learned via other means. For CE1 and CE2 to interwork
   correctly, PE1 and PE2 must mediate the address-learning and
   resolution process.

   One option is 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 is to have
   the service provider network automatically mediate between the
   various address resolution 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 address resolution procedures.  The

   Shah, et al.           Expires April 2003                         3
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   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 address information so
   that address resolution information can be passed to the CE. Under
   no circumstances does the PE make forwarding decision based on the
   Layer 3 addressing information.

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 in which 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 the 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 pseudowire 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 PE discover the attached CEÆs IP address (details in
        section 5.0).
     2. Distribute this IP address to the PE at the remote end of the
        circuit (details in section 6.0).
     3. Notify the attached CE about the remote CEÆs IP address
        (details in section 7.0).

   It is important to note that the dynamic learning and distribution
   of the attached CEÆs IP address is possible only for some data link

   Shah, et al.           Expires April 2003                         4
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   technologies. For other data links, static configuration cannot be
   avoided.  However, ARP Mediation addresses the most common methods
   of creating Layer 2 VPNs, and therefore should be widely useful.

5.0 How the PE Discovers the Address of the 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 Information
     3. Remote CEÆs IP address

   This information is gathered using the mechanisms described below.

   The rest of this section describes how the 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 of either [L2VPN-KOMPELLA] or [PWE3-CONTROL]. Section 7
   describes how the remote PE processes the received cross-connect
   information for IP address resolution.

5.1 Ethernet Data Link

   We are assuming a Virtual Private Wire Service (VPWS) as described
   in [L2VPN-FW] for the CE/PE Attachment Circuit as an Ethernet
   containing only that CE and that PE.

   In order to learn the IP address of the CE device for a given
   Ethernet Attachment Circuit, the PE device may execute Router
   Discovery Protocol [RFC 1256] whereby a Router Discovery Request
   (ICMP -         - router solicitation) message is sent using a source IP
   address of zero. The IP address of the CE device is extracted from
   the Router Discovery Response (ICMP -                                       - router advertisement) message
   from the CE.

   The use of the router discovery mechanism by the PE is optional. The
   alternatives could include gleaning the source address field of any
   broadcasts to IP multicast/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 CE to generate the ARP request
   for its neighbor or send gratuitous ARP on startup. The Ethernet
   address and protocol address can then be gleaned from the request.
   Once the PE learns the IP address of the CE, the CEÆs address is
   signaled to remote PE (section 6.0).

   The PE could periodically generate the ARP request message to the
   CEÆs IP address as a means to verify the continued existence of the
   CEÆs IP address and its binding to the Ethernet MAC address. The
   absence of a response from the CE device for a given number of
   retries could be used as a cause for a withdrawal of the IP address
   advertisement to the remote PE and entering into the address
   resolution phase to rediscover the attached CEÆs IP address. Note

   Shah, et al.           Expires April 2003                         5
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   that such ææheartbeatÆÆ scheme is needed only for broadcast links such
   as Ethernet, as a loss of CE may otherwise be undetectable.

5.2 Frame Relay Data Link

   A Frame Relay attached CE device generates an 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 the 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. a CE), the presence of any intermediate Frame Relay switches,
   a pair of PEs and the fact that the remote CE may be Ethernet-
   attached, is all transparent. As far as Frame Relay CE is concerned,
   the Ethernet CE appears as the remote end point of the Frame Relay
   PVC path.

   However, for IP L2 interworking VPN purposes, the Ethernet CE and
   the Frame Relay CE are two IP end stations and it becomes necessary
   for the PE to play a role in address resolution to keep both end
   stations unaware of data link address resolution inconsistencies.

   When a PE processes the Frame Relay Inverse ARP request for a DLCI,
   it responds with an Inverse ARP reply containing the remote CEÆs IP
   address, if the address is known. If the PE does not yet have the
   remote CEÆs IP address, it does not respond, but notes the IP
   address of the local CE and the DLCI information. Subsequently, when
   the IP address of the remote CE becomes available, the PE may
   initiate the Inverse ARP request as a means to notify the local CE,
   the IP address of the remote CE.

   Also, note that the PE continues to learn the IP address of the CE
   from any multicast/broadcast IP packet that CE may generate
   irrespective of Inverse ARP protocol execution.

5.3 ATM Data Link

   A CE device attached to ATM data link can be configured to treat
   each PVC as an IP subnet. The PE participates in RFC 2225 defined
   inverse ATM ARP. When processing an Inverse ATM ARP request for a
   PVC, if the PE does not have the 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 is available, it responds with the Inverse ATM ARP
   reply. Subsequently, when the IP address of the remote CE becomes
   available, the PE may initiate the Inverse ATM ARP request as a
   means to notify the local CE the IP address of the remote CE.

   Shah, et al.           Expires April 2003                         6
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   Also note that the PE continues to learn the IP address of the CE
   from any multicast/broadcast IP packet that the CE may generate
   irrespective of Inverse ARP protocol execution.

5.4 PPP Data Link

   A CE device attached to a PPP data link participates in IPCP [RFC
   1332] to obtain the neighborÆs IP address. If the PE device has the
   cross-connect and the IP address of the remote CE, it responds to
   the IPCP Configure-Request. However, if the PE does not have the
   remote CEÆs IP address, it does not respond to the local CEÆs IPCP
   request but simply notes its IP address. Subsequently, when the IP
   address of the remote CE becomes available, the PE generates IPCP
   Configure-Request to the local CE.

   Also, the PE must deny configurations such as header compression and
   encryptions in the NCP packets with such options.

6.0 IP Address Distribution Between PE

   There are two cross-connect information distribution mechanisms
   defined in [L2VPN-Kompella] and [PWE3-Control] respectively. The
   following sections discuss how these signaling protocols are
   extended to distribute the associated IP address information.

6.1 When To Distribute IP Address

   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 the VC labels are advertised. For example, in Frame Relay the
   CE device dispatches inverse ARP request only when the DLCI is
   active; if the PE signals the 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 be prepared to advertise the cross-connect information before
   the CEÆs IP address is known. When the IP address of the CE device
   does become available, the PE re-advertises the cross-connect
   information with an updated IP address field value.

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

   If two CE devices are locally attached to the PE where, one CE is
   connected to an Ethernet data link and the other to a Frame Relay
   interface, for example, the IP addresses are learned in the same

   Shah, et al.           Expires April 2003                         7
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   manner described above. However, since the CE devices are local, the
   distribution of IP addresses for these CE devices is a local step.

6.2 BGP Based Distribution [L2VPN-Kompella]

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

   We propose an IP address sub-TLV for this NLRI that accompanies this
   tuple. The type value is TBD. The length is the same as the length
   of the 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 the length field. The PE device should note the label to IP
   address association by iterating through each IP field value in

6.3 LDP Based Distribution [PWE3-CONTROL]

   The [PWE3-CONTROL] 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 the LDP protocol distributes
   to the remote peer in downstream-unsolicited mode. This document
   proposes extensions to VC FEC element to support the IP L2
   interworking as a new VPN type and to include the IP address

6.3.1 IP L2 Interworking Signaling

   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 [PWE3-
   CONTROL] 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                 |
      |                             "                                 |

      The parameter ID is defined as follows:

   Shah, et al.           Expires April 2003                         8
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

      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 the length field itself.

   We propose an 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 the 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, the receiving PE processes the information
   as IP address association unknown for the advertised VC-ID.

   We recommend two options for signaling such ææVC associated
   informationÆÆ that are currently present as the interface parameter
   field in the VC FEC.
     1. The entire ææinterface parameterÆÆ field is either removed or
        duplicated from the VC FEC to the ææoptional parameterÆÆ field of
        the LDPÆs Label Mapping Message.
     2. A new VC Status FEC is introduced that accompanies the VC FEC
        in the LDPÆs Label Mapping Message. The ææinterface parameterÆÆ
        field of the VC FEC is then either removed or duplicated from
        the VC FEC to the VC Status FEC.

   We intend to work with authors of [PWE3-Control] and [Rosen-
   Signaling] to find the most suitable solution for extensions (such
   as IP address, IP address and MAC address, interface status, etc.)
   that are generic, in a backward compatible fashion.

7.0 How CE Learns The Remote CEÆs IP address

   Once the PE has received the remote CEÆs IP address information from
   the remote PE, it will either initiate an address resolution request
   or respond to an outstanding request from the attached CE device.

7.1 Ethernet Data Link

   When the PE learns the remote CEÆs IP address from the Layer 2 VPN
   advertisement (as described above), it may or may not know the local
   CEÆs IP address. If the local CEÆs IP address is not known, the PE
   must wait for the arrival of an IGP broadcast packet, a RDP response
   packet or an ARP request packet from the local CE. If, however,
   local CEÆs IP address is already known, the PE may choose to

   Shah, et al.           Expires April 2003                         9
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   generate an unsolicited ARP message to notify the local CE about the
   binding of the remote CEÆs IP address with the PEÆs own MAC address.

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

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 yet be active. The PE
   should use the cross-connect information to activate the DLCI via
   LMI and schedule an inverse ARP request. The PE may choose to delay
   the generation of the Inverse ARP request in order to allow the
   attached CE to generate the request first. However, it is possible
   that the PE may never receive the Inverse ARP request, nor the
   response to its own request. This could occur for a number of
     1. The IP protocol is not enabled on the CE device at the time
        when the DLCI was activated. This is not an issue since the
        cross connect information exchange is not predicated on
        learning of the CEÆs IP address. When the IP protocol is
        enabled on the CE device, an inverse ARP request will be
     2. No Inverse ARP request is generated if the CE is already
        configured with the remote CEÆs IP address, hence there is no
        need to generate the request. Since the PE does not know of
        this situation, it must generate an Inverse ARP request using
        the remote CEÆs IP address. The response from the CE enables
        the PE to learn its IP address.
     3. The CE router does not support the Inverse ARP protocol or the
        Inverse ARP protocol is disabled. We have found through
        experimentations that most implementations do respond to the
        Inverse ARP Request even when Inverse ARP protocol is disabled
        (it seems that disabling of protocol only means that request
        generation is disabled). However, if the Inverse ARP Protocol
        is not supported, the PE needs to be configured with the IP
        address of the attached CE. This facilitates distribution of
        the IP address to the remote PE.

7.3 ATM Data Link

   The PE device should generate an Inverse ATM ARP request when the IP
   address of the remote cross-connected CE device becomes available.
   The role of the PE device in handling address resolution for the IP
   L2 interworking cross-connect for ATM VCs is similar to the behavior
   described above for Frame Relay VCs.

   As always, static configuration of the local CEÆs IP address is an
   available option, when all else fails.

   Shah, et al.           Expires April 2003                        10
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

7.4 PPP

   The PE device should respond to the local CEÆs IPCP Configure-
   Request with the remote CEÆs IP address. However, if the IP address
   is not available, the PE should postpone the response. When the
   remote CEÆs IP address becomes available, the PE must initiate the
   Configure-Request using the remote CEÆs IP address. As noted
   earlier, all other configuration options related to compression,
   encryptions, etc., should be rejected.

8.0 Data Forwarding

   The IP L2 Interworking permits only IP data packets to be exchanged
   over the pseudowire. 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.

   The PE should observe the following forwarding rules when processing
   IP data packets for interworking circuits.

     1. If the PE has not learned the IP address of the local CE and the
        IP packet received from the local CE is multicast or a
        broadcast, the PE should learn the source IP address and forward
        the packet to the corresponding pseudowire. If the Attached
        Circuit is Ethernet, it should also learn the MAC address of the
        CE device. The PE must forward multicast/broadcast IP packet
        from the Attachment Circuit to the pseudowire irrespective of
        the status of the remote CEÆs IP address.
     2. If the PE has not learned the IP address of the local CE, the PE
        should forward the multicast/broadcast IP packet from the
        pseudowire to the local Attachment Circuit. If the Attachment
        Circuit is Ethernet, PE must translate IP multicast/broadcast
        destination to appropriate MAC DA.
     3. If a PE has the local and the remote CEsÆ IP addresses, all IP
        packets are forwarded in both directions between the Attachment
        Circuit and the pseudowire. When the Attachment Circuit is
        Ethernet, a unicast IP packet from the pseudowire is prepended
        with the Ethernet MAC header using the MAC DA of the CE
        (obtained during the learning phase) and the MAC SA of the PE.
     4. All Unicast IP packets received from the Attachement Circuit and
        the pseudowire are dropped until the local and remote CEsÆ IP
        addresses are known.

   Shah, et al.           Expires April 2003                        11
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

9.0 Use of IGPs with IP L2 Interworking VPNs

   In an IP L2 interworking VPN, when an IGP on a CE connected to a
   broadcast link is cross-connected with an IGP on a 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.

9.1 OSPF

   The OSPF protocol treats broadcast link type with a special
   procedure that engages in neighbor discovery to elect a designated
   and a backup designated router (DR and BDR respectively) with which
   it forms adjacencies. 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, an IP
   L2 interworking VPN has the potential to experience connectivity

   Additionally, the link type specified in the router LSA will not
   match for two routers that are supposedly sharing the same link
   type. Finally, each OSPF router generates network LSAs when
   connected to a broadcast link such as Ethernet, receipt of which by
   an OSPF router on the point-to-point link further adds to the

   Fortunately, the OSPF protocol provides a configuration option
   (ospfIfType), whereby OSPF will 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 interfaces use this configuration option when
   attached to a PE that is participating in an IP L2 Interworking VPN.

9.2 IS-IS

   The IS-IS protocol sends a LAN Hello PDU (IIH packet) with the MAC
   address and the IP address of the intermediate system (i.e., CE
   device) when attached to Ethernet links. The CE device expects its
   neighbor to insert its own MAC and IP address in the response. If
   the neighbor is connected via a point-to-point link type, the LAN
   Hello PDU will be silently discarded. Similarly, Hello PDUs on the
   point-to-point link do not contain any MAC address, which will
   confuse a neighbor on an Ethernet link, if these two neighbors were
   cross-connected via above described mechanisms.

   Thus, use of the IS-IS protocol on CE devices presents problems when
   interconnected by disparate data link types in an IP L2 interworking

   Shah, et al.           Expires April 2003                        12
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   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 networks. The feasibility of such techniques to solve
   this problem is under review.

   It is important to note that the use of the IS-IS protocol in
   enterprise networks (i.e., CE routers) is less common. The IS-IS
   related difficulties for IP L2 Interworking VPNs, hence are

9.3 RIP

   RIP protocol broadcasts RIP advertisements every 30 seconds. If the
   group/broadcast address snooping mechanism is used as described
   above, the attached PE can learn the advertising (CE) 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.

10.0 Conclusion

   The three step procedure of discovering the IP address of a local CE
   device, distributing the CEÆs IP address to the remote PE and
   notifying the local CE of the remote CEÆs IP address, as described
   in this document provides for reduced configuration of the PE
   devices used for IP L2 Interworking VPNs.

   There are cases where the manual configuration of the CEÆs IP
   address is unavoidable. These cases include the use of interfaces
   that support address resolution but do not have address resolution
   enabled, such as unnumbered interfaces on the CE device.

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

   For most common interface types, however, the procedures described
   in this document enhance the IP interworking solution of [L2VPN-
   Kompella] by reducing the amount of configuration required on the PE

11.0 Acknowledgements

   Authors would like to thank Bruce Lasley and other folks within
   Tenor who participated in discussions related to this draft.

12.0 Security Considerations

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

   Shah, et al.           Expires April 2003                        13
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

13.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).

   [PWE3-CONTROL] Martini et. Al., ææTransport of Layer 2 Frames Over
   MPLSÆÆ, draft-ietf-pwe3-control-protocol-00.txt, August 2002 (work in

   [L2VPN-Signaling] Rosen et al., ææLDP-based Signaling for L2VPNsÆÆ,
   draft-rosen-ppvpn-l2-signaling-02.txt, September 2002

   [L2VPN-FW] "PPVPN L2 Framework", Andersson et. al., draft-ietf-
   ppvpn-l2-framework-00.txt, August 2002

   [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, draft-
   andersson-ppvpn-terminology-01.txt, June 2002

   [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.

14. Intellectual Property Considerations

   Tenor Networks may seek patent or other intellectual property
   protection for some of all of the technologies disclosed in this
   document.  If any standards arising from this document are or become
   protected by one or more patents assigned to Tenor Networks,
   Tenor intends to disclose those patents and license them on
   reasonable and non-discriminatory terms.

Author's Address

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

   Prabhu Kavi
   Tenor Networks

   Shah, et al.           Expires April 2003                        14
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   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

   Toby Smith
   Laurel Networks
   Omega Corporate Center
   1300 Omega drive
   Pittsburgh, PA 15205
   Email: jsmith@laurelnetworks.com

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

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

   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   Email: Andy.Malis@vivacenetworks.com

   Shah, et al.           Expires April 2003                        15
   Internet Draft  draft-shah-ppvpn-arp-mediation-01.txt

   Steven Wright
   Bell South Corp
   Email: steven.wright@bellsouth.com

   Vasile Radoaca
   Nortel Networks
   Email: vasile@nortelnetworks.com

   Shah, et al.           Expires April 2003                        16