RFC 6575
Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs
Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs 🦋
RFC 6575 💖 is a Standards Track document from the Internet Engineering Task Force (IETF), dated June 2012, with ISSN 2070-1721. The authors are H. Shah, Ed. (Ciena), E. Rosen, Ed. (Cisco), G. Heron, Ed. (Cisco), and V. Kompella, Ed. (Alcatel-Lucent). Its header doesn't list anything it obsoletes or updates, so it stands on its own 🌸
Abstract ✨
okay so VPWS (detailed in RFC 4664) gives you point-to-point connections between pairs of Customer Edge (CE) devices 💅 It does this by binding two Attachment Circuits (each one connects a CE device to a Provider Edge (PE) device) to a pseudowire (which connects the two PEs). Usually both Attachment Circuits have to be the same technology (for example, both Ethernet or both ATM), and the pseudowire has to carry frames of that technology.
BUT if the frames' payload is made up solely of IP datagrams, you can have a point-to-point connection where the pseudowire connects Attachment Circuits of different technologies 🦋 To make that work, the PEs have to do something called "Address Resolution Protocol (ARP) Mediation". That's the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods in this document still apply even when the CEs run a routing protocol between them, as long as that routing protocol runs over IP ✨
Status of This Memo 🎀
This is an Internet Standards Track document.
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). Further information on Internet Standards is available in 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/rfc6575.
Copyright Notice 💜
Copyright (c) 2012 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.
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. ARP Mediation (AM) Function .....................................5
3. IP Layer 2 Interworking Circuit .................................6
4. IP Address Discovery Mechanisms .................................6
4.1. Discovery of IP Addresses of Locally Attached IPv4 CE ......7
4.1.1. Monitoring Local Traffic ............................7
4.1.2. CE Devices Using ARP ................................7
4.1.3. CE Devices Using Inverse ARP ........................8
4.1.4. CE Devices Using PPP ................................9
4.1.5. Router Discovery Method ............................10
4.1.6. Manual Configuration ...............................10
4.2. How a CE Learns the IPv4 Address of a Remote CE ...........10
4.2.1. CE Devices Using ARP ...............................11
4.2.2. CE Devices Using Inverse ARP .......................11
4.2.3. CE Devices Using PPP ...............................11
4.3. Discovery of IP Addresses of IPv6 CE Devices ..............11
4.3.1. Distinguishing Factors between IPv4 and IPv6 .......11
4.3.2. Requirements for PEs ...............................12
4.3.3. Processing of Neighbor Solicitations ...............12
4.3.4. Processing of Neighbor Advertisements ..............13
4.3.5. Processing Inverse Neighbor Solicitations (INSs) ...14
4.3.6. Processing of Inverse Neighbor
Advertisements (INAs) ..............................15
4.3.7. Processing of Router Solicitations .................15
4.3.8. Processing of Router Advertisements ................15
4.3.9. Duplicate Address Detection ........................16
4.3.10. CE Address Discovery for CEs Attached Using PPP ...16
5. CE IPv4 Address Signaling between PEs ..........................16
5.1. When to Signal an IPv4 Address of a CE ....................16
5.2. LDP-Based Distribution of CE IPv4 Addresses ...............17
6. IPv6 Capability Advertisement ..................................20
6.1. PW Operational Down on Stack Capability Mismatch ..........21
6.2. Stack Capability Fallback .................................21
7. IANA Considerations ............................................22
7.1. LDP Status Messages .......................................22
7.2. Interface Parameters ......................................22
8. Security Considerations ........................................22
8.1. Control Plane Security ....................................23
8.2. Data Plane Security .......................................24
9. Acknowledgements ...............................................24
10. Contributors ..................................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Appendix A. Use of IGPs with IP L2 Interworking L2VPNs ...........27
A.1. OSPF ......................................................27
A.2. RIP .......................................................27
A.3. IS-IS .....................................................281. Introduction 💖
Layer 2 Virtual Private Networks (L2VPNs) are built over a Service Provider IP/MPLS backbone, but they show up to the Customer Edge (CE) devices as Layer 2 networks ✨ In theory an L2VPN can carry any Layer 3 protocol, but in lots of cases that Layer 3 protocol is IP. So it makes sense to think about procedures that are optimized for IP 🫶
In a typical setup, shown in the diagram below, the CE devices connect to the Provider Edge (PE) devices through Attachment Circuits (ACs). The ACs are Layer 2 circuits. In a pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both ACs would have to be the same type (for example, both Ethernet, both Frame Relay, and so on). BUT if it's known that only IP traffic will be carried, the ACs can be different technologies, as long as the PEs provide the right procedures to transfer IP packets properly 💅
+-----+
+------ -----| CE3 |
|AC3 +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................Wait, the diagram above needs its exact original spacing, so here it is verbatim 🙈
+-----+
+------ -----| CE3 |
|AC3 +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................Ugh, I keep reformatting it, so let me restate the original diagram exactly as it appears in the RFC 🙃
+-----+
+------ -----| CE3 |
|AC3 +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................A CE connected through a given type of AC might use an IP address resolution procedure that's specific to that type of AC. For example, an Ethernet-attached IPv4 CE would use ARP [RFC826], and a Frame-Relay-attached CE might use Inverse ARP [RFC2390]. If we want to let the two CEs have a Layer 2 connection between them, even though each AC uses a different Layer 2 technology, the PEs must intercept and "mediate" those Layer-2-specific address resolution procedures 🦋
In this document, we specify the procedures for VPWS services [RFC4664] that the PEs need to implement in order to mediate the IP address resolution mechanism. We call these procedures "ARP Mediation". Let's say a Virtual Private Wire Service (VPWS) is built between CE1 and CE2 in the diagram above. If AC1 and AC2 are different technologies, for example AC1 is Ethernet and AC2 is Frame Relay (FR), then ARP requests coming from CE1 can't be passed transparently to CE2. PE1 MUST interpret the meaning of the ARP requests and mediate the necessary information with PE2 before responding 💀
This document uses the term "ARP" to mean any protocol that's used to resolve IP addresses to link-layer addresses. For instance, in IPv4, the ARP and Inverse ARP protocols are used for address resolution, while in IPv6, Neighbor Discovery [RFC4861] and Inverse Neighbor Discovery [RFC3122], which are based on ICMPv6, are used for address resolution 🌈
1.1. Conventions Used in This Document 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧚
2. ARP Mediation (AM) Function ✨
okay so the ARP Mediation (AM) function is an element that lives inside a PE node and handles IP address resolution for CE devices connected over a VPWS L2VPN 💅. Since it sits in the PE node, the CE devices literally have no idea it's happening 🫶 that's main character energy.
For a given point-to-point connection between a pair of CEs, ARP Mediation works differently depending on whether the packets are IPv4 or IPv6 🦋. A PE that is doing ARP Mediation for IPv4 packets MUST follow these logical steps:
- Discover the IP address of the locally attached CE device.
- Terminate. Do not forward ARP and Inverse ARP requests from the CE device at the local PE.
- Distribute the IP address to the remote PE using pseudowire control signaling.
- Notify the locally attached CE of the IP address of the remote CE.
- Respond appropriately to ARP and Inverse ARP requests from the local CE device using the IP address of the remote CE and the hardware address of the local PE.
A PE that is doing ARP Mediation for IPv6 packets MUST follow these steps 🌸:
- Discover the IPv6 addresses of the locally attached CE device, together with those of the remote CE device.
- Perform the following steps:
- a. Intercept Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND) packets received from the local CE device.
- b. From these ND and IND packets, learn the IPv6 configuration of the CE.
- c. Forward the ND and IND packets over the pseudowire to the remote PE.
- Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the pseudowire from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE and learning information about the IPv6 configuration of the remote CE.
Details for all of the above are in the sections below 👑.
3. IP Layer 2 Interworking Circuit
The IP Layer 2 Interworking Circuit is how the Attachment Circuit gets hooked up to the IP Layer 2 Transport pseudowire, which carries IP datagrams as its payload 🎀. The ingress PE strips off the data link header of its local Attachment Circuit and sends the payload (an IP packet) over the pseudowire, with or without the optional control word. If the IP packet shows up at the ingress PE with multiple data link headers (like a bridged Ethernet PDU on an ATM Attachment Circuit), then all of those data link headers MUST be removed from the IP packet before it goes over the pseudowire (PW) 💅. On the far side, the egress PE wraps the IP packet back up in the data link header used on its local Attachment Circuit ✨.
The encapsulation for the IP Layer 2 Transport pseudowire is described in [RFC4447]. Also, the "IP Layer 2 Interworking Circuit" pseudowire is called "IP pseudowire" in this document 🧚.
For an IPv6 L2 Interworking Circuit, the egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets before it wraps the IP packet in the data link header 🦋.
4. IP Address Discovery Mechanisms
An IP Layer 2 Interworking Circuit enters the monitoring state right after it's configured 👀. While it's in that state, it does two things:
- Discovery of the CE IP device(s)
- Establishment of the PW
The PW gets established independently from local CE IP address discovery 💜. Here's the tea: while the PW is up but the local CE IP device hasn't been discovered yet, only broadcast/multicast IP frames get passed between the Attachment Circuit and the pseudowire, and unicast IP datagrams get dropped 🙈. The IP destination address is what decides whether a packet counts as unicast or multicast.
Unicast IP frames only get passed between the AC and the pseudowire once CE IP devices on both Attachment Circuits have been discovered and notified, and the proxy functions have finished 🔥.
Why wait for address resolution before unicast traffic can flow? It's simple, honestly:
- PEs do not perform routing operations.
- The destination IP address in the packet is not necessarily that of the attached CE.
- On a broadcast link, there is no way to find out the Media Access Control (MAC) address of the CE based on the destination IP address of the packet 😭.
4.1. Discovery of IP Addresses of Locally Attached IPv4 CE
A PE MUST support manual configuration of IPv4 CE addresses 🫶. This section also covers the automated mechanisms a PE MAY also use to discover an IPv4 CE address ✨.
4.1.1. Monitoring Local Traffic
The PE devices MAY learn the IP addresses of the locally attached CEs from any IP traffic, like link-local multicast packets (e.g., destined to 224.0.0.x). They aren't restricted to the operations below 🌈.
4.1.2. CE Devices Using ARP
If a CE device uses ARP to figure out the IP-address-to-MAC-address binding of its neighbor, the PE processes those ARP requests to learn the IP address of the local CE for the local Attachment Circuit 💖.
Quick heads up: the method in this document only supports the case where there's a single CE per Attachment Circuit 🙅♀️. Customer-facing access topologies can still have more than one CE showing up to the PE on a single Attachment Circuit, though. This could happen when CEs are connected to a shared LAN that hooks into the PE 🍓. In that case, the PE MUST select one local CE. The selection could be based on manual configuration, or the PE MAY optionally use the following selection criteria. Either way, manual configuration of the IP address of the local CE (and its MAC address) MUST be supported 💅.
- Wait to learn the IP address of the remote CE (through PW signaling), and then select the local CE that is sending the request for the IP address of the remote CE.
- Augment cross-checking with the local IP address learned through listening for link-local multicast packets (as per Section 4.1.1).
- Augment cross-checking with the local IP address learned through the Router Discovery Protocol (as described in Section 4.1.5).
- There is still a possibility that the local PE may not receive an IP address advertisement from the remote PE, and there may exist multiple local IP routers that attempt to 'connect' to remote CEs. In this situation, the local PE MAY use some other criteria to select one IP device from many (such as "the first ARP received"), or an operator MAY configure the IP address of the local CE. Note that the operator does not have to configure the IP address of the remote CE, since that gets learned through pseudowire signaling 🧚.
Once the local and remote CEs have been discovered for the given Attachment Circuit, the local PE answers any later ARP requests from the local CE that have a destination IP address matching the remote CE's IP address with its own MAC address 🦋.
The local PE signals the IP address of the local CE to the remote PE. It MAY also send out an unsolicited ARP response to notify the local CE of the IP-address-to-MAC-address binding for the remote CE (again using its own MAC address) 📣.
Once the ARP Mediation function is complete (aka the PE knows both the local and remote CE IP addresses), unicast IP frames flow between the AC and the established PW 🔥.
The PE MAY periodically generate ARP request messages for the IP address of the CE to check that the IP address and its MAC address binding are still valid 👀. If the CE doesn't respond after a given number of retries, that could be used as a trigger to withdraw the IP address advertisement to the remote PE. The local PE would then go back into the address resolution phase to rediscover the IP address of the attached CE 🔄. Note that this "heartbeat" scheme is only needed where a CE device failing might otherwise go undetected 💀.
4.1.3. CE Devices Using Inverse ARP
If a CE device uses Inverse ARP to figure out the IP address of its neighbor, the attached PE processes the Inverse ARP request from the Attachment Circuit and replies with an Inverse ARP reply containing the IP address of the remote CE, as long as that address is known 🎀. If the PE doesn't have the IP address of the remote CE yet, it doesn't respond. It does, however, record the IP address of the local CE and the circuit information 📝. Later, once the IP address of the remote CE becomes available, the PE MAY initiate an Inverse ARP request to notify the local CE of the IP address of the remote CE 💌.
This is the typical way things work for Frame Relay and ATM Attachment Circuits 🌸. If the CE doesn't use Inverse ARP, the PE can still discover the IP address of the local CE using the mechanisms in Sections 4.1.1 and 4.1.5 🫶.
4.1.4. CE Devices Using PPP
The IP Control Protocol [RFC1332] describes how to establish and configure IP on a point-to-point connection, including negotiating IP addresses 🧁. When an Attachment Circuit like this is set up for IP interworking, PPP negotiation doesn't happen end-to-end between the CE devices. Instead, it happens between the CE and its local PE. The PE does proxy PPP negotiation, and it tells the attached CE the IP address of the remote CE during IP Control Protocol (IPCP) negotiation, using the IP-Address option (0x03) ✨.
When a PPP link finishes Link Control Protocol (LCP) negotiations, the local PE MAY perform the following IPCP actions 🌈:
- The PE learns the IP address of the local CE from the
Configure-Requestit receives with the IP-Address option (0x03). If the IP address is non-zero, the PE records it and responds withConfigure-Ack. But if the IP address is zero, the PE responds withConfigure-Reject, since that's the CE asking to be assigned an IP address. The IP-Address option also gets set to a zero value in thatConfigure-Rejectresponse, to tell the CE not to include that option in any laterConfigure-Request🙅♀️. - If the PE gets a
Configure-Requestwithout the IP-Address option, it responds with aConfigure-Ack. In this case the PE can't learn the IP address of the local CE using IPCP, so it MUST rely on other means, as described in Sections 4.1.1 and 4.1.5. Also, to use those other learning mechanisms, the IPCP negotiations MUST have reached the open state 🔥. - If the PE doesn't know the IP address of the remote CE, it sends a
Configure-Requestwithout the IP-Address option 🤷♀️. - If the PE knows the IP address of the remote CE, it sends a
Configure-Requestwith the IP-Address option containing the IP address of the remote CE 💅.
The IPCP IP-Address option MAY be negotiated between the PE and the local CE device. Configuration of other IPCP options MAY be rejected 🙈. Other Network Control Protocols (NCPs) MUST be rejected, with the exception of the Compression Control Protocol (CCP) and the Encryption Control Protocol (ECP). The PE device MAY reject configuration of the CCP and ECP too 💜.
4.1.5. Router Discovery Method 🧭
Okay bestie, so if the PE wants to find out the IP address of the CE device on a given Attachment Circuit, it MAY run the Router Discovery Protocol [RFC1256]. It sends out a Router Discovery Request (ICMP - Router Solicitation) message with a source IP address of zero 🫶. The CE's IP address then gets pulled out of the Router Discovery Response (ICMP - Router Advertisement) message that comes back from the CE. Lowkey messy part: the response might list more than one router address with the same preference level 😭, in which case some heuristics (such as first on the list) are necessary. Using the Router Discovery method is optional for the PE 💅.
4.1.6. Manual Configuration 🛠️
Sometimes it may not be possible to figure out the IP address of the local CE using the mechanisms in Sections 4.1.1 to 4.1.5, and that's when manual configuration MAY be used. All implementations of this document MUST support manual configuration of the IPv4 address of the local CE. This is the only REQUIRED mode for a PE to support 🎀.
Configuring the IP address of the remote CE is OPTIONAL ✨.
4.2. How a CE Learns the IPv4 Address of a Remote CE 💌
Once the local PE has received the IP address info of the remote CE from the remote PE, it will either start an address resolution request or respond to an outstanding request from the attached CE device 🦋.
If the IPv4 address of the remote CE is manually configured, address resolution can begin right away, because the PE doesn't need to wait to receive the remote CE's IP address 🚀.
4.2.1. CE Devices Using ARP
When the PE learns the IP address of the remote CE as described in Section 5.1, it may or may not already know the IP address of the local CE 🤷♀️. If the local CE's IP address isn't known, the PE MUST wait until it's acquired through one of the methods in Sections 4.1.1, 4.1.2, and 4.1.5. If the local CE's IP address is known, the PE MAY choose to generate an unsolicited ARP message to notify the local CE about the binding of the remote CE's IP address with the PE's own MAC address 🌸.
When the local CE generates an ARP request, the PE MUST proxy the ARP response [RFC925] using its own MAC address as the source hardware address and the IP address of the remote CE as the source protocol address. The PE MUST respond only to those ARP requests whose destination protocol address matches the IP address of the remote CE 💖.
4.2.2. CE Devices Using Inverse ARP
When the PE learns the IP address of the remote CE, it SHOULD generate an Inverse ARP request 🍓. If the Attachment Circuit requires activation (e.g., Frame Relay), the PE SHOULD activate it first, before the Inverse ARP request. It should be noted that the PE might never receive the response to its own request, nor see any Inverse ARP request from the CE. That can happen when the CE is pre-configured with the IP address of the remote CE, or when the use of Inverse ARP has not been enabled. In either case, the CE has used other means to learn the IP address of its neighbor 🙈.
4.2.3. CE Devices Using PPP
When the PE learns the IP address of the remote CE, it SHOULD initiate a Configure-Request and set the IP-Address option to the IP address of the remote CE. This notifies the local CE of the IP address of the remote CE 🧚.
4.3. Discovery of IP Addresses of IPv6 CE Devices 🌈
4.3.1. Distinguishing Factors between IPv4 and IPv6
Okay so IPv4 uses ARP and Inverse ARP to resolve IP address and link-layer associations. These are dedicated address resolution protocols and not IP packets, so they cannot be carried on an IP pseudowire 🙅♀️. They MUST be processed locally, and the IPv4 address information they carry is signaled between the PEs using the pseudowire control plane. IPv6 uses ICMPv6 extensions to resolve IP address and link address associations. Since these are IPv6 packets, they can be carried on an IP pseudowire; therefore, no IPv6 address signaling is required 💜.
4.3.2. Requirements for PEs
A PE device that supports IPv6 MUST be capable of the following 👑:
- Intercepting ICMPv6 Neighbor Discovery [RFC4861] and Inverse Neighbor Discovery [RFC3122] packets received over the AC as well as over the PW,
- Recording the IPv6 interface addresses and CE link-layer addresses present in these packets,
- Possibly modifying these packets as dictated by the data link type of the egress AC (described in the following sections), and
- Forwarding them towards the original destination.
The PE MUST also be capable of generating packets in order to interwork between Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND). This is specified in Sections 4.3.3 to 4.3.6 🫧.
If an IP PW is used to interconnect CEs that use IPv6 Router Discovery [RFC4861], a PE device MUST also be capable of intercepting and processing those Router Discovery packets. This is required in order to translate between different link-layer addresses. If a Router Discovery message contains a link-layer address, then the PE MAY also use that message to discover the link-layer address and IPv6 interface address. This is described in more detail in Sections 4.3.7 and 4.3.8 🎀.
The PE device MUST learn a list of CE IPv6 interface addresses for its directly attached CE, and another list of CE IPv6 interface addresses for the far-end CE. The PE device MUST also learn the link-layer address of the local CE and be able to use it when forwarding traffic between the local and far-end CEs. The PE MAY also wish to monitor the source link-layer address of data packets received from the CE and discard packets not matching its learned CE link-layer address 🔥.
4.3.3. Processing of Neighbor Solicitations
A Neighbor Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address (if provided, this will not be the case for Duplicate Address Detection) and any link-layer address provided. The packet MUST then be forwarded over the pseudowire unmodified. A Neighbor Solicitation received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the PE interface attached to the local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the CE has no valid link-layer address with which to transmit data packets 🥺.
When a PE with a local AC, which is of the type point-to-point Layer 2 circuit (e.g., FR, ATM, or PPP), receives a Neighbor Solicitation from a far-end PE over the pseudowire, after learning the IP address of the far-end CE, the PE MAY use one of the following procedures 🧩:
- Forward the Neighbor Solicitation to the local CE after replacing the source link-layer address with the link-layer address of the local AC.
- Send an Inverse Neighbor Solicitation to the local CE, specifying the far-end CE's IP address and the link-layer address of the PE interface attached to local AC.
- Reply to the far-end PE with a Neighbor Advertisement, using the IP address of the local CE as the source address and an appropriate link-layer address option that specifies the link-layer address of the PE interface attached to local AC. As described in Section 4.3.10, the IP address of the local CE is learned through IPv6 Control Protocol (IPv6CP) in the case of PPP and through Neighbor Solicitation in other cases.
4.3.4. Processing of Neighbor Advertisements
A Neighbor Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address and any link-layer address provided. The packet MUST then be forwarded over the IP pseudowire unmodified 🌷.
A Neighbor Advertisement received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the PE interface attached to local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the local AC has no valid link-layer address with which to transmit data packets 💫.
When a PE with a local AC that is of the type point-to-point Layer 2 circuit, such as ATM, FR, or PPP, receives a Neighbor Advertisement over the pseudowire, then in addition to learning the remote CE's IPv6 address, it SHOULD perform the following steps 📝:
- If the AC supports Inverse Neighbor Discovery (IND) and the PE had already processed an Inverse Neighbor Solicitation (INS) from the local CE, it SHOULD send an Inverse Neighbor Advertisement (INA) on the local AC using source IP address information received in an ND advertisement (ND-ADV) and its own local AC link-layer information.
- If the PE has not received any Inverse Neighbor Solicitation (INS) from the local CE and the AC supports Inverse Neighbor Discovery (IND), it SHOULD send an INS on the local AC using source IP address information received in the INA together with its own local AC link-layer information.
4.3.5. Processing Inverse Neighbor Solicitations (INSs)
An INS received on an AC from a local CE SHOULD be inspected to determine and learn the IPv6 addresses and the link-layer addresses. The packet MUST then be forwarded over the pseudowire unmodified 🧁.
An INS received over the pseudowire SHOULD be inspected to determine and learn one or more IPv6 addresses for the far-end CE. If the local AC supports IND (e.g., a switched Frame Relay AC), the packet SHOULD be forwarded to the local CE after modifying the link-layer address options to match the type of the local AC.
If the local AC does not support IND, processing of the packet depends on whether the PE has learned at least one interface address for its directly attached CE 🧐.
- If it has learned at least one IPv6 address for the CE, the PE MUST discard the Inverse Neighbor Solicitation (INS) and generate an Inverse Neighbor Advertisement (INA) back into the pseudowire. The destination address of the INA is the source address from the INS; the source address is one of the local CE's interface addresses; and all the local CE's interface addresses that have been learned so far SHOULD be included in the Target Address List. The Source and Target link-layer addresses are copied from the INS. In addition, the PE SHOULD generate ND advertisements on the local AC using the IPv6 address of the remote CE and the link-layer address of the local PE.
- If it has not learned at least one IPv6 and link-layer address of its directly connected CE, the INS MUST continue to be discarded until the PE learns an IPv6 and link-layer address from the local CE (through receiving, for example, a Neighbor Solicitation). After this has occurred, the PE will be able to respond to INS messages received over the pseudowire as described above 🫶.
4.3.6. Processing of Inverse Neighbor Advertisements (INAs) ✨
Okay, INAs bestie 🦋. When an INA comes in on an AC from a local CE, it SHOULD be inspected so the PE can determine and learn one or more IPv6 addresses for that CE. Then it MUST be forwarded unmodified over the pseudowire. 💅
When an INA comes in over the pseudowire, it SHOULD be inspected to determine and learn one or more IPv6 addresses for the far-end CE. ✨
If the local AC supports IND (like a Frame Relay AC), the packet MAY be forwarded to the local CE after the link-layer address options are modified to match the type of the local AC. 🌸
If the local AC does NOT support IND, the PE MUST discard the INA and generate a Neighbor Advertisement (NA) toward its local CE instead. The NA's source IPv6 address is the source IPv6 address from the INA. Its destination IPv6 address is the destination IPv6 address from the INA. And its link-layer address is the one for the local AC on the PE. It's literally a whole replacement moment 😭🎀
4.3.7. Processing of Router Solicitations 🧚
A Router Solicitation that arrives on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 address for the CE and, if present, the link-layer address of the CE. After that it MUST be forwarded unmodified over the pseudowire. 🍓
A Router Solicitation that arrives over the pseudowire SHOULD be inspected to determine and learn an IPv6 address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option that specifies the link-layer address of its local AC. Then the packet gets forwarded to the local CE. Main character energy 👑
4.3.8. Processing of Router Advertisements 🌈
A Router Advertisement that arrives on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 address for the CE and, if present, the link-layer address of the CE. Then it MUST be forwarded unmodified over the pseudowire. ⭐
A Router Advertisement that arrives over the pseudowire SHOULD be inspected to determine and learn an IPv6 address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option that specifies the link-layer address of its local AC. If an MTU option is present, the PE MAY reduce the specified MTU when the MTU of the pseudowire is less than the value in the option. Then the packet is forwarded to the local CE. It's giving careful and considerate 🫶
4.3.9. Duplicate Address Detection 🔥
Duplicate Address Detection [RFC4862] lets IPv6 hosts and routers make sure the addresses on their interfaces are unique on a link. Like all Neighbor Discovery packets, the ones used in Duplicate Address Detection just flow through the pseudowire and get inspected at the PEs at each end. Processing happens as detailed in Sections 4.3.3 and 4.3.4. 💖
BUT here's the tea 🙈: the source IPv6 address of Neighbor Solicitations used in Duplicate Address Detection is the unspecified address. So the PEs can't learn the CE's IPv6 interface address. And honestly it wouldn't even make sense to try, since at least one address is still tentative at that point. Not me being dramatic about it 💀
4.3.10. CE Address Discovery for CEs Attached Using PPP 🦋
The IPv6 Control Protocol (IPv6CP) [RFC5072] describes a procedure for setting up and configuring IPv6 on a point-to-point connection. That includes negotiating a link-local interface identifier. Just like with IPv4, when an AC like this is set up for IP interworking, PPP negotiation does NOT happen end to end between CE devices. Instead, it happens between the CE and its local PE. ✨
The PE does proxy PPP negotiation and tells the attached CE the link-local identifier of its local interface, using the Interface-Identifier option (0x01). That local interface identifier is then used by stateless address autoconfiguration [RFC4862]. It's a whole teamwork moment 🌸
When a PPP link finishes its IPv6CP negotiations and the PPP link is open, a PE MAY discover the IPv6 unicast address of the CE using any of the mechanisms described above. 🎀
5. CE IPv4 Address Signaling between PEs 💜
5.1. When to Signal an IPv4 Address of a CE 🌸
A PE device advertises the IPv4 address of the attached CE ONLY when the encapsulation type of the pseudowire is IP Layer2 Transport (the value 0x000B, as defined in [RFC4446]). The IP Layer2 transport PW is also called the IP PW, and this document uses the two names interchangeably. 🧚
Here's where it gets spicy 🔥: the IPv4 address of a CE device might NOT be available when the PW labels get signaled. For example, in Frame Relay, the CE device only sends an Inverse ARP request once the Data Link Connection Identifier (DLCI) is active. If the PE only signals the DLCI as active after it has received the IPv4 address along with the PW Forwarding Equivalence Class (FEC) from the remote PE, you get a deadlock. Nobody wins 😭
To avoid problems like that, the PE MUST be ready to advertise the PW FEC before the IPv4 address of the CE is known. So the PE uses an IPv4 address value of zero. Once the IPv4 address of the CE device does become available, the PE re-advertises the PW FEC along with that IPv4 address. Glow-up achieved 🌈
Same vibe in reverse: if the PE detects that an IP address of a CE is no longer valid (using the methods described above), the PE MUST re-advertise the PW FEC with a null IP address to show that the CE's IP address has been withdrawn. The receiving PE then waits for notification of the remote IP address. During that time, propagation of unicast IPv4 traffic is suspended, but multicast IPv4 traffic can keep flowing between the AC and the pseudowire. 💔 Multicast's still in the chat though 🦋
If two CE devices are attached locally to the PE on different AC types (say one CE is on an Ethernet port and the other is on a Frame Relay port), the IPv4 addresses are learned the same way as described above. But since both CE devices are local, distributing those IPv4 addresses is a local step. ⭐
Quick note 📝: PEs discover the IPv6 addresses of the remote CE by intercepting Neighbor Discovery and Inverse Neighbor Discovery packets that were passed in-band through the pseudowire. So there's NO need to communicate the IPv6 addresses of the CEs through LDP signaling. Less work, more slay 💅
If the pseudowire is carrying both IPv4 and IPv6 traffic, the mechanisms for IPv6 and IPv4 SHOULD NOT interact. Specifically, just because a PE has learned a link-layer address for IPv6 traffic by intercepting a Neighbor Advertisement from its directly connected CE, it SHOULD NOT assume it can use that link-layer address for IPv4 traffic. It has to wait until that's confirmed, for example by receiving an IPv4 ARP message from the CE. Boundaries, bestie 🫶
5.2. LDP-Based Distribution of CE IPv4 Addresses 🎀
[RFC4447] uses Label Distribution Protocol (LDP) transport to exchange PW FECs in the Label Mapping message in the Downstream Unsolicited (DU) mode. The PW FEC comes in two flavors, which share some common fields: PWid and Generalized ID FEC elements. The discussion below refers to those common fields for the IP L2 Interworking encapsulation. 🦋
On top of the PW FEC, this document uses an IP Address List TLV (as defined in [RFC5036]). That TLV is included in the optional parameter field of the Label Mapping message whenever the PW FEC is advertised for the IP Layer2 Transport. The use of optional parameters in the Label Mapping message to extend the attributes of the PW FEC is specified in [RFC4447]. 🌸
As [RFC4447] defines, when a PE processes a received PW FEC, it matches the PW ID and PW type against its locally configured PW ID and PW Type. If they match and the PW Type is IP Layer2 Transport, the PE then checks for an Address List TLV [RFC5036] in the optional parameter TLVs. Here's how that Address List TLV processing goes 👑
- If a PE is configured for an AC to a CE that's enabled for IPv4 or dual-stack IPv4/IPv6, the PE SHOULD advertise an Address List TLV with the address family type of IPv4 address. The PE SHOULD process the IPv4 Address List TLV as described in this document. The PE MUST advertise and process IPv6 capability using the procedures described in Section 6. ✨
- If a PE does NOT receive any IPv4 address in the Address List TLV, it MAY assume IPv4 behavior. The address resolution for IPv4 then MUST depend on local manual configuration. If the configuration is mismatched, with one PE having manual configuration and the other not, the IP address to link-layer address mapping stays unresolved. That means IPv4 traffic won't successfully propagate to the local CE. Oof 😭
- If a PE is configured for an AC to a CE that's enabled for IPv6 only, the PE MUST advertise IPv6 capability using the procedures described in Section 6. On top of that, because the manual configuration for IPv4 support isn't set, IPv6-only support gets realized. 🧚
We use the Address List TLV [RFC5036] to signal the IPv4 address of the local CE. This IP Address List TLV is included in the optional parameter field of the Label Mapping message. 💖
The Address List TLV is ONLY used for IPv4 addresses. 🔥
Here's how the fields of the IP Address List TLV get set 🍓
Length: Set to6, to cover the 2 bytes of the Address Family field and the 4 bytes of the Addresses field (because only a single IPv4 address is used).Address Family: Set to1to indicate IPv4, as defined in [RFC5036].Addresses: Contains a single IPv4 address, which is the address of the CE attached to the advertising PE.
The address in the Addresses field is set to all zeros to show that the advertising PE has NOT learned the IPv4 address of its local CE. Any non-zero address value is the IPv4 address of the advertising PE's attached CE device. 🌈
The IPv4 address of the CE is also supplied in the optional parameters field of the LDP Notification message, along with the PW FEC. The LDP Notification message is used to signal any change in the status of the CE's IPv4 address. ⭐
The LDP Notification message is encoded 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 say an IP address update is coming. Because this notification doesn't refer to any particular message, the Message ID field is set to 0. ✨
The PW FEC TLV SHOULD NOT include the interface parameters, since they're ignored in the context of this message. Ignored, so don't bother 💅
6. IPv6 Capability Advertisement 🎀
okay so the two PEs send a Stack Capability Interface Parameter sub-TLV so they can agree on which network protocol(s) they SHOULD be using 💅 like we talked about earlier, the Address List TLV already tells you the IPv4 stack is supported 🌸 so this sub-TLV is just the thing that flags whether IPv6 support is required on a given IP PW ✨
The Stack Capability Interface Parameter sub-TLV lives inside the interface parameters 🧚 here's the proposed format:
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 and Length = 4 🦋
The Stack Capability field is a bit field, and only one bit is defined in this document 🍓 when bit zero (the least significant bit, bitmask 0x0001) is set, it means IPv6 Stack Capability ✨
Now the presence of this sub-TLV only matters when the PW type is IP PW 💜 a PE that supports IPv6 on an IP PW MUST signal the Stack Capability Interface Parameter sub-TLV in the initial Label Mapping message for the PW 🔥 then the PE nodes compare what the remote PE advertised with their own local configuration, and they only use a capability that both sides support 🫶
If a PE doesn't understand an Interface Parameter sub-TLV, the behavior is specified in Section 5.5 of RFC 4447 [RFC4447] 🌈
Sometimes you want a PW to go operationally down if the Stack Capability doesn't match between the PEs 💀 other times an operator wants both PEs to fall back to IPv4 if one of them doesn't support IPv6 🙈 the following procedures MUST be followed for each of these cases 👑
6.1. PW Operational Down on Stack Capability Mismatch
If a PE that supports IPv6 and hasn't sent a Label Mapping message yet receives an initial Label Mapping message from the far-end PE that either doesn't include the Stack Capability Interface Parameter sub-TLV, or includes one that isn't set to the 'IPv6 Stack Capability' value, then that PE MUST NOT send a Label Mapping message for this PW 😭
If a PE that supports IPv6 has already sent an initial Label Mapping message for the PW, and it doesn't receive a Stack Capability Interface Parameter sub-TLV in the Label Mapping message from the far-end PE (or it gets one that isn't set to 'IPv6 Stack Capability'), the PE supporting this procedure MUST withdraw its PW label with the LDP status code meaning "IP Address type mismatch" (Status Code 0x0000004A) 💅 but here's the twist: if the far-end PE's configuration changes later and it sends a Stack Capability Interface Parameter sub-TLV in the Label Mapping message, the local PE MUST re-advertise the Label Mapping message for the PW 🦋 comeback arc, iconic ✨
6.2. Stack Capability Fallback
If a PE that supports IPv6 and hasn't sent a Label Mapping message yet receives an initial Label Mapping message from the far-end PE that either doesn't include the Stack Capability Interface Parameter sub-TLV, or includes one that isn't set to the 'IPv6 Stack Capability' value, then it MAY send a Label Mapping message for this PW 🌸 but it MUST NOT include the Stack Capability Interface Parameter sub-TLV 🧚
If a PE that supports IPv6 has already sent a Label Mapping message for the PW with the Stack Capability Interface Parameter sub-TLV, but it doesn't receive a Stack Capability Interface Parameter sub-TLV from the far-end PE in the initial Label Mapping message (or it gets one that isn't set to the 'IPv6 Stack Capability' value), the PE following this procedure MUST send a Label Withdraw for its PW label with the LDP status code meaning "Wrong IP Address type" (Status Code 0x000004B) 🍓 and then a Label Mapping message that does NOT include the Stack Capability Interface Parameter sub-TLV, which MUST NOT be left out of the picture 🙈 wait, let me restate that cleanly: the follow-up Label Mapping message MUST NOT include the sub-TLV at all ✨
If a PE gets a Label Withdraw message with the "Wrong IP Address Type" status code, it SHOULD treat that as a normal Label Withdraw 🫶 but it MUST NOT respond with a Label Release 🌈 it MUST continue to wait for the next control message for the PW, as specified in Section 6.2 of RFC 4447 [RFC4447] 💜
7. IANA Considerations 🌸
7.1. LDP Status Messages
This document uses new LDP status codes 🎀 IANA already maintains a registry called "Status Code Name Space", which was defined by [RFC5036] 🦋 the following values have been assigned:
0x0000002C "IP Address of CE"
0x0000004A "IP Address Type Mismatch"
0x0000004B "Wrong IP Address Type"7.2. Interface Parameters
This document proposes a new Interface Parameters sub-TLV, which has been assigned from the 'Pseudowire Interface Parameters Sub-TLV type Registry' 💅 the following value has been assigned for the Parameter ID:
0x16 "Stack Capability"IANA also set up a registry of "L2VPN PE stack Capabilities" 👑 it's a 16-bit field. Stack Capability bitmask 0x0001 is specified in Section 6 of this document ✨ the remaining bitfield values (0x0002,..,0x8000) are to be assigned by IANA using the "IETF Review" policy defined in [RFC5226] 🧚
L2VPN PE Stack Capabilities:
Bit (Value) Description
=============== ========================
Bit 0 (0x0001) - IPv6 stack capability
Bit 1 (0x0002) - Unassigned
Bit 2 (0x0004) - Unassigned
.
.
.
Bit 14 (0x4000) - Unassigned
Bit 15 (0x8000) - Unassigned8. Security Considerations 💀
okay this part is SERIOUS bestie 😭 the security of this solution gets covered for two planes: the control plane and the data plane 🔥
8.1. Control Plane Security
Control plane security is about setting up the LDP connection, plus pseudowire signaling and CE IP address distribution over that LDP connection 💜 for extra security, the LDP connection between two trusted PEs MUST be secured by each PE verifying the incoming connection against the configured address of the peer, and by authenticating the LDP messages, as described in Section 2.9 of [RFC5036] 🛡️ pseudowire signaling between two secure LDP peers isn't a security issue on its own, but mis-wiring could still happen because of a configuration error 🙈 the good news is the pseudowire only gets established if the two PEs have matching configurations (for example PW ID, PW type, and MTU), which gives you some protection against mis-wiring from config mistakes ✨
Learning the IP address of the right CE can be a security issue 😭 it's expected that the Attachment Circuit to the local CE will be physically secured 🌸 if that's a concern, the PE MUST be configured with the IP and MAC address of the CE when connected with Ethernet, with the IP and virtual circuit information (DLCI or VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier)) when connected over Frame Relay or ATM, and with just the IP address when connected over PPP 🦋 during ARP/Inverse ARP frame processing, the PE MUST verify the received information against local configuration before forwarding it to the remote PE, so nobody can hijack the connection 💅
For IPv6, the preferred security option is Secure Neighbor Discovery (SEND) [RFC3971] 🧚 SEND secures Neighbor Discovery packets over media (like wireless links) that could be insecure and open to packet interception and substitution 🌈 it's based on cryptographic signatures of Neighbor Discovery packets, which let the receiving node detect packet modification and confirm that a received packet actually came from the source node it claims 🔥
BUT here's the tea: SEND is incompatible with the Neighbor Discovery packet modifications described in this document 💀 so SEND can't be used for Neighbor Discovery across an ARP Mediation pseudowire 😭 PEs taking part in IPv6 ARP Mediation MUST remove all SEND packet options from Neighbor Discovery packets before forwarding them into the pseudowire 🫶 and if the CE devices are configured to accept only SEND Neighbor Discovery packets, Neighbor Discovery will fail 🙈 so the CE devices MUST be configured to accept non-SEND packets, even if they treat those with lower priority than SEND packets 💜 since SEND can't be combined with IPv6 ARP Mediation, it's suggested that IPv6 ARP Mediation only be used with secure Attachment Circuits 👑 the one exception is an implementation that supports the SEND Proxy [RFC6496], which lets a device such as a PE act as an ND proxy, as described in [RFC6496] ✨
8.2. Data Plane Security
The data traffic between CE and PE is NOT encrypted 😭 in an insecure environment, a malicious user could tap into the CE-to-PE connection and generate traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit 💀 to avoid this kind of hijacking, the local PE may verify the source MAC address of the received frame against the MAC address of the admitted connection 🛡️ the frame only gets forwarded to the PW once its authenticity is verified 🌸 and when spoofing is detected, the PE MUST sever the connection with the local CE, tear down the PW, and start over 🔥
9. Acknowledgements 🫶
The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro, and others who participated in the discussions related to this document 💖
10. Contributors 🌈
This document is the combined effort of many people who contributed, carefully reviewed, and provided technical clarifications 🧚 this includes the individuals listed in this section and those listed in the Editors' Addresses 💜
Matthew Bocci Alcatel-Lucent EMail: Mathew.bocci@alcatel-lucent.com
Tiberiu Grigoriu Alcatel-Lucent EMail: Tiberiu.Grigoriu@alcatel-lucent.com
Neil Hart Alcatel-Lucent EMail: Neil.Hart@alcatel-lucent.com
Andrew Dolganow Alcatel-Lucent EMail: Andrew.Dolganow@alcatel-lucent.com
Shane Amante Level 3 EMail: Shane@castlepoint.net
Toby Smith Google EMail: tob@google.com
Andrew G. Malis Verizon EMail: Andy.g.Malis@verizon.com
Steven Wright Bell South Corp EMail: steven.wright@bellsouth.com
Waldemar Augustyn Consultant EMail: waldemar@wdmsys.com
Arun Vishwanathan Juniper Networks EMail: arunvn@juniper.net
Ashwin Moranganti IneoQuest Technologies EMail: Ashwin.Moranganti@Ineoquest.com
11. References ✨
11.1. Normative References 📚
[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.
[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[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.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
11.2. Informative References 🌸
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, October 2008.
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-Martinez, "Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)", RFC 6496, February 2012.
Appendix A. Use of IGPs with IP L2 Interworking L2VPNs 🧚
okay so this appendix is about what happens when an IGP on a CE attached to a broadcast link gets cross-connected with an IGP on a CE attached to a point-to-point link 👀 in an IP L2 interworking L2VPN, there are routing protocol issues that MUST be addressed 🚨 the link state routing protocols are aware of the underlying link characteristics and act accordingly when they set up neighbor adjacencies, represent the network topology, and pass protocol packets. the point-to-point operation of routing protocols over a LAN is covered in [RFC5309] 💅
A.1. OSPF 💖
ngl OSPF handles a broadcast link with a special procedure. it uses Neighbor Discovery to elect a designated router and a backup designated router (DR and BDR, respectively), and every other router on the link forms adjacencies with them 🫶 but these procedures are neither applicable nor understood by OSPF running on a point-to-point link. so when you cross-connect two neighbors with different link types, an IP L2 interworking L2VPN can run into connectivity issues 😭
also, the link type in the router Link State Advertisement (LSA) won't match between the two cross-connected routers 🙈
and finally, each OSPF router generates network LSAs when it's connected to a broadcast link such as Ethernet. if an OSPF router that thinks it's on a point-to-point link receives those, it just adds to the confusion 💀
luckily, OSPF has a configuration option (ospfIfType) that tells OSPF to treat the underlying physical broadcast link as a point-to-point link ✨ it is strongly recommended that all OSPF protocols on CE devices connected to Ethernet interfaces use this configuration option when attached to a PE that is participating in an IP L2 Interworking VPN 🔥
A.2. RIP 🌈
the RIP protocol broadcasts RIP advertisements every 30 seconds 🦋 if the multicast/broadcast traffic snooping mechanism is used as described in Section 4.1, the attached PE can learn the local CE router's IP address from the IP header of its advertisements. no special configuration is required for RIP in this type of Layer 2 IP Interworking L2VPN 👑
A.3. IS-IS 🙅♀️
the IS-IS protocol doesn't encapsulate its PDUs in IP, so it can't be supported in IP L2 Interworking L2VPNs 💔
Editors' Addresses 💌
Himanshu Shah (editor) Ciena EMail: hshah@ciena.com
Eric Rosen (editor) Cisco Systems EMail: erosen@cisco.com
Giles Heron (editor) Cisco Systems EMail: giheron@cisco.com
Vach Kompella (editor) Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
📦 where this page comes from
- ietf: rfc6575 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms