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

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/