[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
     Intended Status: Proposed Standard    Eric Rosen    Cisco System
     Internet Draft                       Giles Heron British Telecom
                                        Vach Kompella  Alcatel-Lucent
     
     February 2009
     Expires: August 2009
     
     
     
               ARP Mediation for IP Interworking of Layer 2 VPN
                    draft-ietf-l2vpn-arp-mediation-10.txt
     
     Status of this Memo
     
     This Internet-Draft is submitted to IETF in full conformance
     with the provisions of BCP 78 and BCP 79.
     
     This memo provides information for the Internet community.  It
     does not specify an Internet standard of any kind. Distribution
     of this memo is unlimited.
     
     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 BCP 78 and
     BCP 79.
     
     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/1id-abstracts.html
     
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html
     
     
     
     
     Shah et al             Expires August 2009               [Page 1]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     This Internet-Draft will expire on August 28, 2009.
     
     Copyright and License Notice
     
     Copyright (c) 2009 IETF Trust and the persons identified as the
     document authors.  All rights reserved.
     
     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date of
     publication of this document. Please review these documents
     carefully, as they describe your rights and restrictions with
     respect to this document.
     
     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 pseudowire (connecting
     the two PEs).  In general, the Attachment Circuits must be of
     the same technology (e.g., both Ethernet, both ATM), and the
     pseudowire must carry the frames of that technology.  However,
     if it is known that the frames' payload consists solely of IP
     datagrams, it is possible to provide a point-to-point connection
     in which the pseudowire 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.
     
     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........................................4
     
     
     Shah et al               Expires August 2009       [Page 2]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
        2. Introduction................................................4
        3. ARP Mediation (AM) function.................................5
        4. IP Layer 2 Interworking Circuit.............................6
        5. IP Address Discovery Mechanisms.............................7
           5.1. Discovery of IP Addresses of Locally Attached IPv4 CE
           Devices.....................................................8
              5.1.1. Monitoring Local Traffic..........................8
              5.1.2. CE Devices Using ARP..............................8
              5.1.3. CE Devices Using Inverse ARP......................9
              5.1.4. CE Devices Using PPP.............................10
              5.1.5. Router Discovery method..........................11
              5.1.6. Manual Configuration.............................11
           5.2. How a CE Learns the IPv4 address of a remote CE.......11
              5.2.1. CE Devices Using ARP.............................11
              5.2.2. CE Devices Using Inverse ARP.....................12
              5.2.3. CE Devices Using PPP.............................12
           5.3. Discovery of IP Addresses of IPv6 CE Devices..........12
              5.3.1. Distinguishing factors between IPv4 and IPv6.....12
              5.3.2. Requirements for PE..............................13
              5.3.3. Processing of Neighbor Solicitations.............13
              5.3.4. Processing of Neighbor Advertisements............14
              5.3.5. Processing of Inverse Neighbor Solicitations.....14
              5.3.6. Processing of Inverse Neighbor Advertisements....15
              5.3.7. Processing of Router Solicitations...............16
              5.3.8. Processing of Router Advertisements..............16
              5.3.9. Duplicate Address Detection [RFC 4862]...........16
              5.3.10. Manual Configuration............................17
        6. CE IP Address Signaling between PEs........................17
           6.1. When to Signal an IP address of a CE..................17
           6.2. LDP Based Distribution................................18
           6.3. Dual-Stack support....................................21
        7. IANA Considerations........................................22
           7.1. LDP Status messages...................................22
        8. Use of IGPs with IP L2 Interworking L2VPNs.................22
           8.1. OSPF..................................................23
           8.2. RIP...................................................23
           8.3. IS-IS.................................................23
        9. Multi-domain considerations................................24
        10. Security Considerations...................................25
           10.1. Control plane security...............................25
           10.2. Data plane security..................................26
        11. Acknowledgements..........................................26
        12. References................................................26
           12.1. Normative References.................................26
           12.2. Informative References...............................27
        13. Authors' Addresses........................................28
        Full Copyright Statement......................................29
        Intellectual Property.........................................29
     
     
     Shah et al               Expires August 2009       [Page 3]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     
     
     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. Malis                    Tellabs
     S. Wright                Bell South
     T. Grigoriu          Alcatel-Lucent
     N. Hart              Alcatel-Lucent
     A. Dolganow          Alcatel-Lucent
     S. Amante                    Level3
     
     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 |...........
     
     
     Shah et al               Expires August 2009       [Page 4]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
                    .     +-----+          .
                    .        |             .
                    .        |             .
     +-----+ 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 IPv4 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".
     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.
     
     The draft uses "ARP" terminology to mean any protocol that is
     used to resolve IP address to Link Layer address association
     purposes. For instance in IPv4, ARP and InvArp protocols are
     used for address resolution while in IPv6 Neighbor Discovery and
     Inverse Neighbor Discovery protocol based on ICMPv6 is used for
     address resolution.
     
     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, the
     ARP Mediation procedure depends whether the packets being
     
     
     Shah et al               Expires August 2009       [Page 5]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     forwarded are IPv4 or IPV6. A PE that is to perform ARP
     Mediation for IPv4 packets must perform the following logical
     steps:
     
        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 the IP Address to the remote PE using
           pseudowire control signaling.
        4. Notify the locally attached CE of the IP address of the
           remote CE.
        5. Respond appropriately to ARP and Inverse ARP requests from
           local CE device, using IP address of remote CE and
           hardware address of local PE.
     
     A PE that is to perform ARP Mediation for IPv6 packets must
     perform the following logical steps:
     
       1. Discover the IPv6 addresses of the locally attached CE device,
          together with those of the remote CE device.
       2. Intercept Neighbor Discovery and Inverse Neighbor Discovery
          packets received from the local CE device, learning
          information about the IPv6 configuration of the CE, before
          forwarding the packets across the VPWS to the remote PE.
       3. Intercept Neighbor Discovery and Inverse Neighbor Discovery
          packets received over the VPWS from the remote PE, possibly
          modifying them (if required for the type of outgoing AC)
          before forwarding to the local CE, and also learning
          information about the IPv6 configuration of the remote CE.
     
     Details for the above-described procedures are given 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 pseudowire
     
     
     Shah et al               Expires August 2009       [Page 6]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     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 packet) over the pseudowire with or
     without the optional control word. In some cases, multiple data
     link headers may exist, such as bridged Ethernet PDU on ATM
     Attachment Circuit. In this case, ATM header as well as the
     Ethernet header is removed to expose the IP packet at the
     ingress. 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 pseudowire is
     described in [RFC4447]. The "IP Layer 2 interworking circuit"
     pseudowire is also commonly referred to as "IP pseudowire".
     
     In the case of an IPv6 L2 Interworking Circuit, the egress PE
     may modify the contents of Neighbor Discovery or Inverse
     Neighbor Discovery packets before encapsulating the IP packet
     with the data link header.
     
     5. IP Address Discovery Mechanisms
     An IP Layer 2 Interworking Circuit enters monitoring state
     immediately after the configuration. During this state it
     performs two functions.
     
        - Discovery of the CE IP device(s)
        - 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 discovered,
     only broadcast/multicast IP frames are propagated between the
     Attachment Circuit and pseudowire; unicast IP datagrams are
     dropped. The IP destination address is used to classify
     unicast/multicast packets.
     
     The unicast IP frames are propagated between AC and pseudowire
     only when CE IP devices on both Attachment Circuits have been
     discovered, notified and proxy functions have completed.
     
     The need to wait for address resolution completion before the
     unicast IP traffic can flow is simple.
        . PEs do not perform routing operations
        . Destination IP address in the packet is not necessarily
          that of the attached CE
     
     
     Shah et al               Expires August 2009       [Page 7]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
        . On a broadcast link, there is no way to find out the MAC
          address of the CE based on the Destination IP address of
          the packet.
     
     5.1. Discovery of IP Addresses of Locally Attached IPv4 CE Devices
     
     5.1.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.1.2. CE Devices Using ARP
     
     If a CE device uses ARP to determine the IP address to MAC
     address binding of its neighbor, the PE processes the ARP
     requests to learn the IP address of local CE for the local
     Attachment Circuit.
     
     This document mandates that there MUST be only one CE per
     Attachment Circuit. However, customer facing access topologies
     may exist whereby more than one CE appears 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 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.
     
        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.1 above)
        o  Augment cross checking with the local IP address learned
           through the Router Discovery protocol (as described below
           in section 5.1.5).
     
     
     Shah et al               Expires August 2009       [Page 8]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
        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 pseudowire
           signaling).
     
     Once the local and remote CEs has been discovered for the given
     Attachment Circuit, the local PE responds with its own MAC
     address to any subsequent ARP requests from the local CE with a
     destination IP address matching the 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 the IP
     address to MAC address binding for the remote CE to local CE
     (again using its own MAC address).
     
     Once the ARP mediation function is 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 for the IP
     address of the CE as a means of verifying the continued
     existence of the address and its MAC address binding. The
     absence of a response from the CE device for a given number of
     retries could be used as a trigger for withdrawal of the IP
     address advertisement to the remote PE. The local PE would then
     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), where the
     failure of a CE device may otherwise be undetectable.
     
     5.1.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
     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
     
     
     Shah et al               Expires August 2009       [Page 9]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     address of the remote CE becomes available, the PE may initiate
     the Inverse ARP request as a means of notifying the IP address
     of the remote CE to the local CE.
     
     This is the typical mode of operation for Frame Relay and ATM
     Attachment Circuits. If the CE does not use Inverse ARP, the PE
     can still discover the IP address of local CE using the
     mechanisms described in section 5.1.1 and 5.1.5
     
     5.1.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 completes LCP negotiations, the local PE MAY
     perform the following IPCP actions:
     
        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 it an IP address). Also, the Configure-
           Reject copies the IP-Address option with 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.
        o  If the PE receives Configure-Request without the IP-
           Address option, it responds with a Configure-Ack. In this
           case the PE is unable to learn the IP address of the local
           CE using IPCP and hence must rely on other means as
           described in sections 5.1.1 and 5.1.5. Note that in order
           to employ other learning mechanisms, the IPCP negotiations
           must have reached the open state.
        o  If the PE does not know the IP address of the remote CE,
           it sends a Configure-Request without the IP-Address
           option.
     
     
     Shah et al               Expires August 2009       [Page 10]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
        o  If the PE knows the IP address of the remote CE, it sends
           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 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.1.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.
     
     5.1.6. Manual Configuration
     
     In some cases, it may not be possible to discover the IP address
     of the local CE device using the mechanisms described in section
     5.1 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.
     
     5.2. How a CE Learns the IPv4 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.
     
     5.2.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
     
     
     Shah et al               Expires August 2009       [Page 11]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     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.1, 5.1.2 and 5.1.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.
     
     5.2.2. CE Devices Using Inverse ARP
     
     When the PE learns the IP address of the remote CE, it should
     generate an Inverse ARP request. If the Attachment Circuit
     requires activation (e.g. Frame Relay) the PE should activate it
     first before the Inverse ARP request. It should be noted, that
     PE might never receive the response to its own request, nor see
     any Inverse ARP request from the CE, in cases where CE is pre-
     configured with IP address of the remote CE or where the use of
     Inverse ARP has not been enabled. In either case the CE has used
     other means to learn the IP address of his neighbor.
     
     5.2.3. CE Devices Using PPP
     
     When the PE learns the IP address of the remote CE, it should
     initiate a Configure-Request and set the IP-Address option to
     the IP address of the remote CE to notify the IP address of the
     remote CE to the local CE.
     
     
     5.3. Discovery of IP Addresses of IPv6 CE Devices
     
     5.3.1. Distinguishing factors between IPv4 and IPv6
     The IPv6 uses ICMPv6 extensions to resolve IP address and link
     address associations. These are essentially IP packets as
     compared to ARP and invARP in IPv4 which is a separate protocol
     and not IP packets. The IP pseudowire can not be used to carry
     the ARP/invARP packets and hence requires local processing of
     these PDUs and signaling IP address information between the PEs
     using the Pseudowire control plane.
     
     
     Shah et al               Expires August 2009       [Page 12]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     
     
     5.3.2. Requirements for PE
     
     Each PE device must be capable of intercepting ICMPv6 Neighbor
     Discovery [RFC 4861] packets, whether received over the AC or
     over the pseudowire, inspecting them to learn IPv6 interface
     addresses and CE link-layer addresses, possibly modifying these
     packets as required by Layer 2 of the AC and as described in the
     following sections, and then forwarding them towards the
     original destination. The PE must also be capable of generating
     packets in order to interwork between Neighbor Discovery and
     Inverse Neighbor Discovery [RFC 3122].
     The PE device must learn a list of CE IPv6 interface addresses
     for its directly-attached CE and another list of CE IPv6
     interface addresses for the far-end CE. The PE device must also
     learn the link-layer address of the local CE and be able to use
     it when forwarding traffic between the local and far-end CEs.
     The PE may also wish to monitor the source link-layer address of
     data packets received from the CE, and discard packets not
     matching its learned CE link-layer address.
     
     
     5.3.3. Processing of Neighbor Solicitations
     
     A Neighbor Solicitation received on an AC from a local CE SHOULD
     be inspected to determine and learn an IPv6 interface address
     (if provided - this will not be the case for Duplicate Address
     Detection) and any link-layer address provided. The packet MUST
     then be forwarded over the pseudowire unmodifiedA Neighbor
     Solicitation received over the pseudowire SHOULD be inspected to
     determine and learn an IPv6 interface address for the far-end
     CE. If a source link-layer address option is present, the PE
     MUST remove it. The PE MAY substitute an appropriate link-layer
     address option, specifying the link-layer address of the local
     AC. Note that if the local AC is Ethernet, failure to substitute
     a link-layer address option may mean that the CE has no valid
     link-layer address with which to transmit data packets.
     When a PE with a local AC of the type point-to-point link
     receives a Neighbor Solicitation over the pseudowire, after
     learning the far-end CE's IP address, the PE may use either of
     the following handling procedures:
     
     1. Forward the Neighbor Solicitation to the local CE after
     
     
     Shah et al               Expires August 2009       [Page 13]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     replacing the source link-layer address with the link-layer
     address of the local AC.
     2. Send an Inverse Neighbor Solicitation to the local CE,
     specifying the far-end CE's IP address and the link-layer
     address of the local AC.
     
     5.3.4. Processing of Neighbor Advertisements
     
     A Neighbor Advertisement received on an AC from a local CE
     SHOULD be inspected to determine and learn an IPv6 interface
     address and any link-layer address provided. The packet MUST
     then be forwarded over the pseudowire unmodified.
     
     A Neighbor Advertisement received over the pseudowire SHOULD be
     inspected to determine and learn an IPv6 interface address for
     the far-end CE. If a source link-layer address option is
     present, the PE MUST remove it. The PE MAY substitute an
     appropriate link-layer address option, specifying the link-layer
     address of the local AC. Note that if the local AC is Ethernet,
     failure to substitute a link-layer address option may mean that
     the local CE has no valid link-layer address with which to
     transmit data packets.
     
     When a PE with a local AC of the type point-to-point link
     receives a Neighbor Advertisement over the pseudowire, after
     learning the far-end CE's IP address, the PE may use either of
     the following handling procedures:
     
     1. Forward the Neighbor Advertisement to the local CE after
     replacing the source link-layer address with the link-layer
     address of the local AC.
     2. Send an Inverse Neighbor Advertisement to the local CE,
     specifying the far-end CE's IP address and the link-layer
     address of the local AC.
     
     
     5.3.5. Processing of Inverse Neighbor Solicitations
     
     An Inverse Neighbor Solicitation received on an AC from a local
     CE SHOULD be inspected to determine and learn an IPv6 interface
     address and the link-layer addresses. The packet may optionally
     contain a list of interface addresses for the local CE, and
     these SHOULD also be learned. The packet MUST then be forwarded
     over the pseudowire unmodified.
     
     An Inverse Neighbor Solicitation received over the pseudowire
     SHOULD be inspected to determine and learn one or more interface
     
     
     Shah et al               Expires August 2009       [Page 14]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     addresses for the far-end CE. If the local AC supports Inverse
     Neighbor Discovery (e.g., a Frame Relay AC), the packet may be
     forwarded to the local CE, after modifying the link-layer
     address options to match the type of the local AC.
     
     If the local AC does not support Inverse Neighbor Discovery
     (IND), processing of the packet depends on whether the PE has
     learned at least one interface address for its directly-attached
     CE. If it has learned at least one interface address for the CE,
     the PE MUST discard the Inverse Neighbor Solicitation (INS) and
     generate an Inverse Neighbor Advertisement (INA) back into the
     pseudowire. The destination address of the INA is the source
     address from the INS, the source address is one of the local
     interface addresses of the CE, and all the local interface
     addresses of the CE that have been learned so far SHOULD BE
     included in the Target Address List. The Source and Target
     Link-Layer addresses are copied from the INS. In addition, the
     PE should generate ND advertisement on the local AC using IP
     address of the remote CE and MAC address of the local PE.
     
     The INS MUST be discarded if the PE has not yet learned at least
     one interface address for its directly-connected CE. This
     processing continues until the PE learns an address from the
     local CE (through receiving, for example, a Neighbor
     Solicitation). After this has occurred, the PE will be able to
     respond to INS messages received over the pseudowire.
     
     5.3.6. Processing of Inverse Neighbor Advertisements
     
     An Inverse Neighbor Advertisement (INA) received on an AC from a
     local CE SHOULD be inspected to determine and learn one or more
     interface addresses for the CE. It MUST then be forwarded
     unmodified over the pseudowire.
     
     An INA received over the pseudowire SHOULD be inspected to
     determine and learn one or more interface addresses for the far-
     end CE.
     
     If the local AC supports Inverse Neighbor Discovery (e.g., a
     Frame Relay AC), the packet MAY be forwarded to the local CE,
     after modifying the link-layer address options to match the type
     of the local AC.
     
     If the local AC does not support Inverse Neighbor Discovery, the
     PE MUST discard the INA and generate a Neighbor Advertisement
     (NA) towards its local CE. The source address of the NA is the
     
     
     Shah et al               Expires August 2009       [Page 15]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     source address from the INA, the destination address is the
     destination address from the INA and the link-layer address is
     that of the local AC on the PE.
     
     5.3.7. Processing of Router Solicitations
     
     A Router Solicitation received on an AC from a local CE SHOULD
     be inspected to determine and learn an interface address for the
     CE, and, if present, the link-layer address of the CE. It MUST
     then be forwarded unmodified over the pseudowire.
     
     A Router Solicitation received over the pseudowire SHOULD be
     inspected to determine and learn an interface address for the
     far-end CE. If a source link-layer address option is present,
     the PE MUST remove it. The PE MAY substitute a source link-layer
     address option specifying the link-layer address of its local
     AC. The packet is then forwarded to the local CE.
     
     5.3.8. Processing of Router Advertisements
     
     A Router Advertisement received on an AC from a local CE SHOULD
     be inspected to determine and learn an interface address for the
     CE, and, if present, the link-layer address of the CE. It MUST
     then be forwarded unmodified over the pseudowire.
     
     A Router Advertisement received over the pseudowire SHOULD be
     inspected to determine and learn an interface address for the
     far-end CE. If a source link-layer address option is present,
     the PE MUST remove it. The PE MAY substitute a source link-layer
     address option specifying the link-layer address of its AC. If
     an MTU option is present, the PE MAY reduce the specified MTU if
     the MTU of the pseudowire is less than the value specified in
     the option. The packet is then forwarded to the local CE.
     
     5.3.9. Duplicate Address Detection [RFC 4862]
     
     Duplicate Address Detection allows IPv6 hosts and routers to
     ensure that the addresses assigned to interfaces are unique on a
     link. As with all Neighbor Discovery packets, those used in
     Duplicate Address Detection will simply flow through the
     pseudowire, being inspected at the PEs at each end. Processing
     
     
     Shah et al               Expires August 2009       [Page 16]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     is performed as above. However, the source address of Neighbor
     Solicitations used in Duplicate Address Detection is the
     unspecified address, so the PEs cannot learn the interface
     address of CE (nor would it make sense to do so, given that at
     least one address is tentative at that time).
     
     5.3.10. Manual Configuration
     
     In some cases, it may not be possible to discover the IP address
     of the local CE device using the mechanisms described in
     section 5.3. 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 IPv4 address of the attached CE only
     when the encapsulation type of the pseudowire is IP Layer2
     Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is
     quite possible that the IPv4 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 IPv4 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 IPv4 address of the CE is known and hence uses
     IPv4 address value zero. When the IPv4 address of the CE device
     does become available, the PE re-advertises the PW FEC along
     with the IPv4 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 IPv4 traffic is suspended, but multicast
     IPv4 traffic can continue to flow between the AC and the
     pseudowire.
     
     
     
     Shah et al               Expires August 2009       [Page 17]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     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 IPv4 addresses are learned in the same
     manner described above. However, since the CE devices are local,
     the distribution of IPv4 addresses for these CE devices is a
     local step.
     
     Note that the PEs discover the IPv6 addresses of the remote CE
     by intercepting Neighbor Discovery and Inverse Neighbor
     Discovery packets that have been passed in-band through the
     pseudowire. As such, there is no need to communicate the IPv6
     addresses of the CEs through LDP signaling.
     
     If the pseudowire is only carrying IPv6 traffic, the address
     specified in the IP Address List TLV will always be zero. If the
     pseudowire is carrying both IPv4 and IPv6 traffic, the
     mechanisms used for IPV6 and IPv4 should not overlap. In
     particular, just because a PE has learned a link-layer address
     for IPv6 traffic by intercepting a Neighbor Advertisement from
     its directly-connected CE, it should not assume that it can use
     that link-layer address for IPv4 traffic until that fact is
     confirmed by reception of, for example, an IPv4 ARP message from
     the CE.
     
     
     6.2. LDP Based Distribution
     
     [RFC4447] uses Label Distribution Protocol (LDP) transport to
     exchange PW 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 is 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 [RFC4447].
     
     As defined in [RFC4447], when processing a received PW FEC, the
     PE matches the PW ID and PW type with the locally configured PW
     ID and PW Type. If there is a match, and if the PW Type is IP
     Layer2 Transport the PE further checks for the presence of an
     Address List TLV (as specified in [RFC 5036]) in the optional
     
     
     Shah et al               Expires August 2009       [Page 18]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     parameter TLVs. The processing of the address list TLV is as
     follows.
       . If a pseudowire is configured for AC with IPv4 CEs only,
          the PE should advertise address list tlv with address
          family type to be of IPv4 address. The PE should process
          the IPv4 address list TLV as described in this document.
          The PE should issue a Label Release message with a status
          code indicating "IP address mismatch" when an IPv6 address
          list is received.
       . If a pseudowire is configured for AC with IPv6 CEs only,
          the PE should advertise the address list tlv with address
          family type to be of IPv6 address. A receipt of IPv6
          address list TLV should be processed as described in the
          document while a receipt of IPv4 address list should be
          rejected by issuing a Label Release with reason code of "IP
          address mismatch".
       . If a pseudowire is configured for AC with IPv4 and IPv6
          CEs, please refer to section 6.3 below for processing of IP
          address list TLV and IP user data traffic as well as
          adapting to one or the other when the remote PE support
          only one type of address resolution.
       . If a PE does not receive any address list TLV, it may
          assume IPv4 behavior. The address resolution must then
          depend on the local configuration.
     
     
     We use the Address List TLV as defined in [RFC 5036] to signal
     the IP address of the local CE. This IP address list TLV is
     included in the optional parameter field of the Label Mapping
     message.
     
     
     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
          2 bytes: 2 bytes for address family to signal the support
          of IPv6 address family
     
     
     Shah et al               Expires August 2009       [Page 19]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
          6 bytes: 2 bytes for address family and 4 bytes of IPv4
          address.
     
     Address Family
          Two octet quantity containing a value from the ADDRESS
          FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 3232]
          that encodes the address contained in the Address field.
     
     IP Address of CE
          IPv4 address of the CE attached to the advertising PE.  The
          encoding of the individual address depends on the Address
          Family (which may be of value zero).
     
     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)             Absent
     
     
     The IP address field is set to all zeroes to denote that
     advertising PE has not learned the IPv4 address of its local CE
     device. Any non-zero value of the IP address field denotes the
     IPv4 address of advertising PE's attached CE device.
     
     The IPv4 address of the CE is also supplied in the optional
     parameters field of the LDP Notification message along with the
     PW FEC. The LDP Notification message is used to signal any
     change in the status of the CE's IPv4 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                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     
     Shah et al               Expires August 2009       [Page 20]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     The Status TLV status code is set to 0x0000002C "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 0x0000002C 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. Dual-Stack support
     The transition from IPv4 to IPv6 networks has created the
     requirements for the CE to carry both stacks, referred as dual-
     stack CE, enabled on the same network. The PEs connected to such
     CEs need to perform the following steps.
       . Enable configuration of the dual-stack on the PE
       . Advertise two IP address list TLVs; one for the IPv4 and
          other for IPv6 in the Label Mapping message as described
          above.
       . A PE configured with dual-stack processes the Label Mapping
          message with the IP address TLVs as follows,
            o If IPv4 and IPv6 address list TLVs are present, each
               is processed individually as described in the above
               section
            o If only one IP address list TLV is present (IPv4 or
               IPv6), the TLV is processed as described above. In
               addition, the PE will revert to the respective IP
               address resolution and disallow the propagation of
               user IP traffic that belongs to the other IP address
               discipline. For instance, if PE has reverted to IPv4
               address resolution, the IPv6 data frames from the
               local AC and pseudowire are discarded. It is prudent
               to alert the operator by traditional means such as
               event logging or alarms about such adaptation as this
               could be a result of unintentional asymmetric
               configuration at two PEs.
            o If IP address list TLV is absent, support of only IPv4
               address discipline is assumed for the remote PE and
               should prevent the propagation of IPv6 from local AC
               to the corresponding pseudowire and vice-versa. Again,
               an operator should be alerted for a possible mis-
               configuration.
       . A PE configured with a single IP address discipline,
          processes the Label Mapping message with the IP address
          list TLV as follows,
            o If IPv4 and IPv6 address list TLVs are present, only
               the one that matches the local configuration of IP
               address discipline is processed. For instance, if PE
     
     
     Shah et al               Expires August 2009       [Page 21]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
               is configured for IPv4, only the IPv4 address TLV is
               processed and engages in IPv4 based address resolution
               as well as IPv4 user data traffic propagation. The
               IPv6 address resolution is disbanded and IPv6 user
               data traffic is discarded.
            o If one of the IPv4 or IPv6 address list TLV is
               present, the processing of the TLV as well as the
               forwarding of user IP data traffic is performed as
               described in the above section.
       . The PE must use the version field of the IP header to
          determine the appropriate link headers when forwarding the
          IP user data traffic from the pseudowire to the local AC.
          For example, when forwarding IPv6 traffic from pseudowire
          to the Ethernet AC, ethertype value 0x86DD is used in the
          MAC header as compared to 0x0800 for IPv4 traffic.
     
       The address resolution aspects of the dual-stack IP, in
       essence, are handled as two independent mechanisms.
     
     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 [RFC
     5036]. The following values are suggested for assignment:
     
        0x0000002C "IP Address of CE"
        0x0000002D "IP Address type mismatch"
     
     
     
     8. 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.
     
     
     
     Shah et al               Expires August 2009       [Page 22]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     8.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 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 the two cross-connected routers.
     
     Finally, each OSPF router generates network LSAs when connected
     to a broadcast link such as Ethernet, receipt of which by an
     OSPF router 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.
     
     8.2. RIP
     
     RIP protocol broadcasts RIP advertisements every 30 seconds. If
     the multicast/broadcast traffic snooping mechanism is used as
     described in section 5.1, the attached PE can learn the local CE
     router's IP address from the IP header of its advertisements. No
     special configuration is required for RIP in this type of Layer
     2 IP Interworking L2VPN.
     
     
     8.3. IS-IS
     
     The IS-IS protocol does not encapsulate its PDUs in IP, and
     hence cannot be supported in IP L2 Interworking L2VPNs.
     
     
     
     
     Shah et al               Expires August 2009       [Page 23]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     9. Multi-domain considerations
     
     In a back-to-back configuration, when two PEs are connected with
     Ethernet, the ARP proxy function has limited 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
     
     Consider a Multi-domain network topology as shown above where PW
     segment 1 (PE1<->PE2) is in network A and PW segment 2 (PE3<-
     >PE4) is in network B. In this configuration CE1 is connected to
     PE1 and CE2 is connected to PE4. PE2 on network A is directly
     connected to PE3 in network B with Ethernet. In this
     configuration there needs to be a mechanism for PE2 and PE3 to
     learn IP addresses of the CEs present in each others network.
     The two options to do this are as follows.
     
        o  Configure IP address of CE2 as a local IP address of the CE
           at PE2 and IP address of CE1 as local IP address of the 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 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
           providers) network.
        o  In the second 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 PE3
           with the source and destination IP address field set to
           IP address of CE1 and the source MAC address field set to
           MAC address of PE2. 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 the opposite direction, when PE3 learns the
           IP address of CE2, it sends a gratuitous ARP to PE2. PE2
           sends an IP address notification, via LDP,the IP address
           of CE2 to PE1 using the same procedures described above.
           This allows PE2 and PE3 to dynamically learn the IP
           addresses of the CEs present in each others networks.
           This is the preferred mode of operation as compared to the
           option 1 above.
     
     
     Shah et al               Expires August 2009       [Page 24]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     
     10. Security Considerations
     
     The security aspect of this solution is addressed for two
     planes; control plane and data plane.
     
     10.1. Control plane security
     
     Control plane security pertains to establishing the LDP
     connection, and to pseudowire signaling and CE IP address
     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.
     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 pseudowire type and other
     pseudowire options may prevent mis-wiring due to configuration
     errors.
     
     Learning the IP address of the appropriate CE can be a security
     issue. It is expected that the Attachment Circuit to the local
     CE 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 (DLCI or
     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
     local configuration before forwarding the information to the
     remote PE to protect against hijacking the connection.
     
     For IPv6, the preferred means of security is Secure Neighbor
     Discover (SEND) [RFC 3971]. SEND provides a mechanism for
     securing Neighbor Discovery packets over media (such as wireless
     links) that may be insecure and open to packet interception and
     substitution. SEND is based upon cryptographic signatures of
     Neighbor Discovery packets. These signatures allow the receiving
     node to detect packet modification and confirm that a received
     packet originated from the claimed source node.
     SEND is incompatible with the Neighbor Discovery packet
     modifications described in this document. As such, SEND cannot
     be used for Neighbor Discovery across an ARP Mediation
     pseudowire. PEs taking part in IPv6 ARP Mediation must remove
     all SEND packet options from Neighbor Discovery packets before
     
     
     Shah et al               Expires August 2009       [Page 25]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     forwarding into the pseudowire. If the CE devices are configured
     to only accept SEND Neighbor Discovery packets, this will lead
     to Neighbor Discovery failing. Thus, the CE devices must be
     configured to accept non-SEND packets, even if they treat them
     with lower priority than SEND packets.
     Because SEND cannot be used in combination with IPv6 ARP
     Mediation, it is suggested that IPv6 ARP Mediation is only used
     with secure Attachment Circuits.
     
     10.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.
     
     11. Acknowledgements
     
     The authors would like to thank Yetik Serbest, Prabhu Kavi,
     Bruce Lasley, Mark Lewis, Carlos Pignataro, Shane Amante and
     other folks who participated in the discussions related to this
     draft.
     
     12. References
     
     12.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".
     
     
     Shah et al               Expires August 2009       [Page 26]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     
        [RFC4447]   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 2119] S. Bradner, "Key words for use in RFCs to
                  indicate requirement levels"
        [RFC 5036] L.Anderssen et al., "LDP Specification"
        [RFC 4861] Narten, T., Nordmark, E. and W.Simpson, "Neighbor
                  Discovery for IP Version 6 (IPv6)", RFC 4861,
                  December, 1998.
        [RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery
                  for Inverse Discovery Specification", RFC 3122,
                  June 2001.
        [RFC 4862] Thomson, S. and Narten, T., "IPv6 Stateless
                  Address Autoconfiguration", RFC 4862, December
                  1998.
        [RFC 3971] Arkko, J. et al., "Secure Neighbor Discovery
                  (SEND)", RFC 3971, March 2005.
        [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
                   Control Protocol (IPCP)".
     
     12.2. Informative References
     
        [L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June
                   2004, work in progress.
        [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address
                    Resolution".
        [RFC 1256] S.Deering, "ICMP Router Discovery Messages".
        [RFC 3232] Reynolds and Postel, "Assigned Numbers".
     
     
     
     
     Shah et al               Expires August 2009       [Page 27]
     

                  Draft-ietf-l2vpn-arp-mediation-10.txt
     
     13. 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@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
     Network Appliance, Inc.
     800 Cranberry Woods Drive
     Suite 300
     Cranberry Township, PA 16066
     EMail: tob@netapp.com
     
     
     Andrew G. Malis
     Tellabs
     1415 West Diehl Road
     Naperville, IL 60563
     EMail: Andy.Malis@tellabs.com
     
     Steven Wright
     Bell South Corp
     Email: steven.wright@bellsouth.com
     
     
     
     Shah et al               Expires August 2009       [Page 28]
     
                  Draft-ietf-l2vpn-arp-mediation-10.txt
     

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