RFC 7436

IP-Only LAN Service (IPLS)

📅 published January 2015, from ietf

RFC 7436: IP-Only LAN Service (IPLS) ✨

okay bestie, this one is a historic record, so grab a snack 🍓

The Title Block 🎀

Series: Internet Engineering Task Force (IETF) 🌈
Category: Historic 🕰️
Date: January 2015 📅
ISSN: 2070-1721
Authors:
- H. Shah, Cinea Corp. 💜
- E. Rosen, Juniper Networks 💜
- F. Le Faucheur, Cisco Systems 💜
- G. Heron, Cisco Systems 💜
Obsoletes: nothing listed in the header 🙈
Updates: nothing listed in the header 🙈

Abstract ✨

okay so a Virtual Private LAN Service (VPLS) is how you connect systems across a wide-area or metropolitan-area network so it looks like they're all on one private LAN 🔗. The systems being connected can be LAN switches, which is totally fine, but if they're IP hosts or IP routers, you can simplify the VPLS a bunch 💅. This document calls that simplified version an "IP-only LAN Service" (IPLS) 🦋.

It's giving VPLS vibes: LAN interfaces run in promiscuous mode, and frames get forwarded based on their destination Media Access Control (MAC) addresses 👀. The twist is how the MAC forwarding tables get built. Instead of using the MAC address learning procedures from the IEEE's "Media Access Control (MAC) Bridges", the tables are maintained through signaling 📡. This doc spells out the protocol extensions and procedures needed to support IPLS, so it's a whole main-character spec 👑.

Now the tea ☕. The original goal was to give Provider Edge (PE) routers that couldn't learn MAC addresses through the data plane an alternate option to VPLS 🙃. Then newer hardware showed up and that problem just... vanished 💀. But the ideas here are still iconic and newer work has picked them up in one form or another, like Ethernet VPN in the L2VPN working group, and possibly data center stuff too 🌸. So no further action is planned for this document. It's getting published purely as a historic record of the ideas 🫶.

Status of This Memo 📜

Real talk: this document is not an Internet Standards Track specification. It's being published for the historical record 🕰️.

It defines a Historic Document for the Internet community 🌍. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🙌. Not every IESG-approved document is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for that 🔍.

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7436 🔗.

Copyright Notice ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication 📚. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🧐. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.

Table of Contents 🗺️

   1. Overview ........................................................4
      1.1. Terminology ................................................7
   2. Topology ........................................................9
   3. Configuration ..................................................10
   4. Discovery ......................................................10
      4.1. CE Discovery ..............................................10
           4.1.1. IPv4-Based CE Discovery ............................11
           4.1.2. IPv6-Based CE Discovery (RFC 4861) .................11
   5. PW Creation ....................................................11
      5.1. Receive Unicast Multipoint-to-Point PW ....................11
      5.2. Receive Multicast Multipoint-to-Point PW ..................12
      5.3. Send Multicast Replication Tree ...........................13

   6. Signaling ......................................................13
      6.1. IPLS PW Signaling .........................................13
      6.2. IPv6 Capability Advertisement .............................17
      6.3. Signaling Advertisement Processing ........................18
   7. IANA Considerations ............................................19
      7.1. LDP Status Messages .......................................19
      7.2. Interface Parameters ......................................19
   8. Forwarding .....................................................20
      8.1. Non-IP or Non-ARP Traffic .................................20
      8.2. Unicast IP Traffic ........................................20
      8.3. Broadcasts and Multicast IP Traffic .......................20
      8.4. ARP Traffic ...............................................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
   9. Attaching to IPLS via ATM or Frame Relay (FR) ..................24
   10. VPLS vs. IPLS .................................................24
   11. IP Protocols ..................................................25
   12. Dual-Homing with IPLS .........................................25
   13. Proxy ARP Function ............................................26
      13.1. ARP Proxy - Responder ....................................26
      13.2. ARP Proxy - Generator ....................................26
   14. Data Center Applicability .....................................27
   15. Security Considerations .......................................27
      15.1. Control-Plane Security ...................................27
      15.2. Data-Plane Security ......................................28
   16. References ....................................................29
      16.1. Normative References .....................................29
      16.2. Informative References ...................................30
   Acknowledgements ..................................................31
   Contributors ......................................................31
   Authors' Addresses ................................................32

Part 1 of 7 wrapped up, bestie 🧚 Section 1 comes next in the following part, and it's where the real protocol fun starts 💜

1. Overview ✨

okay so bestie, first things first 💅 Ethernet has totally taken over as the access tech in metro and wide-area networks, and [RFC4762] is the one that explains how far-apart customer LANs can get linked up over a service provider's network 🌍. VPLS is the service doing that, and it's run by Provider Edge (PE) devices plugged into Customer Edge (CE) devices. The VPLS architecture makes it work by putting bridging stuff like MAC address learning right inside the PE devices 🧠

Here's the tea 🫖 PE platforms are built to be IP routers, not LAN switches. So to give a PE router VPLS powers, you'd have to bolt on MAC-address-learning, plus aging and other Ethernet-switch mechanisms [IEEE802.1D]. That can get pretty complicated to fit into an IP router's forwarding plane 😵‍💫 [RFC4664] points out that when the CE devices are NOT LAN switches (they're IP hosts or IP routers instead), you can offer VPLS-style service without MAC learning and aging on the PE 🙌 The PE just has to match the destination MAC address of a packet coming from a CE to an outbound pseudowire (PW). The requirements for the IPLS service are in [RFC4665], and this document is here to specify a solution that's tuned specifically for IPLS 🎀

