L2VPN Working Group Himanshu Shah Ciena Corp
Internet Draft Eric Rosen Cisco System
Giles Heron Tellabs
Vach Kompella Alcatel
June 2006
Expires: December 2006
ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-06.txt
Status of this Memo
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 2006.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Shah et al Expires December 2006 [Page 1]
Draft-ietf-l2vpn-arp-mediation-06.txt
Abstract
The VPWS service [L2VPN-FRM] provides point-to-point connections
between pairs of Customer Edge (CE) devices. It does so by
binding two Attachment Circuits (each connecting a CE device
with a Provider Edge, PE, device) to a pseudo-wire (connecting
the two PEs). In general, the Attachment Circuits must be of
the same technology (e.g., both Ethernet, both ATM), and the
pseudo-wire must carry the frames of that technology. However,
if it is known that the frames' payload consists solely of IP
datagrams, it is possible to provide a point-to-point connection
in which the pseudo-wire connects Attachment Circuits of
different technologies. This requires the PEs to perform a
function known as "ARP Mediation". ARP Mediation refers to the
process of resolving Layer 2 addresses when different resolution
protocols are used on either Attachment Circuit. The methods
described in this document are applicable even when the CEs run
a routing protocol between them, as long as the routing protocol
runs over IP. In particular, the applicability of ARP mediation
to ISIS is not addressed as IS-IS PDUs are not sent over IP.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC 2119].
Table of Contents
1. Contributing Authors........................................3
2. Introduction................................................3
3. ARP Mediation (AM) function.................................5
4. IP Layer 2 Interworking Circuit.............................5
5. Discovery of IP Addresses of Locally Attached CE Device.....5
5.1. Monitoring Local Traffic...............................6
5.2. CE Devices Using ARP...................................6
5.3. CE Devices Using Inverse ARP...........................8
5.4. CE Devices Using PPP...................................8
5.5. Router Discovery method................................9
6. CE IP Address Signaling between PEs.........................9
6.1. When to Signal an IP address of a CE...................9
Shah et al Expires December 2006 [Page 2]
Draft-ietf-l2vpn-arp-mediation-06.txt
6.2. LDP Based Distribution................................10
6.3. Out-of-band Distribution Configuration................12
7. IANA Considerations........................................12
7.1. LDP Status messages...................................12
8. How a CE Learns the IP address of remote CE................13
8.1. CE Devices Using ARP..................................13
8.2. CE Devices Using Inverse ARP..........................13
8.3. CE Devices Using PPP..................................14
9. Use of IGPs with IP L2 Interworking L2VPNs.................14
9.1. OSPF..................................................14
9.2. RIP...................................................15
10. IPV6 Considerations.......................................15
11. Multi-Segment PW consideration............................15
12. Security Considerations...................................16
12.1. Control plane security...............................16
12.2. Data plane security..................................16
13. Acknowledgements..........................................17
14. References................................................17
14.1. Normative References.................................17
14.2. Informative References...............................17
15. Authors' Addresses........................................18
Intellectual Property Statement...............................19
Disclaimer of Validity........................................19
1. Contributing Authors
This document is the combined effort of the following
individuals and many others who have carefully reviewed the
document and provided the technical clarifications.
W. Augustyn consultant
T. Smith Laurel Networks
A. Moranganti Big Band Networks
S. Khandekar Alcatel
A. Malis Tellabs
S. Wright Bell South
V. Radoaca Westridge Networks
A. Vishwanathan Force10 Networks
2. Introduction
Shah et al Expires December 2006 [Page 3]
Draft-ietf-l2vpn-arp-mediation-06.txt
Layer 2 Virtual Private Networks (L2VPN) are constructed over a
Service Provider IP backbone but are presented to the Customer
Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can
carry any Layer 3 protocol, but in many cases, the Layer 3
protocol is IP. Thus it makes sense to consider procedures that
are optimized for IP.
In a typical implementation, illustrated in the diagram below,
the CE devices are connected to the Provider Edge (PE) devices
via Attachment Circuits (AC). The ACs are Layer 2 links. In a
pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via
AC2, both ACs would have to be of the same type (i.e., both
Ethernet, both FR, etc.). However, if it is known that only IP
traffic will be carried, the ACs can be of different
technologies, provided that the PEs provide the appropriate
procedures to allow the proper transfer of IP packets.
+-----+
+--------------------| CE3 |
| +-----+
+-----+
........| PE3 |.........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................
A CE, which is connected via a given type of AC, may use an IP
Address Resolution procedure that is specific to that type of
AC. For example, an Ethernet-attached CE would use ARP [ARP] and
a FR-attached CE might use Inverse ARP [INVARP]. If we are to
allow the two CEs to have a Layer 2 connection between them,
even though each AC uses a different Layer 2 technology, the PEs
must intercept and "mediate" the Layer 2 specific address
resolution procedures.
In this draft, we specify the procedures for VPWS services,
which the PEs must implement in order to mediate the IP address
resolution mechanism. We call these procedures "ARP Mediation".
Consider a Virtual Private Wire Service (VPWS) constructed
between CE1 and CE2 in the diagram above. If AC1 and AC2 are of
different technologies, e.g. AC1 is Ethernet and AC2 is Frame
Relay (FR), then ARP requests coming from CE1 cannot be passed
transparently to CE2. PE1 must interpret the meaning of the ARP
Shah et al Expires December 2006 [Page 4]
Draft-ietf-l2vpn-arp-mediation-06.txt
requests and mediate the necessary information with PE2 before
responding.
3. ARP Mediation (AM) function
The ARP Mediation (AM) function is an element of a PE node that
deals with the IP address resolution for CE devices connected
via an VPWS L2VPN. By placing this function in the PE node, ARP
Mediation is transparent to the CE devices.
For a given point-to-point connection between a pair of CEs, a
PE must perform following logical steps as part of the ARP
Mediation procedure:
1. Discover the IP address of the locally attached CE device
2. Terminate, do not distribute ARP and Inverse ARP requests
from CE device at local PE.
3. Distribute those IP Addresses to the remote PE
4. Notify the locally attached CE, the IP address of the
remote CE.
This information is gathered using the mechanisms described in
the following sections.
4. IP Layer 2 Interworking Circuit
The IP Layer 2 interworking Circuit refers to interconnection of
the Attachment Circuit with the IP Layer 2 Transport pseudo-wire
that carries IP datagrams as the payload. The ingress PE removes
the data link header of its local Attachment Circuit and
transmits the payload (an IP frame) over the pseudo-wire with or
without the optional control word. In some cases, multiple data
link headers may exist, such as bridged PDU on ATM AC. In this
case, ATM header as well as the Ethernet header is removed to
expose the IP frame. The egress PE encapsulates the IP packet
with the data link header used on its local Attachment Circuit.
The encapsulation for the IP Layer 2 Transport pseudo-wire is
described in [PWE3-Control].
5. Discovery of IP Addresses of Locally Attached CE Device
Shah et al Expires December 2006 [Page 5]
Draft-ietf-l2vpn-arp-mediation-06.txt
An IP Layer 2 Interworking Circuit enters monitoring state
immediately after the configuration. During this state it
performs two functions.
o Discovery of locally attached CE IP device
o Establishment of the PW
The establishment of the PW occurs independently from local CE
IP address discovery. During the period when the PW has been
established but local CE IP device has not been detected, only
broadcast/multicast IP frames are propagated between the
Attachment Circuit and pseudo-wire; unicast IP datagrams are
dropped. On Ethernet AC, MAC Destination Address is used to
classify unicast/multicast packets. However, on non-Ethernet
ACs, IP destination address is used to classify
unicast/multicast packets.
The unicast IP frames are propagated between AC and pseudo-wire
only when CE IP devices on both Attachment Circuits have been
discovered, notified and proxy functions have completed.
5.1. Monitoring Local Traffic
The PE devices may learn the IP addresses of the locally
attached CEs from any IP traffic, such as link local multicast
packets (e.g., destined to 224.0.0.x), and are not restricted to
the operations below.
5.2. CE Devices Using ARP
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 the IP address of local CE for the stated
locally attached circuit.
This document mandates that only one CE per attachment circuit
MUST be connected to the PE. However, customer facing access
topology may exist whereby more than one CEs appear to be
connected to the PE on a single attachment circuit. For example
this could be the case when CEs are connected to a shared LAN
that connects to the PE. In such case, the PE MUST select one
local CE. The selection could be based on manual configuration
or PE may optionally use following selection criteria. In either
case, manual configuration of IP address of the local CE (and
its MAC address) MUST be supported.
Shah et al Expires December 2006 [Page 6]
Draft-ietf-l2vpn-arp-mediation-06.txt
o Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending
the request for IP address of the remote CE.
o Augment cross checking with the local IP address learned
through listening of link local multicast packets (as per
section 5.1 above)
o Augment cross checking with the local IP address learned
through the Router Discovery protocol (as described below
in section 5.5).
o There is still a possibility that the local PE may not
receive an IP address advertisement from the remote PE and
there may exist multiple local IP routers that attempt to
'connect' to remote CEs. In this situation, the local PE
may use some other criteria to select one IP device from
many (such as "the first ARP received"), or an operator
may configure the IP address of local CE. Note that the
operator does not have to configure the IP address of the
remote CE (as that would be learned through pseudo-wire
signaling).
Once the local CE has been discovered for the given Attachment
Circuit, the local PE responds to subsequent ARP requests from
that device with its own MAC address when the destination IP
address in the ARP request is found to match with IP address of
the remote CE.
The local PE signals IP address of the CE to the remote PE and
may initiate an unsolicited ARP response to notify local CE MAC
address to IP address binding of the remote CE. Once the ARP
mediation function is completed, unicast IP frames are
propagated between the AC and the established PW.
The PE may periodically generate ARP request messages to the IP
address of the CE as a means of verifying the continued
existence of the 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 used as a cause for withdrawal of the IP
address advertisement to the remote PE. The local PE would then
enter into the address resolution phase to rediscover the IP
address of the attached CE. Note that this "heartbeat" scheme is
needed only for broadcast links (such as Ethernet AC), as the
loss of a CE may otherwise be undetectable.
Shah et al Expires December 2006 [Page 7]
Draft-ietf-l2vpn-arp-mediation-06.txt
5.3. CE Devices Using Inverse ARP
If a CE device uses Inverse ARP to determine the IP address of
its neighbor, the attached PE processes the Inverse ARP request
for stated circuit and responds with an Inverse ARP reply
containing the IP address of the remote CE, if the address is
known. If the PE does not yet have the IP address of the remote
CE, it does not respond, but notes the IP address of the local
CE and the circuit information. Subsequently, when the IP
address of the remote CE becomes 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.
This is a typical operation for Frame Relay and ATM attachment
circuits. When the CE does not use Inverse ARP, PE could still
discover the IP address of local CE as described in section 5.1
and 5.5
5.4. CE Devices Using PPP
The IP Control Protocol [PPP-IPCP] describes a procedure to
establish and configure IP on a point-to-point connection,
including the negotiation of IP addresses. When using IP
(Routed) mode L2VPN interworking, PPP negotiation is not
performed end-to-end between CE devices. In this case, PPP
negotiation takes place between the CE device and its local PE
device (on the PPP attachment circuit). The PE device performs
proxy PPP negotiation, and informs the local CE device of the IP
address of the remote CE device during IPCP negotiation using
the IP-Address option [0x03].
When a PPP link becomes operational after the LCP negotiations,
the local PE MAY perform following actions
o The PE learns the IP address of the local CE from the
Configure- Request received with the IP-Address option
(0x03). The PE verifies that the IP address present in the
IP-Address option is non-zero. If the IP address is zero,
PE responds with Configure- Reject (as this is a request
from CE to assign him an IP address). Also, the Configure-
Reject copies the IP-Address option with null value to
instruct the CE to not include that option in new
Configure-Request. If the IP address is non-zero, PE
responds with Configure-Ack.
Shah et al Expires December 2006 [Page 8]
Draft-ietf-l2vpn-arp-mediation-06.txt
o If the PE receives Configure-Request without the IP-
Address option, PE responds with Configure-Ack. In this
case, PE would not learn the IP address of the local CE
using IPCP and hence would rely on other means as
described above (such as link-local broadcast from OSPF
hello). Note that in order to employ other learning
mechanisms, IPCP connection must be open.
o If the PE does not know the IP address of the remote CE,
it generates a Configure-Request without the IP-Address
option.
o If the PE knows the IP address of the remote CE, it sends
an IPCP Configure-Request with the IP-Address option
containing the IP address of the remote CE.
The IPCP IP-Address option MAY be negotiated between the PE and
the local CE device. Configuration of other IPCP option MAY be
rejected. Other NCPs, with the exception of the Compression
Control Protocol (CCP) and Encryption Control Protocol (ECP),
MUST be rejected. The PE device MAY reject configuration of the
CCP and ECP.
5.5. Router Discovery method
In order to learn the IP address of the CE device for a given
Attachment Circuit, the PE device may execute Router Discovery
Protocol [RFC 1256] whereby a Router Discovery Request (ICMP -
router solicitation) message is sent using a source IP address
of zero. The IP address of the CE device is extracted from the
Router Discovery Response (ICMP - router advertisement) message
from the CE. It is possible that the response contains more than
one router addresses with the same preference level; in which
case, some heuristics (such as first on the list) is necessary.
The use of the Router Discovery method by the PE is optional.
6. CE IP Address Signaling between PEs
6.1. When to Signal an IP address of a CE
A PE device advertises the IP address of the attached CE only
when the encapsulation type of the pseudo-wire is IP Layer2
Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is
quite possible that the IP address of a CE device is not
Shah et al Expires December 2006 [Page 9]
Draft-ietf-l2vpn-arp-mediation-06.txt
available at the time the PW labels are signaled. For example,
in Frame Relay the CE device sends an inverse ARP request only
when the DLCI is active; if the PE signals the DLCI to be active
only when it has received the IP address along with the PW FEC
from the remote PE, a chicken and egg situation arises. In order
to avoid such problems, the PE must be prepared to advertise the
PW FEC before the IP address of the CE is known and hence uses
IP address value zero. When the IP address of the CE device does
become available, the PE re-advertises the PW FEC along with the
IP address of the CE.
Similarly, if the PE detects that an IP address of a CE is no
longer valid (by methods described above), the PE must re-
advertise the PW FEC with null IP address to denote the
withdrawal of IP address of the CE. The receiving PE then waits
for notification of the remote IP address. During this period,
propagation of unicast IP traffic is suspended, but multicast IP
traffic can continue to flow between the AC and the pseudo-wire.
If two CE devices are locally attached to the PE where one CE is
connected to an Ethernet port and the other to a Frame Relay
port, for example, the IP addresses are learned in the same
manner described above. However, since the CE devices are local,
the distribution of IP addresses for these CE devices is a local
step.
6.2. LDP Based Distribution
The [PWE3-Control] uses Label Distribution Protocol (LDP)
transport to exchange PW FEC in the Label Mapping message in the
Downstream Unsolicited (DU) mode. The PW FEC comes in two
flavors; PWid and Generalized ID FEC elements and has some
common fields between them. The discussions below refer to these
common fields for IP L2 Interworking encapsulation.
In addition to PW-FEC, this document defines an IP address TLV
that must be included in the optional parameter field of the
Label Mapping message when advertising the PW FEC for the IP
Layer2 Transport. The use of optional parameters in the Label
Mapping message to extend the attributes of the PW FEC is
specified in the [PWE3-Control].
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 is of type IP Layer2 Transport. If there is a match, it
further checks the presence of IP address TLV in the optional
parameter field. If absent, a Label Release message is issued
Shah et al Expires December 2006 [Page 10]
Draft-ietf-l2vpn-arp-mediation-06.txt
with a Status Code meaning "IP Address of the CE is absent"
[note: Status Code 0x0000002C is pending IANA allocation] to
reject the PW establishment.
We use the Address List TLV as defined in RFC 3036 to signal the
IP address of the local CE. This IP address TLV must be included
in the optional parameter field of the Label Mapping message.
Encoding of the IP Address TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | IP Address of CE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Address of CE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
When Address Family is IPV4, Length is equal to 6 bytes; 2
bytes for address family and 4 bytes of IP address.
Address Family
Two octet quantity containing a value from the ADDRESS
FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 1700]
that encodes the address contained in the Address field.
IP Address of CE
IP address of the CE attached to the advertising PE. The
encoding of the individual address depends on the Address
Family.
The following address encodings are defined by this version of
the protocol:
Address Family Address Encoding
IPv4 (1) 4 octet full IPv4 address
IPv6 (2) 16 octet full IPv6 address
The IP address field is set to value null to denote that
advertising PE has not learned the IP address of his local CE
device. The non-zero value of the IP address field denotes IP
address of advertising PE's attached CE device.
Shah et al Expires December 2006 [Page 11]
Draft-ietf-l2vpn-arp-mediation-06.txt
The IP address of the CE is also supplied in the optional
parameter field of the LDP's Notification message along with the
PW FEC. The LDP Notification message is used to signal the
change in CE's IP address.
The encoding of the LDP Notification message is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is set to 0x0000002B "IP address of
CE", to indicate that IP Address update follows. Since this
notification does not refer to any particular message the
Message Id, and Message Type fields are set to 0. [note: Status
Code 0x0000002B is pending IANA allocation].
The PW FEC TLV SHOULD not include the interface parameters as
they are ignored in the context of this message.
6.3. Out-of-band Distribution Configuration
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. The
support for manual configuration of IP address of the local CE
is mandatory.
7. IANA Considerations
7.1. LDP Status messages
Shah et al Expires December 2006 [Page 12]
Draft-ietf-l2vpn-arp-mediation-06.txt
This document uses new LDP status codes, IANA already maintains
a registry of name "STATUS CODE NAME SPACE" defined by RFC3036.
The following values are suggested for assignment:
0x0000002B "IP Address of CE"
0x0000002C "IP Address of CE is absent"
8. How a CE Learns the IP address of remote CE
Once the local PE has received IP address information of the
remote CE from the remote PE, it will either initiate an address
resolution request or respond to an outstanding request from the
attached CE device.
8.1. CE Devices Using ARP
When the PE learns IP address of the remote CE as described in
section 6.1 and 6.2, it may or may not already know IP address
of the local CE. If the IP address is not known, the PE must
wait until it is acquired through one of the methods described
in sections 5.1, 5.3 and 5.5. If IP address of the local CE is
known, the PE may choose to generate an unsolicited ARP message
to notify the local CE about the binding of the IP address of
the remote CE with the PE's own MAC address.
When the local CE generates an ARP request, the PE must proxy
the ARP response [PROXY-ARP] using its own MAC address as the
source hardware address and IP address of remote CE as the
source protocol address. The PE must respond only to those ARP
requests whose destination protocol address matches the IP
address of the remote CE. An exception to this rule is when the
strict topology of one IP end station per Attachment Circuit is
assumed. In which case, PE can promiscuously respond to the ARP
request of the CE with his own MAC address.
8.2. CE Devices Using Inverse ARP
When the PE learns the IP address of the remote CE, it should
generate an Inverse ARP request. In case, the local circuit
requires activation e.g. Frame Relay, PE should activate it
first before sending Inverse ARP request. It should be noted,
that PE might never receive the response to its own request, nor
see any CE's Inverse ARP request in cases where CE is pre-
configured with remote CE IP address or the use of Inverse ARP
is not enabled. In either case CE has used other means to learn
the IP address of his neighbor.
Shah et al Expires December 2006 [Page 13]
Draft-ietf-l2vpn-arp-mediation-06.txt
8.3. CE Devices Using PPP
When the PE learns the IP address of the remote CE, it should
initiate the Configure-Request and set the IP-Address option to
the IP address of the remote CE to notify local CE the IP
address of the remote CE.
9. Use of IGPs with IP L2 Interworking L2VPNs
In an IP L2 interworking L2VPN, when an IGP on a CE connected to
a broadcast link is cross-connected with an IGP on a CE
connected to a point-to-point link, there are routing protocol
related issues that must be addressed. The link state routing
protocols are cognizant of the underlying link characteristics
and behave accordingly when establishing neighbor adjacencies,
representing the network topology, and passing protocol packets.
9.1. OSPF
The OSPF protocol treats a broadcast link type with a special
procedure that engages in neighbor discovery to elect a
designated and a backup designated router (DR and BDR
respectively) with which it forms adjacencies. However, these
procedures are neither applicable nor understood by OSPF running
on a point-to-point link. By cross-connecting two neighbors with
disparate link types, an IP L2 interworking L2VPN may experience
connectivity issues.
Additionally, the link type specified in the router LSA will not
match for two routers that are supposedly sharing the same link
type. Finally, each OSPF router generates network LSAs when
connected to a broadcast link such as Ethernet, receipt of which
by an OSPF router on the point-to-point link further adds to the
confusion.
Fortunately, the OSPF protocol provides a configuration option
(ospfIfType), whereby OSPF will treat the underlying physical
broadcast link as a point-to-point link.
It is strongly recommended that all OSPF protocols on CE devices
connected to Ethernet interfaces use this configuration option
when attached to a PE that is participating in an IP L2
Interworking VPN.
Shah et al Expires December 2006 [Page 14]
Draft-ietf-l2vpn-arp-mediation-06.txt
9.2. RIP
RIP protocol broadcasts RIP advertisements every 30 seconds. If
the group/broadcast address snooping mechanism is used as
described above, the attached PE can learn the advertising (CE)
router's IP address from the IP header of the advertisement. No
special configuration is required for RIP in this type of Layer
2 IP Interworking L2VPN.
10. IPV6 Considerations
The support for IPV6 is not addressed in this draft and is for
future study.
11. Multi-Segment PW consideration
In a back-to-back configuration, when two PEs are connected with
an Ethernet, ARP proxy function has limited application, as
there is no local CE. Consider a Multi-Segment Pseudo-wire
consisting of two pseudo-wire segments; segment 1 (PE1<->PE2) in
network A and segment 2 (PE3<->PE4) in network B. In this
configuration CE1 is connected to PE1 and CE2 is connected to
PE4. The PE2 on network A is directly connected to PE3 in
network B with an Ethernet. Since there is no CE present between
PE2 and PE3, there needs a mechanism for PE2 and PE3 to discover
each others MAC address to enable connectivity between CE1 and
CE2 across the two networks. There are two options.
o Configure IP address of CE2 as IP address of local CE at
PE2 and IP address of CE1 as IP address of local CE at PE3.
Additionally, PE2 and PE3 are required to generate ARP
requests using their own MAC addresses as the source
address. These PEs are in effect proxying for CEs present
in the each others network. This is not a desirable
option as it requires configuration of IP address of a CE
that is present in others (possibly other service
provider) network.
o The second option is to follow the procedures recommended
in [MS-PW] architecture, which provides the intervening or
switching PEs to remain oblivious to native PW processing.
We recommend this option. Note this may mean creating a
third PW segment between PE2 and PE3 for the example shown
above.
Shah et al Expires December 2006 [Page 15]
Draft-ietf-l2vpn-arp-mediation-06.txt
12. Security Considerations
The security aspect of this solution is addressed for two
planes; control plane and data plane.
12.1. Control plane security
The control plane security pertains to establishing the LDP
connection, pseudo-wire 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 address of the peer and authenticating the LDP
messages using MD5 authentication. The pseudo-wire
establishments between two secure LDP peers do not pose security
issue but mis-wiring could occur due to configuration error.
Some checks, such as, proper pseudo-wire type and other pseudo-
wire options may prevent mis-wiring due to configuration errors.
The learning of IP address of the appropriate CE 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 IP and MAC address of the CE when connected
with Ethernet or IP and virtual circuit information (e.g. DLCI
or VPI/VCI) of the CE. During each ARP/inARP frame processing,
PE must verify the received information against the
configuration before accepting to protect against hijacking the
connection.
12.2. Data plane security
The data traffic between CE and PE is not encrypted and it is
possible that in an insecure environment, a malicious user may
tap into the CE to PE connection and generate traffic using the
spoofed destination MAC address on the Ethernet Attachment
Circuit. In order to avoid such hijacking, local PE may verify
the source MAC address of the received frame against the MAC
address of the admitted connection. The frame is forwarded to PW
only when authenticity is verified. When spoofing is detected,
PE must sever the connection with the local CE, tear down the PW
and start over.
Shah et al Expires December 2006 [Page 16]
Draft-ietf-l2vpn-arp-mediation-06.txt
13. Acknowledgements
The authors would like to thank Yetik Serbest, Prabhu Kavi,
Bruce Lasley, Mark Lewis, Carlos Pignataro and other folks who
participated in the discussions related to this draft.
14. References
14.1. Normative References
[ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address
Resolution protocol: Or Converting Network Protocol
Addresses to 48.bit Ethernet Addresses for Transmission
on Ethernet Hardware".
[INVARP] RFC 2390, T. Bradley et al., "Inverse Address
Resolution Protocol".
[PWE3-Control] L. Martini et al., "Pseudowire Setup and
Maintenance using LDP", RFC 4447.
[PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo
Wire Edge to Edge Emulation (PWE3)", RFC 4446.
[RFC 1700] Reynolds and Postel, "Assigned Numbers".
[RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels"
14.2. Informative References
[L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June
2004, work in progress.
[PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
Control Protocol (IPCP)".
[PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address
Resolution".
[RFC 1256] S.Deering, "ICMP Router Discovery Messages".
Shah et al Expires December 2006 [Page 17]
Draft-ietf-l2vpn-arp-mediation-06.txt
[MS-PW] M.Bocci et al,. "An Architecture for Multi-Segment
Pseudo Wire Emulation Edge-to-Edge", May 2006, work
in progress
15. Authors' Addresses
Himanshu Shah
35 Nagog Park,
Acton, MA 01720
Email: hshah@ciena.com
Eric Rosen
Cisco Systems
1414 Massachusetts Avenue,
Boxborough, MA 01719
Email: erosen@cisco.com
Waldemar Augustyn
Email: waldemar@nxp.com
Giles Heron
Email: giles.heron@tellabs.com
Sunil Khandekar and Vach Kompella
Email: sunil@timetra.com
Email: vkompella@timetra.com
Toby Smith
Laurel Networks
Omega Corporate Center
1300 Omega drive
Pittsburgh, PA 15205
Email: jsmith@laurelnetworks.com
Arun Vishwanathan
Force10 Networks
1440 McCarthy Blvd.,
Milpitas, CA 95035
Email: arun@force10networks.com
Andrew G. Malis
Tellabs
2730 Orchard Parkway
San Jose, CA 95134
Shah et al Expires December 2006 [Page 18]
Draft-ietf-l2vpn-arp-mediation-06.txt
Email: Andy.Malis@tellabs.com
Steven Wright
Bell South Corp
Email: steven.wright@bellsouth.com
Vasile Radoaca
Email: vasile@westridgenetworks.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Shah et al Expires December 2006 [Page 19]
Draft-ietf-l2vpn-arp-mediation-06.txt
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Shah et al Expires December 2006 [Page 20]