L2VPN Working Group Himanshu Shah Ciena Corp Internet Draft Eric Rosen Cisco System Giles Heron Tellabs Vach Kompella Alcatel June 2006 Expires: December 2006 ARP Mediation for IP Interworking of Layer 2 VPN draft-ietf-l2vpn-arp-mediation-06.txt Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 2006. IPR Disclosure Acknowledgement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Shah et al Expires December 2006 [Page 1] Draft-ietf-l2vpn-arp-mediation-06.txt Abstract The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudo-wire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudo-wire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudo-wire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. In particular, the applicability of ARP mediation to ISIS is not addressed as IS-IS PDUs are not sent over IP. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Table of Contents 1. Contributing Authors........................................3 2. Introduction................................................3 3. ARP Mediation (AM) function.................................5 4. IP Layer 2 Interworking Circuit.............................5 5. Discovery of IP Addresses of Locally Attached CE Device.....5 5.1. Monitoring Local Traffic...............................6 5.2. CE Devices Using ARP...................................6 5.3. CE Devices Using Inverse ARP...........................8 5.4. CE Devices Using PPP...................................8 5.5. Router Discovery method................................9 6. CE IP Address Signaling between PEs.........................9 6.1. When to Signal an IP address of a CE...................9 Shah et al Expires December 2006 [Page 2] Draft-ietf-l2vpn-arp-mediation-06.txt 6.2. LDP Based Distribution................................10 6.3. Out-of-band Distribution Configuration................12 7. IANA Considerations........................................12 7.1. LDP Status messages...................................12 8. How a CE Learns the IP address of remote CE................13 8.1. CE Devices Using ARP..................................13 8.2. CE Devices Using Inverse ARP..........................13 8.3. CE Devices Using PPP..................................14 9. Use of IGPs with IP L2 Interworking L2VPNs.................14 9.1. OSPF..................................................14 9.2. RIP...................................................15 10. IPV6 Considerations.......................................15 11. Multi-Segment PW consideration............................15 12. Security Considerations...................................16 12.1. Control plane security...............................16 12.2. Data plane security..................................16 13. Acknowledgements..........................................17 14. References................................................17 14.1. Normative References.................................17 14.2. Informative References...............................17 15. Authors' Addresses........................................18 Intellectual Property Statement...............................19 Disclaimer of Validity........................................19 1. Contributing Authors This document is the combined effort of the following individuals and many others who have carefully reviewed the document and provided the technical clarifications. W. Augustyn consultant T. Smith Laurel Networks A. Moranganti Big Band Networks S. Khandekar Alcatel A. Malis Tellabs S. Wright Bell South V. Radoaca Westridge Networks A. Vishwanathan Force10 Networks 2. Introduction Shah et al Expires December 2006 [Page 3] Draft-ietf-l2vpn-arp-mediation-06.txt Layer 2 Virtual Private Networks (L2VPN) are constructed over a Service Provider IP backbone but are presented to the Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can carry any Layer 3 protocol, but in many cases, the Layer 3 protocol is IP. Thus it makes sense to consider procedures that are optimized for IP. In a typical implementation, illustrated in the diagram below, the CE devices are connected to the Provider Edge (PE) devices via Attachment Circuits (AC). The ACs are Layer 2 links. In a pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both ACs would have to be of the same type (i.e., both Ethernet, both FR, etc.). However, if it is known that only IP traffic will be carried, the ACs can be of different technologies, provided that the PEs provide the appropriate procedures to allow the proper transfer of IP packets. +-----+ +--------------------| CE3 | | +-----+ +-----+ ........| PE3 |......... . +-----+ . . | . . | . +-----+ AC1 +-----+ Service +-----+ AC2 +-----+ | CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 | +-----+ +-----+ Backbone +-----+ +-----+ . . ........................ A CE, which is connected via a given type of AC, may use an IP Address Resolution procedure that is specific to that type of AC. For example, an Ethernet-attached CE would use ARP [ARP] and a FR-attached CE might use Inverse ARP [INVARP]. If we are to allow the two CEs to have a Layer 2 connection between them, even though each AC uses a different Layer 2 technology, the PEs must intercept and "mediate" the Layer 2 specific address resolution procedures. In this draft, we specify the procedures for VPWS services, which the PEs must implement in order to mediate the IP address resolution mechanism. We call these procedures "ARP Mediation". Consider a Virtual Private Wire Service (VPWS) constructed between CE1 and CE2 in the diagram above. If AC1 and AC2 are of different technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), then ARP requests coming from CE1 cannot be passed transparently to CE2. PE1 must interpret the meaning of the ARP Shah et al Expires December 2006 [Page 4] Draft-ietf-l2vpn-arp-mediation-06.txt requests and mediate the necessary information with PE2 before responding. 3. ARP Mediation (AM) function The ARP Mediation (AM) function is an element of a PE node that deals with the IP address resolution for CE devices connected via an VPWS L2VPN. By placing this function in the PE node, ARP Mediation is transparent to the CE devices. For a given point-to-point connection between a pair of CEs, a PE must perform following logical steps as part of the ARP Mediation procedure: 1. Discover the IP address of the locally attached CE device 2. Terminate, do not distribute ARP and Inverse ARP requests from CE device at local PE. 3. Distribute those IP Addresses to the remote PE 4. Notify the locally attached CE, the IP address of the remote CE. This information is gathered using the mechanisms described in the following sections. 4. IP Layer 2 Interworking Circuit The IP Layer 2 interworking Circuit refers to interconnection of the Attachment Circuit with the IP Layer 2 Transport pseudo-wire that carries IP datagrams as the payload. The ingress PE removes the data link header of its local Attachment Circuit and transmits the payload (an IP frame) over the pseudo-wire with or without the optional control word. In some cases, multiple data link headers may exist, such as bridged PDU on ATM AC. In this case, ATM header as well as the Ethernet header is removed to expose the IP frame. The egress PE encapsulates the IP packet with the data link header used on its local Attachment Circuit. The encapsulation for the IP Layer 2 Transport pseudo-wire is described in [PWE3-Control]. 5. Discovery of IP Addresses of Locally Attached CE Device Shah et al Expires December 2006 [Page 5] Draft-ietf-l2vpn-arp-mediation-06.txt An IP Layer 2 Interworking Circuit enters monitoring state immediately after the configuration. During this state it performs two functions. o Discovery of locally attached CE IP device o Establishment of the PW The establishment of the PW occurs independently from local CE IP address discovery. During the period when the PW has been established but local CE IP device has not been detected, only broadcast/multicast IP frames are propagated between the Attachment Circuit and pseudo-wire; unicast IP datagrams are dropped. On Ethernet AC, MAC Destination Address is used to classify unicast/multicast packets. However, on non-Ethernet ACs, IP destination address is used to classify unicast/multicast packets. The unicast IP frames are propagated between AC and pseudo-wire only when CE IP devices on both Attachment Circuits have been discovered, notified and proxy functions have completed. 5.1. Monitoring Local Traffic The PE devices may learn the IP addresses of the locally attached CEs from any IP traffic, such as link local multicast packets (e.g., destined to 224.0.0.x), and are not restricted to the operations below. 5.2. CE Devices Using ARP If a CE device uses ARP to determine the MAC address to IP address binding of its neighbor, the PE processes the ARP requests to learn the IP address of local CE for the stated locally attached circuit. This document mandates that only one CE per attachment circuit MUST be connected to the PE. However, customer facing access topology may exist whereby more than one CEs appear to be connected to the PE on a single attachment circuit. For example this could be the case when CEs are connected to a shared LAN that connects to the PE. In such case, the PE MUST select one local CE. The selection could be based on manual configuration or PE may optionally use following selection criteria. In either case, manual configuration of IP address of the local CE (and its MAC address) MUST be supported. Shah et al Expires December 2006 [Page 6] Draft-ietf-l2vpn-arp-mediation-06.txt o Wait to learn the IP address of the remote CE (through PW signaling) and then select the local CE that is sending the request for IP address of the remote CE. o Augment cross checking with the local IP address learned through listening of link local multicast packets (as per section 5.1 above) o Augment cross checking with the local IP address learned through the Router Discovery protocol (as described below in section 5.5). o There is still a possibility that the local PE may not receive an IP address advertisement from the remote PE and there may exist multiple local IP routers that attempt to 'connect' to remote CEs. In this situation, the local PE may use some other criteria to select one IP device from many (such as "the first ARP received"), or an operator may configure the IP address of local CE. Note that the operator does not have to configure the IP address of the remote CE (as that would be learned through pseudo-wire signaling). Once the local CE has been discovered for the given Attachment Circuit, the local PE responds to subsequent ARP requests from that device with its own MAC address when the destination IP address in the ARP request is found to match with IP address of the remote CE. The local PE signals IP address of the CE to the remote PE and may initiate an unsolicited ARP response to notify local CE MAC address to IP address binding of the remote CE. Once the ARP mediation function is completed, unicast IP frames are propagated between the AC and the established PW. The PE may periodically generate ARP request messages to the IP address of the CE as a means of verifying the continued existence of the address and its binding to the MAC address. The absence of a response from the CE device for a given number of retries could be used as a cause for withdrawal of the IP address advertisement to the remote PE. The local PE would then enter into the address resolution phase to rediscover the IP address of the attached CE. Note that this "heartbeat" scheme is needed only for broadcast links (such as Ethernet AC), as the loss of a CE may otherwise be undetectable. Shah et al Expires December 2006 [Page 7] Draft-ietf-l2vpn-arp-mediation-06.txt 5.3. CE Devices Using Inverse ARP If a CE device uses Inverse ARP to determine the IP address of its neighbor, the attached PE processes the Inverse ARP request for stated circuit and responds with an Inverse ARP reply containing the IP address of the remote CE, if the address is known. If the PE does not yet have the IP address of the remote CE, it does not respond, but notes the IP address of the local CE and the circuit information. Subsequently, when the IP address of the remote CE becomes available, the PE may initiate the Inverse ARP request as a means to notify the local CE about the IP address of the remote CE. This is a typical operation for Frame Relay and ATM attachment circuits. When the CE does not use Inverse ARP, PE could still discover the IP address of local CE as described in section 5.1 and 5.5 5.4. CE Devices Using PPP The IP Control Protocol [PPP-IPCP] describes a procedure to establish and configure IP on a point-to-point connection, including the negotiation of IP addresses. When using IP (Routed) mode L2VPN interworking, PPP negotiation is not performed end-to-end between CE devices. In this case, PPP negotiation takes place between the CE device and its local PE device (on the PPP attachment circuit). The PE device performs proxy PPP negotiation, and informs the local CE device of the IP address of the remote CE device during IPCP negotiation using the IP-Address option [0x03]. When a PPP link becomes operational after the LCP negotiations, the local PE MAY perform following actions o The PE learns the IP address of the local CE from the Configure- Request received with the IP-Address option (0x03). The PE verifies that the IP address present in the IP-Address option is non-zero. If the IP address is zero, PE responds with Configure- Reject (as this is a request from CE to assign him an IP address). Also, the Configure- Reject copies the IP-Address option with null value to instruct the CE to not include that option in new Configure-Request. If the IP address is non-zero, PE responds with Configure-Ack. Shah et al Expires December 2006 [Page 8] Draft-ietf-l2vpn-arp-mediation-06.txt o If the PE receives Configure-Request without the IP- Address option, PE responds with Configure-Ack. In this case, PE would not learn the IP address of the local CE using IPCP and hence would rely on other means as described above (such as link-local broadcast from OSPF hello). Note that in order to employ other learning mechanisms, IPCP connection must be open. o If the PE does not know the IP address of the remote CE, it generates a Configure-Request without the IP-Address option. o If the PE knows the IP address of the remote CE, it sends an IPCP Configure-Request with the IP-Address option containing the IP address of the remote CE. The IPCP IP-Address option MAY be negotiated between the PE and the local CE device. Configuration of other IPCP option MAY be rejected. Other NCPs, with the exception of the Compression Control Protocol (CCP) and Encryption Control Protocol (ECP), MUST be rejected. The PE device MAY reject configuration of the CCP and ECP. 5.5. Router Discovery method In order to learn the IP address of the CE device for a given Attachment Circuit, the PE device may execute Router Discovery Protocol [RFC 1256] whereby a Router Discovery Request (ICMP - router solicitation) message is sent using a source IP address of zero. The IP address of the CE device is extracted from the Router Discovery Response (ICMP - router advertisement) message from the CE. It is possible that the response contains more than one router addresses with the same preference level; in which case, some heuristics (such as first on the list) is necessary. The use of the Router Discovery method by the PE is optional. 6. CE IP Address Signaling between PEs 6.1. When to Signal an IP address of a CE A PE device advertises the IP address of the attached CE only when the encapsulation type of the pseudo-wire is IP Layer2 Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is quite possible that the IP address of a CE device is not Shah et al Expires December 2006 [Page 9] Draft-ietf-l2vpn-arp-mediation-06.txt available at the time the PW labels are signaled. For example, in Frame Relay the CE device sends an inverse ARP request only when the DLCI is active; if the PE signals the DLCI to be active only when it has received the IP address along with the PW FEC from the remote PE, a chicken and egg situation arises. In order to avoid such problems, the PE must be prepared to advertise the PW FEC before the IP address of the CE is known and hence uses IP address value zero. When the IP address of the CE device does become available, the PE re-advertises the PW FEC along with the IP address of the CE. Similarly, if the PE detects that an IP address of a CE is no longer valid (by methods described above), the PE must re- advertise the PW FEC with null IP address to denote the withdrawal of IP address of the CE. The receiving PE then waits for notification of the remote IP address. During this period, propagation of unicast IP traffic is suspended, but multicast IP traffic can continue to flow between the AC and the pseudo-wire. If two CE devices are locally attached to the PE where one CE is connected to an Ethernet port and the other to a Frame Relay port, for example, the IP addresses are learned in the same manner described above. However, since the CE devices are local, the distribution of IP addresses for these CE devices is a local step. 6.2. LDP Based Distribution The [PWE3-Control] uses Label Distribution Protocol (LDP) transport to exchange PW FEC in the Label Mapping message in the Downstream Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and Generalized ID FEC elements and has some common fields between them. The discussions below refer to these common fields for IP L2 Interworking encapsulation. In addition to PW-FEC, this document defines an IP address TLV that must be included in the optional parameter field of the Label Mapping message when advertising the PW FEC for the IP Layer2 Transport. The use of optional parameters in the Label Mapping message to extend the attributes of the PW FEC is specified in the [PWE3-Control]. When processing a received PW FEC, the PE matches the PW Id and PW type with the locally configured PW Id to determine if the PW FEC is of type IP Layer2 Transport. If there is a match, it further checks the presence of IP address TLV in the optional parameter field. If absent, a Label Release message is issued Shah et al Expires December 2006 [Page 10] Draft-ietf-l2vpn-arp-mediation-06.txt with a Status Code meaning "IP Address of the CE is absent" [note: Status Code 0x0000002C is pending IANA allocation] to reject the PW establishment. We use the Address List TLV as defined in RFC 3036 to signal the IP address of the local CE. This IP address TLV must be included in the optional parameter field of the Label Mapping message. Encoding of the IP Address TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | IP Address of CE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Address of CE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length When Address Family is IPV4, Length is equal to 6 bytes; 2 bytes for address family and 4 bytes of IP address. Address Family Two octet quantity containing a value from the ADDRESS FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 1700] that encodes the address contained in the Address field. IP Address of CE IP address of the CE attached to the advertising PE. The encoding of the individual address depends on the Address Family. The following address encodings are defined by this version of the protocol: Address Family Address Encoding IPv4 (1) 4 octet full IPv4 address IPv6 (2) 16 octet full IPv6 address The IP address field is set to value null to denote that advertising PE has not learned the IP address of his local CE device. The non-zero value of the IP address field denotes IP address of advertising PE's attached CE device. Shah et al Expires December 2006 [Page 11] Draft-ietf-l2vpn-arp-mediation-06.txt The IP address of the CE is also supplied in the optional parameter field of the LDP's Notification message along with the PW FEC. The LDP Notification message is used to signal the change in CE's IP address. The encoding of the LDP Notification message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address TLV (as defined above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC or Generalized ID FEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x0000002B "IP address of CE", to indicate that IP Address update follows. Since this notification does not refer to any particular message the Message Id, and Message Type fields are set to 0. [note: Status Code 0x0000002B is pending IANA allocation]. The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. 6.3. Out-of-band Distribution Configuration In some cases, it may not be possible either to deduce the IP addresses from the VPN traffic nor induce remote PEs to supply the necessary information on demand. For those cases, out-of- band methods, such as manual configuration, MAY be used. The support for manual configuration of IP address of the local CE is mandatory. 7. IANA Considerations 7.1. LDP Status messages Shah et al Expires December 2006 [Page 12] Draft-ietf-l2vpn-arp-mediation-06.txt This document uses new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The following values are suggested for assignment: 0x0000002B "IP Address of CE" 0x0000002C "IP Address of CE is absent" 8. How a CE Learns the IP address of remote CE Once the local PE has received IP address information of the remote CE from the remote PE, it will either initiate an address resolution request or respond to an outstanding request from the attached CE device. 8.1. CE Devices Using ARP When the PE learns IP address of the remote CE as described in section 6.1 and 6.2, it may or may not already know IP address of the local CE. If the IP address is not known, the PE must wait until it is acquired through one of the methods described in sections 5.1, 5.3 and 5.5. If IP address of the local CE is known, the PE may choose to generate an unsolicited ARP message to notify the local CE about the binding of the IP address of the remote CE with the PE's own MAC address. When the local CE generates an ARP request, the PE must proxy the ARP response [PROXY-ARP] using its own MAC address as the source hardware address and IP address of remote CE as the source protocol address. The PE must respond only to those ARP requests whose destination protocol address matches the IP address of the remote CE. An exception to this rule is when the strict topology of one IP end station per Attachment Circuit is assumed. In which case, PE can promiscuously respond to the ARP request of the CE with his own MAC address. 8.2. CE Devices Using Inverse ARP When the PE learns the IP address of the remote CE, it should generate an Inverse ARP request. In case, the local circuit requires activation e.g. Frame Relay, PE should activate it first before sending Inverse ARP request. It should be noted, that PE might never receive the response to its own request, nor see any CE's Inverse ARP request in cases where CE is pre- configured with remote CE IP address or the use of Inverse ARP is not enabled. In either case CE has used other means to learn the IP address of his neighbor. Shah et al Expires December 2006 [Page 13] Draft-ietf-l2vpn-arp-mediation-06.txt 8.3. CE Devices Using PPP When the PE learns the IP address of the remote CE, it should initiate the Configure-Request and set the IP-Address option to the IP address of the remote CE to notify local CE the IP address of the remote CE. 9. 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. 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 it 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 two routers that are supposedly sharing the same link type. Finally, each OSPF router generates network LSAs when connected to a broadcast link such as Ethernet, receipt of which by an OSPF router on the point-to-point link further adds to the 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. Shah et al Expires December 2006 [Page 14] Draft-ietf-l2vpn-arp-mediation-06.txt 9.2. RIP RIP protocol broadcasts RIP advertisements every 30 seconds. If the group/broadcast address snooping mechanism is used as described above, the attached PE can learn the advertising (CE) router's IP address from the IP header of the advertisement. No special configuration is required for RIP in this type of Layer 2 IP Interworking L2VPN. 10. IPV6 Considerations The support for IPV6 is not addressed in this draft and is for future study. 11. Multi-Segment PW consideration In a back-to-back configuration, when two PEs are connected with an Ethernet, ARP proxy function has limited application, as there is no local CE. Consider a Multi-Segment Pseudo-wire consisting of two pseudo-wire segments; segment 1 (PE1<->PE2) in network A and segment 2 (PE3<->PE4) in network B. In this configuration CE1 is connected to PE1 and CE2 is connected to PE4. The PE2 on network A is directly connected to PE3 in network B with an Ethernet. Since there is no CE present between PE2 and PE3, there needs a mechanism for PE2 and PE3 to discover each others MAC address to enable connectivity between CE1 and CE2 across the two networks. There are two options. o Configure IP address of CE2 as IP address of local CE at PE2 and IP address of CE1 as IP address of local CE 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 others 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) network. o The second option is to follow the procedures recommended in [MS-PW] architecture, which provides the intervening or switching PEs to remain oblivious to native PW processing. We recommend this option. Note this may mean creating a third PW segment between PE2 and PE3 for the example shown above. Shah et al Expires December 2006 [Page 15] Draft-ietf-l2vpn-arp-mediation-06.txt 12. Security Considerations The security aspect of this solution is addressed for two planes; control plane and data plane. 12.1. Control plane security The control plane security pertains to establishing the LDP connection, pseudo-wire establishment and CE's IP address distribution. The LDP connection between two trusted PEs can be achieved by each PE verifying the incoming connection against the configured address of the peer and authenticating the LDP messages using MD5 authentication. The pseudo-wire establishments between two secure LDP peers do not pose security issue but mis-wiring could occur due to configuration error. Some checks, such as, proper pseudo-wire type and other pseudo- wire options may prevent mis-wiring due to configuration errors. The learning of IP address of the appropriate CE can be a security issue. It is expected that the local attachment circuit to CE is physically secured. If this is a concern, the PE must be configured with IP and MAC address of the CE when connected with Ethernet or IP and virtual circuit information (e.g. DLCI or VPI/VCI) of the CE. During each ARP/inARP frame processing, PE must verify the received information against the configuration before accepting to protect against hijacking the connection. 12.2. Data plane security The data traffic between CE and PE is not encrypted and it is possible that in an insecure environment, a malicious user may tap into the CE to PE connection and generate traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit. In order to avoid such hijacking, local PE may verify the source MAC address of the received frame against the MAC address of the admitted connection. The frame is forwarded to PW only when authenticity is verified. When spoofing is detected, PE must sever the connection with the local CE, tear down the PW and start over. Shah et al Expires December 2006 [Page 16] Draft-ietf-l2vpn-arp-mediation-06.txt 13. Acknowledgements The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro and other folks who participated in the discussions related to this draft. 14. References 14.1. Normative References [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware". [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution Protocol". [PWE3-Control] L. Martini et al., "Pseudowire Setup and Maintenance using LDP", RFC 4447. [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", RFC 4446. [RFC 1700] Reynolds and Postel, "Assigned Numbers". [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels" 14.2. Informative References [L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June 2004, work in progress. [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)". [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". [RFC 1256] S.Deering, "ICMP Router Discovery Messages". Shah et al Expires December 2006 [Page 17] Draft-ietf-l2vpn-arp-mediation-06.txt [MS-PW] M.Bocci et al,. "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", May 2006, work in progress 15. Authors' Addresses Himanshu Shah 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Eric Rosen Cisco Systems 1414 Massachusetts Avenue, Boxborough, MA 01719 Email: erosen@cisco.com Waldemar Augustyn Email: waldemar@nxp.com Giles Heron Email: giles.heron@tellabs.com Sunil Khandekar and Vach Kompella Email: sunil@timetra.com Email: vkompella@timetra.com Toby Smith Laurel Networks Omega Corporate Center 1300 Omega drive Pittsburgh, PA 15205 Email: jsmith@laurelnetworks.com Arun Vishwanathan Force10 Networks 1440 McCarthy Blvd., Milpitas, CA 95035 Email: arun@force10networks.com Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Shah et al Expires December 2006 [Page 18] Draft-ietf-l2vpn-arp-mediation-06.txt Email: Andy.Malis@tellabs.com Steven Wright Bell South Corp Email: steven.wright@bellsouth.com Vasile Radoaca Email: vasile@westridgenetworks.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Shah et al Expires December 2006 [Page 19] Draft-ietf-l2vpn-arp-mediation-06.txt Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Shah et al Expires December 2006 [Page 20]