L2VPN Working Group                                  Himanshu
Internet Engineering Task Force (IETF)                           H. Shah
   Internet-Draft                                          Ciena Corp
   Intended Status:
Request for Comments: 7436                                   Cinea Corp.
Category: Historic
                                                           Eric                                              E. Rosen
                                                 Francois
ISSN: 2070-1721                                         Juniper Networks
                                                          F. Le Faucheur
                                                          Giles
                                                                G. Heron
                                                           Cisco Systems
                                                     October 30, 2014
                                                            January 2015

                       IP-Only LAN Service (IPLS)
                       draft-ietf-l2vpn-ipls-16.txt

Status

Abstract

   A Virtual Private LAN Service (VPLS) is used to interconnect systems
   across a wide-area or metropolitan-area network, making it appear
   that they are on a private LAN.  The systems that are interconnected
   may themselves be LAN switches.  If, however, they are IP hosts or IP
   routers, certain simplifications to the operation of the VPLS are
   possible.  We call this simplified type of VPLS an "IP-only LAN
   Service" (IPLS).  In an IPLS, as in a VPLS, LAN interfaces are run in
   promiscuous mode, and frames are forwarded based on their destination
   Media Access Control (MAC) addresses.  However, the maintenance of
   the MAC forwarding tables is done via signaling, rather than via the
   MAC address learning procedures specified in the IEEE's "Media Access
   Control (MAC) Bridges".  This document specifies the protocol
   extensions and procedures for support of the IPLS service.

   The original intent was to provide an alternate solution to VPLS for
   those Provider Edge (PE) routers that were not capable of learning
   MAC addresses through data plane.  This became a non-issue with newer
   hardware.  The concepts put forth by this document are still valuable
   and are adopted in one form or other by newer work such as Ethernet
   VPN in L2VPN working group and possible data center applications.  At
   this point, no further action is planned to update this document and
   it is published simply as a historic record of the ideas.

Status of This Memo

   This document is not an Internet Standards Track specificaion; specification; it is
   published for the historical record.

   This document defines a Historic Document for the Internet community.
   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see section Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6348.

   This Internet-Draft is submitted in full conformance with the
   provisions of 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

   This Internet-Draft will expire on April 30, 2015
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt
   http://www.rfc-editor.org/info/rfc7436.

Copyright Notice

   Copyright (c) 2014 2015 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   A Virtual Private LAN Service (VPLS) is used to interconnect
   systems across a wide-area or metropolitan-area network, making it
   appear that they are on a private LAN.  The systems which are
   interconnected may themselves be LAN switches.  If, however, they
   are IP hosts or IP routers, certain simplifications to the operation
   of the VPLS are possible.  We call this simplified type of VPLS an
   "IP-only LAN Service" (IPLS).  In an IPLS, as in a VPLS, LAN
   interfaces are run in promiscuous mode, and frames are forwarded
   based on their destination MAC addresses.  However, the maintenance
   of the MAC forwarding tables is done via signaling, rather than via
   the MAC address learning procedures specified in [IEEE 802.1D].
   This draft specifies the protocol extensions and procedures for
   support of the IPLS service.

   The original intent was to provide an alternate solution to VPLS
   for those PE routers that were not capable of learning MAC address
   through data plane. This became a non-issue with newer hardware.
   The concepts put forth by this draft are still valuable and are
   adopted in one form or other by newer work such as Ethernet VPN
   in L2VPN Working Group and possible data center applications. At
   this point, no further action is planned to update this document
   and is published simply as a historic record of the ideas.

Conventions

   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.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt License.

Table of Contents

 Copyright Notice .................................................... 1
Abstract.............................................................. 2
1.0 Contributing Authors ............................................. 3
2.0 Overview.......................................................... 4
 2.1

   1. Overview ........................................................4
      1.1. Terminology ..................................................... 7
3.0 Topology.......................................................... 8
4.0 Configuration..................................................... 9
5.0 Discovery........................................................ 10
 5.1 ................................................7
   2. Topology ........................................................9
   3. Configuration ..................................................10
   4. Discovery ......................................................10
      4.1. CE discovery ................................................... 10
  5.1.1 IPv4 based Discovery ..............................................10
           4.1.1. IPv4-Based CE discovery ..................................... 10
  5.1.2 Ipv6 based Discovery ............................11
           4.1.2. IPv6-Based CE discovery [RFC 4861] .......................... 10
6.0 Pseudowire Creation.............................................. 11
 6.1 Discovery (RFC 4861) .................11
   5. PW Creation ....................................................11
      5.1. Receive Unicast Multipoint-to-point Pseudowire ................. 11
 6.2 Multipoint-to-Point PW ....................11
      5.2. Receive Multicast Multipoint-to-point Pseudowire ............... 11
 6.3 Multipoint-to-Point PW ..................12
      5.3. Send Multicast Replication tree ................................ 12
7.0 Signaling........................................................ 13
 7.1 Tree ...........................13
   6. Signaling ......................................................13
      6.1. IPLS PW Signaling .............................................. 13
 7.2 .........................................13
      6.2. IPv6 Capability Advertisement .................................. 17
 7.3 .............................17
      6.3. Signaling Advertisement Processing ............................. 18
8. ........................18
   7. IANA Considerations............................................... 19
 8.1. Considerations ............................................19
      7.1. LDP Status messages ........................................... 19
 8.2. Messages .......................................19
      7.2. Interface Parameters .......................................... 19
9.0 Forwarding....................................................... 19
 9.1 ......................................19
   8. Forwarding .....................................................20
      8.1. Non-IP or non-ARP traffic ...................................... 19
 9.2 Non-ARP Traffic .................................20
      8.2. Unicast IP Traffic ............................................. 20
 9.3 ........................................20
      8.3. Broadcasts and Multicast IP Traffic ............................ 20
 9.4 .......................20
      8.4. ARP Traffic .................................................... 20
 9.6 ...............................................21
      8.5. Discovery of IPv6 CE Devices ..............................21
           8.5.1. Processing of Neighbor Solicitations ...............22
           8.5.2. Processing of Neighbor Advertisements ..............22
           8.5.3. Processing of Inverse Neighbor
                  Solicitations and Advertisement ....................22
           8.5.4. Processing of Router Solicitations and
                  Advertisements .....................................23
      8.6. Encapsulation .................................................. 23
10.0 .............................................23
   9. Attaching to IPLS via ATM or FR............................... 23
11.0 Frame Relay (FR) ..................24
   10. VPLS vs IPLS.................................................... 23
12.0 IP Protocols.................................................... 24
13.0 Dual Homing with IPLS........................................... 25
14.0 vs. IPLS .................................................24
   11. IP Protocols ..................................................25
   12. Dual-Homing with IPLS .........................................25
   13. Proxy ARP function.............................................. 25
 14.1 Function ............................................26
      13.1. ARP Proxy - Responder ......................................... 25
 14.2 ....................................26
      13.2. ARP Proxy - Generator ......................................... 25
15.0 ....................................26
   14. Data Center Applicability ...................................... 25
16.0 Acknowledgements................................................ 26
17.0 .....................................27
   15. Security Considerations......................................... 27
 17.1 Control plane security ........................................ 27
 17.2 Data plane security ........................................... 28
18.0 References...................................................... 29
 18.1 Considerations .......................................27
      15.1. Control-Plane Security ...................................27
      15.2. Data-Plane Security ......................................28
   16. References ....................................................29
      16.1. Normative References .......................................... 29
 18.2 .....................................29
      16.2. Informative References ........................................ 29
19.0 Author's Address................................................ 30

1.0  Contributing Authors
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

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

   K. Arvind                    Fortress
   Vach Kompella/Mathew Bocci   Alcatel/Lucent
   Shane Amante                 Apple

2.0 ...................................30
   Acknowledgements ..................................................31
   Contributors ......................................................31
   Authors' Addresses ................................................32