IPLS gives you a VPLS-like service using PE routers that weren't made for general LAN bridging 🦋 The catch is that an IPLS can only carry IP traffic, and you can't use it to connect CE devices that are LAN switches themselves. Honestly that's totally fine in lots of environments, since IP is the main traffic type on today's networks 💖

The original goal was an alternative to VPLS for PE routers that couldn't learn MAC addresses in the data plane. Then newer hardware showed up and that stopped being a problem 📱 But the ideas in this document still matter, and newer work like Ethernet VPN in the L2VPN working group, plus possible data center uses, has adopted them in one form or another 🌸 Right now no further action is planned to update this document, so it's published purely as a historic record of the ideas 📜

In IPLS, a PE device does multipoint LAN connectivity for IP traffic using these key functions:

CE Address Discovery: Each PE device discovers the MAC address of the locally attached 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).
Pseudowire (PW) for Unicast Traffic: For each locally attached CE device in a given IPLS instance, a PE device sets up a pseudowire (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 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 PWs carry traffic only in one direction. Further, while the 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 PW.

Pseudowires for Multicast Traffic: In addition, every PE supporting a given IPLS instance will set up a special '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, and ICMP (Inverse) Neighbor Discovery (ND/IND) packets for IPv6. 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.

Signaling: The necessary pseudowires can be set up and maintained using the signaling procedures based on the Label Distribution Protocol (LDP) described in [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.

ARP Packet Forwarding: ARP packets [RFC826] are forwarded from the attachment circuit (AC) to 'multicast' pseudowires in the Ethernet frame format as described by [RFC4448]. The following rules are observed when processing ARP 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.

ICMP IPv6 ND/IND-related Packet Forwarding: 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 the control plane to learn the MAC address and, optionally, corresponding IPv6 addresses.
Multicast IP packet forwarding: An IP Ethernet frame received from an AC is replicated to other ACs and the 'multicast' PWs associated with the IPLS instance. An IP Ethernet frame received from a 'multicast' PW is replicated to all the egress ACs associated with the IPLS instance.
Unicast IP packet forwarding: An IP packet received from the AC is forwarded based on the destination MAC 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 PW, the packet is sent without a MAC header. If the egress interface is a local AC, the Ethernet frame is forwarded as such. An IP packet received from the unicast PW is forwarded to the egress AC with the MAC header prepended. The destination MAC address is derived from the forwarding table while the source MAC address is the MAC address of the PE.

Both 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); whereas, in IPLS, MAC entries are placed in the FIB as a result of 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.

The following sections describe the details of the IPLS scheme 🫶

1.1. Terminology ✨

okay so first, the key word rule 💅 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document mean what [RFC2119] says they mean 🎀

Here's the glossary, bestie 🦋

IPLS: IPLS stands for IP-only LAN service, which is a type of Virtual Private LAN Service that only carries IP traffic 🌸
MP2P PW: A Multipoint-to-Point Pseudowire is a PW that carries traffic from remote PE devices to a PE device that signals the PW. The signaling PE device advertises the same PW label to all remote PE devices that take part in the IPLS service instance. In IPLS, for a given IPLS instance, a PE sets up an MP2P PW for IP unicast traffic for each CE device locally attached to that PE. It's a unidirectional tree 🌳 whose leaves are 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. It's giving tree energy ✨
Multicast PW: A Multicast/broadcast Pseudowire is a special kind of 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 sets up exactly one multicast PW. Multicast PW uses Ethernet encapsulation. 💜
Unicast PW: A Unicast pseudowire carries IP unicast packets. A PE creates a unicast PW for each locally attached CE. The unicast PW uses IP Layer 2 (L2) transport encapsulation. 🧚
CE: In this document, a Customer Edge (CE) is any IP node (host or router) connected to the IPLS LAN service. Obsessed with how broad that is 😭
Send Multicast Replication Tree: The collection of all multicast PWs and ACs that are members of an IPLS service instance on a given PE. When a PE receives a multicast/broadcast packet from an AC, the PE device sends a copy of the packet to every multicast PW and AC of the 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 Send Multicast Replication Tree and never to other PWs. Never to other PWs, periodt 🙈
(I)ND: (Inverse) Neighbor Discovery in IPv6 uses ICMP Neighbor Solicitation (NS) and Neighbor Advertisement (NA) packets. 🍓
RS: Router Solicitation is when hosts generate all-routers multicast ICMP packets to discover the IPv6 router on the local link. 🌈
RA: Router Advertisement happens when a router generates all-nodes multicast ICMP 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. 🔍
NA: Neighbor Advertisement in IPv6 uses (unicast) ICMP packets to respond to NS. 💌

2. Topology ✨

okay the CE devices are IP nodes (hosts or routers) that connect to PE devices either directly or through an Ethernet network. We assume the PE/CE connection can be seen by the PE as an "interface" that one or more CEs are attached to. That interface can be a physical LAN interface or a VLAN. The PE routers are MPLS Label Edge Routers (LERs) that act as PW endpoints. Main character PE energy 👑

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

In the diagram above, there's an IPLS instance with three sites: site S1, site S2, and site S3. At site S3, the CE device is directly connected to its PE. At the other two sites, multiple CEs connect to a single PE. To be more precise, the CEs at these sites are on an Ethernet network (switched at site 1 and shared at site 2) or VLAN, and the PE is attached to that same Ethernet network or VLAN). Here's the rule we're putting on this 🚨: if one or more CEs attach to a PE because they're on a common LAN or VLAN, there MUST NOT be more than one PE on that LAN or VLAN. Non-negotiable, bestie 💀

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

An IPLS instance is a single broadcast domain, so each IP end station (e.g., IPa) appears to be co-located with the other IP end stations (e.g., IPb through IPf) on the same subnet. The IPLS service is transparent to the CE devices and doesn't require any changes to them. Iconic invisibility 🫶

3. Configuration ✨

each PE router is configured with one or more IPLS service instances, and every IPLS service instance is tied to a unique VPN-ID. For a given IPLS service instance, a set of ACs gets identified. Each AC can be associated with only one IPLS instance. In this document, an AC 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. Tiny detail, big vibes 🎀

The PE router can optionally be configured with a local MAC address to use as the source MAC address when IP packets are forwarded from a PW to an AC. By default, a PE uses the MAC address of the customer-facing Ethernet interface for this purpose. Default is giving reliable 💖

4. Discovery ✨

The discovery process includes:

Remote PE discovery
VPN (i.e., IPLS) membership discovery
IP CE end station discovery

This document doesn't cover remote PE discovery or VPN membership discovery. That info can be user configured, or it can be obtained using the auto-discovery techniques in [RFC6074] or other methods. However, discovering the CE is a super important operational step in the IPLS model, so we describe it below 🔍

4.1. CE 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 checks each multicast/broadcast Ethernet frame. For link-local IP broadcast/multicast frames (e.g., IPv4 packets with destination addresses within 224.0.0/24 [RFC5771]), the CE's (source) MAC address is pulled from the Ethernet header, and the (source) IP address is taken from the IP header. Detective work, lowkey iconic 🧚

For each CE, the PE keeps track of the following tuple: <Attachment Circuit identification info, VPN-ID, MAC address, IP address (optional)> 📝

4.1.1. IPv4-Based CE Discovery

as mentioned earlier, a copy of each ARP frame received over the AC is sent 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. Ghosting detection, ngl 👻

4.1.2. IPv6-Based CE Discovery (RFC 4861)

A copy of Neighbor and Router Discovery frames received over the AC is sent to the control plane in the PE. Ten out of ten for the plumbing 🌸

If the PE receives 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 NA message, the PE learns the source MAC address and optionally the IP address of the CE.

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

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

The PE will periodically generate NS messages for the IP address of the CE to verify that the address and its MAC address binding still exist. 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. Checking in on the CE like a good bestie 🫶

5. PW Creation ✨

As the PE discovers each locally attached CE, a unicast multipoint-to-point pseudowire (MP2P PW) that's associated exclusively with that CE gets created. It's made by distributing the MAC address and optionally the IP address of the CE, along with a PW label, to all the remote PE peers that take part in the same IPLS instance. Note that the same value of a PW label SHOULD be distributed to all the remote PE peers for a given CE. The MP2P PW created this way is used by remote PEs to send unicast IP traffic to a specific CE. Label consistency is the vibe 💜

5.1. Receive Unicast Multipoint-to-Point PW 🦋

(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 to all the other PEs. For convenience, though, we'll use the term MP2P PWs, which may be implemented using a set of point-to-point PWs.) Okay, so there are two ways to get there, and both are valid 🌈

The PE forwards a frame received over this MP2P PW to the associated AC. Straight to the right AC, no detours 🍓

The unicast PW uses IP Layer 2 Transport encapsulation as defined in [RFC4447]. ✨

5.2. Receive Multicast Multipoint-to-Point PW ✨

okay so when a PE is set up to join an IPLS instance, it tells every other PE in that same IPLS "hey, use this 'multicast' PW label" 🎀. The advertised label value is the same for every PE, and that's what makes it an MP2P PW. Each PE gets exactly one multicast MP2P PW per IPLS instance, and it's only used for carrying IP multicast/broadcast, ARP traffic, and (inverse) Neighbor Discovery packets for IPv6 from the remote PEs into this PE for this IPLS instance 💅.

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

In particular, the Receive multicast MP2P PW does not do any replication of frames itself 🚫. Instead, it's there to tell the PE that it may need to replicate a copy of a frame received over this MP2P PW onto all the ACs that are associated with the IPLS instance of the MP2P PW.

The multicast MP2P PW counts as the principal PW in the bundle of MP2P PWs for a given IPLS instance. That bundle is one multicast MP2P PW plus a variable number of unicast MP2P PWs. In that principal role, the multicast PW represents the whole IPLS instance 👑. The life of all the unicast PWs in the IPLS instance depends on the multicast PW existing. If, for some reason, multicast PWs stop existing, all the associated unicast PWs in the bundle would be removed 💀.

The multicast PW uses Ethernet encapsulation as defined in [RFC4448].

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

5.3. Send Multicast Replication Tree 🌈

The PE creates a Send Multicast Replication Tree for each IPLS instance. This tree is the collection of all ACs and all the 'multicast' PWs of that IPLS instance 🧚.

Any ARP, Neighbor Discovery, or broadcast/multicast IP Ethernet frame that comes in over an AC gets replicated to the other ACs and to the MP2P multicast PW of the Send Multicast Replication Tree. This tree deals mostly with broadcast/multicast Ethernet MAC frames. The one exception is unicast ARP and IPv6 Neighbor Discovery frames, and their processing is described in the following section 🫶.

Any Ethernet frame received over the multicast PW gets replicated to all the ACs of the Send Multicast Replication Tree of the IPLS instance that's linked to the incoming PW label. Again, the one exception is unicast ARP and Neighbor Discovery frames used for IPv6, which are handled in the following section ✨.

6. Signaling 🦋

[RFC4447] uses LDP to exchange PW FECs in the Label Mapping message, in a downstream unsolicited mode. The PW FEC comes in two forms: PWid and Generalized PWid FEC elements. These FEC elements define some fields that are common between them, and the discussions below refer to those common fields for IPLS-related extensions. Also, the multipoint-to-point and unidirectional characteristics of the PW make BGP the ideal candidate for PW FEC signaling 👀. Using BGP for that purpose is for future study 🔮.

6.1. IPLS PW Signaling 🌸

An IPLS carries IP packets as payload over its unicast PWs, and Ethernet frames as payload over its multicast PW. The PW type for the unicast PW is the IP PW, defined in [RFC4447] as IP Layer 2 Transport. The PW type for the multicast PW is the Ethernet PW as defined in [RFC4448]. The PW type values for these encapsulations are defined in [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 is for multicast PWs. If the PW type is 'IP Layer 2 transport', the PW FEC is for unicast PWs.

For unicast PWs, the PE must check for a MAC 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 meaning "MAC Address of the CE is absent" (note: status code 0x000000XX is pending IANA allocation (see Section 7)). That rejects the establishment of the unicast PW with the remote PE 🚫.

The PE may optionally include an IP address TLV, based on the user configuration, to advertise the IP addresses of the local CE 🎀.

The processing of the Address List TLV goes like this:

If a PW is configured for ACs with IPv4 CEs only, the PE should advertise an Address List TLV with an Address Family type of an IPv4 address. The PE should process the IPv4 address list TLV as described in this document.
If a PW is configured for ACs with both IPv4 and IPv6 CEs, the PE should advertise IPv6 capability using the procedures described in the section below.
If a PE does not receive any IP Address List TLV or IPv6 capability advertisement, it MAY assume IPv4 behavior.

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

When the PE is configured to support a specific type of IP traffic (IPv4 or IPv6), it verifies the type of IP traffic the PW will carry. If the received Address Family value doesn't match what the IPLS instance the PW belongs to expects, the PE must issue a Label Release message with a status code meaning "IP Address type mismatch" (status code 0x0000004A) to reject the PW establishment ❌.

The encoding of the IP Address TLV looks like this 🧩:

 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 IP Address           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     CE IP Address             |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Address Family: A two-octet quantity containing a value from the "Address Family Numbers" registry [ADDR-IANA], which encodes the addresses contained in the Addresses field.

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

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

         Address Family      Address Encoding

         IPv4 (1)             4-octet full IPv4 address

         IPv6 (2)             16-octet full IPv6 address

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

The encoding of the MAC Address TLV looks like this 🧩:

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

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

Address Family: A two-octet quantity containing a value from the "Address Family Numbers" registry [ADDR-IANA], which encodes the addresses contained in the Addresses field.

CE's MAC Address: The 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 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 the Notification message does not apply to the MAC Address TLV. That's because an update to the CE's MAC address should result in label withdrawal, followed by establishment of a new PW with the new MAC address of the CE 🔁. However, advertisement of the CE's IP address(es) is optional, and changes may become known after the unicast PW is established 🤷‍♀️.

The encoding of the LDP Notification message looks like this 🧩:

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 update follows. Since this notification doesn't refer to any particular message, the Message ID and Message Type fields are set to 0 🙌.

The PW FEC TLV SHOULD NOT include the interface parameters, because they are ignored in the context of this message 🙅‍♀️.

6.2. IPv6 Capability Advertisement 🎀

okay so the two PEs send each other a 'Stack Capability' Interface Parameter sub-TLV so they can agree on which stack(s) to use 🤝 by default the IP PW is assumed to always be able to carry IPv4 packets, so this capability sub-TLV is how you say "hey, I also need the other stacks running alongside IPv4" 💅

The 'Stack Capability' sub-TLV lives in the interface parameters of the PW FEC. The proposed format looks like this:

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

here's the breakdown 🧚

Parameter ID = 0x16
Length = 4
Stack Capability = 0x000X to indicate IPv6 stack capability. Its value depends on the PW type context. For the IP PW type, a setting of 0x000X means IPv6 stack capability.

A PE that supports IPv6 on an IP PW MUST signal the 'Stack Capability' sub-TLV in the initial Label Mapping message for the PW. the PE nodes compare what the remote PE advertised with their own local configuration, and they only use a capability that both sides advertised 🫶

now the important bit 😭 if a PE that supports IPv6 doesn't get a 'Stack Capability' sub-TLV from the far-end PE in the initial Label Mapping message, or it gets one but the value is a reserved one, the PE MUST send an unsolicited release for the PW label with the LDP status code meaning "IP Address type mismatch" (status code 0x0000004A). no notes, that's just how it goes 💀

the behavior of a PE that doesn't understand an interface parameter sub-TLV is specified in RFC 4447 [RFC4447] 📖

6.3. Signaling Advertisement Processing 📬

a PE should process a received [RFC4447] advertisement with a PW type of IP Layer 2 Transport for IPLS like this 💖

Verify the IPLS VPN membership by matching the VPN-ID signaled in the Attachment Group Identifier (AGI) field or the PWid field against all the VPN-IDs configured in the PE. If the VPN-ID isn't found, discard and release the PW label.
Program the FIB so that when a unicast IP packet comes in from an AC with its destination MAC address matching the advertised MAC address, the packet gets forwarded out over the tunnel to the advertising PE, with the advertised PW label as the inner label 🦋

a PE should process a received [RFC4447] advertisement with the PW type of Ethernet for IPLS like this 🌸

Verify the IPLS VPN membership by matching the VPN-ID signaled in the AGI field or the PWid field against all the VPN-IDs configured in the PE. If the VPN-ID isn't found, discard and release the PW label.
Add the PW label to the send broadcast replication tree for the VPN-ID. This lets a copy of a multicast/broadcast IP Ethernet frame, ARP Ethernet frame, or Neighbor Discovery frame go from the AC to this PW ✨

7. IANA Considerations 🌷

okay so this document is being published as Historic, which means no registration of IANA code points is needed 🙈 but if anyone ever wants to pick this proposal back up, these IANA code registrations would become necessary 🔥

7.1. LDP Status Messages

this document uses a new LDP status code. IANA already maintains the "Status Code Name Space" registry defined by [RFC5036], so the following allocation would be needed from the LDP Status Code Name Space 🧾

0x000000XX "MAC Address of CE is absent"

7.2. Interface Parameters

this document proposes a new Interface Parameters sub-TLV, to be assigned from the "Pseudowire Interface Parameters Sub-TLV type Registry". the following allocation would be needed for the Parameter ID 🎀

0xXX "Stack Capability"

IANA would also be asked to set up an "L2VPN PE Stack Capabilities" registry. it's a 16-bit field, and the Stack Capability value (0x000X) is specified in Section 6.2 of this document. the remaining bit field values (0x0002,..,0x8000) would be assigned by IANA using the "IETF Consensus" policy defined in [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

8. Forwarding 🦋

8.1. Non-IP or Non-ARP Traffic

in an IPLS VPN, a PE only forwards IP and ARP traffic 🚫 all other frames get dropped silently 🤫 if the CEs need to pass non-IP traffic to each other, they must do it through IP tunnels that terminate at the CEs themselves 🧚

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 L2 frame, and not based on the IP header 💅

the PE works out the FIB associated with an IPLS instance from the AC or the PW label. when a frame comes in from an AC, the PE uses the destination MAC address as the lookup key. when a frame comes in from a PW, the PE uses the PW label as the lookup key. if the lookup fails, the frame is dropped 🗑️

for IPv6 support, the unicast IP ICMP frame of Neighbor Discovery Protocol [RFC4861] is bi-casted: one copy goes to the control plane and the other copy goes to the PW, based on the destination MAC address 👯‍♀️

8.3. Broadcasts and Multicast IP Traffic

when the destination MAC address is broadcast or multicast, a copy of the frame is sent to the control plane for CE discovery purposes (see Section 4.1). this is the big one: stricter rate-limiting criteria are applied to frames sent to the control plane, so it doesn't get overwhelmed under rough conditions like DoS attacks 🛡️

the service provider should also provide a configurable limit to stop the learned source addresses in a given IPLS instance from overflowing 📈 and caution must be used so that only link-local multicasts and broadcast IP packets get sent to the control plane ⚠️

when a multicast/broadcast IP packet comes in from an AC, the PE replicates it onto the Send Multicast Replication Tree (see Section 5.3). when a multicast/broadcast IP Ethernet frame comes in from a PW, the PE forwards a copy of the frame to all the ACs associated with the respective IPLS VPN instance. note that the 'multicast' PW uses Ethernet encapsulation, so it doesn't need any extra header manipulations 🌈

8.4. ARP Traffic

when a broadcast ARP frame comes in 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 5.3), which results in a copy being delivered to all the remote PEs on the 'multicast' PW and to the other local CEs through the egress ACs 📣

when a broadcast Ethernet ARP frame comes in over the 'multicast' PW, a copy of the Ethernet ARP frame is sent to all the ACs associated with the IPLS instance 💜

when a unicast Ethernet ARP frame comes in over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. the PE may optionally do a destination MAC 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 5.3) 🔍

when a unicast ARP Ethernet frame comes in over the 'multicast' PW, the PE may optionally do a destination MAC address lookup in the forwarding table and forward it to the AC where the CE is located. if the CE isn't accessible through any local AC, the frame is dropped 🙅‍♀️ or, the PE may simply forward the frame to all the ACs associated with that IPLS instance without any lookup in the forwarding table 🤷‍♀️

8.5. Discovery of IPv6 CE Devices

a PE device that supports IPv6 MUST be capable of 🫶

Intercepting ICMPv6 Neighbor Discovery [RFC4861] packets received over the AC.
Recording the IPv6 interface addresses and CE link-layer addresses present in these packets.
Forwarding them towards the original destination. a PE device may also intercept Router Discovery packets in order to discover the link-layer address and IPv6 interface address(es) of the CE. 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, and discard packets that don't match its learned CE link-layer address 🔐 the PE device may also optionally learn a list of CE IPv6 interface addresses for its directly attached CE 🌷

8.5.1. Processing of Neighbor Solicitations

when a multicast NS frame comes in 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 5.3), which results in a copy being delivered to all the remote PEs on the 'multicast' PW and to the other local CEs through the egress ACs. the PE may optionally learn an IPv6 interface address (if provided -- this won't be the case for Duplicate Address Detection) when one is present 🕵️‍♀️

when a multicast Ethernet NS frame comes in over the 'multicast' PW, a copy is sent to all the ACs associated with the IPLS instance 💅

8.5.2. Processing of Neighbor Advertisements

when a unicast NA comes in over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. the PE may optionally do a destination MAC address lookup in the forwarding table and send the 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 5.3) 🎯

