Network Working Group T. D. Nadeau (Editor) Internet Draft Cisco Systems, Inc. Expiration Date: February 2006 R. Aggarwal (Editor) Juniper Networks August 2005 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) draft-ietf-pwe3-vccv-06.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. Abstract This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with pseudo wire (PW) connections. VCCV supports connection verification applications for PWs regardless of the underlying public service network technology. VCCV makes use of IP-based protocols to perform operations and maintenance functions. This is accomplished by providing a control channel associated with Nadeau & Raggarwa [Page 1] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 each PW. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. Nadeau & Raggarwa [Page 2] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 Table of Contents 1 Specification of requirements ......................... 4 2 Introduction .......................................... 4 3 Overview of VCCV ...................................... 5 3.1 LSP Ping .............................................. 6 3.2 L2TPV3 ................................................ 6 3.3 Bidirectional Forwarding Detection .................... 6 4 VCCV Control Channels for PWs Demultiplexed using MPLS ....7 4.1 Inband VCCV ........................................... 7 4.2 Out-of-Band VCCV ...................................... 8 4.3 TTL Expiry VCCV ....................................... 8 5 VCCV Types ............................................ 8 5.1 MPLS LSP Ping Packet .................................. 9 5.2 Bidirectional Forwarding Detection .................... 9 6 OAM Capability Indication for PWs Demultiplexed using MPLS 10 6.1 Optional VCCV Parameter ............................... 11 7 VCCV Control Channel for L2TPv3/IP PSN ................ 12 7.1 L2TPv3 VCCV Message ................................... 13 7.1.1 L2TPv3 VCCV ICMP Ping AVP ............................. 13 7.1.2 L2TPv3 VCCV BFD AVP ................................... 13 7.2 L2TPv3 VCCV Capability Indication ..................... 13 7.2.1 L2TPv3 VCCV Capability AVP ............................ 13 7.3 L2TPv3 VCCV Operation ................................. 14 8 IANA Considerations ................................... 14 8.1 VCCV Parameter ID ..................................... 14 8.1.1 CC Types .............................................. 15 8.1.2 CV Types .............................................. 15 8.2 L2TPv3 Assignments .................................... 15 8.2.1 CV Types .............................................. 15 9 Security Considerations ............................... 15 10 Acknowledgements ...................................... 17 11 References ............................................ 17 11.1 Normative References .................................. 17 11.2 Informative References ................................ 18 12 Author Information .................................... 19 13 Intellectual Property Statement ....................... 20 14 Full Copyright Statement .............................. 20 Nadeau & Raggarwa [Page 3] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 1. Specification of requirements 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]. 2. Introduction As network operators deploy pseudo wire (PW) services, fault detec- tion and diagnostic mechanisms particularly for the PSN portion of the network are pivotal. Specifically, the ability to provide end-to- end fault detection and diagnostics for an emulated PW service is critical for the network operator. Operators have indicated in [MPLSOAMREQS][PWREQ] that such a tool is required for PW deployments. This document describes procedures for PSN-agnostic fault detection and diagnostics called Virtual Circuit Connection Verification (VCCV). |<----- Pseudo Wire ---->| | | Attachment | |<-- PSN Tunnel -->| | Attachment Circuit V V V V Circuit | +----+ +----+ | +----+ | | PE1|==================| PE2| | +----+ | |----------|............PW1.............|----------| | | CE1| | | | | | | |CE2 | | |----------|............PW2.............|----------| | +----+ | | |==================| | | +----+ ^ +----+ +----+ | ^ | Provider Edge 1 Provider Edge 2 | | | |<--------------- Emulated Service --------------->| |<---------- VCCV ------>| Customer Customer Edge 1 Edge 2 Figure 1: PWE3 VCCV Operation Reference Model Figure 1 depicts the basic functionality of VCCV. VCCV provides sev- eral means of creating a control channel between PEs that attaches the PW under test. Nadeau & Raggarwa [Page 4] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 +-------------+ +-------------+ | Layer2 | | Layer2 | | Emulated | Emulated Service | Emulated | | Services | | Services | +-------------+ +-------------+ | | VCCV/PW | | |Demultiplexer| Control Channel |Demultiplexer| +-------------+ +-------------+ | PSN | PSN Tunnel | PSN | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ | | | ____ ___ ____ | | _/ ___/ _/ __ | | / __/ _ | | / | ---------| MPLS or IP Network |----- / ___ ___ __ _/ _/ ____/ ___/ ____/ Figure 2: PWE3 Protocol Stack Reference Model including the VCCV control channel. Figure 2 depicts how the VCCV control channel is associated with the pseudo wire. Ping and other IP messages are encapsulated using the PWE3 encapsulation as described below in sections 5 and 6. These mes- sages, referred to as VCCV messages, are exchanged only after the desire to exchange such traffic has been negotiated between the PEs (see section 8). 3. Overview of VCCV VCCV defines a set of messages that are exchanged between PEs to ver- ify connectivity of the pseudo wire. To make sure that VCCV packets follow the same path as the PW data flow, they are encapsulated in the PW demultiplexer and trasported over the PSN tunnel. VCCV can operate in two modes: 1) as a diagnostic tool 2) as a fault detection tool In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, or ICMP Ping [ICMP] modes depending on the underlying PSN. Since a PW service is bi-directional, the reply SHOULD be sent over the PW in the reverse direction, that makes up the other half of the PW service Nadeau & Raggarwa [Page 5] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 under test. For example, if the PSN is MPLS, the reply should be sent over the reverse PW, which is transported over the PSN LSP in the reverse direction. If this fails, the operator may use other reply modes to determine the fault [LSP-PING]. The fault detection mode provides a way to emulate fault detection mechanisms in other technologies, such as ATM for example. For exam- ple, in the fault detection mode, the BFD Bidirectional Forwarding Detection (BFD) mechanism can be used as following: the upstream PE sends BFD control messages periodically. When the downstream PE doesn't receive these message for a defined period of time, it declares that direction of the PW down and it notifies the upstream PE. Based on the emulated service, the PEs may send native indica- tions over the related attachment circuits to notify the end points of the fault condition. The specific details of the handling of these conditions is out of the scope of this document, and are only noted here to illustrate the utility of VCCV for these purposes. 3.1. LSP Ping When PWs are demultiplexed using MPLS, LSP Ping is used as described in [LSP-PING] as a connectivity verification and diagnostic tool for PWs. The PSN may be MPLS or IP. 3.2. L2TPV3 When IP is used as the PSN, various protocols can be deployed for PW Demultiplexing [PWEARCH]. If L2TP or UDP is used, ICMP ECHO packets [ICMP] can be used as the means by which connectivity verification is achieved. 3.3. Bidirectional Forwarding Detection When fault detection indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [BFD] provides a light- weight means of continuous monitoring and propagation of forward and reverse defect indications. BFD can be used regardless of the under- lying PSN technology. Nadeau & Raggarwa [Page 6] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 4. VCCV Control Channels for PWs Demultiplexed using MPLS In order to apply IP monitoring tools to PWE3 circuits, VCCV creates a control channel between PWE3 PEs [PWEARCH]. Packets sent across this channel are IP packets, allowing maximum flexibility. Ideally such a control channel would be completely in band. When a control word is present on virtual circuit, it is possible to indi- cate the control channel by setting a bit in the control header. This method is described in section 4.1 and is referred to as PWE3 inband VCCV. 4.1. Inband VCCV The PW set-up protocol [PWSIG] determines whether a PW uses a control word. When a control word is used, it SHOULD have the following form for the purpose of indicating VCCV control channel messages. (Note that for data, one uses the control word defined just above the MPLS payload [PWEARCH].) The PW Associated Channel for VCCV control channel traffic is defined as follows in [PW-CW]: 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 0 1| FmtID | Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PW Associated Channel Header The first nibble is set to 0x0001. The Format ID and the reserved fields are set to 0 and the channel type is used as defined in [PW- CW, PWE3IANA]. For example, the following is an example of how the ethernet control word would be received [ENETENCAP]: 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 0 1| 0 | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PW Associated Channel Header for VCCV Nadeau & Raggarwa [Page 7] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 It should be noted that PWs are not required to carry the control word, and that this method can only be used for those PWs that do. 4.2. Out-of-Band VCCV When the control word is not used, or the receiving hardware cannot divert control traffic based on information in the control word (i.e.: older hardware), a VCCV control channel can be created alter- natively by including the MPLS router alert label [RFC3032] immedi- ately above the PW label. If the control word is in use on this PW it is also included in the VCCV control flow. It should be noted that this approach may alter equal cost multi-path (ECMP) hashing behav- ior, and thus the VCCV traffic may take a path which differs from that of the data traffic under test. 4.3. TTL Expiry VCCV The TTL of the PW demultiplexor label can be set to 1 to force the packet to be processed within the destination router's control plane. This is an inband control channel identification mechanism that is an alternate to section 4.1. When the PSN is MPLS it should be noted that this mode may not work in cases where the penultimate hop overwrites the TTL values of labels underneath the top-most label. Some older implementations do this, and the result would be a false positive. Therefore, we recom- mend that operators investigate the TTL handling behavior of the routers in their networks to determine if this situation can occur. If it is discovered that it can, than this mode should not be used for the reasons explained above. 5. VCCV Types VCCV can carry several types of protocols that can be used on the control channel either at the same time, or serially. The specific type or types of VCCV packets accepted by a router are indicated dur- ing signaling as described in section 6. The various VCCV types sup- ported SHOULD be used only when they apply to the PW demultiplexor in use. For example, the LSP Ping type should only be used when MPLS is utilized as the PW demultiplexor. Nadeau & Raggarwa [Page 8] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 5.1. MPLS LSP Ping Packet The LSP Ping header must be used as described [LSP-PING] and must also contain the sub-TLV of 8 for the L2 VPN endpoint or 9 for the L2 circuit ID. The sub-TLV indicates the PW to be verified. 5.2. Bidirectional Forwarding Detection When heart-beat indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [BFD] provides a light- weight means of continuous monitoring and propagation of forward and reverse defect indications. In order to use BFD, both ends of the PW connection must have sig- naled the existence of a control channel and the ability to run BFD. Once a node has both signaled and received signaling from its peer of these capabilities, it MUST begin sending BFD control packets. The packets MUST be sent on the control channel. The use of the control channel provides the context required to bind the BFD session to a particular PW (FEC). Thus normal BFD initialization procedures are followed. BFD MUST be run in asynchronous mode. In addition, it may also be desirable to use LSP-Ping for periodic diagnostics, in addi- tion to BFD, for fault detection on the same PW. The procedures for this are described in [BFDMPLS]. When one of the PEs (PE2) doesn't receive control messages from PE1 during the specified amount of time it declares that the PW in the direction from PE2 to PE1 is down. It stores the cause (e.g., con- trol detection time expired) and sends a message to PE1 with H (i.e., "I don't hear you"). This causes PE1 to declare the PW in the direc- tion from PE1 to PE2 down and it stores as cause: neighbor signaled session down. Depending on the emulated services, PE2 may send a FDI indication on its attachment circuits and PE1 may send an RDI indica- tion on its attachment circuits [OAM-MAP]. BFD defines the following diagnostics: 0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset (Local equipment failure) 5 -- Path Down (Alarm Suppression) 6 -- Concatenated Path Down (Propagating access link alarm) 7 -- Administratively Down Note that the value, 0 is used when the PW is up and 2 is not appli- cable to asynchronous mode. Nadeau & Raggarwa [Page 9] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 6. OAM Capability Indication for PWs Demultiplexed using MPLS To permit the indication of the type or types of PW control chan- nel(s), and connectivity verification mode or modes over a particular PW, a VCCV parameter is defined below that is used as part of the PW establishment signaling. When a PE signals a PW and desires PW OAM for that PW, it MUST indicate this during PW establishment using the messages defined below. Specifically, for LDP the PE MUST include the VCCV parameter in the PW setup message. The decision of the type of VCCV control channel is left completely to the receiving control entity. When a PE sends a label for a PW, it uses the VCCV parameter to indicate the type of OAM control channels and connectivity verification type or types it is willing to receive on that PW. The capablity of supporting a control channel or chan- nels, and connectivity type or types used over that control channel or channels MUST be signaled before the remote PE may send VCCV mes- sages, and then only on the control channel or channels, and using the connectivity verification type or types indicated. If a PE receives VCCV messages prior to advertising capability for this message, it MUST discard these messages and not reply to them. In this case, the PE SHOULD increment an error counter and optionally issue a system and/or SNMP notification to indicate to the system administrator that this condition exists. When LDP is used as the PW signaling protocol the requesting PE indi- cates its configured VCCV capability or capabilities to the remote PE by including the VCCV parameter with appropriate options indicating which methods of OAM it supports in the interface parameter field of the PW ID FEC TLV (FEC 128) or in the interface parameter TLV of the Genralized PW ID FEC TLV (FEC 129). The requesting PE MAY indicate that it supports multiple control channel options, and in doing so agrees to support any and all indicated types if transmitted to it. Local policy may direct the PE to support certain OAM capability and to indicate it. The absence of the VCCV parameter indicates that no OAM functions are supported by the requesting PE, and thus the receiving PE MUST NOT send any VCCV control channel traffic to it. The reception of a VCCV parameter with no options set MUST be ignored as if one is not transmitted at all. The receiving PE agrees to accept any of the indicated OAM types and options by virtue of establishing the PW. If it does not or cannot support at least one of the options specified, it MUST not establish the PW. If the requesting PE wishes to continue, it may choose dif- ferent options and try to signal the PW again. Nadeau & Raggarwa [Page 10] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 6.1. Optional VCCV Parameter [PWE3CONTROL] defines an Interface Parameter field in the LDP PW ID FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized PW ID FEC (FEC 129) to signal different capabilities for specific PWs. We propose an optional parameter to be used to indicate the desire to use a control channel for VCCV. This is the VCCV parameter field. If FEC 128 is used the VCCV parameter field is carried in the Interface Parameters field. If FEC 129 is used it is carried as a sub-TLV in the Interface Parameters TLV. The VCCV parameter ID is defined as follows in [PWE3IANA]: Parameter ID Length Description 0x0c 4 VCCV The format of the VCCV parameter field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0c | 0x04 | CC Types | CV Types | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Control Channel (CC Types) type field defines a bitmask used to indicate the type of control channel(s) (i.e.: none, one or both) that may be used to receive OAM control channel traffic on. If more than one control channel is specified, the router agrees to accept control traffic at any time over either control channel. If none of the types are supported, a CC Type Indicator of 0x00 SHOULD be trans- mitted to indicate this to the peer. However, if no capability is signaled, then the peer MUST assume that the peer is incapable of receiving VCCV and MUST NOT send any OAM control channel traffic to it. 0x01 PWE3 control word with 0x0001 as first nibble 0x02 MPLS Router Alert Label 0x04 MPLS PW Demultiplexor Label TL = 1 The CV Type Indicators field is a bitmask used to indicate the spe- cific type or types (i.e.: none, one or more) of control channel packets that may be sent on the specified control channel. The defined values are: 0x01 ICMP Ping 0x02 LSP Ping 0x04 BFD Nadeau & Raggarwa [Page 11] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 If none of the types above are supported, a CV Type Indicator of 0x00 SHOULD be transmitted to indicate this to the peer. However, if no capability is signaled, then the peer MUST assume that the peer has no VCCV capability. 7. VCCV Control Channel for L2TPv3/IP PSN When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are carried over the L2TPv3 session as defined in this section. It should be noted that L2TPv3 has a built-in "Hello" keepalive mechanism for its control plane that operates "in-band" over IP with respect to the IP protocol number, port (when UDP is used), source and destination IP addresses. This built-in Hello mechanism provides connection sta- tus only for the group of sessions associated with the L2TP Control Channel. VCCV, however, allows individual L2TP sessions to be tested. This provides a more granular mechanism which can be used to trou- bleshoot potential problems deeper within the dataplane of L2TP end- points themselves, or to provide additional connection status of individual pseudo wires. In order to carry VCCV messages within an L2TPv3 session data packet, this draft relies on the presence of the L2-Specific Sublayer. The presence of this field is signaled via the L2-Specific Sublayer AVP as defined in [L2TPv3]. The 'V' bit within the Default L2-Specific Sublayer is used to identify that a VCCV message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V|S|x|x|x|x|x|x| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Default L2-Specific Sublayer Format with V bit. The 'V' bit indicates that a VCCV session message follows. If the PW has not been signaled to include a L2-specific sublayer format, other mechanisms are needed to indicate the VCCV message. Such mechanisms are for further study. Nadeau & Raggarwa [Page 12] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 7.1. L2TPv3 VCCV Message The VCCV message MUST contain a VCCV AVP. It does not contain a mes- sage header. This could either be a new VCCV ICMP Ping AVP or VCCV BFD AVP. The usage of the L2TPv3 AVP format leaves room for adding further AVPs to this message in the future as needed. 7.1.1. L2TPv3 VCCV ICMP Ping AVP This AVP encodes the ICMP Ping Echo Packet [ICMP]. This AVP may be followed by the L2TPv3 Remote End Identifier AVP to identify the PW associated with the session. 7.1.2. L2TPv3 VCCV BFD AVP This AVP encodes a BFD packet that is used to verify the session. When heart-beat indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [BFD] provides a light- weight means of continuous monitoring and propagation of forward and reverse defect indications. BFD MUST be run in asynchronous mode. BFD control packets [BFD] are encapsulated in the AVP. The L2TPv3 session provides the context to demultiplex the first BFD control packet. The L2TPv3 VCCV BFD AVP may be followed by the L2TPv3 Remote End Identifier AVP to identify the PW associated with the session. 7.2. L2TPv3 VCCV Capability Indication A LCCE or a LAC should be able to indicate whether the session is capable of processing VCCV packets. This is done by including the optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP. 7.2.1. L2TPv3 VCCV Capability AVP This AVP specifies the VCCV capability. Its attribute type is TBD. The value field has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | CV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nadeau & Raggarwa [Page 13] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 The CV Type Indicators field defines a bitmask used to indicate the specific type or types (i.e.: none, one or more) of IP control pack- ets that may be sent on the specified control channel. The defined values are: 0x01 ICMP Ping 0x02 BFD If none of the types above are supported, a CV Type Indicator of 0x00 SHOULD be transmitted to indicate this to the session peer. However, if no capability is signaled, then the peer MUST assume that the other peer has no VCCV capability. 7.3. L2TPv3 VCCV Operation A PE sends VCCV echo requests on a L2TPv3 signaled PW for fault detection and diagnostic of the L2TPv3 session. The destination IP address in the echo request is set to the remote PE's IP address, while the source IP address is set to the local PE's IP address. The egress of the L2TPv3 session verifies the signaling and forwarding state of the PW, on reception of the VCCV message. Any faults detected can be signaled in the VCCV echo response. Its to be noted that the VCCV mechanism for L2TPv3 is primarily targeted at verifying the PW forwarding and signaling state at the egress PE. It also helps when L2TPv3 control and session paths are not identical. A PE must send VCCV packets on a L2TPv3 session only if it has sig- naled VCCV capability to the remote end and received VCCV capability from the remote end. If a PE receives VCCV packets and its not VCCV capable or it has not received VCCV capability indication from the remote end, it must discard these messages. In addition if a PE receives VCCV messages and it has not received VCCV capability from the remote end, it should increment an error counter. In this case the PE can optionally issue a system and/or SNMP notification. 8. IANA Considerations 8.1. VCCV Parameter ID VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA is requested to maintain a registry for the CC Types and CV Types, bit- masks in the VCCV parameter ID. The allocations must be done using the "First Come First Served" policy defined in RFC2434. IANA is requested to reserve the following bits in this registry: Nadeau & Raggarwa [Page 14] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 8.1.1. CC Types 0x01 PWE3 control word with 0x0001 as first nibble 0x02 MPLS Router Alert Label 0x04 MPLS PW Demultiplexor Label TL = 1 8.1.2. CV Types 0x01 ICMP Ping 0x02 LSP Ping 0x04 BFD 8.2. L2TPv3 Assignments The 'V' bit within the L2TPv3 Default L2-Specific Sublayer has to assigned by IANA. L2TPv3 VCCV ICMP Ping AVP, BFD AVP, VCCV Capability AVP must also be assigned by IANA. IANA is requested to maintain a registry for the CV Types, bit-mask in the VCCV Capability AVP. The allocations must be done using the "First Come First Served" policy defined in RFC2434. IANA is requested to reserve the following bits in this registry: 8.2.1. CV Types 0x01 ICMP Ping 0x02 BFD 9. Security Considerations Routers that implement the mechanism described herein are subject to to additional denial-of-service attacks as follows: An intruder may impersonate an LDP peer in order to force a failure and reconnection of the TCP connection, but where the intruder sets the Recovery Time to 0 on reconnection. An intruder could intercept the traffic between LDP or peers and override the setting of the TCP Recovery Time to be set to 0. An intruder could inject traffic into the TCP connection and effectively masquerade as an LDP peer. The same is possible for the UDP stream between L2TPv3 peers. In doing Nadeau & Raggarwa [Page 15] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 so could falsely indicate VCCV capabilities to a peer. An intruder could intercept or inject VCCV packets effectively providing false positives or false negatives. An intruder could deliberately flood a peer router with VCCV messages to either obtain services without authorization or to deny services to others. A misconfigured or misbehaving device could inadvertantly flood a peer router with VCCV messages which could result in a denial of services. In particular, if a router is either implicitly or explicitly indicated that it cannot support one or all of the types of VCCV, but is sent those messages in sufficient quantity, could result in a denial of service. All of attacks above which concern the L2TPv3 or LDP control planes may be countered by use of a control message authentication scheme between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in [LDP] or [L2TPv3]. Implementation of IP address filters may also aid in deterring these types of attacks. VCCV message throttling mechanisms should be employed, especially in distributed implementations which have a centralized control plane processor with various line cards attached by some data path. In these architectures VCCV messages may be processed on the central processor after being forwarded there by the receiving line card. In this case, the path between the line card and the control processor may become saturated if appropriate VCCV traffic throttling is not employed, which could lead to a denial of service. Such filtering is also useful for preventing the processing of unwanted VCCV messages, such as those which are sent on unwanted (and perhaps unadvertised) control channel types or VCCV types. VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN tunnel header. As far as the PW label is concerned the same consider- ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel, PSN tunnel label spoofing is also required. Nadeau & Raggarwa [Page 16] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 10. Acknowledgements The authors would like to thank Hari Rakotoranto, Michel Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric Rosen, Dan Tappan,Danny McPherson and Luca Martini for their valuable comments and suggestions. 11. References 11.1. Normative References [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 [BFD] Katz, D., Ward, D., Bidirectional Forwarding Indication, draft-ietf-bfd-03.txt, July 2005 [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-11.txt, June 2005. [IANAPPP] IANA Point-to-Point Protocol Field Assignments, April 12, 2004, http://www.iana.org/assignments/ppp-numbers [LSPPING] Kompella, K., G. Swallow, " Detecting MPLS Data Plane Failures", Internet Draft draft-ietf-mpls-lsp-ping-09.txt, May 2005. [PWCTRL] Martini, L., et. al., "Pseudo Wire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-17.txt, June 2005 [ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Trans- port of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-10.txt, June 2005. [RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol version 3", draft-ietf-l2tpext-l2tp-base-12.txt, March 2004. Nadeau & Raggarwa [Page 17] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 [ICMP] Postel, J. "Internet Control Message Protocol, RFC 792 [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [PW-CW] S. Bryant et. al., "PWE3 Control Word for use over an MPLS PSN", draft-ietf-pwe3-cw-05.txt, June 2005. 11.2. Informative References [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS Networks, Internet Draft draft-ietf-oam-requirements-02.txt, June 2003. [PWEARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985, March 2005 [PWREQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo Wire Emulation Edge to-Edge (PWE3)", draft-ietf-pwe3-requirements-08.txt, December 2003 [BFDMPLS] R. Aggarwal, et al, "BFD for MPLS LSPs", Internet Draft , June 2005. [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [OAM-MAP] T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map- ping", draft-ietf-pwe3-oam-msg-map-02.txt, February 2005 Nadeau & Raggarwa [Page 18] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 12. Author Information Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 Email: tnadeau@cisco.com Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 Email: swallow@cisco.com Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Yuichi Ikejiri NTT Communication Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Shinjuku-ku, JAPAN Email: y.ikejiri@ntt.com Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2, Nishishinjuku, Tokyo 163-8003, JAPAN E-mail: ke-kumaki@kddi.com Peter B. Busschbach Lucent Technologies 67 Whippany Road Whippany, NJ, 07981 E-mail: busschbach@lucent.com Nadeau & Raggarwa [Page 19] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 Vasile Radoaca Nortel Networks Billerica, MA, 01803 Email: vasile@nortelnetworks.com 13. 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 assur- ances 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. 14. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on 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 INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nadeau & Raggarwa [Page 20] Internet Draft draft-ietf-pwe3-vccv-06.txt August 2005 Nadeau & Raggarwa [Page 21]