Technical Overview of L2TPv3

This section contains a brief overview of the L2TPv3. As noted in the introduction, there are three different L2TPv3 tunneling models: LAC to LNS, LNS to LNS, and LAC to LAC. This chapter discusses L2TPv3 deployed using the LAC to LAC pseudowire configuration.

L2TP can operate directly over several packet switched network types, including IP, MPLS, Frame Relay, and ATM. This chapter focuses on operation over an IP backbone network.

Internet Draft draft-ietf-l2tpext-l2tp-base discusses two methods of transporting L2TPv3 over an IP network:

• L2TPv3 directly over IP (using IP Protocol ID 115)

• L2TPv3 over UDP (using destination port 1701)

Cisco's current LAC to LAC implementation supports L2TPv3 over IP, so this method of transport is assumed in this chapter. Note that L2TPv3 over IP has less overhead, but L2TPv3 over UDP can be useful in environments where an L2TP tunnel has to traverse a Network Address Translation (NAT) device or firewall.

L2TPv3 Message Types

There are two different types of L2TPv3 message:

• Control messages are used to establish, maintain, and tear down L2TPv3 control channels and data sessions. Control messages are reliably transmitted in-band between peer LACs.

  One or more control channels can be established between the two L2TPv3 control connection endpoints (LCCEs), which in this case are the peer LACs.

• Session data messages are used to transport Layer 2 frames between the peer LACs. Each Layer 2 connection is carried over a separate data session.

L2TPv3 Control Messages

As previously mentioned, control messages are used for the establishment, maintenance, and teardown of L2TPv3 control connections and data sessions.

A control connection is not essential to the operation of data sessions between peer LACs. However, unless otherwise stated, this chapter assumes the existence of a control connection.

Figure 5-4 illustrates the overall packet format of L2TPv3 control messages.

Note that there is one control message that consists of only the IP and control message headers. This is called the Zero-Length-Body Acknowledgment (ZLB Ack) and is used to acknowledge explicitly other control message types. The ZLB Ack is used in the absence of another control messages that provide implicit acknowledgment. The ZLB Ack can be used only if authentication is disabled. In cases where authentication is enabled, an Explicit Acknowledgment message is used instead.

Figure 5-5 shows the format of the L2TPv3 control message.

The first thing you will notice if you have read Chapter 4, "Troubleshooting Layer 2 Tunneling Protocol Version 2 VPNs," is that the header looks pretty similar (see Figure 4-5 in Chapter 4). One or two differences do exist, however. The bulleted list that follows discusses the bits and fields in the L2TPv3 control message:

• The first part of the header is 32 bits, all set to zero. These 32 bits allow an LAC receiving a control message to distinguish it from a data message (these 32 bits are actually the reserved session ID of zero).

• After the initial 32 bits are the L2TP flags. The first of these is the T bit. The T bit must be set to 1, and it is used when L2TPv3 is transported over UDP to indicate that this is a control message. When L2TPv3 is transported over IP, this function is performed by the initial 32 bits, so the T bit is somewhat redundant.

• The L bit must be set to 1 and indicates that the Length field is present.

• The following two bits shown as x (and, in fact, all bits shown as x) are reserved and must be set to zero.

• The S bit must be set to 1, and it indicates that the Ns (Next sent) and Nr (Next received) fields are present.

  NOTE

  Before moving on, note the absence of the O (Offset) and P (Priority) bits, when compared to L2TPv2. The absence of the O bit, of course, also means that the Offset and Offset pad fields are no longer present.

  
  

• The Ver (version) field is 4 bits long and must be set to 3 to indicate that this is an L2TPv3 control message.

• The Length field is 16 bits long and indicates the total length for the message in octets starting from the T bit.

