[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         Himanshu Shah                    Ciena Corp
     Internet Draft                Eric Rosen                   Cisco System
                                  Giles Heron                        Tellabs
                                 Vach Kompella                       Alcatel
     
     
     June 2006
     Expires: December 2006
     
     
     
                 ARP Mediation for IP Interworking of Layer 2 VPN
                      draft-ietf-l2vpn-arp-mediation-05.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.
     
     Abstract
     
     
     
     
     Shah et al              Expires December  2006                 [Page 1]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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 (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 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
     
        IPR Disclosure Acknowledgement.........Error! Bookmark not defined.
        1. Contributing Authors...........................................3
        2. Introduction...................................................4
        3. ARP Mediation (AM) function....................................5
        4. IP Layer 2 Interworking Circuit................................5
        5. Discovery of IP Addresses of Locally Attached CE Device........6
           5.1. Monitoring Local Traffic..................................6
           5.2. CE Devices Using ARP......................................6
           5.3. CE Devices Using Inverse ARP..............................8
           5.4. CE Devices Using PPP......................................8
           5.5. Router Discovery method...................................9
        6. CE IP Address Signaling between PEs...........................10
           6.1. When to Signal an IP address of a CE.....................10
           6.2. LDP Based Distribution...................................10
           6.3. Out-of-band Distribution Configuration...................12
     
     
     Shah et al              Expires December  2006                 [Page 2]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        7. IANA Considerations...........................................13
           7.1. LDP Status messages......................................13
        8. How a CE Learns the Remote CE's IP address....................13
           8.1. CE Devices Using ARP.....................................13
           8.2. CE Devices Using Inverse ARP.............................14
           8.3. CE Devices Using PPP.....................................14
        9. Use of IGPs with IP L2 Interworking L2VPNs....................14
           9.1. OSPF.....................................................14
           9.2. RIP......................................................15
        10. IPV6 Considerations..........................................15
        11. Multi-Segment PW consideration...............................15
        12. Security Considerations......................................16
           12.1. Control plane security..................................16
           12.2. Data plane security.....................................17
        13. Acknowledgements.............................................17
        14. References...................................................17
           14.1. Normative References....................................17
           14.2. Informative References..................................18
        15. Authors' Addresses...........................................18
        Intellectual Property Statement..................................19
        Disclaimer of Validity...........................................20
        Copyright Statement....................Error! Bookmark not defined.
     
     
     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
        A. Vishwanathan    Force10 Networks
     
     
     
     Shah et al              Expires December  2006                 [Page 3]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
     2. 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 [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.
     
     
     
     Shah et al              Expires December  2006                 [Page 4]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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".
     
        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. 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 three logical steps as part of the ARP Mediation
        procedure:
     
        1. Discover the IP addresses of the locally attached CE device
        2. Terminate, do not distribute ARP and Inverse ARP requests from CE
           device(s) at local PE.
        3. Distribute those IP Addresses to the remote PE
        4. 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. 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
     
     
     Shah et al              Expires December  2006                 [Page 5]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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. Discovery of IP Addresses of Locally Attached CE Device
     
        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 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
     
     
     
     Shah et al              Expires December  2006                 [Page 6]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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.
        This document mandates that only one CE per attachment circuit MUST
        be connected to the PE. However, customer facing access topology may
        exist whereby more than one CEs appear to be connected to the PE on
        a single attachment circuit. For example this could be 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 PE may optionally use following selection
        criteria. In either case, manual configuration of local CE’s IP
        address (and MAC address) MUST be supported.
     
        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 the remote CE's IP address.
        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 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
     
     
     Shah et al              Expires December  2006                 [Page 7]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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
        discover the IP address of local CE as 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].
     
        When a PPP link becomes operational after the LCP negotiations, the
        local PE MAY perform following actions
     
     
     
     Shah et al              Expires December  2006                 [Page 8]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        o  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.
        o  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.
        o  If the PE does not know the IP address of the remote CE, it
           generates a Configure-Request without the IP-Address option.
        o  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
     
        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.
     
     
     
     Shah et al              Expires December  2006                 [Page 9]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
     
     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 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 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 CE's IP address.
     
        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 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
        Generalized ID FEC elements and has some common fields between them.
        The discussions below refer to these common fields for IP L2
        Interworking encapsulation.
     
     
     
     Shah et al              Expires December  2006                [Page 10]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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 TLV in the optional parameter
        field. If absent, a Label Release message is issued with a Status
        Code meaning "IP Address of the CE is absent" [note: Status Code
        0x0000002C 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 TLV must be included in the
        optional parameter field of the Label Mapping message.
     
        Encoding of the IP Address 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            |     CE's IP Address           ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~       CE's IP Address         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Length
          When Address Family is IPV4, Length is equal to 6 bytes; 2 bytes
          for address family and 4 bytes of IP address.
     
        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.
     
        CE's IP Address
          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:
     
     
     Shah et al              Expires December  2006                [Page 11]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
     
                    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 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.
     
        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 TLV (as defined above)        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 PWId FEC or Generalized ID FEC                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Status TLV status code is set to 0x0000002B "IP address of CE",
        to indicate that IP Address update follows. Since this notification
        does not refer to any particular message the 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
     
     
     
     Shah et al              Expires December  2006                [Page 12]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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 the local CE’s IP address is mandatory.
     
     
     7. IANA Considerations
     
     7.1. LDP Status messages
     
        This document uses new LDP status codes, IANA already maintains a
        registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The
        following values are suggested for assignment:
     
                  0x0000002B "IP Address of CE"
                  0x0000002C "IP Address of CE is absent"
     
     
     8. 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.
     
     
     8.1. CE Devices Using ARP
     
        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 [PROXY-ARP] 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
     
     
     Shah et al              Expires December  2006                [Page 13]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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.
     
     
     8.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.
     
     
     8.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.
     
     
     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 adjacencies. However, these procedures are neither
     
     
     Shah et al              Expires December  2006                [Page 14]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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.
     
     
     9.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.
     
     
     10. IPV6 Considerations
     
        The support for IPV6 is not addressed in this draft and is for
        future study.
     
     
     11. Multi-Segment PW consideration
     
        In a back-to-back configuration, when two PEs are connected with an
        Ethernet, ARP proxy function has limited application, as there is no
        local CE. Consider a network configuration whereby PE1 in network A
        is connected to CE1 and PE4 in network B is connected to CE2. The
        PE2 on network A is connected to PE3 in network B directly with an
        Ethernet. Since there is no CE present between PE2 and PE3, there
     
     
     Shah et al              Expires December  2006                [Page 15]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        needs a mechanism for PE2 and PE3 to discover each other’s MAC
        address to enable connectivity between CE1 and CE2 across the two
        networks. There are two options.
          . Configure CE2’s IP address as a local CE’s IP address at PE2
             and CE1’s IP address as local CE’s IP address 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 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’s) network.
          . The second option is to follow the procedures recommended in
             [MS-PW] architecture, which provides the intervening or
             switching PEs to remain oblivious to native PW processing. We
             recommend this option.
     
     
     12. Security Considerations
     
        The security aspect of this solution is addressed for two planes;
        control plane and data plane.
     
     
     12.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
        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
     
     
     Shah et al              Expires December  2006                [Page 16]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        ARP/inARP frame processing, PE must verify the received information
        against the configuration before accepting 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.
     
     
     13. 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.
     
     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] 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.
     
     
     Shah et al              Expires December  2006                [Page 17]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        [MS-PW] M.Bocci et al,. "An Architecture for Multi-Segment Pseudo
                Wire Emulation Edge-to-Edge", May 2006, work in progress
        [RFC 1700] Reynolds and Postel, "Assigned Numbers".
        [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
                requirement levels".
     
     
     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".
     
     
     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
     
        Giles Heron
        Email: giles.heron@tellabs.com
     
        Sunil Khandekar and Vach Kompella
     
     
     Shah et al              Expires December  2006                [Page 18]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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
        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.
     
     
     
     Shah et al              Expires December  2006                [Page 19]
     

                     Draft-ietf-l2vpn-arp-mediation-05.txt              2006
     
        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.
     
     
     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.
     
     
        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.
     
     
     Shah et al              Expires December  2006                [Page 20]
     

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