draft-ietf-l2vpn-arp-mediation-08.txt   draft-ietf-l2vpn-arp-mediation-09.txt 
L2VPN Working Group Himanshu Shah Ciena Networks L2VPN Working Group Himanshu Shah Ciena Corp
Intended Status: Proposed Standard Eric Rosen Cisco System Intended Status: Proposed Standard Eric Rosen Cisco System
Internet Draft Giles Heron Tellabs Internet Draft Giles Heron BT
Vach Kompella Alcatel Vach Kompella Alcatel/lucent
Expires: January 2008
February 2008
Expires: August 2008
ARP Mediation for IP Interworking of Layer 2 VPN ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-08.txt draft-ietf-l2vpn-arp-mediation-09.txt
Status of this Memo Status of this Memo
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.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
skipping to change at page 1, line 37 skipping to change at page 1, line 39
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 2008. This Internet-Draft will expire on August 2008.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
Abstract Abstract
The VPWS service [L2VPN-FRM] provides point-to-point connections The VPWS service [L2VPN-FRM] provides point-to-point connections
between pairs of Customer Edge (CE) devices. It does so by between pairs of Customer Edge (CE) devices. It does so by
binding two Attachment Circuits (each connecting a CE device binding two Attachment Circuits (each connecting a CE device
with a Provider Edge, PE, device) to a pseudowire (connecting with a Provider Edge, PE, device) to a pseudowire (connecting
the two PEs). In general, the Attachment Circuits must be of the two PEs). In general, the Attachment Circuits must be of
the same technology (e.g., both Ethernet, both ATM), and the the same technology (e.g., both Ethernet, both ATM), and the
pseudowire must carry the frames of that technology. However, pseudowire must carry the frames of that technology. However,
skipping to change at page 3, line 4 skipping to change at page 3, line 4
5. IP Address Discovery Mechanisms.............................6 5. IP Address Discovery Mechanisms.............................6
5.1. Discovery of IP Addresses of Locally Attached IPv4 CE 5.1. Discovery of IP Addresses of Locally Attached IPv4 CE
Devices.....................................................7 Devices.....................................................7
5.1.1. Monitoring Local Traffic..........................7 5.1.1. Monitoring Local Traffic..........................7
5.1.2. CE Devices Using ARP..............................7 5.1.2. CE Devices Using ARP..............................7
5.1.3. CE Devices Using Inverse ARP......................8 5.1.3. CE Devices Using Inverse ARP......................8
5.1.4. CE Devices Using PPP..............................9 5.1.4. CE Devices Using PPP..............................9
5.1.5. Router Discovery method..........................10 5.1.5. Router Discovery method..........................10
5.1.6. Manual Configuration.............................10 5.1.6. Manual Configuration.............................10
5.2. How a CE Learns the IPv4 address of a remote CE.......10 5.2. How a CE Learns the IPv4 address of a remote CE.......10
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
5.2.1. CE Devices Using ARP.............................10 5.2.1. CE Devices Using ARP.............................10
5.2.2. CE Devices Using Inverse ARP.....................11 5.2.2. CE Devices Using Inverse ARP.....................11
5.2.3. CE Devices Using PPP.............................11 5.2.3. CE Devices Using PPP.............................11
5.3. Discovery of IP Addresses of Locally Attached IPv6 CE 5.3. Discovery of IP Addresses of Locally Attached IPv6 CE
Devices [RFC 2461].........................................11 Devices [RFC 2461].........................................11
5.3.1. Monitoring Local Traffic.........................11 5.3.1. Monitoring Local Traffic.........................11
5.3.2. CE Devices Using Neighbor Discovery..............12 5.3.2. CE Devices Using Neighbor Discovery..............12
5.3.3. CE Devices Using Inverse Neighbor Discovery......13 5.3.3. CE Devices Using Inverse Neighbor Discovery......13
5.3.4. Manual Configuration.............................13 5.3.4. Manual Configuration.............................13
skipping to change at page 3, line 46 skipping to change at page 3, line 46
Full Copyright Statement......................................24 Full Copyright Statement......................................24
Intellectual Property.........................................25 Intellectual Property.........................................25
1. Contributing Authors 1. Contributing Authors
This document is the combined effort of the following This document is the combined effort of the following
individuals and many others who have carefully reviewed the individuals and many others who have carefully reviewed the
document and provided the technical clarifications. document and provided the technical clarifications.
W. Augustyn consultant W. Augustyn consultant
T. Smith Laurel Networks T. Smith Network Appliances
A. Moranganti Big Band Networks A. Moranganti Big Band Networks
S. Khandekar Alcatel S. Khandekar Alcatel/Lucent
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
A. Malis Tellabs A. Malis Verizon
S. Wright Bell South S. Wright Bell South
V. Radoaca consultant V. Radoaca consultant
A. Vishwanathan Force10 Networks A. Vishwanathan Force10 Networks
T. Grigoriu Alcatel T. Grigoriu Alcatel/Lucent
N. Hart Alcatel N. Hart Alcatel/Lucent
S. Amante Level3 S. Amante Level3
2. Introduction 2. 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 Service Provider IP backbone but are presented to the Customer
Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can
carry any Layer 3 protocol, but in many cases, the Layer 3 carry any Layer 3 protocol, but in many cases, the Layer 3
protocol is IP. Thus it makes sense to consider procedures that protocol is IP. Thus it makes sense to consider procedures that
are optimized for IP. are optimized for IP.
skipping to change at page 5, line 4 skipping to change at page 5, line 4
. | . . | .
+-----+ 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 Address Resolution procedure that is specific to that type of
AC. For example, an Ethernet-attached IPv4 CE would use ARP AC. For example, an Ethernet-attached IPv4 CE would use ARP
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
[ARP] and a FR-attached CE might use Inverse ARP [INVARP]. If [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 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, them, even though each AC uses a different Layer 2 technology,
the PEs must intercept and "mediate" the Layer 2 specific the PEs must intercept and "mediate" the Layer 2 specific
address resolution procedures. address resolution procedures.
In this draft, we specify the procedures for VPWS services, In this draft, we specify the procedures for VPWS services,
which the PEs must implement in order to mediate the IP address which the PEs must implement in order to mediate the IP address
resolution mechanism. We call these procedures "ARP Mediation". resolution mechanism. We call these procedures "ARP Mediation".
skipping to change at page 6, line 5 skipping to change at page 6, line 5
3. Distribute those IP Addresses to the remote PE 3. Distribute those IP Addresses to the remote PE
4. Notify the locally attached CE of the IP address of the 4. Notify the locally attached CE of the IP address of the
remote CE. remote CE.
5. Respond appropriately to ARP, Inverse ARP, Neighbor 5. Respond appropriately to ARP, Inverse ARP, Neighbor
Discovery and Inverse Neighbor Discovery requests from Discovery and Inverse Neighbor Discovery requests from
local CE device, using IP address of remote CE and local CE device, using IP address of remote CE and
hardware address of local PE. hardware address of local PE.
This information is gathered using the mechanisms described in This information is gathered using the mechanisms described in
the following sections. the following sections.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
4. 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 Attachment Circuit with the IP Layer 2 Transport pseudowire the Attachment Circuit with the IP Layer 2 Transport pseudowire
that carries IP datagrams as the payload. The ingress PE removes that carries IP datagrams as the payload. The ingress PE removes
the data link header of its local Attachment Circuit and the data link header of its local Attachment Circuit and
transmits the payload (an IP packet) over the pseudowire with or transmits the payload (an IP packet) over the pseudowire with or
without the optional control word. In some cases, multiple data without the optional control word. In some cases, multiple data
link headers may exist, such as bridged Ethernet PDU on ATM link headers may exist, such as bridged Ethernet PDU on ATM
skipping to change at page 7, line 4 skipping to change at page 7, line 4
only broadcast/multicast IP frames are propagated between the only broadcast/multicast IP frames are propagated between the
Attachment Circuit and pseudowire; unicast IP datagrams are Attachment Circuit and pseudowire; unicast IP datagrams are
dropped. The IP destination address is used to classify dropped. The IP destination address is used to classify
unicast/multicast packets. unicast/multicast packets.
The unicast IP frames are propagated between AC and pseudowire The unicast IP frames are propagated between AC and pseudowire
only when CE IP devices on both Attachment Circuits have been only when CE IP devices on both Attachment Circuits have been
discovered, notified and proxy functions have completed. discovered, notified and proxy functions have completed.
5.1. Discovery of IP Addresses of Locally Attached IPv4 CE Devices 5.1. Discovery of IP Addresses of Locally Attached IPv4 CE Devices
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
5.1.1. Monitoring Local Traffic 5.1.1. Monitoring Local Traffic
The PE devices may learn the IP addresses of the locally The PE devices may learn the IP addresses of the locally
attached CEs from any IP traffic, such as link local multicast 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 packets (e.g., destined to 224.0.0.x), and are not restricted to
the operations below. the operations below.
5.1.2. CE Devices Using ARP 5.1.2. CE Devices Using ARP
skipping to change at page 8, line 5 skipping to change at page 8, line 5
o Wait to learn the IP address of the remote CE (through PW o Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending signaling) and then select the local CE that is sending
the request for IP address of the remote CE. the request for IP address of the remote CE.
o Augment cross checking with the local IP address learned o Augment cross checking with the local IP address learned
through listening of link local multicast packets (as per through listening of link local multicast packets (as per
section 5.1.1 above) section 5.1.1 above)
o Augment cross checking with the local IP address learned o Augment cross checking with the local IP address learned
through the Router Discovery protocol (as described below through the Router Discovery protocol (as described below
in section 5.1.5). in section 5.1.5).
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
o There is still a possibility that the local PE may not o There is still a possibility that the local PE may not
receive an IP address advertisement from the remote PE and receive an IP address advertisement from the remote PE and
there may exist multiple local IP routers that attempt to there may exist multiple local IP routers that attempt to
'connect' to remote CEs. In this situation, the local PE 'connect' to remote CEs. In this situation, the local PE
may use some other criteria to select one IP device from may use some other criteria to select one IP device from
many (such as "the first ARP received"), or an operator many (such as "the first ARP received"), or an operator
may configure the IP address of local CE. Note that the may configure the IP address of local CE. Note that the
operator does not have to configure the IP address of the operator does not have to configure the IP address of the
remote CE (as that would be learned through pseudowire remote CE (as that would be learned through pseudowire
skipping to change at page 9, line 4 skipping to change at page 9, line 4
5.1.3. CE Devices Using Inverse ARP 5.1.3. CE Devices Using Inverse ARP
If a CE device uses Inverse ARP to determine the IP address of If a CE device uses Inverse ARP to determine the IP address of
its neighbor, the attached PE processes the Inverse ARP request its neighbor, the attached PE processes the Inverse ARP request
from the Attachment Circuit and responds with an Inverse ARP from the Attachment Circuit and responds with an Inverse ARP
reply containing the IP address of the remote CE, if the address 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 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 remote CE, it does not respond, but notes the IP address of the
local CE and the circuit information. Subsequently, when the IP local CE and the circuit information. Subsequently, when the IP
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
address of the remote CE becomes available, the PE may initiate address of the remote CE becomes available, the PE may initiate
the Inverse ARP request as a means of notifying the IP address the Inverse ARP request as a means of notifying the IP address
of the remote CE to the local CE. of the remote CE to the local CE.
This is the typical mode of operation for Frame Relay and ATM This is the typical mode of operation for Frame Relay and ATM
Attachment Circuits. If the CE does not use Inverse ARP, the PE Attachment Circuits. If the CE does not use Inverse ARP, the PE
can still discover the IP address of local CE using the can still discover the IP address of local CE using the
mechanisms described in section 5.1.1 and 5.1.5 mechanisms described in section 5.1.1 and 5.1.5
skipping to change at page 10, line 5 skipping to change at page 10, line 5
Address option, it responds with a Configure-Ack. In this Address option, it responds with a Configure-Ack. In this
case the PE is unable to learn the IP address of the local case the PE is unable to learn the IP address of the local
CE using IPCP and hence must rely on other means as 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 described in sections 5.1.1 and 5.1.5. Note that in order
to employ other learning mechanisms, the IPCP negotiations to employ other learning mechanisms, the IPCP negotiations
must have reached the open state. must have reached the open state.
o If the PE does not know the IP address of the remote CE, o If the PE does not know the IP address of the remote CE,
it sends a Configure-Request without the IP-Address it sends a Configure-Request without the IP-Address
option. option.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
o If the PE knows the IP address of the remote CE, it sends o If the PE knows the IP address of the remote CE, it sends
a Configure-Request with the IP-Address option containing a Configure-Request with the IP-Address option containing
the IP address of the remote CE. the IP address of the remote CE.
The IPCP IP-Address option MAY be negotiated between the PE and The IPCP IP-Address option MAY be negotiated between the PE and
the local CE device. Configuration of other IPCP options MAY be the local CE device. Configuration of other IPCP options MAY be
rejected. Other NCPs, with the exception of the Compression rejected. Other NCPs, with the exception of the Compression
Control Protocol (CCP) and Encryption Control Protocol (ECP), Control Protocol (CCP) and Encryption Control Protocol (ECP),
MUST be rejected. The PE device MAY reject configuration of the MUST be rejected. The PE device MAY reject configuration of the
skipping to change at page 11, line 4 skipping to change at page 11, line 4
Once the local PE has received the IP address information of the Once the local PE has received the IP address information of the
remote CE from the remote PE, it will either initiate an address remote CE from the remote PE, it will either initiate an address
resolution request or respond to an outstanding request from the resolution request or respond to an outstanding request from the
attached CE device. attached CE device.
5.2.1. CE Devices Using ARP 5.2.1. CE Devices Using ARP
When the PE learns IP address of the remote CE as described in When the PE learns IP address of the remote CE as described in
section 6.1 and 6.2, it may or may not already know IP address section 6.1 and 6.2, it may or may not already know IP address
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
of the local CE. If the IP address is not known, the PE must 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 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 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 CE is known, the PE may choose to generate an unsolicited ARP
message to notify the local CE about the binding of the IP message to notify the local CE about the binding of the IP
address of the remote CE with the PE's own MAC address. address of the remote CE with the PE's own MAC address.
When the local CE generates an ARP request, the PE must proxy When the local CE generates an ARP request, the PE must proxy
the ARP response [PROXY-ARP] using its own MAC address as the the ARP response [PROXY-ARP] using its own MAC address as the
skipping to change at page 12, line 5 skipping to change at page 12, line 5
5.3. Discovery of IP Addresses of Locally Attached IPv6 CE Devices 5.3. Discovery of IP Addresses of Locally Attached IPv6 CE Devices
[RFC 2461] [RFC 2461]
5.3.1. Monitoring Local Traffic 5.3.1. Monitoring Local Traffic
The PE devices may learn the IP addresses of the locally The PE devices may learn the IP addresses of the locally
attached CEs from any IP traffic, such as link local multicast attached CEs from any IP traffic, such as link local multicast
packets (e.g., destined to FF02::x), and are not restricted to packets (e.g., destined to FF02::x), and are not restricted to
the operations below. the operations below.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
5.3.2. CE Devices Using Neighbor Discovery 5.3.2. CE Devices Using Neighbor Discovery
If a CE device uses Neighbor Discovery to determine the IP If a CE device uses Neighbor Discovery to determine the IP
address to MAC address binding of its neighbor, the PE processes address to MAC address binding of its neighbor, the PE processes
the messages to learn the IP address of local CE for the local the messages to learn the IP address of local CE for the local
Attachment Circuit. Attachment Circuit.
If the PE receives a Neighbor Solicitation message, and the If the PE receives a Neighbor Solicitation message, and the
source IP address of the message is not the unspecified address, source IP address of the message is not the unspecified address,
skipping to change at page 13, line 5 skipping to change at page 13, line 5
for the given Attachment Circuit, the local PE responds with its for the given Attachment Circuit, the local PE responds with its
own link-layer address to any subsequent Neighbor Solicitation own link-layer address to any subsequent Neighbor Solicitation
and Router Solicitation requests from the local CE with a and Router Solicitation requests from the local CE with a
destination IP address matching the IP address of the remote CE. 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 The local PE signals the IP addresses of the CE to the remote PE
and may initiate an unsolicited Router Advertisment to notify and may initiate an unsolicited Router Advertisment to notify
the IP address to link-layer address binding for the remote CE the IP address to link-layer address binding for the remote CE
to local CE (again using its own link-layer address). to local CE (again using its own link-layer address).
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
Once the ARP mediation function is completed (i.e. the PE device Once the ARP mediation function is completed (i.e. the PE device
knows both the local and remote CE IP addresses), unicast IP knows both the local and remote CE IP addresses), unicast IP
frames are propagated between the AC and the established PW. frames are propagated between the AC and the established PW.
The PE will periodically generate Neighbor Solicitation messages The PE will periodically generate Neighbor Solicitation messages
for the IP address of the CE as a means of verifying the for the IP address of the CE as a means of verifying the
continued existence of the address and its MAC address binding. continued existence of the address and its MAC address binding.
The absence of a response from the CE device for a given number 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 of retries could be used as a trigger for withdrawal of the IP
skipping to change at page 14, line 4 skipping to change at page 14, line 4
section 5.3. above. In such cases manual configuration MAY be section 5.3. above. In such cases manual configuration MAY be
used. All implementations of this draft MUST support manual used. All implementations of this draft MUST support manual
configuration of the IP address of the local CE. configuration of the IP address of the local CE.
5.4. How a CE Learns the IPv6 address of a remote 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 Once the local PE has received the IP address information of the
remote CE from the remote PE, it will either initiate an address remote CE from the remote PE, it will either initiate an address
resolution request or respond to an outstanding request from the resolution request or respond to an outstanding request from the
attached CE device. The PE uses the Address List TLV to attached CE device. The PE uses the Address List TLV to
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
communicate the IP addresses. If the PE has received no Router communicate the IP addresses. If the PE has received no Router
Advertisements from its local CE, it should specify the single Advertisements from its local CE, it should specify the single
CE IP address it has received. If the PE has received a Router CE IP address it has received. If the PE has received a Router
Advertisement, it should specify an Address List in which the Advertisement, it should specify an Address List in which the
first entry is the source interface address and the remaining first entry is the source interface address and the remaining
entries are taken from the list of on-link addresses. entries are taken from the list of on-link addresses.
5.4.1. CE Devices Using Neighbor Discovery 5.4.1. CE Devices Using Neighbor Discovery
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Solicitation. It should be noted, that the PE might never Solicitation. It should be noted, that the PE might never
receive the response to its own solicitation, nor see any receive the response to its own solicitation, nor see any
Inverse Neighbor Discovery Solicitation from the CE, in cases Inverse Neighbor Discovery Solicitation from the CE, in cases
where the CE is pre-configured with the IP address of the remote 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 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 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 IP address of his neighbor. The PE may also generate a Router
Advertisement message in the same way as specified in Advertisement message in the same way as specified in
section 5.4.1. section 5.4.1.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
6. CE IP Address Signaling between PEs 6. CE IP Address Signaling between PEs
6.1. When to Signal an IP address of a CE 6.1. When to Signal an IP address of a CE
A PE device advertises the IP address of the attached CE only A PE device advertises the IP address of the attached CE only
when the encapsulation type of the pseudowire is IP Layer2 when the encapsulation type of the pseudowire is IP Layer2
Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is
quite possible that the IP address of a CE device is not quite possible that the IP address of a CE device is not
available at the time the PW labels are signaled. For example, available at the time the PW labels are signaled. For example,
skipping to change at page 16, line 4 skipping to change at page 16, line 4
[RFC4447] uses Label Distribution Protocol (LDP) transport to [RFC4447] uses Label Distribution Protocol (LDP) transport to
exchange PW FECs in the Label Mapping message in the Downstream exchange PW FECs 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 Generalized ID FEC elements and has some common fields between
them. The discussions below refer to these common fields for IP them. The discussions below refer to these common fields for IP
L2 Interworking encapsulation. L2 Interworking encapsulation.
In addition to PW-FEC, this document defines an IP address list In addition to PW-FEC, this document defines an IP address list
TLV that must be included in the optional parameter field of the TLV that must be included in the optional parameter field of the
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
Label Mapping message when advertising the PW FEC for the IP Label Mapping message when advertising the PW FEC for the IP
Layer2 Transport. The use of optional parameters in the Label Layer2 Transport. The use of optional parameters in the Label
Mapping message to extend the attributes of the PW FEC is Mapping message to extend the attributes of the PW FEC is
specified in the [RFC4447]. specified in the [RFC4447].
As defined in [RFC4447], when processing a received PW FEC, the As defined in [RFC4447], when processing a received PW FEC, the
PE matches the PW ID and PW type with the locally configured PW 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 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 Layer2 Transport the PE further checks for the presence of an
skipping to change at page 17, line 4 skipping to change at page 17, line 4
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 | IP Address of CE ~ | Address Family | IP Address of CE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Address of CE | ~ IP Address of CE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
Length Length
When Address Family is IPV4, Length is equal to 6 bytes; 2 When Address Family is IPV4, Length is equal to 6 bytes; 2
bytes for address family and 4 bytes of IP address. When bytes for address family and 4 bytes of IP address. When
Address Family is IPV6, Length is equal to (2 + (n * 16)); Address Family is IPV6, Length is equal to (2 + (n * 16));
2 bytes for address family and 16 bytes for each IPv6 2 bytes for address family and 16 bytes for each IPv6
address. address.
Address Family Address Family
Two octet quantity containing a value from the ADDRESS Two octet quantity containing a value from the ADDRESS
skipping to change at page 18, line 5 skipping to change at page 18, line 5
device. Any non-zero value of the IP address field denotes the device. Any non-zero value of the IP address field denotes the
IP address of advertising PE's attached CE device. IP address of advertising PE's attached CE device.
The IP address of the CE is also supplied in the optional The IP address of the CE is also supplied in the optional
parameters field of the LDP Notification message along with the parameters field of the LDP Notification message along with the
PW FEC. The LDP Notification message is used to signal any PW FEC. The LDP Notification message is used to signal any
change in the status of the CE's IP address. change in the status of the CE's IP address.
The encoding of the LDP Notification message is as follows. The encoding of the LDP Notification message is as follows.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 4 skipping to change at page 19, line 4
0x0000002D "IP Address of the CE is absent" 0x0000002D "IP Address of the CE is absent"
0x0000002E "IP Address type mismatch" 0x0000002E "IP Address type mismatch"
8. Use of IGPs with IP L2 Interworking L2VPNs 8. Use of IGPs with IP L2 Interworking L2VPNs
In an IP L2 interworking L2VPN, when an IGP on a CE connected to 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 a broadcast link is cross-connected with an IGP on a CE
connected to a point-to-point link, there are routing protocol connected to a point-to-point link, there are routing protocol
related issues that must be addressed. The link state routing related issues that must be addressed. The link state routing
protocols are cognizant of the underlying link characteristics protocols are cognizant of the underlying link characteristics
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
and behave accordingly when establishing neighbor adjacencies, and behave accordingly when establishing neighbor adjacencies,
representing the network topology, and passing protocol packets. representing the network topology, and passing protocol packets.
8.1. OSPF 8.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 procedure that engages in neighbor discovery to elect a
designated and a backup designated router (DR and BDR designated and a backup designated router (DR and BDR
respectively) with which each other router on the link forms respectively) with which each other router on the link forms
skipping to change at page 20, line 4 skipping to change at page 20, line 4
8.2. RIP 8.2. RIP
RIP protocol broadcasts RIP advertisements every 30 seconds. If RIP protocol broadcasts RIP advertisements every 30 seconds. If
the multicast/broadcast traffic snooping mechanism is used as the multicast/broadcast traffic snooping mechanism is used as
described in section 5.1, the attached PE can learn the local CE 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 router's IP address from the IP header of its advertisements. No
special configuration is required for RIP in this type of Layer special configuration is required for RIP in this type of Layer
2 IP Interworking L2VPN. 2 IP Interworking L2VPN.
8.3. IS-IS 8.3. IS-IS
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
The IS-IS protocol does not encapsulate its PDUs in IP, and The IS-IS protocol does not encapsulate its PDUs in IP, and
hence cannot be supported in IP L2 Interworking L2VPNs. hence cannot be supported in IP L2 Interworking L2VPNs.
9. Multi-domain considerations 9. Multi-domain considerations
In a back-to-back configuration, when two PEs are connected with In a back-to-back configuration, when two PEs are connected with
Ethernet, the ARP proxy function has limited application as Ethernet, the ARP proxy function has limited application as
there is no local CE. there is no local CE.
| |
Network A | Network B Network A | Network B
CE-1 <---> PE-1 <---> PE-2 <===> PE-3 <---> PE-4 <---> CE-2 CE-1 <---> PE-1 <---> PE-2 <===> PE-3 <---> PE-4 <---> CE-2
ATM LDP ETH LDP ETH ATM LDP ETH LDP ETH
PW-1 PW-2 PW-1 PW-2
Consider a Multi-domain network topology as shown above where PW Consider a Multi-domain network topology as shown above where PW
segment 1 (PE1<->PE2) is in network A and PW segment 2 (PE3<- 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 >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 PE1 and CE2 is connected to PE4. PE2 on network A is directly
connected to PE3 in network B with Ethernet. In this connected to PE3 in network B with Ethernet. In this
configuration there needs to be a mechanism for PE2 and PE3 to configuration there needs to be a mechanism for PE2 and PE3 to
learn IP addresses of the CEs present in each other’s network. learn IP addresses of the CEs present in each other's network.
The two options to do this are as follows. The two options to do this are as follows.
o Configure CE2’s IP address as a local CE’s IP address at 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. PE2 and CE1's IP address as local CE's IP address at PE3.
Additionally, PE2 and PE3 are required to generate ARP Additionally, PE2 and PE3 are required to generate ARP
requests using their own MAC addresses as the source requests using their own MAC addresses as the source
address. These PEs are in effect proxying for CEs present address. These PEs are in effect proxying for CEs present
in the each other’s network. This is not a desirable in the each other's network. This is not a desirable
option as it requires configuration of IP address of a CE option as it requires configuration of IP address of a CE
that is present in others (possibly other service that is present in others (possibly other service
provider’s) network. provider's) network.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
o In the second option, PE2 and PE3 use gratuitous ARP which o In the second option, PE2 and PE3 use gratuitous ARP which
eliminates configuration of IP addresses of the CEs. In eliminates configuration of IP addresses of the CEs. In
this scheme, when PE2 learns the IP address of CE1 this scheme, when PE2 learns the IP address of CE1
(through LDP signaling), PE2 sends a gratuitous ARP to PE3 (through LDP signaling), PE2 sends a gratuitous ARP to PE3
with the source and destination IP address field set to with the source and destination IP address field set to
CE1’s IP address and the source MAC 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 PE2's MAC address. When PE3 learns the IP address of CE1
(from the gratuitous ARP), PE3 notifies PE4 of the IP (from the gratuitous ARP), PE3 notifies PE4 of the IP
address of the CE1 through LDP signaling. Similarly, for address of the CE1 through LDP signaling. Similarly, for
the traffic in the opposite direction, when PE3 learns the the traffic in the opposite direction, when PE3 learns the
IP address of CE2, it sends a gratuitous ARP to PE2. PE2 IP address of CE2, it sends a gratuitous ARP to PE2. PE2
sends an IP address notification, via LDP, of CE2’s IP sends an IP address notification, via LDP, of CE2's IP
address to PE1 using the same procedures described above. address to PE1 using the same procedures described above.
This allows PE2 and PE3 to dynamically learn the IP This allows PE2 and PE3 to dynamically learn the IP
addresses of the CEs present in each other’s networks. addresses of the CEs present in each other's networks.
This is the preferred mode of operation as compared to the This is the preferred mode of operation as compared to the
option 1 above. option 1 above.
10. Security Considerations 10. Security Considerations
The security aspect of this solution is addressed for two The security aspect of this solution is addressed for two
planes; control plane and data plane. planes; control plane and data plane.
10.1. Control plane security 10.1. Control plane security
skipping to change at page 22, line 4 skipping to change at page 22, line 4
pseudowire options may prevent mis-wiring due to configuration pseudowire options may prevent mis-wiring due to configuration
errors. errors.
Learning the IP address of the appropriate CE can be a security Learning the IP address of the appropriate CE can be a security
issue. It is expected that the Attachment Circuit to the local issue. It is expected that the Attachment Circuit to the local
CE will be physically secured. If this is a concern, the PE must 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 be configured with IP and MAC address of the CE when connected
with Ethernet or IP and virtual circuit information (DLCI or with Ethernet or IP and virtual circuit information (DLCI or
VPI/VCI when connected over Frame Relay or ATM and IP address VPI/VCI when connected over Frame Relay or ATM and IP address
only when connected over PPP). During each ARP/inARP frame only when connected over PPP). During each ARP/inARP frame
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
processing, the PE must verify the received information against processing, the PE must verify the received information against
local configuration before forwarding the information to the local configuration before forwarding the information to the
remote PE to protect against hijacking the connection. remote PE to protect against hijacking the connection.
10.2. Data plane security 10.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 possible that in an insecure environment, a malicious user may
tap into the CE to PE connection and generate traffic using the tap into the CE to PE connection and generate traffic using the
skipping to change at page 23, line 5 skipping to change at page 23, line 5
Addresses to 48.bit Ethernet Addresses for Transmission Addresses to 48.bit Ethernet Addresses for Transmission
on Ethernet Hardware". on Ethernet Hardware".
[INVARP] RFC 2390, T. Bradley et al., "Inverse Address [INVARP] RFC 2390, T. Bradley et al., "Inverse Address
Resolution Protocol". Resolution Protocol".
[RFC4447] L. Martini et al., "Pseudowire Setup and [RFC4447] L. Martini et al., "Pseudowire Setup and
Maintenance using LDP", RFC 4447. Maintenance using LDP", RFC 4447.
[PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo
Wire Edge to Edge Emulation (PWE3)", RFC 4446. Wire Edge to Edge Emulation (PWE3)", RFC 4446.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
[RFC 2119] S. Bradner, "Key words for use in RFCs to indicate [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels" requirement levels"
[RFC 3036] L.Anderssen et al., "LDP Specification" [RFC 3036] L.Anderssen et al., "LDP Specification"
[RFC 2461] Narten, T., Nordmark, E. and W.Simpson, "Neighbor [RFC 2461] Narten, T., Nordmark, E. and W.Simpson, "Neighbor
Discovery for IP Version(IPv6)", RFC 2461, Discovery for IP Version(IPv6)", RFC 2461,
December, 1998. December, 1998.
12.2. Informative References 12.2. Informative References
skipping to change at page 24, line 4 skipping to change at page 24, line 4
Eric Rosen Eric Rosen
Cisco Systems Cisco Systems
1414 Massachusetts Avenue, 1414 Massachusetts Avenue,
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Waldemar Augustyn Waldemar Augustyn
Email: waldemar@wdmsys.com Email: waldemar@wdmsys.com
Giles Heron Giles Heron
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
Tellabs Tellabs
24-28 Easton Steet 24-28 Easton Steet
High Wycombe High Wycombe
Bucks Bucks
HP11 1NT HP11 1NT
UK UK
Email: giles.heron@tellabs.com Email: giles.heron@tellabs.com
Sunil Khandekar and Vach Kompella Sunil Khandekar and Vach Kompella
skipping to change at page 25, line 5 skipping to change at page 25, line 5
Vasile Radoaca Vasile Radoaca
Email: vasile@westridgenetworks.com Email: vasile@westridgenetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights. therein, the authors retain all their rights.
Draft-ietf-l2vpn-arp-mediation-08.txt Draft-ietf-l2vpn-arp-mediation-09.txt
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 38 change blocks. 
44 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/