One document matched: draft-ietf-l2vpn-arp-mediation-09.txt
Differences from draft-ietf-l2vpn-arp-mediation-08.txt
L2VPN Working Group Himanshu Shah Ciena Corp
Intended Status: Proposed Standard Eric Rosen Cisco System
Internet Draft Giles Heron BT
Vach Kompella Alcatel/lucent
February 2008
Expires: August 2008
ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-09.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 2008.
Shah et al Expires August 2008 [Page 1]
Draft-ietf-l2vpn-arp-mediation-09.txt
Abstract
The VPWS service [L2VPN-FRM] provides point-to-point connections
between pairs of Customer Edge (CE) devices. It does so by
binding two Attachment Circuits (each connecting a CE device
with a Provider Edge, PE, device) to a pseudowire (connecting
the two PEs). In general, the Attachment Circuits must be of
the same technology (e.g., both Ethernet, both ATM), and the
pseudowire 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 pseudowire 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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC 2119].
Table of Contents
1. Contributing Authors........................................3
2. Introduction................................................4
3. ARP Mediation (AM) function.................................5
4. IP Layer 2 Interworking Circuit.............................6
5. IP Address Discovery Mechanisms.............................6
5.1. Discovery of IP Addresses of Locally Attached IPv4 CE
Devices.....................................................7
5.1.1. Monitoring Local Traffic..........................7
5.1.2. CE Devices Using ARP..............................7
5.1.3. CE Devices Using Inverse ARP......................8
5.1.4. CE Devices Using PPP..............................9
5.1.5. Router Discovery method..........................10
5.1.6. Manual Configuration.............................10
5.2. How a CE Learns the IPv4 address of a remote CE.......10
Shah et al Expires August 2008 [Page 2]
Draft-ietf-l2vpn-arp-mediation-09.txt
5.2.1. CE Devices Using ARP.............................10
5.2.2. CE Devices Using Inverse ARP.....................11
5.2.3. CE Devices Using PPP.............................11
5.3. Discovery of IP Addresses of Locally Attached IPv6 CE
Devices [RFC 2461].........................................11
5.3.1. Monitoring Local Traffic.........................11
5.3.2. CE Devices Using Neighbor Discovery..............12
5.3.3. CE Devices Using Inverse Neighbor Discovery......13
5.3.4. Manual Configuration.............................13
5.4. How a CE Learns the IPv6 address of a remote CE.......13
5.4.1. CE Devices Using Neighbor Discovery..............14
5.4.2. CE Devices Using Inverse Neighbor Discovery......14
6. CE IP Address Signaling between PEs........................15
6.1. When to Signal an IP address of a CE..................15
6.2. LDP Based Distribution................................15
7. IANA Considerations........................................18
7.1. LDP Status messages...................................18
8. Use of IGPs with IP L2 Interworking L2VPNs.................18
8.1. OSPF..................................................19
8.2. RIP...................................................19
8.3. IS-IS.................................................19
9. Multi-domain considerations................................20
10. Security Considerations...................................21
10.1. Control plane security...............................21
10.2. Data plane security..................................22
11. Acknowledgements..........................................22
12. References................................................22
12.1. Normative References.................................22
12.2. Informative References...............................23
13. Authors' Addresses........................................23
Full Copyright Statement......................................24
Intellectual Property.........................................25
1. Contributing Authors
This document is the combined effort of the following
individuals and many others who have carefully reviewed the
document and provided the technical clarifications.
W. Augustyn consultant
T. Smith Network Appliances
A. Moranganti Big Band Networks
S. Khandekar Alcatel/Lucent
Shah et al Expires August 2008 [Page 3]
Draft-ietf-l2vpn-arp-mediation-09.txt
A. Malis Verizon
S. Wright Bell South
V. Radoaca consultant
A. Vishwanathan Force10 Networks
T. Grigoriu Alcatel/Lucent
N. Hart Alcatel/Lucent
S. Amante Level3
2. Introduction
Layer 2 Virtual Private Networks (L2VPN) are constructed over a
Service Provider IP backbone but are presented to the Customer
Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can
carry any Layer 3 protocol, but in many cases, the Layer 3
protocol is IP. Thus it makes sense to consider procedures that
are optimized for IP.
In a typical implementation, illustrated in the diagram below,
the CE devices are connected to the Provider Edge (PE) devices
via Attachment Circuits (AC). The ACs are Layer 2 links. In a
pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via
AC2, both ACs would have to be of the same type (i.e., both
Ethernet, both FR, etc.). However, if it is known that only IP
traffic will be carried, the ACs can be of different
technologies, provided that the PEs provide the appropriate
procedures to allow the proper transfer of IP packets.
+-----+
+------------| CE3 |
| +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................
A CE, which is connected via a given type of AC, may use an IP
Address Resolution procedure that is specific to that type of
AC. For example, an Ethernet-attached IPv4 CE would use ARP
Shah et al Expires August 2008 [Page 4]
Draft-ietf-l2vpn-arp-mediation-09.txt
[ARP] and a FR-attached CE might use Inverse ARP [INVARP]. If
we are to allow the two CEs to have a Layer 2 connection between
them, even though each AC uses a different Layer 2 technology,
the PEs must intercept and "mediate" the Layer 2 specific
address resolution procedures.
In this draft, we specify the procedures for VPWS services,
which the PEs must implement in order to mediate the IP address
resolution mechanism. We call these procedures "ARP Mediation".
Consider a Virtual Private Wire Service (VPWS) constructed
between CE1 and CE2 in the diagram above. If AC1 and AC2 are of
different technologies, e.g. AC1 is Ethernet and AC2 is Frame
Relay (FR), then ARP requests coming from CE1 cannot be passed
transparently to CE2. PE1 must interpret the meaning of the ARP
requests and mediate the necessary information with PE2 before
responding.
3. ARP Mediation (AM) function
The ARP Mediation (AM) function is an element of a PE node that
deals with the IP address resolution for CE devices connected
via an VPWS L2VPN. By placing this function in the PE node, ARP
Mediation is transparent to the CE devices.
For a given point-to-point connection between a pair of CEs, a
PE must perform the following logical steps as part of the ARP
Mediation procedure:
1. Discover the IP address of the locally attached CE device
2. Terminate, do not distribute ARP, Inverse ARP, Neighbor
Discovery and Inverse Neighbor Discovery requests from CE
device at local PE.
3. Distribute those IP Addresses to the remote PE
4. Notify the locally attached CE of the IP address of the
remote CE.
5. Respond appropriately to ARP, Inverse ARP, Neighbor
Discovery and Inverse Neighbor Discovery requests from
local CE device, using IP address of remote CE and
hardware address of local PE.
This information is gathered using the mechanisms described in
the following sections.
Shah et al Expires August 2008 [Page 5]
Draft-ietf-l2vpn-arp-mediation-09.txt
4. IP Layer 2 Interworking Circuit
The IP Layer 2 interworking Circuit refers to interconnection of
the Attachment Circuit with the IP Layer 2 Transport pseudowire
that carries IP datagrams as the payload. The ingress PE removes
the data link header of its local Attachment Circuit and
transmits the payload (an IP packet) over the pseudowire with or
without the optional control word. In some cases, multiple data
link headers may exist, such as bridged Ethernet PDU on ATM
Attachment Circuit. In this case, ATM header as well as the
Ethernet header is removed to expose the IP packet at the
ingress. The egress PE encapsulates the IP packet with the data
link header used on its local Attachment Circuit.
The encapsulation for the IP Layer 2 Transport pseudowire is
described in [RFC4447].
5. IP Address Discovery Mechanisms
An IP Layer 2 Interworking Circuit enters monitoring state
immediately after the configuration. During this state it
performs two functions.
- Discovery of locally attached CE IP device
- Establishment of the PW
The establishment of the PW occurs independently from local CE
IP address discovery. During the period when the PW has been
established but the local CE IP device has not been discovered,
only broadcast/multicast IP frames are propagated between the
Attachment Circuit and pseudowire; unicast IP datagrams are
dropped. The IP destination address is used to classify
unicast/multicast packets.
The unicast IP frames are propagated between AC and pseudowire
only when CE IP devices on both Attachment Circuits have been
discovered, notified and proxy functions have completed.
5.1. Discovery of IP Addresses of Locally Attached IPv4 CE Devices
Shah et al Expires August 2008 [Page 6]
Draft-ietf-l2vpn-arp-mediation-09.txt
5.1.1. Monitoring Local Traffic
The PE devices may learn the IP addresses of the locally
attached CEs from any IP traffic, such as link local multicast
packets (e.g., destined to 224.0.0.x), and are not restricted to
the operations below.
5.1.2. CE Devices Using ARP
If a CE device uses ARP to determine the IP address to MAC
address binding of its neighbor, the PE processes the ARP
requests to learn the IP address of local CE for the local
Attachment Circuit.
This document mandates that there MUST be only one CE per
Attachment Circuit. However, customer facing access topologies
may exist whereby more than one CE appears to be connected to
the PE on a single Attachment Circuit. For example this could be
the case when CEs are connected to a shared LAN that connects to
the PE. In such case, the PE MUST select one local CE. The
selection could be based on manual configuration or the 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.
o Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending
the request for IP address of the remote CE.
o Augment cross checking with the local IP address learned
through listening of link local multicast packets (as per
section 5.1.1 above)
o Augment cross checking with the local IP address learned
through the Router Discovery protocol (as described below
in section 5.1.5).
Shah et al Expires August 2008 [Page 7]
Draft-ietf-l2vpn-arp-mediation-09.txt
o There is still a possibility that the local PE may not
receive an IP address advertisement from the remote PE and
there may exist multiple local IP routers that attempt to
'connect' to remote CEs. In this situation, the local PE
may use some other criteria to select one IP device from
many (such as "the first ARP received"), or an operator
may configure the IP address of local CE. Note that the
operator does not have to configure the IP address of the
remote CE (as that would be learned through pseudowire
signaling).
Once the local and remote CEs has been discovered for the given
Attachment Circuit, the local PE responds with its own MAC
address to any subsequent ARP requests from the local CE with a
destination IP address matching the IP address of the remote CE.
The local PE signals IP address of the CE to the remote PE and
may initiate an unsolicited ARP response to notify the IP
address to MAC address binding for the remote CE to local CE
(again using its own MAC address).
Once the ARP mediation function is completed (i.e. the PE device
knows both the local and remote CE IP addresses), unicast IP
frames are propagated between the AC and the established PW.
The PE may periodically generate ARP request messages for the IP
address of the CE as a means of verifying the continued
existence of the address and its MAC address binding. The
absence of a response from the CE device for a given number of
retries could be used as a trigger for withdrawal of the IP
address advertisement to the remote PE. The local PE would then
re-enter 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), where the
failure of a CE device may otherwise be undetectable.
5.1.3. CE Devices Using Inverse ARP
If a CE device uses Inverse ARP to determine the IP address of
its neighbor, the attached PE processes the Inverse ARP request
from the Attachment Circuit and responds with an Inverse ARP
reply containing the IP address of the remote CE, if the address
is known. If the PE does not yet have the IP address of the
remote CE, it does not respond, but notes the IP address of the
local CE and the circuit information. Subsequently, when the IP
Shah et al Expires August 2008 [Page 8]
Draft-ietf-l2vpn-arp-mediation-09.txt
address of the remote CE becomes available, the PE may initiate
the Inverse ARP request as a means of notifying the IP address
of the remote CE to the local CE.
This is the typical mode of operation for Frame Relay and ATM
Attachment Circuits. If the CE does not use Inverse ARP, the PE
can still discover the IP address of local CE using the
mechanisms described in section 5.1.1 and 5.1.5
5.1.4. CE Devices Using PPP
The IP Control Protocol [PPP-IPCP] describes a procedure to
establish and configure IP on a point-to-point connection,
including the negotiation of IP addresses. When using IP
(Routed) mode L2VPN interworking, PPP negotiation is not
performed end-to-end between CE devices. In this case, PPP
negotiation takes place between the CE device and its local PE
device (on the PPP attachment circuit). The PE device performs
proxy PPP negotiation, and informs the local CE device of the IP
address of the remote CE device during IPCP negotiation using
the IP-Address option (0x03).
When a PPP link completes LCP negotiations, the local PE MAY
perform the following IPCP 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 it an IP address). Also, the Configure-
Reject copies the IP-Address option with a zero 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, it responds with a Configure-Ack. In this
case the PE is unable to learn the IP address of the local
CE using IPCP and hence must rely on other means as
described in sections 5.1.1 and 5.1.5. Note that in order
to employ other learning mechanisms, the IPCP negotiations
must have reached the open state.
o If the PE does not know the IP address of the remote CE,
it sends a Configure-Request without the IP-Address
option.
Shah et al Expires August 2008 [Page 9]
Draft-ietf-l2vpn-arp-mediation-09.txt
o If the PE knows the IP address of the remote CE, it sends
a 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 options 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.1.5. Router Discovery method
In order to learn the IP address of the CE device for a given
Attachment Circuit, the PE device may execute Router Discovery
Protocol [RFC 1256] whereby a Router Discovery Request (ICMP -
router solicitation) message is sent using a source IP address
of zero. The IP address of the CE device is extracted from the
Router Discovery Response (ICMP - router advertisement) message
from the CE. It is possible that the response contains more than
one router addresses with the same preference level; in which
case, some heuristics (such as first on the list) is necessary.
The use of the Router Discovery method by the PE is optional.
5.1.6. Manual Configuration
In some cases, it may not be possible to discover the IP address
of the local CE device using the mechanisms described in section
5.1 above. In such cases manual configuration MAY be used. All
implementations of this draft MUST support manual configuration
of the IP address of the local CE.
5.2. How a CE Learns the IPv4 address of a remote CE
Once the local PE has received the IP address information of the
remote CE from the remote PE, it will either initiate an address
resolution request or respond to an outstanding request from the
attached CE device.
5.2.1. CE Devices Using ARP
When the PE learns IP address of the remote CE as described in
section 6.1 and 6.2, it may or may not already know IP address
Shah et al Expires August 2008 [Page 10]
Draft-ietf-l2vpn-arp-mediation-09.txt
of the local CE. If the IP address is not known, the PE must
wait until it is acquired through one of the methods described
in sections 5.1.1, 5.1.2 and 5.1.5. If IP address of the local
CE is known, the PE may choose to generate an unsolicited ARP
message to notify the local CE about the binding of the IP
address of the remote CE with the PE's own MAC address.
When the local CE generates an ARP request, the PE must proxy
the ARP response [PROXY-ARP] using its own MAC address as the
source hardware address and IP address of remote CE as the
source protocol address. The PE must respond only to those ARP
requests whose destination protocol address matches the IP
address of the remote CE.
5.2.2. CE Devices Using Inverse ARP
When the PE learns the IP address of the remote CE, it should
generate an Inverse ARP request. If the Attachment Circuit
requires activation (e.g. Frame Relay) the PE should activate it
first before the Inverse ARP request. It should be noted, that
PE might never receive the response to its own request, nor see
any Inverse ARP request from the CE, in cases where CE is pre-
configured with IP address of the remote CE or where the use of
Inverse ARP has not been enabled. In either case the CE has used
other means to learn the IP address of his neighbor.
5.2.3. CE Devices Using PPP
When the PE learns the IP address of the remote CE, it should
initiate a Configure-Request and set the IP-Address option to
the IP address of the remote CE to notify the IP address of the
remote CE to the local CE.
5.3. Discovery of IP Addresses of Locally Attached IPv6 CE Devices
[RFC 2461]
5.3.1. Monitoring Local Traffic
The PE devices may learn the IP addresses of the locally
attached CEs from any IP traffic, such as link local multicast
packets (e.g., destined to FF02::x), and are not restricted to
the operations below.
Shah et al Expires August 2008 [Page 11]
Draft-ietf-l2vpn-arp-mediation-09.txt
5.3.2. CE Devices Using Neighbor Discovery
If a CE device uses Neighbor Discovery to determine the IP
address to MAC address binding of its neighbor, the PE processes
the messages to learn the IP address of local CE for the local
Attachment Circuit.
If the PE receives a Neighbor Solicitation message, and the
source IP address of the message is not the unspecified address,
the PE saves the CE address and may communicate it to the remote
PE (see section 6. ). It also saves the source link-layer
address. If the PE has received remote CE IP addresses, and the
destination address in the message matches one of the remote CE
IP addresses, the PE replies with a Neighbor Advertisement
specifying its own link-layer address as the source link-layer
address and the remote CE IP address as source address.
If the PE receives an unsolicited Neighbor Advertisement
message, the PE saves the CE address (the source IP address) and
may communicate it to the other PE. It also saves the source
link-layer address.
If the PE receives a Router Solicitation, and the source IP
address of the message is not the unspecified address, the PE
saves the CE address and may communicate it to the other PE. It
also saves the source link-layer address. If the PE has received
remote CE IP addresses from the other PE, it may reply with a
Router Advertisement, specifying its own source link-layer
address and specify remote CE IP addresses in prefix information
option.
If the PE receives a Router Advertisement, it may communicate
the source IP address and the on-link addresses to the other PE.
It also saves the source link-layer address.
Once the local and remote CE IP addresses have been discovered
for the given Attachment Circuit, the local PE responds with its
own link-layer address to any subsequent Neighbor Solicitation
and Router Solicitation requests from the local CE with a
destination IP address matching the IP address of the remote CE.
The local PE signals the IP addresses of the CE to the remote PE
and may initiate an unsolicited Router Advertisment to notify
the IP address to link-layer address binding for the remote CE
to local CE (again using its own link-layer address).
Shah et al Expires August 2008 [Page 12]
Draft-ietf-l2vpn-arp-mediation-09.txt
Once the ARP mediation function is completed (i.e. the PE device
knows both the local and remote CE IP addresses), unicast IP
frames are propagated between the AC and the established PW.
The PE will periodically generate Neighbor Solicitation messages
for the IP address of the CE as a means of verifying the
continued existence of the address and its MAC address binding.
The absence of a response from the CE device for a given number
of retries could be used as a trigger for withdrawal of the IP
address advertisement to the remote PE. The local PE would then
re-enter the address resolution phase to rediscover the IP
address of the attached CE.
5.3.3. CE Devices Using Inverse Neighbor Discovery
If a CE device uses Inverse Neighbor Discovery to determine the
IP address of its neighbor, the attached PE processes the
Inverse Neighbor Discovery Solicitation from the Attachment
Circuit and responds with an Inverse Neighbor Discovery
Advertisement containing the IP address of the remote CE, if the
address is known. If the PE does not yet have the IP address of
the remote CE, it does not respond, but notes the IP address of
the local CE and the circuit information. Subsequently, when the
IP address of the remote CE becomes available, the PE may
initiate the Inverse Neighbor Discovery Solicitation as a means
of notifying the IP address of the remote CE to the local CE.
This is the typical mode of operation for Frame Relay and ATM
Attachment Circuits.
5.3.4. Manual Configuration
In some cases, it may not be possible to discover the IP address
of the local CE device using the mechanisms described in
section 5.3. above. In such cases manual configuration MAY be
used. All implementations of this draft MUST support manual
configuration of the IP address of the local CE.
5.4. How a CE Learns the IPv6 address of a remote CE
Once the local PE has received the IP address information of the
remote CE from the remote PE, it will either initiate an address
resolution request or respond to an outstanding request from the
attached CE device. The PE uses the Address List TLV to
Shah et al Expires August 2008 [Page 13]
Draft-ietf-l2vpn-arp-mediation-09.txt
communicate the IP addresses. If the PE has received no Router
Advertisements from its local CE, it should specify the single
CE IP address it has received. If the PE has received a Router
Advertisement, it should specify an Address List in which the
first entry is the source interface address and the remaining
entries are taken from the list of on-link addresses.
5.4.1. CE Devices Using Neighbor Discovery
When the PE learns the IP address of the remote CE as described
in section 6.1 and 6.2, it may or may not already know the IP
address of the local CE. If the IP address is not known, the PE
must wait until it is acquired through one of the methods
described in section 5.3. above. If the IP address of the local
CE is known, the PE may choose to generate an unsolicited
Neighbor Advertisement message to notify the local CE about the
binding of the IP address of the remote CE with the PE's own
link-layer address. It may also generate a Router Advertisement
in which the source IP address is the first address from the
Address List TLV and the on-link addresses are the remaining
entries in the TLV.
When the local CE generates a Neighbor Solicitation request, the
PE must proxy the response using its own link-layer address as
the source hardware address and IP address of remote CE as the
source protocol address. The PE must respond only to those
requests whose target address matches the IP address of the
remote CE.
5.4.2. CE Devices Using Inverse Neighbor Discovery
When the PE learns the IP address of the remote CE, it should
generate an Inverse Neighbor Discovery Solicitation. If the
Attachment Circuit requires activation (e.g. Frame Relay) the PE
should activate it first before the Inverse Neighbor Discovery
Solicitation. It should be noted, that the PE might never
receive the response to its own solicitation, nor see any
Inverse Neighbor Discovery Solicitation from the CE, in cases
where the CE is pre-configured with the IP address of the remote
CE or where the use of Inverse Neighbor Discovery has not been
enabled. In either case the CE has used other means to learn the
IP address of his neighbor. The PE may also generate a Router
Advertisement message in the same way as specified in
section 5.4.1.
Shah et al Expires August 2008 [Page 14]
Draft-ietf-l2vpn-arp-mediation-09.txt
6. CE IP Address Signaling between PEs
6.1. When to Signal an IP address of a CE
A PE device advertises the IP address of the attached CE only
when the encapsulation type of the pseudowire is IP Layer2
Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is
quite possible that the IP address of a CE device is not
available at the time the PW labels are signaled. For example,
in Frame Relay the CE device sends an inverse ARP request only
when the DLCI is active. If the PE signals the DLCI to be active
only when it has received the IP address along with the PW FEC
from the remote PE, a chicken and egg situation arises. In order
to avoid such problems, the PE must be prepared to advertise the
PW FEC before the IP address of the CE is known and hence uses
IP address value zero. When the IP address of the CE device does
become available, the PE re-advertises the PW FEC along with the
IP address of the CE.
Similarly, if the PE detects that an IP address of a CE is no
longer valid (by methods described above), the PE must re-
advertise the PW FEC with null IP address to denote the
withdrawal of IP address of the CE. The receiving PE then waits
for notification of the remote IP address. During this period,
propagation of unicast IP traffic is suspended, but multicast IP
traffic can continue to flow between the AC and the pseudowire.
If two CE devices are locally attached to the PE where one CE is
connected to an Ethernet port and the other to a Frame Relay
port, for example, the IP addresses are learned in the same
manner described above. However, since the CE devices are local,
the distribution of IP addresses for these CE devices is a local
step.
6.2. LDP Based Distribution
[RFC4447] uses Label Distribution Protocol (LDP) transport to
exchange PW FECs in the Label Mapping message in the Downstream
Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and
Generalized ID FEC elements and has some common fields between
them. The discussions below refer to these common fields for IP
L2 Interworking encapsulation.
In addition to PW-FEC, this document defines an IP address list
TLV that must be included in the optional parameter field of the
Shah et al Expires August 2008 [Page 15]
Draft-ietf-l2vpn-arp-mediation-09.txt
Label Mapping message when advertising the PW FEC for the IP
Layer2 Transport. The use of optional parameters in the Label
Mapping message to extend the attributes of the PW FEC is
specified in the [RFC4447].
As defined in [RFC4447], when processing a received PW FEC, the
PE matches the PW ID and PW type with the locally configured PW
ID and PW Type. If there is a match, and if the PW Type is IP
Layer2 Transport the PE further checks for the presence of an
Address List TLV (as specified in [RFC 3036]) in the optional
parameter TLVs. If absent, a Label Release message is issued
with a Status Code meaning "IP Address of the CE is absent"
[note: Status Code 0x0000002D is pending IANA allocation] to
reject the PW establishment. The Address Family Type value
further augments the meaning of type of IP traffic (IPv4 or
IPv6) that PW will carry. If there is a mismatch between the
received Address Family value and the configured Address Family
value, the PE must issue a Label Release message with a Status
Code meaning "IP Address type mismatch" [note: Status Code
0x0000002E is pending IANA allocation] to reject the PW
establishment.
We use the Address List TLV as defined in [RFC 3036] to signal
the IP address(es) of the local CE. This IP address list TLV
must be included in the optional parameter field of the Label
Mapping message, and MUST contain exactly one address of family
IPv4 or one or more addresses of family IPv6. If the message
contains multiple IPv6 addresses, it is assumed that the PE
received a Router Advertisement and the first address in the
list was the source address of the Router Advertisement packet,
while the remaining addresses are taken from the on-link address
list of the Rourter Advertisement packet.
Encoding of the IP Address List TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | IP Address of CE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Address of CE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shah et al Expires August 2008 [Page 16]
Draft-ietf-l2vpn-arp-mediation-09.txt
Length
When Address Family is IPV4, Length is equal to 6 bytes; 2
bytes for address family and 4 bytes of IP address. When
Address Family is IPV6, Length is equal to (2 + (n * 16));
2 bytes for address family and 16 bytes for each IPv6
address.
Address Family
Two octet quantity containing a value from the ADDRESS
FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 3232]
that encodes the address contained in the Address field.
IP Address of CE
IP address of the CE attached to the advertising PE. The
encoding of the individual address depends on the Address
Family.
The following address encodings are defined by this version of
the protocol:
Address Family Address Encoding
IPv4 (1) 4 octet full IPv4 address
IPv6 (2) 16 octet full IPv6 address
The IP address field is set to all zeroes to denote that
advertising PE has not learned the IP address of its local CE
device. Any non-zero value of the IP address field denotes the
IP address of advertising PE's attached CE device.
The IP address of the CE is also supplied in the optional
parameters field of the LDP Notification message along with the
PW FEC. The LDP Notification message is used to signal any
change in the status of the CE's IP address.
The encoding of the LDP Notification message is as follows.
Shah et al Expires August 2008 [Page 17]
Draft-ietf-l2vpn-arp-mediation-09.txt
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address List TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is set to 0x0000002C "IP address of
CE", to indicate that IP Address update follows. Since this
notification does not refer to any particular message the
Message Id, and Message Type fields are set to 0. [note: Status
Code 0x0000002C is pending IANA allocation].
The PW FEC TLV SHOULD not include the interface parameters as
they are ignored in the context of this message.
7. IANA Considerations
7.1. LDP Status messages
This document uses new LDP status codes, IANA already maintains
a registry of name "STATUS CODE NAME SPACE" defined by [RFC
3036]. The following values are suggested for assignment:
0x0000002C "IP Address of CE"
0x0000002D "IP Address of the CE is absent"
0x0000002E "IP Address type mismatch"
8. Use of IGPs with IP L2 Interworking L2VPNs
In an IP L2 interworking L2VPN, when an IGP on a CE connected to
a broadcast link is cross-connected with an IGP on a CE
connected to a point-to-point link, there are routing protocol
related issues that must be addressed. The link state routing
protocols are cognizant of the underlying link characteristics
Shah et al Expires August 2008 [Page 18]
Draft-ietf-l2vpn-arp-mediation-09.txt
and behave accordingly when establishing neighbor adjacencies,
representing the network topology, and passing protocol packets.
8.1. OSPF
The OSPF protocol treats a broadcast link type with a special
procedure that engages in neighbor discovery to elect a
designated and a backup designated router (DR and BDR
respectively) with which each other router on the link forms
adjacencies. However, these procedures are neither applicable
nor understood by OSPF running on a point-to-point link. By
cross-connecting two neighbors with disparate link types, an IP
L2 interworking L2VPN may experience connectivity issues.
Additionally, the link type specified in the router LSA will not
match for the two cross-connected routers.
Finally, each OSPF router generates network LSAs when connected
to a broadcast link such as Ethernet, receipt of which by an
OSPF router which believes itself to be connected to a point-to-
point link further adds to the confusion.
Fortunately, the OSPF protocol provides a configuration option
(ospfIfType), whereby OSPF will treat the underlying physical
broadcast link as a point-to-point link.
It is strongly recommended that all OSPF protocols on CE devices
connected to Ethernet interfaces use this configuration option
when attached to a PE that is participating in an IP L2
Interworking VPN.
8.2. RIP
RIP protocol broadcasts RIP advertisements every 30 seconds. If
the multicast/broadcast traffic snooping mechanism is used as
described in section 5.1, the attached PE can learn the local CE
router's IP address from the IP header of its advertisements. No
special configuration is required for RIP in this type of Layer
2 IP Interworking L2VPN.
8.3. IS-IS
Shah et al Expires August 2008 [Page 19]
Draft-ietf-l2vpn-arp-mediation-09.txt
The IS-IS protocol does not encapsulate its PDUs in IP, and
hence cannot be supported in IP L2 Interworking L2VPNs.
9. Multi-domain considerations
In a back-to-back configuration, when two PEs are connected with
Ethernet, the ARP proxy function has limited application as
there is no local CE.
|
Network A | Network B
CE-1 <---> PE-1 <---> PE-2 <===> PE-3 <---> PE-4 <---> CE-2
ATM LDP ETH LDP ETH
PW-1 PW-2
Consider a Multi-domain network topology as shown above where PW
segment 1 (PE1<->PE2) is in network A and PW segment 2 (PE3<-
>PE4) is in network B. In this configuration CE1 is connected to
PE1 and CE2 is connected to PE4. PE2 on network A is directly
connected to PE3 in network B with Ethernet. In this
configuration there needs to be a mechanism for PE2 and PE3 to
learn IP addresses of the CEs present in each other's network.
The two options to do this are as follows.
o 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.
Shah et al Expires August 2008 [Page 20]
Draft-ietf-l2vpn-arp-mediation-09.txt
o In the second option, PE2 and PE3 use gratuitous ARP which
eliminates configuration of IP addresses of the CEs. In
this scheme, when PE2 learns the IP address of CE1
(through LDP signaling), PE2 sends a gratuitous ARP to PE3
with the source and destination IP address field set to
CE1's IP address and the source MAC address field set to
PE2's MAC address. When PE3 learns the IP address of CE1
(from the gratuitous ARP), PE3 notifies PE4 of the IP
address of the CE1 through LDP signaling. Similarly, for
the traffic in the opposite direction, when PE3 learns the
IP address of CE2, it sends a gratuitous ARP to PE2. PE2
sends an IP address notification, via LDP, of CE2's IP
address to PE1 using the same procedures described above.
This allows PE2 and PE3 to dynamically learn the IP
addresses of the CEs present in each other's networks.
This is the preferred mode of operation as compared to the
option 1 above.
10. Security Considerations
The security aspect of this solution is addressed for two
planes; control plane and data plane.
10.1. Control plane security
Control plane security pertains to establishing the LDP
connection, and to pseudowire signaling and CE IP address
distribution over that LDP connection. The LDP connection
between two trusted PEs can be achieved by each PE verifying the
incoming connection against the configured address of the peer
and authenticating the LDP messages using MD5 authentication.
Pseudowire signaling between two secure LDP peers do not pose
security issue but mis-wiring could occur due to configuration
error. Some checks, such as, proper pseudowire type and other
pseudowire options may prevent mis-wiring due to configuration
errors.
Learning the IP address of the appropriate CE can be a security
issue. It is expected that the Attachment Circuit to the local
CE will be physically secured. If this is a concern, the PE must
be configured with IP and MAC address of the CE when connected
with Ethernet or IP and virtual circuit information (DLCI or
VPI/VCI when connected over Frame Relay or ATM and IP address
only when connected over PPP). During each ARP/inARP frame
Shah et al Expires August 2008 [Page 21]
Draft-ietf-l2vpn-arp-mediation-09.txt
processing, the PE must verify the received information against
local configuration before forwarding the information to the
remote PE to protect against hijacking the connection.
10.2. Data plane security
The data traffic between CE and PE is not encrypted and it is
possible that in an insecure environment, a malicious user may
tap into the CE to PE connection and generate traffic using the
spoofed destination MAC address on the Ethernet Attachment
Circuit. In order to avoid such hijacking, local PE may verify
the source MAC address of the received frame against the MAC
address of the admitted connection. The frame is forwarded to PW
only when authenticity is verified. When spoofing is detected,
PE must sever the connection with the local CE, tear down the PW
and start over.
11. Acknowledgements
The authors would like to thank Yetik Serbest, Prabhu Kavi,
Bruce Lasley, Mark Lewis, Carlos Pignataro, Shane Amante and
other folks who participated in the discussions related to this
draft.
12. References
12.1. Normative References
[ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address
Resolution protocol: Or Converting Network Protocol
Addresses to 48.bit Ethernet Addresses for Transmission
on Ethernet Hardware".
[INVARP] RFC 2390, T. Bradley et al., "Inverse Address
Resolution Protocol".
[RFC4447] L. Martini et al., "Pseudowire Setup and
Maintenance using LDP", RFC 4447.
[PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo
Wire Edge to Edge Emulation (PWE3)", RFC 4446.
Shah et al Expires August 2008 [Page 22]
Draft-ietf-l2vpn-arp-mediation-09.txt
[RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels"
[RFC 3036] L.Anderssen et al., "LDP Specification"
[RFC 2461] Narten, T., Nordmark, E. and W.Simpson, "Neighbor
Discovery for IP Version(IPv6)", RFC 2461,
December, 1998.
12.2. Informative References
[L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June
2004, work in progress.
[PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
Control Protocol (IPCP)".
[PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address
Resolution".
[RFC 1256] S.Deering, "ICMP Router Discovery Messages".
[RFC 3232] Reynolds and Postel, "Assigned Numbers".
13. Authors' Addresses
Himanshu Shah
35 Nagog Park,
Acton, MA 01720
Email: hshah@ciena.com
Eric Rosen
Cisco Systems
1414 Massachusetts Avenue,
Boxborough, MA 01719
Email: erosen@cisco.com
Waldemar Augustyn
Email: waldemar@wdmsys.com
Giles Heron
Shah et al Expires August 2008 [Page 23]
Draft-ietf-l2vpn-arp-mediation-09.txt
Tellabs
24-28 Easton Steet
High Wycombe
Bucks
HP11 1NT
UK
Email: giles.heron@tellabs.com
Sunil Khandekar and Vach Kompella
Email: sunil@timetra.com
Email: vkompella@timetra.com
Toby Smith
Network Appliance, Inc.
800 Cranberry Woods Drive
Suite 300
Cranberry Township, PA 16066
EMail: tob@netapp.com
Arun Vishwanathan
Force10 Networks
1440 McCarthy Blvd.,
Milpitas, CA 95035
Email: arun@force10networks.com
Andrew G. Malis
Tellabs
1415 West Diehl Road
Naperville, IL 60563
EMail: Andy.Malis@tellabs.com
Steven Wright
Bell South Corp
Email: steven.wright@bellsouth.com
Vasile Radoaca
Email: vasile@westridgenetworks.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Shah et al Expires August 2008 [Page 24]
Draft-ietf-l2vpn-arp-mediation-09.txt
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Shah et al Expires August 2008 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-20 07:41:18 |