1.  Overview

   As emphasized in [VPLS], [RFC4762], Ethernet has become popular as an access
   technology in Metropolitan metropolitan- and Wide Area Networks. [VPLS] wide-area networks.  [RFC4762]
   describes how geographically dispersed customer LANs can be
   interconnected over a service provider's network.  The VPLS service
   is provided by Provider Edge (PE) devices that connect Customer Edge
   (CE) devices.  The VPLS architecture provides this service by
   incorporating bridging functions such as MAC address learning in the
   PE devices.

   Provider Edge

   PE platforms are designed primarily to be IP routers, routers rather than to be LAN
   switches.  To add VPLS capability to a PE router, one has to add MAC address learning MAC-
   address-learning capabilities, along with aging and other mechanisms
   native to Ethernet switches. switches [IEEE802.1D].  This may be fairly complex
   to add to the forwarding plane forwarding-plane architecture of an IP router.  As
   discussed in [L2VPN-FWK], [RFC4664], in scenarios where the CE devices are NOT LAN
   switches, but rather are IP hosts or IP routers, it is possible to
   provide the VPLS service without requiring MAC address learning and
   aging on the PE.  Instead, a PE router has to have the capability to
   match the destination MAC address in a packet received from a CE to
   an outbound pseudowire. pseudowire (PW).  The requirements for the IPLS service
   are described in [L2VPN-REQTS]. [RFC4665].  The purpose of this document is to
   specify a solution optimized for IPLS.

   IPLS provides a VPLS-like service using PE routers that are not
   designed to perform general LAN bridging functions.  One must be
   willing to accept the restriction that an IPLS be used for IP traffic
   only, and not used to interconnect CE devices that are themselves LAN
   switches.  This is an acceptable restriction in many environments,
   given that IP is the predominant type of traffic in today's networks.

   The original intent was to provide an alternate solution to VPLS for
   those PE routers that were not capable of learning MAC address
   through addresses in
   the data plane.  This became a non-issue with newer hardware.  The
   concepts put forth by this draft document are still valuable and are
   adopted in one form or other by newer work such as Ethernet VPN in
   the L2VPN Working Group working group and possible data center applications.  At
   this point, no further action is planned to update this document and
   is published simply as a historic record of the ideas.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   In IPLS, a PE device implements multi-point multipoint LAN connectivity for IP
   traffic using the following key functions:

      1. CE Address Discovery: Each Provider Edge (PE) PE device discovers the MAC address
         of the locally attached Customer Edge (CE) CE IP devices, for each IPLS instance
         configured on the PE device.  In some configurations, the PE
         also learns the IP address of the CE device (when performing
         ARP proxy functions, described later in the document).

      2. Pseudowire (PW) for Unicast Traffic: For each locally attached
         CE device in a given IPLS instance, a PE device sets up a
         pseudowire (PW-LSP) (PW) to each of the other PEs that supports the same
         IPLS instance.

         For instance, if PEx and PEy both support IPLS I, and PEy is
         locally attached to CEa and CEb, PEy will initiate the setup of
         two pseudowires PWs between itself and PEx.  One of these will be used to
         carry unicast traffic from any of PEx's CE devices to CEa.  The
         other will be used to carry unicast traffic from any of PEx's
         CE devices to CEb.

         Note that these pseudowires PWs carry traffic only in one direction.
         Further, while the pseudowire PW implicitly identifies the destination CE
         of the traffic, it does not identify the source CE; packets
         from different source CEs bound to the same destination CE are
         sent on a single pseudowire. PW.

      3. Pseudowires for Multicast Traffic:  In addition, every PE
         supporting a given IPLS instance will set up a special
        'multicast pseudowire'
         'multicast' pseudowire to every other PE in that IPLS instance.
         If, in the above example, one of PEx's CE devices sends a
         multicast packet, PEx would forward the multicast packet to PEy
         on the special 'multicast' pseudowire.  PEy would then send a
         copy of that packet to CEa and a copy to CEb.

         The 'multicast' pseudowire carries Ethernet frames of
         multicast/broadcast IP, ARP ARP, and ICMP (Inverse) Neighbor
         Discovery (ND/IND) packets for IPv6. Thus  Thus, when a PE sends a
         multicast packet across the network, it sends one copy to each
         remote PE (supporting the given IPLS instance).  If a
         particular remote PE has more than one CE device in that IPLS
         instance, the remote PE must replicate the packet and send one
         copy to each of its local CEs.

         As with the pseudowires that are used for unicast traffic,
         packets travel in only one direction on these pseudowires, and
         packets from different sources may be freely intermixed.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

      4. Signaling:  The necessary pseudowires can be set up and
         maintained using the LDP-based signaling procedures based on the Label
         Distribution Protocol (LDP) described in [PWE3-CONTROL]. [RFC4447].

         A PE may assign the same label to each of the unicast
         pseudowires that lead to a given CE device, in effect creating
         a multipoint-to-point pseudowire.

         Similarly, a PE may assign the same label to each of the
         'multicast' pseudowires for a given IPLS instance, in effect
         creating a multipoint-to-point pseudowire.  When setting up a
         pseudowire to be used for unicast traffic, the PE must also
         signal the MAC address of the corresponding CE device.  It
         should also, optionally, advertise the IP address of the local
         CE device, especially when ARP proxy function is configured or
         simply for operational management purposes.  Similarly, for
         IPv6 support, PE may optionally advertise the IPv6 addresses of
         the local CE device.

      5. ARP Packet Forwarding: ARP packets [ARP] [RFC826] are forwarded from
         the attachment circuit (AC) to 'multicast' pseudowires in the
         Ethernet frame format as described by [PWE3-ETH].The [RFC4448].  The following
         rules are observed when processing ARP packets, packets:

         a. Both broadcast (request) and unicast (response) ARP packets
            are sent over the 'multicast' pseudowire.

         b. When an ARP packet is received from an AC, the packet is
            copied to the control plane for the purpose of learning the
            MAC address of the CE.  Optionally, an IP address is also
            learned to record the association of the IP and MAC address.

         c. All Ethernet packets, including ARP packets, received from
            the 'multicast' pseudowire are forwarded out to all the ACs
            associated with the IPLS instance.  These packets are not
            copied to the control plane.

      6. ICMP IPv6 ND/IND related ND/IND-related Packet Forwarding: (Inverse) Neighbor
        Discovery (ND/IND) ND/IND IPv6 packets
         from an AC are replicated and a copy is sent to other ACs and
         to 'multicast' PWs associated with the IPLS instance in the
         native Ethernet format, unchanged.  A copy is also submitted to Control Plane
         the control plane to learn the MAC address and optionally and, optionally,
         corresponding IPv6 addresses.

      7. Multicast IP packet forwarding: An IP Ethernet frame received
         from an AC is replicated to other ACs and the 'multicast'
        pseudowires PWs
         associated with the IPLS instance.  An IP Ethernet frame
         received from a 'multicast' pseudowire PW is replicated to all the egress
         ACs associated with the IPLS instance.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

      8. Unicast IP packet forwarding: An IP packet received from the AC
         is forwarded based on the destination MAC DA address lookup in the
         forwarding table.  If a match is found, the packet is forwarded
         to the associated egress interface.  If the egress interface is
         unicast
        pseudowire, PW, the packet is sent without a MAC header.  If the
         egress interface is a local AC AC, the Ethernet frame is forwarded
         as such.  An IP packet received from the unicast pseudowire PW is
         forwarded to the egress AC with the MAC header prepended.  The
         destination MAC DA address is derived from the forwarding table
         while the source MAC SA address is the MAC address of the PE.

   Both VPLS [VPLS] [RFC4762] and IPLS require the ingress PE to forward a
   frame based on its destination MAC address.  However, two key
   differences between VPLS and IPLS can be noted from the above
   description:

     .

   -  In VPLS, MAC entries are placed in the Forwarding Information Base
      (FIB) of the ingress PE as a result of MAC address learning (which
      occurs in the data plane) while plane); whereas, in IPLS IPLS, MAC entries are
      placed in the FIB as a result of pseudowire PW signaling operations (control
      plane).
     .

   -  In VPLS, the egress PE looks up a frame's destination MAC address
      to determine the egress AC; in IPLS, the egress AC is determined
      entirely by the ingress PW-label. PW label.

   The following sections describe the details of the IPLS scheme.

2.1

