[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-shah-l2vpn-arp-mediation) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6575

  L2VPN Working Group                H. Shah                  Ciena Corp
  Internet Draft                     E. Rosen              Cisco Systems
                                     G. Heron                    Tellabs
  July 2005                          V. Kompella                 Alcatel
  Expires: January 2006






           ARP Mediation for IP Interworking of Layer 2 VPN

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


  Status of this memo

  By submitting this Internet-Draft, we certify that any applicable
  patent or other IPR claims of which we are aware have been
  disclosed, or will be disclosed, and any of which we become aware
  will be disclosed, in accordance with RFC 3668.

  This document is an Internet-Draft and is in full conformance with
  Sections 5 and 6 of RFC3667 and Section 5 of RFC3668.

  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.

IPR Disclosure Acknowledgement

  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 Section 6 of BCP 79.

  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 pseudo-wire (connecting the
    two PEs).  In general, the Attachment Circuits must be of the same
    technology (e.g., both Ethernet, both ATM), and the pseudo-wire
    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
    pseudo-wire connects Attachment Circuits of different technologies.
    This requires the PEs to perform a function known as "ARP
    Mediation".  ARP Mediation refers to the process of resolving Layer
    2 addresses when different resolution protocols are used on either 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    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 not addressed as IS-IS
    PDUs are not sent over IP.


     Table of Contents

    1 .0 Contributing Authors........................................2
    2 .0 Introduction................................................3
    3 .0 ARP Mediation (AM) function.................................4
    4 .0 IP Layer 2 Interworking Circuit.............................4
    5 .0 Discovery of IP Addresses of Locally Attached CE Device.....4
    5.1 Monitoring Local Traffic.....................................5
    5.2 CE Devices Using ARP.........................................5
    5.3 CE Devices Using Inverse ARP.................................6
    5.4 CE Devices Using PPP.........................................7
    5.5 Router Discovery method......................................7
    6 .0 CE IP Address Signaling between PEs.........................8
    6.1 When to Signal a CE's IP Address.............................8
    6.2 LDP Based Distribution.......................................8
    6.3 Out-of-band Distribution Configuration.......................9
    7 .0 How a CE Learns the Remote CE's IP address..................9
    7.1 CE Devices Using ARP.........................................9
    7.2 CE Devices Using Inverse ARP................................10
    7.3 CE Devices Using PPP........................................10
    8 .0 Use of IGPs with IP L2 Interworking L2VPNs.................10
    8.1 OSPF........................................................10
    8.2 RIP.........................................................11
    9 .0 Security Considerations....................................11
    9.1 Control plane security......................................11
    9.2 Data plane security.........................................12
    10 .0 Acknowledgements..........................................12
    11 .0 References................................................12
    11.1 Normative References.......................................12
    11.2 Informative References.....................................13
    12 .0 Authors' Addresses........................................13

    1.0 Contributing Authors
    This document is the combined effort of the following individuals
    and many others who have carefully reviewed the document and
    provided the technical clarifications.

            W. Augustyn              consultant

 Shah, et. al.            Expires January 2006                        2 
                 draft-ietf-l2vpn-arp-mediation-02.txt

            T. Smith            Laurel Networks
            A. Moranganti     Big Band Networks
            S. Khandekar                Alcatel
            A. Malis                    Tellabs
            S. Wright                Bell South
            V. Radoaca       Westridge Networks
            A. Vishwanathan    Force10 Networks


    2.0 Introduction

    Layer 2 Virtual Private Networks (L2VPN) are constructed 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  Layer 3 protocol is IP.
    Thus it makes sense to consider procedures that are  optimized for
    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
    L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both
    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 2 connection between them, even though each AC uses a
    different Layer 2 technology, the PEs must intercept and "mediate"
    the Layer 2 specific address resolution procedures.


 Shah, et. al.            Expires January 2006                        3 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    In this draft, we specify the 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.

    3.0 ARP Mediation (AM) function

    The ARP Mediation (AM) function is an element of a PE node  that
    deals with the IP address resolution for CE devices connected via
    an L2VPN. By placing this function in the PE node, ARP Mediation 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
      2. Distribute those IP Addresses to the remote PE
      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.

    4.0 IP Layer 2 Interworking Circuit

    The IP Layer 2 interworking Circuit refers to interconnection of
    the Attachment Circuit with the IP Layer 2 Transport pseudo-wire
    that carries IP datagrams as the payload.  The ingress PE removes
    the data link header of its local Attachment Circuit and transmits
    the payload (an IP frame) over the pseudo-wire with or without the
    optional control word. In some cases, multiple data link headers
    may exist, such as bridged PDU on ATM AC. In this case, ATM header
    as well as the Ethernet header is removed to expose the IP frame.
    The egress PE encapsulates the IP packet with the data link header
    used on its local Attachment Circuit.

    The encapsulation for the IP Layer 2 Transport pseudo-wire is
    described in [PWE3-Control].

    5.0 Discovery of IP Addresses of Locally Attached CE Device


 Shah, et. al.            Expires January 2006                        4 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    An IP Layer 2 Interworking Circuit enters monitoring state
    immediately  after the configuration is enabled. 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 PW has been
    established but local CE IP device has not been detected, only
    broadcast/multicast IP frames are propagated between the Attachment
    Circuit and pseudo-wire; unicast IP datagrams are dropped. On
    Ethernet AC, MAC Destination Address is used to classify
    unicast/multicast packets. However, on non-Ethernet ACs, IP
    destination address is used to classify unicast/multicast packets.
    The unicast IP frames are propagated between AC and pseudo-wire
    only when CE IP devices on both Attachment Circuits have been
    discovered, notified and proxy functions have completed.

    5.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 packets
    (e.g., destined to 224.0.0.x), and are not restricted to the
    operations below.

    5.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
    router CE can exist for a given AC then the PE can 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 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 5.1 above)

 Shah, et. al.            Expires January 2006                        5 
                 draft-ietf-l2vpn-arp-mediation-02.txt

      .   Augment cross checking with the local IP address learned
         through the Router Discovery protocol (as described below in
         section 5.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 other
         criteria to select one IP device from many (such as "the first
         ARP received"), or an operator may configure the IP address of
         local CE. Note that the operator does not have to configure
         the IP address of the remote CE (as that would be learned
         through pseudo-wire signaling).

    Once the local CE has been discovered for the given Attachment
    Circuit, the local PE responds to subsequent ARP requests from that
    device with its own MAC address when the destination IP address in
    the ARP request is found to match with the remote CE's IP address.
    The local PE signals the CE's IP address to the remote PE and may
    initiate an unsolicited ARP response to notify local CE MAC address
    to  IP address binding of the remote CE. Once the ARP mediation
    function is completed, unicast IP frames are propagated between the
    AC and the established PW.

    The PE may periodically generate ARP request messages to the CE's
    IP address as a means of verifying the continued existence of the
    address and its binding to the MAC address. The absence of a
    response from the CE device for a given number of retries could be
    used as a cause for withdrawal of the IP address advertisement to
    the remote PE. The local PE would then enter into the address
    resolution phase to rediscover the attached CE's IP address. Note
    that this "heartbeat" scheme is needed only for broadcast links
    (such as Ethernet AC), as the loss of a CE may otherwise be
    undetectable.

    5.3 CE Devices Using Inverse ARP

    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. When the CE does not use Inverse ARP, PE could still

 Shah, et. al.            Expires January 2006                        6 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    discover the local CE's IP address as described in section 5.1 and
    5.5.

    5.4 CE Devices Using PPP

    The IP Control Protocol (IPCP) describes a procedure to establish
    and configure IP on a point-to-point connection, including the
    negotiation of IP addresses. When using IP (Routed) mode L2VPN
    interworking, PPP negotiation is not performed end-to-end between
    CE devices. In this case, PPP negotiation takes place between the
    CE device and its local PE device (on the PPP attachment circuit).
    The PE device performs proxy PPP negotiation, and informs the local
    CE device of the IP address of the remote CE device during IPCP
    negotiation using the IP-Address option [0x03].

    When a PPP link becomes operational after the LCP negotiations, the
    local PE MAY perform following actions

    . The PE learns the IP address of the local CE from the Configure-
      Request received with the IP-Address option (0x03). The PE
      verifies that the IP address present in the IP-Address option is
      non-zero. If the IP address is zero, PE responds with Configure-
      Reject (as this is a request from CE to assign him an IP
      address). Also, the Configure-Reject copies the IP-Address option
      with null value to instruct the CE to not include that option in
      new Configure-Request. If the IP address is non-zero, PE responds
      with Configure-Ack.
    . If the PE receives Configure-Request without the IP-Address
      option, PE responds with Configure-Ack. In this case, PE would
      not learn the IP address of the local CE using IPCP and hence
      would rely on other means as described above (such as link-local
      broadcast from OSPF hello). Note that in order to employ other
      learning mechanisms, IPCP connection must be open.
    . If the PE does not know the IP address of the remote CE, it
      generates a Configure-Request without the IP-Address option.
    . If the PE knows the IP address of the remote CE, it sends an IPCP
      Configure-Request with the IP-Address option containing the
      remote CE's IP address.

    The IPCP IP-Address option MAY be negotiated between the PE and the
    local CE device. Configuration of other IPCP option MAY be
    rejected. Other NCPs, with the exception of the Compression Control
    Protocol (CCP) and Encryption Control Protocol (ECP), MUST be
    rejected. The PE device MAY reject configuration of the CCP and
    ECP.


    5.5 Router Discovery method


 Shah, et. al.            Expires January 2006                        7 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    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. It is possible that the response contains more than one router
    addresses with the same preference level; in which case, some
    heuristics (such as first on the list) is necessary.

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

    6.0 CE IP Address Signaling between PEs

    6.1 When 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 pseudo-wire is IP Layer2 Transport
    (the value 0x0000B, as defined in [PWE3-IANA]). It is quite
    possible that the IP address of a CE device is not available at the
    time the PW labels are signaled. For example, in Frame Relay the CE
    device 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 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 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 along with the CE's IP
    address.

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

    If two CE devices are locally attached to the PE where one CE is
    connected to an Ethernet port and the other to a Frame Relay 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.

    6.2 LDP Based Distribution

    The [PWE3-Control] uses Label Distribution Protocol (LDP) transport
    to exchange PW FEC in the Label Mapping message in the Downstream
    Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and

 Shah, et. al.            Expires January 2006                        8 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    Generalized ID FEC elements and has some common fields between
    them. The discussions below refer to these common fields for IP L2
    Interworking Circuits.

    In addition to PW-FEC, this document defines an IP address TLV that
    must be included in the optional parameter field of the  Label
    Mapping message when advertising the PW FEC for the IP Layer2
    Transport. The  use of optional parameters in the Label Mapping
    message to extend the attributes of the PW FEC is specified in the
    [PWE3-Control].

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

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

    Optional Parameter   type    length    value
    IP address           TBD      04       CE's IP address

    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 is also supplied in the optional parameter
    field of the LDP's Notification message along with the PW FEC. The
    LDP Notification message is used to signal the change in CE's IP
    address.

    6.3 Out-of-band 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,  MAY be used.

    7.0 How a CE Learns 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.

    7.1 CE Devices Using ARP


 Shah, et. al.            Expires January 2006                        9 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    When the PE learns the remote CE's IP address as described in
    section 6.1 and 6.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 5.1, 5.3 and 5.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.

    When the local CE generates an ARP request, the PE must proxy the
    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 address. An exception
    to this rule is when the strict topology of one IP end station per
    Attachment Circuit is assumed. In which case, PE can promiscuously
    respond to the CE's ARP request with his own MAC address.

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

    7.3 CE Devices Using PPP

    When the PE learns the remote CE's IP address, it should initiate
    the Configure-Request and set the IP-Address option to the remote
    CE's IP address to notify local CE the IP address of the remote CE.

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

    8.1 OSPF


 Shah, et. al.            Expires January 2006                       10 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    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 may experience connectivity issues.

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


    8.2 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 L2VPN.

    9.0 Security Considerations

    The security aspect of this solution is addressed for two planes;
    control plane and data plane.

    9.1 Control plane security

    The control plane security pertains to establishing the LDP
    connection, pseudo-wire establishment and CE’s IP address
    distribution. The LDP connection between two trusted PEs can be
    achieved by each PE verifying the incoming connection against the
    configured peer’s address and authenticating the LDP messages using
    MD5 authentication. The pseudo-wire establishments between two
    secure LDP peers do not pose security issue but mis-wiring could
    occur due to configuration error. Some checks, such as, proper

 Shah, et. al.            Expires January 2006                       11 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    pseudo-wire type and other pseudo-wire options may prevent mis-
    wiring due to configuration errors.

    The learning of the appropriate CE's IP address can be a security
    issue. It is expected that the local attachment circuit to CE is
    physically secured. If this is a concern, the PE must be configured
    with CE's IP and MAC address when connected with Ethernet or CE's
    IP 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 protect
    against hijacking the connection.

    9.2 Data plane security

    The data traffic between CE and PE is not encrypted and it is
    possible that in an insecure environment, a malicious user may tap
    into the CE to PE connection and generate traffic using the spoofed
    destination MAC address on the Ethernet Attachment Circuit. In
    order to avoid such hijacking, local PE may verify the source MAC
    address of the received frame against the MAC address of the
    admitted connection. The 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.

    10.0 Acknowledgements

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

    11.0 References

    11.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".

    [PWE3-Control] L. Martini et al., "Pseudowire Setup and Maintenance
    using LDP", February 2005, work in progress.


    [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire
    Edge to Edge Emulation (PWE3)", February 2005, work in progress.



 Shah, et. al.            Expires January 2006                       12 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    11.2 Informative References


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

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


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


    12.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
    Email: giles.heron@tellabs.com

    Sunil Khandekar and Vach Kompella
    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


    Andrew G. Malis

 Shah, et. al.            Expires January 2006                       13 
                 draft-ietf-l2vpn-arp-mediation-02.txt

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

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

    Vasile Radoaca
    Email: vasile@westridgenetworks.com


    Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights 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; nor does it represent that
    it has made any independent effort to identify any such rights.
    Information on the procedures with respect to rights in RFC
    documents can be found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use
    of such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository
    at http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at ietf-
    ipr@ietf.org.

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    or will be disclosed, and any of which I become aware will be
    disclosed, in accordance with RFC 3668.


  Full Copyright Statement

    Copyright (C) The Internet Society (2005).

    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

 Shah, et. al.            Expires January 2006                       14 
                 draft-ietf-l2vpn-arp-mediation-02.txt

    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 January 2006                       15


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/