optionally, the PE could learn the IPv6 interface address of the CE ✨

when a unicast NA frame comes in over the 'multicast' PW, the PE may optionally do a destination MAC address lookup in the forwarding table and forward it to the AC where the CE is located. if the CE isn't accessible through any local AC, the frame is dropped. or, the PE may simply forward the frame to all the ACs associated with that IPLS instance without any lookup in the forwarding table 🙃

8.5.3. Processing of Inverse Neighbor Solicitations and Advertisement

Inverse Neighbor Discovery is typically used on non-broadcast links, but it's allowed on broadcast links as well [RFC3122] 🦄 a PE may optionally intercept Inverse Neighbor Solicitation and Advertisement messages 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 a destination MAC 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 5.3) 💖

8.5.4. Processing of Router Solicitations and Advertisements ✨

okay so RSs are multicast, but RAs can be unicast OR multicast Ethernet frames 🫶 the PE is allowed to optionally intercept RS and RA frames and send a copy up to the control plane 💅 and the PE may learn the MAC address plus a list of interface addresses for the attached CE 🌸

for unicast RA, the PE may optionally do a destination MAC address lookup in the forwarding table and send the RA frame out to one specific egress interface (an AC, or a 'multicast' PW to a remote PE) 🦋 or it can replicate the frame onto the Send Multicast Replication Tree (see Section 5.3) 🧚 and the multicast RA and RS Ethernet frames get replicated using that same Send Multicast Replication Tree, as described in Section 5.3 💜

