draft-ietf-l2vpn-arp-mediation-03.txt   draft-ietf-l2vpn-arp-mediation-04.txt 
L2VPN Working Group H. Shah Ciena Corp L2VPN Working Group H. Shah Ciena Corp
Internet Draft E. Rosen Cisco Systems Internet Draft E. Rosen Cisco Systems
G. Heron Tellabs G. Heron Tellabs
August 2005 V. Kompella Alcatel October 2005 V. Kompella Alcatel
Expires: February 2006 Expires: April 2006
ARP Mediation for IP Interworking of Layer 2 VPN ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
Sections 5 and 6 of RFC3667 and Section 5 of RFC3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IPR Disclosure Acknowledgement IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that
applicable patent or other IPR claims of which he or she is aware any applicable patent or other IPR claims of which he or she is
have been or will be disclosed, and any of which he or she becomes aware have been or will be disclosed, and any of which he or she
aware will be disclosed, in accordance with Section 6 of BCP 79. becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Abstract Abstract
The VPWS service [L2VPN Framework] provides point-to-point The VPWS service [L2VPN Framework] provides point-to-point
connections between pairs of Customer Edge (CE) devices. It does connections between pairs of Customer Edge (CE) devices. It does
so by binding two Attachment Circuits (each connecting a CE device so by binding two Attachment Circuits (each connecting a CE device
with a Provider Edge, PE, device) to a pseudo-wire (connecting the with a Provider Edge, PE, device) to a pseudo-wire (connecting the
two PEs). In general, the Attachment Circuits must be of the same two PEs). In general, the Attachment Circuits must be of the same
technology (e.g., both Ethernet, both ATM), and the pseudo-wire technology (e.g., both Ethernet, both ATM), and the pseudo-wire
must carry the frames of that technology. However, if it is known must carry the frames of that technology. However, if it is known
that the frames' payload consists solely of IP datagrams, it is that the frames' payload consists solely of IP datagrams, it is
possible to provide a point-to-point connection in which the possible to provide a point-to-point connection in which the
pseudo-wire connects Attachment Circuits of different technologies. pseudo-wire connects Attachment Circuits of different technologies.
This requires the PEs to perform a function known as "ARP This requires the PEs to perform a function known as "ARP
Mediation". ARP Mediation refers to the process of resolving Layer Mediation". ARP Mediation refers to the process of resolving Layer
2 addresses when different resolution protocols are used on either 2 addresses when different resolution protocols are used on either
draft-ietf-l2vpn-arp-mediation-03.txt
Shah, et. al. Expires April 2006 1
draft-ietf-l2vpn-arp-mediation-04.txt
Attachment Circuit. The methods described in this document are Attachment Circuit. The methods described in this document are
applicable even when the CEs run a routing protocol between them, applicable even when the CEs run a routing protocol between them,
as long as the routing protocol runs over IP. In particular, the as long as the routing protocol runs over IP. In particular, the
applicability of ARP mediation to ISIS is not addressed as IS-IS applicability of ARP mediation to ISIS is not addressed as IS-IS
PDUs are not sent over IP. PDUs are not sent over IP.
Table of Contents Table of Contents
1 .0 Contributing Authors........................................2 1.0 Contributing Authors.........................................2
2 .0 Introduction................................................3 2.0 Introduction.................................................3
3 .0 ARP Mediation (AM) function.................................4 3.0 ARP Mediation (AM) function..................................4
4 .0 IP Layer 2 Interworking Circuit.............................4 4.0 IP Layer 2 Interworking Circuit..............................4
5 .0 Discovery of IP Addresses of Locally Attached CE Device.....4 5.0 Discovery of IP Addresses of Locally Attached CE Device......4
5.1 Monitoring Local Traffic.....................................5 5.1 Monitoring Local Traffic.....................................5
5.2 CE Devices Using ARP.........................................5 5.2 CE Devices Using ARP.........................................5
5.3 CE Devices Using Inverse ARP.................................6 5.3 CE Devices Using Inverse ARP.................................6
5.4 CE Devices Using PPP.........................................7 5.4 CE Devices Using PPP.........................................7
5.5 Router Discovery method......................................7 5.5 Router Discovery method......................................7
6 .0 CE IP Address Signaling between PEs.........................8 6.0 CE IP Address Signaling between PEs..........................8
6.1 When to Signal a CEs IP Address..........................8 6.1 When to Signal an IP address of a CE.........................8
6.2 LDP Based Distribution.......................................8 6.2 LDP Based Distribution.......................................8
6.3 Out-of-band Distribution Configuration......................10 6.3 Out-of-band Distribution Configuration......................10
7 .0 IANA consideration.........................................10 7.0 IANA considerations.........................................10
7.1 LDP Status messages.........................................10 7.1 LDP Status messages.........................................10
8 .0 How a CE Learns the Remote CE's IP address.................11 8.0 How a CE Learns the Remote CE's IP address..................11
8.1 CE Devices Using ARP........................................11 8.1 CE Devices Using ARP........................................11
8.2 CE Devices Using Inverse ARP................................11 8.2 CE Devices Using Inverse ARP................................11
8.3 CE Devices Using PPP........................................11 8.3 CE Devices Using PPP........................................11
9 .0 Use of IGPs with IP L2 Interworking L2VPNs.................12 9.0 Use of IGPs with IP L2 Interworking L2VPNs..................12
9.1 OSPF........................................................12 9.1 OSPF........................................................12
9.2 RIP.........................................................12 9.2 RIP.........................................................12
10 .0 IPV6 Considerations.......................................13 10.0 IPV6 Considerations........................................13
11 .0 Security Considerations...................................13 11.0 Security Considerations....................................13
11.1 Control plane security.....................................13 11.1 Control plane security.....................................13
11.2 Data plane security........................................13 11.2 Data plane security........................................13
12 .0 Acknowledgements..........................................13 12.0 Acknowledgements...........................................13
13 .0 References................................................14 13.0 References.................................................14
13.1 Normative References.......................................14 13.1 Normative References.......................................14
13.2 Informative References.....................................14 13.2 Informative References.....................................14
14 .0 Authors' Addresses........................................14 14.0 Authors' Addresses.........................................14
1.0 Contributing Authors 1.0 Contributing Authors
This document is the combined effort of the following individuals This document is the combined effort of the following individuals
and many others who have carefully reviewed the document and and many others who have carefully reviewed the document and
provided the technical clarifications. provided the technical clarifications.
W. Augustyn consultant W. Augustyn consultant
Shah, et. al. Expires February 2006 2 Shah, et. al. Expires April 2006 2
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
T. Smith Laurel Networks T. Smith Laurel Networks
A. Moranganti Big Band Networks A. Moranganti Big Band Networks
S. Khandekar Alcatel S. Khandekar Alcatel
A. Malis Tellabs A. Malis Tellabs
S. Wright Bell South S. Wright Bell South
V. Radoaca Westridge Networks V. Radoaca Westridge Networks
A. Vishwanathan Force10 Networks A. Vishwanathan Force10 Networks
2.0 Introduction 2.0 Introduction
skipping to change at line 163 skipping to change at line 159
........................ ........................
A CE, which is connected via a given type of AC, may use an IP A CE, which is connected via a given type of AC, may use an IP
Address Resolution procedure that is specific to that type of AC. Address Resolution procedure that is specific to that type of AC.
For example, an Ethernet-attached CE would use ARP, a FR-attached For example, an Ethernet-attached CE would use ARP, a FR-attached
CE might use Inverse ARP. If we are to allow the two CEs to have a CE might use Inverse ARP. If we are to allow the two CEs to have a
Layer 2 connection between them, even though each AC uses a Layer 2 connection between them, even though each AC uses a
different Layer 2 technology, the PEs must intercept and "mediate" different Layer 2 technology, the PEs must intercept and "mediate"
the Layer 2 specific address resolution procedures. the Layer 2 specific address resolution procedures.
Shah, et. al. Expires February 2006 3 Shah, et. al. Expires April 2006 3
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
In this draft, we specify the procedures, which the PEs must In this draft, we specify the procedures, which the PEs must
implement in order to mediate the IP address resolution mechanism. implement in order to mediate the IP address resolution mechanism.
We call these procedures "ARP Mediation". We call these procedures "ARP Mediation".
Consider a Virtual Private Wire Service (VPWS) constructed between Consider a Virtual Private Wire Service (VPWS) constructed between
CE1 and CE2 in the diagram above. If AC1 and AC2 are of different CE1 and CE2 in the diagram above. If AC1 and AC2 are of different
technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR),
then ARP requests coming from CE1 cannot be passed transparently to then ARP requests coming from CE1 cannot be passed transparently to
CE2. PE1 must interpret the meaning of the ARP requests and CE2. PE1 must interpret the meaning of the ARP requests and
skipping to change at line 213 skipping to change at line 209
may exist, such as bridged PDU on ATM AC. In this case, ATM header may exist, such as bridged PDU on ATM AC. In this case, ATM header
as well as the Ethernet header is removed to expose the IP frame. as well as the Ethernet header is removed to expose the IP frame.
The egress PE encapsulates the IP packet with the data link header The egress PE encapsulates the IP packet with the data link header
used on its local Attachment Circuit. used on its local Attachment Circuit.
The encapsulation for the IP Layer 2 Transport pseudo-wire is The encapsulation for the IP Layer 2 Transport pseudo-wire is
described in [PWE3-Control]. described in [PWE3-Control].
5.0 Discovery of IP Addresses of Locally Attached CE Device 5.0 Discovery of IP Addresses of Locally Attached CE Device
Shah, et. al. Expires February 2006 4 Shah, et. al. Expires April 2006 4
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
An IP Layer 2 Interworking Circuit enters monitoring state An IP Layer 2 Interworking Circuit enters monitoring state
immediately after the configuration. During this state it performs immediately after the configuration. During this state it performs
two functions. two functions.
. Discovery of locally attached CE IP device . Discovery of locally attached CE IP device
. Establishment of the PW . Establishment of the PW
The establishment of the PW occurs independently from local CE IP The establishment of the PW occurs independently from local CE IP
address discovery. During the period when the PW has been address discovery. During the period when the PW has been
established but local CE IP device has not been detected, only established but local CE IP device has not been detected, only
skipping to change at line 265 skipping to change at line 261
circuit. In this case, the PE may select the local CE device using circuit. In this case, the PE may select the local CE device using
following criteria. following criteria.
. Wait to learn the IP address of the remote CE (through PW . Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending the signaling) and then select the local CE that is sending the
ARP request for the remote CE's IP address. ARP request for the remote CE's IP address.
. Augment cross checking with the local IP address learned . 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 above) section 5.1 above)
Shah, et. al. Expires February 2006 5 Shah, et. al. Expires April 2006 5
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
. Augment cross checking with the local IP address learned . Augment cross checking with the local IP address learned
through the Router Discovery protocol (as described below in through the Router Discovery protocol (as described below in
section 5.5). section 5.5).
. There is still a possibility that the local PE may not receive . There is still a possibility that the local PE may not receive
an IP address advertisement from the remote PE and there may an IP address advertisement from the remote PE and there may
exist multiple local IP routers that attempt to 'connect' to exist multiple local IP routers that attempt to 'connect' to
remote CEs. In this situation, the local PE may use some other remote CEs. In this situation, the local PE may use some other
criteria to select one IP device from many (such as "the first criteria to select one IP device from many (such as "the first
ARP received"), or an operator may configure the IP address of ARP received"), or an operator may configure the IP address of
skipping to change at line 317 skipping to change at line 313
the remote CE's IP address, if the address is known. If the PE does the remote CE's IP address, if the address is known. If the PE does
not yet have the remote CE's IP address, it does not respond, but not yet have the remote CE's IP address, it does not respond, but
notes the IP address of the local CE and the circuit information. notes the IP address of the local CE and the circuit information.
Subsequently, when the IP address of the remote CE becomes Subsequently, when the IP address of the remote CE becomes
available, the PE may initiate the Inverse ARP request as a means available, the PE may initiate the Inverse ARP request as a means
to notify the local CE about the IP address of the remote CE. to notify the local CE about the IP address of the remote CE.
This is a typical operation for Frame Relay and ATM attachment This is a typical operation for Frame Relay and ATM attachment
circuits. When the CE does not use Inverse ARP, PE could still circuits. When the CE does not use Inverse ARP, PE could still
Shah, et. al. Expires February 2006 6 Shah, et. al. Expires April 2006 6
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
discover the local CEs IP address as described in section 5.1 and discover the IP address of local CE as described in section 5.1 and
5.5. 5.5.
5.4 CE Devices Using PPP 5.4 CE Devices Using PPP
The IP Control Protocol (IPCP) describes a procedure to establish The IP Control Protocol (IPCP) describes a procedure to establish
and configure IP on a point-to-point connection, including the and configure IP on a point-to-point connection, including the
negotiation of IP addresses. When using IP (Routed) mode L2VPN negotiation of IP addresses. When using IP (Routed) mode L2VPN
interworking, PPP negotiation is not performed end-to-end between interworking, PPP negotiation is not performed end-to-end between
CE devices. In this case, PPP negotiation takes place between the CE devices. In this case, PPP negotiation takes place between the
CE device and its local PE device (on the PPP attachment circuit). CE device and its local PE device (on the PPP attachment circuit).
skipping to change at line 368 skipping to change at line 364
The IPCP IP-Address option MAY be negotiated between the PE and the The IPCP IP-Address option MAY be negotiated between the PE and the
local CE device. Configuration of other IPCP option MAY be local CE device. Configuration of other IPCP option MAY be
rejected. Other NCPs, with the exception of the Compression Control rejected. Other NCPs, with the exception of the Compression Control
Protocol (CCP) and Encryption Control Protocol (ECP), MUST be Protocol (CCP) and Encryption Control Protocol (ECP), MUST be
rejected. The PE device MAY reject configuration of the CCP and rejected. The PE device MAY reject configuration of the CCP and
ECP. ECP.
5.5 Router Discovery method 5.5 Router Discovery method
Shah, et. al. Expires February 2006 7 Shah, et. al. Expires April 2006 7
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
In order to learn the IP address of the CE device for a given In order to learn the IP address of the CE device for a given
Attachment Circuit, the PE device may execute Router Discovery Attachment Circuit, the PE device may execute Router Discovery
Protocol [RFC 1256] whereby a Router Discovery Request (ICMP - Protocol [RFC 1256] whereby a Router Discovery Request (ICMP -
router solicitation) message is sent using a source IP address of router solicitation) message is sent using a source IP address of
zero. The IP address of the CE device is extracted from the Router zero. The IP address of the CE device is extracted from the Router
Discovery Response (ICMP - router advertisement) message from the Discovery Response (ICMP - router advertisement) message from the
CE. It is possible that the response contains more than one router CE. It is possible that the response contains more than one router
addresses with the same preference level; in which case, some addresses with the same preference level; in which case, some
heuristics (such as first on the list) is necessary. heuristics (such as first on the list) is necessary.
The use of the Router Discovery method by the PE is optional. The use of the Router Discovery method by the PE is optional.
6.0 CE IP Address Signaling between PEs 6.0 CE IP Address Signaling between PEs
6.1 When to Signal a CE's IP Address 6.1 When to Signal an IP address of a CE
A PE device advertises the IP address of the attached CE only when A PE device advertises the IP address of the attached CE only when
the encapsulation type of the pseudo-wire is IP Layer2 Transport the encapsulation type of the pseudo-wire is IP Layer2 Transport
(the value 0x0000B, as defined in [PWE3-IANA]). It is quite (the value 0x0000B, as defined in [PWE3-IANA]). It is quite
possible that the IP address of a CE device is not available at the possible that the IP address of a CE device is not available at the
time the PW labels are signaled. For example, in Frame Relay the CE time the PW labels are signaled. For example, in Frame Relay the CE
device sends an inverse ARP request only when the DLCI is active; device sends an inverse ARP request only when the DLCI is active;
if the PE signals the DLCI to be active only when it has received 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 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 and egg situation arises. In order to avoid such problems, the PE
must be prepared to advertise the PW FEC before the CE's IP address must be prepared to advertise the PW FEC before the CE's IP address
is known. When the IP address of the CE device does become is known. When the IP address of the CE device does become
available, the PE re-advertises the PW FEC along with the CE's IP available, the PE re-advertises the PW FEC along with the CE's IP
address. address.
Similarly, if the PE detects a CE's IP address is no longer valid Similarly, if the PE detects that an IP address of a CE is no
(by methods described above), the PE must re-advertise the PW FEC longer valid (by methods described above), the PE must
with null IP address to denote the withdrawal of the CE's IP re-advertise the PW FEC with null IP address to denote the
address. The receiving PE then waits for notification of the remote withdrawal of the CE's IP address. The receiving PE then waits for
IP address. During this period, propagation of unicast IP traffic notification of the remote IP address. During this period,
is suspended, but multicast IP traffic can continue to flow between propagation of unicast IP traffic is suspended, but multicast IP
the AC and the pseudo-wire. traffic can continue to flow between the AC and the pseudo-wire.
If two CE devices are locally attached to the PE where one CE is If two CE devices are locally attached to the PE where one CE is
connected to an Ethernet port and the other to a Frame Relay port, connected to an Ethernet port and the other to a Frame Relay port,
for example, the IP addresses are learned in the same manner for example, the IP addresses are learned in the same manner
described above. However, since the CE devices are local, the described above. However, since the CE devices are local, the
distribution of IP addresses for these CE devices is a local step. distribution of IP addresses for these CE devices is a local step.
6.2 LDP Based Distribution 6.2 LDP Based Distribution
The [PWE3-Control] uses Label Distribution Protocol (LDP) transport The [PWE3-Control] uses Label Distribution Protocol (LDP) transport
to exchange PW FEC in the Label Mapping message in the Downstream to exchange PW FEC in the Label Mapping message in the Downstream
Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and
Shah, et. al. Expires February 2006 8 Shah, et. al. Expires April 2006 8
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
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 L2 them. The discussions below refer to these common fields for IP L2
Interworking Circuits. Interworking Circuits.
In addition to PW-FEC, this document defines an IP address TLV that In addition to PW-FEC, this document defines an IP address TLV that
must be included in the optional parameter field of the Label must be included in the optional parameter field of the Label
Mapping message when advertising the PW FEC for the IP Layer2 Mapping message when advertising the PW FEC for the IP Layer2
Transport. The use of optional parameters in the Label Mapping Transport. The use of optional parameters in the Label Mapping
message to extend the attributes of the PW FEC is specified in the message to extend the attributes of the PW FEC is specified in the
[PWE3-Control]. [PWE3-Control].
When processing a received PW FEC, the PE matches the PW Id and PW When processing a received PW FEC, the PE matches the PW Id and PW
type with the locally configured PW Id to determine if the PW FEC type with the locally configured PW Id to determine if the PW FEC
is of type IP Layer2 Transport. If there is a match, it further is of type IP Layer2 Transport. If there is a match, it further
checks the presence of IP address TLV in the optional parameter checks the presence of IP address TLV in the optional parameter
field. If absent, a Label Release message is issued with a Status field. If absent, a Label Release message is issued with a Status
Code meaning "IP Address of the CE is absent" [note: Status Code Code meaning "IP Address of the CE is absent" [note: Status Code
0x0000002C is pending IANA allocation] to reject the PW establishment. 0x0000002C is pending IANA allocation] to reject the PW
establishment.
We use the Address List TLV as defined in RFC 3036 to signal the IP We use the Address List TLV as defined in RFC 3036 to signal the IP
address of the local CE. This IP address TLV must be included in address of the local CE. This IP address TLV must be included in
the optional parameter field of the Label Mapping message. the optional parameter field of the Label Mapping message.
Encoding of the IP Address TLV is: Encoding of the IP Address TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length | |0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE's IP Address | | Address Family | CE's IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE's IP Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CE's IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length
When Address Family is IPV4, Length is equal to 6 bytes; When Address Family is IPV4, Length is equal to 6 bytes;
2 bytes for address family and 4 bytes of IP address. 2 bytes for address family and 4 bytes of IP address.
Address Family Address Family
Two octet quantity containing a value from the ADDRESS FAMILY Two octet quantity containing a value from the ADDRESS FAMILY
NUMBERS from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the NUMBERS from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the
address contained in the Address field. address contained in the Address field.
CE's IP Address CE's IP Address
IP address of the CE attached to the advertising PE. The IP address of the CE attached to the advertising PE. The
encoding of the individual address depends on the Address Family. encoding of the individual address depends on the Address Family.
The following address encodings are defined by this version of the The following address encodings are defined by this version of the
protocol: protocol:
Address Family Address Encoding Address Family Address Encoding
Shah, et. al. Expires February 2006 9 Shah, et. al. Expires April 2006 9
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
IPv4 (1) 4 octet full IPv4 address IPv4 (1) 4 octet full IPv4 address
IPv6 (2) 16 octet full IPv6 address IPv6 (2) 16 octet full IPv6 address
The IP address field is set to value null to denote that The IP address field is set to value null to denote that
advertising PE has not learned the IP address of his local CE advertising PE has not learned the IP address of his local CE
device. The non-zero value of the IP address field denotes IP device. The non-zero value of the IP address field denotes IP
address of advertising PE's attached CE device. address of advertising PE's attached CE device.
The CE's IP address is also supplied in the optional parameter The CE's IP address is also supplied in the optional parameter
skipping to change at line 525 skipping to change at line 522
The PW FEC TLV SHOULD not include the interface parameters as they The PW FEC TLV SHOULD not include the interface parameters as they
are ignored in the context of this message. are ignored in the context of this message.
6.3 Out-of-band Distribution Configuration 6.3 Out-of-band Distribution Configuration
In some cases, it may not be possible either to deduce the IP In some cases, it may not be possible either to deduce the IP
addresses from the VPN traffic nor induce remote PEs to supply the addresses from the VPN traffic nor induce remote PEs to supply the
necessary information on demand. For those cases, out-of-band necessary information on demand. For those cases, out-of-band
methods, such as manual configuration, MAY be used. methods, such as manual configuration, MAY be used.
7.0 IANA consideration 7.0 IANA Considerations
7.1 LDP Status messages 7.1 LDP Status messages
Shah, et. al. Expires February 2006 10 Shah, et. al. Expires April 2006 10
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
This document uses new LDP status codes, IANA already maintains a This document uses new LDP status codes, IANA already maintains a
registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The
following values are suggested for assignment: following values are suggested for assignment:
0x0000002B "IP Address of CE" 0x0000002B "IP Address of CE"
0x0000002C "IP Address of CE is absent" 0x0000002C "IP Address of CE is absent"
8.0 How a CE Learns the Remote CE's IP address 8.0 How a CE Learns the Remote CE's IP address
skipping to change at line 580 skipping to change at line 577
activation e.g. Frame Relay, PE should activate it first before activation e.g. Frame Relay, PE should activate it first before
sending Inverse ARP request. It should be noted, that PE might sending Inverse ARP request. It should be noted, that PE might
never receive the response to its own request, nor see any CE's never receive the response to its own request, nor see any CE's
Inverse ARP request in cases where CE is pre-configured with remote Inverse ARP request in cases where CE is pre-configured with remote
CE IP address or the use of Inverse ARP is not enabled. In either CE IP address or the use of Inverse ARP is not enabled. In either
case CE has used other means to learn the IP address of his case CE has used other means to learn the IP address of his
neighbor. neighbor.
8.3 CE Devices Using PPP 8.3 CE Devices Using PPP
Shah, et. al. Expires February 2006 11 Shah, et. al. Expires April 2006 11
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
When the PE learns the remote CE's IP address, it should initiate When the PE learns the remote CE's IP address, it should initiate
the Configure-Request and set the IP-Address option to the remote the Configure-Request and set the IP-Address option to the remote
CE's IP address to notify local CE the IP address of the remote CE. CE's IP address to notify local CE the IP address of the remote CE.
9.0 Use of IGPs with IP L2 Interworking L2VPNs 9.0 Use of IGPs with IP L2 Interworking L2VPNs
In an IP L2 interworking L2VPN, when an IGP on a CE connected to a In an IP L2 interworking L2VPN, when an IGP on a CE connected to a
broadcast link is cross-connected with an IGP on a CE connected to broadcast link is cross-connected with an IGP on a CE connected to
a point-to-point link, there are routing protocol related issues a point-to-point link, there are routing protocol related issues
skipping to change at line 632 skipping to change at line 629
9.2 RIP 9.2 RIP
RIP protocol broadcasts RIP advertisements every 30 seconds. If the RIP protocol broadcasts RIP advertisements every 30 seconds. If the
group/broadcast address snooping mechanism is used as described group/broadcast address snooping mechanism is used as described
above, the attached PE can learn the advertising (CE) router's IP above, the attached PE can learn the advertising (CE) router's IP
address from the IP header of the advertisement. No special address from the IP header of the advertisement. No special
configuration is required for RIP in this type of Layer 2 IP configuration is required for RIP in this type of Layer 2 IP
Interworking L2VPN. Interworking L2VPN.
Shah, et. al. Expires February 2006 12 Shah, et. al. Expires April 2006 12
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
10.0 IPV6 Considerations 10.0 IPV6 Considerations
The support for IPV6 is not addressed in this draft and is for The support for IPV6 is not addressed in this draft and is for
future study. future study.
11.0 Security Considerations 11.0 Security Considerations
The security aspect of this solution is addressed for two planes; The security aspect of this solution is addressed for two planes;
control plane and data plane. control plane and data plane.
skipping to change at line 676 skipping to change at line 673
11.2 Data plane security 11.2 Data plane security
The data traffic between CE and PE is not encrypted and it is The data traffic between CE and PE is not encrypted and it is
possible that in an insecure environment, a malicious user may tap possible that in an insecure environment, a malicious user may tap
into the CE to PE connection and generate traffic using the spoofed into the CE to PE connection and generate traffic using the spoofed
destination MAC address on the Ethernet Attachment Circuit. In destination MAC address on the Ethernet Attachment Circuit. In
order to avoid such hijacking, local PE may verify the source MAC order to avoid such hijacking, local PE may verify the source MAC
address of the received frame against the MAC address of the address of the received frame against the MAC address of the
admitted connection. The frame is forwarded to PW only when admitted connection. The frame is forwarded to PW only when
authenticity is verified. When spoofing is detected, PE must severe authenticity is verified. When spoofing is detected, PE must sever
the connection with the local CE, tear down the PW and start over. the connection with the local CE, tear down the PW and start over.
12.0 Acknowledgements 12.0 Acknowledgements
Shah, et. al. Expires February 2006 13 Shah, et. al. Expires April 2006 13
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce
Lasley, Mark Lewis, Carlos Pignataro and other folks who Lasley, Mark Lewis, Carlos Pignataro and other folks who
participated in the discussions related to this draft. participated in the discussions related to this draft.
13.0 References 13.0 References
13.1 Normative References 13.1 Normative References
[ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution
skipping to change at line 728 skipping to change at line 725
35 Nagog Park, 35 Nagog Park,
Acton, MA 01720 Acton, MA 01720
Email: hshah@ciena.com Email: hshah@ciena.com
Eric Rosen Eric Rosen
Cisco Systems Cisco Systems
1414 Massachusetts Avenue, 1414 Massachusetts Avenue,
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Shah, et. al. Expires February 2006 14 Shah, et. al. Expires April 2006 14
draft-ietf-l2vpn-arp-mediation-03.txt draft-ietf-l2vpn-arp-mediation-04.txt
Waldemar Augustyn Waldemar Augustyn
Email: waldemar@nxp.com Email: waldemar@nxp.com
Giles Heron Giles Heron
Email: giles.heron@tellabs.com Email: giles.heron@tellabs.com
Sunil Khandekar and Vach Kompella Sunil Khandekar and Vach Kompella
Email: sunil@timetra.com Email: sunil@timetra.com
Email: vkompella@timetra.com Email: vkompella@timetra.com
skipping to change at line 767 skipping to change at line 764
San Jose, CA 95134 San Jose, CA 95134
Email: Andy.Malis@tellabs.com Email: Andy.Malis@tellabs.com
Steven Wright Steven Wright
Bell South Corp Bell South Corp
Email: steven.wright@bellsouth.com Email: steven.wright@bellsouth.com
Vasile Radoaca Vasile Radoaca
Email: vasile@westridgenetworks.com Email: vasile@westridgenetworks.com
Shah, et. al. Expires April 2006 15
draft-ietf-l2vpn-arp-mediation-04.txt
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
Shah, et. al. Expires February 2006 15
draft-ietf-l2vpn-arp-mediation-03.txt
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
By submitting this Internet-Draft, I certify that any applicable Disclaimer of Validity
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Shah, et. al. Expires February 2006 16 Copyright Statement
Copyright (C) The Internet Society (2005).
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 April 2006 16
 End of changes. 40 change blocks. 
90 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/