L2TPEXT Working Group C. Pignataro Internet-Draft W. Luo Expires: August 18, 2006 Cisco Systems, Inc. February 14, 2006 Signaling and Encapsulation for the Transport of IP over L2TPv3 draft-ietf-l2tpext-pwe3-ip-02.txt Status of this Memo 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. 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 August 18, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document defines the control messaging, signaling procedures and encapsulation specifics of how to tunnel IPv4 and IPv6 packets directly over L2TPv3. Requirements Language Pignataro & Luo Expires August 18, 2006 [Page 1] Internet-Draft IP over L2TPv3 February 2006 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Control Connection Establishment . . . . . . . . . . . . . . . 4 3. Session Establishment and IP Interface Status Notification . . 5 3.1. L2TPv3 Session Establishment . . . . . . . . . . . . . . . 5 3.2. L2TPv3 Session Teardown . . . . . . . . . . . . . . . . . 7 3.3. L2TPv3 Session Maintenance . . . . . . . . . . . . . . . . 7 3.4. Use of Circuit Status AVP for IP Transport Pseudowires . . 7 4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Data Packet Encapsulation . . . . . . . . . . . . . . . . 8 4.2. Data Packet Sequencing . . . . . . . . . . . . . . . . . . 9 4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 9 5. Point-to-Point Address Resolution Considerations . . . . . . . 10 5.1. Static Address Resolution . . . . . . . . . . . . . . . . 10 5.2. Dynamic ARP Mediation . . . . . . . . . . . . . . . . . . 11 5.2.1. CE IP Address AVP usage . . . . . . . . . . . . . . . 12 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. Pseudowire Type . . . . . . . . . . . . . . . . . . . . . 15 8.2. Control Message Attribute Value Pairs (AVPs) . . . . . . . 15 8.3. Result Code AVP Values . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9.1. Preventing forwarding loops with Ethernet and VLAN ACs . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Pignataro & Luo Expires August 18, 2006 [Page 2] Internet-Draft IP over L2TPv3 February 2006 1. Introduction The Layer 2 Tunneling Protocol - Version 3 (L2TPv3) [RFC3931] defines a base protocol for Layer 2 Tunneling over IP networks. This document describes the specifics necessary for tunneling IPv4 and IPv6 packets over L2TPv3. Such emulated circuits are referred to as IP Transport Pseudowires (IP PWs). One application of IP PWs is to interconnect Attachment Circuits of disparate Layer 2 protocols by locally terminating the Layer 2 and transporting IP datagrams directly over L2TPv3 sessions. This document refers to these Attachment Circuits as IP interfaces. Protocol specifics defined in this document for L2TPv3 IP PWs include those necessary for simple point-to-point (e.g., between two L2TPv3 nodes) IP PW signaling, IP datagram encapsulation, address resolution considerations and simple interface up and interface down notifications. This document also defines a new AVP to be used in point-to-point IP PWs. The reader is expected to be very familiar with the terminology and protocol constructs defined in [RFC3931]. 1.1. Abbreviations AC Attachment Circuit CE Customer Edge (Typically also the L2TPv3 Remote System). IP PW IP Transport Pseudowire LAC L2TP Access Concentrator (See [RFC3931]) LCCE L2TP Control Connection Endpoint (See [RFC3931]) NSP Native Service Processing PE Provider Edge (Typically also the LCCE). PW Pseudowire 1.2. Requirements The Pseudowire architecture [RFC3985] defines a Native Service Processing (NSP) function to restrict a Pseudowire to homogeneous operation by having the NSP perform actions that need knowledge of the semantics of the payload. Pignataro & Luo Expires August 18, 2006 [Page 3] Internet-Draft IP over L2TPv3 February 2006 The following figure depicts the PW termination and NSP function within an LCCE: +---------------------------------------+ | LCCE | +-+ +-----+ +------+ +------+ +-+ |P| |IP PW| | PW | | PSN | |P| AC (IP <==>|h|<=>| NSP |<=>| Term |<=>|Tunnel|<=>|h|<==> PSN Interface) |y| | | | | | | |y| +-+ +-----+ +------+ +------+ +-+ | | +---------------------------------------+ Figure 1: Requirements for IP PWs In IP Transport, the NSP function acts as the interface between the AC and the PW termination, and performs the following operations: o Terminates the data link layer. o Extracts IP datagrams from the Layer 2 frames and injects them into the PW. o Drops non-IP payloads. o Performs Address Resolution mediation and proxy functions (optionally). To the right of the NSP in Figure 1, only IP datagrams are forwarded to the PW termination point. The PW termination point receives raw IP datagrams and delivers them unaltered to the PW termination point on the remote LCCE, providing an IP Transport emulation service. Consequently, in one application, the IP PW emulation allows for interworking between Attachment Circuits of different Layer 2 technologies. 2. Control Connection Establishment In order to tunnel IP datagrams over an IP packet switched network using L2TPv3, an L2TPv3 Control Connection MUST first be established as described in [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP Control Message MUST include the IP Transport Pseudowire Type of 0x000B (See IANA Considerations Section), in the Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931]. Signaling such a capability in the control messages indicates that L2TP sessions support IP PWs. Pignataro & Luo Expires August 18, 2006 [Page 4] Internet-Draft IP over L2TPv3 February 2006 An LCCE MUST be able to uniquely identify itself in the SCCRQ and SCCRP messages via a globally unique value. This is advertised via the structured Router ID AVP [RFC3931], though the unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as well. 3. Session Establishment and IP Interface Status Notification This section specifies how the status of the IP interface is reported between two LCCEs, and the associated L2TP session creation and deletion that occurs. 3.1. L2TPv3 Session Establishment Associating an IP interface with a PW and its transition to "Ready" or "Up" results in the establishment of an L2TP session via the standard three-way handshake described in Section 3.4.1 of [RFC3931]. For the purposes of this discussion, the action of locally associating an IP interface with a PW by local configuration or otherwise is referred to as "provisioning" the interface. The transition of the interface to "ready" or "up" will be referred to as the interface becoming ACTIVE. The transition of the interface to "not-ready" or "down" will be referred to as the interfacing becoming INACTIVE. An LCCE MAY initiate the session immediately upon association with an IP interface, or wait until the interface becomes ACTIVE before attempting to establish an L2TP session. The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], Attribute Type 68, MUST be present in the ICRQ messages and MUST include the Pseudowire Type of 0x000B for IP PWs. The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ, ICRP messages and MAY be present in the SLI message for IP PWs. The Interface Maximum Transmission Unit AVP defined in Section 4.3 of [I-D.ietf-l2tpext-l2vpn], Attribute Type 91, MAY be present in the ICRQ and ICRP messages. When an LCCE receives an Interface MTU AVP with an MTU value different from its own, it MAY respond with a CDN with a result code of 23 indicating Mismatching interface MTU. Pignataro & Luo Expires August 18, 2006 [Page 5] Internet-Draft IP over L2TPv3 February 2006 Following is an example of the L2TP messages exchanged for an IP PW which is initiated after an IP interface is provisioned and becomes ACTIVE. LCCE (LAC) A LCCE (LAC) B ------------------ ------------------ IP Interface Provisioned IP Interface Provisioned IP Interface ACTIVE ICRQ (status = 0x03) ----> IP Interface ACTIVE <---- ICRP (status = 0x03) L2TP session established, OK to send data into tunnel ICCN -----> L2TP session established, OK to send data into tunnel In the example above, an ICRQ is sent after the interface is provisioned and becomes ACTIVE. The Circuit Status AVP (see Section 3.4) indicates that this link is ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be present in the ICRQ in order to identify the IP Transport AC (together with the identity of the LCCE itself as defined in Section 2) to associate the L2TP session with. The Remote End ID AVP defined in [RFC3931] is of opaque form and variable length, though an implementation MUST at a minimum support use of an unstructured four-octet value that is known to both LCCEs (either by direct configuration, or some other means). The exact method of how this value is configured, retrieved, discovered, or otherwise determined at each LCCE is outside the scope of this document. As with the ICRQ, the ICRP is sent only after the associated IP interface transitions to ACTIVE as well. If LCCE B had not been provisioned for the interface identified in the ICRQ, a CDN would have been immediately returned indicating that the associated link was not provisioned or available at this LCCE. LCCE A SHOULD then exhibit a periodic retry mechanism. If so, the period and maximum number of retries MUST be configurable. An Implementation MAY send an ICRQ or ICRP before an IP interface is ACTIVE, as long as the Circuit Status AVP reflects that the link is INACTIVE and an SLI is sent when the IP interface becomes ACTIVE (see Pignataro & Luo Expires August 18, 2006 [Page 6] Internet-Draft IP over L2TPv3 February 2006 Section 3.3). The ICCN is the final stage in the session establishment, confirming the receipt of the ICRP with acceptable parameters to allow bidirectional traffic. 3.2. L2TPv3 Session Teardown In the event a link is removed (unprovisioned) at either LCCE, the associated L2TP session MUST be torn down via the CDN message defined in Section 3.4.3 of [RFC3931]. General Result Codes regarding L2TP session establishment are defined in [RFC3931]. 3.3. L2TPv3 Session Maintenance IP PWs over L2TP make use of the Set Link Info (SLI) control message defined in [RFC3931] to signal IP interface status notifications between PEs. The SLI message is a single message that is sent over the L2TP control channel, signaling the interface state change. The SLI message MUST be sent any time there is a status change of the Active value identified in the Circuit Status AVP. The only exception to this is the initial ICRQ, ICRP and CDN messages which establish and teardown the L2TP session itself. The SLI message may be sent from either PE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup). All sessions established by a given control connection utilize the L2TP Hello facility defined in [RFC3931] for session keepalive. This gives all sessions basic dead peer and path detection between PEs. 3.4. Use of Circuit Status AVP for IP Transport Pseudowires IP Transport reports Circuit Status with the Circuit Status AVP defined in [RFC3931], Attribute Type 71. For reference, this AVP is shown below: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |N|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Value is a 16 bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 when sending, and ignored upon receipt. Pignataro & Luo Expires August 18, 2006 [Page 7] Internet-Draft IP over L2TPv3 February 2006 The N (New) bit SHOULD be set to one (1) if the Circuit Status indication is for a new IP interface, zero (0) otherwise. The A (Active) bit indicates whether the IP interface is ACTIVE (1) or INACTIVE (0). 4. Encapsulation 4.1. Data Packet Encapsulation IP PWs use the default encapsulations defined in [RFC3931] for demultiplexing, sequencing, and flags. The L2TPv3 encapsulation carrying an IP datagram 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie (optional, maximum 64 bits)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Default L2-Specific Sublayer (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP datagram | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Because Layer 2 frames of different encapsulation are normalized into IP datagrams when transporting over the IP over L2TP Pseudowire, it becomes possible to interconnect a pair of disparate attachment circuits. In consequence, the IP PW does not have any operational mode contraints, (i.e., it can either operate in an "interface to interface" fashion, "virtual circuit to virtual circuit" fashion, or hybrid "interface to virtual circuit" fashion). For example one AC can be a Frame-Relay DLCI while the other AC can be a PPP interface; or one AC can be an ATM PVC, while the other AC can be an ethernet VLAN. The Layer 2 is terminated on the LAC, the IPv4 or IPv6 datagram extracted and transported over the IP PW. If a non-IP packet is received over the AC, it MUST be dropped and not transported over the Pignataro & Luo Expires August 18, 2006 [Page 8] Internet-Draft IP over L2TPv3 February 2006 PW. 4.2. Data Packet Sequencing Data Packet Sequencing MAY be enabled for IP PWs. The sequencing mechanisms described in Section 4.6.1 of [RFC3931] MUST be used for signaling sequencing support. IP PW over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer defined in Section 4.6 of [RFC3931] when sequencing is enabled, and MAY request its presence at all times. It should be noted that the following two values for the Data Sequencing AVP, Attribute Type 70, have the exact same meaning for IP PWs: 0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. As such, the value of 1 SHOULD NOT be used for IP PWs. Additionally, the requirement of sequencing MUST be signaled with the following value: 2 - All incoming data packets require sequencing. This value implies that all IPv4 and IPv6 datagrams transported include sequencing as described in Section 4.6.1 of [RFC3931]. 4.3. MTU Considerations With L2TPv3 as the tunneling protocol, the packet resulting from the encapsulation is N bytes longer than the raw IP datagram transported. The value of N depends on the following fields: L2TP Session Header: Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) Session ID - 4 octets Cookie Size - 0, 4 or 8 octets L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing) Pignataro & Luo Expires August 18, 2006 [Page 9] Internet-Draft IP over L2TPv3 February 2006 Hence the range for N in octets is: N = 4-16, for L2TPv3 data messages are over IP; N = 16-28, for L2TPv3 data messages are over UDP; (N does not include the IP header). The MTU and fragmentation implications resulting from this are discussed in Section 4.1.4 of [RFC3931]. 5. Point-to-Point Address Resolution Considerations Different data link layers implement different address resolution mechanisms. The following sections describe the two address resolution operational modes: the REQUIRED Static Address Resolution mode (see Section 5.1) and the OPTIONAL Dynamic ARP Mediation mode (see Section 5.2). 5.1. Static Address Resolution An IP PW is intended to provide point-to-point connectivity, in one application between two CE devices. When dynamic ARP mediation procedures are not used, the following considerations and requirements apply to the specific data link layers that connect PE and CE devices. o Ethernet Because only one CE device is expected to be attached to the Ethernet port, the LAC SHOULD act as proxy ARP for the segment responding with its own MAC address to all ARP requests. The LAC MUST provide a configuration option to turn off this behavior, for the cases where more than one CE device may be connected to the Ethernet port. Additionally, the LAC MAY provide an option to configure the remote CE's IP address and when doing so the LAC MUST respond with its own MAC address (source hardware address) to ARP requests for this configured IP address (destination protocol address) only. If neither of these options are provided, address resolution is achieved by configuring static ARP entries for the locally attached devices. o VLAN Same as Ethernet. o PPP The LAC MUST provide an option to configure the remote CE's IP address and use it in IPCP negotiations. Pignataro & Luo Expires August 18, 2006 [Page 10] Internet-Draft IP over L2TPv3 February 2006 o Frame-Relay Because it is expected that the CE device treats the link as point-to-point, no specific address resolution requirements are needed. For the cases where the CE device may treat the link as multi-point, the LAC MAY provide an option to configure the remote CE's IP address and use it when replying to Inverse ARP messages from the local CE; additionally, when the CE device treats the link as multi-point, address resolution can be achieved by a static Inverse ARP configuration at the CE device. o ATM Same as Frame-Relay o HDLC The CE MUST treat the link as point-to-point. Note that for Ethernet and VLAN links, the PE device MUST discover the MAC address of the locally attached CE device, and MAY use the procedures in [I-D.ietf-l2vpn-arp-mediation] to do so. This discovery is a local process that does not affect interoperability. 5.2. Dynamic ARP Mediation The IP Transport NSP function MAY implement dynamic ARP mediation mechanisms and procedures to signal the CE IP addresses between PE devices for point-to-point IP PWs, and SHOULD follow [I-D.ietf-l2vpn- arp-mediation] if doing so. The dynamic ARP mediation defined in [I-D.ietf-l2vpn-arp-mediation] outlines a three-step procedure for PE devices: 1. Discover the IP addresses of the locally attached CE device. 2. Distribute those IP Addresses to the remote PE. 3. Notify the locally attached CE of the remote CE's IP address. The dynamic ARP mediation procedures for L2TPv3 IP PWs make use of steps 1 and 3 and define the signaling procedures for step 2. Additionally, if the AC data link layer is Ethernet or VLAN, the PE device also needs to discover the MAC address of the locally attached CE device and MAY use the procedures in [I-D.ietf-l2vpn-arp- mediation]. When using the Dynamic ARP Mediation signaling procedures for L2TPv3 IP PWs, the CE IP Address AVP, Attribute Type AVP-TBD-1, is used to distribute the CE IP address to the remote PE. Pignataro & Luo Expires August 18, 2006 [Page 11] Internet-Draft IP over L2TPv3 February 2006 The Attribute Value field for this AVP has the following format: CE IP Address AVP (ICRQ, ICRP, SLI) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | CE IP Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Address Family is a two octet quantity containing a value from the ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address contained in the CE IP Address field. The following address encodings to be used in this AVP are hereby defined: +----------------+----------------------------+ | Address Family | Address Encoding | +----------------+----------------------------+ | IPv4 (1) | 4 octet full IPv4 address | | IPv6 (2) | 16 octet full IPv6 address | +----------------+----------------------------+ Table 1 The CE IP Address encodes the IP address of the CE attached to the advertising PE. The encoding depends on the Address Family field, either a 4 octet IPv4 address or a 16 octet IPv6 address. The Length of this AVP is either 12 (when encoding an IPv4 address) or 24 (when encoding an IPv6 address). The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0). 5.2.1. CE IP Address AVP usage The presence of this AVP in an ICRQ or ICRP message indicates that the LCCE is willing to perform ARP mediation procedures. A null CE IP Address value indicates that the LCCE has not yet learned the IP address of his attached Remote System for the given address family. In this case, this AVP MUST be included in SLI messages sent asynchronously when the IP address of the local Remote System is discovered, with a non-null value denoting the IP address of the Remote System. Pignataro & Luo Expires August 18, 2006 [Page 12] Internet-Draft IP over L2TPv3 February 2006 The following example depicts the L2TP signaling messages exchanged for an IP PW establishment using the dynamic ARP Mediation procedures assuming an IPv4 address family. LCCE (LAC) A LCCE (LAC) B ------------------ ------------------ IP Interface Provisioned with ARP Mediation IP Interface Provisioned with ARP Mediation IP Interface ACTIVE ICRQ (IP address = NULL) ----> IP Interface ACTIVE <---- ICRP (IP address = NULL) L2TP session established, OK to send data into tunnel ICCN -----> L2TP session established, OK to send data into tunnel CE A's IP Address learned. SLI (IP address = CE_A) ----> CE B's IP Address learned. <---- SLI (IP address = CE_B) Likewise, this AVP MAY be re-advertised with a null CE IP Address value in an SLI message to indicate that the CE IP Address has become unavailable or is no longer valid. This mechanism serves as a CE IP Address withdrawal. Continuing with the same example, the following figure depicts the L2TP signaling message sent when PE A discovers that CE A's IP Address is no longer valid. LCCE (LAC) A LCCE (LAC) B ------------------ ------------------ CE A's IP Address invalidated. SLI (IP address = NULL) ----> Pignataro & Luo Expires August 18, 2006 [Page 13] Internet-Draft IP over L2TPv3 February 2006 If an ICRQ or ICRP message is received containing the CE IP Address AVP and the receiving LCCE is not capable, configured or willing to perform ARP mediation procedures, the session MUST be rejected via a CDN mesage with the following General Result Code: RC-TBD1: Mismatching ARP Mediation If an ICRP message is received lacking the CE IP Address AVP when the respective ICRQ was sent including this AVP, the session MUST be rejected via a CDN mesage with the same General Result Code. 6. Applicability Statement This document defines the specifics necessary for tunneling IP datagrams over L2TPv3 IP PWs. Some characteristics of the IP Transport Pseudowires are: o The length of the resulting L2TPv3 packet is longer than the encapsulated IP packet as detailed in Section 4.3. The resulting MTU and fragmentation implications and procedures are discussed in Section 4.1.4 of [RFC3931] and in Section 5 of [I-D.ietf-pwe3- fragmentation]. o Sequencing may be enabled in the IP PW by using the Default L2- Specific Sublayer to detect lost, duplicate, or out-of-order packets on a per-session basis (see Section 4.2). o To allow for payload integrity checking transparency on IP PWs using L2TP over IP or L2TP over UDP/IP, the L2TPv3 session can utilize IPSec as specified in Section 4.1.3 of [RFC3931]. In one application of IP PWs, the mechanism described in this document can be used to provide L2TPv3 sessions that connects unlike data link technologies (e.g., Ethernet and PPP) in an interworking fashion when the access service payloads are known beforehand to consist only of IP datagrams. This is achieved by terminating the Layer 2 protocol in the LCCE and transporting only the IP datagrams over L2TPv3, such that the L2TPv3 session links uniform Pseudowire terminations (i.e. IP Transport Pseudowire Type) and an NSP function provides translation from the AC before presentation to the PW and viceversa. The ACs carrying IP-framed can be interfaces (such as PPP, HDLC or Ethernet interfaces) or virtual circuits (such as Frame- Relay or ATM virtual circuits). IP PWs can in turn operate in an "interface to interface" mode, "virtual circuit to virtual circuit" mode or a hybrid "interface to virtual circuit" mode, because the Pseudowire payload is normalized and the NSP function performs operations between the Pseudowire termination and the Attachment Pignataro & Luo Expires August 18, 2006 [Page 14] Internet-Draft IP over L2TPv3 February 2006 Circuit. Because disparate attachment circuit types may be used in conjunction with an IP Pseudowire, there is an increased likelihood that an L2TPv3 session will be established to carry traffic between attachment circuits with mismatched MTU sizes, and that partial communication between CE devices over the pseudowire will result. The possibility of mismatched MTUs is avoided if the LCCEs advertise their respective attachment circuit MTU sizes using the Interface Maximum Transmission Unit AVP as described in Section 3.1. 7. Acknowledgements This document heavily borrows and adapts format and text from the "HDLC Frames over L2TPv3" Internet-Draft, and we would like to acknowledge its authors and contributors. Many thanks to Maria Alice Dos Santos, George Wilkie, Bill Storer and Mark Lewis for providing a thorough review and valuable comments and suggestions. 8. IANA Considerations 8.1. Pseudowire Type The signaling mechanisms defined in this document rely upon the assignment of an IP Transport Pseudowire Type (see Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space created as part of publication of [RFC3931]). The IP Transport Pseudowire Type is defined in Section 2 of this specification: 0x000B IP Transport Pseudowire Type. 8.2. Control Message Attribute Value Pairs (AVPs) A new AVP appears in Section 5.2 which needs assignment by IANA as described in Section 2.2 of [RFC3438]. AVP-TBD-1: CE IP Address AVP 8.3. Result Code AVP Values A new L2TP Result Code for the CDN message appears in Section 5.2.1 which need assignment by IANA as described in Section 2.3 of [RFC3438]. Pignataro & Luo Expires August 18, 2006 [Page 15] Internet-Draft IP over L2TPv3 February 2006 RC-TBD1: Mismatching ARP Mediation 9. Security Considerations The IP Transport over L2TPv3 is subject to the security considerations defined in [RFC3931] and [I-D.ietf-l2vpn-arp- mediation]. Additionaly, Section 9.1 includes a specific consideration to IP Transport Pseudowires using the Static Address Resolution procedures not present when carrying other data link types. 9.1. Preventing forwarding loops with Ethernet and VLAN ACs IP PWs are intended to provide point-to-point connectivity between two CE devices, and therefore it is expected that the CE devices be configured with a subnet mask of at least 30-bits. In an IP PW where the ACs are either Ethernet or Ethernet VLAN, an undesired side effect arises if the CE device is configured with a subnet mask shorter than 30-bits and the LCCE acts as a proxy ARP for the segment responding to all ARP requests with its own MAC Address: If an IP Address falls within the prefix in the segment but is not at either end of the PW, IP datagrams destined to it would loop back and forth until the TTL field expires. To prevent this unwanted behavior, the mechanisms defined in Section 5.1 MUST be used. They are copied verbatim as follows: Because only one CE device is expected to be attached to the Ethernet port, the LAC SHOULD act as proxy ARP for the segment responding with its own MAC address to all ARP requests. The LAC MUST provide a configuration option to turn off this behavior, for the cases where more than one CE device may be connected to the Ethernet port. Additionally, the LAC MAY provide an option to configure the remote CE's IP address and when doing so the LAC MUST respond with its own MAC address (source hardware address) to ARP requests for this configured IP address (destination protocol address) only. If neither of these options are provided, address resolution is achieved by configuring static ARP entries for the locally attached devices. 10. References 10.1. Normative References [I-D.ietf-l2vpn-arp-mediation] Shah, H., "ARP Mediation for IP Interworking of Layer 2 VPN", draft-ietf-l2vpn-arp-mediation-04 (work in Pignataro & Luo Expires August 18, 2006 [Page 16] Internet-Draft IP over L2TPv3 February 2006 progress), October 2005. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 10.2. Informative References [I-D.ietf-l2tpext-l2vpn] Luo, W., "L2VPN Extensions for L2TP", draft-ietf-l2tpext-l2vpn-06 (work in progress), January 2006. [I-D.ietf-pwe3-fragmentation] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", draft-ietf-pwe3-fragmentation-10 (work in progress), November 2005. [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. Pignataro & Luo Expires August 18, 2006 [Page 17] Internet-Draft IP over L2TPv3 February 2006 Authors' Addresses Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA Email: cpignata@cisco.com Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: luo@cisco.com Pignataro & Luo Expires August 18, 2006 [Page 18] Internet-Draft IP over L2TPv3 February 2006 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pignataro & Luo Expires August 18, 2006 [Page 19]