8.6. Encapsulation 🎀

the Ethernet MAC header of a unicast IP packet that comes in from an AC gets stripped before the frame goes out over the unicast PW, bestie 💖 BUT the MAC header sticks around for these cases:

when a frame is a unicast IP packet that's directed to a local AC.
when a frame is a broadcast/multicast IP packet.
when a frame is an ARP packet.
when a frame is a Neighbor/Router Solicitation/Advertisement.

when an IP frame comes in over a unicast PW, the PE prepends a MAC header to it before it gets sent out on the right AC(s) 🌈 and the fields in that MAC header get filled in like this:

the destination MAC address is the MAC address associated with the PW label in the FIB.
the source MAC address is the PE's own local MAC address, or a MAC address that's been specially configured on the PE for this use.
the Ethernet Type field is 0x0800 if it's IPv4, or 0x86DD if it's IPv6 [RFC2464].
the frame may be IEEE 802.1Q tagged, based on the VLAN information associated with the AC.

and then a Frame Check Sequence (FCS) gets appended to the frame ✨

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

so besides (i) an Ethernet port, and (ii) a combo of an Ethernet port and a VLAN ID, an AC to IPLS can also be (iii) an ATM or FR Virtual Circuit (VC) carrying encapsulated bridged Ethernet frames, or (iv) a combo of an ATM or FR VC and a VLAN ID 🌸

