L2VPN Working Group                H. Shah                       Ciena
  Internet Draft                     E. Rosen              Cisco Systems
                                     W. Augustyn              consultant
  October 2004
  April 2005                         G. Heron                    Tellabs
  Expires: April September 2005            T. Smith            Laurel Networks
                                     A. Moranganti     Axiowave     Big Band Networks
                                     S. Khandekar                Alcatel
                                     V. Kompella                 Alcatel
                                     A. Malis                    Tellabs
                                      S. Wright                Bell South
                                      V. Radoaca          Nortel       Westridge Networks
                                      A. Vishwanathan    Force10 Networks

           ARP Mediation for IP Interworking of Layer 2 VPN

                   draft-ietf-l2vpn-arp-mediation-00.txt

                   draft-ietf-l2vpn-arp-mediation-01.txt

  Status of this memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with RFC 3668.

    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.

  Abstract

    The VPWS service [L2VPN Framework] provides point-to-point
    connections between pairs of Customer Edge (CE) devices.  It does
    so by binding two Attachment Circuits (each connecting a CE device
    with a Provider Edge, PE, device) to a Pseudowire (connecting the
    two PEs).  In general, the Attachment Circuits must be of the same
    technology (e.g., both ethernet, both ATM), and the Pseudowire must
    carry the frames of that technology.  However, if it is known that
    the frames' payload consists solely of IP datagrams, it is possible
    to provide a point-to-point connection in which the Pseudowire 
                 draft-ietf-l2vpn-arp-mediation-00.txt 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    connects Attachment Circuits of different technologies.  This
    requires the PEs to perform a function known as "ARP Mediation".
    This document specifies the
    ARP Mediation function, and specifies
    the encapsulation used refers to carry the IP datagrams process of resolving Layer 2 addresses
    when different resolution protocols are used on the Pseudowires either Attachment
    Circuit. The methods described in this document are applicable even
    when the CEs run a routing protocol between them, as long as the
    routing protocol runs over IP. In particular, the applicability of
    ARP mediation to ISIS is used. not addressed.

     Table of Contents

    1 .0 Introduction................................................2
    2 .0 ARP Mediation (AM) function.................................3
    3 .0 IP Layer 2 Interworking Circuits............................4
    4 .0 Discovery of IP Addresses of Locally Attached CE Device.....4
    4.1 Monitoring Local Traffic.....................................4
    4.2 CE Devices Using ARP.........................................4
    4.3 CE Devices Using Inverse ARP.................................6 ARP.................................5
    4.4 CE Devices Using PPP.........................................6
    4.5 Proactive method.............................................6 Router Discovery method......................................6
    5 .0 CE IP Address Distribution Between PE..........................7 Signaling between PEs.........................7
    5.1 When To Distribute to Signal a CEĂs IP Address................................7 Address.............................7
    5.2 LDP Based Distribution.......................................7
    5.3 Out-of-band Distribution, Manual Configuration...............8
    5.4 Single sided ARP mediation...................................8 Distribution Configuration.......................8
    6 .0 How a CE Learns The the Remote CE's IP address....................9 address..................8
    6.1 CE Devices Using ARP.........................................9 ARP.........................................8
    6.2 CE Devices Using Inverse ARP................................10 ARP.................................9
    6.3 CE Devices Using PPP........................................10 PPP.........................................9
    7 .0 Use of IGPs with IP L2 Interworking L2VPNs.................10 L2VPNs..................9
    7.1 OSPF........................................................10 OSPF.........................................................9
    7.2 IS-IS.......................................................11
    7.3 RIP.........................................................11 RIP.........................................................10
    8 .0 Security Considerations....................................12 Considerations....................................10
    8.1 Control plane security......................................10
    8.2 Data plane security.........................................11
    9 .0 Acknowledgements...........................................12 Acknowledgements...........................................11
    10 .0 References................................................12 References................................................11
    10.1 Normative References.......................................12 References.......................................11
    10.2 Informative References.....................................12 References.....................................11
    11 .0 Authors' Addresses........................................13 Addresses........................................12

    1.0 Introduction

    Layer 2 Virtual Private Networks (L2VPN) are constructed with the
    use of over  a
    Service Provider IP backbone but are presented to the Customer Edge
    (CE) devices as Layer 2 networks.  In theory, L2VPNs can carry any
    Layer 3 protocol, but in many cases, the only  Layer 3 protocol is IP.
    Thus it makes sense to consider procedures that are either  optimized for IP or are outright dedicated to IP traffic
    only.
    IP.

    In a typical implementation, illustrated in the diagram below, the
    CE devices are connected to the Provider Edge (PE) devices via
    Attachment Circuits (AC).  The ACs are Layer 2 links.  In a pure

 Shah, et. al.           Expires September 2005                       2 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both

 Shah, et. al.             Expires April 2005                         2 
                 draft-ietf-l2vpn-arp-mediation-00.txt
    ACs would have to be of the same type (i.e., both Ethernet, both
    FR, etc.). However, if it is known that only IP traffic will be
    carried, the ACs can be of different technologies, provided that
    the PEs provide the appropriate procedures to allow the proper
    transfer of IP packets.

                                                     +-----+
                                +--------------------| CE3 |
                                |                    +-----+
                             +-----+
                     ........| PE3 |.........
                     .       +-----+        .
                     .          |           .
                     .          |           .
      +-----+ AC1 +-----+    Service     +-----+ AC2 +-----+
      | CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 |
      +-----+     +-----+    Backbone    +-----+     +-----+
                     .                      .
                     ........................

    A CE, which is connected via a given type of AC, may use an IP
    Address Resolution procedure that is specific to that type of AC.
    For example, an Ethernet-attached CE would use ARP, a FR-attached
    CE might use Inverse ARP.  If we are to allow the two CEs to have a
    layer
    Layer 2 connection between them, even though each AC uses a
    different layer Layer 2 technology, the PEs must intercept and "mediate"
    the technology-specific Layer 2 specific address resolution procedures.

    In this draft, we specify the procedures procedures, which the PEs must
    implement in order to mediate the IP address resolution mechanism.
    We call these procedures "ARP Mediation".

    Consider a Virtual Private Wire Service (VPWS) constructed between
    CE1 and CE2 in the diagram above.  If AC1 and AC2 are of different
    technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR),
    then ARP requests coming from CE1 cannot be passed transparently to
    CE2.  PE1 must interpret the meaning of the ARP requests and
    mediate the necessary information with PE2 before responding.

    2.0 ARP Mediation (AM) function

    The ARP Mediation (AM) function is an element of a PE node
    operation  that
    deals with the IP address resolution for CE devices connected via a
    an L2VPN. By placing this function in the PE node, ARP Mediation can be made completely is
    transparent to the CE devices.

    For a given point-to-point connection between a pair of CEs, a PE
    must perform three logical steps as part of the ARP Mediation
    procedure:

      1. Discover the IP addresses of the locally attached CE device

 Shah, et. al.           Expires September 2005                       3 
                 draft-ietf-l2vpn-arp-mediation-01.txt

      2. Distribute those IP Addresses to the remote PE

 Shah, et. al.             Expires April 2005                         3 
                 draft-ietf-l2vpn-arp-mediation-00.txt
      3. Notify the locally attached CE of the remote CE's IP address.

    This information is gathered using the mechanisms described in the
    following sections.

    3.0 IP Layer 2 Interworking Circuits

    The IP Layer 2 Interworking Circuits refer to Pseudowires that
    carry IP datagram datagrams as the payload.  At ingress,  The ingress PE removes the data
    link header of
    an IP frame is removed its local Attachment Circuit and dispatched transmits the
    payload (an IP frame) over the Pseudowire with or without the
    optional control word. At the egress, The egress PE encapsulates the IP packet
    with the data link header used on the its local Attachment Circuit.

    The use of this IP Pseudowire encapsulation is determined by the exchange of
    value 0x000B as the PW type during Pseudowire establishment as described in [PWE3-Control]. [PWE3-IANA].

    4.0 Discovery of IP Addresses of Locally Attached CE Device

    An IP Layer 2 Interworking Circuit enters monitoring state right
    immediately  after the configuration. During this state it performs
    two functions.
       . Discovery of locally attached CE IP device
       . Establishment of the PW

    The establishment of the PW occurs independently from local CE IP
    address discovery. During the period when the (bi-directional) PW
    has been established but local CE IP device has not been detected,
    only datagrams inside of broadcast/multicast frames are propagated;
    IP datagrams inside unicast frames are dropped. The IP datagrams
    from unicast frames flow only when IP end systems on both
    Attachment Circuits have been discovered, notified and proxy
    functions have completed.

    4.1 Monitoring Local Traffic

    The PE devices may learn the IP addresses of the locally attached
    CEs from any IP traffic, such as link local multicast (e.g. 224.x.x.x)
    packets, that CE may generate irrespective of reacting packets
    (e.g., destined to specific
    address resolution queries described 224.0.0.x), and are not restricted to the
    operations below.

    4.2 CE Devices Using ARP

    If a CE device uses ARP to determine the MAC address to IP address
    binding of its neighbor, the PE processes the ARP requests to learn
    the IP address of local CE for the stated locally attached circuit.
    If we observe the strict topology restriction whereby only one IP

 Shah, et. al.             Expires April 2005                         4 
                 draft-ietf-l2vpn-arp-mediation-00.txt
    router CE can exist for a given attachment circuit then the PE can

 Shah, et. al.           Expires September 2005                       4 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    assume that ARP request received is from the candidate IP CE and
    can learn the IP to MAC address binding of the local CE.

    However, if this topology restriction is relaxed, the PE can learn
    the MAC address to IP address binding of the local CE but can not
    assume that this CE (possibly amongst many) is the candidate IP
    device that is to be interworked with the remote attachment
    circuit. In these circumstances, this case, the PE may select the local CE device using
    following criteria.

      .  Wait to learn the IP address of the remote CE (through PW
         signaling) and then select the local CE that is sending the
         ARP request for the remote CEĂs IP address.
      .   Augment cross checking with the local IP address learned
         through listening of link local multicast packets (as per
         section 4.1 above)
      .   Augment cross checking with the local IP address learned
         through the Router Discovery protocol (as described below in
         section 4.5).
      .   There is still a possibility that the local PE may not receive
         an IP address advertisement from the remote PE and there may
         exist multiple local IP routers that attempt to 'connect' to
         remote CEs. In this situation, the local PE may use some arbitrary other
         criteria to select one IP device from many (such as ˘the first
         ARP
         received), received÷), or have an operator may configure the IP address of
         local CE. Note that the operator does not have to configure
         the
         MAC address of the local CE as that would be learned through
         ARP mechanisms described above nor the IP address of the remote CE as (as that would be learned
         through Pseudowire
         signaling described later in this document. signaling).

    Once the local CE has been discovered for the given attachment
    circuit, Attachment
    Circuit, the local PE responds to the subsequent ARP requests from that
    device with the its own MAC address of his own. address. The local PE signals the CEĂs IP
    address to the remote PE and may initiate the an unsolicited ARP
    response as a means to notify local CE, the IP CE MAC address to MAC  IP address binding of
    the remote, in order to facilitate remote CE. Once this is completed, unicast traffic between two CEs.
    CEs can start flowing.

    The PE may periodically generate ARP request messages to the CE's
    IP address as a means to verify of verifying the continued existence of the
    address and its binding to the stated 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. The local PE and entering would then enter into the address
    resolution phase to rediscover the attached CE's IP address. Note
    that such this "heartbeat" scheme is needed only for broadcast links, as a
    the loss of a CE may otherwise be undetectable.

 Shah, et. al.             Expires April 2005                         5 
                 draft-ietf-l2vpn-arp-mediation-00.txt

    4.3 CE Devices Using Inverse ARP

 Shah, et. al.           Expires September 2005                       5 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    If a CE device uses Inverse ARP to determine the IP address of its
    neighbor, the attached PE processes the Inverse ARP request for
    stated circuit and 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 circuit 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 about the IP address of the remote CE.

    This is a typical operation for Frame Relay and ATM attachment
    circuits. In the cases where When the CE does not use Inverse ARP, PE could still
    discover the CE local CEĂs IP address as described in section 4.1 and
    4.5.

    4.4 CE Devices Using PPP

    When a PPP link becomes operational after the LCP negotiations, the
    local PE performs following action actions
       . If the local PE does not know the IP address of the local CE,
         it generates a configure-request without the configure IP
         address TLV. The response from CE is accepted as IP address of
         the local CE.
       . If PE knows the IP address of the remote CE, it sends an IPCP
         configure-request with the IP address of the remote CE in the
         configure IP address TLV
       . If the local PE receives an IPCP configure-request without the
         configure IP address TLV, and if it knows the IP address of
         the remote CE, it responds with configure NAK with the
         configure IP address TLV set with remote CEĂs IP address.
         However, if PE does not know the remote CEĂs IP address yet,
         it responds with a configure NAK.
       . If the local PE does not know the IP address of the remote CE,
         it sends an IPCP configure-request with IP address as zero.
         The response from CE is recorded and used to validate the
         incoming remote CEĂs IP address via PW signaling.

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

    4.5 Proactive Router Discovery method

    In order to learn the IP address of the CE device for a given
    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.

 Shah, et. al.           Expires April September 2005                       6 
                 draft-ietf-l2vpn-arp-mediation-00.txt 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    The use of the router discovery mechanism Router Discovery method by the PE is optional.

    5.0 CE IP Address Distribution Between PE Signaling between PEs

    5.1 When To Distribute to Signal a CEĂs IP Address

    A PE device advertises the IP address of the attached CE only when
    the encapsulation type of the Pseudowire is IP L2 interworking
    (0x0B). . It
    is quite possible that the IP address of a CE device is not
    available at the time the PW labels are advertised. signaled. For example, in
    Frame Relay the CE device dispatches sends an inverse ARP request only when
    the DLCI is active; if the PE signals the DLCI to be active only
    when it has received the IP address along with the
    PW-FEC PW FEC from the
    remote PE, a chicken and egg situation arises. In order to avoid
    such problems, the PE must be prepared to advertise the PW-FEC PW FEC
    before the CE's IP address is known. When the IP address of the CE
    device does become available, the PE re-advertises the
    PW-FEC PW FEC along
    with the IP.

    Similarly, if the PE detects invalidation of the  a CE's IP address
    (by is no longer
    valid(by methods described above) above), the PE must re-advertise the PW-FEC PW
    FEC with null IP address to denote the withdrawal of the CE's IP
    address. The receiving PE then waits for the notification of the remote
    IP address. During this period, propagation of unicast IP traffic
    is suspended while continuing to let suspended, but multicast IP traffic can continue to flow.

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

    5.2 LDP Based Distribution

    The [PWE3-CONTROL] uses Label Distribution Protocol (LDP) transport
    to exchange PW-FEC PW FEC in the Label Mapping message in a downstream
    unsolicited the Downstream
    Unsolicited (DU) mode. The PW-FEC PW FEC comes in two flavors; Pwid PWid and
    Generalized ID FEC elements and shares have some fields that are  common fields between
    them. The discussions below refer to these common fields for IP L2
    Interworking Circuits.

    The IP L2 Interworking uses an IP datagram as payload over the
    Pseduowire. The use of such encapsulation is identified by PW type
    field of the PW-FEC as the value 0x000B [PWE3-Control].
    Pseudowire[PWE3-IANA].

    In addition, this document defines an IP address TLV that must be
    included in the as an optional TLV field of parameter in the  Label Mapping message

 Shah, et. al.             Expires April 2005                         7 
                 draft-ietf-l2vpn-arp-mediation-00.txt
    when advertising PW-FEC the PW FEC for the IP L2 Interworking Circuit. Such The
    use of optional TLV parameters in the Label Mapping message to extend
    the attributes of the PW-FEC has also been PW FEC is specified in the [PWE3-
    Control]. [PWE3-Control].

 Shah, et. al.           Expires September 2005                       7 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    When processing a received PW-FEC, PW FEC, the PE matches the PW-Id PW Id and PW- PW
    type with the locally configured PW-Id PW Id to determine if the PW-FEC PW FEC
    is of type IP L2 Interworking. If matched, there is a match, it further
    checks the presence of IP address TLV. optional parameter. If an IP address TLV is absent, a
    Label Release message is issued to reject the PW establishment.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|  IP address TLV (TBD)     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         IP Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The Length field optional parameter of the Label Mapping message is defined as the
    follows.

    Optional Parameter   type    length of the    value
    IP address           TBD      04       CEĂs IP address and is
    set to value 4.

    The IP address field is set to value null to denote that
    advertising PE has not learned the IP address of his local CE
    device. The non-zero value of the IP address field denotes IP
    address of advertising PEĂs attached CE device.

    The CEĂs IP address TLV is also used supplied in the LDP notification optional parameter
    field of the LDPĂs Notification message along with the PW-FEC. PW FEC. The IP address TLV in
    LDP Notification message is used as an update mechanism to notify signal the changes change in the CEĂs IP
    address of the local CE device as described in [SHAH-CONTROL].
    address.

    5.3 Out-of-band Distribution, Manual Distribution Configuration

    In some cases, it may not be possible either to deduce the IP
    addresses from the VPN traffic nor induce remote PEs to supply the
    necessary information on demand.  For those cases, out-of-band
    methods, such as manual configuration, could  MAY be used.  The use of these types of
    methods is useful only to handle corner cases.

    5.4 Single sided ARP mediation

    In this configuration, one PE device treats the Pseudowire as a
    homogeneous circuit, while the other PE device treats it as a
    heterogenous circuit. For example, if PE1 is connected to an
    Ethernet Attachment Circuit and PE2 is connected to an ATM
    Attachment Circuit, PE1 and PE2 would both treat the Pseudowire as

 Shah, et. al.             Expires April 2005                         8 
                 draft-ietf-l2vpn-arp-mediation-00.txt

    of type Ethernet.  From PE1's point of view, the circuit is
    homogeneous, since the Attachment Circuit and the Pseudowire are
    both Ethernet. Hence PE1 does no ARP mediation. From PE2's point of
    view, the circuit is heterogeneous, so PE2 performs ARP mediation.
    That is,

            o PE2 signals to PE1 that the PW Type is Ethernet,
            o PE2 learns the IP address of remote CE from Ethernet
              frames received over the PW,
            o PE2 learns the IP address of locally attached ATM CE,
            o PE2 proxies the IP address of each CE to the other,
            o PE2 decapsulates the ATM data link header and
              reencapsulates with an Ethernet header before forwarding
              the IP data frames from its local CE over the PW.  The
              information used to build the Ethernet data link header
              is obtained through ARP mediation functions.  Similar
              header manipulation is performed when Ethernet IP frames
              are forwarded to ATM Attachment Circuit,
            o Drop all non IP Ethernet frames received over Ethernet
              PW.

    The above example show how single sided ARP mediation would work
    when Pseudowire is Ethernet. However, the choice of Pseudowire type
    and which side performs the ARP mediation functions is largely
    dictated by the existing network topology and how this service is
    rolled out. The single sided architecture is not restricted to a
    specific Pseudowire type.

    In summary, single sided configuration handles ARP mediation as PE
    would typically when managing two locally attached heterogenous
    Attachment Circuits.
    6.0 How a CE Learns The the Remote CE's IP address

    Once the local 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.

    6.1 CE Devices Using ARP

    When the PE learns the remote CE's IP address as described in
    section 5.1 and 5.2, 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 until it is acquired through one of the methods described in
    sections 4.1, 4.3 and 4.5. If the IP address of the local CE is
    known, the PE may choose to 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.

 Shah, et. al.             Expires April 2005                         9 
                 draft-ietf-l2vpn-arp-mediation-00.txt

    When the local CE generates an ARP request, the PE must proxy the
    ARP response using its own MAC address as the source hardware

 Shah, et. al.           Expires September 2005                       8 
                 draft-ietf-l2vpn-arp-mediation-01.txt

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

    6.2 CE Devices Using Inverse ARP

    When the PE learns the remote CE's IP address, it should generate
    an Inverse ARP request. In case, the local circuit requires
    activation e.g. Frame Relay, PE should activate it first before
    sending Inverse ARP request. It should be noted, that PE might
    never receive the response to its own request, nor see any CE's
    Inverse ARP request in cases where CE is pre-configured with remote
    CE IP address or the use of Inverse ARP is not enabled. In either
    case CE has used other means to learn the IP address of his
    neighbor.

    6.3 CE Devices Using PPP

    When the PE learns the remote CE's IP address, it should initiate
    the Configure-Request using the remote CE's IP address or respond
    to pending Configure-Request from the local CE. As noted earlier,
    all other configuration options related to compression,
    encryptions, etc., should be rejected.

    7.0 Use of IGPs with IP L2 Interworking L2VPNs

    In an IP L2 interworking L2VPN, 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.

    7.1 OSPF

    The OSPF protocol treats a 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 L2VPN has the potential to may experience connectivity issues.

 Shah, et. al.             Expires April 2005                        10 
                 draft-ietf-l2vpn-arp-mediation-00.txt

    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

 Shah, et. al.           Expires September 2005                       9 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    an OSPF router on the point-to-point link further adds to the
    confusion.

    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.

    7.2 IS-IS

    The IS-IS RIP

    RIP protocol sends a LAN Hello PDU (IIH packet) with broadcasts RIP advertisements every 30 seconds. If the MAC
    group/broadcast address and 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 intermediate system (i.e., CE
    device) when attached to Ethernet links. advertisement. No special
    configuration is required for RIP in this type of Layer 2 IP
    Interworking L2VPN.

    8.0 Security Considerations

    The CE device expects its
    neighbor security aspect of this solution is addressed for two planes;
    control plane and data plane.

    8.1 Control plane security

    The control plane security pertains to insert its own MAC establishing the LDP
    connection, Pseudowire establishment and CEĂs IP address in the response. If
    distribution. The LDP connection between two trusted PEs can be
    achieved by each PE verifying the neighbor is connected via a point-to-point link type, incoming connection against the LAN
    Hello PDU will be silently discarded. Similarly, Hello PDUs on
    configured peerĂs address and authenticating the
    point-to-point link LDP messages using
    MD5 authentication. The Pseudowire establishments between two
    secure LDP peers 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 pose security issue but mis-wiring could
    occur due to configuration error. Some checks, such as, proper
    Pseudowire type and other Pseudowire options may prevent mis-wiring
    due to configuration errors.

    The learning of the IS-IS protocol on appropriate CEĂs IP address can be a security
    issue. It is expected that the local attachment circuit to CE devices presents problems is
    physically secured. If this is a concern, the PE must be configured
    with CEĂs IP and MAC address when interconnected by disparate data link types in an connected with Ethernet or CEĂs
    IP L2
    Interworking VPN environment.  There are some mechanisms defined in
    draft-ietf-isis-igp-p2p-over-lan-00.txt and virtual circuit information (e.g. DLCI or VPI/VCI). During
    each ARP/inARP frame processing, PE must verify the received
    information against the configuration before accepting to accommodate point-to-
    point behavior over broadcast networks. protect
    against hijacking the connection.

 Shah, et. al.           Expires September 2005                      10 
                 draft-ietf-l2vpn-arp-mediation-01.txt

    8.2 Data plane security

    The feasibility of such
    techniques to solve this problem data traffic between CE and PE is under review.

    It not encrypted and it is important to note
    possible that the use of the IS-IS protocol in
    enterprise networks (i.e., an insecure environment, a malicious user may tap
    into the CE routers) is less common. The IS-IS
    related difficulties for IP L2 Interworking VPNs, hence are
    minimized.

    7.3 RIP

    RIP protocol broadcasts RIP advertisements every 30 seconds. If to PE connection and generate traffic using the
    group/broadcast spoofed
    destination MAC address snooping mechanism is used as described
    above, on the attached Ethernet Attachment Circuit. In
    order to avoid such hijacking, local PE can learn may verify the advertising (CE) router's IP source MAC
    address from the IP header of the advertisement. No special
    configuration is required for RIP in this type received frame against the MAC address of Layer 2 IP
    Interworking L2VPN.

 Shah, et. al.             Expires April 2005                        11 
                 draft-ietf-l2vpn-arp-mediation-00.txt

    8.0 Security Considerations the
    admitted connection. The security aspects of this solution will be discussed at a later
    time. frame is forwarded to PW only when
    authenticity is verified. When spoofing is detected, PE must severe
    the connection with the local CE, tear down the PW and start over.

    9.0 Acknowledgements

    The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce
    Lasley and other folks who participated in the discussions related
    to this draft.

    10.0 References

    10.1 Normative References

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

    [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution
    Protocol".

    10.2 Informative References

    [L2VPN-REQ] W. Augustyn et al., "Service Requirements for Layer 2
    Provider Provisioned Virtual Private Networks", February 2003, work
    in progress.

    [L2VPN-FRM] L. Andersson et al., "L2VPN Framework", January 2003, "Framework for L2VPN", June 2004,
    work in progress.

    [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
    Control Protocol (IPCP)".

    [L2VPN-Kompella] K. Kompella et al., "Layer 2 VPNs Over Tunnels",
    June 2002, work in progress.

    [PWE3-CONTROL] L. Martini et al., "Transport of Layer 2 Frames Over
    MPLS", November 2002, "Pseudowire Setup and Maintenance
    using LDP", February 2005, work in progress.

    [L2VPN-Signaling] E. Rosen

    [PWE3-IANA] L. Martini et al., "LDP-based Signaling al,. ˘IANA Allocations for
    L2VPNs", September 2002, pseudo Wire
    Edge to Edge Emulation (PWE3)÷, February 2005, work in progress.

 Shah, et. al.           Expires September 2005                      11 
                 draft-ietf-l2vpn-arp-mediation-01.txt

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

    [SHAH-CONTROL] H. Shah et al., ˘Dynamic Parameters Signaling for
    MPLS-based Pseudowires÷, June 2003, work in progress

 Shah, et. al.             Expires April 2005                        12 
                 draft-ietf-l2vpn-arp-mediation-00.txt

    11.0 Authors' Addresses

    Himanshu Shah
    35 Nagog Park,
    Acton, MA 01720
    Email: hshah@ciena.com

    Eric Rosen
    Cisco Systems
    1414 Massachusetts Avenue,
    Boxborough, MA 01719
    Email: erosen@cisco.com

    Waldemar Augustyn
    Email: waldemar@nxp.com

    Giles Heron
    PacketExchange Ltd.
    The Truman Brewery
    91 Brick Lane
    LONDON E1 6QL
    United Kingdom
    Email: giles@packetexchange.net giles@tellabs.com

    Sunil Khandekar and Vach Kompella
    Alcatel
    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
    Axiowave Network
    Marlboro, MA 01720

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

 Shah, et. al.             Expires April 2005                        13 
                 draft-ietf-l2vpn-arp-mediation-00.txt

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

    Vasile Radoaca
    Nortel Networks
    Email: vasile@nortelnetworks.com vasile@westridgenetworks.com

 Shah, et. al.           Expires September 2005                      12 
                 draft-ietf-l2vpn-arp-mediation-01.txt

  IPR Notice

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights. Information on the
    IETFĂs procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11. Copies of
    claims of rights made available for publication and any assurances
    of licenses to be made available, or the result of an attempt made
    to obtain a general license or permission of such proprietary
    rights by implementers or users of this specification can be
    obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.

  Full Copyright Statement
    Copyright (C) The Internet Society (2004).  This document is
    subject
    to the rights, licenses and restrictions contained in BCP 78 and
    except as set forth therein, the authors retain all their rights.

    This document and the information contained herein are provided on
    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
    ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 Shah, et. al.           Expires April September 2005                        14                      13