Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
updated by
- rfc-5586 — MPLS Generic Associated Channel
Extracted elements (30)
Capability selection uses a logical AND of sent and received bitmasks, and a fixed precedence order (Type 1 > Type 2 > Type 3) when multiple CC Types match, to ensure both PEs converge deterministically on a single CC Type without negotiation round-trips.
CC Type 2 (Router Alert Label) and CC Type 3 (TTL==1) may take a different ECMP path than PW data traffic, potentially testing a path that is not the actual data path. CC Type 1 (PW-ACH, in-band) is the preferred mode when a control word is present because it follows the same data-plane path as PW data.
L2TPv3 already has a built-in Hello keepalive for the L2TP Control Connection, but this only detects dead peers for the entire connection. VCCV provides per-session (per-pseudowire) granularity to troubleshoot individual L2TP sessions independently.
CC Type 1 (PW-ACH) can only be used for PW types that employ the control word and only when the CW follows the 'Generic PW MPLS Control Word' format. It cannot be applied to PWs that do not use a control word or use a different CW format.
Changing CC Types after one has been established is NOT RECOMMENDED as it could cause problems at the receiving end and lead to interoperability issues; the pseudowire must be torn down and re-established to use a different CC Type.
A remote PE MUST NOT send VCCV messages before the capability for the control channel and connectivity verification type to be used has been signaled. If VCCV messages are received prior to advertising capability, they MUST be discarded.
An LCCE MUST NOT send VCCV packets on an L2TPv3 session unless it has received VCCV capability via the VCCV Capability AVP. If VCCV packets are received without capability exchange, they MUST be discarded.
CC Type 1 (In-Band VCCV using PW-ACH) MUST be supported when the control word is present on the pseudowire.
For L2TPv3 ICMP Ping, the ICMP Echo request IP Header fields MUST set destination IP to the remote LCCE's tunnel endpoint address, source IP to the local LCCE's tunnel endpoint address, and TTL or Hop Limit to 1.
For L2TPv3 PWs, to carry VCCV messages the PW MUST be established with an L2-Specific Sublayer (L2SS) that defines the V-bit. If CC Type 0x01 is requested without requesting an L2SS AVP with an L2SS type that defines the V-bit, the session MUST be disconnected with a CDN message.
ICMP Ping CV Type implementations MUST use ICMPv4 if signaling used IPv4 addresses, or ICMPv6 if IPv6 addresses were used. For statically set-up PWs, the encoding MUST match what was used in configuration.
If no VCCV capability is signaled, the peer MUST assume the peer has no VCCV capability. The receiving PE MUST NOT send any VCCV control channel traffic to a peer that has not indicated VCCV support.
Implementations MUST provide a method to secure the data plane against data-plane attacks, either via IPsec encryption of MPLS packets (per RFC 4023) or by architecting the MPLS network to prevent external packet injection.
Once a valid CC Type is used by a PE, the PE MUST NOT send any traffic down another CC Type control channel, and MUST continue using that CC Type until the pseudowire is re-signaled.
VCCV applications MUST consider congestion and bandwidth usage implications. Outgoing VCCV messages SHOULD be rate-limited to prevent aggressive connectivity verification causing congestion or denial-of-service attacks. ICMP and MPLS LSP Ping SHOULD be rate-limited to below 5% of the associated PW's bit-rate.
When a PE signals a PW and desires PW OAM, it MUST indicate this during PW establishment and MUST include the VCCV interface parameter sub-TLV (0x0C) in the PW set-up message.
When CC Type 2 (Router Alert Label) or CC Type 3 (TTL==1) is used and the Control Word is in use on the PW, the CW MUST also be included before the VCCV message to avoid different ECMP hashing behavior.
When LSP Ping is used as CV Type, the LSP Ping header MUST be used per RFC 4379 and MUST contain the target FEC Stack with the appropriate sub-TLV (sub-Type 8, 9, 10, or 11) to identify the PW to be verified.
MPLS CC Types: Type 1 (0x01) uses PW-ACH (in-band with control word), Type 2 (0x02) uses MPLS Router Alert Label (out-of-band), Type 3 (0x04) uses PW label with TTL=1. L2TPv3 defines only Type 1 (0x01): L2-Specific Sublayer with V-bit set.
MPLS CV Types: ICMP Ping (0x01) and LSP Ping (0x02). L2TPv3 CV Types: ICMP Ping (0x01) only. All are 8-bit bitmask fields allowing multiple concurrent CV Types to be advertised.
VCCV defines two type spaces: Control Channel (CC) Types specifying how VCCV messages are encapsulated, and Connectivity Verification (CV) Types specifying what OAM protocol runs over the control channel. Only one CC Type may be active at a time, but multiple CV Types can be supported concurrently.
IANA assigned V-bit (Bit 0) in the Default L2-Specific Sublayer and ATM-Specific Sublayer to indicate VCCV traffic in L2TPv3 sessions, via the existing L2TP Name Spaces registries.
IANA created the 'MPLS VCCV Control Channel Types' registry (8-bit bitmask) and 'MPLS VCCV Control Verification Types' registry (8-bit bitmask) in the Pseudo Wires Name Spaces. New assignments require IETF Consensus and an IESG-approved RFC.
IANA created the 'VCCV Capability AVP Values' registry in L2TP Name Spaces, covering L2TPv3 CC Types and CV Types bitmasks in the VCCV Capability AVP (Attribute Type 96). New assignments require IETF Consensus.
VCCV is vulnerable to three attack categories: (1) control-plane attacks on VCCV capability signaling, (2) data-plane attacks including packet injection/interception to generate false positives/negatives and flooding attacks causing DoS, and (3) vulnerabilities inherited from carried protocols (LSP Ping, ICMP). Mitigations include VCCV message throttling, IPsec for data-plane protection, and L2TPv3 Cookie field for spoofing prevention.
VCCV capability negotiation: PW setup → PE sends VCCV capability in signaling (CC Types AND CV Types bitmasks) → peer returns its capabilities → logical AND selects usable types → single CC Type chosen per precedence rules → CC Type locked until PW is re-signaled (torn down and re-established to change).
The L2-Specific Sublayer with V-bit set for L2TPv3 VCCV is a 32-bit field: V-bit (bit 0) set to 1, next 3 bits set to 0, then 28 bits for Version (4 bits, set to 0), Reserved (8 bits, set to 0), and Channel Type (16 bits: 0x0021 for IPv4 or 0x0057 for IPv6).
The L2TPv3 VCCV Capability AVP (Attribute Type 96) has a 16-bit value field: 8-bit CC Types bitmask followed by 8-bit CV Types bitmask. The AVP Vendor ID MUST be 0, M bit SHOULD be 0, and length (before hiding) is 8.
The PW Associated Channel Header (PW-ACH) used for CC Type 1 is a 32-bit header: first nibble 0001b, 4-bit Version (0), 8-bit Reserved (0), and 16-bit Channel Type (0x0021 for IPv4, 0x0057 for IPv6).
The VCCV LDP Sub-TLV (parameter ID 0x0C, length 4) carries an 8-bit CC Types bitmask and an 8-bit CV Types bitmask encoded in a 32-bit field: [0x0c | 0x04 | CC Types | CV Types].