draft-ietf-l2vpn-arp-mediation-12.txt   draft-ietf-l2vpn-arp-mediation-13.txt 
L2VPN Working Group Himanshu Shah Force10 Networks L2VPN Working Group Himanshu Shah, Ed.(Force10)
Intended Status: Proposed Standard Eric Rosen Cisco System Intended Status: Proposed Standard Eric Rosen, Ed. (Cisco)
Internet Draft Giles Heron British Telecom Internet Draft Giles Heron, Ed. (BT)
Vach Kompella Alcatel-Lucent Vach Kompella, Ed. (Alcatel-Lucent)
Expiration Date: August 27, 2010
June 2009 February 27 2010
Expires: December 2009
ARP Mediation for IP Interworking of Layer 2 VPN ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-12.txt draft-ietf-l2vpn-arp-mediation-13.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance This Internet-Draft is submitted in full conformance with the
with the provisions of BCP 78 and BCP 79. This document may provisions of BCP 78 and BCP 79.
contain material from IETF Documents or IETF Contributions
published or made publicly available before November 10, 2008.
The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards
Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
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/1id-abstracts.html
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
Draft-ietf-l2vpn-arp-mediation-12.txt
This Internet-Draft will expire on December 2009. This Internet-Draft will expire on August 27, 2010
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Draft-ietf-l2vpn-arp-mediation-13.txt
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license- (http://trustee.ietf.org/license-info) in effect on the date of
info). Please review these documents carefully, as they describe publication of this document. Please review these documents
your rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
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 5 skipping to change at page 2, line 44
a routing protocol between them, as long as the routing protocol a routing protocol between them, as long as the routing protocol
runs over IP. runs over IP.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC 2119]. in [RFC 2119].
Draft-ietf-l2vpn-arp-mediation-12.txt
Table of Contents Table of Contents
Copyright Notice........................................... 2 Copyright Notice........................................... 1
1. Contributing Authors....................................... 4 1. Contributing Authors....................................... 4
2. Introduction............................................... 4 2. Introduction............................................... 4
3. ARP Mediation (AM) function................................ 5 3. ARP Mediation (AM) function................................ 5
4. IP Layer 2 Interworking Circuit............................ 7 Draft-ietf-l2vpn-arp-mediation-13.txt
4. IP Layer 2 Interworking Circuit............................ 6
5. IP Address Discovery Mechanisms............................ 7 5. IP Address Discovery Mechanisms............................ 7
5.1. Discovery of IP Addresses of Locally Attached IPv4 CE. 8 5.1. Discovery of IP Addresses of Locally Attached IPv4 CE. 8
5.1.1. Monitoring Local Traffic......................... 8 5.1.1. Monitoring Local Traffic......................... 8
5.1.2. CE Devices Using ARP............................. 8 5.1.2. CE Devices Using ARP............................. 8
5.1.3. CE Devices Using Inverse ARP.....................10 5.1.3. CE Devices Using Inverse ARP.................... 10
5.1.4. CE Devices Using PPP............................ 10 5.1.4. CE Devices Using PPP............................ 10
5.1.5. Router Discovery method......................... 11 5.1.5. Router Discovery method......................... 11
5.1.6. Manual Configuration............................ 11 5.1.6. Manual Configuration............................ 11
5.2. How a CE Learns the IPv4 address of a remote CE...... 12 5.2. How a CE Learns the IPv4 address of a remote CE...... 12
5.2.1. CE Devices Using ARP............................ 12 5.2.1. CE Devices Using ARP............................ 12
5.2.2. CE Devices Using Inverse ARP.................... 12 5.2.2. CE Devices Using Inverse ARP.................... 12
5.2.3. CE Devices Using PPP............................ 12 5.2.3. CE Devices Using PPP............................ 12
5.3. Discovery of IP Addresses of IPv6 CE Devices......... 13 5.3. Discovery of IP Addresses of IPv6 CE Devices......... 13
5.3.1. Distinguishing factors between IPv4 and IPv6.... 13 5.3.1. Distinguishing Factors Between IPv4 and IPv6.... 13
5.3.2. Requirements for PE............................. 13 5.3.2. Requirements for PEs............................ 13
5.3.3. Processing of Neighbor Solicitations............ 14 5.3.3. Processing of Neighbor Solicitations............ 14
5.3.4. Processing of Neighbor Advertisements........... 14 5.3.4. Processing of Neighbor Advertisements........... 14
5.3.5. Processing of Inverse Neighbor Solicitations.... 15 5.3.5. Processing Inverse Neighbor Solicitations....... 15
5.3.6. Processing of Inverse Neighbor Advertisements... 16 5.3.6. Processing of Inverse Neighbor Advertisements... 16
5.3.7. Processing of Router Solicitations.............. 17 5.3.7. Processing of Router Solicitations.............. 16
5.3.8. Processing of Router Advertisements............. 17 5.3.8. Processing of Router Advertisements............. 17
5.3.9. Duplicate Address Detection [RFC 2462].......... 17 5.3.9. Duplicate Address Detection [RFC 2462].......... 17
5.3.10.CE address discovery for CEs attached using PPP. 17
6. CE IPv4 Address Signaling between PEs..................... 18 6. CE IPv4 Address Signaling between PEs..................... 18
6.1. When to Signal an IPv4 address of a CE............... 18 6.1. When to Signal an IPv4 address of a CE............... 18
6.2. LDP Based Distribution of CE IPv4 Addresses.......... 19
7. IPv6 Capability Advertisement............................. 21 7. IPv6 Capability Advertisement............................. 21
8. IANA Considerations....................................... 22 8. IANA Considerations....................................... 22
8.1. LDP Status messages.................................. 22 8.1. LDP Status messages.................................. 22
8.2. Interface Parameters................................. 23 8.2. Interface Parameters................................. 23
9. Use of IGPs with IP L2 Interworking L2VPNs................ 23 9. Security Considerations................................... 23
9.1. OSPF................................................. 24 9.1. Control plane security............................... 23
9.2. RIP.................................................. 24 9.2. Data plane security.................................. 25
9.3. IS-IS................................................ 24 10. Acknowledgements......................................... 25
10. Multi-domain considerations.............................. 25 11. References............................................... 25
11. Security Considerations.................................. 26 11.1. Normative References................................ 25
11.1. Control plane security.............................. 26 11.2. Informative References.............................. 26
11.2. Data plane security................................. 27 12. Authors' Addresses....................................... 26
12. Acknowledgements......................................... 27 APPENDIX A:.................................................. 28
13. References............................................... 28 A.1. Use of IGPs with IP L2 Interworking L2VPNs........... 28
13.1. Normative References................................ 28 A.1.1. OSPF............................................ 28
13.2. Informative References.............................. 29 A.1.2. RIP............................................. 28
Draft-ietf-l2vpn-arp-mediation-12.txt A.1.3. IS-IS........................................... 29
Draft-ietf-l2vpn-arp-mediation-13.txt
14. Authors' Addresses....................................... 29
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 NetApps T. Smith NetApps
A. Malis Verizon A. Malis Verizon
S. Wright Bell South S. Wright Bell South
M. Bocci Alcatel-Lucent
T. Grigoriu Alcatel-Lucent T. Grigoriu Alcatel-Lucent
N. Hart Alcatel-Lucent N. Hart Alcatel-Lucent
A. Dolganow Alcatel-Lucent A. Dolganow Alcatel-Lucent
S. Amante Level3 S. Amante Level3
A. Vishwanathan Force10 Networks A. Vishwanathan Force10 Networks
A. Moranganti Consultant A. Moranganti Consultant
2. Introduction 2. Introduction
Layer 2 Virtual Private Networks (L2VPN) are constructed over a Layer 2 Virtual Private Networks (L2VPN) are constructed over a
skipping to change at page 5, line 5 skipping to change at page 4, line 43
In a typical implementation, illustrated in the diagram below, In a typical implementation, illustrated in the diagram below,
the CE devices are connected to the Provider Edge (PE) devices the CE devices are connected to the Provider Edge (PE) devices
via Attachment Circuits (AC). The ACs are Layer 2 links. In a via Attachment Circuits (AC). The ACs are Layer 2 links. In a
pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via 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 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 Ethernet, both FR, etc.). However, if it is known that only IP
traffic will be carried, the ACs can be of different traffic will be carried, the ACs can be of different
technologies, provided that the PEs provide the appropriate technologies, provided that the PEs provide the appropriate
procedures to allow the proper transfer of IP packets. procedures to allow the proper transfer of IP packets.
Draft-ietf-l2vpn-arp-mediation-12.txt
+-----+ +-----+
+------ -----| CE3 | +------ -----| CE3 |
| +-----+ | +-----+
+-----+ +-----+
Draft-ietf-l2vpn-arp-mediation-13.txt
......| PE3 |........... ......| PE3 |...........
. +-----+ . . +-----+ .
. | . . | .
. | . . | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+ +-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 | | CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+ +-----+ +-----+ Backbone +-----+ +-----+
. . . .
........................ ........................
skipping to change at page 5, line 43 skipping to change at page 5, line 39
Consider a Virtual Private Wire Service (VPWS) constructed Consider a Virtual Private Wire Service (VPWS) constructed
between CE1 and CE2 in the diagram above. If AC1 and AC2 are of 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 different technologies, e.g. AC1 is Ethernet and AC2 is Frame
Relay (FR), then ARP requests coming from CE1 cannot be passed Relay (FR), then ARP requests coming from CE1 cannot be passed
transparently to CE2. PE1 must interpret the meaning of the ARP transparently to CE2. PE1 must interpret the meaning of the ARP
requests and mediate the necessary information with PE2 before requests and mediate the necessary information with PE2 before
responding. responding.
The draft uses "ARP" terminology to mean any protocol that is The draft uses "ARP" terminology to mean any protocol that is
used to resolve IP address to Link Layer address association used to resolve IP address to Link Layer address association
purposes. For instance in IPv4, ARP and InvArp protocols are purposes. For instance in IPv4, ARP and Inverse ARP protocols
used for address resolution while in IPv6 Neighbor Discovery and are used for address resolution while in IPv6 Neighbor Discovery
Inverse Neighbor Discovery protocol based on ICMPv6 is used for and Inverse Neighbor Discovery protocol based on ICMPv6 is used
address resolution. for address resolution.
3. ARP Mediation (AM) function 3. ARP Mediation (AM) function
The ARP Mediation (AM) function is an element of a PE node that The ARP Mediation (AM) function is an element of a PE node that
deals with the IP address resolution for CE devices connected deals with the IP address resolution for CE devices connected
Draft-ietf-l2vpn-arp-mediation-12.txt
via an VPWS L2VPN. By placing this function in the PE node, ARP via an VPWS L2VPN. By placing this function in the PE node, ARP
Mediation is transparent to the CE devices. Mediation is transparent to the CE devices.
For a given point-to-point connection between a pair of CEs, the For a given point-to-point connection between a pair of CEs, the
ARP Mediation procedure depends on whether the packets being ARP Mediation procedure depends on whether the packets being
forwarded are IPv4 or IPV6. A PE that is to perform ARP forwarded are IPv4 or IPV6. A PE that is to perform ARP
Draft-ietf-l2vpn-arp-mediation-13.txt
Mediation for IPv4 packets must perform the following logical Mediation for IPv4 packets must perform the following logical
steps: steps:
1. Discover the IP address of the locally attached CE device 1. Discover the IP address of the locally attached CE device
2. Terminate, do not distribute ARP and Inverse ARP requests 2. Terminate, do not distribute ARP and Inverse ARP requests
from CE device at local PE. from CE device at local PE.
3. Distribute the IP Address to the remote PE using 3. Distribute the IP Address to the remote PE using
pseudowire control signaling. pseudowire control signaling.
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.
skipping to change at page 7, line 5 skipping to change at page 6, line 38
forwarding the packets across the VPWS to the remote PE. forwarding the packets across the VPWS to the remote PE.
3. Intercept Neighbor Discovery and Inverse Neighbor Discovery 3. Intercept Neighbor Discovery and Inverse Neighbor Discovery
packets received over the VPWS from the remote PE, possibly packets received over the VPWS from the remote PE, possibly
modifying them (if required for the type of outgoing AC) modifying them (if required for the type of outgoing AC)
before forwarding to the local CE, and also learning before forwarding to the local CE, and also learning
information about the IPv6 configuration of the remote CE. information about the IPv6 configuration of the remote CE.
PEs MUST support ARP mediation for IPv4 L2 Interworking PEs MUST support ARP mediation for IPv4 L2 Interworking
circuits. Support for IPv6 L2 interworking circuits is OPTIONAL. circuits. Support for IPv6 L2 interworking circuits is OPTIONAL.
Draft-ietf-l2vpn-arp-mediation-12.txt
Details for the above-described procedures are given in the Details for the above-described procedures are given in the
following sections. following sections.
4. IP Layer 2 Interworking Circuit 4. IP Layer 2 Interworking Circuit
Draft-ietf-l2vpn-arp-mediation-13.txt
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
Attachment Circuit. In this case, ATM header as well as the Attachment Circuit. In this case, ATM header as well as the
Ethernet header is removed to expose the IP packet at the Ethernet header is removed to expose the IP packet at the
skipping to change at page 8, line 5 skipping to change at page 7, line 44
- Establishment of the PW - Establishment of the PW
The establishment of the PW occurs independently from local CE The establishment of the PW occurs independently from local CE
IP address discovery. During the period when the PW has been IP address discovery. During the period when the PW has been
established but the local CE IP device has not been discovered, established but the local CE IP device has not been discovered,
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.
Draft-ietf-l2vpn-arp-mediation-12.txt
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.
Draft-ietf-l2vpn-arp-mediation-13.txt
The need to wait for address resolution completion before the The need to wait for address resolution completion before the
unicast IP traffic can flow is simple. unicast IP traffic can flow is simple.
. PEs do not perform routing operations . PEs do not perform routing operations
. Destination IP address in the packet is not necessarily . Destination IP address in the packet is not necessarily
that of the attached CE that of the attached CE
. On a broadcast link, there is no way to find out the MAC . On a broadcast link, there is no way to find out the MAC
address of the CE based on the Destination IP address of address of the CE based on the Destination IP address of
the packet. the packet.
5.1. Discovery of IP Addresses of Locally Attached IPv4 CE 5.1. Discovery of IP Addresses of Locally Attached IPv4 CE
skipping to change at page 9, line 5 skipping to change at page 8, line 46
Attachment Circuit. However, customer facing access topologies Attachment Circuit. However, customer facing access topologies
may exist whereby more than one CE appears to be connected to may exist whereby more than one CE appears to be connected to
the PE on a single Attachment Circuit. For example, this could the PE on a single Attachment Circuit. For example, this could
be the case when CEs are connected to a shared LAN that connects 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 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 selection could be based on manual configuration or the PE may
optionally use following selection criteria. In either case, optionally use following selection criteria. In either case,
manual configuration of IP address of the local CE (and its MAC manual configuration of IP address of the local CE (and its MAC
address) MUST be supported. address) MUST be supported.
Draft-ietf-l2vpn-arp-mediation-12.txt
o Wait to learn the IP address of the remote CE (through PW o Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending 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.
Draft-ietf-l2vpn-arp-mediation-13.txt
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 for 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. ).
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
signaling). signaling).
skipping to change at page 9, line 43 skipping to change at page 9, line 40
may initiate an unsolicited ARP response to notify the IP may initiate an unsolicited ARP response to notify the IP
address to MAC address binding for the remote CE to local CE address to MAC address binding for the remote CE to local CE
(again using its own MAC address). (again using its own MAC address).
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 may periodically generate ARP request messages for the IP The PE may periodically generate ARP request messages for the IP
address of the CE as a means of verifying the continued address of the CE as a means of verifying the continued
existence of the address and its MAC address binding. The existence of the IP address and its MAC address binding. The
absence of a response from the CE device for a given number of 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 retries could be used as a trigger for withdrawal of the IP
address advertisement to the remote PE. The local PE would then address advertisement to the remote PE. The local PE would then
re-enter the address resolution phase to rediscover the IP re-enter the address resolution phase to rediscover the IP
address of the attached CE. Note that this "heartbeat" scheme is address of the attached CE. Note that this "heartbeat" scheme is
needed only for broadcast links (such as Ethernet AC), where the needed only for broadcast links (such as Ethernet AC), where the
failure of a CE device may otherwise be undetectable. failure of a CE device may otherwise be undetectable.
Draft-ietf-l2vpn-arp-mediation-12.txt Draft-ietf-l2vpn-arp-mediation-13.txt
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 records the IP address of remote CE, it does not respond, but records the IP address of
the local CE and the circuit information. Subsequently, when the the local CE and the circuit information. Subsequently, when the
IP address of the remote CE becomes available, the PE may IP address of the remote CE becomes available, the PE may
initiate the Inverse ARP request as a means of notifying the IP initiate the Inverse ARP request as a means of notifying the IP
address of the remote CE to the local CE. address 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.
5.1.4. CE Devices Using PPP 5.1.4. CE Devices Using PPP
The IP Control Protocol [PPP-IPCP] describes a procedure to The IP Control Protocol [PPP-IPCP] describes a procedure to
establish and configure IP on a point-to-point connection, establish and configure IP on a point-to-point connection,
including the negotiation of IP addresses. When such Attachment including the negotiation of IP addresses. When such Attachment
Circuit is configured for IP interworking, PPP negotiation is Circuit is configured for IP interworking, PPP negotiation is
not performed end-to-end between CE devices. Instead, PPP not performed end-to-end between CE devices. Instead, PPP
negotiation takes place between the CE and its local PE. The PE negotiation takes place between the CE and its local PE. The PE
performs proxy PPP negotiation and informs the attached CE the performs proxy PPP negotiation and informs the attached CE the
skipping to change at page 11, line 5 skipping to change at page 11, line 5
o The PE learns the IP address of the local CE from the o The PE learns the IP address of the local CE from the
Configure-Request received with the IP-Address option Configure-Request received with the IP-Address option
(0x03). If the IP address is non-zero, PE records the (0x03). If the IP address is non-zero, PE records the
address and responds with Configure-Ack. However, if the address and responds with Configure-Ack. However, if the
IP address is zero, PE responds with Configure-Reject (as IP address is zero, PE responds with Configure-Reject (as
this is a request from CE to assign it an IP address). this is a request from CE to assign it an IP address).
Also, the IP address option is set with zero value in the Also, the IP address option is set with zero value in the
Configure-Reject response to instruct the CE to not Configure-Reject response to instruct the CE to not
include that option in subsequent new Configure-Request. include that option in subsequent new Configure-Request.
Draft-ietf-l2vpn-arp-mediation-12.txt Draft-ietf-l2vpn-arp-mediation-13.txt
o If the PE receives Configure-Request without the IP- o If the PE receives Configure-Request without the IP-
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
to employ other learning mechanisms, the IPCP negotiations order to employ other learning mechanisms, the IPCP
must have reached the open state. negotiations 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.
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
skipping to change at page 11, line 45 skipping to change at page 11, line 45
Router Discovery Response (ICMP - router advertisement) message Router Discovery Response (ICMP - router advertisement) message
from the CE. It is possible that the response contains more than from the CE. It is possible that the response contains more than
one router addresses with the same preference level; in which one router addresses with the same preference level; in which
case, some heuristics (such as first on the list) is necessary. case, some heuristics (such as first on the list) is necessary.
The use of the Router Discovery method by the PE is optional. The use of the Router Discovery method by the PE is optional.
5.1.6. Manual Configuration 5.1.6. Manual Configuration
In some cases, it may not be possible to discover the IP address In some cases, it may not be possible to discover the IP address
of the local CE device using the mechanisms described in section of the local CE device using the mechanisms described in section
5.1 above. In such cases manual configuration MAY be used. All 5.1. above. In such cases manual configuration MAY be used. All
implementations of this draft MUST support manual configuration implementations of this draft MUST support manual configuration
of the IPv4 address of the local CE. This is the only REQUIRED of the IPv4 address of the local CE. This is the only REQUIRED
mode for a PE to support. mode for a PE to support.
Draft-ietf-l2vpn-arp-mediation-12.txt Draft-ietf-l2vpn-arp-mediation-13.txt
5.2. How a CE Learns the IPv4 address of a remote 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 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. , it may or may not already know IP address of the
of the local CE. If the IP address is not known, the PE must local CE. If the IP address is not known, the PE must wait until
wait until it is acquired through one of the methods described it is acquired through one of the methods described in sections
in sections 5.1.1, 5.1.2 and 5.1.5. If IP address of the local 5.1.1, 5.1.2 and 5.1.5. If IP address of the local CE is known,
CE is known, the PE may choose to generate an unsolicited ARP the PE may choose to generate an unsolicited ARP message to
message to notify the local CE about the binding of the IP notify the local CE about the binding of the IP address of the
address of the remote CE with the PE's own MAC address. 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
source hardware address and IP address of remote CE as the source hardware address and IP address of remote CE as the
source protocol address. The PE must respond only to those ARP source protocol address. The PE must respond only to those ARP
requests whose destination protocol address matches the IP requests whose destination protocol address matches the IP
address of the remote CE. address of the remote CE.
5.2.2. CE Devices Using Inverse ARP 5.2.2. CE Devices Using Inverse ARP
skipping to change at page 13, line 5 skipping to change at page 13, line 5
Inverse ARP has not been enabled. In either case the CE has used Inverse ARP has not been enabled. In either case the CE has used
other means to learn the IP address of his neighbor. other means to learn the IP address of his neighbor.
5.2.3. CE Devices Using PPP 5.2.3. CE Devices Using PPP
When the PE learns the IP address of the remote CE, it should When the PE learns the IP address of the remote CE, it should
initiate a Configure-Request and set the IP-Address option to 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 the IP address of the remote CE to notify the IP address of the
remote CE to the local CE. remote CE to the local CE.
Draft-ietf-l2vpn-arp-mediation-12.txt Draft-ietf-l2vpn-arp-mediation-13.txt
5.3. Discovery of IP Addresses of IPv6 CE Devices 5.3. Discovery of IP Addresses of IPv6 CE Devices
5.3.1. Distinguishing factors between IPv4 and IPv6 5.3.1. Distinguishing Factors Between IPv4 and IPv6
The IPv6 uses ICMPv6 extensions to resolve IP address and link IPv6 uses ICMPv6 extensions to resolve IP address and link
address associations. These are essentially IP packets as address associations. These are ICMPv6 packets, as compared to
compared to ARP and invARP in IPv4 which is a separate protocol ARP and inverse ARP in IPv4 which are dedicated address
and not IP packets. The IP pseudowire can not be used to carry resolution protocols and not IP packets. The IP pseudowire
the ARP/invARP packets and hence requires local processing of cannot be used to carry ARP and Inverse ARP packets and hence
these PDUs and signaling of IP address information between the requires local processing of these PDUs and signaling of IP
PEs using the Pseudowire control plane. address information between the PEs using the Pseudowire control
plane.
5.3.2. Requirements for PE 5.3.2. Requirements for PEs
A PE device that supports IPv6 MUST be capable of, A PE device that supports IPv6 MUST be capable of,
- Intercepting ICMPv6 Neighbor Discovery [RFC 2461] and - Intercepting ICMPv6 Neighbor Discovery [RFC 2461] and
Inverse Neighbor Discovery [RFC 3122] packets received Inverse Neighbor Discovery [RFC 3122] packets received
over the AC as well as over the PW. over the AC as well as over the PW.
- Record the IPv6 interface addresses and CE link-layer - Recording the IPv6 interface addresses and CE link-layer
addresses present in these packets addresses present in these packets
- Possibly modify these packets as dictated by the data link - Possibly modifying these packets as dictated by the data
type of the egress AC (described in the following link type of the egress AC (described in the following
sections), and sections), and
- Forward them towards the original destination - Forwarding them towards the original destination
The PE MUST also be capable of generating packets in order to The PE MUST also be capable of generating packets in order to
interwork between Neighbor Discovery (ND) and Inverse Neighbor interwork between Neighbor Discovery (ND) and Inverse Neighbor
Discovery (IND). This is specified in Sections 5.3.3. to Section Discovery (IND). This is specified in Sections 5.3.3. to 5.3.6.
5.3.6. below. below.
A PE device MUST also be capable of intercepting Router
Discovery packets. This is required in order to translate
between different link layer addresses. If a Router Discovery
message contains a link layer address, then the PE MAY also use
this message to discover the link layer address and IPv6
Draft-ietf-l2vpn-arp-mediation-12.txt
interface address. This is described in more detail in Section If an IP PW is used to interconnect CEs that use IPv6 Router
5.3.7. and Section 5.3.8. Discovery [RFC 2461], a PE device MUST also be capable of
intercepting and processing those Router Discovery packets. This
is required in order to translate between different link layer
addresses. If a Router Discovery message contains a link layer
address, then the PE MAY also use this message to discover the
link layer address and IPv6 interface address. This is described
in more detail in Section 5.3.7. and Section 5.3.8.
The PE device MUST learn a list of CE IPv6 interface addresses The PE device MUST learn a list of CE IPv6 interface addresses
for its directly-attached CE and another list of CE IPv6 for its directly-attached CE and another list of CE IPv6
interface addresses for the far-end CE. The PE device MUST also interface addresses for the far-end CE. The PE device MUST also
learn the link-layer address of the local CE and be able to use learn the link-layer address of the local CE and be able to use
Draft-ietf-l2vpn-arp-mediation-13.txt
it when forwarding traffic between the local and far-end CEs. it when forwarding traffic between the local and far-end CEs.
The PE MAY also wish to monitor the source link-layer address of The PE MAY also wish to monitor the source link-layer address of
data packets received from the CE, and discard packets not data packets received from the CE, and discard packets not
matching its learned CE link-layer address. matching its learned CE link-layer address.
5.3.3. Processing of Neighbor Solicitations 5.3.3. Processing of Neighbor Solicitations
A Neighbor Solicitation received on an AC from a local CE SHOULD A Neighbor Solicitation received on an AC from a local CE SHOULD
be inspected to determine and learn an IPv6 interface address be inspected to determine and learn an IPv6 interface address
(if provided - this will not be the case for Duplicate Address (if provided - this will not be the case for Duplicate Address
skipping to change at page 14, line 35 skipping to change at page 14, line 28
Solicitation received over the pseudowire SHOULD be inspected to Solicitation received over the pseudowire SHOULD be inspected to
determine and learn an IPv6 interface address for the far-end determine and learn an IPv6 interface address for the far-end
CE. If a source link-layer address option is present, the PE CE. If a source link-layer address option is present, the PE
MUST remove it. The PE MAY substitute an appropriate link-layer MUST remove it. The PE MAY substitute an appropriate link-layer
address option, specifying the link-layer address of the local address option, specifying the link-layer address of the local
AC. Note that if the local AC is Ethernet, failure to substitute AC. Note that if the local AC is Ethernet, failure to substitute
a link-layer address option may mean that the CE has no valid a link-layer address option may mean that the CE has no valid
link-layer address with which to transmit data packets. link-layer address with which to transmit data packets.
When a PE with a local AC of the type point-to-point link When a PE with a local AC of the type point-to-point link
receives a Neighbor Solicitation over the pseudowire, after receives a Neighbor Solicitation from a far end PE over the
learning the far-end CE's IP address, the PE may use either of pseudowire, after learning the IP address of the far-end CE, the
the following handling procedures: PE MAY use one of the following procedures:
1. Forward the Neighbor Solicitation to the local CE after
replacing the source link-layer address with the link-layer
address of the local AC.
2. Send an Inverse Neighbor Solicitation to the local CE,
specifying the far-end CE's IP address and the link-layer
address of the local AC.
1. Forward the Neighbor Solicitation to the local CE after
replacing the source link-layer address with the link-
layer address of the local AC.
2. Send an Inverse Neighbor Solicitation to the local CE,
specifying the far-end CE's IP address and the link-layer
address of the local AC.
3. Reply to the far end PE with a Neighbor Advertisement,
using the IP address of the local CE learned using IPv6CP
as the source address, and an appropriate link-layer
address option, specifying the link-layer address of the
local AC.
5.3.4. Processing of Neighbor Advertisements 5.3.4. Processing of Neighbor Advertisements
Draft-ietf-l2vpn-arp-mediation-12.txt
A Neighbor Advertisement received on an AC from a local CE A Neighbor Advertisement received on an AC from a local CE
SHOULD be inspected to determine and learn an IPv6 interface SHOULD be inspected to determine and learn an IPv6 interface
address and any link-layer address provided. The packet MUST address and any link-layer address provided. The packet MUST
then be forwarded over the pseudowire unmodified. then be forwarded over the IP pseudowire unmodified.
Draft-ietf-l2vpn-arp-mediation-13.txt
A Neighbor Advertisement received over the pseudowire SHOULD be A Neighbor Advertisement received over the pseudowire SHOULD be
inspected to determine and learn an IPv6 interface address for inspected to determine and learn an IPv6 interface address for
the far-end CE. If a source link-layer address option is the far-end CE. If a source link-layer address option is
present, the PE MUST remove it. The PE MAY substitute an present, the PE MUST remove it. The PE MAY substitute an
appropriate link-layer address option, specifying the link-layer appropriate link-layer address option, specifying the link-layer
address of the local AC. Note that if the local AC is Ethernet, address of the local AC. Note that if the local AC is Ethernet,
failure to substitute a link-layer address option may mean that failure to substitute a link-layer address option may mean that
the local CE has no valid link-layer address with which to the local CE has no valid link-layer address with which to
transmit data packets. transmit data packets.
When a PE with a local AC of the type point-to-point link When a PE with a local AC of the type point-to-point link
receives a Neighbor Advertisement over the pseudowire, it should receives a Neighbor Advertisement over the pseudowire, it should
perform the following steps. perform the following steps:
o Learn the IPv6 interface addresses of the far-end CE.
o If the PE had already processed an IND-SOL from local CE,
it should send on the local AC an IND-ADV using source IP
address information received in ND-ADV and its own link
information.
o If the PE had not received any IND-SOL from the local CE,
it should send on the local AC an IND-SOL using source IP
address information received in ND-ADV and its own link
information
5.3.5. Processing of Inverse Neighbor Solicitations o Learn the IPv6 addresses of the far-end CE.
o If the AC supports Inverse Neighbor Discovery and the PE
had already processed an Inverse Neighbor Solicitation
(IND-SOL) from local CE, it SHOULD send an Inverse
Neighbor Advertisement (INA) on the local AC using source
IP address information received in ND-ADV and its own
local AC link layer information.
o If the PE has not received any Inverse Neighbor
Solicitation (INS) from the local CE, and the AC supports
Inverse Neighbor Discovery, it SHOULD send an INS on the
local AC using source IP address information received in
the INA together with its own local AC link layer
information.
5.3.5. Processing Inverse Neighbor Solicitations
An Inverse Neighbor Solicitation received on an AC from a local An Inverse Neighbor Solicitation received on an AC from a local
CE SHOULD be inspected to determine and learn an IPv6 interface CE SHOULD be inspected to determine and learn the IPv6 addresses
address and the link-layer addresses. The packet may optionally and the link-layer addresses. The packet MUST then be forwarded
contain a list of interface addresses for the local CE, and
these SHOULD also be learned. The packet MUST then be forwarded
over the pseudowire unmodified. over the pseudowire unmodified.
An Inverse Neighbor Solicitation received over the pseudowire An Inverse Neighbor Solicitation received over the pseudowire
SHOULD be inspected to determine and learn one or more interface SHOULD be inspected to determine and learn one or more IPv6
addresses for the far-end CE. If the local AC supports Inverse addresses for the far-end CE. If the local AC supports Inverse
Neighbor Discovery (e.g., a Frame Relay AC), the packet may be Neighbor Discovery (e.g., a switched Frame Relay AC), the packet
forwarded to the local CE, after modifying the link-layer may be forwarded to the local CE, after modifying the link-layer
address options to match the type of the local AC. address options to match the type of the local AC.
Draft-ietf-l2vpn-arp-mediation-12.txt
If the local AC does not support Inverse Neighbor Discovery If the local AC does not support Inverse Neighbor Discovery
(IND), processing of the packet depends on whether the PE has (IND), processing of the packet depends on whether the PE has
learned at least one interface address for its directly-attached learned at least one interface address for its directly-attached
CE. If it has learned at least one interface address for the CE, CE. If it has learned at least one IPv6 address for the CE, the
the PE MUST discard the Inverse Neighbor Solicitation (INS) and Draft-ietf-l2vpn-arp-mediation-13.txt
PE MUST discard the Inverse Neighbor Solicitation (INS) and
generate an Inverse Neighbor Advertisement (INA) back into the generate an Inverse Neighbor Advertisement (INA) back into the
pseudowire. The destination address of the INA is the source pseudowire. The destination address of the INA is the source
address from the INS, the source address is one of the local address from the INS, the source address is one of the local
CE's interface addresses, and all the local CE's interface CE's interface addresses, and all the local CE's interface
addresses that have been learned so far SHOULD BE included in addresses that have been learned so far SHOULD be included in
the Target Address List. The Source and Target Link-Layer the Target Address List. The Source and Target Link-Layer
addresses are copied from the INS. In addition, the PE should addresses are copied from the INS. In addition, the PE should
generate ND advertisement on the local AC using IP address of generate ND advertisements on the local AC using the IPv6
the remote CE and MAC address of the local PE. address of the remote CE and link-layer address of the local PE.
The INS MUST be discarded if the PE has not yet learned at least The INS MUST be discarded if the PE has not yet learned at least
one interface address for its directly-connected CE. This one IPv6 and link-layer address for its directly-connected CE.
processing continues until the PE learns an address from the This processing continues until the PE learns an IPv6 and link-
local CE (through receiving, for example, a Neighbor layer address from the local CE (through receiving, for example,
Solicitation). After this has occurred, the PE will be able to a Neighbor Solicitation). After this has occurred, the PE will
respond to INS messages received over the pseudowire. be able to respond to INS messages received over the pseudowire.
5.3.6. Processing of Inverse Neighbor Advertisements 5.3.6. Processing of Inverse Neighbor Advertisements
An Inverse Neighbor Advertisement (INA) received on an AC from a An Inverse Neighbor Advertisement (INA) received on an AC from a
local CE SHOULD be inspected to determine and learn one or more local CE SHOULD be inspected to determine and learn one or more
interface addresses for the CE. It MUST then be forwarded IPv6 addresses for the CE. It MUST then be forwarded unmodified
unmodified over the pseudowire. over the pseudowire.
An INA received over the pseudowire SHOULD be inspected to An INA received over the pseudowire SHOULD be inspected to
determine and learn one or more interface addresses for the far- determine and learn one or more IPv6 addresses for the far-end
end CE. CE.
If the local AC supports Inverse Neighbor Discovery (e.g., a If the local AC supports Inverse Neighbor Discovery (e.g., a
Frame Relay AC), the packet MAY be forwarded to the local CE, Frame Relay AC), the packet MAY be forwarded to the local CE,
after modifying the link-layer address options to match the type after modifying the link-layer address options to match the type
of the local AC. of the local AC.
If the local AC does not support Inverse Neighbor Discovery, the If the local AC does not support Inverse Neighbor Discovery, the
PE MUST discard the INA and generate a Neighbor Advertisement PE MUST discard the INA and generate a Neighbor Advertisement
(NA) towards its local CE. The source address of the NA is the (NA) towards its local CE. The source IPv6 address of the NA is
source address from the INA, the destination address is the the source IPv6 address from the INA, the destination IPv6
destination address from the INA and the link-layer address is address is the destination IPv6 address from the INA and the
that of the local AC on the PE. link-layer address is that of the local AC on the PE.
Draft-ietf-l2vpn-arp-mediation-12.txt
5.3.7. Processing of Router Solicitations 5.3.7. Processing of Router Solicitations
A Router Solicitation received on an AC from a local CE SHOULD A Router Solicitation received on an AC from a local CE SHOULD
be inspected to determine and learn an interface address for the be inspected to determine and learn an IPv6 address for the CE,
CE, and, if present, the link-layer address of the CE. It MUST and, if present, the link-layer address of the CE. It MUST then
then be forwarded unmodified over the pseudowire. be forwarded unmodified over the pseudowire.
Draft-ietf-l2vpn-arp-mediation-13.txt
A Router Solicitation received over the pseudowire SHOULD be A Router Solicitation received over the pseudowire SHOULD be
inspected to determine and learn an interface address for the inspected to determine and learn an IPv6 address for the far-end
far-end CE. If a source link-layer address option is present, CE. If a source link-layer address option is present, the PE
the PE MUST remove it. The PE MAY substitute a source link-layer MUST remove it. The PE MAY substitute a source link-layer
address option specifying the link-layer address of its local address option specifying the link-layer address of its local
AC. The packet is then forwarded to the local CE. AC. The packet is then forwarded to the local CE.
5.3.8. Processing of Router Advertisements 5.3.8. Processing of Router Advertisements
A Router Advertisement received on an AC from a local CE SHOULD A Router Advertisement received on an AC from a local CE SHOULD
be inspected to determine and learn an interface address for the be inspected to determine and learn an IPv6 address for the CE,
CE, and, if present, the link-layer address of the CE. It MUST and, if present, the link-layer address of the CE. It MUST then
then be forwarded unmodified over the pseudowire. be forwarded unmodified over the pseudowire.
A Router Advertisement received over the pseudowire SHOULD be A Router Advertisement received over the pseudowire SHOULD be
inspected to determine and learn an interface address for the inspected to determine and learn an IPv6 address for the far-end
far-end CE. If a source link-layer address option is present, CE. If a source link-layer address option is present, the PE
the PE MUST remove it. The PE MAY substitute a source link-layer MUST remove it. The PE MAY substitute a source link-layer
address option specifying the link-layer address of its AC. If address option specifying the link-layer address of its local
an MTU option is present, the PE MAY reduce the specified MTU if AC. If an MTU option is present, the PE MAY reduce the specified
the MTU of the pseudowire is less than the value specified in MTU if the MTU of the pseudowire is less than the value
the option. The packet is then forwarded to the local CE. specified in the option. The packet is then forwarded to the
local CE.
5.3.9. Duplicate Address Detection [RFC 2462] 5.3.9. Duplicate Address Detection [RFC 2462]
Duplicate Address Detection allows IPv6 hosts and routers to Duplicate Address Detection allows IPv6 hosts and routers to
ensure that the addresses assigned to interfaces are unique ensure that the addresses assigned to interfaces are unique on a
on a link. As with all Neighbor Discovery packets, those link. As with all Neighbor Discovery packets, those used in
used in Duplicate Address Detection will simply flow Duplicate Address Detection will simply flow through the
through the pseudowire, being inspected at the PEs at each pseudowire, being inspected at the PEs at each end. Processing
end. Processing is performed as above. However, the source is performed as above. However, the source IPv6 address of
address of Neighbor Solicitations used in Duplicate Address Neighbor Solicitations used in Duplicate Address Detection is
Detection is the unspecified address, so the PEs can not the unspecified address, so the PEs cannot learn the CE's IPv6
Draft-ietf-l2vpn-arp-mediation-12.txt interface address (nor would it make sense to do so, given that
at least one address is tentative at that time).
learn the CE's interface address (nor would it make sense 5.3.10. CE address discovery for CEs attached using PPP
to do so, given that at least one address is tentative at
that time). The IPv6 Control Protocol (IPv6CP) [PPP-IPV6] describes a
procedure to establish and configure IPv6 on a point-to-point
connection, including the negotiation of link-local interface
identifier. As in the case of IPv4, when such an AC is
configured for IP interworking, PPP negotiation is not performed
end-to-end between CE devices. Instead, PPP negotiation takes
place between the CE and its local PE. The PE performs proxy PPP
negotiation and informs the attached CE of the link-local
identifier of its local interface using the Interface-Identifier
Draft-ietf-l2vpn-arp-mediation-13.txt
option (0x01). This local interface identifier is used by
stateless address auto configuration [RFC 2462].
When a PPP link completes IPv6CP negotiations and the PPP link
is open, a PE MAY discover the IPv6 unicast address of the CE
using any of the mechanisms described above.
6. CE IPv4 Address Signaling between PEs 6. CE IPv4 Address Signaling between PEs
6.1. When to Signal an IPv4 address of a CE 6.1. When to Signal an IPv4 address of a CE
A PE device advertises the IPv4 address of the attached CE only A PE device advertises the IPv4 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 IPv4 address of a CE device is not quite possible that the IPv4 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 18, line 30 skipping to change at page 18, line 33
when the DLCI is active. If the PE signals the DLCI to be active when the DLCI is active. If the PE signals the DLCI to be active
only when it has received the IPv4 address along with the PW FEC only when it has received the IPv4 address along with the PW FEC
from the remote PE, a chicken and egg situation arises. In order from the remote PE, a chicken and egg situation arises. In order
to avoid such problems, the PE must be prepared to advertise the to avoid such problems, the PE must be prepared to advertise the
PW FEC before the IPv4 address of the CE is known and hence uses PW FEC before the IPv4 address of the CE is known and hence uses
IPv4 address value zero. When the IPv4 address of the CE device IPv4 address value zero. When the IPv4 address of the CE device
does become available, the PE re-advertises the PW FEC along does become available, the PE re-advertises the PW FEC along
with the IPv4 address of the CE. with the IPv4 address of the CE.
Similarly, if the PE detects that an IP address of a CE is no Similarly, if the PE detects that an IP address of a CE is no
longer valid (by methods described above), the PE must re- longer valid (by methods described above),the PE must re-
advertise the PW FEC with null IP address to denote the advertise the PW FEC with null IP address to denote the
withdrawal of IP address of the CE. The receiving PE then waits withdrawal of IP address of the CE. The receiving PE then waits
for notification of the remote IP address. During this period, for notification of the remote IP address. During this period,
propagation of unicast IPv4 traffic is suspended, but multicast propagation of unicast IPv4 traffic is suspended, but multicast
IPv4 traffic can continue to flow between the AC and the IPv4 traffic can continue to flow between the AC and the
pseudowire. pseudowire.
If two CE devices are locally attached to the PE on disparate AC If two CE devices are locally attached to the PE on disparate AC
types (for example, one CE connected to an Ethernet port and the types (for example, one CE connected to an Ethernet port and the
other to a Frame Relay port), the IPv4 addresses are learned in other to a Frame Relay port), the IPv4 addresses are learned in
the same manner as described above. However, since the CE the same manner as described above. However, since the CE
devices are local, the distribution of IPv4 addresses for these devices are local, the distribution of IPv4 addresses for these
CE devices is a local step. CE devices is a local step.
Note that the PEs discover the IPv6 addresses of the remote CE Note that the PEs discover the IPv6 addresses of the remote CE
by intercepting Neighbor Discovery and Inverse Neighbor by intercepting Neighbor Discovery and Inverse Neighbor
Draft-ietf-l2vpn-arp-mediation-13.txt
Discovery packets that have been passed in-band through the Discovery packets that have been passed in-band through the
pseudowire. Hence, there is no need to communicate the IPv6 pseudowire. Hence, there is no need to communicate the IPv6
addresses of the CEs through LDP signaling. addresses of the CEs through LDP signaling.
Draft-ietf-l2vpn-arp-mediation-12.txt
If the pseudowire is only carrying IPv6 traffic, the address If the pseudowire is only carrying IPv6 traffic, the address
specified in the IP Address List TLV will always be zero. If the specified in the IP Address List TLV will always be zero. If the
pseudowire is carrying both IPv4 and IPv6 traffic, the pseudowire is carrying both IPv4 and IPv6 traffic, the
mechanisms used for IPV6 and IPv4 should not overlap. In mechanisms used for IPV6 and IPv4 should not overlap. In
particular, just because a PE has learned a link-layer address particular, just because a PE has learned a link-layer address
for IPv6 traffic by intercepting a Neighbor Advertisement from for IPv6 traffic by intercepting a Neighbor Advertisement from
its directly-connected CE, it should not assume that it can use its directly-connected CE, it should not assume that it can use
that link-layer address for IPv4 traffic until that fact is that link-layer address for IPv4 traffic until that fact is
confirmed by reception of, for example, an IPv4 ARP message from confirmed by reception of, for example, an IPv4 ARP message from
the CE. the CE.
LDP Based Distribution of CE IPv4 Addresses 6.2. LDP Based Distribution of CE IPv4 Addresses
[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 is to be included in the optional parameter field of TLV that is to be included in the optional parameter field of
skipping to change at page 19, line 46 skipping to change at page 20, line 4
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
Address List TLV (as specified in [RFC 3036]) in the optional Address List TLV (as specified in [RFC 3036]) in the optional
parameter TLVs. The processing of the address list TLV is as parameter TLVs. The processing of the address list TLV is as
follows. follows.
o If a pseudowire is configured for AC with IPv4 CEs only, o If a pseudowire is configured for AC with IPv4 CEs only,
the PE should advertise address list tlv with address the PE should advertise address list tlv with address
family type to be of IPv4 address. The PE should process family type to be of IPv4 address. The PE should process
the IPv4 address list TLV as described in this document. the IPv4 address list TLV as described in this document.
Draft-ietf-l2vpn-arp-mediation-13.txt
o If a pseudowire is configured for AC with both IPv4 and o If a pseudowire is configured for AC with both IPv4 and
IPv6 CEs, the PE should advertise IPv6 capability using IPv6 CEs, the PE should advertise IPv6 capability using
the procedures described in Section 7. below. the procedures described in Section 7. below.
Draft-ietf-l2vpn-arp-mediation-12.txt
o If a PE does not receive any address list TLV or IPv6 o If a PE does not receive any address list TLV or IPv6
capability advertisement, it MAY assume IPv4 behavior. The capability advertisement, it MAY assume IPv4 behavior. The
address resolution for IPv4 MUST then depend on local address resolution for IPv4 MUST then depend on local
manual configuration. manual configuration.
We use the Address List TLV as defined in [RFC 3036] to signal We use the Address List TLV as defined in [RFC 3036] to signal
the IPv4 address of the local CE. This IP address list TLV is the IPv4 address of the local CE. This IP address list TLV is
included in the optional parameter field of the Label Mapping included in the optional parameter field of the Label Mapping
message. message.
skipping to change at page 20, line 48 skipping to change at page 21, line 5
that encodes the address contained in the Address field. that encodes the address contained in the Address field.
IP Address of CE IP Address of CE
IPv4 address of the CE attached to the advertising PE. The IPv4 address of the CE attached to the advertising PE. The
encoding of the individual address depends on the Address encoding of the individual address depends on the Address
Family (which may be of value zero). Family (which may be of value zero).
The following address encodings are defined by this version of The following address encodings are defined by this version of
the protocol: the protocol:
Draft-ietf-l2vpn-arp-mediation-13.txt
Address Family Address Encoding Address Family Address Encoding
IPv4 (1) 4 octet full IPv4 address IPv4 (1) 4 octet full IPv4 address
Draft-ietf-l2vpn-arp-mediation-12.txt
The IP address field is set to all zeroes to denote that The IP address field is set to all zeroes to denote that
advertising PE has not learned the IPv4 address of its local CE. advertising PE has not learned the IPv4 address of its local CE.
Any non-zero value of the IP address field denotes the IPv4 Any non-zero value of the IP address field denotes the IPv4
address of advertising PE's attached CE device. address of advertising PE's attached CE device.
The IPv4 address of the CE is also supplied in the optional The IPv4 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 IPv4 address. change in the status of the CE's IPv4 address.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
7. IPv6 Capability Advertisement 7. IPv6 Capability Advertisement
A 'Stack Capability' Interface Parameter sub-TLV is signaled by A 'Stack Capability' Interface Parameter sub-TLV is signaled by
the two PEs so that they can agree which stack(s) they should be the two PEs so that they can agree which stack(s) they should be
using. It is assumed by default that the IP PW will always be using. It is assumed by default that the IP PW will always be
capable of carrying IPv4 packets. Thus this capability sub-TLV capable of carrying IPv4 packets. Thus this capability sub-TLV
is used to indicate if other stacks need to be supported is used to indicate if other stacks need to be supported
concurrently with IPv4. concurrently with IPv4.
Draft-ietf-l2vpn-arp-mediation-12.txt Draft-ietf-l2vpn-arp-mediation-13.txt
The 'Stack Capability' sub-TLV is part of the interface The 'Stack Capability' sub-TLV is part of the interface
parameters of the PW FEC. The proposed format for the Stack parameters of the PW FEC. The proposed format for the Stack
Capability interface parameter sub-TLV is as follows: Capability interface parameter sub-TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability | | Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 31 skipping to change at page 22, line 31
Stack capability = 0x0001 to indicate IPv6 stack capability Stack capability = 0x0001 to indicate IPv6 stack capability
The Value of Stack capability is dependent on the PW type The Value of Stack capability is dependent on the PW type
context. For IP PW type, a setting of 0x0001 indicates IPv6 context. For IP PW type, a setting of 0x0001 indicates IPv6
stack capability. stack capability.
A PE that supports IPv6 on an IP PW MUST signal the stack A PE that supports IPv6 on an IP PW MUST signal the stack
capability sub-TLV in the initial label mapping message for the capability sub-TLV in the initial label mapping message for the
PW. The PE nodes compare the value advertised by the remote PE PW. The PE nodes compare the value advertised by the remote PE
with the local configuration and only use a capability which is with the local configuration and only use a capability which is
advertised by both. If a PE does not receive a 'stack advertised by both. If a PE that supports IPv6 does not receive
capability' sub-TLV from the far-end PE in the initial label a 'stack capability' sub-TLV from the far-end PE in the initial
mapping message, or one is received but it is set to a reserved label mapping message, or one is received but it is set to a
value, the PE MUST assume IPv4-only behavior. reserved value, the PE MUST send an unsolicited release for the
PW label with the LDP status code meaning "IP Address type
If the stack capability value in the 'stack capability' sub-TLV mismatch" (Status Code 0x0000004A).
received from the far end PE is not set to all zeros, then the
sub-TLV MUST be treated as invalid and the PE MUST release the
PW label.
The behavior of a PE that does not understand an interface The behavior of a PE that does not understand an interface
parameter sub-TLV is specified in RFC4447 [RFC4447]. parameter sub-TLV is specified in RFC4447 [RFC4447].
8. IANA Considerations 8. IANA Considerations
8.1. LDP Status messages 8.1. LDP Status messages
Draft-ietf-l2vpn-arp-mediation-12.txt
This document uses new LDP status codes, IANA already maintains This document uses new LDP status codes, IANA already maintains
a registry of name "STATUS CODE NAME SPACE" defined by [RFC a registry of name "STATUS CODE NAME SPACE" defined by [RFC
3036]. The following values are suggested for assignment: 3036]. The following values are suggested for assignment:
Draft-ietf-l2vpn-arp-mediation-13.txt
0x0000002C "IP Address of CE" 0x0000002C "IP Address of CE"
0x0000004A "IP Address Type Mismatch"
8.2. Interface Parameters 8.2. Interface Parameters
This document proposes a new Interface Parameters sub-TLV, to be This document proposes a new Interface Parameters sub-TLV, to be
assigned from the 'Pseudowire Interface Parameters Sub-TLV type assigned from the 'Pseudowire Interface Parameters Sub-TLV type
Registry'. The following value is suggested for the Parameter ID: Registry'. The following value is suggested for the Parameter ID:
0x16 "Stack capability" 0x16 "Stack capability"
IANA is also requested to set up a registry of "L2VPN PE stack IANA is also requested to set up a registry of "L2VPN PE stack
capabilities". This is a 16 bit field. Stack capability values capabilities". This is a 16 bit field. Stack capability values
0x0001 is specified in Section 7. of this document. The remaining 0x0001 is specified in Section 7. of this document. The remaining
bitfield values (0x0002 to 0x8000) are to be assigned by IANA bitfield values (0x0002,..,0x8000) are to be assigned by IANA
using the "IETF Consensus" policy defined in [RFC2434]. using the "IETF Consensus" policy defined in [RFC2434].
L2VPN PE Stack Capabilities: L2VPN PE Stack Capabilities:
Bit (Value) Description Bit (Value) Description
=============== ========================================== =============== ==========================================
Bit 0 (0x0001) - IPv6 stack capability Bit 0 (0x0001) - IPv6 stack capability
Bit 1 (0x0002) - Reserved Bit 1 (0x0002) - Reserved
Bit 2 (0x0004) - Reserved Bit 2 (0x0004) - Reserved
. .
. .
. .
Bit 14 (0x4000) - Reserved Bit 14 (0x4000) - Reserved
Bit 15 (0x8000) - Reserved Bit 15 (0x8000) - Reserved
9. Use of IGPs with IP L2 Interworking L2VPNs 9. Security Considerations
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
and behave accordingly when establishing neighbor adjacencies,
representing the network topology, and passing protocol packets.
Draft-ietf-l2vpn-arp-mediation-12.txt
9.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.
9.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.
9.3. IS-IS
The IS-IS protocol does not encapsulate its PDUs in IP, and
hence cannot be supported in IP L2 Interworking L2VPNs.
Draft-ietf-l2vpn-arp-mediation-12.txt
10. 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.
Draft-ietf-l2vpn-arp-mediation-12.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.
11. 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.
11.1. Control plane security 9.1. Control plane security
Draft-ietf-l2vpn-arp-mediation-13.txt
Control plane security pertains to establishing the LDP Control plane security pertains to establishing the LDP
connection, and to pseudowire signaling and CE IP address connection, and to pseudowire signaling and CE IP address
distribution over that LDP connection. The LDP connection distribution over that LDP connection. The LDP connection
between two trusted PEs can be achieved by each PE verifying the between two trusted PEs can be achieved by each PE verifying the
incoming connection against the configured address of the peer incoming connection against the configured address of the peer
and authenticating the LDP messages using MD5 authentication. and authenticating the LDP messages using MD5 authentication.
Pseudowire signaling between two secure LDP peers do not pose Pseudowire signaling between two secure LDP peers do not pose
security issue but mis-wiring could occur due to configuration security issue but mis-wiring could occur due to configuration
error. Some checks, such as, proper pseudowire type and other error. Some checks, such as, proper pseudowire type and other
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-12.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.
For IPv6, the preferred means of security is Secure Neighbor For IPv6, the preferred means of security is Secure Neighbor
Discover (SEND) [RFC3971]. SEND provides a mechanism for Discover (SEND) [RFC3971]. SEND provides a mechanism for
securing Neighbor Discovery packets over media (such as wireless securing Neighbor Discovery packets over media (such as wireless
links) that may be insecure and open to packet interception and links) that may be insecure and open to packet interception and
substitution. SEND is based upon cryptographic signatures of substitution. SEND is based upon cryptographic signatures of
Neighbor Discovery packets. These signatures allow the receiving Neighbor Discovery packets. These signatures allow the receiving
skipping to change at page 27, line 32 skipping to change at page 25, line 5
all SEND packet options from Neighbor Discovery packets before all SEND packet options from Neighbor Discovery packets before
forwarding into the pseudowire. If the CE devices are configured forwarding into the pseudowire. If the CE devices are configured
to only accept SEND Neighbor Discovery packets, this will lead to only accept SEND Neighbor Discovery packets, this will lead
to Neighbor Discovery failing. Thus, the CE devices must be to Neighbor Discovery failing. Thus, the CE devices must be
configured to accept non-SEND packets, even if they treat them configured to accept non-SEND packets, even if they treat them
with lower priority than SEND packets. with lower priority than SEND packets.
Because SEND cannot be used in combination with IPv6 ARP Because SEND cannot be used in combination with IPv6 ARP
Mediation, it is suggested that IPv6 ARP Mediation is only used Mediation, it is suggested that IPv6 ARP Mediation is only used
with secure Attachment Circuits. with secure Attachment Circuits.
11.2. Data plane security Draft-ietf-l2vpn-arp-mediation-13.txt
9.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
spoofed destination MAC address on the Ethernet Attachment spoofed destination MAC address on the Ethernet Attachment
Circuit. In order to avoid such hijacking, local PE may verify Circuit. In order to avoid such hijacking, local PE may verify
the source MAC address of the received frame against the MAC the source MAC address of the received frame against the MAC
address of the admitted connection. The frame is forwarded to PW address of the admitted connection. The frame is forwarded to PW
only when authenticity is verified. When spoofing is detected, only when authenticity is verified. When spoofing is detected,
PE must sever the connection with the local CE, tear down the PW PE must sever the connection with the local CE, tear down the PW
and start over. and start over.
12. Acknowledgements 10. Acknowledgements
The authors would like to thank Mathew Bocci, Yetik Serbest, The authors would like to thank Mathew Bocci, Yetik Serbest,
Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro, Shane Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro, Shane
Draft-ietf-l2vpn-arp-mediation-12.txt
Amante and other folks who participated in the discussions Amante and other folks who participated in the discussions
related to this draft. related to this draft.
13. References 11. References
13.1. Normative References 11.1. Normative References
[ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address
Resolution protocol: Or Converting Network Protocol Resolution protocol: Or Converting Network Protocol
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.
[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"
Draft-ietf-l2vpn-arp-mediation-13.txt
[RFC 2461] Narten, T., Nordmark, E. and W.Simpson, "Neighbor [RFC 2461] Narten, T., Nordmark, E. and W.Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December, 1998. December, 1998.
[RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery [RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery
for Inverse Discovery Specification", RFC 3122, for Inverse Discovery Specification", RFC 3122,
June 2001. June 2001.
[RFC 2462] Thomson, S. and Narten, T., "IPv6 Stateless [RFC 2462] Thomson, S. and Narten, T., "IPv6 Stateless
Address Autoconfiguration", RFC 2462, December Address Autoconfiguration", RFC 2462, December
1998. 1998.
[RFC 3971] Arkko, J. et al., "Secure Neighbor Discovery [RFC 3971] Arkko, J. et al., "Secure Neighbor Discovery
(SEND)", RFC 3971, March 2005. (SEND)", RFC 3971, March 2005.
[RFC2434] Narten, T et al., "Guidelines for Writing an IANA [RFC2434] Narten, T et al., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, Oct 1998 Considerations Section in RFCs", RFC 2434, Oct 1998
Draft-ietf-l2vpn-arp-mediation-12.txt
13.2. Informative References 11.2. Informative References
[L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June [L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June
2004, work in progress. 2004, work in progress.
[PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol
Control Protocol (IPCP)". Control Protocol (IPCP)".
[PPP-IPV6] RFC 2472, D. Haskin, "IP Version 6 over PPP"
[PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address
Resolution". Resolution".
[RFC 1256] S.Deering, "ICMP Router Discovery Messages". [RFC 1256] S.Deering, "ICMP Router Discovery Messages".
[RFC 3232] Reynolds and Postel, "Assigned Numbers". [RFC 3232] Reynolds and Postel, "Assigned Numbers".
14. Authors' Addresses 12. Authors' Addresses
Himanshu Shah Himanshu Shah
Draft-ietf-l2vpn-arp-mediation-13.txt
30 Nagog Park, 30 Nagog Park,
Acton, MA 01720 Acton, MA 01720
Email: hshah@force10networks.com Email: hshah@force10networks.com
Eric Rosen Eric Rosen
Cisco Systems Cisco Systems
Email: erosen@cisco.com Email: erosen@cisco.com
Waldemar Augustyn Waldemar Augustyn
Email: waldemar@wdmsys.com Email: waldemar@wdmsys.com
skipping to change at page 30, line 4 skipping to change at page 27, line 28
BT BT
Email: giles.heron@gmail.com Email: giles.heron@gmail.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
Toby Smith Toby Smith
Network Appliance, Inc. Network Appliance, Inc.
EMail: tob@netapp.com EMail: tob@netapp.com
Draft-ietf-l2vpn-arp-mediation-12.txt
Andrew G. Malis Andrew G. Malis
Verizon Verizon
EMail: Andy.g.Malis@verizon.com EMail: Andy.g.Malis@verizon.com
Steven Wright Steven Wright
Bell South Corp Bell South Corp
Email: steven.wright@bellsouth.com Email: steven.wright@bellsouth.com
Draft-ietf-l2vpn-arp-mediation-13.txt
APPENDIX A:
A.1. 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
and behave accordingly when establishing neighbor adjacencies,
representing the network topology, and passing protocol packets.
A.1.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.
A.1.2. RIP
RIP protocol broadcasts RIP advertisements every 30 seconds. If
the multicast/broadcast traffic snooping mechanism is used as
Draft-ietf-l2vpn-arp-mediation-13.txt
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.
A.1.3. IS-IS
The IS-IS protocol does not encapsulate its PDUs in IP, and
hence cannot be supported in IP L2 Interworking L2VPNs.
 End of changes. 106 change blocks. 
337 lines changed or deleted 252 lines changed or added

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