1.1.  Terminology

   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 [RFC2119].

   IPLS           IPLS stands for IP-only LAN service (a type of Virtual
                  Private LAN Service that is restricted to IP traffic
                  only).

        mp2p

   MP2P PW        Multipoint-to-Point Pseudowire.        A pseudowire Multipoint-to-Point Pseudowire is a PW that carries
                  traffic from remote PE devices to a PE device that
                  signals the pseudowire. PW.  The signaling PE device advertises
                  the same PW- PW label to all remote PE devices that
                  participate in the IPLS service instance.  In IPLS,
                  for a given IPLS instance, an mp2p MP2P PW used for IP
                  unicast traffic is established by a PE for each CE
                  device locally attached to that PE.  It is a
                  unidirectional tree whose leaves consist of the remote
                  PE peers (which connect at least one AC associated
                  with the same IPLS instance) and whose root is the
                  signaling PE.  Traffic flows from the leaves towards
                  the root.

   Multicast PW   Multicast/broadcast Pseudowire.   A Multicast/broadcast Pseudowire is a special kind of mp2p
                  MP2P PW that carries IP multicast/broadcast traffic,
                  all ARP frames and ICMP (I)ND frames for IPv6.  In the
                  IPLS architecture, for each IPLS instance supported by
                  a PE, that PE device establishes exactly one multicast
                  PW.  Multicast PW uses Ethernet encapsulation.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   Unicast PW     A Unicast Pseudowire pseudowire carries IP unicast packets.  A PE
                  creates unicast PW for each locally attached CE.  The
                  unicast PW uses IP Layer2 Layer 2 (L2) transport
                  encapsulation.

   CE             Customer Edge device.             In this document, a CE Customer Edge (CE) is any IP node
                  (host or router) connected to the IPLS LAN service.

        Replication Tree

   Send           The collection of all multicast PWs and ACs
   Multicast      that are members of an IPLS service instance on a
   Replication    given PE.  When a PE receives a multicast/broadcast
   Tree           packet from an AC, the PE device sends a copy of the
                  packet to every multicast pseudowire PW and AC of the replication
                       tree, Send
                  Multicast Replication Tree, excluding the AC on which
                  the packet was received.  When a PE receives a packet
                  from a multicast PW, the PE device sends a copy of the
                  packet to all the ACs of the replication tree Send Multicast
                  Replication Tree and never to other PWs.

   (I)ND          (Inverse) Neighbor Discovery in IPv6 uses ICMP
                       packets. It is a protocol that uses
                  Neighbor
                       solicitation/Advertisement PDUs. Solicitation (NS) and Neighbor Advertisement
                  (NA) packets.

   RS             Router Solicitation. Hosts Solicitation is when hosts generate all router all-routers
                  multicast ICMP packet packets to discover the IPv6 router on
                  the local link.

   RA             Router Advertisement. Router Advertisement occurs when a router generates all
                  all-nodes multicast ICMP packet packets to advertise its
                  presence on the link.  A unicast response is also sent
                  when RS is received.

   NS             Neighbor Solicitation in IPv6 uses (multicast) ICMP
                  packets to resolve the association of the IPv6
                  interface address to the MAC address association. address.

   NA             Neighbor Advertisement in IPv6 uses (unicast) ICMP
                  packets to respond to NS.

3.0

2.  Topology

   The Customer Edge (CE) CE devices are IP nodes (hosts or routers) that are connected to
   PE devices either directly, directly or via an Ethernet network.  We assume
   that the PE/CE connection may be regarded by the PE as an "interface"
   to which one or more CEs are attached.  This interface may be a
   physical LAN interface or a VLAN.  The Provider
   Edge (PE) PE routers are MPLS Label Edge
   Routers (LERs) that serve as
   pseudowire PW endpoints.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   +----+                                              +----+
   + S1 +---+      ...........................     +---| S2 |
   +----+ | |      .                         .     |   +----+
    IPa   | |   +----+                    +----+   |    IPe
          + +---| PE1|---MPLS and/or IP---| PE2|---+
         / \    +----+         |Network   +----+   |
   +----+   +---+  .           |             .     |   +----+
   + S1 +   | S1|  .         +----+          .     +---| S2 |
   +----+   +---+  ..........| PE3|...........         +----+
    IPb       IPc            +----+                     IPf
                               |
                               |
                             +----+
                             | S3 |
                             +----+
                               IPd

   In the above diagram, an IPLS instance is shown with three sites:
   site S1, site S2 S2, and site S3.  In site S3, the CE device is directly
   connected to its PE.  In the other two sites, there are multiple CEs
   connected to a single PE.  More precisely, the CEs at these sites are
   on an Ethernet (switched at site 1 and shared at site 2) network (or
   VLAN), and the PE is attached to that same Ethernet network or VLAN).
   We impose the following restriction: if one or more CEs attach to a
   PE by virtue of being on a common LAN or VLAN, there MUST NOT be more
   than one PE on that LAN or VLAN.

   PE1, PE2 PE2, and PE3 are shown as connected via an MPLS network;
   however, other tunneling technologies, such as GRE, L2TPv3, Generic Routing
   Encapsulation (GRE), Layer 2 Tunneling Protocol version 3 (L2TPv3),
   etc., could also be used to carry the pseudowires. PWs.

   An IPLS instance is a single broadcast domain, such that each IP end
   station (e.g., IPa) appears to be co-located with other IP end
   stations (e.g., IPb through IPf) on the same subnet.  The IPLS
   service is transparent to the CE devices and requires no changes to
   them.

4.0

3.  Configuration

   Each PE router is configured with one or more IPLS service instances,
   and each IPLS service instance is associated with a unique VPN-Id. VPN-ID.
   For a given IPLS service instance, a set of ACs is identified.  Each
   AC can be associated with only one IPLS instance.  An AC, in this
   document, is either a customer-facing Ethernet port, or a particular
   VLAN (identified by an IEEE 802.1Q VLAN ID) on a customer-facing
   Ethernet port.

   The PE router can optionally be configured with a local MAC address
   to be used as a source MAC address when IP packets are forwarded from
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt
   a pseudowire PW to an AC.  By default, a PE uses the MAC address of the
   customer-facing Ethernet interface for this purpose.

5.0

4.  Discovery

   The discovery process includes:
     .
      -  Remote PE discovery
     .
      -  VPN (i.e., IPLS) membership discovery
     .
      -  IP CE end station discovery

   This draft document does not discuss the remote PE discovery or VPN
   membership discovery.  This information can either be user configured
   or can be obtained using auto-discovery techniques described in
   [L2VPN-SIG]
   [RFC6074] or other methods.  However, the discovery of the CE is an
   important operational step in the IPLS model and is described below.

5.1

4.1.  CE discovery Discovery

   Each PE actively detects the presence of local CEs by snooping IP and
   ARP frames received over the ACs.  When an AC configured in an IPLS
   instance becomes operational, it enters the CE discovery phase.  In
   this phase, the PE examines each multicast/broadcast Ethernet frame.
   For link-local IP broadcast/multicast frames (for example IGP
   discovery/multicast/broadcast (e.g., IPv4 packets typically 224.0.0.x with
   destination addresses
   [RFC-1112]), within 224.0.0/24 [RFC5771]), the CE's (source)
   MAC address is extracted from the Ethernet header and the (source) IP
   address is obtained from the IP header.

   For each CE, the PE maintains the following tuple: <Attachment
   Circuit identification info, VPN-Id, VPN-ID, MAC address, IP address
   (optional)>.

 5.1.1 IPv4 based

4.1.1.  IPv4-Based CE discovery Discovery

   As indicated earlier, a copy of each ARP frames frame received over the AC
   is submitted to the control plane.  The PE learns the MAC address and
   optionally the IP address of the CE from the source address fields of
   the ARP PDU.

   Once a CE is discovered, its status is monitored continuously by
   examining the received ARP frames and by periodically generating ARP
   requests.  The absence of an ARP response from a CE after a
   configurable number of ARP requests is interpreted as loss of
   connectivity with the CE.

 5.1.2 Ipv6 based

4.1.2.  IPv6-Based CE discovery [RFC 4861] Discovery (RFC 4861)

   A copy of Neighbor and Router Discovery frames received over the AC
   are submitted to the control plane in the PE.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   If the PE receives a Neighbor Solicitation an NS message, and the source IP address of the
   message is not the unspecified address, the PE learns the MAC address
   and optionally the IP address of the CE.

   If the PE receives an unsolicited Neighbor Advertisement NA message, the PE learns the
   source MAC address and optionally the IP address of the CE.

   If the PE receives a Router Solicitation, an RS, and the source IP address of the message is
   not the unspecified address, the PE learns source MAC address and
   optionally the IP address of the CE.

   If the PE receives a Router Advertisement, an RA, it learns the source MAC address and
   optionally the IP address of the CE.

   The PE will periodically generate Neighbor Solicitation NS 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 interpreted as a loss
   of connectivity with the CE.

6.0 Pseudowire

5.  PW Creation

6.1