the ATM/FR VC is literally just a way to transport Ethernet frames between a customer site and the PE 🚚 the PE terminates the ATM/FR VC and handles those encapsulated Ethernet frames exactly as if they came in on a local Ethernet interface 💅 when a frame is propagated from a PW out to an ATM or FR VC, the PE prepends the Ethernet frame with the right bridged encapsulation header, as defined in [RFC2684] and [RFC2427] respectively 🧚 an IPLS running over an ATM/FR VC works exactly like what's described above, with one exception: the AC is identified by the ATM VCI/VPI or the Frame Relay Data Link Connection Identifier (DLCI) instead of a local Ethernet port ID, or by a combo of those with a VLAN ID 💜

10. VPLS vs. IPLS 💖

the VPLS approach proposed in [RFC4762] gives VPN services for IP AND other protocols 🌈 the IPLS approach in this document is similar to VPLS in a bunch of ways:

it provides a Provider-Provisioned Virtual LAN service with multipoint capability, where a CE connected through a single attachment circuit can reach lots of remote CEs.
it appears as a broadcast domain and a single subnet.
forwarding is based on destination MAC addresses.

BUT unlike VPLS, IPLS is restricted to IP traffic only 🙈 by narrowing the service down to the most common type of traffic these days, IPLS means service provider edge routers don't need to do some bridging stuff, like MAC address learning in the data path (instead, MAC info gets distributed in the control plane) ✨ so this solution comes with a bunch of perks:

