L2VPN Working Group Himanshu Shah Force10 Networks Intended Status: Proposed Standard Eric Rosen Cisco System Internet Draft Giles Heron British Telecom Vach Kompella Alcatel-Lucent June 2009 Expires: December 2009 ARP Mediation for IP Interworking of Layer 2 VPN draft-ietf-l2vpn-arp-mediation-12.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may 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 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 Shah et al Expires December 2009 [Page 1] Draft-ietf-l2vpn-arp-mediation-12.txt This Internet-Draft will expire on December 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Shah et al Expires December 2009 [Page 2] Draft-ietf-l2vpn-arp-mediation-12.txt Table of Contents Copyright Notice........................................... 2 1. Contributing Authors....................................... 4 2. Introduction............................................... 4 3. ARP Mediation (AM) function................................ 5 4. IP Layer 2 Interworking Circuit............................ 7 5. IP Address Discovery Mechanisms............................ 7 5.1. Discovery of IP Addresses of Locally Attached IPv4 CE. 8 5.1.1. Monitoring Local Traffic......................... 8 5.1.2. CE Devices Using ARP............................. 8 5.1.3. CE Devices Using Inverse ARP.....................10 5.1.4. CE Devices Using PPP............................ 10 5.1.5. Router Discovery method......................... 11 5.1.6. Manual Configuration............................ 11 5.2. How a CE Learns the IPv4 address of a remote CE...... 12 5.2.1. CE Devices Using ARP............................ 12 5.2.2. CE Devices Using Inverse ARP.................... 12 5.2.3. CE Devices Using PPP............................ 12 5.3. Discovery of IP Addresses of IPv6 CE Devices......... 13 5.3.1. Distinguishing factors between IPv4 and IPv6.... 13 5.3.2. Requirements for PE............................. 13 5.3.3. Processing of Neighbor Solicitations............ 14 5.3.4. Processing of Neighbor Advertisements........... 14 5.3.5. Processing of Inverse Neighbor Solicitations.... 15 5.3.6. Processing of Inverse Neighbor Advertisements... 16 5.3.7. Processing of Router Solicitations.............. 17 5.3.8. Processing of Router Advertisements............. 17 5.3.9. Duplicate Address Detection [RFC 2462].......... 17 6. CE IPv4 Address Signaling between PEs..................... 18 6.1. When to Signal an IPv4 address of a CE............... 18 7. IPv6 Capability Advertisement............................. 21 8. IANA Considerations....................................... 22 8.1. LDP Status messages.................................. 22 8.2. Interface Parameters................................. 23 9. Use of IGPs with IP L2 Interworking L2VPNs................ 23 9.1. OSPF................................................. 24 9.2. RIP.................................................. 24 9.3. IS-IS................................................ 24 10. Multi-domain considerations.............................. 25 11. Security Considerations.................................. 26 11.1. Control plane security.............................. 26 11.2. Data plane security................................. 27 12. Acknowledgements......................................... 27 13. References............................................... 28 13.1. Normative References................................ 28 13.2. Informative References.............................. 29 Shah et al Expires December 2009 [Page 3] Draft-ietf-l2vpn-arp-mediation-12.txt 14. Authors' Addresses....................................... 29 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 NetApps A. Malis Verizon S. Wright Bell South T. Grigoriu Alcatel-Lucent N. Hart Alcatel-Lucent A. Dolganow Alcatel-Lucent S. Amante Level3 A. Vishwanathan Force10 Networks A. Moranganti Consultant 2. Introduction Layer 2 Virtual Private Networks (L2VPN) are constructed over a Service Provider IP backbone but are presented to the Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can carry any Layer 3 protocol, but in many cases, the Layer 3 protocol is IP. Thus it makes sense to consider procedures that are optimized for IP. In a typical implementation, illustrated in the diagram below, the CE devices are connected to the Provider Edge (PE) devices via Attachment Circuits (AC). The ACs are Layer 2 links. In a pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both ACs would have to be of the same type (i.e., both Ethernet, both FR, etc.). However, if it is known that only IP traffic will be carried, the ACs can be of different technologies, provided that the PEs provide the appropriate procedures to allow the proper transfer of IP packets. Shah et al Expires December 2009 [Page 4] Draft-ietf-l2vpn-arp-mediation-12.txt +-----+ +------ -----| CE3 | | +-----+ +-----+ ......| PE3 |........... . +-----+ . . | . . | . +-----+ AC1 +-----+ Service +-----+ AC2 +-----+ | CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 | +-----+ +-----+ Backbone +-----+ +-----+ . . ........................ A CE, which is connected via a given type of AC, may use an IP Address Resolution procedure that is specific to that type of AC. For example, an Ethernet-attached IPv4 CE would use ARP [ARP] and a FR-attached CE might use Inverse ARP [INVARP]. If we are to allow the two CEs to have a Layer 2 connection between them, even though each AC uses a different Layer 2 technology, the PEs must intercept and "mediate" the Layer 2 specific address resolution procedures. In this draft, we specify the procedures for VPWS services, which the PEs must implement in order to mediate the IP address resolution mechanism. We call these procedures "ARP Mediation". Consider a Virtual Private Wire Service (VPWS) constructed between CE1 and CE2 in the diagram above. If AC1 and AC2 are of different technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), then ARP requests coming from CE1 cannot be passed transparently to CE2. PE1 must interpret the meaning of the ARP requests and mediate the necessary information with PE2 before responding. The draft uses "ARP" terminology to mean any protocol that is used to resolve IP address to Link Layer address association purposes. For instance in IPv4, ARP and InvArp protocols are used for address resolution while in IPv6 Neighbor Discovery and Inverse Neighbor Discovery protocol based on ICMPv6 is used for address resolution. 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 Shah et al Expires December 2009 [Page 5] Draft-ietf-l2vpn-arp-mediation-12.txt 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, the ARP Mediation procedure depends on whether the packets being forwarded are IPv4 or IPV6. A PE that is to perform ARP Mediation for IPv4 packets must perform the following logical steps: 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 the IP Address to the remote PE using pseudowire control signaling. 4. Notify the locally attached CE of the IP address of the remote CE. 5. Respond appropriately to ARP and Inverse ARP requests from local CE device, using IP address of remote CE and hardware address of local PE. A PE that is to perform ARP Mediation for IPv6 packets must perform the following logical steps: 1. Discover the IPv6 addresses of the locally attached CE device, together with those of the remote CE device. 2. Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received from the local CE device, learning information about the IPv6 configuration of the CE, before forwarding the packets across the VPWS to the remote PE. 3. Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the VPWS from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE, and also learning information about the IPv6 configuration of the remote CE. PEs MUST support ARP mediation for IPv4 L2 Interworking circuits. Support for IPv6 L2 interworking circuits is OPTIONAL. Shah et al Expires December 2009 [Page 6] Draft-ietf-l2vpn-arp-mediation-12.txt Details for the above-described procedures are given 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 pseudowire that carries IP datagrams as the payload. The ingress PE removes the data link header of its local Attachment Circuit and transmits the payload (an IP packet) over the pseudowire with or without the optional control word. In some cases, multiple data link headers may exist, such as bridged Ethernet PDU on ATM Attachment Circuit. In this case, ATM header as well as the Ethernet header is removed to expose the IP packet at the ingress. The egress PE encapsulates the IP packet with the data link header used on its local Attachment Circuit. The encapsulation for the IP Layer 2 Transport pseudowire is described in [RFC4447]. The "IP Layer 2 interworking circuit" pseudowire is also commonly referred to as "IP pseudowire". In the case of an IPv6 L2 Interworking Circuit, the egress PE may modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets before encapsulating the IP packet with the data link header. 5. IP Address Discovery Mechanisms An IP Layer 2 Interworking Circuit enters monitoring state immediately after the configuration. During this state it performs two functions. - Discovery of the CE IP device(s) - Establishment of the PW The establishment of the PW occurs independently from local CE IP address discovery. During the period when the PW has been established but the local CE IP device has not been discovered, only broadcast/multicast IP frames are propagated between the Attachment Circuit and pseudowire; unicast IP datagrams are dropped. The IP destination address is used to classify unicast/multicast packets. Shah et al Expires December 2009 [Page 7] Draft-ietf-l2vpn-arp-mediation-12.txt The unicast IP frames are propagated between AC and pseudowire only when CE IP devices on both Attachment Circuits have been discovered, notified and proxy functions have completed. The need to wait for address resolution completion before the unicast IP traffic can flow is simple. . PEs do not perform routing operations . Destination IP address in the packet is not necessarily that of the attached CE . On a broadcast link, there is no way to find out the MAC address of the CE based on the Destination IP address of the packet. 5.1. Discovery of IP Addresses of Locally Attached IPv4 CE A PE MUST support manual configuration of IPv4 CE addresses. This section also describes automated mechanisms by which a PE MAY also discover an IPv4 CE address. 5.1.1. Monitoring Local Traffic The PE devices may learn the IP addresses of the locally attached CEs from any IP traffic, such as link local multicast packets (e.g., destined to 224.0.0.x), and are not restricted to the operations below. 5.1.2. CE Devices Using ARP If a CE device uses ARP to determine the IP address to MAC address binding of its neighbor, the PE processes the ARP requests to learn the IP address of local CE for the local Attachment Circuit. This document mandates that there MUST be only one CE per Attachment Circuit. However, customer facing access topologies may exist whereby more than one CE appears to be connected to the PE on a single Attachment Circuit. For example, this could be the case when CEs are connected to a shared LAN that connects to the PE. In such case, the PE MUST select one local CE. The selection could be based on manual configuration or the PE may optionally use following selection criteria. In either case, manual configuration of IP address of the local CE (and its MAC address) MUST be supported. Shah et al Expires December 2009 [Page 8] Draft-ietf-l2vpn-arp-mediation-12.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.1 above) o Augment cross checking with the local IP address learned through the Router Discovery protocol (as described below in section 5.1.5). o There is still a possibility that the local PE may not receive an IP address advertisement from the remote PE and there may exist multiple local IP routers that attempt to 'connect' to remote CEs. In this situation, the local PE may use some other criteria to select one IP device from many (such as "the first ARP received"), or an operator may configure the IP address of local CE. Note that the operator does not have to configure the IP address of the remote CE (as that would be learned through pseudowire signaling). Once the local and remote CEs has been discovered for the given Attachment Circuit, the local PE responds with its own MAC address to any subsequent ARP requests from the local CE with a destination IP address matching the IP address of the remote CE. The local PE signals IP address of the CE to the remote PE and may initiate an unsolicited ARP response to notify the IP address to MAC address binding for the remote CE to local CE (again using its own MAC address). Once the ARP mediation function is completed (i.e. the PE device knows both the local and remote CE IP addresses), unicast IP frames are propagated between the AC and the established PW. The PE may periodically generate ARP request messages for the IP address of the CE as a means of verifying the continued existence of the address and its MAC address binding. The absence of a response from the CE device for a given number of retries could be used as a trigger for withdrawal of the IP address advertisement to the remote PE. The local PE would then re-enter the address resolution phase to rediscover the IP address of the attached CE. Note that this "heartbeat" scheme is needed only for broadcast links (such as Ethernet AC), where the failure of a CE device may otherwise be undetectable. Shah et al Expires December 2009 [Page 9] Draft-ietf-l2vpn-arp-mediation-12.txt 5.1.3. CE Devices Using Inverse ARP If a CE device uses Inverse ARP to determine the IP address of its neighbor, the attached PE processes the Inverse ARP request from the Attachment Circuit and responds with an Inverse ARP reply containing the IP address of the remote CE, if the address is known. If the PE does not yet have the IP address of the remote CE, it does not respond, but records 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 of notifying the IP address of the remote CE to the local CE. This is the typical mode of operation for Frame Relay and ATM Attachment Circuits. If the CE does not use Inverse ARP, the PE can still discover the IP address of local CE using the mechanisms described in section 5.1.1 and 5.1.5. 5.1.4. CE Devices Using PPP The IP Control Protocol [PPP-IPCP] describes a procedure to establish and configure IP on a point-to-point connection, including the negotiation of IP addresses. When such Attachment Circuit 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 the IP address of the remote CE during IPCP negotiation using the IP-Address option (0x03). When a PPP link completes LCP negotiations, the local PE MAY perform the following IPCP actions: o The PE learns the IP address of the local CE from the Configure-Request received with the IP-Address option (0x03). If the IP address is non-zero, PE records the address and responds with Configure-Ack. However, if the IP address is zero, PE responds with Configure-Reject (as this is a request from CE to assign it an IP address). Also, the IP address option is set with zero value in the Configure-Reject response to instruct the CE to not include that option in subsequent new Configure-Request. Shah et al Expires December 2009 [Page 10] Draft-ietf-l2vpn-arp-mediation-12.txt o If the PE receives Configure-Request without the IP- Address option, it responds with a Configure-Ack. In this case the PE is unable to learn the IP address of the local CE using IPCP and hence must rely on other means as described in sections 5.1.1 and 5.1.5. Note that in order to employ other learning mechanisms, the IPCP negotiations must have reached the open state. o If the PE does not know the IP address of the remote CE, it sends a Configure-Request without the IP-Address option. o If the PE knows the IP address of the remote CE, it sends a Configure-Request with the IP-Address option containing the IP address of the remote CE. The IPCP IP-Address option MAY be negotiated between the PE and the local CE device. Configuration of other IPCP options MAY be rejected. Other NCPs, with the exception of the Compression Control Protocol (CCP) and Encryption Control Protocol (ECP), MUST be rejected. The PE device MAY reject configuration of the CCP and ECP. 5.1.5. Router Discovery method In order to learn the IP address of the CE device for a given Attachment Circuit, the PE device may execute Router Discovery Protocol [RFC 1256] whereby a Router Discovery Request (ICMP - router solicitation) message is sent using a source IP address of zero. The IP address of the CE device is extracted from the Router Discovery Response (ICMP - router advertisement) message from the CE. It is possible that the response contains more than one router addresses with the same preference level; in which case, some heuristics (such as first on the list) is necessary. The use of the Router Discovery method by the PE is optional. 5.1.6. Manual Configuration In some cases, it may not be possible to discover the IP address of the local CE device using the mechanisms described in section 5.1 above. In such cases manual configuration MAY be used. All implementations of this draft MUST support manual configuration of the IPv4 address of the local CE. This is the only REQUIRED mode for a PE to support. Shah et al Expires December 2009 [Page 11] Draft-ietf-l2vpn-arp-mediation-12.txt 5.2. How a CE Learns the IPv4 address of a remote CE Once the local PE has received the IP address information of the remote CE from the remote PE, it will either initiate an address resolution request or respond to an outstanding request from the attached CE device. 5.2.1. CE Devices Using ARP When the PE learns IP address of the remote CE as described in section 6.1 and 6.2, it may or may not already know IP address of the local CE. If the IP address is not known, the PE must wait until it is acquired through one of the methods described in sections 5.1.1, 5.1.2 and 5.1.5. If IP address of the local CE is known, the PE may choose to generate an unsolicited ARP message to notify the local CE about the binding of the IP address of the remote CE with the PE's own MAC address. When the local CE generates an ARP request, the PE must proxy the ARP response [PROXY-ARP] using its own MAC address as the source hardware address and IP address of remote CE as the source protocol address. The PE must respond only to those ARP requests whose destination protocol address matches the IP address of the remote CE. 5.2.2. CE Devices Using Inverse ARP When the PE learns the IP address of the remote CE, it should generate an Inverse ARP request. If the Attachment Circuit requires activation (e.g. Frame Relay) the PE should activate it first before the Inverse ARP request. It should be noted, that PE might never receive the response to its own request, nor see any Inverse ARP request from the CE, in cases where CE is pre- configured with IP address of the remote CE or where the use of Inverse ARP has not been enabled. In either case the CE has used other means to learn the IP address of his neighbor. 5.2.3. CE Devices Using PPP When the PE learns the IP address of the remote CE, it should initiate a Configure-Request and set the IP-Address option to the IP address of the remote CE to notify the IP address of the remote CE to the local CE. Shah et al Expires December 2009 [Page 12] Draft-ietf-l2vpn-arp-mediation-12.txt 5.3. Discovery of IP Addresses of IPv6 CE Devices 5.3.1. Distinguishing factors between IPv4 and IPv6 The IPv6 uses ICMPv6 extensions to resolve IP address and link address associations. These are essentially IP packets as compared to ARP and invARP in IPv4 which is a separate protocol and not IP packets. The IP pseudowire can not be used to carry the ARP/invARP packets and hence requires local processing of these PDUs and signaling of IP address information between the PEs using the Pseudowire control plane. 5.3.2. Requirements for PE A PE device that supports IPv6 MUST be capable of, - Intercepting ICMPv6 Neighbor Discovery [RFC 2461] and Inverse Neighbor Discovery [RFC 3122] packets received over the AC as well as over the PW. - Record the IPv6 interface addresses and CE link-layer addresses present in these packets - Possibly modify these packets as dictated by the data link type of the egress AC (described in the following sections), and - Forward them towards the original destination The PE MUST also be capable of generating packets in order to interwork between Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND). This is specified in Sections 5.3.3. to Section 5.3.6. 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 Shah et al Expires December 2009 [Page 13] Draft-ietf-l2vpn-arp-mediation-12.txt 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 for its directly-attached CE and another list of CE IPv6 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 it when forwarding traffic between the local and far-end CEs. The PE MAY also wish to monitor the source link-layer address of data packets received from the CE, and discard packets not matching its learned CE link-layer address. 5.3.3. Processing of Neighbor Solicitations A Neighbor Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address (if provided - this will not be the case for Duplicate Address Detection) and any link-layer address provided. The packet MUST then be forwarded over the pseudowire unmodified. A Neighbor Solicitation received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the local 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 link-layer address with which to transmit data packets. When a PE with a local AC of the type point-to-point link receives a Neighbor Solicitation over the pseudowire, after learning the far-end CE's IP address, the PE may use either of the following handling 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. 5.3.4. Processing of Neighbor Advertisements Shah et al Expires December 2009 [Page 14] Draft-ietf-l2vpn-arp-mediation-12.txt A Neighbor Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address and any link-layer address provided. The packet MUST then be forwarded over the pseudowire unmodified. A Neighbor Advertisement received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the local CE has no valid link-layer address with which to transmit data packets. When a PE with a local AC of the type point-to-point link receives a Neighbor Advertisement over the pseudowire, it should 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 An Inverse Neighbor Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address and the link-layer addresses. The packet may optionally 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. An Inverse Neighbor Solicitation received over the pseudowire SHOULD be inspected to determine and learn one or more interface addresses for the far-end CE. If the local AC supports Inverse Neighbor Discovery (e.g., a Frame Relay AC), the packet may be forwarded to the local CE, after modifying the link-layer address options to match the type of the local AC. Shah et al Expires December 2009 [Page 15] Draft-ietf-l2vpn-arp-mediation-12.txt If the local AC does not support Inverse Neighbor Discovery (IND), processing of the packet depends on whether the PE has learned at least one interface address for its directly-attached CE. If it has learned at least one interface address for the CE, the PE MUST discard the Inverse Neighbor Solicitation (INS) and generate an Inverse Neighbor Advertisement (INA) back into the pseudowire. The destination address of the INA is the source address from the INS, the source address is one of the local CE's interface addresses, and all the local CE's interface addresses that have been learned so far SHOULD BE included in the Target Address List. The Source and Target Link-Layer addresses are copied from the INS. In addition, the PE should generate ND advertisement on the local AC using IP address of the remote CE and MAC address of the local PE. The INS MUST be discarded if the PE has not yet learned at least one interface address for its directly-connected CE. This processing continues until the PE learns an address from the local CE (through receiving, for example, a Neighbor Solicitation). After this has occurred, the PE will be able to respond to INS messages received over the pseudowire. 5.3.6. Processing of Inverse Neighbor Advertisements An Inverse Neighbor Advertisement (INA) received on an AC from a local CE SHOULD be inspected to determine and learn one or more interface addresses for the CE. It MUST then be forwarded unmodified over the pseudowire. An INA received over the pseudowire SHOULD be inspected to determine and learn one or more interface addresses for the far- end CE. If the local AC supports Inverse Neighbor Discovery (e.g., a Frame Relay AC), the packet MAY be forwarded to the local CE, after modifying the link-layer address options to match the type of the local AC. If the local AC does not support Inverse Neighbor Discovery, the PE MUST discard the INA and generate a Neighbor Advertisement (NA) towards its local CE. The source address of the NA is the source address from the INA, the destination address is the destination address from the INA and the link-layer address is that of the local AC on the PE. Shah et al Expires December 2009 [Page 16] Draft-ietf-l2vpn-arp-mediation-12.txt 5.3.7. Processing of Router Solicitations A Router Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an interface address for the CE, and, if present, the link-layer address of the CE. It MUST then be forwarded unmodified over the pseudowire. A Router Solicitation received over the pseudowire SHOULD be inspected to determine and learn an interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option specifying the link-layer address of its local AC. The packet is then forwarded to the local CE. 5.3.8. Processing of Router Advertisements A Router Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an interface address for the CE, and, if present, the link-layer address of the CE. It MUST then be forwarded unmodified over the pseudowire. A Router Advertisement received over the pseudowire SHOULD be inspected to determine and learn an interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option specifying the link-layer address of its AC. If an MTU option is present, the PE MAY reduce the specified MTU if the MTU of the pseudowire is less than the value specified in the option. The packet is then forwarded to the local CE. 5.3.9. Duplicate Address Detection [RFC 2462] Duplicate Address Detection allows IPv6 hosts and routers to ensure that the addresses assigned to interfaces are unique on a link. As with all Neighbor Discovery packets, those used in Duplicate Address Detection will simply flow through the pseudowire, being inspected at the PEs at each end. Processing is performed as above. However, the source address of Neighbor Solicitations used in Duplicate Address Detection is the unspecified address, so the PEs can not Shah et al Expires December 2009 [Page 17] Draft-ietf-l2vpn-arp-mediation-12.txt learn the CE's interface address (nor would it make sense to do so, given that at least one address is tentative at that time). 6. CE IPv4 Address Signaling between PEs 6.1. When to Signal an IPv4 address of a CE A PE device advertises the IPv4 address of the attached CE only when the encapsulation type of the pseudowire is IP Layer2 Transport (the value 0x0000B, as defined in [PWE3-IANA]). It is quite possible that the IPv4 address of a CE device is not available at the time the PW labels are signaled. For example, in Frame Relay the CE device sends an inverse ARP request only when the DLCI is active. If the PE signals the DLCI to be active only when it has received the IPv4 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 IPv4 address of the CE is known and hence uses IPv4 address value zero. When the IPv4 address of the CE device does become available, the PE re-advertises the PW FEC along with the IPv4 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 IPv4 traffic is suspended, but multicast IPv4 traffic can continue to flow between the AC and the pseudowire. 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 other to a Frame Relay port), the IPv4 addresses are learned in the same manner as described above. However, since the CE devices are local, the distribution of IPv4 addresses for these CE devices is a local step. Note that the PEs discover the IPv6 addresses of the remote CE by intercepting Neighbor Discovery and Inverse Neighbor Discovery packets that have been passed in-band through the pseudowire. Hence, there is no need to communicate the IPv6 addresses of the CEs through LDP signaling. Shah et al Expires December 2009 [Page 18] Draft-ietf-l2vpn-arp-mediation-12.txt If the pseudowire is only carrying IPv6 traffic, the address specified in the IP Address List TLV will always be zero. If the pseudowire is carrying both IPv4 and IPv6 traffic, the mechanisms used for IPV6 and IPv4 should not overlap. In particular, just because a PE has learned a link-layer address for IPv6 traffic by intercepting a Neighbor Advertisement from its directly-connected CE, it should not assume that it can use that link-layer address for IPv4 traffic until that fact is confirmed by reception of, for example, an IPv4 ARP message from the CE. LDP Based Distribution of CE IPv4 Addresses [RFC4447] uses Label Distribution Protocol (LDP) transport to exchange PW FECs in the Label Mapping message in the Downstream Unsolicited (DU) mode. The PW FEC comes in two flavors; PWid and Generalized ID FEC elements and has some common fields between them. The discussions below refer to these common fields for IP L2 Interworking encapsulation. In addition to PW-FEC, this document defines an IP address list TLV that is to 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 [RFC4447]. As defined in [RFC4447], when processing a received PW FEC, the PE matches the PW ID and PW type with the locally configured PW ID and PW Type. If there is a match and if the PW Type is IP Layer2 Transport, the PE further checks for the presence of an Address List TLV (as specified in [RFC 3036]) in the optional parameter TLVs. The processing of the address list TLV is as follows. o If a pseudowire is configured for AC with IPv4 CEs only, the PE should advertise address list tlv with address family type to be of IPv4 address. The PE should process the IPv4 address list TLV as described in this document. o If a pseudowire is configured for AC with both IPv4 and IPv6 CEs, the PE should advertise IPv6 capability using the procedures described in Section 7. below. Shah et al Expires December 2009 [Page 19] Draft-ietf-l2vpn-arp-mediation-12.txt o If a PE does not receive any address list TLV or IPv6 capability advertisement, it MAY assume IPv4 behavior. The address resolution for IPv4 MUST then depend on local manual configuration. 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 included in the optional parameter field of the Label Mapping message. The Address List TLV is only used for IPv4 addresses. Encoding of the IP Address List TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | IP Address of CE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Address of CE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length 6 bytes: 2 bytes for address family and 4 bytes of IPv4 address. Address Family Two octet quantity containing a value from the ADDRESS FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 3232] that encodes the address contained in the Address field. IP Address of CE IPv4 address of the CE attached to the advertising PE. The encoding of the individual address depends on the Address Family (which may be of value zero). The following address encodings are defined by this version of the protocol: Address Family Address Encoding IPv4 (1) 4 octet full IPv4 address Shah et al Expires December 2009 [Page 20] Draft-ietf-l2vpn-arp-mediation-12.txt The IP address field is set to all zeroes to denote that advertising PE has not learned the IPv4 address of its local CE. Any non-zero value of the IP address field denotes the IPv4 address of advertising PE's attached CE device. The IPv4 address of the CE is also supplied in the optional parameters field of the LDP Notification message along with the PW FEC. The LDP Notification message is used to signal any change in the status of the CE's IPv4 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 List TLV (as defined above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC or Generalized ID FEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x0000002C "IP address of CE", to indicate that IP Address update follows. Since this notification does not refer to any particular message the Message Id, and Message Type fields are set to 0. [note: Status Code 0x0000002C is pending IANA allocation]. The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. 7. IPv6 Capability Advertisement A 'Stack Capability' Interface Parameter sub-TLV is signaled by 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 capable of carrying IPv4 packets. Thus this capability sub-TLV is used to indicate if other stacks need to be supported concurrently with IPv4. Shah et al Expires December 2009 [Page 21] Draft-ietf-l2vpn-arp-mediation-12.txt The 'Stack Capability' sub-TLV is part of the interface parameters of the PW FEC. The proposed format for the Stack Capability interface parameter sub-TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | Stack Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter ID = 0x16 Length = 4 Stack capability = 0x0001 to indicate IPv6 stack capability The Value of Stack capability is dependent on the PW type context. For IP PW type, a setting of 0x0001 indicates IPv6 stack capability. A PE that supports IPv6 on an IP PW MUST signal the stack capability sub-TLV in the initial label mapping message for the PW. The PE nodes compare the value advertised by the remote PE with the local configuration and only use a capability which is advertised by both. If a PE does not receive a 'stack capability' sub-TLV from the far-end PE in the initial label mapping message, or one is received but it is set to a reserved value, the PE MUST assume IPv4-only behavior. If the stack capability value in the 'stack capability' sub-TLV 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 parameter sub-TLV is specified in RFC4447 [RFC4447]. 8. IANA Considerations 8.1. LDP Status messages Shah et al Expires December 2009 [Page 22] Draft-ietf-l2vpn-arp-mediation-12.txt This document uses new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by [RFC 3036]. The following values are suggested for assignment: 0x0000002C "IP Address of CE" 8.2. Interface Parameters This document proposes a new Interface Parameters sub-TLV, to be assigned from the 'Pseudowire Interface Parameters Sub-TLV type Registry'. The following value is suggested for the Parameter ID: 0x16 "Stack capability" IANA is also requested to set up a registry of "L2VPN PE stack capabilities". This is a 16 bit field. Stack capability values 0x0001 is specified in Section 7. of this document. The remaining bitfield values (0x0002 to 0x8000) are to be assigned by IANA using the "IETF Consensus" policy defined in [RFC2434]. L2VPN PE Stack Capabilities: Bit (Value) Description =============== ========================================== Bit 0 (0x0001) - IPv6 stack capability Bit 1 (0x0002) - Reserved Bit 2 (0x0004) - Reserved . . . Bit 14 (0x4000) - Reserved Bit 15 (0x8000) - Reserved 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. Shah et al Expires December 2009 [Page 23] 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. Shah et al Expires December 2009 [Page 24] 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. Shah et al Expires December 2009 [Page 25] 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 planes; control plane and data plane. 11.1. Control plane security Control plane security pertains to establishing the LDP connection, and to pseudowire signaling and CE IP address distribution over that LDP connection. The LDP connection between two trusted PEs can be achieved by each PE verifying the incoming connection against the configured address of the peer and authenticating the LDP messages using MD5 authentication. Pseudowire signaling between two secure LDP peers do not pose security issue but mis-wiring could occur due to configuration error. Some checks, such as, proper pseudowire type and other pseudowire options may prevent mis-wiring due to configuration errors. Learning the IP address of the appropriate CE can be a security issue. It is expected that the Attachment Circuit to the local CE will be physically secured. If this is a concern, the PE must be configured with IP and MAC address of the CE when connected with Ethernet or IP and virtual circuit information (DLCI or VPI/VCI when connected over Frame Relay or ATM and IP address only when connected over PPP). During each ARP/inARP frame Shah et al Expires December 2009 [Page 26] Draft-ietf-l2vpn-arp-mediation-12.txt processing, the PE must verify the received information against local configuration before forwarding the information to the remote PE to protect against hijacking the connection. For IPv6, the preferred means of security is Secure Neighbor Discover (SEND) [RFC3971]. SEND provides a mechanism for securing Neighbor Discovery packets over media (such as wireless links) that may be insecure and open to packet interception and substitution. SEND is based upon cryptographic signatures of Neighbor Discovery packets. These signatures allow the receiving node to detect packet modification and confirm that a received packet originated from the claimed source node. SEND is incompatible with the Neighbor Discovery packet modifications described in this document. As such, SEND cannot be used for Neighbor Discovery across an ARP Mediation pseudowire. PEs taking part in IPv6 ARP Mediation must remove all SEND packet options from Neighbor Discovery packets before forwarding into the pseudowire. If the CE devices are configured to only accept SEND Neighbor Discovery packets, this will lead to Neighbor Discovery failing. Thus, the CE devices must be configured to accept non-SEND packets, even if they treat them with lower priority than SEND packets. Because SEND cannot be used in combination with IPv6 ARP Mediation, it is suggested that IPv6 ARP Mediation is only used with secure Attachment Circuits. 11.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. 12. Acknowledgements The authors would like to thank Mathew Bocci, Yetik Serbest, Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro, Shane Shah et al Expires December 2009 [Page 27] Draft-ietf-l2vpn-arp-mediation-12.txt Amante and other folks who participated in the discussions related to this draft. 13. References 13.1. Normative References [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware". [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution Protocol". [RFC4447] L. Martini et al., "Pseudowire Setup and Maintenance using LDP", RFC 4447. [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) ", RFC 4446. [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels" [RFC 3036] L.Anderssen et al., "LDP Specification" [RFC 2461] Narten, T., Nordmark, E. and W.Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. [RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001. [RFC 2462] Thomson, S. and Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC 3971] Arkko, J. et al., "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC2434] Narten, T et al., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, Oct 1998 Shah et al Expires December 2009 [Page 28] Draft-ietf-l2vpn-arp-mediation-12.txt 13.2. Informative References [L2VPN-FRM] L. Andersson et al., "Framework for L2VPN", June 2004, work in progress. [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)". [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". [RFC 1256] S.Deering, "ICMP Router Discovery Messages". [RFC 3232] Reynolds and Postel, "Assigned Numbers". 14. Authors' Addresses Himanshu Shah 30 Nagog Park, Acton, MA 01720 Email: hshah@force10networks.com Eric Rosen Cisco Systems Email: erosen@cisco.com Waldemar Augustyn Email: waldemar@wdmsys.com Giles Heron BT Email: giles.heron@gmail.com Sunil Khandekar and Vach Kompella Email: sunil@timetra.com Email: vkompella@timetra.com Toby Smith Network Appliance, Inc. EMail: tob@netapp.com Shah et al Expires December 2009 [Page 29] Draft-ietf-l2vpn-arp-mediation-12.txt Andrew G. Malis Verizon EMail: Andy.g.Malis@verizon.com Steven Wright Bell South Corp Email: steven.wright@bellsouth.com Shah et al Expires December 2009 [Page 30]