Manual

Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
17
Cisco IOS Releases 12.0(29)S and 12.2(25)S
If you enable the ip dfbit set command in the pseudowire class, the default MTU behavior changes
so that any packets that cannot fit within the tunnel MTU are dropped.
If you enable the ip pmtu command in the pseudowire class, the L2TPv3 control channel
participates in the path MTU discovery. When you enable this feature, the following processing is
performed:
ICMP unreachable messages sent back to the L2TPv3 router are deciphered and the tunnel MTU
is updated accordingly. In order to receive ICMP unreachable messages for fragmentation
errors, the DF bit in the tunnel header is set according to the DF bit value received from the CE,
or statically if the ip dfbit set option is enabled. The tunnel MTU is periodically reset to the
default value based on a periodic timer.
ICMP unreachable messages are sent back to the clients on the CE side. ICMP unreachable
messages are sent to the CE whenever IP packets arrive on the CE-PE interface and have a
packet size greater than the tunnel MTU. A Layer 2 header calculation is performed before the
ICMP unreachable message is sent to the CE.
L2TPv3 Control Connection Hashing
The L2TPv3 Control Connection Hashing feature introduces a new and more secure authentication
system that replaces the Challenge Handshake Authentication Protocol (CHAP)-like authentication
system inherited from L2TPv2, which uses the Challenge and Challenge Response AVPs in the SCCRQ,
SCCRP, and SCCCN messages.
The per-message authentication introduced by the L2TPv3 Control Connection Hashing feature is
designed to perform a mutual authentication between L2TP nodes, check integrity of all control
messages, and guard against control message spoofing and replay attacks that would otherwise be trivial
to mount against the network.
L2TPv3 Control Connection Hashing incorporates an optional authentication or integrity check for all
control messages. The new authentication method uses a computed one-way hash over the header and
body of the L2TP control message, a pre-configured shared secret that must be defined on
communicating L2TP nodes, and a local and remote random value exchanged via the Nonce AVPs.
Received control messages that lack any of the required security elements are dropped.
L2TPv3 control connection integrity checking is a unidirectional mechanism that does not require the
configuration of a shared secret. If integrity checking is enabled on the local PE router, control messages
are sent with the message digest calculated without the shared secret or Nonce AVPs, and are verified
by the remote PE router. If verification fails, the remote PE router drops the control message.
L2TPv3 Control Connection Rate Limiting
Cisco IOS Release 12.0(29)S introduces the L2TPv3 Control Connection Rate Limiting feature to
counter the possibility of a denial-of-service attack on a router running L2TPv3. The L2TPv3 Control
Connection Rate Limiting feature limits the rate at which SCCRQ control packets arriving at the PE that
terminates the L2TPv3 tunnel can be processed. SCCRQ control packets initiate the process of bringing
up the L2TPv3 tunnel and require a large amount of the control plane resources of the PE router.
On distributed platforms, most control packet filtering will occur at the line card level, and the CPU of
the RP will be minimally impacted even in a worst-case denial-of-service attack scenario. This feature
will have minimal impact on the shared bus or switching fabric, which are typically the bottleneck of a
router.
No configuration is required for the L2TPv3 Control Connection Rate Limiting feature. This feature will
automatically run in the background of Cisco IOS Release 12.0(29)S and subsequent releases.