it makes Virtual LAN services possible where PE devices cannot, or cannot efficiently, do MAC address learning (or are specifically configured not to) 🫶
Unknown Unicast frames are never flooded, which is NOT what happens in VPLS 😭
encapsulation is more efficient (the MAC header is stripped) for unicast IP packets crossing the backbone network 🚀
PE devices don't carry the processing overhead that comes with traditional bridging, like Spanning Tree Protocol (STP) processing and so on. heads up though: some of that overhead (like STP processing) could optionally be turned off with a VPLS solution, when it's known that only IP devices are interconnected 💅
loops (maybe through backdoor links) get minimized, since a PE can easily reject a duplicate IP to MAC address advertisement via label release 🔥
you get greater control over CE topology distribution 👑

11. IP Protocols 🌸

the solution in this document only offers IPLS service for IPv4 and IPv6 traffic 🎀 that's why the MAC header isn't carried over the unicast PW. the PE rebuilds it when it receives a packet from a unicast PW, and it uses Ethertype 0x0800 or 0x86DD in that MAC header, since IPv4 or IPv6 is assumed, respectively 🧚

BUT this solution could be extended to carry other important traffic types, like IS-IS, which doesn't use Ethernet-II, an EtherType-based header 👀 to let those packets propagate correctly, you could create a separate set of PWs, pass protocol information in the "control word" of a "multiprotocol" PW, or encapsulate the Ethernet MAC header in the PW 💜 picking the right multiplexing/demultiplexing scheme is the subject of future study 🔮 for now, this document focuses on IPLS service for IPv4 and IPv6 traffic only 🫶