5.1.  Receive Unicast Multipoint-to-point Pseudowire Multipoint-to-Point PW

   As the PE discovers each locally attached CE, a unicast multipoint-
   to-point pseudowire (mp2p (MP2P PW) associated exclusively with that CE is
   created by distributing the MAC address and optionally the IP address
   of the CE along with a PW-Label PW label to all the remote PE peers that
   participate in the same IPLS instance.  Note that the same value of a
   PW-label
   PW label SHOULD be distributed to all the remote PE peers for a given
   CE.  The mp2p MP2P PW thus created is used by remote PEs to send unicast
   IP traffic to a specific CE.

   (The same functionality can be provided by a set of point-to-point
   PWs, and the PE is not required to send the same PW-label PW label to all the
   other PEs.  For convenience, however, we will use the term mp2p MP2P PWs,
   which may be implemented using a set of point-to-point PWs.)

   The PE forwards a frame received over this mp2p MP2P PW to the associated
   AC.

   The unicast pseudowire PW uses IP Layer2 Layer 2 Transport encapsulation as
   define defined in [PWE3-CONTROL].

6.2
   [RFC4447].

5.2.  Receive Multicast Multipoint-to-point Pseudowire Multipoint-to-Point PW

   When a PE is configured to participate in an IPLS instance, it
   advertises a 'multicast' PW-label PW label to every other PE that is a member
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt
   of the same IPLS.  The advertised PW-label PW label value is the same for each
   PE, which creates an mp2p pseudowire. MP2P PW.  There is only one such multicast mp2p MP2P
   PW per PE for each IPLS instance instance, and this pseudowire PW is used exclusively to
   carry IP multicast/broadcast, ARP traffic traffic, and (inverse) Neighbor
   Discovery packets for IPv6 from the remote PEs to this PE for this
   IPLS instance.

   Note that no special functionality is expected from this pseudowire. PW.  We call
   it a 'multicast' pseudowire PW because we use it to carry multicast and
   broadcast IP, ARP ARP, and IPv6 Neighbor Discovery traffic.  The pseudowire PW
   itself need not provide any different service than any of the unicast pseudowires.
   PWs.

   In particular, the Receive multicast mp2p MP2P PW does not perform any
   replication of frames itself.  Rather, it is there to signify to the
   PE that the PE may need to replicate a copy of a frame received over
   this mp2p MP2P PW onto all the AC ACs that are associated with the IPLS
   instance of the mp2p MP2P PW.

   The multicast mp2p pseudowire MP2P PW is considered the principle pseudowire principal PW in the bundle of mp2p pseudowires
   MP2P PWs that consist consists of one multicast mp2p
   pseudowire MP2P PW and a variable number
   of unicast mp2p pseudowires MP2P PWs for a given IPLS instance.  In a principle principal role,
   multicast PW represents the IPLS instance.  The life of all unicast
   PWs in the IPLS instance depends on the existence of the multicast
   PW.  If, for some reasons, reason, multicast PW PWs cease to exist, all the
   associated unicast pseudowires PWs in the bundle are would be removed.

   The multicast pseudowire PW uses Ethernet encapsulation as defined in
   [PWE3-ETH]. [RFC4448].

   The use of pseudowires which PWs that are specially optimized for multicast is for
   further study.

6.3

5.3.  Send Multicast Replication tree Tree

   The PE creates a send replication tree Send Multicast Replication Tree for each IPLS
   instance, which consists of the collection of all ACs and all the
   'multicast'
   pseudowires PWs of the IPLS instance.

   Any ARP, Neighbor Discovery Discovery, or multicast broadcast/multicast IP Ethernet frame
   received over an AC is replicated to the other ACs and to the mp2p MP2P
   multicast
   pseudowire PW of the send replication tree. Send Multicast Replication Tree.  The send replication tree Send
   Multicast Replication Tree deals mostly with broadcast/multicast
   Ethernet MAC frames.  One exception to this is unicast ARP and IPv6
   Neighbor Discovery frame, the processing of which is described in the
   following section.

   Any Ethernet frame received over the multicast PW is replicated to
   all the ACs of the send replication tree Send Multicast Replication Tree of the IPLS
   instance associated with the incoming PW label. One label: one exception is
   unicast ARP
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt and Neighbor Discovery frame frames used for IPv6, the
   processing of which is described in the following section.

7.0

6.  Signaling

   [PWE3-CONTROL]

   [RFC4447] uses the Label Distribution Protocol (LDP) LDP to exchange PW-FECs PW FECs in the Label Mapping message
   in a downstream unsolicited mode.  The PW-FEC PW FEC comes in two forms;
   PWid and Generalized PWid FEC elements.  These FEC elements define
   some fields that are common between them.  The discussions below
   refer to these common fields for IPLS related IPLS-related extensions.  Note that
   the use of
   multipoint to point multipoint-to-point and unidirectional characteristics of
   the PW makes BGP as the ideal candidate for PW-FEC PW FEC signaling.  The use
   of BGP for such purposes is for future study.

7.1

6.1.  IPLS PW Signaling

   An IPLS carries IP packets as payload over its unicast pseudowires PWs and
   Ethernet packet frames as payload over its multicast pseudowire. PW.  The
   PW-type PW type to be
   used for unicast pseudowire PW is the IP PW, defined in
   [PWE3-CONTROL] [RFC4447] as IP Layer2 Layer 2
   Transport.  The PW-type PW type to be used for multicast pseudowire PW is the Ethernet
   PW as defined in [PWE3-ETH]. [RFC4448].  The PW-Type PW type values for these
   encapsulations are defined in [PWE3-
   IANA]. [RFC4446].

   When processing a received PW FEC, the PE matches the PW Id with the
   locally configured PW Id for the IPLS instance.  If the PW type is
   Ethernet, the PW-FEC PW FEC is for multicast PW. PWs.  If the PW type is 'IP
   Layer2
   Layer 2 transport', the PW FEC is for unicast PW. PWs.

   For unicast PW, PWs, the PE must check the presence of a MAC address Address TLV
   in the optional parameter fields of the Label Mapping message.  If
   this parameter is absent, a Label Release message must be issued with
   a
   Status Code status code meaning "MAC Address of the CE is absent" [note: Status
   Code (note: status
   code 0x000000XX is pending IANA allocation], allocation (see Section 7)), to
   reject the establishment of the unicast PW with the remote PE.

   The PE may optionally include an IP address TLV based on the user
   configuration for the advertising of the IP addresses of the local
   CE.

   The processing of the address list Address List TLV is as follows.

      o  If a pseudowire PW is configured for AC ACs with IPv4 CEs only, the PE should
         advertise address list tlv an Address List TLV with address family an Address Family type
        to be of an
         IPv4 address.  The PE should process the IPv4 address list TLV
         as described in this document.

      o  If a pseudowire PW is configured for AC ACs with both IPv4 and IPv6 CEs, the
         PE should advertise IPv6 capability using the procedures
         described in Section the section below.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

      o  If a PE does not receive any IP address list Address List TLV or IPv6
         capability advertisement, it MAY assume IPv4 behavior.

   The IPLS uses the Address List TLV as defined in [RFC 5036] [RFC5036] to signal
   the MAC (and optionally IP) address of the local CE.  There are two
   TLVs defined below; below: the IP Address TLV and MAC Address TLV.  The MAC
   address
   Address TLV must be included in the optional parameter field of the
   Label Mapping message when establishing the unicast IP PW for IPLS.

   When configured to support a specific type of IP traffic (IPv4 or
   IPv6), the PE augments verification of verifies the type of IP traffic the PW will
   carry using the Address Family Type value. carry.  If
   there is a mismatch between the received Address Family value and the
   expectation of an IPLS instance to which the PW belongs, the PE must
   issue a Label Release message with a Status Code status code meaning "IP Address
   type mismatch" (Status Code (status code 0x0000004A) to reject the PW
   establishment.

   Encoding

   The encoding of the IP Address TLV is: 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|0| Address List (0x0101)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Address Family            |     CE's       CE IP Address           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       CE's     CE IP Address             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length
      When an Address Family is IPV4, IPv4, the Length is equal to 6 bytes; 2
      bytes for address family the Address Family and 4 bytes of IP address.  The
        length
      Length is 18 bytes when address family the Address Family is IPv6, IPv6; 2 bytes for
        address family
      the Address Family and 16 bytes of IP address.

   Address Family
        Two octet
      Two-octet quantity containing a value from the ADDRESS FAMILY
        NUMBERS from ADDRESS FAMILY NUMBERS in "Address Family
      Numbers" registry [ADDR-IANA] that encodes the addresses contained
      in the Addresses field.

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

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

            Address Family      Address Encoding

            IPv4 (1)             4 octet             4-octet full IPv4 address
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

            IPv6 (2)             16 octet             16-octet full IPv6 address

   Note that more than one instance of the IP address TLV may exist,
   especially when support for IPv6 is configured.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   Encoding

   The encoding of the MAC Address TLV is: 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|0| Address List (0x0101)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Address Family            |     CE's MAC address Address          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length
      The length Length field is set to a value of 8 (2 bytes for address family, the Address
      Family, 6 bytes for the MAC address)

   Address Family
        Two octet
      Two-octet quantity containing a value from ADDRESS FAMILY
        NUMBERS in the "Address Family
      Numbers" registry [ADDR-IANA] that encodes the addresses contained
      in the Addresses field.

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

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

            Address Family      Address Encoding

            MAC (6)             6 octet             6-octet full Ethernet MAC address

   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.

   Note that Notification message does not apply to the MAC address Address TLV
   since an update to the MAC address of the CE should result in label
   withdraw
   withdrawal followed by establishment of a new PW with a new MAC
   address of the CE.  However, advertisement of IP address(es) of the
   CE is
   optional optional, and changes may become known after the establishment
   of unicast PW.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   The encoding of the LDP Notification message is as follows.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IP Address List TLV (as defined above)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 PWId FEC or Generalized ID FEC                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Status TLV status code is set to 0x0000002C "IP address of CE",
   to indicate that an IP Address address update follows.  Since this
   notification does not refer to any particular message message, the Message Id, ID
   and Message Type fields are set to 0.

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

7.2

6.2.  IPv6 Capability Advertisement

   A 'Stack Capability' Interface Parameter sub-TLV is signaled by the
   two PEs so that they can agree which stack(s) they should be using.
   It is assumed assumed, by default default, that the IP PW will always be capable of
   carrying IPv4 packets. Thus  Thus, this capability sub-TLV is used to
   indicate if other stacks need to be supported concurrently with IPv4.

   The 'Stack Capability' sub-TLV is part of the interface parameters of
   the PW FEC.  The proposed format for the Stack Capability
   interface parameter 'Stack Capability' Interface
   Parameter sub-TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Parameter ID  |     Length    |       Stack Capability        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter ID = 0x16

   Length = 4

   Stack capability Capability = 0x000X to indicate IPv6 stack capability
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt
   The Value value of Stack capability Capability is dependent on the PW type context.
   For IP PW type, a setting of 0x000X indicates IPv6 stack capability.

   A PE that supports IPv6 on an IP PW MUST signal the stack capability the 'Stack
   Capability' sub-TLV in the initial label mapping Label Mapping message for the PW.
   The PE nodes compare the value advertised by the remote PE with the
   local configuration and only use a capability which that is advertised by
   both.  If a PE that supports IPv6 does not receive a 'stack capability' 'Stack
   Capability' sub-TLV from the far-end PE in the initial label mapping Label Mapping
   message, or one is received but it is set to a reserved value, the PE
   MUST send an unsolicited release for the PW label with the LDP status
   code meaning "IP Address type mismatch" (Status Code (status code 0x0000004A).

   The behavior of a PE that does not understand an interface parameter
   sub-TLV is specified in RFC4447 [PWE3-CONTROL].

7.3 RFC 4447 [RFC4447].

6.3.  Signaling Advertisement Processing

   A PE should process a received [PWE3-CONTROL] [RFC4447] advertisement with PW- a PW type
   of IP Layer2 transport Layer 2 Transport for IPLS as follows, follows:

      -  Verify the IPLS VPN membership by matching the VPN-Id VPN-ID signaled
         in the AGI Attachment Group Identifier (AGI) field or the PW-ID PWid
         field with all the
          VPN-Ids VPN-IDs configured in the PE.  Discard and
         release the PW label if VPN-Id VPN-ID is not found.

      -  Program the Forwarding Information Base (FIB) FIB such that when a unicast IP packet is received
         from an AC with its destination MAC address matching the
         advertised MAC address, the packet is forwarded out over the
         tunnel to the advertising PE with the advertised PW-label PW label as
         the inner label.

   A PE should process a received [PWE3-CONTROL] [RFC4447] advertisement with the PW
   type of Ethernet for IPLS as follows, follows:

      -  Verify the IPLS VPN membership by matching the VPN-Id VPN-ID signaled
         in the AGI field or the PW-ID PWid field with all the
          VPN-Ids VPN-IDs
         configured in the PE.  Discard and release the PW label if VPN-Id VPN-
         ID is not found.

      -  Add the PW-label PW label to the send broadcast replication tree for the VPN-Id.
         VPN-ID.  This enables the sending of a copy of a
         multicast/broadcast IP Ethernet frame or frame, ARP Ethernet frame frame, or
         Neighbor Discovery frames frame from the AC to this pseudowire.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

8. PW.

7.  IANA Considerations

   Since this document is being published as historic record, Historic, no
   requests for registration
   of IANA code points are is necessary.  However, if in the future, if
   interest to pursue this proposal arises, the following
   requests for IANA codes code
   registrations would become necessary.

8.1.

7.1.  LDP Status messages Messages

   This document uses a new LDP status code.  IANA already maintains a the
   "Status Code Name Space" registry of name "STATUS CODE NAME SPACE" defined by [RFC 5036]. [RFC5036].  The
   following value is suggested for assignment: allocation would be needed from the LDP Status Code Name
   Space.

             0x000000XX "MAC Address of CE is absent"

8.2.

7.2.  Interface Parameters

   This document proposes a new Interface Parameters sub-TLV, to be
   assigned from the 'Pseudowire "Pseudowire Interface Parameters Sub-TLV type
   Registry'.
   Registry".  The following value is suggested allocation would be needed for the
   Parameter ID:

   0xXX "Stack capability" Capability"

   IANA is would also be requested to set up a registry of an "L2VPN PE stack
   capabilities". Stack
   Capabilities" registry.  This is a 16 bit 16-bit field.  The Stack capability values
   0x000X
   Capability value (0x000X) is specified in Section 7. 6.2 of this
   document.  The remaining
   bitfield bit field values (0x0002,..,0x8000) are to would be
   assigned by IANA using the "IETF Consensus" policy defined in [RFC 5226].
   [RFC5226].

   L2VPN PE Stack Capabilities:

   Bit (Value)       Description
   ===============   ==========================================
   Bit 0  (0x000X) -   IPv6 stack capability
   Bit 1  (0x000X) -   Reserved
   Bit 2  (0x000X) -   Reserved
            .
            .
            .
   Bit 14 (0xX000) -   Reserved
   Bit 15 (0xX000) -   Reserved

9.0

8.  Forwarding

9.1

8.1.  Non-IP or non-ARP traffic Non-ARP Traffic

   In an IPLS VPN, a PE forwards only IP and ARP traffic.  All other
   frames are dropped silently.  If the CEs must pass non-IP traffic to
   each other, they must do so through IP tunnels that terminate at the
   CEs themselves.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

9.2

8.2.  Unicast IP Traffic

   In IPLS, IP traffic is forwarded from the AC to the PW based on the
   destination MAC address of the layer 2 L2 frame (and not based on the IP Header).
   header).

   The PE identifies the FIB associated with an IPLS instance based on
   the AC or the PW label.  When a frame is received from an AC, the PE
   uses the destination MAC address as the lookup key.  When a frame is
   received from a PW, the PE uses the PW-Label PW label as the lookup key.  The
   frame is dropped if the lookup fails.

   For IPv6 support, the unicast IP ICMP frame of Neighbor Discovery
   Protocol [RFC 4861] [RFC4861] is bi-casted; one copy is submitted to the control
   plane and other copy to the PW, based on the destination MAC address.

9.3

8.3.  Broadcasts and Multicast IP Traffic

   When the destination MAC address is either a broadcast or multicast, a
   copy of the frame is sent to the control plane for CE discovery
   purposes (see section 5.1). Section 4.1).  It is important to note that stricter
   rate-limiting criteria is applied to frames sent to the control
   plane, in order to avoid overwhelming it under adverse conditions
   such as Denial of Service attack. DoS attacks.  The service provider should also provide a
   configurable limitation to prevent the overflowing of the learned
   source addresses in a given IPLS instance.  Also, caution must be
   used such that only link local link-local multicasts and broadcast IP packets
   are sent to the control plane.

   When a multicast/broadcast IP packet is received from an AC, the PE
   replicates it onto the Send Multicast Replication Tree (See section
   6.3). (see Section
   5.3).  When a multicast/broadcast IP Ethernet frame is received from
   a pseudowire, PW, the PE forwards a copy of the frame to all the ACs associated
   with the respective IPLS VPN instance.  Note that 'multicast' PW uses
   Ethernet encapsulation and hence encapsulation; hence, it does not require additional header
   manipulations.

