draft-ietf-l2vpn-arp-mediation-04.txt   draft-ietf-l2vpn-arp-mediation-05.txt 
L2VPN Working Group H. Shah Ciena Corp L2VPN Working Group Himanshu Shah Ciena Corp
Internet Draft E. Rosen Cisco Systems Internet Draft Eric Rosen Cisco System
G. Heron Tellabs Giles Heron Tellabs
October 2005 V. Kompella Alcatel Vach Kompella Alcatel
ARP Mediation for IP Interworking of Layer 2 VPN Expires: December 2006
draft-ietf-l2vpn-arp-mediation-04.txt
Status of this memo ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-05.txt
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 months and may be updated, replaced, or obsoleted by other documents
documents at any time. It is inappropriate to use Internet-Drafts at any time. It is inappropriate to use Internet-Drafts as
as reference material or to cite them other than as "work in reference material or to cite them other than as "work in progress."
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.
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.
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 Framework] provides point-to-point Conventions used in this document
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
Shah, et. al. Expires April 2006 1
draft-ietf-l2vpn-arp-mediation-04.txt
Attachment Circuit. The methods described in this document are The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
applicable even when the CEs run a routing protocol between them, "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
as long as the routing protocol runs over IP. In particular, the document are to be interpreted as described in [RFC 2119].
applicability of ARP mediation to ISIS is not addressed as IS-IS
PDUs are not sent over IP.
Table of Contents Table of Contents
1.0 Contributing Authors.........................................2 IPR Disclosure Acknowledgement.........Error! Bookmark not defined.
2.0 Introduction.................................................3 1. Contributing Authors...........................................3
3.0 ARP Mediation (AM) function..................................4 2. Introduction...................................................4
4.0 IP Layer 2 Interworking Circuit..............................4 3. ARP Mediation (AM) function....................................5
5.0 Discovery of IP Addresses of Locally Attached CE Device......4 4. IP Layer 2 Interworking Circuit................................5
5.1 Monitoring Local Traffic.....................................5 5. Discovery of IP Addresses of Locally Attached CE Device........6
5.2 CE Devices Using ARP.........................................5 5.1. Monitoring Local Traffic..................................6
5.3 CE Devices Using Inverse ARP.................................6 5.2. CE Devices Using ARP......................................6
5.4 CE Devices Using PPP.........................................7 5.3. CE Devices Using Inverse ARP..............................8
5.5 Router Discovery method......................................7 5.4. CE Devices Using PPP......................................8
6.0 CE IP Address Signaling between PEs..........................8 5.5. Router Discovery method...................................9
6.1 When to Signal an IP address of a CE.........................8 6. CE IP Address Signaling between PEs...........................10
6.2 LDP Based Distribution.......................................8 6.1. When to Signal an IP address of a CE.....................10
6.3 Out-of-band Distribution Configuration......................10 6.2. LDP Based Distribution...................................10
7.0 IANA considerations.........................................10 6.3. Out-of-band Distribution Configuration...................12
7.1 LDP Status messages.........................................10 7. IANA Considerations...........................................13
8.0 How a CE Learns the Remote CE's IP address..................11 7.1. LDP Status messages......................................13
8.1 CE Devices Using ARP........................................11 8. How a CE Learns the Remote CE's IP address....................13
8.2 CE Devices Using Inverse ARP................................11 8.1. CE Devices Using ARP.....................................13
8.3 CE Devices Using PPP........................................11 8.2. CE Devices Using Inverse ARP.............................14
9.0 Use of IGPs with IP L2 Interworking L2VPNs..................12 8.3. CE Devices Using PPP.....................................14
9.1 OSPF........................................................12 9. Use of IGPs with IP L2 Interworking L2VPNs....................14
9.2 RIP.........................................................12 9.1. OSPF.....................................................14
10.0 IPV6 Considerations........................................13 9.2. RIP......................................................15
11.0 Security Considerations....................................13 10. IPV6 Considerations..........................................15
11.1 Control plane security.....................................13 11. Multi-Segment PW consideration...............................15
11.2 Data plane security........................................13 12. Security Considerations......................................16
12.0 Acknowledgements...........................................13 12.1. Control plane security..................................16
13.0 References.................................................14 12.2. Data plane security.....................................17
13.1 Normative References.......................................14 13. Acknowledgements.............................................17
13.2 Informative References.....................................14 14. References...................................................17
14.0 Authors' Addresses.........................................14 14.1. Normative References....................................17
14.2. Informative References..................................18
15. Authors' Addresses...........................................18
Intellectual Property Statement..................................19
Disclaimer of Validity...........................................20
Copyright Statement....................Error! Bookmark not defined.
1.0 Contributing Authors 1. Contributing Authors
This document is the combined effort of the following individuals This document is the combined effort of the following individuals
and many others who have carefully reviewed the document and and many others who have carefully reviewed the document and
provided the technical clarifications. provided the technical clarifications.
W. Augustyn consultant W. Augustyn consultant
Shah, et. al. Expires April 2006 2
draft-ietf-l2vpn-arp-mediation-04.txt
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.0 Introduction
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 Edge
(CE) devices as Layer 2 networks. In theory, L2VPNs can carry any (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. Layer 3 protocol, but in many cases, the Layer 3 protocol is IP.
Thus it makes sense to consider procedures that are optimized for Thus it makes sense to consider procedures that are optimized for
IP. IP.
In a typical implementation, illustrated in the diagram below, the In a typical implementation, illustrated in the diagram below, the
CE devices are connected to the Provider Edge (PE) devices via CE devices are connected to the Provider Edge (PE) devices via
Attachment Circuits (AC). The ACs are Layer 2 links. In a pure Attachment Circuits (AC). The ACs are Layer 2 links. In a pure
L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both
ACs would have to be of the same type (i.e., both Ethernet, both ACs would have to be of the same type (i.e., both Ethernet, both FR,
FR, etc.). However, if it is known that only IP traffic will be etc.). However, if it is known that only IP traffic will be carried,
carried, the ACs can be of different technologies, provided that the ACs can be of different technologies, provided that the PEs
the PEs provide the appropriate procedures to allow the proper provide the appropriate procedures to allow the proper transfer of
transfer of IP packets. 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 AC.
For example, an Ethernet-attached CE would use ARP, a FR-attached For example, an Ethernet-attached CE would use ARP [ARP] and a FR-
CE might use Inverse ARP. If we are to allow the two CEs to have a attached CE might use Inverse ARP [INVARP]. If we are to allow the
Layer 2 connection between them, even though each AC uses a two CEs to have a Layer 2 connection between them, even though each
different Layer 2 technology, the PEs must intercept and "mediate" AC uses a different Layer 2 technology, the PEs must intercept and
the Layer 2 specific address resolution procedures. "mediate" the Layer 2 specific address resolution procedures.
Shah, et. al. Expires April 2006 3
draft-ietf-l2vpn-arp-mediation-04.txt
In this draft, we specify the procedures, which the PEs must In this draft, we specify the procedures for VPWS services, which
implement in order to mediate the IP address resolution mechanism. the PEs must implement in order to mediate the IP address resolution
We call these procedures "ARP Mediation". mechanism. We call these procedures "ARP Mediation".
Consider a Virtual Private Wire Service (VPWS) constructed between Consider a Virtual Private Wire Service (VPWS) constructed between
CE1 and CE2 in the diagram above. If AC1 and AC2 are of different CE1 and CE2 in the diagram above. If AC1 and AC2 are of different
technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), then
then ARP requests coming from CE1 cannot be passed transparently to ARP requests coming from CE1 cannot be passed transparently to CE2.
CE2. PE1 must interpret the meaning of the ARP requests and PE1 must interpret the meaning of the ARP requests and mediate the
mediate the necessary information with PE2 before responding. necessary information with PE2 before responding.
3.0 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 deals with the IP address resolution for CE devices connected via an
an L2VPN. By placing this function in the PE node, ARP Mediation is VPWS L2VPN. By placing this function in the PE node, ARP Mediation
transparent to the CE devices. 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 PE
must perform three logical steps as part of the ARP Mediation must perform three logical steps as part of the ARP Mediation
procedure: procedure:
1. Discover the IP addresses of the locally attached CE device 1. Discover the IP addresses of the locally attached CE device
2. Distribute those IP Addresses to the remote PE 2. Terminate, do not distribute ARP and Inverse ARP requests from CE
3. Notify the locally attached CE of the remote CE's IP address. device(s) at local PE.
3. Distribute those IP Addresses to the remote PE
4. Notify the locally attached CE of the remote CE's IP address.
This information is gathered using the mechanisms described in the This information is gathered using the mechanisms described in the
following sections. following sections.
4.0 IP Layer 2 Interworking Circuit 4. IP Layer 2 Interworking Circuit
The IP Layer 2 interworking Circuit refers to interconnection of The IP Layer 2 interworking Circuit refers to interconnection of the
the Attachment Circuit with the IP Layer 2 Transport pseudo-wire Attachment Circuit with the IP Layer 2 Transport pseudo-wire that
that carries IP datagrams as the payload. The ingress PE removes carries IP datagrams as the payload. The ingress PE removes the
the data link header of its local Attachment Circuit and transmits data link header of its local Attachment Circuit and transmits the
the payload (an IP frame) over the pseudo-wire with or without the payload (an IP frame) over the pseudo-wire with or without the
optional control word. In some cases, multiple data link headers optional control word. In some cases, multiple data link headers may
may exist, such as bridged PDU on ATM AC. In this case, ATM header exist, such as bridged PDU on ATM AC. In this case, ATM header as
as well as the Ethernet header is removed to expose the IP frame. well as the Ethernet header is removed to expose the IP frame. The
The egress PE encapsulates the IP packet with the data link header egress PE encapsulates the IP packet with the data link header used
used on its local Attachment Circuit. 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.0 Discovery of IP Addresses of Locally Attached CE Device 5. Discovery of IP Addresses of Locally Attached CE Device
Shah, et. al. Expires April 2006 4
draft-ietf-l2vpn-arp-mediation-04.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 performs
two functions. two functions.
. Discovery of locally attached CE IP device
. Establishment of the PW o Discovery of locally attached CE IP device
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 IP
address discovery. During the period when the PW has been 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 Attachment
Circuit and pseudo-wire; unicast IP datagrams are dropped. On Circuit and pseudo-wire; unicast IP datagrams are dropped. On
Ethernet AC, MAC Destination Address is used to classify Ethernet AC, MAC Destination Address is used to classify
unicast/multicast packets. However, on non-Ethernet ACs, IP unicast/multicast packets. However, on non-Ethernet ACs, IP
destination address is used to classify unicast/multicast packets. destination address is used to classify unicast/multicast packets.
The unicast IP frames are propagated between AC and pseudo-wire The unicast IP frames are propagated between AC and pseudo-wire only
only when CE IP devices on both Attachment Circuits have been when CE IP devices on both Attachment Circuits have been discovered,
discovered, notified and proxy functions have completed. 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 attached
CEs from any IP traffic, such as link local multicast packets CEs from any IP traffic, such as link local multicast packets (e.g.,
(e.g., destined to 224.0.0.x), and are not restricted to the destined to 224.0.0.x), and are not restricted to the operations
operations below. 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 If a CE device uses ARP to determine the MAC address to IP address
binding of its neighbor, the PE processes the ARP requests to learn binding of its neighbor, the PE processes the ARP requests to learn
the IP address of local CE for the stated locally attached circuit. the IP address of local CE for the stated locally attached circuit.
If we observe the strict topology restriction whereby only one IP This document mandates that only one CE per attachment circuit MUST
router CE can exist for a given AC then the PE can assume that ARP be connected to the PE. However, customer facing access topology may
request received is from the candidate IP CE and can learn the IP exist whereby more than one CEs appear to be connected to the PE on
to MAC address binding of the local CE. 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
However, if this topology restriction is relaxed, the PE can learn case, the PE MUST select one local CE. The selection could be based
the MAC address to IP address binding of the local CE but can not on manual configuration or PE may optionally use following selection
assume that this CE (possibly amongst many) is the candidate IP criteria. In either case, manual configuration of local CEís IP
device that is to be interworked with the remote attachment address (and MAC address) MUST be supported.
circuit. In this case, the PE may select the local CE device using
following criteria.
. 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 the
ARP request for the remote CE's IP address. request for the remote CE's IP address.
. Augment cross checking with the local IP address learned o Augment cross checking with the local IP address learned through
through listening of link local multicast packets (as per listening of link local multicast packets (as per section 5.1
section 5.1 above) above)
o Augment cross checking with the local IP address learned through
Shah, et. al. Expires April 2006 5 the Router Discovery protocol (as described below in section
draft-ietf-l2vpn-arp-mediation-04.txt 5.5).
o There is still a possibility that the local PE may not receive an
. Augment cross checking with the local IP address learned IP address advertisement from the remote PE and there may exist
through the Router Discovery protocol (as described below in multiple local IP routers that attempt to 'connect' to remote
section 5.5). CEs. In this situation, the local PE may use some other criteria
. There is still a possibility that the local PE may not receive to select one IP device from many (such as "the first ARP
an IP address advertisement from the remote PE and there may received"), or an operator may configure the IP address of local
exist multiple local IP routers that attempt to 'connect' to CE. Note that the operator does not have to configure the IP
remote CEs. In this situation, the local PE may use some other address of the remote CE (as that would be learned through
criteria to select one IP device from many (such as "the first pseudo-wire signaling).
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 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 that
device with its own MAC address when the destination IP address in device with its own MAC address when the destination IP address in
the ARP request is found to match with the remote CE's IP address. the ARP request is found to match with the remote CE's IP address.
The local PE signals the CE's IP address to the remote PE and may The local PE signals the CE's IP address to the remote PE and may
initiate an unsolicited ARP response to notify local CE MAC address initiate an unsolicited ARP response to notify local CE MAC address
to IP address binding of the remote CE. Once the ARP mediation to IP address binding of the remote CE. Once the ARP mediation
function is completed, unicast IP frames are propagated between the function is completed, unicast IP frames are propagated between the
AC and the established PW. AC and the established PW.
skipping to change at line 296 skipping to change at page 8, line 14
IP address as a means of verifying the continued existence of the IP address as a means of verifying the continued existence of the
address and its binding to the MAC address. The absence of a address and its binding to the MAC address. The absence of a
response from the CE device for a given number of retries could be response from the CE device for a given number of retries could be
used as a cause for withdrawal of the IP address advertisement to used as a cause for withdrawal of the IP address advertisement to
the remote PE. The local PE would then enter into the address the remote PE. The local PE would then enter into the address
resolution phase to rediscover the attached CE's IP address. Note resolution phase to rediscover the attached CE's IP address. Note
that this "heartbeat" scheme is needed only for broadcast links that this "heartbeat" scheme is needed only for broadcast links
(such as Ethernet AC), as the loss of a CE may otherwise be (such as Ethernet AC), as the loss of a CE may otherwise be
undetectable. undetectable.
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 its
neighbor, the attached PE processes the Inverse ARP request for neighbor, the attached PE processes the Inverse ARP request for
stated circuit and responds with an Inverse ARP reply containing stated circuit and responds with an Inverse ARP reply containing the
the remote CE's IP address, if the address is known. If the PE does remote CE's IP address, if the address is known. If the PE does not
not yet have the remote CE's IP address, it does not respond, but yet have the remote CE's IP address, it does not respond, but notes
notes the IP address of the local CE and the circuit information. the IP address of the local CE and the circuit information.
Subsequently, when the IP address of the remote CE becomes Subsequently, when the IP address of the remote CE becomes
available, the PE may initiate the Inverse ARP request as a means available, the PE may initiate the Inverse ARP request as a means to
to notify the local CE about the IP address of the remote CE. 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
Shah, et. al. Expires April 2006 6
draft-ietf-l2vpn-arp-mediation-04.txt
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 and
5.5. 5.5
5.4 CE Devices Using PPP 5.4. CE Devices Using PPP
The IP Control Protocol (IPCP) describes a procedure to establish The IP Control Protocol [PPP-IPCP] describes a procedure to
and configure IP on a point-to-point connection, including the establish and configure IP on a point-to-point connection, including
negotiation of IP addresses. When using IP (Routed) mode L2VPN the negotiation of IP addresses. When using IP (Routed) mode L2VPN
interworking, PPP negotiation is not performed end-to-end between interworking, PPP negotiation is not performed end-to-end between
CE devices. In this case, PPP negotiation takes place between the CE devices. In this case, PPP negotiation takes place between the CE
CE device and its local PE device (on the PPP attachment circuit). device and its local PE device (on the PPP attachment circuit). The
The PE device performs proxy PPP negotiation, and informs the local PE device performs proxy PPP negotiation, and informs the local CE
CE device of the IP address of the remote CE device during IPCP device of the IP address of the remote CE device during IPCP
negotiation using the IP-Address option [0x03]. 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, the
local PE MAY perform following actions local PE MAY perform following actions
o The PE learns the IP address of the local CE from the Configure-
. The PE learns the IP address of the local CE from the Configure-
Request received with the IP-Address option (0x03). The PE Request received with the IP-Address option (0x03). The PE
verifies that the IP address present in the IP-Address option is verifies that the IP address present in the IP-Address option is
non-zero. If the IP address is zero, PE responds with Configure- 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 Reject (as this is a request from CE to assign him an IP
address). Also, the Configure-Reject copies the IP-Address option address). Also, the Configure-Reject copies the IP-Address option
with null value to instruct the CE to not include that option in 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 new Configure-Request. If the IP address is non-zero, PE responds
with Configure-Ack. with Configure-Ack.
. If the PE receives Configure-Request without the IP-Address o If the PE receives Configure-Request without the IP-Address
option, PE responds with Configure-Ack. In this case, PE would option, PE responds with Configure-Ack. In this case, PE would
not learn the IP address of the local CE using IPCP and hence 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 would rely on other means as described above (such as link-local
broadcast from OSPF hello). Note that in order to employ other broadcast from OSPF hello). Note that in order to employ other
learning mechanisms, IPCP connection must be open. learning mechanisms, IPCP connection must be open.
. If the PE does not know the IP address of the remote CE, it o If the PE does not know the IP address of the remote CE, it
generates a Configure-Request without the IP-Address option. generates a Configure-Request without the IP-Address option.
. If the PE knows the IP address of the remote CE, it sends an IPCP 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 Configure-Request with the IP-Address option containing the
remote CE's IP address. remote CE's IP address.
The IPCP IP-Address option MAY be negotiated between the PE and the The IPCP IP-Address option MAY be negotiated between the PE and the
local CE device. Configuration of other IPCP option MAY be local CE device. Configuration of other IPCP option MAY be rejected.
rejected. Other NCPs, with the exception of the Compression Control Other NCPs, with the exception of the Compression Control Protocol
Protocol (CCP) and Encryption Control Protocol (ECP), MUST be (CCP) and Encryption Control Protocol (ECP), MUST be rejected. The
rejected. The PE device MAY reject configuration of the CCP and PE device MAY reject configuration of the CCP and ECP.
ECP.
5.5 Router Discovery method
Shah, et. al. Expires April 2006 7 5.5. Router Discovery method
draft-ietf-l2vpn-arp-mediation-04.txt
In order to learn the IP address of the CE device for a given In order to learn the IP address of the CE device for a given
Attachment Circuit, the PE device may execute Router Discovery Attachment Circuit, the PE device may execute Router Discovery
Protocol [RFC 1256] whereby a Router Discovery Request (ICMP - Protocol [RFC 1256] whereby a Router Discovery Request (ICMP -
router solicitation) message is sent using a source IP address of router solicitation) message is sent using a source IP address of
zero. The IP address of the CE device is extracted from the Router zero. The IP address of the CE device is extracted from the Router
Discovery Response (ICMP - router advertisement) message from the Discovery Response (ICMP - router advertisement) message from the
CE. It is possible that the response contains more than one router CE. It is possible that the response contains more than one router
addresses with the same preference level; in which case, some addresses with the same preference level; in which case, some
heuristics (such as first on the list) is necessary. 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.0 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 when
the encapsulation type of the pseudo-wire is IP Layer2 Transport the encapsulation type of the pseudo-wire is IP Layer2 Transport
(the value 0x0000B, as defined in [PWE3-IANA]). It is quite (the value 0x0000B, as defined in [PWE3-IANA]). It is quite
possible that the IP address of a CE device is not available at the possible that the IP address of a CE device is not available at the
time the PW labels are signaled. For example, in Frame Relay the CE 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; device sends an inverse ARP request only when the DLCI is active; if
if the PE signals the DLCI to be active only when it has received the PE signals the DLCI to be active only when it has received the
the IP address along with the PW FEC from the remote PE, a chicken IP address along with the PW FEC from the remote PE, a chicken and
and egg situation arises. In order to avoid such problems, the PE egg situation arises. In order to avoid such problems, the PE must
must be prepared to advertise the PW FEC before the CE's IP address be prepared to advertise the PW FEC before the CE's IP address is
is known. When the IP address of the CE device does become known and hence uses IP address value zero. When the IP address of
available, the PE re-advertises the PW FEC along with the CE's IP the CE device does become available, the PE re-advertises the PW FEC
address. along with the CE's IP address.
Similarly, if the PE detects that an IP address of a CE is no Similarly, if the PE detects that an IP address of a CE is no longer
longer valid (by methods described above), the PE must valid (by methods described above), the PE must re-advertise the PW
re-advertise the PW FEC with null IP address to denote the FEC with null IP address to denote the withdrawal of the CE's IP
withdrawal of the CE's IP address. The receiving PE then waits for address. The receiving PE then waits for notification of the remote
notification of the remote IP address. During this period, IP address. During this period, propagation of unicast IP traffic is
propagation of unicast IP traffic is suspended, but multicast IP suspended, but multicast IP traffic can continue to flow between the
traffic can continue to flow between the AC and the pseudo-wire. 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 port,
for example, the IP addresses are learned in the same manner for example, the IP addresses are learned in the same manner
described above. However, since the CE devices are local, the described above. However, since the CE devices are local, the
distribution of IP addresses for these CE devices is a local step. 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) transport
to exchange PW FEC in the Label Mapping message in the Downstream to exchange PW FEC in the Label Mapping message in the Downstream
Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and
Generalized ID FEC elements and has some common fields between them.
Shah, et. al. Expires April 2006 8 The discussions below refer to these common fields for IP L2
draft-ietf-l2vpn-arp-mediation-04.txt Interworking encapsulation.
Generalized ID FEC elements and has some common fields between
them. The discussions below refer to these common fields for IP L2
Interworking Circuits.
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 that
must be included in the optional parameter field of the Label must be included in the optional parameter field of the Label
Mapping message when advertising the PW FEC for the IP Layer2 Mapping message when advertising the PW FEC for the IP Layer2
Transport. The use of optional parameters in the Label Mapping Transport. The use of optional parameters in the Label Mapping
message to extend the attributes of the PW FEC is specified in the message to extend the attributes of the PW FEC is specified in the
[PWE3-Control]. [PWE3-Control].
When processing a received PW FEC, the PE matches the PW Id and PW When processing a received PW FEC, the PE matches the PW Id and PW
type with the locally configured PW Id to determine if the PW FEC type with the locally configured PW Id to determine if the PW FEC
is of type IP Layer2 Transport. If there is a match, it further is of type IP Layer2 Transport. If there is a match, it further
checks the presence of IP address TLV in the optional parameter checks the presence of IP address TLV in the optional parameter
field. If absent, a Label Release message is issued with a Status field. If absent, a Label Release message is issued with a Status
Code meaning "IP Address of the CE is absent" [note: Status Code Code meaning "IP Address of the CE is absent" [note: Status Code
0x0000002C is pending IANA allocation] to reject the PW 0x0000002C is pending IANA allocation] to reject the PW
establishment. establishment.
We use the Address List TLV as defined in RFC 3036 to signal the IP 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 address of the local CE. This IP address TLV must be included in the
the optional parameter field of the Label Mapping message. 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 | CE's IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CE's IP Address | ~ CE's IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length
When Address Family is IPV4, Length is equal to 6 bytes; When Address Family is IPV4, Length is equal to 6 bytes; 2 bytes
2 bytes for address family and 4 bytes of IP address. 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 FAMILY
NUMBERS from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the NUMBERS from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the
address contained in the Address field. address contained in the Address field.
CE's IP Address CE's IP Address
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 the
protocol: protocol:
Address Family Address Encoding Address Family Address Encoding
Shah, et. al. Expires April 2006 9
draft-ietf-l2vpn-arp-mediation-04.txt
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 The IP address field is set to value null to denote that advertising
advertising PE has not learned the IP address of his local CE PE has not learned the IP address of his local CE device. The non-
device. The non-zero value of the IP address field denotes IP zero value of the IP address field denotes IP address of advertising
address of advertising PE's attached CE device. PE's attached CE device.
The CE's IP address is also supplied in the optional parameter The CE's IP address is also supplied in the optional parameter field
field of the LDP's Notification message along with the PW FEC. The of the LDP's Notification message along with the PW FEC. The LDP
LDP Notification message is used to signal the change in CE's IP Notification message is used to signal the change in CE's IP
address. 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 CE",
to indicate that IP Address update follows. Since this notification to indicate that IP Address update follows. Since this notification
does not refer to any particular message the Message Id, and does not refer to any particular message the Message Id, and Message
Message Type fields are set to 0. [note: Status Code 0x0000002B is Type fields are set to 0. [note: Status Code 0x0000002B is pending
pending IANA allocation]. 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 they
are ignored in the context of this message. 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 the
necessary information on demand. For those cases, out-of-band necessary information on demand. For those cases, out-of-band
methods, such as manual configuration, MAY be used. methods, such as manual configuration, MAY be used. The support for
manual configuration of the local CEís IP address is mandatory.
7.0 IANA Considerations
7.1 LDP Status messages 7. IANA Considerations
Shah, et. al. Expires April 2006 10 7.1. LDP Status messages
draft-ietf-l2vpn-arp-mediation-04.txt
This document uses new LDP status codes, IANA already maintains a This document uses new LDP status codes, IANA already maintains a
registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The
following values are suggested for assignment: 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.0 How a CE Learns the Remote CE's IP address 8. How a CE Learns the Remote CE's IP address
Once the local PE has received the remote CE's IP address Once the local PE has received the remote CE's IP address
information from the remote PE, it will either initiate an address information 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 the remote CE's IP address 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 know the local CE's IP
address. If the local CE's IP address is not known, the PE must address. If the local CE's IP address is not known, the PE must wait
wait until it is acquired through one of the methods described in until it is acquired through one of the methods described in
sections 5.1, 5.3 and 5.5. If the IP address of the local CE is sections 5.1, 5.3 and 5.5. If the IP address of the local CE is
known, the PE may choose to generate an unsolicited ARP message to known, the PE may choose to generate an unsolicited ARP message to
notify the local CE about the binding of the remote CE's IP address notify the local CE about the binding of the remote CE's IP address
with the PE's own MAC address. with the PE's own MAC address.
When the local CE generates an ARP request, the PE must proxy the When the local CE generates an ARP request, the PE must proxy the
ARP response using its own MAC address as the source hardware ARP response [PROXY-ARP] using its own MAC address as the source
address and remote CE's IP address as the source protocol address. hardware address and remote CE's IP address as the source protocol
The PE must respond only to those ARP requests whose destination address. The PE must respond only to those ARP requests whose
protocol address matches the remote CE's IP address. An exception destination protocol address matches the remote CE's IP address. An
to this rule is when the strict topology of one IP end station per exception to this rule is when the strict topology of one IP end
Attachment Circuit is assumed. In which case, PE can promiscuously station per Attachment Circuit is assumed. In which case, PE can
respond to the CE's ARP request with his own MAC address. promiscuously respond to the CE's ARP request with his own MAC
address.
8.2 CE Devices Using Inverse ARP
When the PE learns the remote CE's IP address, it should generate 8.2. CE Devices Using Inverse ARP
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.
8.3 CE Devices Using PPP When the PE learns the remote CE's IP address, 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 April 2006 11 8.3. CE Devices Using PPP
draft-ietf-l2vpn-arp-mediation-04.txt
When the PE learns the remote CE's IP address, it should initiate When the PE learns the remote CE's IP address, it should initiate
the Configure-Request and set the IP-Address option to the remote the Configure-Request and set the IP-Address option to the remote
CE's IP address to notify local CE the IP address of the remote CE. CE's IP address to notify local CE the IP address of the remote CE.
9.0 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 a
broadcast link is cross-connected with an IGP on a CE connected to broadcast link is cross-connected with an IGP on a CE connected to a
a point-to-point link, there are routing protocol related issues point-to-point link, there are routing protocol related issues that
that must be addressed. The link state routing protocols are must be addressed. The link state routing protocols are cognizant of
cognizant of the underlying link characteristics and behave the underlying link characteristics and behave accordingly when
accordingly when establishing neighbor adjacencies, representing establishing neighbor adjacencies, representing the network
the network topology, and passing protocol packets. 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 designated
and a backup designated router (DR and BDR respectively) with which and a backup designated router (DR and BDR respectively) with which
it forms adjacencies. However, these procedures are neither it forms adjacencies. However, these procedures are neither
applicable nor understood by OSPF running on a point-to-point link. applicable nor understood by OSPF running on a point-to-point link.
By cross-connecting two neighbors with disparate link types, an IP By cross-connecting two neighbors with disparate link types, an IP
L2 interworking L2VPN may experience connectivity issues. 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
skipping to change at line 608 skipping to change at page 15, line 14
applicable nor understood by OSPF running on a point-to-point link. applicable nor understood by OSPF running on a point-to-point link.
By cross-connecting two neighbors with disparate link types, an IP By cross-connecting two neighbors with disparate link types, an IP
L2 interworking L2VPN may experience connectivity issues. 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 by
an OSPF router on the point-to-point link further adds to the an OSPF router on the point-to-point link further adds to the
confusion. confusion.
Fortunately, the OSPF protocol provides a configuration option Fortunately, the OSPF protocol provides a configuration option
(ospfIfType), whereby OSPF will treat the underlying physical (ospfIfType), whereby OSPF will treat the underlying physical
broadcast link as a point-to-point link. broadcast link as a point-to-point link.
It is strongly recommended that all OSPF protocols on CE devices It is strongly recommended that all OSPF protocols on CE devices
connected to Ethernet interfaces use this configuration option when connected to Ethernet interfaces use this configuration option when
attached to a PE that is participating in an IP L2 Interworking attached to a PE that is participating in an IP L2 Interworking VPN.
VPN.
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 the
group/broadcast address snooping mechanism is used as described group/broadcast address snooping mechanism is used as described
above, the attached PE can learn the advertising (CE) router's IP above, the attached PE can learn the advertising (CE) router's IP
address from the IP header of the advertisement. No special address from the IP header of the advertisement. No special
configuration is required for RIP in this type of Layer 2 IP configuration is required for RIP in this type of Layer 2 IP
Interworking L2VPN. Interworking L2VPN.
Shah, et. al. Expires April 2006 12 10. IPV6 Considerations
draft-ietf-l2vpn-arp-mediation-04.txt
10.0 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.0 Security Considerations 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 network configuration whereby PE1 in network A
is connected to CE1 and PE4 in network B is connected to CE2. The
PE2 on network A is connected to PE3 in network B directly with an
Ethernet. Since there is no CE present between PE2 and PE3, there
needs a mechanism for PE2 and PE3 to discover each otherís MAC
address to enable connectivity between CE1 and CE2 across the two
networks. There are two options.
. Configure CE2ís IP address as a local CEís IP address at PE2
and CE1ís IP address as local CEís IP address 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 otherís
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ís) network.
. 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.
12. Security Considerations
The security aspect of this solution is addressed for two planes; The security aspect of this solution is addressed for two planes;
control plane and data plane. control plane and data plane.
11.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 the
configured peer's address and authenticating the LDP messages using configured peer's address and authenticating the LDP messages using
MD5 authentication. The pseudo-wire establishments between two MD5 authentication. The pseudo-wire establishments between two
secure LDP peers do not pose security issue but mis-wiring could secure LDP peers do not pose security issue but mis-wiring could
occur due to configuration error. Some checks, such as, proper occur due to configuration error. Some checks, such as, proper
pseudo-wire type and other pseudo-wire options may prevent mis- pseudo-wire type and other pseudo-wire options may prevent mis-
wiring due to configuration errors. wiring due to configuration errors.
The learning of the appropriate CE's IP address can be a security The learning of the appropriate CE's IP address can be a security
issue. It is expected that the local attachment circuit to CE is issue. It is expected that the local attachment circuit to CE is
physically secured. If this is a concern, the PE must be configured physically secured. If this is a concern, the PE must be configured
with CE's IP and MAC address when connected with Ethernet or CE's with CE's IP and MAC address when connected with Ethernet or CE's IP
IP and virtual circuit information (e.g. DLCI or VPI/VCI). During and virtual circuit information (e.g. DLCI or VPI/VCI). During each
each ARP/inARP frame processing, PE must verify the received ARP/inARP frame processing, PE must verify the received information
information against the configuration before accepting to protect against the configuration before accepting to protect against
against hijacking the connection. hijacking the connection.
11.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 tap
into the CE to PE connection and generate traffic using the spoofed into the CE to PE connection and generate traffic using the spoofed
destination MAC address on the Ethernet Attachment Circuit. In destination MAC address on the Ethernet Attachment Circuit. In order
order to avoid such hijacking, local PE may verify the source MAC to avoid such hijacking, local PE may verify the source MAC address
address of the received frame against the MAC address of the of the received frame against the MAC address of the admitted
admitted connection. The frame is forwarded to PW only when connection. The frame is forwarded to PW only when authenticity is
authenticity is verified. When spoofing is detected, PE must sever verified. When spoofing is detected, PE must sever the connection
the connection with the local CE, tear down the PW and start over. with the local CE, tear down the PW and start over.
12.0 Acknowledgements
Shah, et. al. Expires April 2006 13 13. Acknowledgements
draft-ietf-l2vpn-arp-mediation-04.txt
The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce
Lasley, Mark Lewis, Carlos Pignataro and other folks who 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.
13.0 References 14. References
13.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 Resolution
Protocol: Or Converting Network Protocol Addresses to 48.bit protocol: Or Converting Network Protocol Addresses to 48.bit
Ethernet Addresses for Transmission on Ethernet Hardware". Ethernet Addresses for Transmission on Ethernet Hardware".
[INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution
Protocol". Protocol".
[PWE3-Control] L. Martini et al., "Pseudowire Setup and Maintenance [PWE3-Control] L. Martini et al., "Pseudowire Setup and Maintenance
using LDP", February 2005, work in progress. using LDP", RFC 4447.
[PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire
Edge to Edge Emulation (PWE3)", RFC 4446.
[PWE3-IANA] L. Martini et al,. IANA Allocations for pseudo Wire [MS-PW] M.Bocci et al,. "An Architecture for Multi-Segment Pseudo
Edge to Edge Emulation (PWE3), February 2005, work in progress. Wire Emulation Edge-to-Edge", May 2006, work in progress
[RFC 1700] Reynolds and Postel, "Assigned Numbers".
[RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels".
13.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 2004,
work in progress. work in progress.
[PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
Control Protocol (IPCP)". Control Protocol (IPCP)".
[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".
14.0 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,
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Shah, et. al. Expires April 2006 14
draft-ietf-l2vpn-arp-mediation-04.txt
Waldemar Augustyn Waldemar Augustyn
Email: waldemar@nxp.com Email: waldemar@nxp.com
Giles Heron Giles Heron
Email: giles.heron@tellabs.com Email: giles.heron@tellabs.com
Sunil Khandekar and Vach Kompella Sunil Khandekar and Vach Kompella
Email: sunil@timetra.com Email: sunil@timetra.com
Email: vkompella@timetra.com Email: vkompella@timetra.com
skipping to change at line 762 skipping to change at page 19, line 33
San Jose, CA 95134 San Jose, CA 95134
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
Shah, et. al. Expires April 2006 15
draft-ietf-l2vpn-arp-mediation-04.txt
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at line 793 skipping to change at page 20, line 22
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. 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 on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
This document is subject to the rights, licenses and restrictions except as set forth therein, the authors retain all their rights.
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Shah, et. al. Expires April 2006 16
 End of changes. 96 change blocks. 
325 lines changed or deleted 305 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/