L2VPN Working Group                 Himanshu Shah  Ciena Corp Networks
     Internet Draft                         Eric Rosen    Cisco System
                                           Giles Heron         Tellabs
                                         Vach Kompella         Alcatel
     Expires: December

     August 2006
     Expires: February 2007

               ARP Mediation for IP Interworking of Layer 2 VPN
                    draft-ietf-l2vpn-arp-mediation-06.txt
                    draft-ietf-l2vpn-arp-mediation-07.txt

     Status of this Memo

     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

     This Internet-Draft will expire on December 2006.

     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.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     Abstract

     The VPWS service [L2VPN-FRM] 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 pseudowire (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
     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 pseudo-wire pseudowire 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 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.

     Conventions used in this document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described
     in [RFC 2119].

     Table of Contents

        1. Contributing Authors........................................3 Authors......................................3
        2. Introduction................................................3 Introduction..............................................4
        3. ARP Mediation (AM) function.................................5 function...............................5
        4. IP Layer 2 Interworking Circuit.............................5 Circuit...........................5
        5. Discovery of IP Addresses of Locally Attached CE Device.....5 Device...6
           5.1. Monitoring Local Traffic...............................6 Traffic.............................6
           5.2. CE Devices Using ARP...................................6 ARP.................................6
           5.3. CE Devices Using Inverse ARP...........................8 ARP.........................8
           5.4. CE Devices Using PPP...................................8 PPP.................................8
           5.5. Router Discovery method................................9 method..............................9
           5.6. Manual Configuration................................10
                  Draft-ietf-l2vpn-arp-mediation-07.txt

        6. CE IP Address Signaling between PEs.........................9 PEs......................10
           6.1. When to Signal an IP address of a CE...................9
                  Draft-ietf-l2vpn-arp-mediation-06.txt CE................10
           6.2. LDP Based Distribution................................10
           6.3. Out-of-band Distribution Configuration................12 Distribution..............................11
        7. IANA Considerations........................................12 Considerations......................................13
           7.1. LDP Status messages...................................12 messages.................................13
        8. How a CE Learns the IP address of a remote CE................13 CE............13
           8.1. CE Devices Using ARP..................................13 ARP................................13
           8.2. CE Devices Using Inverse ARP..........................13 ARP........................14
           8.3. CE Devices Using PPP..................................14 PPP................................14
        9. Use of IGPs with IP L2 Interworking L2VPNs.................14 L2VPNs...............14
           9.1. OSPF..................................................14 OSPF................................................14
           9.2. RIP...................................................15 RIP.................................................15
           9.3. IS-IS...............................................15
        10. IPV6 Considerations.......................................15 Considerations.....................................15
        11. Multi-Segment PW consideration............................15 Multi-domain considerations.............................15
        12. Security Considerations...................................16 Considerations.................................16
           12.1. Control plane security...............................16 security.............................17
           12.2. Data plane security..................................16 security................................17
        13. Acknowledgements..........................................17 Acknowledgements........................................17
        14. References................................................17 References..............................................18
           14.1. Normative References.................................17 References...............................18
           14.2. Informative References...............................17 References.............................18
        15. Authors' Addresses........................................18 Addresses......................................19
        Intellectual Property Statement...............................19 Statement.............................20
        Disclaimer of Validity........................................19 Validity......................................20

     1. 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
     T. Smith            Laurel Networks
     A. Moranganti     Big Band Networks
     S. Khandekar                Alcatel
     A. Malis                    Tellabs
     S. Wright                Bell South
     V. Radoaca       Westridge Networks               consultant
     A. Vishwanathan    Force10 Networks
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     2. Introduction
                  Draft-ietf-l2vpn-arp-mediation-06.txt

     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 [ARP] and
     a FR-attached CE might use Inverse ARP [INVARP].  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.

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

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     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
                  Draft-ietf-l2vpn-arp-mediation-06.txt
     requests and mediate the necessary information with PE2 before
     responding.

     3. 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 VPWS 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 the following logical steps as part of the ARP
     Mediation procedure:

        1. Discover the IP address of the locally attached CE device
        2. Terminate, do not distribute ARP and Inverse ARP requests
           from CE device at local PE.
        3. Distribute those IP Addresses to the remote PE
        4. Notify the locally attached CE, CE of the IP address of the
           remote CE.
     This information is gathered using the mechanisms described in
     the following sections.

     4. 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 pseudowire
     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) packet) over the pseudo-wire pseudowire with or
     without the optional control word. In some cases, multiple data
     link headers may exist, such as bridged Ethernet PDU on ATM AC.
     Attachment Circuit. In this case, ATM header as well as the
     Ethernet header is removed to expose the IP frame. packet at the
     ingress. The egress PE encapsulates the IP packet with the data
     link header used on its local Attachment Circuit.

                  Draft-ietf-l2vpn-arp-mediation-07.txt

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

     5. Discovery of IP Addresses of Locally Attached CE Device
                  Draft-ietf-l2vpn-arp-mediation-06.txt

     An IP Layer 2 Interworking Circuit enters monitoring state
     immediately after the configuration. During this state it
     performs two functions.

        o  Discovery of locally attached CE IP device
        o  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 the local CE IP device has not been detected, discovered,
     only broadcast/multicast IP frames are propagated between the
     Attachment Circuit and pseudo-wire; pseudowire; unicast IP datagrams are
     dropped. On Ethernet AC, MAC Destination Address is used to
     classify unicast/multicast packets. However, on non-Ethernet
     ACs, The IP destination address is used to classify
     unicast/multicast packets.

     The unicast IP frames are propagated between AC and pseudo-wire pseudowire
     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 IP address to IP MAC
     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. local
     Attachment Circuit.

     This document mandates that there MUST be only one CE per attachment circuit
     MUST be connected to the PE.
     Attachment Circuit. However, customer facing access
     topology topologies
     may exist whereby more than one CEs appear CE appears to be connected to
     the PE on a single attachment circuit. Attachment Circuit. For example this could be
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     the case when CEs are connected to a shared LAN that connects to
     the PE. In such case, the PE MUST select one local CE. The
     selection could be based on manual configuration or the PE may
     optionally use following selection criteria. In either case,
     manual configuration of IP address of the local CE (and its MAC
     address) MUST be supported.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

        o  Wait to learn the IP address of the remote CE (through PW
           signaling) and then select the local CE that is sending
           the request for IP address of the remote CE.
        o  Augment cross checking with the local IP address learned
           through listening of link local multicast packets (as per
           section 5.1 above)
        o  Augment cross checking with the local IP address learned
           through the Router Discovery protocol (as described below
           in section 5.5).
        o  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 pseudowire
           signaling).

     Once the local CE and remote CEs 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 to any subsequent ARP requests from the local CE with a
     destination IP address in matching the ARP request is found to match with IP address of the remote CE.

     The local PE signals IP address of the CE to the remote PE and
     may initiate an unsolicited ARP response to notify local CE MAC the IP
     address to IP MAC address binding of for the remote CE. CE to local CE
     (again using its own MAC address).

     Once the ARP mediation function is completed, completed (i.e. the PE device
     knows both the local and remote CE IP addresses), unicast IP
     frames are propagated between the AC and the established PW.

     The PE may periodically generate ARP request messages to for the IP
     address of the CE as a means of verifying the continued
     existence of the address and its binding to the MAC address. address binding. The
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     absence of a response from the CE device for a given number of
     retries could be used as a cause trigger for withdrawal of the IP
     address advertisement to the remote PE. The local PE would then
     enter into
     re-enter the address resolution phase to rediscover the IP
     address of the attached CE. Note that this "heartbeat" scheme is
     needed only for broadcast links (such as Ethernet AC), as where the
     loss
     failure of a CE device may otherwise be undetectable.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     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
     from the Attachment Circuit and responds with an Inverse ARP
     reply containing the IP address of the remote CE, if the address
     is known. If the PE does not yet have the IP address of the
     remote CE, 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 of notifying the IP address
     of the remote CE to the local CE.

     This is a the typical mode of operation for Frame Relay and ATM attachment
     circuits. When
     Attachment Circuits. If the CE does not use Inverse ARP, the PE could
     can still discover the IP address of local CE as using the
     mechanisms described in section 5.1 and 5.5

     5.4. CE Devices Using PPP

     The IP Control Protocol [PPP-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]. (0x03).

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

                  Draft-ietf-l2vpn-arp-mediation-07.txt

        o  The PE learns the IP address of the local CE from the
           Configure- Request
           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 Configure-Reject (as this is a request
           from CE to assign him it an IP address). Also, the Configure-
           Reject copies the IP-Address option with null a zero 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.

                  Draft-ietf-l2vpn-arp-mediation-06.txt
        o  If the PE receives Configure-Request without the IP-
           Address option, PE it responds with a Configure-Ack. In this
           case,
           case the PE would not is unable to learn the IP address of the local
           CE using IPCP and hence would must rely on other means as
           described above (such as link-local broadcast from OSPF
           hello). in sections 5.1 and 5.5. Note that in order to
           employ other learning mechanisms, the IPCP connection negotiations
           must be open. have reached the open state.
        o  If the PE does not know the IP address of the remote CE,
           it generates sends a Configure-Request without the IP-Address
           option.
        o  If the PE knows the IP address of the remote CE, it sends
           an IPCP
           a Configure-Request with the IP-Address option containing
           the IP address of the remote CE.

     The IPCP IP-Address option MAY be negotiated between the PE and
     the local CE device. Configuration of other IPCP option options 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

     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. CE IP Address Signaling between PEs

     6.1. When

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     5.6. Manual Configuration

     In some cases, it may not be possible to Signal discover the IP address
     of the local CE device using the mechanisms described in section
     5 above. In such cases manual configuration MAY be used. All
     implementations of this draft MUST support manual configuration
     of the IP address of the local CE.

     6. CE IP Address Signaling between PEs

     6.1. When to Signal an IP address of a CE

     A PE device advertises the IP address of the attached CE only
     when the encapsulation type of the pseudo-wire pseudowire 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
                  Draft-ietf-l2vpn-arp-mediation-06.txt
     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 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 IP address of the CE is known and hence uses
     IP address value zero. When the IP address of the CE device does
     become available, the PE re-advertises the PW FEC along with the
     IP address of the CE.

     Similarly, if the PE detects that an IP address of a CE 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 IP address of the CE. 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. pseudowire.

     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.

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     6.2. LDP Based Distribution

     The [PWE3-Control]

     [RFC 4447] uses Label Distribution Protocol (LDP) transport to
     exchange PW FEC FECs in the Label Mapping message in the Downstream
     Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and
     Generalized ID FEC elements and has some common fields between
     them. The discussions below refer to these common fields for IP
     L2 Interworking encapsulation.

     In addition to PW-FEC, this document defines an IP address list
     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 [RFC 4447].

     As defined in [RFC 4447], when processing a received PW FEC, the
     PE matches the PW Id ID and PW type with the locally configured PW Id to determine if the
     ID and PW
     FEC is of type IP Layer2 Transport. Type. If there is a match, it and if the PW Type is IP
     Layer2 Transport the PE further checks for the presence of IP address an
     Address List TLV (as specified in [RFC 3036]) in the optional
     parameter field. TLVs. If absent, a Label Release message is issued
                  Draft-ietf-l2vpn-arp-mediation-06.txt
     with a Status Code meaning "IP Address of the CE is absent"
     [note: Status Code 0x0000002C 0x0000002D is pending IANA allocation] to
     reject the PW establishment.

     We use the Address List TLV as defined in RFC 3036 to signal the
     IP address of the local CE. This IP address list TLV must be
     included in the optional parameter field of the Label Mapping message.
     message, and MUST contain exactly one address of family IPv4.

     Encoding of the IP Address List TLV is:

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0| Address List (0x0101)     |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Address Family            |     IP Address of CE          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~      IP Address of CE         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Length
          When Address Family is IPV4, Length is equal to 6 bytes; 2
          bytes for address family and 4 bytes of IP address.

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     Address Family
          Two octet quantity containing a value from the ADDRESS
          FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 1700]
          that encodes the address contained in the Address field.

     IP Address of CE
          IP address of the CE attached to the advertising PE.  The
          encoding of the individual address depends on the Address
          Family.

     The following address encodings are defined by this version of
     the protocol:

                    Address Family      Address Encoding

                    IPv4 (1)             4 octet full IPv4 address
                    IPv6 (2)             16 octet full IPv6 address

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

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     The IP address of the CE is also supplied in the optional
     parameter
     parameters field of the LDP's LDP Notification message along with the
     PW FEC. The LDP Notification message is used to signal the any
     change in the status of the CE's IP address.

     The encoding of the LDP Notification message is 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|   Notification (0x0001)     |      Message Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message ID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Status (TLV)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 IP Address List TLV (as defined above)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 PWId FEC or Generalized ID FEC                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The Status TLV status code is set to 0x0000002B 0x0000002C "IP address of
     CE", to indicate that IP Address update follows. Since this
     notification does not refer to any particular message the
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     Message Id, and Message Type fields are set to 0. [note: Status
     Code 0x0000002B is pending IANA allocation].

     The PW FEC TLV SHOULD not include the interface parameters as
     they are ignored in the context of this message.

     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. The
     support for manual configuration of IP address of the local CE
     is mandatory.

     7. IANA Considerations

     7.1. LDP Status messages
                  Draft-ietf-l2vpn-arp-mediation-06.txt

     This document uses new LDP status codes, IANA already maintains
     a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. RFC 3036.
     The following values are suggested for assignment:

        0x0000002B

        0x0000002C "IP Address of CE"
        0x0000002C
        0x0000002D "IP Address of the CE is absent"

     8. How a CE Learns the IP address of a remote CE

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

     8.1. CE Devices Using ARP

     When the PE learns IP address of the remote CE as described in
     section 6.1 and 6.2, it may or may not already know IP address
     of the local CE. If the 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 5.2 and 5.5. If 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 IP address of
     the remote CE with the PE's own MAC address.

     When the local CE generates an ARP request, the PE must proxy
     the ARP response [PROXY-ARP] using its own MAC address as the
     source hardware address and IP address of remote CE as the
     source protocol address. The PE must respond only to those ARP
     requests whose destination protocol address matches the IP
     address of the remote CE. 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 ARP
     request of the CE with his own MAC address.

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     8.2. CE Devices Using Inverse ARP

     When the PE learns the IP address of the remote CE, it should
     generate an Inverse ARP request. In case, If the local circuit Attachment Circuit
     requires activation e.g. (e.g. Frame Relay, Relay) the PE should activate it
     first before sending the 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 from the CE, in cases where CE is pre-
     configured with remote CE IP address of the remote CE or where the use of
     Inverse ARP
     is has not been enabled. In either case the CE has used
     other means to learn the IP address of his neighbor.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     8.3. CE Devices Using PPP

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

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

     9.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 each other router on the link 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. two cross-connected routers.

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     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 which believes itself to be connected to a 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.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     9.2. RIP

     RIP protocol broadcasts RIP advertisements every 30 seconds. If
     the group/broadcast address multicast/broadcast traffic snooping mechanism is used as
     described above, in section 5.1, the attached PE can learn the advertising (CE) local CE
     router's IP address from the IP header of the advertisement. its advertisements. No
     special configuration is required for RIP in this type of Layer
     2 IP Interworking L2VPN.

     9.3. IS-IS

     The IS-IS protocol does not encapsulate its PDUs in IP, and
     hence cannot be supported in IP L2 Interworking L2VPNs.

     10. IPV6 Considerations

     The support for IPV6 is not addressed in this draft and is for
     future study.

     11. Multi-Segment PW consideration Multi-domain considerations

     In a back-to-back configuration, when two PEs are connected with
     an
     Ethernet, the ARP proxy function has limited application, application as
     there is no local CE.
                                   |
               Network A           |         Network B
     CE-1 <---> PE-1 <---> PE-2 <===> PE-3 <---> PE-4 <---> CE-2
           ATM        LDP        ETH        LDP        ETH
                      PW-1                   PW-2
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     Consider a Multi-Segment Pseudo-wire
     consisting of two pseudo-wire segments; Multi-domain network topology as shown above where PW
     segment 1 (PE1<->PE2) is in network A and PW segment 2 (PE3<->PE4) (PE3<->
     PE4) is in network B. In this configuration CE1 is connected to
     PE1 and CE2 is connected to PE4. The PE2 on network A is directly
     connected to PE3 in network B with an Ethernet. Since there is no CE present between
     PE2 and PE3, In this
     configuration there needs to be a mechanism for PE2 and PE3 to discover
     each others MAC address to enable connectivity between CE1 and
     CE2 across
     learn IP addresses of the CEs present in each otherís network.
     The two networks. There options to do this are two options. as follows.

        o  Configure CE2ís IP address of CE2 as a local CEís IP address of local CE at
           PE2 and CE1ís IP address of CE1 as local CEís IP address of local CE at PE3.
           Additionally, PE2 and PE3 are required to generate ARP
           requests using their own MAC addresses as the source
           address. These PEs are in effect proxying for CEs present
           in the each others otherís network. This is not a desirable
           option as it requires configuration of IP address of a CE
           that is present in others (possibly other service
           provider)
           providerís) network.
        o  The  In the second option is option, PE2 and PE3 use gratuitous ARP which
           eliminates configuration of IP addresses of the CEs. In
           this scheme, when PE2 learns the IP address of CE1
           (through LDP signaling), PE2 sends a gratuitous ARP to follow PE3
           with the procedures recommended source and destination IP address field set to
           CE1ís IP address and the source MAC address field set to
           PE2ís MAC address. When PE3 learns the IP address of CE1
           (from the gratuitous ARP), PE3 notifies PE4 of the IP
           address of the CE1 through LDP signaling. Similarly, for
           the traffic in [MS-PW] architecture, which provides the intervening or
           switching PEs opposite direction, when PE3 learns the
           IP address of CE2, it sends a gratuitous ARP to remain oblivious PE2. PE2
           sends an IP address notification, via LDP, of CE2ís IP
           address to native PW processing.
           We recommend this option. Note this may mean creating a
           third PW segment between PE1 using the same procedures described above.
           This allows PE2 and PE3 for to dynamically learn the example shown IP
           addresses of the CEs present in each otherís networks.
           This is the preferred mode of operation as compared to the
           option 1 above.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     12. Security Considerations

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

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     12.1. Control plane security

     The control

     Control plane security pertains to establishing the LDP
     connection, pseudo-wire establishment and CE's to pseudowire signaling and CE IP address
     distribution.
     distribution over that LDP connection. The LDP connection
     between two trusted PEs can be achieved by each PE verifying the
     incoming connection against the configured address of the peer
     and authenticating the LDP messages using MD5 authentication. The pseudo-wire
     establishments
     Pseudowire signaling between two secure LDP peers do not pose
     security issue but mis-wiring could occur due to configuration
     error. Some checks, such as, proper pseudo-wire pseudowire type and other pseudo-
     wire
     pseudowire options may prevent mis-wiring due to configuration
     errors.

     The learning of

     Learning the IP address of the appropriate CE can be a security
     issue. It is expected that the local attachment circuit Attachment Circuit to the local
     CE is will be physically secured. If this is a concern, the PE must
     be configured with IP and MAC address of the CE when connected
     with Ethernet or IP and virtual circuit information (e.g. DLCI (DLCI or VPI/VCI) of the CE.
     VPI/VCI when connected over Frame Relay or ATM and IP address
     only when connected over PPP). During each ARP/inARP frame
     processing, the PE must verify the received information against the
     local configuration before accepting forwarding the information to the
     remote PE to protect against hijacking the connection.

     12.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 sever the connection with the local CE, tear down the PW
     and start over.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     13. Acknowledgements

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

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     14. References

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

        [RFC 4447]  L. Martini et al., "Pseudowire Setup and
                       Maintenance using LDP", RFC 4447.
        [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo
                   Wire Edge to Edge Emulation (PWE3)", RFC 4446.
        [RFC 1700] Reynolds and Postel, "Assigned Numbers".
        [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
                   requirement levels"
        [RFC 3036] L.Anderssen et al., "LDP Specification"

     14.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".
        [RFC 1256] S.Deering, "ICMP Router Discovery Messages".

                  Draft-ietf-l2vpn-arp-mediation-06.txt
        [MS-PW] M.Bocci et al,. "An Architecture for Multi-Segment
                Pseudo  Wire Emulation Edge-to-Edge", May 2006, work
                in progress
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     15. 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 waldemar@wdmsys.com

     Giles Heron
     Tellabs
     24-28 Easton Steet
     High Wycombe
     Bucks
     HP11 1NT
     UK
     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,
     Network Appliance, Inc.
     800 Cranberry Woods Drive
     Suite 300
     Cranberry Township, PA 15205
     Email: jsmith@laurelnetworks.com 16066
     EMail: tob@netapp.com

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

     Andrew G. Malis
     Tellabs
     2730 Orchard Parkway
     San Jose, CA 95134
                  Draft-ietf-l2vpn-arp-mediation-06.txt

     Email:
     1415 West Diehl Road
                  Draft-ietf-l2vpn-arp-mediation-07.txt

     Naperville, IL 60563
     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.

                  Draft-ietf-l2vpn-arp-mediation-06.txt

     Disclaimer of Validity

     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.

                  Draft-ietf-l2vpn-arp-mediation-07.txt

     Copyright Statement

     Copyright (C) The Internet Society (2006).  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.