9.4

8.4.  ARP Traffic

   When a broadcast ARP frame is received over the AC, a copy of the
   frame is sent to the control plane for CE discovery purposes.  The PE
   replicates the frame onto the Send Multicast Replication Tree (see
   section 6.3),
   Section 5.3), which results into in a copy to be delivered to all the
   remote PEs on the 'multicast' PW and other local CEs through the
   egress ACs.

   When a broadcast Ethernet ARP frame is received over the 'multicast'
   PW, a copy of the Ethernet ARP frame is sent to all the ACs
   associated with the IPLS instance.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   When a unicast Ethernet ARP frame is received over the AC, a copy of
   the frame is sent to the control plane for CE discovery purposes.
   The PE may optionally do destination MAC DA address lookup in the
   forwarding table and send the ARP frame to a specific egress
   interface (AC or 'multicast' PW to a remote PE) or replicate the
   frame onto the Send Multicast Replication Tree (see section 6.3). Section 5.3).

   When a unicast ARP Ethernet frame is received over the 'multicast'
   PW, the PE may optionally do destination MAC DA address lookup in the
   forwarding table and forward it to the AC where the CE is located.
   If the CE is not accessible through any local AC, the frame is
   dropped.  Conversely, the PE may simply forward the frame to all the
   ACs associated with that IPLS instance without any lookup in the
   forwarding table.