12. Dual-Homing with IPLS 🦋

as we said in earlier sections, IPLS prohibits connecting a common LAN or VLAN to more than one PE 🚫 BUT the CE device itself can connect to more than one instance of IPLS, through two separate LAN or VLAN connections going to separate PEs 🌈 to the CE IP device, those separate connections look like connections to two IP subnets 👯 so if reachability through one subnet fails, it gets resolved via the other subnet using IP routing protocols 💅

13. Proxy ARP Function 💖

the earlier version of this proposal used IP-PW to carry both the broadcast/multicast AND the unicast IP traffic 🕰️ it also talked about how PE proxy functionality responds to ARP requests from the local CE on behalf of a remote CE 🧚 the current version of the document got rid of these functions, and instead uses Ethernet PW to carry broadcast, multicast and ARP frames to remote PEs ✨ the reason for using Ethernet PW and propagating ARP frames in the current version is to support configurations like back-to-back IPLS (similar to Inter-AS option-A configurations in [RFC4364]) 🔥

the termination and controlled propagation of ARP frames is still a desirable option for security, DoS, and other purposes 🛡️ so for these reasons, we bring back the ARP Proxy [RFC925] function in this revision as an optional feature 🫶 the following sections describe this option 🌸

13.1. ARP Proxy - Responder 🌷

as a local configuration, a PE can enable the ARP Proxy Responder function 💅 in this mode, the local PE responds to ARP requests received over the Attachment Circuit, using learned IP and MAC address associations that the remote PEs advertised 🦋 the PE may also use local policies to decide whether ARP requests should be responded to, based on the source of the ARP request, the rate at which the ARP requests are generated, and so on 🧚 basically, when this feature is enabled, ARP requests are NOT propagated to remote PE routers that are members of the same IPLS instance 🙈

13.2. ARP Proxy - Generator 🌈

as a local configuration, a PE can enable the ARP Proxy Generator function 🎀 in this mode, the PE generates an ARP request for each IP and MAC address association it receives 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 comes from local configuration (so the user needs to configure an IP address when this feature is enabled) 🫶 the ARP request gets sent on the ACs that have ARP Proxy Generator enabled and that are associated with the given IPLS instance 🚀

also, the PE may use local policies to figure out which IP/MAC addresses are candidates for ARP request generation 💜

the ARP Proxy Generator feature is REQUIRED to support back-to-back IPLS configuration whenever any member of the IPLS instance is using the ARP Proxy Responder function 🔥 an example of back-to-back IPLS is a setup where PE-1 (ASBR) in an IPLS cloud in one Autonomous System (say, AS-1) is connected via an AC to PE-2 (ASBR) in an IPLS cloud in another Autonomous System (say, AS-2), where each PE looks like a CE to the other one 👯 this kind of configuration is described in [RFC4364] as option-A for inter-AS connectivity 🌸 the Proxy ARP Responder feature stops ARP requests from being propagated to PE-1 (ASBR) in AS-1 😭 which means PE-1 (ASBR) in AS-1 has to generate an ARP request on behalf of each CE connected to the IPLS instance in AS-1, as a way to 'advertise' reachability to the IPLS cloud in AS-2 🧚

14. Data Center Applicability 🖥️

the resurgence of interest in an IP/MPLS-based solution for Data Center Networks (DCNs) deserves another look at the IPLS methodologies in this document ✨ the key requirement of a DCN, to allow Virtual Machine (VM) mobility within or across a DCN, means you have to extend the reachability of an IP subnet over a LAN, transparently 🦋 and VMs tend to generate frequent gratuitous ARPs for location discovery, which means you need a solution that curbs broadcasts as close to the source as possible 😤