• Next is the 32-bit Control Connection ID field. Again, if you are familiar with L2TPv2, you will notice that this field has replaced the Tunnel ID field. The Control Connection ID is locally significant only. It is possible, therefore, for the same control connection to have different IDs on either peer LAC.

  Note that the local Control Connection ID is passed by the LAC to its peer in the Assigned Control Connection ID Attribute-Value-Pair (AVP) during control connection setup.

  Figure 5-6 illustrates Control Connection IDs.

  Figure 5-6. Control Connection IDs

  

  
  

  In Figure 5-6, the L2TPv3 control connection between Stockholm_LCCE and London_LCCE is identified by Control Connection ID 1002 on Stockholm_LCCE and by Control Connection ID 2002 on London_LCCE.

  The control connection between Frankfurt_LCCE and London_LCCE is identified by Control Connection ID 3001 on Frankfurt_LCCE and by Control Connection ID 2001 on London_LCCE.

• The Ns (Next sent) field is 16 bits long and indicates the sequence number for this control message.

• The Nr (Next received) field is again 16 bits long and indicates the sequence number of the next message expected from the peer LAC.

Following the control message header is the control message itself.

Control Message Types

Table 5-1 lists the 14 different types of control messages as defined by L2TPv3.

Table 5-1. L2TPv3 Control Message Types

Message Type	Description	Function
0	(reserved)	(none)
1	Start-Control-Connection-Request (SCCRQ)	Control channel setup
2	Start-Control-Connection-Reply (SCCRP)	Control channel setup
3	Start-Control-Connection-Connected (SCCCN)	Control channel setup
4	Stop-Control-Connection-Notification (StopCCN)	Control channel teardown
5	(reserved)	(none)
6	Hello (HELLO)	Control channel maintenance
7	Outgoing-Call-Request (OCRQ)	Outgoing call (session) setup
8	Outgoing-Call-Reply (OCRP)	Outgoing call (session) setup
9	Outgoing-Call-Connected (OCCN)	Outgoing call (session) setup
10	Incoming-Call-Request (ICRQ)	Incoming call (session) setup
11	Incoming-Call-Reply (ICRP)	Incoming call (session) setup
12	Incoming-Call-Connected (ICCN)	Incoming call (session) setup
13	(reserved)	(none)
14	Call-Disconnect-Notify (CDN)	Call (session) teardown
15	WAN-Error-Notify (WEN)	Call status
16	Set-Link-Info (SLI)	Call status
TBA-M1 (to be announced)	Explicit Acknowledgment	Explicitly acknowledges receipt of control messages

Note that the OCRQ, OCRP, and OCCN messages are not used in the LAC to LAC model and are, therefore, not discussed further in this chapter. Also, the Explicit Acknowledgment message type value is yet to be announced at the time of this writing.

The composition and function of each of the other message types listed in Table 5-1 are discussed in the following few sections.

AVPs

Control messages are made up of a number of AVPs. AVPs are used to describe a particular variable (the attribute) and its associated value. These AVPs allow great protocol extensibility.

AVPs have a common encoding format, which is shown in Figure 5-7. Note that this encoding format is carried over from L2TPv2.

The bits and fields in the AVP encoding format are defined as follows:

• The M (mandatory) bit should be checked if the AVP is unrecognized or malformed. If the LCCE receives an unrecognized or malformed AVP with the M bit set, it tears down the session or control connection (together with all associated sessions) associated with the message that contains this AVP. If, on the other hand, the LCCE receives an unrecognized or malformed AVP without the M bit set, the AVP is ignored.

• The H (hidden) bit, if set to 1, indicates that the value or data in the AVP is hidden. The hiding of data in AVPs can be used to pass sensitive data such as passwords.

  The method of hiding data in AVPs is the same as that used by L2TPv2. For more details, see section 5.3 of draft-ietf-l2tpext-l2tp-base (L2TPv3).

  Note that AVP hiding makes use of the shared password configured on peer LCCEs.

• Four reserved bits (RSVD) follow the H bit. These must be set to zero.

• The 10-bit Length field indicates the overall length of the AVP in octets. The minimum length is 6 (indicating that the value field is absent), and the maximum length is 1023.

• The 16-bit Vendor-ID field allows vendors to implement proprietary AVPs. Vendor-ID values correspond to the SMI Network Management Private Enterprise Codes (RFC 1700). The value of zero indicates that the AVP is an Internet Engineering Task Force (IETF) defined AVP.

• The 16-bit Attribute Type field specifies the type of AVP.

• The variable-length Attribute Value field specifies the associated value.

Internet Draft draft-ietf-l2tpext-l2tp-base (L2TPv3) defines a number of different AVPs. These fall into five categories:

• General control message AVPs

• The result code AVP

• Control connection management AVPs

• Session management AVPs

• Circuit status AVPs

The sections that follow cover these AVPs in more detail.

General Control Message AVPs

The four general control message AVPs are Message Type, Message Digest, Control Message Authentication Nonce, and Random Vector.

Table 5-2 summarizes general control message AVPs.

Table 5-2. General Control Message AVPs

Attribute Type	Attribute Name	Description	Present In
0	Message Type	Defines the message type	All messages
TBA	Message Digest	Provides integrity check and authentication of control messages	All messages (if authentication is enabled)
TBA	Control Message Authentication Nonce	Cryptographically random value used for Control Connection message authentication.	SCCRQ, SCCRP (if authentication is enabled)
36	Random Vector	Contains a cryptographically random number used with AVP hiding	ICRQ, ICRP, ICCN, CDN, StopCCN, SLI

The Message Type, Message Digest, and Control Message Authentication Nonce AVPs are of particular significance. The Message Type AVP is used to define the control message type (described in Table 5-1) itself. The Message Digest and Control Message Authentication Nonce AVPs are both used for L2TPv3 message authentication. The Message Digest AVP additionally provides an integrity check over the whole control message. Note that the attribute type values for these two AVPs are yet to be announced at the time of this writing.

L2TPv3 message authentication is described later in this chapter in the section entitled "Control Connection Establishment."

Result Code AVP

The Result Code AVP is functionally in its own category. This AVP is contained in the Call-Disconnect-Notify (CDN) and Stop-Control-Connection-Notification (StopCCN) messages. It is used to describe the reason for session or control channel teardown.

The Result Code AVP contains the result code itself, together with an optional Error Code and Error Message. These collectively describe the reason for session or control connection teardown.

Table 5-3 describes the Result Code AVP.

Table 5-3. Result Code AVP

Attribute Type	Attribute Name	Description	Present In
1	Result Code	Indicates the reason for session or control channel teardown	CDN, StopCCN

When included with a StopCCN message, the result code values are as shown in Table 5-4.

Table 5-4. Result Code Values (StopCCN)

Result Code	Description
0	(reserved)
1	General request to clear control connection
2	General error (Error code indicates problemsee Table 5-6)
3	Control connection already exists
4	Requestor is not authorized to establish control channel
5	Protocol version of peer is not supported
6	LCCE is being shut down
7	Finite state machine error or timeout

When included with a CDN message, the result code values are as shown in Table 5-5.

Table 5-5. Result Code Values (CDN)

Result Code	Description
0	(reserved)
1	Session disconnected because of loss of carrier or circuit disconnect
2	Session disconnected for the reason specified in Error Code
3	Session disconnected for administrative reasons
4	Session establishment failed because of lack of appropriate facilities being available (temporary condition)
5	Session establishment failed because of lack of appropriate facilities being available (permanent condition)
6 to 11	Reserved (PPP-specific codes)
TBA1	Session not established because of losing tie breaker
TBA2	Session not established because of unsupported pseudowire type
TBA3	Session not established, sequencing required without valid L2-specific sublayer
TBA4	Finite state machine error or timeout

Note result codes values TBA1-4. These are result code values that are yet to be announced (at the time of this writing). A Result Code AVP can also optionally include Error Code and Error Message fields. If the Error Code field is included, the Error Code values are those shown in Table 5-6.

Table 5-6. Error Code Values

Result Code	Description
0	No general error
1	No control connection exists yet for this pair of LCCEs
2	Length is wrong
3	One of the field values was out of range
4	Insufficient resources to handle this operation now
5	Invalid Session ID
6	A generic vendor-specific error occurred
7	Try another LCCE
8	The session or control connection was shut down due to receipt of an unknown AVP with the M bit set
9	Try another directed (Error Message must contain a list of addresses of other LCCEs to try)

Finally, the optional Error Message field in the Result Code AVP contains human-readable text describing the error condition.

The mechanics of session and control connection teardown are discussed in the sections entitled "Session Teardown" and "Control Connection Teardown" later in this chapter.

Control Connection Management AVPs

Control connection management AVPs are carried in messages used to establish and tear down control connections between LCCEs.

Table 5-7 shows control connection management AVPs.

Table 5-7. Control Connection Management AVPs

Attribute Type	Attribute Name	Description	Present In
5	Control Connection Tie Breaker	Used to ensure that only one control channel is established between peer LCCEs	SCCRQ
7	Host Name	Name of the LAC or LNS	SCCRQ / SCCRP
TBA	Router ID	Identifies an LCCE	SCCRQ / SCCRP
8	Vendor Name	String describing type of LAC or LNS	SCCRQ / SCCRP
TBA	Assigned Control Connection ID	Used to communicate locally assigned control connection ID to peer	SCCRQ / SCCRP / StopCCN
10	Receive Window Size	Receive window size offered to the remote LCCE (used for flow control)	SCCRQ / SCCRP
TBA	Pseudowire Capabilities List	Used to indicate Layer 2 payload types supported by the sender	SCCRQ / SCCRP
TBA	Preferred Language	Indicates language in which human-readable messages should be composed	SCCRQ / SCCRP

Note that some attribute type values (marked TBA) are yet to be announced at the time of writing.

Of particular note is the Pseudowire Capabilities List AVP. This is used to inform the remote LCCE about which pseudowire types are supported by the local LCCE.

Session Management AVPs

Call management AVPs are carried in messages used for session establishment and teardown between peer LCCEs.

Table 5-8 summarizes session management AVPs.

Table 5-8. Session Management AVPs

Attribute Type	Attribute Name	Description	Present In
TBA	Local Session ID	Used to communicate the locally assigned session ID to the peer LCCE	ICRQ / ICRP / ICCN / CDN / WEN / SLI
TBA	Remote Session ID	Indicates the session ID assigned by the peer LCCE	ICRQ / ICRP / ICCN / CDN / WEN / SLI
TBA	Assigned Cookie	Used to communicate locally assigned cookie value to peer LCCE	ICRQ / ICRP
15	Serial Number	Identifies a session; used for administrative purposes	ICRQ
TBA	Remote End ID	Used to associate a session with a circuit, interface, or bridging instance	ICRQ
TBA	Application ID	Used to identify application types for a session	ICRQ
TBA	Session Tie Breaker	Used to ensure that only one session is established for a given circuit	ICRQ
TBA	Pseudowire Type	Used to specify the Layer 2 payload type of frames carried by this session	ICRQ
TBA	L2-Specific Sublayer	Used to specify the Layer 2 specific sublayer that the sender requires for a specific session (if any)	ICRQ / ICRP / ICCN
TBA	Data Sequencing	Used to indicate whether the sender requires sequencing on data packets for a particular session	ICRQ / ICRP / ICCN
24	Tx Connect Speed	Indicates the transmit speed in bits per second (bps) from the LAC to the CE router / remote system (if Rx Connect Speed attribute is not also present, indicates bidirectional speed)	ICRQ / ICRP / ICCN
38	Rx Connect Speed	Indicates the receive speed in bits per second (bps) from the CE router / remote system to the LAC	ICRQ / ICRP / ICCN
25	Physical Channel ID	Indicates the physical channel ID associated with the call (vendor specific)	ICRQ / ICRP

Note that the Remote End ID AVP is used to carry the Virtual Circuit ID (VCID) value, which is discussed in the following sections.

Also note the Data Sequencing AVP. This is used if sequencing is enabled for data sessions.

Circuit Status AVPs

The final category is circuit status AVPs. These are carried in messages to communicate attachment circuit active/inactive (up/down) or attachment circuit error information.

Table 5-9 summarizes call status AVPs.

Table 5-9. Call Status AVPs

Attribute Type	Attribute Name	Description	Present In
TBA	Circuit Status	Used to indicate the initial status or change of status of a circuit	ICRQ / ICRP / ICCN / SLI
34	Circuit Errors	Used to communicate circuit error information to a peer	WEN

L2TPv3 Data Messages

L2TPv3 data messages are used to transport frames received on a local attachment circuit to a peer LAC.

Figure 5-8 shows the overall session data message format.

The session data message header used by L2TPv3 over IP is very simple and is shown in Figure 5-9.

The 32-bit nonzero session ID carried in the data message header is used to associate incoming data messages with a particular local attachment circuit. Note that one L2TPv3 session corresponds to one pseudowire.

Following the session ID is an optional variable length random cookie value (maximum 64 bits). This cookie value can be used in addition to the session ID and adds an extra level of assurance that the incoming data messages are correctly associated with the local attachment circuit. Furthermore, a randomly chosen cookie provides protection against blind insertion attacks. That is, an attacker would find it very difficult, if not impossible, to insert packets into a data stream (pseudowire) if the attacker is unable to sniff packets transiting the network between peer LCCEs. This is because of the difficulty of guessing the correct cookie value (0 to 2⁶⁴ if the cookie is 64 bits in length).

Session IDs and cookie values are locally significant to an LCCE. They are communicated to the peer LCCE during session setup using the Local Session ID and Assigned Cookie AVPs (see Table 5-8).

Once the locally significant session ID and cookie values have been communicated to the remote peer, the remote peer can forward data messages with those values to the local peer.

Figure 5-10 illustrates the function of session IDs and cookies.

Figure 5-10. Session IDs and Cookies

[View full size image]

In Figure 5-10, Layer 2 frames received by London_LCCE from mjlnet_CE1 are forwarded to Frankfurt_LCCE using session ID 11 and cookie 110. Layer 2 frames received by Frankfurt_LCCE from mjlnet_CE2 are forwarded to London_LCCE using session ID 1 and cookie 100.

Similarly, Layer 2 frames received by London_LCCE from cisco_CE1 are forwarded to Frankfurt_LCCE using session ID 2 and cookie 200. Layer 2 frames received by Frankfurt_LCCE from cisco_CE2 are forwarded to London_LCCE using session ID 22 and cookie 220.

The next portion of the data message is the Layer 2 specific sublayer. The Layer 2 specific sublayer can be used to provide additional functionality, such as data message sequencing and packet priority settings.

A default Layer 2 specific sublayer is defined in draft-ietf-l2tpext-l2tp-base (L2TP), and this is shown in Figure 5-11.

The S bit, if set, is used to specify that sequence numbering is being used. In this case, the Sequence number field contains a valid sequence number. Bits marked as x are undefined and should be set to zero.

It is worth noting that other Layer 2 sublayers may be used when transporting particular frame types, such as Ethernet. An LCCE can signal the use of a particular Layer 2 sublayer during session setup in an L2 Specific Sublayer AVP (see Table 5-8).

Control Connection Establishment

Before session establishment can begin, a control connection must be established between peer LCCEs. Control connection establishment is initiated using a Start-Control-Connection-Request (SCCRQ) message. This message indicates to the peer LCCE that the sending LCCE wishes to establish a control connection.

The SCCRQ message also carries (among other things) the Pseudowire Capabilities List AVP, which is used to indicate to the peer LCCE what pseudowire types the sender supports. Pseudowire types could include Ethernet (port or VLAN), HDLC, and Frame-Relay, for example. Additionally, the SCCRQ may carry a Control Message Authentication Nonce AVP (containing a locally generated random number), if authentication is enabled.

Assuming the SCCRQ is acceptable, the peer LCCE responds with a Start-Control-Connection-Reply (SCCRP) message. This indicates that establishment of the control connection can proceed. The SCCRP contains (among other things) the peer LCCE's Pseudowire Capabilities List AVP. If authentication is enabled, the SCCRP will also contain a Message Digest AVP, together with a Control Message Authentication Nonce AVP containing the peer LCCE's random number.

The Message Digest AVP contains a hash (HMAC-MD5 or HMAC-SHA-1) value that the remote LCCE calculates with the following inputs: its random number (nonce), the local LCCE's random number (nonce), a shared-key generated from a shared L2TPv3 password, and the L2TPv3 control message itself (header and AVPs).

The local LCCE performs the same calculation, with the same inputs. If the locally calculated hash value and that contained in the Message Digest AVP are the same, the message from the remote LCCE is authenticated.

Finally, the control connection initiating LCCE sends a Start-Control-Connection-Connected (SCCCN) message to the peer LCCE, indicating that control connection establishment has been completed. If authentication is enabled, the SCCCN will contain a Message Digest AVP. This is calculated as previously described and is used by the remote LCCE to authenticate the message.

All control connection messages must carry a Message Digest AVP if authentication is enabled. The hash value carried in the SCCRQ message is, however, calculated slightly differently. The inputs are simply the shared key and the control message, including header and AVPs. The reason for this is that at the time the local LCCE sends the SCCRQ, it does not yet possess the remote LCCE's nonce value (which is communicated in the SCCRP).

Note that early implementations of L2TPv3 may use AVPs 11 (Challenge) and 13 (Challenge Response) for authentication. AVPs 11 and 13 were included in early versions of draft-ietf-l2tpext-l2tp-base but later were replaced by the Message Digest and Control Message Authentication Nonce AVPs.

Figure 5-12 illustrates control connection establishment.

Figure 5-12. Control Connection Establishment

[View full size image]

Note that only one control connection is required between peer LCCEs regardless of the number of sessions between the two.

Session Establishment

Once the control connection has been established, session setup can begin. Session setup starts with the initiating LCCE sending a Incoming-Call-Request (ICRQ). Among other things, the ICRQ includes the pseudowire type and circuit status AVPs. These are used to signal the payload to be carried in the session (corresponding to the attachment circuit type), and whether the circuit is active or inactive.

If session setup can proceed, the peer LCCE then responds with an Incoming-Call-Reply (ICRP). The ICRP carries a number of AVPs, including a circuit status AVP.

The session initiating LCCE now responds to the ICRP with an Incoming-Call-Connected (ICCN), indicating that the session has been established.

Figure 5-13 illustrates session setup.

Figure 5-13. Session Setup

[View full size image]

Once session setup has completed successfully, Layer 2 frames can be transported over the data session between the LCCEs.

Control Connection Maintenance

If an LCCE does not receive any data or control messages from its peer LCCE for a certain period, the control connection is maintained by sending a hello message.

Internet Draft draft-ietf-l2tpext-l2tp-base recommends a default inactivity interval of 60 seconds. This is the default on Cisco routers. If the peer LCCE does not acknowledge the hello message, the control connection is torn down.

Figure 5-14 illustrates the transmission of a hello (keepalive) message.

Figure 5-14. Hello Message

[View full size image]

Session Teardown

When either LCCE wishes to tear down a session, it sends a CDN message to its peer. The reason for the session teardown is contained within the Result Code AVP sent in the CDN. There are a number of possible reasons for session teardown, including if VCIDs or Layer 2 payload types are mismatched between LCCEs. See Table 5-5 for a list of possible result code values contained in the CDN (carried in a Result Code AVP).

Figure 5-15 illustrates session teardown when VCIDs are mismatched.

Figure 5-15. Session Teardown

[View full size image]

Control Connection Teardown

The control connection can be torn down by either LCCE using a StopCCN message. The reason for the control connection teardown is contained within the Result Code AVP in the StopCCN. The control connection can be torn down for a number of reasons, including if a hello (or other control message) is not acknowledged. For a complete list of results code values (contained in the StopCCN's Result Code AVP), see Table 5-4. If any sessions remain active, they are torn down at the same time as the control connection.

Figure 5-16 illustrates control connection teardown because of the failure of a peer LCCE to acknowledge a hello message.

Figure 5-16. Control Connection Teardown

[View full size image]

Set-Link-Info (SLI) Message

Another message type that is used by L2TPv3 is Set-Link-Info (SLI). This is used to signal attachment circuit status.

In Figure 5-17, an LCCE sends an SLI when an attachment circuit changes state to inactive (down).

Figure 5-17. SLI Message

[View full size image]