9.5

8.5.  Discovery of IPv6 CE devices Devices

   A PE device that supports IPv6 MUST be capable of, of:

      -  Intercepting ICMPv6 Neighbor Discovery [RFC 4861] [RFC4861] packets
         received over the AC.

      -  Record  Recording the IPv6 interface addresses and CE link-layer
         addresses present in these packets

      -  Forward  Forwarding them towards the original destination destination.  A PE device
         may also intercept Router Discovery packets in order to
         discover the link layer link-layer address and IPv6 interface address(es)
         of the CE. Following  The following sections describe the details.

   The PE device MUST learn the link-layer address of the local CE and
   be able to use it when forwarding traffic between CEs.  The PE MAY
   also wish to monitor the source link-layer address of data packets
   received from the CE, CE and discard packets not matching its learned CE
   link-layer address.  The PE device may also optionally learn a list
   of CE IPv6 interface addresses for its directly-attached directly attached CE.

9.5.1.

8.5.1.  Processing of Neighbor Solicitations

   When a broadcast Neighbor Solicitation multicast NS frame is received over the AC, a copy of the
   frame is sent to the control plane for CE discovery purposes.  The PE
   replicates the frame onto the Send Multicast Replication Tree (see section 6.3),
   Section 5.3), which results in a copy to be delivered to all the
   remote PEs on the 'multicast' PW and other local CEs through the
   egress ACs.  The PE may optionally learn an IPv6 interface address
   (If provided - -- this will not be the case for Duplicate Address
   Detection) when present.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

   When a broadcast multicast Ethernet Neighbor Solicitation NS frame is received over the 'multicast'
   PW, a copy is sent to all the ACs associated with the IPLS instance.

9.5.2

8.5.2.  Processing of Neighbor Advertisements

   When a unicast Neighbor Advertisement NA is received over the AC, a copy of the frame is
   sent to the control plane for the CE discovery purposes.  The PE may
   optionally do destination MAC DA address lookup in the forwarding table
   and send the Neighbor Advertisement NA frame to a specific egress interface (AC or
   'multicast' PW to a remote PE) or replicate the frame onto the Send
   Multicast Replication Tree (see section 6.3). Section 5.3).

   Optionally, the PE could learn the IPv6 Interface address of the CE.

   When a unicast Neighbor Advertisement NA frame is received over the 'multicast' PW, the PE
   may optionally do destination MAC DA address lookup in the forwarding
   table and forward it to the AC where the CE is located.  If the CE is
   not accessible through any local AC, the frame is dropped.
   Conversely, the PE may simply forward the frame to all the ACs
   associated with that IPLS instance without any lookup in the
   forwarding table.

9.5.3

8.5.3.  Processing of Inverse Neighbor Solicitations and Advertisement

   Inverse Neighbor Discovery is typically used on non-broadcast links,
   but are is allowed on broadcast links too [RFC 3122]. as well [RFC3122].  A PE may
   optionally intercept Inverse Neighbor Solicitation and Advertisement
   and learn the MAC and IPv6 interface address list of the attached CE
   from the copy of the frame sent to the control plane.  The PE may
   optionally do destination MAC
   DA address lookup in the forwarding table
   and send another copy of the frame to a specific egress interface (AC
   or 'multicast' PW to a remote PE) or replicate the frame onto the
   Send Multicast Replication Tree (see
   section 6.3).

9.5.4 Section 5.3).

8.5.4.  Processing of Router Solicitations and Advertisements

   Router Solicitations (RS)

   RSs are multicast while Router Advertisement
   (RA) RAs can be unicast or multicast Ethernet
   frames.  The PE could optionally intercept RS and RA frames and send
   a copy to the control plane.  The PE may learn the MAC address and a
   list of interface addresses for the attached CE.

   For unicast RA, the PE may optionally do destination MAC DA address
   lookup in the forwarding table and send the Neighbor Advertisement RA frame to a specific
   egress interface (AC or 'multicast' PW to a remote PE) or replicate
   the frame onto the Send Multicast Replication Tree (see
   section 6.3). Section 5.3).
   The multicast RA and RS Ethernet frames are replicated using the Send
   Multicast Replication Tree as described in section
   6.3.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

9.6 Section 5.3.

8.6.  Encapsulation

   The Ethernet MAC header of a unicast IP packet received from an AC is
   stripped before forwarding the frame to the unicast pseudowire. PW.  However, the
   MAC header is retained for the following cases,
     .

      -  when a frame is a unicast or broadcast IP packet that is directed to one or more a local AC(s).
     .
         AC.

      -  when a frame is a broadcast broadcast/multicast IP packet
     .

      -  when a frame is an ARP packet
     .

      -  when a frame is Neighbor/Router Solicitation/Advertisement

   An IP frame received over a unicast pseudowire PW is prepended with a MAC header
   before transmitting it on the appropriate AC(s).  The fields in the
   MAC header are filled in as follows:

      -  The destination MAC address is the MAC address associated with
         the PW label in the FIB FIB.

      -  The source MAC address is the PE's own local MAC address or a
         MAC address which that has been specially configured on the PE for
         this use.

      -  The Ethernet Type field is 0x0800 if IPv4 or 0x86DD if IPv6
          [RFC 2464]
         [RFC2464].

      -  The frame may be IEEE802.1Q IEEE 802.1Q tagged based on the VLAN
         information associated with the AC.

   An FCS

   A Frame Check Sequence (FCS) is appended to the frame.

10.0

9.  Attaching to IPLS via ATM or FR Frame Relay (FR)

   In addition to (i) an Ethernet port and a (ii) combination of
   Ethernet port and a VLAN ID, an AC to IPLS may also be (iii) an ATM
   or FR VC Virtual Circuit (VC) carrying encapsulated bridged Ethernet
   frames or (iv) the combination of an ATM or FR VC and a VLAN ID.

   The ATM/FR VC is just used as a way to transport Ethernet frames
   between a customer site and the PE.  The PE terminates the ATM/FR VC
   and operates on the encapsulated Ethernet frames exactly as if those
   were received on a local Ethernet interface.  When a frame is
   propagated from pseudowire PW to a an ATM or FR VC VC, the PE prepends the Ethernet
   frame with the appropriate bridged encapsulation header as defined in [RFC 2684]
   [RFC2684] and [RFC 2427] [RFC2427], respectively.  Operation of an IPLS over
   ATM/FR VC is exactly as described above, with the exception that the
   AC is then identified via the ATM VCI/VPI or Frame Relay DLCI Data Link
   Connection Identifier (DLCI) (instead of via a local Ethernet port
   ID), or a combination of those with a VLAN ID.

11.0