the IPLS solution helps VM mobility by having the PE closest to the new location signal the MAC address to all remote peers 🚀 plus, control-plane-based MAC learning mechanisms stop unknown unicast from flooding across a DCN 🛑 and the optional ARP proxy mechanisms cut down ARP broadcast floods even more, by stopping them from reaching across a local PE 💅

15. Security Considerations 🔐

okay bestie, this part is SERIOUS 😤 a more comprehensive description of the security issues involved in L2VPNs is covered in [RFC4111] 📚 most of the security issues can be avoided by implementing appropriate guards 🛡️ the security aspect of this solution is addressed for two planes: the control plane and the data plane 💜

15.1. Control-Plane Security ✨

okay so control-plane security is all about the stuff that happens before any data moves 🎀. That means setting up the LDP connection, establishing the PW, and passing around each CE's IP and MAC address 🧚. For the LDP connection between two trusted PEs, each PE checks that the incoming connection matches the configured peer's address, and then it authenticates the LDP messages by verifying keyed digests 🔐. PW establishment between two secure LDP peers isn't a security issue in itself 💅, but mis-wiring can happen because of a configuration error 😭. Checks like the proper PW type and other PW options can help stop that kind of mis-wiring 🫶.

Learning the right CE IP and MAC addresses can be a security issue, though 💀. The local attachment circuit to the CE is expected to be physically secured. If that's a worry for you, the PE must be configured with the CE's IP and MAC address 🌸. Then, during each ARP frame processing, the PE must verify the received information against the configuration before accepting it ✅. This is what prevents theft of service, denial of service to a subscriber, and DoS attacks against all subscribers through malicious use of network services 🚫.

The IPLS also gives you MAC anti-spoofing by refusing to let an already known MAC address be reused 🙅‍♀️. Say a PE has already learned that a CE is present, either through a local connection or from another PE. If an advertisement for that same MAC and/or IP address then shows up from a different PE, the receiving PE can terminate service to that CE, either by label release and/or by removing the ARP entry from the FIB, and raise the alarm 🚨. Main character energy for security, honestly 👑.

The IPLS learns and distributes CE reachability through the control plane 🗺️. This gives you much greater control over how CE topology gets distributed, because you can apply local policies to it 🎯.

15.2. Data-Plane Security 🔒

the data traffic between the CE and the PE is not encrypted 😱. In an insecure environment, a malicious user could tap into the CE-to-PE connection and carry out an active or passive attack 👀. An active attack could look like generating traffic with a spoofed destination MAC address on the Ethernet Attachment Circuit, and a passive attack could be targeted or passive monitoring between the CE and PE 🕵️‍♀️. To avoid this kind of hijacking, the local PE may verify the source MAC address of each received frame against the MAC address of the admitted connection 🧐. The frame is forwarded to the PW only when its authenticity is verified ✔️. When spoofing is detected, the PE must sever the connection with the local CE, tear down the PW, and start over 🔁.

Each IPLS instance uses its own FIB, which stops one customer's data from leaking into another's 🛡️. Iconic isolation, no notes 💖.

16. References 📚

16.1. Normative References

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

[RFC826]       Plummer, D., "Ethernet Address Resolution 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 3122, June 2001,
               <http://www.rfc-editor.org/info/rfc3122>.

[RFC4446]      Martini, L., "IANA Allocations for 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 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, April 2006,
               <http://www.rfc-editor.org/info/rfc4448>.

[RFC4762]      Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
               Private LAN Service (VPLS) Using Label Distribution
               Protocol (LDP) Signaling", RFC 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,
               <http://www.rfc-editor.org/info/rfc4861>.

[RFC5036]      Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
               Ed., "LDP Specification", RFC 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,
               <http://www.rfc-editor.org/info/rfc5226>.

16.2. Informative References

[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,
               <http://www.rfc-editor.org/info/rfc4664>.

[RFC4665]      Augustyn, W., Ed., and Y. Serbest, Ed., "Service
               Requirements for Layer 2 Provider-Provisioned Virtual
               Private Networks", RFC 4665, September 2006,
               <http://www.rfc-editor.org/info/rfc4665>.

[RFC5771]      Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines
               for IPv4 Multicast Address Assignments", BCP 51, RFC
               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
               2 Virtual Private Networks (L2VPNs)", RFC 6074,
               January 2011,
               <http://www.rfc-editor.org/info/rfc6074>.

Acknowledgements 🫶

the authors want to give a big thank-you to Alp Dibirdi from Alcatel and Xiaohu Xu from Huawei, plus the other L2VPN working group members, for their valuable comments 💜.

Contributors 🌈

this document is the combined effort of the people below and many others who carefully reviewed it and gave the technical clarifications it needed ✨.

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

Authors' Addresses 💌

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

EMail: hshah@ciena.com


Eric Rosen
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA, 01886
United States

EMail: erosen@juniper.net


Francois Le Faucheur
Cisco Systems, Inc.
Batiment D, 45 Allee des Ormes
06254 Mougins
France

EMail: flefauch@cisco.com


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

EMail: giheron@cisco.com

that's the whole spec, bestie 🦋💖 you made it!!

📦 where this page comes from

ietf: rfc7436 2015-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms