draft-ietf-l2vpn-arp-mediation-00.txt   draft-ietf-l2vpn-arp-mediation-01.txt 
L2VPN Working Group H. Shah Ciena L2VPN Working Group H. Shah Ciena
Internet Draft E. Rosen Cisco Systems Internet Draft E. Rosen Cisco Systems
W. Augustyn consultant W. Augustyn consultant
October 2004 G. Heron Tellabs April 2005 G. Heron Tellabs
Expires: April 2005 T. Smith Laurel Networks Expires: September 2005 T. Smith Laurel Networks
A. Moranganti Axiowave Networks A. Moranganti Big Band Networks
S. Khandekar Alcatel S. Khandekar Alcatel
V. Kompella Alcatel V. Kompella Alcatel
A. Malis Tellabs A. Malis Tellabs
S. Wright Bell South S. Wright Bell South
V. Radoaca Nortel Networks V. Radoaca Westridge Networks
A. Vishwanathan Force10 Networks A. Vishwanathan Force10 Networks
ARP Mediation for IP Interworking of Layer 2 VPN ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-00.txt draft-ietf-l2vpn-arp-mediation-01.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 54 skipping to change at line 54
The VPWS service [L2VPN Framework] provides point-to-point The VPWS service [L2VPN Framework] provides point-to-point
connections between pairs of Customer Edge (CE) devices. It does connections between pairs of Customer Edge (CE) devices. It does
so by binding two Attachment Circuits (each connecting a CE device so by binding two Attachment Circuits (each connecting a CE device
with a Provider Edge, PE, device) to a Pseudowire (connecting the with a Provider Edge, PE, device) to a Pseudowire (connecting the
two PEs). In general, the Attachment Circuits must be of the same two PEs). In general, the Attachment Circuits must be of the same
technology (e.g., both ethernet, both ATM), and the Pseudowire must technology (e.g., both ethernet, both ATM), and the Pseudowire must
carry the frames of that technology. However, if it is known that carry the frames of that technology. However, if it is known that
the frames' payload consists solely of IP datagrams, it is possible the frames' payload consists solely of IP datagrams, it is possible
to provide a point-to-point connection in which the Pseudowire to provide a point-to-point connection in which the Pseudowire
draft-ietf-l2vpn-arp-mediation-00.txt draft-ietf-l2vpn-arp-mediation-01.txt
connects Attachment Circuits of different technologies. This connects Attachment Circuits of different technologies. This
requires the PEs to perform a function known as "ARP Mediation". requires the PEs to perform a function known as "ARP Mediation".
This document specifies the ARP Mediation function, and specifies ARP Mediation refers to the process of resolving Layer 2 addresses
the encapsulation used to carry the IP datagrams on the Pseudowires when different resolution protocols are used on either Attachment
when ARP mediation is used. Circuit. The methods described in this document are applicable even
when the CEs run a routing protocol between them, as long as the
routing protocol runs over IP. In particular, the applicability of
ARP mediation to ISIS is not addressed.
Table of Contents Table of Contents
1 .0 Introduction................................................2 1 .0 Introduction................................................2
2 .0 ARP Mediation (AM) function.................................3 2 .0 ARP Mediation (AM) function.................................3
3 .0 IP Layer 2 Interworking Circuits............................4 3 .0 IP Layer 2 Interworking Circuits............................4
4 .0 Discovery of IP Addresses of Locally Attached CE Device.....4 4 .0 Discovery of IP Addresses of Locally Attached CE Device.....4
4.1 Monitoring Local Traffic.....................................4 4.1 Monitoring Local Traffic.....................................4
4.2 CE Devices Using ARP.........................................4 4.2 CE Devices Using ARP.........................................4
4.3 CE Devices Using Inverse ARP.................................6 4.3 CE Devices Using Inverse ARP.................................5
4.4 CE Devices Using PPP.........................................6 4.4 CE Devices Using PPP.........................................6
4.5 Proactive method.............................................6 4.5 Router Discovery method......................................6
5 .0 IP Address Distribution Between PE..........................7 5 .0 CE IP Address Signaling between PEs.........................7
5.1 When To Distribute IP Address................................7 5.1 When to Signal a CEĂs IP Address.............................7
5.2 LDP Based Distribution.......................................7 5.2 LDP Based Distribution.......................................7
5.3 Out-of-band Distribution, Manual Configuration...............8 5.3 Out-of-band Distribution Configuration.......................8
5.4 Single sided ARP mediation...................................8 6 .0 How a CE Learns the Remote CE's IP address..................8
6 .0 How CE Learns The Remote CE's IP address....................9 6.1 CE Devices Using ARP.........................................8
6.1 CE Devices Using ARP.........................................9 6.2 CE Devices Using Inverse ARP.................................9
6.2 CE Devices Using Inverse ARP................................10 6.3 CE Devices Using PPP.........................................9
6.3 CE Devices Using PPP........................................10 7 .0 Use of IGPs with IP L2 Interworking L2VPNs..................9
7 .0 Use of IGPs with IP L2 Interworking L2VPNs.................10 7.1 OSPF.........................................................9
7.1 OSPF........................................................10 7.2 RIP.........................................................10
7.2 IS-IS.......................................................11 8 .0 Security Considerations....................................10
7.3 RIP.........................................................11 8.1 Control plane security......................................10
8 .0 Security Considerations....................................12 8.2 Data plane security.........................................11
9 .0 Acknowledgements...........................................12 9 .0 Acknowledgements...........................................11
10 .0 References................................................12 10 .0 References................................................11
10.1 Normative References.......................................12 10.1 Normative References.......................................11
10.2 Informative References.....................................12 10.2 Informative References.....................................11
11 .0 Authors' Addresses........................................13 11 .0 Authors' Addresses........................................12
1.0 Introduction 1.0 Introduction
Layer 2 Virtual Private Networks (L2VPN) are constructed with the Layer 2 Virtual Private Networks (L2VPN) are constructed over a
use of a Service Provider IP backbone but are presented to the Service Provider IP backbone but are presented to the Customer Edge
Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs (CE) devices as Layer 2 networks. In theory, L2VPNs can carry any
can carry any Layer 3 protocol, but in many cases, the only Layer 3 Layer 3 protocol, but in many cases, the Layer 3 protocol is IP.
protocol is IP. Thus it makes sense to consider procedures that Thus it makes sense to consider procedures that are optimized for
are either optimized for IP or are outright dedicated to IP traffic IP.
only.
In a typical implementation, illustrated in the diagram below, the In a typical implementation, illustrated in the diagram below, the
CE devices are connected to the Provider Edge (PE) devices via CE devices are connected to the Provider Edge (PE) devices via
Attachment Circuits (AC). The ACs are Layer 2 links. In a pure Attachment Circuits (AC). The ACs are Layer 2 links. In a pure
L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both
Shah, et. al. Expires April 2005 2 Shah, et. al. Expires September 2005 2
draft-ietf-l2vpn-arp-mediation-00.txt draft-ietf-l2vpn-arp-mediation-01.txt
L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both
ACs would have to be of the same type (i.e., both Ethernet, both ACs would have to be of the same type (i.e., both Ethernet, both
FR, etc.). However, if it is known that only IP traffic will be FR, etc.). However, if it is known that only IP traffic will be
carried, the ACs can be of different technologies, provided that carried, the ACs can be of different technologies, provided that
the PEs provide the appropriate procedures to allow the proper the PEs provide the appropriate procedures to allow the proper
transfer of IP packets. transfer of IP packets.
+-----+ +-----+
+--------------------| CE3 | +--------------------| CE3 |
| +-----+ | +-----+
+-----+ +-----+
skipping to change at line 135 skipping to change at line 137
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+ +-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 | | CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+ +-----+ +-----+ Backbone +-----+ +-----+
. . . .
........................ ........................
A CE, which is connected via a given type of AC, may use an IP A CE, which is connected via a given type of AC, may use an IP
Address Resolution procedure that is specific to that type of AC. Address Resolution procedure that is specific to that type of AC.
For example, an Ethernet-attached CE would use ARP, a FR-attached For example, an Ethernet-attached CE would use ARP, a FR-attached
CE might use Inverse ARP. If we are to allow the two CEs to have a CE might use Inverse ARP. If we are to allow the two CEs to have a
layer 2 connection between them, even though each AC uses a Layer 2 connection between them, even though each AC uses a
different layer 2 technology, the PEs must intercept and "mediate" different Layer 2 technology, the PEs must intercept and "mediate"
the technology-specific address resolution procedures. the Layer 2 specific address resolution procedures.
In this draft, we specify the procedures which the PEs must In this draft, we specify the procedures, which the PEs must
implement in order to mediate the IP address resolution mechanism. implement in order to mediate the IP address resolution mechanism.
We call these procedures "ARP Mediation". We call these procedures "ARP Mediation".
Consider a Virtual Private Wire Service (VPWS) constructed between Consider a Virtual Private Wire Service (VPWS) constructed between
CE1 and CE2 in the diagram above. If AC1 and AC2 are of different CE1 and CE2 in the diagram above. If AC1 and AC2 are of different
technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR),
then ARP requests coming from CE1 cannot be passed transparently to then ARP requests coming from CE1 cannot be passed transparently to
CE2. PE1 must interpret the meaning of the ARP requests and CE2. PE1 must interpret the meaning of the ARP requests and
mediate the necessary information with PE2 before responding. mediate the necessary information with PE2 before responding.
2.0 ARP Mediation (AM) function 2.0 ARP Mediation (AM) function
The ARP Mediation (AM) function is an element of a PE node The ARP Mediation (AM) function is an element of a PE node that
operation that deals with the IP address resolution for CE devices deals with the IP address resolution for CE devices connected via
connected via a L2VPN. By placing this function in the PE node, ARP an L2VPN. By placing this function in the PE node, ARP Mediation is
Mediation can be made completely transparent to the CE devices. transparent to the CE devices.
For a given point-to-point connection between a pair of CEs, a PE For a given point-to-point connection between a pair of CEs, a PE
must perform three logical steps as part of the ARP Mediation must perform three logical steps as part of the ARP Mediation
procedure: procedure:
1. Discover the IP addresses of the locally attached CE device 1. Discover the IP addresses of the locally attached CE device
2. Distribute those IP Addresses to the remote PE
Shah, et. al. Expires April 2005 3 Shah, et. al. Expires September 2005 3
draft-ietf-l2vpn-arp-mediation-00.txt draft-ietf-l2vpn-arp-mediation-01.txt
2. Distribute those IP Addresses to the remote PE
3. Notify the locally attached CE of the remote CE's IP address. 3. Notify the locally attached CE of the remote CE's IP address.
This information is gathered using the mechanisms described in the This information is gathered using the mechanisms described in the
following sections. following sections.
3.0 IP Layer 2 Interworking Circuits 3.0 IP Layer 2 Interworking Circuits
The IP Layer 2 Interworking Circuits refer to Pseudowires that The IP Layer 2 Interworking Circuits refer to Pseudowires that
carry IP datagram as the payload. At ingress, data link header of carry IP datagrams as payload. The ingress PE removes the data
an IP frame is removed and dispatched over the Pseudowire with or link header of its local Attachment Circuit and transmits the
without the optional control word. At the egress, PE encapsulates payload (an IP frame) over the Pseudowire with or without the
the IP packet with the data link header used on the local optional control word. The egress PE encapsulates the IP packet
Attachment Circuit. with the data link header used on its local Attachment Circuit.
The use of this encapsulation is determined by the exchange of The IP Pseudowire encapsulation is described in [PWE3-IANA].
value 0x000B as the PW type during Pseudowire establishment as
described in [PWE3-Control].
4.0 Discovery of IP Addresses of Locally Attached CE Device 4.0 Discovery of IP Addresses of Locally Attached CE Device
An IP Layer 2 Interworking Circuit enters monitoring state right An IP Layer 2 Interworking Circuit enters monitoring state
after the configuration. During this state it performs two immediately after the configuration. During this state it performs
functions. two functions.
. Discovery of locally attached CE IP device . Discovery of locally attached CE IP device
. Establishment of the PW . Establishment of the PW
The establishment of PW occurs independently from local CE IP The establishment of the PW occurs independently from local CE IP
address discovery. During the period when (bi-directional) PW has address discovery. During the period when the (bi-directional) PW
been established but local CE IP device has not been detected, only has been established but local CE IP device has not been detected,
datagrams inside of broadcast/multicast frames are propagated; IP only datagrams inside of broadcast/multicast frames are propagated;
datagrams inside unicast frames are dropped. The IP datagrams from IP datagrams inside unicast frames are dropped. The IP datagrams
unicast frames flow only when IP end systems on both Attachment from unicast frames flow only when IP end systems on both
Circuits have been discovered, notified and proxy functions have Attachment Circuits have been discovered, notified and proxy
completed. functions have completed.
4.1 Monitoring Local Traffic 4.1 Monitoring Local Traffic
The PE devices may learn the IP addresses of the locally attached The PE devices may learn the IP addresses of the locally attached
CEs from any IP traffic, such as local multicast (e.g. 224.x.x.x) CEs from any IP traffic, such as link local multicast packets
packets, that CE may generate irrespective of reacting to specific (e.g., destined to 224.0.0.x), and are not restricted to the
address resolution queries described below. operations below.
4.2 CE Devices Using ARP 4.2 CE Devices Using ARP
If a CE device uses ARP to determine the MAC address to IP address If a CE device uses ARP to determine the MAC address to IP address
binding of its neighbor, the PE processes the ARP requests to learn binding of its neighbor, the PE processes the ARP requests to learn
the IP address of local CE for the stated locally attached circuit. the IP address of local CE for the stated locally attached circuit.
If we observe the strict topology restriction whereby only one IP If we observe the strict topology restriction whereby only one IP
router CE can exist for a given attachment circuit then the PE can
Shah, et. al. Expires April 2005 4 Shah, et. al. Expires September 2005 4
draft-ietf-l2vpn-arp-mediation-00.txt draft-ietf-l2vpn-arp-mediation-01.txt
router CE can exist for a given attachment circuit then PE can
assume that ARP request received is from the candidate IP CE and assume that ARP request received is from the candidate IP CE and
can learn the IP to MAC address binding of the local CE. can learn the IP to MAC address binding of the local CE.
However, if this topology restriction is relaxed, the PE can learn However, if this topology restriction is relaxed, the PE can learn
the MAC address to IP address binding of the local CE but can not the MAC address to IP address binding of the local CE but can not
assume that this CE (possibly amongst many) is the candidate IP assume that this CE (possibly amongst many) is the candidate IP
device that is to be interworked with the remote attachment device that is to be interworked with the remote attachment
circuit. In these circumstances, PE may select the local CE device circuit. In this case, the PE may select the local CE device using
using following criteria. following criteria.
. Wait to learn the IP address of the remote CE (through PW . Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending the signaling) and then select the local CE that is sending the
ARP request for the remote CEĂs IP address. ARP request for the remote CEĂs IP address.
. Augment cross checking with the local IP address learned . Augment cross checking with the local IP address learned
through listening of link local multicast packets (as per through listening of link local multicast packets (as per
section 4.1 above) section 4.1 above)
. Augment cross checking with the local IP address learned . Augment cross checking with the local IP address learned
through Router Discovery protocol (as described below in through the Router Discovery protocol (as described below in
section 4.5). section 4.5).
. There is still a possibility that PE may not receive IP . There is still a possibility that the local PE may not receive
address advertisement from the remote and there may exist an IP address advertisement from the remote PE and there may
multiple local IP routers that attempt to 'connect' to exist multiple local IP routers that attempt to 'connect' to
remote CEs. In this situation, PE may use some arbitrary remote CEs. In this situation, the local PE may use some other
criteria to select one IP device from many (such as first ARP criteria to select one IP device from many (such as ˘the first
received), or have operator configure the IP address of ARP received÷), or an operator may configure the IP address of
local CE. Note that operator does not have to configure the local CE. Note that the operator does not have to configure
MAC address of the local CE as that would be learned through the IP address of the remote CE (as that would be learned
ARP mechanisms described above nor the IP address of the through Pseudowire signaling).
remote CE as that would be learned through Pseudowire
signaling described later in this document.
Once the local CE has been discovered for the given attachment Once the local CE has been discovered for the given Attachment
circuit, PE responds to the subsequent ARP requests from that Circuit, the local PE responds to subsequent ARP requests from that
device with the MAC address of his own. The PE signals the IP device with its own MAC address. The local PE signals the CEĂs IP
address to the remote PE and may initiate the unsolicited ARP address to the remote PE and may initiate an unsolicited ARP
response as a means to notify local CE, the IP address to MAC response to notify local CE MAC address to IP address binding of
address binding of the remote, in order to facilitate unicast the remote CE. Once this is completed, unicast traffic between two
traffic between two CEs. CEs can start flowing.
The PE may periodically generate ARP request messages to the CE's The PE may periodically generate ARP request messages to the CE's
IP address as a means to verify the continued existence of the IP address as a means of verifying the continued existence of the
address and its binding to the stated MAC address. The absence of a address and its binding to the MAC address. The absence of a
response from the CE device for a given number of retries could be response from the CE device for a given number of retries could be
used as a cause for a withdrawal of the IP address advertisement to used as cause for withdrawal of the IP address advertisement to the
the remote PE and entering into the address resolution phase to remote PE. The local PE would then enter into the address
rediscover the attached CE's IP address. Note that such "heartbeat" resolution phase to rediscover the attached CE's IP address. Note
scheme is needed only for broadcast links, as a loss of CE may that this "heartbeat" scheme is needed only for broadcast links, as
otherwise be undetectable. the loss of a CE may otherwise be undetectable.
Shah, et. al. Expires April 2005 5
draft-ietf-l2vpn-arp-mediation-00.txt
4.3 CE Devices Using Inverse ARP 4.3 CE Devices Using Inverse ARP
Shah, et. al. Expires September 2005 5
draft-ietf-l2vpn-arp-mediation-01.txt
If a CE device uses Inverse ARP to determine the IP address of its If a CE device uses Inverse ARP to determine the IP address of its
neighbor, the attached PE processes the Inverse ARP request for neighbor, the attached PE processes the Inverse ARP request for
stated circuit and responds with an Inverse ARP reply containing stated circuit and responds with an Inverse ARP reply containing
the remote CE's IP address, if the address is known. If the PE does the remote CE's IP address, if the address is known. If the PE does
not yet have the remote CE's IP address, it does not respond, but not yet have the remote CE's IP address, it does not respond, but
notes the IP address of the local CE and the circuit information. notes the IP address of the local CE and the circuit information.
Subsequently, when the IP address of the remote CE becomes Subsequently, when the IP address of the remote CE becomes
available, the PE may initiate the Inverse ARP request as a means available, the PE may initiate the Inverse ARP request as a means
to notify the local CE about the IP address of the remote CE. to notify the local CE about the IP address of the remote CE.
This is a typical operation for Frame Relay and ATM attachment This is a typical operation for Frame Relay and ATM attachment
circuits. In the cases where the CE does not use Inverse ARP, PE circuits. When the CE does not use Inverse ARP, PE could still
could still discover the CE as described in section 4.1 and 4.5. discover the local CEĂs IP address as described in section 4.1 and
4.5.
4.4 CE Devices Using PPP 4.4 CE Devices Using PPP
When PPP link becomes operational after the LCP negotiations, PE When a PPP link becomes operational after the LCP negotiations, the
performs following action local PE performs following actions
. If PE does not know the IP address of the local CE, it . If the local PE does not know the IP address of the local CE,
generates configure-request without configure IP address TLV. it generates a configure-request without the configure IP
The response from CE is accepted as IP address of the local address TLV. The response from CE is accepted as IP address of
CE. the local CE.
. If PE knows the IP address of the remote CE, it sends IPCP . If PE knows the IP address of the remote CE, it sends an IPCP
configure-request with IP address of the remote CE in the configure-request with the IP address of the remote CE in the
configure IP address TLV configure IP address TLV
. If PE receives IPCP configure-request without configure IP . If the local PE receives an IPCP configure-request without the
address TLV, and if it knows the IP address of the remote CE, configure IP address TLV, and if it knows the IP address of
it responds with configure NAK with configure IP address TLV the remote CE, it responds with configure NAK with the
set with remote CEĂs IP address. However, if PE does not know configure IP address TLV set with remote CEĂs IP address.
the remote CEĂs IP address yet, it responds with configure However, if PE does not know the remote CEĂs IP address yet,
NAK. it responds with a configure NAK.
. If PE does not know the IP address of the remote CE, it sends . If the local PE does not know the IP address of the remote CE,
IPCP configure-request with IP address as zero. The response it sends an IPCP configure-request with IP address as zero.
from CE is recorded and used to validate the incoming remote The response from CE is recorded and used to validate the
CEĂs IP address via PW signaling. incoming remote CEĂs IP address via PW signaling.
The PE must deny configurations such as header compression and The local PE must deny configurations such as header compression
encryptions in the NCP packets with such options. and encryptions in the NCP packets with such options.
4.5 Proactive method 4.5 Router Discovery method
In order to learn the IP address of the CE device for a given In order to learn the IP address of the CE device for a given
Attachment Circuit, the PE device may execute Router Discovery Attachment Circuit, the PE device may execute Router Discovery
Protocol [RFC 1256] whereby a Router Discovery Request (ICMP ű Protocol [RFC 1256] whereby a Router Discovery Request (ICMP ű
router solicitation) message is sent using a source IP address of router solicitation) message is sent using a source IP address of
zero. The IP address of the CE device is extracted from the Router zero. The IP address of the CE device is extracted from the Router
Discovery Response (ICMP ű router advertisement) message from the Discovery Response (ICMP ű router advertisement) message from the
CE. CE.
Shah, et. al. Expires April 2005 6 Shah, et. al. Expires September 2005 6
draft-ietf-l2vpn-arp-mediation-00.txt draft-ietf-l2vpn-arp-mediation-01.txt
The use of the router discovery mechanism by the PE is optional. The use of the Router Discovery method by the PE is optional.
5.0 IP Address Distribution Between PE 5.0 CE IP Address Signaling between PEs
5.1 When To Distribute IP Address 5.1 When to Signal a CEĂs IP Address
A PE device advertises the IP address of the attached CE only when A PE device advertises the IP address of the attached CE only when
the encapsulation type of the Pseudowire is IP L2 interworking the encapsulation type of the Pseudowire is IP L2 interworking . It
(0x0B). It is quite possible that the IP address of a CE device is is quite possible that the IP address of a CE device is not
not available at the time the PW labels are advertised. For available at the time the PW labels are signaled. For example, in
example, in Frame Relay the CE device dispatches inverse ARP Frame Relay the CE device sends an inverse ARP request only when
request only when the DLCI is active; if the PE signals the DLCI to the DLCI is active; if the PE signals the DLCI to be active only
be active only when it has received the IP address along with the when it has received the IP address along with the PW FEC from the
PW-FEC from the remote PE, a chicken and egg situation arises. In remote PE, a chicken and egg situation arises. In order to avoid
order to avoid such problems, the PE must be prepared to advertise such problems, the PE must be prepared to advertise the PW FEC
the PW-FEC before the CE's IP address is known. When the IP address before the CE's IP address is known. When the IP address of the CE
of the CE device does become available, the PE re-advertises the device does become available, the PE re-advertises the PW FEC along
PW-FEC along with the IP. with the IP.
Similarly, if the PE detects invalidation of the CE's IP address Similarly, if the PE detects a CE's IP address is no longer
(by methods described above) the PE must re-advertise the PW-FEC valid(by methods described above), the PE must re-advertise the PW
with null IP address to denote the withdrawal of the CE's IP FEC with null IP address to denote the withdrawal of the CE's IP
address. The receiving PE then waits for the notification of remote address. The receiving PE then waits for notification of the remote
IP address. During this period, propagation of unicast IP traffic IP address. During this period, propagation of unicast IP traffic
is suspended while continuing to let multicast IP traffic flow. is suspended, but multicast IP traffic can continue to flow.
If two CE devices are locally attached to the PE where, one CE is If two CE devices are locally attached to the PE where one CE is
connected to an Ethernet data link and the other to a Frame Relay connected to an Ethernet port and the other to a Frame Relay port,
interface, for example, the IP addresses are learned in the same for example, the IP addresses are learned in the same manner
manner described above. However, since the CE devices are local, described above. However, since the CE devices are local, the
the distribution of IP addresses for these CE devices is a local distribution of IP addresses for these CE devices is a local step.
step.
5.2 LDP Based Distribution 5.2 LDP Based Distribution
The [PWE3-CONTROL] uses Label Distribution Protocol (LDP) transport The [PWE3-CONTROL] uses Label Distribution Protocol (LDP) transport
to exchange PW-FEC in the Label Mapping message in a downstream to exchange PW FEC in the Label Mapping message in the Downstream
unsolicited mode. The PW-FEC comes in two flavors; Pwid and Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and
Generalized ID FEC elements and shares some fields that are common Generalized ID FEC elements and have some common fields between
between them. The discussions below refer to these common fields them. The discussions below refer to these common fields for IP L2
for IP L2 Interworking Circuits. Interworking Circuits.
The IP L2 Interworking uses IP datagram as payload over the The IP L2 Interworking uses an IP datagram as payload over the
Pseduowire. The use of such encapsulation is identified by PW type Pseudowire[PWE3-IANA].
field of the PW-FEC as the value 0x000B [PWE3-Control].
In addition, this document defines an IP address TLV that must be In addition, this document defines an IP address TLV that must be
included in the optional TLV field of the Label Mapping message included as an optional parameter in the Label Mapping message
when advertising the PW FEC for the IP L2 Interworking Circuit. The
Shah, et. al. Expires April 2005 7 use of optional parameters in the Label Mapping message to extend
draft-ietf-l2vpn-arp-mediation-00.txt the attributes of the PW FEC is specified in the [PWE3-Control].
when advertising PW-FEC for the IP L2 Interworking Circuit. Such Shah, et. al. Expires September 2005 7
use of optional TLV in the Label Mapping message to extend the draft-ietf-l2vpn-arp-mediation-01.txt
attributes of the PW-FEC has also been specified in the [PWE3-
Control].
When processing a received PW-FEC, the PE matches the PW-Id and PW- When processing a received PW FEC, the PE matches the PW Id and PW
type with the locally configured PW-Id to determine if the PW-FEC type with the locally configured PW Id to determine if the PW FEC
is of type IP L2 Interworking. If matched, it further checks the is of type IP L2 Interworking. If there is a match, it further
presence of IP address TLV. If an IP address TLV is absent, a Label checks the presence of IP address optional parameter. If absent, a
Release message is issued to reject the PW establishment. Label Release message is issued to reject the PW establishment.
0 1 2 3 The optional parameter of the Label Mapping message is defined as
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 follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| IP address TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field is defined as the length of the IP address and is Optional Parameter type length value
set to value 4. IP address TBD 04 CEĂs IP address
The IP address field is set to value null to denote that The IP address field is set to value null to denote that
advertising PE has not learned the IP address of his local CE advertising PE has not learned the IP address of his local CE
device. The non-zero value of the IP address field denotes IP device. The non-zero value of the IP address field denotes IP
address of advertising PEĂs attached CE device. address of advertising PEĂs attached CE device.
The IP address TLV is also used in the LDP notification message The CEĂs IP address is also supplied in the optional parameter
along with the PW-FEC. The IP address TLV in Notification message field of the LDPĂs Notification message along with the PW FEC. The
is used as an update mechanism to notify the changes in the IP LDP Notification message is used to signal the change in CEĂs IP
address of the local CE device as described in [SHAH-CONTROL]. address.
5.3 Out-of-band Distribution, Manual Configuration
In some cases, it may not be possible to deduce the IP addresses
from the VPN traffic nor induce remote PEs to supply the necessary
information on demand. For those cases, out-of-band methods, such
as manual configuration, could be used. The use of these types of
methods is useful only to handle corner cases.
5.4 Single sided ARP mediation
In this configuration, one PE device treats the Pseudowire as a
homogeneous circuit, while the other PE device treats it as a
heterogenous circuit. For example, if PE1 is connected to an
Ethernet Attachment Circuit and PE2 is connected to an ATM
Attachment Circuit, PE1 and PE2 would both treat the Pseudowire as
Shah, et. al. Expires April 2005 8
draft-ietf-l2vpn-arp-mediation-00.txt
of type Ethernet. From PE1's point of view, the circuit is
homogeneous, since the Attachment Circuit and the Pseudowire are
both Ethernet. Hence PE1 does no ARP mediation. From PE2's point of
view, the circuit is heterogeneous, so PE2 performs ARP mediation.
That is,
o PE2 signals to PE1 that the PW Type is Ethernet,
o PE2 learns the IP address of remote CE from Ethernet
frames received over the PW,
o PE2 learns the IP address of locally attached ATM CE,
o PE2 proxies the IP address of each CE to the other,
o PE2 decapsulates the ATM data link header and
reencapsulates with an Ethernet header before forwarding
the IP data frames from its local CE over the PW. The
information used to build the Ethernet data link header
is obtained through ARP mediation functions. Similar
header manipulation is performed when Ethernet IP frames
are forwarded to ATM Attachment Circuit,
o Drop all non IP Ethernet frames received over Ethernet
PW.
The above example show how single sided ARP mediation would work
when Pseudowire is Ethernet. However, the choice of Pseudowire type
and which side performs the ARP mediation functions is largely
dictated by the existing network topology and how this service is
rolled out. The single sided architecture is not restricted to a
specific Pseudowire type.
In summary, single sided configuration handles ARP mediation as PE 5.3 Out-of-band Distribution Configuration
would typically when managing two locally attached heterogenous
Attachment Circuits.
6.0 How CE Learns The Remote CE's IP address In some cases, it may not be possible either to deduce the IP
addresses from the VPN traffic nor induce remote PEs to supply the
necessary information on demand. For those cases, out-of-band
methods, such as manual configuration, MAY be used.
6.0 How a CE Learns the Remote CE's IP address
Once the PE has received the remote CE's IP address information Once the local PE has received the remote CE's IP address
from the remote PE, it will either initiate an address resolution information from the remote PE, it will either initiate an address
request or respond to an outstanding request from the attached CE resolution request or respond to an outstanding request from the
device. attached CE device.
6.1 CE Devices Using ARP 6.1 CE Devices Using ARP
When the PE learns the remote CE's IP address as described in When the PE learns the remote CE's IP address as described in
section 5.1 and 5.2, it may or may not know the local CE's IP section 5.1 and 5.2, it may or may not know the local CE's IP
address. If the local CE's IP address is not known, the PE must address. If the local CE's IP address is not known, the PE must
wait until it is acquired through one of the methods described in wait until it is acquired through one of the methods described in
sections 4.1, 4.3 and 4.5. If the IP address of the local CE is sections 4.1, 4.3 and 4.5. If the IP address of the local CE is
known, the PE may choose to generate an unsolicited ARP message to 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 notify the local CE about the binding of the remote CE's IP address
with the PE's own MAC address. with the PE's own MAC address.
Shah, et. al. Expires April 2005 9
draft-ietf-l2vpn-arp-mediation-00.txt
When the local CE generates an ARP request, the PE must proxy the When the local CE generates an ARP request, the PE must proxy the
ARP response using its own MAC address as the source hardware ARP response using its own MAC address as the source hardware
Shah, et. al. Expires September 2005 8
draft-ietf-l2vpn-arp-mediation-01.txt
address and remote CE's IP address as the source protocol address. address and remote CE's IP address as the source protocol address.
The PE must respond only to those ARP requests whose destination The PE must respond only to those ARP requests whose destination
protocol address matches the remote CE's IP address. protocol address matches the remote CE's IP address.
6.2 CE Devices Using Inverse ARP 6.2 CE Devices Using Inverse ARP
When the PE learns the remote CE's IP address, it should generate When the PE learns the remote CE's IP address, it should generate
an Inverse ARP request. In case, the local circuit requires an Inverse ARP request. In case, the local circuit requires
activation e.g. Frame Relay, PE should activate it first before activation e.g. Frame Relay, PE should activate it first before
sending Inverse ARP request. It should be noted, that PE might sending Inverse ARP request. It should be noted, that PE might
skipping to change at line 520 skipping to change at line 466
In an IP L2 interworking L2VPN, when an IGP on a CE connected to a In an IP L2 interworking L2VPN, when an IGP on a CE connected to a
broadcast link is cross-connected with an IGP on a CE connected to broadcast link is cross-connected with an IGP on a CE connected to
a point-to-point link, there are routing protocol related issues a point-to-point link, there are routing protocol related issues
that must be addressed. The link state routing protocols are that must be addressed. The link state routing protocols are
cognizant of the underlying link characteristics and behave cognizant of the underlying link characteristics and behave
accordingly when establishing neighbor adjacencies, representing accordingly when establishing neighbor adjacencies, representing
the network topology, and passing protocol packets. the network topology, and passing protocol packets.
7.1 OSPF 7.1 OSPF
The OSPF protocol treats broadcast link type with a special The OSPF protocol treats a broadcast link type with a special
procedure that engages in neighbor discovery to elect a designated procedure that engages in neighbor discovery to elect a designated
and a backup designated router (DR and BDR respectively) with which and a backup designated router (DR and BDR respectively) with which
it forms adjacencies. However, these procedures are neither it forms adjacencies. However, these procedures are neither
applicable nor understood by OSPF running on a point-to-point link. applicable nor understood by OSPF running on a point-to-point link.
By cross-connecting two neighbors with disparate link types, an IP By cross-connecting two neighbors with disparate link types, an IP
L2 interworking L2VPN has the potential to experience connectivity L2 interworking L2VPN may experience connectivity issues.
issues.
Shah, et. al. Expires April 2005 10
draft-ietf-l2vpn-arp-mediation-00.txt
Additionally, the link type specified in the router LSA will not Additionally, the link type specified in the router LSA will not
match for two routers that are supposedly sharing the same link match for two routers that are supposedly sharing the same link
type. Finally, each OSPF router generates network LSAs when type. Finally, each OSPF router generates network LSAs when
connected to a broadcast link such as Ethernet, receipt of which by connected to a broadcast link such as Ethernet, receipt of which by
Shah, et. al. Expires September 2005 9
draft-ietf-l2vpn-arp-mediation-01.txt
an OSPF router on the point-to-point link further adds to the an OSPF router on the point-to-point link further adds to the
confusion. confusion.
Fortunately, the OSPF protocol provides a configuration option Fortunately, the OSPF protocol provides a configuration option
(ospfIfType), whereby OSPF will treat the underlying physical (ospfIfType), whereby OSPF will treat the underlying physical
broadcast link as a point-to-point link. broadcast link as a point-to-point link.
It is strongly recommended that all OSPF protocols on CE devices It is strongly recommended that all OSPF protocols on CE devices
connected to Ethernet interfaces use this configuration option when connected to Ethernet interfaces use this configuration option when
attached to a PE that is participating in an IP L2 Interworking attached to a PE that is participating in an IP L2 Interworking
VPN. VPN.
7.2 IS-IS 7.2 RIP
The IS-IS protocol sends a LAN Hello PDU (IIH packet) with the MAC
address and the IP address of the intermediate system (i.e., CE
device) when attached to Ethernet links. The CE device expects its
neighbor to insert its own MAC and IP address in the response. If
the neighbor is connected via a point-to-point link type, the LAN
Hello PDU will be silently discarded. Similarly, Hello PDUs on the
point-to-point link do not contain any MAC address, which will
confuse a neighbor on an Ethernet link, if these two neighbors were
cross-connected via above described mechanisms.
Thus, use of the IS-IS protocol on CE devices presents problems
when interconnected by disparate data link types in an IP L2
Interworking VPN environment. There are some mechanisms defined in
draft-ietf-isis-igp-p2p-over-lan-00.txt to accommodate point-to-
point behavior over broadcast networks. The feasibility of such
techniques to solve this problem is under review.
It is important to note that the use of the IS-IS protocol in
enterprise networks (i.e., CE routers) is less common. The IS-IS
related difficulties for IP L2 Interworking VPNs, hence are
minimized.
7.3 RIP
RIP protocol broadcasts RIP advertisements every 30 seconds. If the RIP protocol broadcasts RIP advertisements every 30 seconds. If the
group/broadcast address snooping mechanism is used as described group/broadcast address snooping mechanism is used as described
above, the attached PE can learn the advertising (CE) router's IP above, the attached PE can learn the advertising (CE) router's IP
address from the IP header of the advertisement. No special address from the IP header of the advertisement. No special
configuration is required for RIP in this type of Layer 2 IP configuration is required for RIP in this type of Layer 2 IP
Interworking L2VPN. Interworking L2VPN.
Shah, et. al. Expires April 2005 11
draft-ietf-l2vpn-arp-mediation-00.txt
8.0 Security Considerations 8.0 Security Considerations
The security aspects of this solution will be discussed at a later The security aspect of this solution is addressed for two planes;
time. control plane and data plane.
8.1 Control plane security
The control plane security pertains to establishing the LDP
connection, Pseudowire establishment and CEĂs IP address
distribution. The LDP connection between two trusted PEs can be
achieved by each PE verifying the incoming connection against the
configured peerĂs address and authenticating the LDP messages using
MD5 authentication. The Pseudowire establishments between two
secure LDP peers do not pose security issue but mis-wiring could
occur due to configuration error. Some checks, such as, proper
Pseudowire type and other Pseudowire options may prevent mis-wiring
due to configuration errors.
The learning of the appropriate CEĂs IP address can be a security
issue. It is expected that the local attachment circuit to CE is
physically secured. If this is a concern, the PE must be configured
with CEĂs IP and MAC address when connected with Ethernet or CEĂs
IP and virtual circuit information (e.g. DLCI or VPI/VCI). During
each ARP/inARP frame processing, PE must verify the received
information against the configuration before accepting to protect
against hijacking the connection.
Shah, et. al. Expires September 2005 10
draft-ietf-l2vpn-arp-mediation-01.txt
8.2 Data plane security
The data traffic between CE and PE is not encrypted and it is
possible that in an insecure environment, a malicious user may tap
into the CE to PE connection and generate traffic using the spoofed
destination MAC address on the Ethernet Attachment Circuit. In
order to avoid such hijacking, local PE may verify the source MAC
address of the received frame against the MAC address of the
admitted connection. The frame is forwarded to PW only when
authenticity is verified. When spoofing is detected, PE must severe
the connection with the local CE, tear down the PW and start over.
9.0 Acknowledgements 9.0 Acknowledgements
The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce
Lasley and other folks who participated in the discussions related Lasley and other folks who participated in the discussions related
to this draft. to this draft.
10.0 References 10.0 References
10.1 Normative References 10.1 Normative References
[ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution
Protocol: Or Converting Network Protocol Addresses to 48.bit Protocol: Or Converting Network Protocol Addresses to 48.bit
Ethernet Addresses for Transmission on Ethernet Hardware". Ethernet Addresses for Transmission on Ethernet Hardware".
[INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution
Protocol". Protocol".
10.2 Informative References 10.2 Informative References
[L2VPN-REQ] W. Augustyn et al., "Service Requirements for Layer 2 [L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June 2004,
Provider Provisioned Virtual Private Networks", February 2003, work
in progress.
[L2VPN-FRM] L. Andersson et al., "L2VPN Framework", January 2003,
work in progress. work in progress.
[PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
Control Protocol (IPCP)". Control Protocol (IPCP)".
[L2VPN-Kompella] K. Kompella et al., "Layer 2 VPNs Over Tunnels", [PWE3-CONTROL] L. Martini et al., "Pseudowire Setup and Maintenance
June 2002, work in progress. using LDP", February 2005, work in progress.
[PWE3-CONTROL] L. Martini et al., "Transport of Layer 2 Frames Over [PWE3-IANA] L. Martini et al,. ˘IANA Allocations for pseudo Wire
MPLS", November 2002, work in progress. Edge to Edge Emulation (PWE3)÷, February 2005, work in progress.
[L2VPN-Signaling] E. Rosen et al., "LDP-based Signaling for Shah, et. al. Expires September 2005 11
L2VPNs", September 2002, work in progress. draft-ietf-l2vpn-arp-mediation-01.txt
[PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution".
[SHAH-CONTROL] H. Shah et al., ˘Dynamic Parameters Signaling for
MPLS-based Pseudowires÷, June 2003, work in progress
Shah, et. al. Expires April 2005 12
draft-ietf-l2vpn-arp-mediation-00.txt
11.0 Authors' Addresses 11.0 Authors' Addresses
Himanshu Shah Himanshu Shah
35 Nagog Park, 35 Nagog Park,
Acton, MA 01720 Acton, MA 01720
Email: hshah@ciena.com Email: hshah@ciena.com
Eric Rosen Eric Rosen
Cisco Systems Cisco Systems
1414 Massachusetts Avenue, 1414 Massachusetts Avenue,
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Waldemar Augustyn Waldemar Augustyn
Email: waldemar@nxp.com Email: waldemar@nxp.com
Giles Heron Giles Heron
PacketExchange Ltd. Email: giles@tellabs.com
The Truman Brewery
91 Brick Lane
LONDON E1 6QL
United Kingdom
Email: giles@packetexchange.net
Sunil Khandekar and Vach Kompella Sunil Khandekar and Vach Kompella
Alcatel
274 Ferguson Dr.
Mountain View, CA 94043
Email: sunil@timetra.com Email: sunil@timetra.com
Email: vkompella@timetra.com Email: vkompella@timetra.com
Toby Smith Toby Smith
Laurel Networks Laurel Networks
Omega Corporate Center Omega Corporate Center
1300 Omega drive 1300 Omega drive
Pittsburgh, PA 15205 Pittsburgh, PA 15205
Email: jsmith@laurelnetworks.com Email: jsmith@laurelnetworks.com
Arun Vishwanathan Arun Vishwanathan
Force10 Networks Force10 Networks
1440 McCarthy Blvd., 1440 McCarthy Blvd.,
Milpitas, CA 95035 Milpitas, CA 95035
Email: arun@force10networks.com Email: arun@force10networks.com
Ashwin Moranganti
Axiowave Network
Marlboro, MA 01720
Andrew G. Malis Andrew G. Malis
Tellabs Tellabs
2730 Orchard Parkway 2730 Orchard Parkway
San Jose, CA 95134 San Jose, CA 95134
Email: Andy.Malis@vivacenetworks.com Email: Andy.Malis@vivacenetworks.com
Shah, et. al. Expires April 2005 13
draft-ietf-l2vpn-arp-mediation-00.txt
Steven Wright Steven Wright
Bell South Corp Bell South Corp
Email: steven.wright@bellsouth.com Email: steven.wright@bellsouth.com
Vasile Radoaca Vasile Radoaca
Nortel Networks Email: vasile@westridgenetworks.com
Email: vasile@nortelnetworks.com
Shah, et. al. Expires September 2005 12
draft-ietf-l2vpn-arp-mediation-01.txt
IPR Notice IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETFĂs procedures with respect to rights in standards-track and IETFĂs procedures with respect to rights in standards-track and
skipping to change at line 737 skipping to change at line 670
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Shah, et. al. Expires April 2005 14 Shah, et. al. Expires September 2005 13
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/