10.  VPLS vs vs. IPLS

   The VPLS approach proposed in [VPLS] [RFC4762] provides VPN services for IP
   as well as other protocols.  The IPLS approach described in this draft
   document is similar to VPLS in many respects:

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

      -  It provides a Provider Provisioned Provider-Provisioned Virtual LAN service with
         multipoint capability where a CE connected via a single
         attachment circuit can reach many remote CEs

      -  It appears as a broadcast domain and a single subnet

      - forwarding  Forwarding is based on destination MAC addresses

   However, unlike VPLS, IPLS is restricted to IP traffic only.  By
   restricting the scope of the service to the predominant type of
   traffic in today's environment, IPLS eliminates the need for service
   provider edge routers to implement some bridging functions such as
   MAC address learning in the data path (by, instead, distributing MAC
   information in the control plane). Thus  Thus, this solution offers a
   number of benefits:

      - Facilitates  It facilitates Virtual LAN services in instances where PE
         devices cannot or cannot efficiently (or are specifically
         configured not to) perform MAC address learning.

      -  Unknown Unicast frames are never flooded as would be the case
         in VPLS.

      -  Encapsulation is more efficient (MAC (the MAC header is stripped)
         for unicast IP packets while traversing the backbone network.

      -  PE devices are not burdened with the processing overhead
         associated with traditional bridging (e.g., STP Spanning Tree
         Protocol (STP) processing, etc.).  Note, however, that some of
         these overheads (e.g., STP processing) could optionally be turned-off
         turned off with a VPLS solution in the case where it is known
         that only IP devices are interconnected.

      -  Loops (perhaps through backdoor links) are minimized since a PE
         could easily reject (via label release) a duplicate IP to MAC
         address advertisement.

      -  Greater control over CE topology distribution.

12.0 distribution is available.

11.  IP Protocols

   The solution described in this document offers IPLS service for IPv4
   and IPv6 traffic only.  For this reason, the MAC Header header is not
   carried over the unicast pseudowire. PW.  It is reconstructed by the PE when
   receiving a packet from a unicast pseudowire PW and the Ethertype 0x0800 or
   0x86DD is used in the MAC Header header since IPv4 or IPv6 IPv6, respectively, is
   assumed.

   However, this solution may be extended to carry other types of
   important traffic such as ISIS IS-IS , which does not use Ethernet-II,
   EtherType based an
   EtherType-based header.  In order to permit the propagation of such
   packets correctly, one may create a separate set of pseudowires, PWs, or pass
   protocol information in the "control word" of a "multiprotocol"
   pseudowire, PW,
   or encapsulate the Ethernet MAC Header header in the
   pseudowire. PW.  The selection of
   appropriate multiplexing/demultiplexing schemes is the subject of
   future study.  The current document focuses on IPLS service for IPv4
   and IPv6 traffic.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

13.0 Dual Homing

12.  Dual-Homing with IPLS

   As stated in previous sections, IPLS prohibits the connection of a
   common LAN or VLAN to more than one PE.  However, the CE device
   itself can connect to more than one instance of IPLS through two
   separate LAN or VLAN connections to separate PEs.  To the CE IP
   device, these separate connections appear as connections to two IP
   subnets.  The failure of reachability through one subnet is then
   resolved via the other subnet using IP routing protocols.

14.0

13.  Proxy ARP function Function

   The earlier version of this proposal used IP-PW to carry both the
   broadcast/multicast and unicast IP traffic.  It also discussed how PE
   proxy functionality responds to the ARP requests of the local CE on
   behalf of remote CE.  The current version of the draft document eliminated
   these functions and instead uses Ethernet PW to carry broadcast,
   multicast and ARP frames to remote PEs.  The motivation to use
   Ethernet PW and propagate ARP frames in the current version is to
   support configuration like back-to-back IPLS (similar to Inter
   AS Inter-AS
   option-A configurations in [RFC 4364]). [RFC4364]).

   The termination and controlled propagation of ARP frames is still a
   desirable option for security, DoS DoS, and other purposes.  For these
   reasons, we re-introduce reintroduce the ARP Proxy [PROXY-ARP] [RFC925] function in this
   revision as an optional feature. Following  The following sections describe
   this option.

14.1

13.1.  ARP Proxy - Responder

   As a local configuration, a PE can enable the ARP Proxy responder Responder
   function.  In this mode, the local PE responds to ARP requests
   received over the Attachment Circuit via learnt learned IP and MAC address
   associations, which are advertised by the remote PEs.  In addition,
   the PE may utilize local policies to determine if ARP requests should
   be responded based on the source of the ARP request, rate at which
   the ARP requests are generated, etc.  In a nutshell, when this
   feature is enabled, ARP requests are not propagated to remote PE
   routers that are members of the same IPLS instance.

14.2

13.2.  ARP Proxy - Generator

   As a local configuration, a PE can enable the ARP Proxy generator Generator
   function.  In this mode, the PE generates an ARP request for each IP
   and MAC address associations association received from the remote PEs.  The remote
   CE's IP and MAC address is used as the source information in the ARP
   request while the destination IP address in the request is obtained
   from the local configuration (that is, user needs to configure an IP
   address when this feature is enabled).  The ARP request is sent on
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt
   the Attachment Circuits ACs that have ARP Proxy Generator enabled and is associated with
   the given IPLS instance.

   In addition, the PE may utilize local policies to determine which
   IP/MAC addresses are candidate for ARP request generation.

   The ARP Proxy Generator feature is required to support back-to-back
   IPLS configuration when any member of the IPLS instance is using the
   ARP Proxy Responder function.  An example of a back-to-back IPLS is a
   configuration where PE-1 (ASBR) in an IPLS cloud in one Autonomous
   System (say, AS-1) is connected via an Attachment Circuit AC to another PE-2 (ASBR) in
   an IPLS cloud in another Autonomous System (say, AS- 2) where each PE
   appears as CE to each other.  Such configuration is described in [RFC 4364]
   [RFC4364] as option-A for inter-AS connectivity.  The Proxy ARP responder
   Responder feature prevents propagation of ARP requests to PE-1 (ASBR)
   in AS-1.  This necessitates that PE-1 (ASBR) in AS-1
   generate generates an ARP
   request on behalf of each CE connected to the IPLS instance in AS-1
   as a mean to 'advertise' the reachability to IPLS cloud in AS-2

15.0 AS-2.

14.  Data Center Applicability

   The resurgence of interest in providing IP/MPLS based an IP/MPLS-based solution for
   Data Center Networks (DCN) (DCNs) deserves another look at the IPLS
   methodologies described in this document.  The key requirement of a
   DCN to permit VM Virtual Machine (VM) mobility within or across a DCN necessiates
   necessitates extending the reachability of IP subnet over a LAN,
   transparently.  In addition, VMs tendency to generate frequent gratutious
   gratuitous ARPs for location discovery necessiates necessitates a solution that
   curbs broadcasts closest to the source.

   The IPLS solution facilitates VM mobility by the PE closest to the
   new location signaling the MAC address to all remote peers.  In
   addition, control-plane based control-plane-based MAC learning mechanisms prevent
   flooding of unknown unicast across a DCN.  The optional ARP proxy
   mechanisms further reduces reduce ARP broadcast floods by preventing its
   reach across a local PE.

16.0 Acknowledgements

   Authors would like to thank Alp Dibirdi from Alcatel, Xiahou from
   Huawei and other L2VPN working group members for their valuable
   comments.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

17.0

15.  Security Considerations

   A more comprehensive description of the security issues involved in
   L2VPNs are covered in [VPN-SEC]. [RFC4111].  Most of the security issues can be
   avoided through implementation of appropriate guards.  The security
   aspect of this solution is addressed for two planes; planes: the control
   plane and data plane.

17.1 Control plane security

15.1.  Control-Plane Security

   The control plane control-plane security pertains to establishing the LDP
   connection, pseudo-wire PW establishment and CE's IP and MAC 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 by
   verifying keyed digests.  The pseudo-wire PW 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 PW type and
   other pseudo-wire PW options may prevent mis-
   wiring mis-wiring due to configuration errors.

   The learning of the appropriate CE's IP and MAC address can be a
   security issue.  It is expected that the local attachment circuit to
   CE be physically secured.  If this is a concern, the PE must be
   configured with the CE's IP and MAC address.  During each ARP frame
   processing, the PE must verify the received information against the
   configuration before accepting.  This prevents theft of service,
   denial of service to a subscriber subscriber, or DoS attacks to all subscribers
   by malicious use of network services.

   The IPLS also provides MAC anti spoofing anti-spoofing by preventing the use of
   already known MAC address.  For instance, if a PE has already learned
   a presence of a CE through a local connection or from another PE, and
   subsequently an advertisement for the same MAC and/or IP address is
   received from a different PE, the receiving PE can terminate service
   to that CE (either through label release and/or removing the ARP
   entry from the FIB) and raise the alarm.

   The IPLS learns and distributes CE reachability through the control
   plane.  This provides greater control over CE topology distribution
   through the application of local policies.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

17.2 Data plane security

15.2.  Data-Plane Security

   The data traffic between the CE and PE is not encrypted and encrypted.  In an
   insecure environment, it is possible that in an insecure environment, a malicious user may tap
   into the CE to PE CE-to-PE connection and could conduct an active or passive
   attack.  An example of an active attack would be generating traffic
   using the spoofed destination MAC address on the Ethernet Attachment
   Circuit and a passive attack could include targeted or passive
   monitoring between the CE and PE.  In order to avoid such hijacking,
   the 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 the PW only when authenticity is verified.  When
   spoofing is detected, the PE must severe sever the connection with the local
   CE, tear down the PW PW, and start over.

   Each IPLS instance uses its own FIB.  This prevents leaking of one
   customer data into another.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

18.0

16.  References

18.1

16.1.  Normative References

   [ARP] RFC 826, STD 37, D.

   [IEEE802.1D]   ISO/IEC 10038, ANSI/IEEE Std 15802-3:1998, "MAC
                  Bridges".

   [RFC826]       Plummer, "An Ethernet D., "Ethernet Address Resolution
         Protocol".

   [PWE3-CONTROL] L. Martini et al., "Pseudowire Setup and Maintenance
                  using LDP", Protocol: Or
                  Converting Network Protocol Addresses to 48.bit
                  Ethernet Address for Transmission on Ethernet
                  Hardware", STD 37, RFC 826, November 1982,
                  <http://www.rfc-editor.org/info/rfc826>.

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997,
                  <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]      Crawford, M., "Transmission of IPv6 Packets over
                  Ethernet Networks", RFC 2464, December 1998,
                  <http://www.rfc-editor.org/info/rfc2464>.

   [RFC3122]      Conta, A., "Extensions to IPv6 Neighbor Discovery for
                  Inverse Discovery Specification", RFC 4447.

   [PWE3-IANA] L. Martini et al,. 3122, June 2001,
                  <http://www.rfc-editor.org/info/rfc3122>.

   [RFC4446]      Martini, L., "IANA Allocations for pseudo Wire Pseudowire Edge to
                  Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006,
                  <http://www.rfc-editor.org/info/rfc4446>.

   [RFC4447]      Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T.,
                  and G. Heron, "Pseudowire Setup and Maintenance Using
                  the Label Distribution Protocol (LDP)", RFC 4446.

   [PWE3-ETH] Martini et al., 4447,
                  April 2006, <http://www.rfc-editor.org/info/rfc4447>.

   [RFC4448]      Martini, L., Ed., Rosen, E., El-Aawar, N., and G.
                  Heron, "Encapsulation Methods for Transport of
                  Ethernet over MPLS Networks", RFC 4448.

   [VPLS] Lasserre et al, "Virtual Private LAN Service Using LDP", RFC
          4762, January 2007.

   [RFC 5036]  Andersson, L., Ed., Minei, I., 4448, April 2006,
                  <http://www.rfc-editor.org/info/rfc4448>.

   [RFC4762]      Lasserre, M., Ed., and B. Thomas, V. Kompella, Ed.,
              "LDP Specification", "Virtual
                  Private LAN Service (VPLS) Using Label Distribution
                  Protocol (LDP) Signaling", RFC 5036, October 2007.

   [IEEE 802.1D] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993, "MAC
                 Bridges".

   [RFC 4861] 4762, January 2007,
                  <http://www.rfc-editor.org/info/rfc4762>.

   [RFC4861]      Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                  "Neighbor Discovery for IP version 6 (IPv6)", RFC
                  4861, September 2007.

   [RFC 2464] Crawford, M., "Transmission of IPv6 packets over
              Ethernet Networks", RFC 2464, December 1998.

   [RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
              Inverse Discovery 2007,
                  <http://www.rfc-editor.org/info/rfc4861>.

   [RFC5036]      Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
                  Ed., "LDP Specification", RFC 3122, June 2001.

   [RFC 5226] 5036, October 2007,
                  <http://www.rfc-editor.org/info/rfc5036>.

   [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  5226, May 2008.

   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

18.2 2008,
                  <http://www.rfc-editor.org/info/rfc5226>.

16.2.  Informative References

   [L2VPN-FWK]

   [ADDR-IANA]    IANA, "Address Family Numbers",
                  http://www.iana.org/assignments/address-family-
                  numbers/.

   [RFC925]       Postel, J., "Multi-LAN address resolution", RFC 925,
                  October 1984, <http://www.rfc-editor.org/info/rfc925>.

   [RFC2427]      Brown, C. and A. Malis, "Multiprotocol Interconnect
                  over Frame Relay", STD 55, RFC 2427, September 1998,
                  <http://www.rfc-editor.org/info/rfc2427>.

   [RFC2684]      Grossman, D. and J. Heinanen, "Multiprotocol
                  Encapsulation over ATM Adaptation Layer 5", RFC 2684,
                  September 1999,
                  <http://www.rfc-editor.org/info/rfc2684>.

   [RFC4111]      Fang, L., Ed., "Security Framework for Provider-
                  Provisioned Virtual Private Networks (PPVPNs)", RFC
                  4111, July 2005,
                  <http://www.rfc-editor.org/info/rfc4111>.

   [RFC4364]      Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
                  Networks (VPNs)", RFC 4364, February 2006,
                  <http://www.rfc-editor.org/info/rfc4364>.

   [RFC4664]      Andersson, L., Ed., and E. Rosen, Ed., "Framework for
                  Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
                  September 2006.

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

   [L2VPN-REQTS] 2006,
                  <http://www.rfc-editor.org/info/rfc4664>.

   [RFC4665]      Augustyn, W. et.al W., Ed., and Y. Serbest, Ed., "Service
                  Requirements for Layer 2
                 Provider Provisioned Provider-Provisioned Virtual
                  Private Networks", RFC 4665, September 2006.

   [L2VPN-SIG] Rosen et al., "Provisioning, Autodiscovery, 2006,
                  <http://www.rfc-editor.org/info/rfc4665>.

   [RFC5771]     Cotton, M., Vegoda, L., and
               signaling in L2VPN", RFC 6074, Jan 2011.

   [RFC-1112] Deering, S., "Host Extensions D. Meyer, "IANA Guidelines
                  for IP Multicasting", IPv4 Multicast Address Assignments", BCP 51, RFC
              1112, August, 1989.

   [RFC 2684] Grossman, et al., "Multiprotocol Encapsulation over ATM
              Adaptation
                  5771, March 2010,
                  <http://www.rfc-editor.org/info/rfc5771>.

   [RFC6074]      Rosen, E., Davie, B., Radoaca, V., and W. Luo,
                  "Provisioning, Auto-Discovery, and Signaling in Layer 5", September 1999.

   [RFC 2427] Brown, et al., "Multiprotocol Interconnect over Frame
              Relay", September 1998.

   [RFC 4364] Rosen et al., "BGP/MPLS IP Virtual Private Network
              (VPNs)", February 2006.

   [VPN-SEC] Fang, L., "Security framework for Provider Provisioned
                  2 Virtual Private Networks", Networks (L2VPNs)", RFC 4111, July 2005.

   [ADDR-IANA] http://www.iana.org/assignments/address-family-numbers/
             address-family-numbers.xhtml
   Internet Draft    draft-ietf-l2vpn-ipls-16.txt

18.0 Author's Address 6074,
                  January 2011,
                  <http://www.rfc-editor.org/info/rfc6074>.

Acknowledgements

   Authors would like to thank Alp Dibirdi from Alcatel, Xiaohu Xu from
   Huawei, and other L2VPN working group members for their valuable
   comments.

Contributors

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

   K. Arvind                    Fortress
   Vach Kompella                Alcatel-Lucent
   Matthew Bocci                Alcatel-Lucent
   Shane Amante                 Apple

Authors' Addresses

   Himanshu Shah
   Ciena Corp
   3939 North 1st Street, Street
   San Jose, CA 95110
   Email:
   United States

   EMail: hshah@ciena.com

   Eric Rosen
   Cisco Systems
   300 Apollo Drive,
   Chelmsford, MA 01824
   Email: erosen@cisco.com

   Giles Heron
   Cisco Systems
   Email: giheron@cisco.com
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA, 01886
   United States

   EMail: erosen@juniper.net

   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side -
   Batiment T3
   400, Avenue de Roumanille
   06410 Biot-Sophia Antipolis, D, 45 Allee des Ormes
   06254 Mougins
   France
   Email:

   EMail: flefauch@cisco.com

   Giles Heron
   Cisco Systems
   9-11 New Square
   Bedfont Lakes
   Feltham
   Middlesex
   TW14 8HA
   United Kingdom

   EMail: giheron@cisco.com