< draft-ietf-l2tpext-l2tp-base-10.txt   draft-ietf-l2tpext-l2tp-base-11.txt >
Network Working Group J. Lau Network Working Group J. Lau
Internet-Draft M. Townsley Internet-Draft M. Townsley
Category: Standards Track cisco Systems Category: Standards Track cisco Systems
<draft-ietf-l2tpext-l2tp-base-10.txt> I. Goyret <draft-ietf-l2tpext-l2tp-base-11.txt> I. Goyret
Lucent Technologies Lucent Technologies
Editors Editors
August 2003 October 2003
Layer Two Tunneling Protocol (Version 3) Layer Two Tunneling Protocol (Version 3)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes "version 3" of the Layer Two Tunneling This document describes "version 3" of the Layer Two Tunneling
Protocol (L2TPv3). L2TPv3 defines the base control protocol and Protocol (L2TPv3). L2TPv3 defines the base control protocol and
encapsulation for tunneling multiple layer 2 connections between two encapsulation for tunneling multiple layer 2 connections between two
IP connected nodes. Additional documents detail the specifics for IP connected nodes. Additional documents detail the specifics for
each link-type being emulated. each link-type being emulated.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 4 1. Introduction............................................. 4
1.1 Changes from RFC 2661................................ 5 1.1 Changes from RFC 2661................................ 5
1.2 Specification of Requirements........................ 5 1.2 Specification of Requirements........................ 5
1.3 Terminology.......................................... 5 1.3 Terminology.......................................... 5
2. Topology................................................. 9 2. Topology................................................. 9
3. Protocol Overview........................................ 10 3. Protocol Overview........................................ 10
3.1 Control Message Types................................ 11 3.1 Control Message Types................................ 11
3.2 L2TP Header Formats.................................. 12 3.2 L2TP Header Formats.................................. 12
3.2.1 L2TP Control Message Header..................... 12 3.2.1 L2TP Control Message Header..................... 12
3.2.2 L2TP Data Message............................... 13 3.2.2 L2TP Data Message............................... 13
3.3 Control Connection Management........................ 14 3.3 Control Connection Management........................ 14
3.3.1 Control Connection Establishment................ 15 3.3.1 Control Connection Establishment................ 15
3.3.2 Control Connection Teardown..................... 15 3.3.2 Control Connection Teardown..................... 15
3.4 Session Management................................... 16 3.4 Session Management................................... 16
3.4.1 Session Establishment for an Incoming Call...... 16 3.4.1 Session Establishment for an Incoming Call...... 16
3.4.2 Session Establishment for an Outgoing Call...... 16 3.4.2 Session Establishment for an Outgoing Call...... 16
3.4.3 Session Teardown................................ 16 3.4.3 Session Teardown................................ 16
4. Protocol Operation....................................... 17 4. Protocol Operation....................................... 17
4.1 L2TP Over Specific Packet-Switched Networks (PSN).... 17 4.1 L2TP Over Specific Packet-Switched Networks (PSN).... 17
4.1.1 L2TPv3 over IP.................................. 18 4.1.1 L2TPv3 over IP.................................. 18
4.1.2 L2TP over UDP................................... 19 4.1.2 L2TP over UDP................................... 19
4.1.3 IP Fragmentation Issues......................... 21 4.1.3 IP Fragmentation Issues......................... 21
4.2 Reliable Delivery of Control Messages................ 21 4.2 Reliable Delivery of Control Messages................ 21
4.3 Control Connection and Control Message Authentication 23 4.3 Control Connection and Control Message Authentication 23
4.4 Keepalive (Hello).................................... 24 4.4 Keepalive (Hello).................................... 24
4.5 Forwarding Session Data Frames....................... 25 4.5 Forwarding Session Data Frames....................... 25
4.6 Default L2-Specific Sublayer......................... 25 4.6 Default L2-Specific Sublayer......................... 25
4.6.1 Sequencing Data Packets......................... 26 4.6.1 Sequencing Data Packets......................... 26
4.7 L2TPv2/v3 Interoperability and Migration............. 27 4.7 L2TPv2/v3 Interoperability and Migration............. 27
4.7.1 L2TPv3 over IP.................................. 27 4.7.1 L2TPv3 over IP.................................. 27
4.7.2 L2TPv3 over UDP................................. 27 4.7.2 L2TPv3 over UDP................................. 27
4.7.3 Automatic L2TPv2 Fallback....................... 28 4.7.3 Automatic L2TPv2 Fallback....................... 28
5. Control Message Attribute Value Pairs.................... 28 5. Control Message Attribute Value Pairs.................... 28
5.1 AVP Format........................................... 29 5.1 AVP Format........................................... 28
5.2 Mandatory AVPs and Setting the M Bit................. 30 5.2 Mandatory AVPs and Setting the M Bit................. 30
5.3 Hiding of AVP Attribute Values....................... 31 5.3 Hiding of AVP Attribute Values....................... 31
5.4 AVP Summary.......................................... 33 5.4 AVP Summary.......................................... 33
5.4.1 General Control Message AVPs.................... 33 5.4.1 General Control Message AVPs.................... 33
5.4.2 Result and Error Codes.......................... 38 5.4.2 Result and Error Codes.......................... 37
5.4.3 Control Connection Management AVPs.............. 40 5.4.3 Control Connection Management AVPs.............. 40
5.4.4 Session Management AVPs......................... 45 5.4.4 Session Management AVPs......................... 45
5.4.5 Circuit Status AVPs............................. 54 5.4.5 Circuit Status AVPs............................. 53
6. Control Connection Protocol Specification................ 56 6. Control Connection Protocol Specification................ 56
6.1 Start-Control-Connection-Request (SCCRQ)............. 56 6.1 Start-Control-Connection-Request (SCCRQ)............. 56
6.2 Start-Control-Connection-Reply (SCCRP)............... 57 6.2 Start-Control-Connection-Reply (SCCRP)............... 56
6.3 Start-Control-Connection-Connected (SCCCN)........... 57 6.3 Start-Control-Connection-Connected (SCCCN)........... 57
6.4 Stop-Control-Connection-Notification (StopCCN)....... 57 6.4 Stop-Control-Connection-Notification (StopCCN)....... 57
6.5 Hello (HELLO)........................................ 58 6.5 Hello (HELLO)........................................ 58
6.6 Incoming-Call-Request (ICRQ)......................... 58 6.6 Incoming-Call-Request (ICRQ)......................... 58
6.7 Incoming-Call-Reply (ICRP)........................... 59 6.7 Incoming-Call-Reply (ICRP)........................... 59
6.8 Incoming-Call-Connected (ICCN)....................... 60 6.8 Incoming-Call-Connected (ICCN)....................... 59
6.9 Outgoing-Call-Request (OCRQ)......................... 60 6.9 Outgoing-Call-Request (OCRQ)......................... 60
6.10 Outgoing-Call-Reply (OCRP).......................... 61 6.10 Outgoing-Call-Reply (OCRP).......................... 61
6.11 Outgoing-Call-Connected (OCCN)...................... 62 6.11 Outgoing-Call-Connected (OCCN)...................... 61
6.12 Call-Disconnect-Notify (CDN)........................ 62 6.12 Call-Disconnect-Notify (CDN)........................ 62
6.13 WAN-Error-Notify (WEN).............................. 63 6.13 WAN-Error-Notify (WEN).............................. 62
6.14 Set-Link-Info (SLI)................................. 63 6.14 Set-Link-Info (SLI)................................. 63
6.15 Explicit-Acknowledgement (ACK)...................... 64 6.15 Explicit-Acknowledgement (ACK)...................... 63
7. Control Connection State Machines........................ 64 7. Control Connection State Machines........................ 64
7.1 Malformed Control Messages........................... 65 7.1 Malformed Control Messages........................... 64
7.2 Control Connection States............................ 66 7.2 Control Connection States............................ 65
7.3 Incoming Calls....................................... 68 7.3 Incoming Calls....................................... 67
7.3.1 ICRQ Sender States.............................. 68 7.3.1 ICRQ Sender States.............................. 68
7.3.2 ICRQ Recipient States........................... 70 7.3.2 ICRQ Recipient States........................... 69
7.4 Outgoing Calls....................................... 71 7.4 Outgoing Calls....................................... 70
7.4.1 OCRQ Sender States.............................. 71 7.4.1 OCRQ Sender States.............................. 71
7.4.2 OCRQ Recipient (LAC) States..................... 73 7.4.2 OCRQ Recipient (LAC) States..................... 72
7.5 Termination of a Control Connection.................. 74 7.5 Termination of a Control Connection.................. 73
8. Security Considerations.................................. 74 8. Security Considerations.................................. 74
8.1 Control Connection Endpoint and Message Security..... 74 8.1 Control Connection Endpoint and Message Security..... 74
8.2 Data Channel Security................................ 75 8.2 Data Channel Security................................ 74
8.3 End-to-End Security.................................. 75 8.3 End-to-End Security.................................. 75
8.4 L2TP and IPsec....................................... 75 8.4 L2TP and IPsec....................................... 75
8.5 Impact of L2TPv3 Features on RFC 3193................ 76 8.5 Impact of L2TPv3 Features on RFC 3193................ 75
9. Internationalization Considerations...................... 76 9. Internationalization Considerations...................... 76
10. IANA Considerations..................................... 76 10. IANA Considerations..................................... 76
10.1 Control Message Attribute Value Pairs (AVPs)........ 77 10.1 Control Message Attribute Value Pairs (AVPs)........ 76
10.2 Message Type AVP Values............................. 77 10.2 Message Type AVP Values............................. 77
10.3 Result Code AVP Values.............................. 77 10.3 Result Code AVP Values.............................. 77
10.3.2 Error Code Field Values........................ 78 10.3.2 Error Code Field Values........................ 77
10.4 AVP Header Bits..................................... 78 10.4 AVP Header Bits..................................... 77
10.5 L2TP Control Message Header Bits.................... 78 10.5 L2TP Control Message Header Bits.................... 77
10.6 Pseudowire Types..................................... 78 10.6 Pseudowire Types..................................... 78
10.7 Application Code..................................... 78 10.7 Application Code..................................... 78
10.8 Circuit Status Bits.................................. 78 10.8 Circuit Status Bits.................................. 78
10.9 Default L2-Specific Sublayer bits.................... 79 10.9 Default L2-Specific Sublayer bits.................... 78
10.10 L2-Specific Sublayer Type........................... 79 10.10 L2-Specific Sublayer Type........................... 78
10.11 Data Sequencing Level............................... 79 10.11 Data Sequencing Level............................... 79
13. Acknowledgments......................................... 79 13. Acknowledgments......................................... 79
11. References.............................................. 81 11. References.............................................. 80
11.1 Normative References................................ 81 11.1 Normative References................................ 80
11.2 Informative References.............................. 81 11.2 Informative References.............................. 81
12. Editors' Addresses...................................... 83 12. Editors' Addresses...................................... 82
Appendix A: Control Slow Start and Congestion Avoidance...... 83 Appendix A: Control Slow Start and Congestion Avoidance...... 82
Appendix B: Control Message Examples......................... 84 Appendix B: Control Message Examples......................... 83
Appendix C: Processing Sequence Numbers...................... 85 Appendix C: Processing Sequence Numbers...................... 85
Appendix D: Intellectual Property Notice..................... 87 Appendix D: Intellectual Property Notice..................... 87
Appendix E: Full Copyright Statement......................... 88 Appendix E: Full Copyright Statement......................... 87
1. Introduction 1. Introduction
The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism
for tunneling Layer 2 (L2) "circuits" across a packet-oriented data for tunneling Layer 2 (L2) "circuits" across a packet-oriented data
network (e.g., over IP). L2TP, as originally defined in RFC 2661, is network (e.g., over IP). L2TP, as originally defined in RFC 2661, is
a standard method for tunneling Point to Point Protocol (PPP) a standard method for tunneling Point to Point Protocol (PPP)
[RFC1661] sessions. L2TP has since been adopted for tunneling a [RFC1661] sessions. L2TP has since been adopted for tunneling a
number of other L2 protocols. In order to provide greater number of other L2 protocols. In order to provide greater
modularity, this document describes the base L2TP protocol, modularity, this document describes the base L2TP protocol,
independent of the L2 payload that is being tunneled. independent of the L2 payload that is being tunneled.
The base L2TP protocol defined in this document consists of (1) the The base L2TP protocol defined in this document consists of (1) the
control protocol for dynamic creation, maintenance, and teardown of control protocol for dynamic creation, maintenance, and teardown of
L2TP sessions, and (2) the L2TP data encapsulation to multiplex and L2TP sessions, and (2) the L2TP data encapsulation to multiplex and
demultiplex L2 data streams between two L2TP nodes across an IP demultiplex L2 data streams between two L2TP nodes across an IP
network. Additional documents are expected to be published for each network. Additional documents are expected to be published for each
layer 2 data link emulation type (a.k.a. pseudowire-type) supported layer 2 data link emulation type (a.k.a. pseudowire-type) supported
by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents
will contain any individual details that are outside the scope of will contain any individual details that are outside the scope of
this base specification. this base specification.
1.1 Changes from RFC 2661 1.1 Changes from RFC 2661
Many of the protocol constructs described in this document are Many of the protocol constructs described in this document are
carried over from RFC 2661. Changes include clarifications based on carried over from RFC 2661. Changes include clarifications based on
years of interoperability and deployment experience as well as years of interoperability and deployment experience as well as
modifications to either improve protocol operation or provide a modifications to either improve protocol operation or provide a
clearer separation from PPP. The intent of these modifications is to clearer separation from PPP. The intent of these modifications is to
achieve a healthy balance between code reuse, interoperability achieve a healthy balance between code reuse, interoperability
experience, and a directed evolution of L2TP as it is applied to new experience, and a directed evolution of L2TP as it is applied to new
tasks. tasks.
When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as
defined in RFC 2661 will be referred to as "L2TPv2", corresponding to defined in RFC 2661 will be referred to as "L2TPv2", corresponding to
the value in the Version field of an L2TP header. (Layer 2 the value in the Version field of an L2TP header. (Layer 2
Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, Forwarding, L2F, [RFC2341] was defined as "version 1".) At times,
L2TP as defined in this document will be referred to as "L2TPv3". L2TP as defined in this document will be referred to as "L2TPv3".
Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in
general. general.
Notable differences between L2TPv2 and L2TPv3 include: Notable differences between L2TPv2 and L2TPv3 include:
Separation of all PPP-related AVPs, references, etc., including a Separation of all PPP-related AVPs, references, etc., including a
portion of the L2TP data header that was specific to the needs of portion of the L2TP data header that was specific to the needs of
PPP. The PPP-specific constructs are described in a companion PPP. The PPP-specific constructs are described in a companion
document. document.
Transition from a 16-bit Session ID and Tunnel ID to a 32-bit Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
Session ID and Control Connection ID, respectively. Session ID and Control Connection ID, respectively.
Extension of the Tunnel Authentication mechanism to cover the Extension of the Tunnel Authentication mechanism to cover the
entire control message rather than just a portion of certain entire control message rather than just a portion of certain
messages. messages.
Details of these changes and a recommendation for transitioning to Details of these changes and a recommendation for transitioning to
L2TPv3 may be found in Section 4.7. L2TPv3 may be found in Section 4.7.
1.2 Specification of Requirements 1.2 Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3 Terminology 1.3 Terminology
Attribute Value Pair (AVP) Attribute Value Pair (AVP)
The variable-length concatenation of a unique Attribute The variable-length concatenation of a unique Attribute
(represented by an integer), a length field, and a Value (represented by an integer), a length field, and a Value
containing the actual value identified by the attribute. Zero or containing the actual value identified by the attribute. Zero or
more AVPs make up the body of control messages, which are used in more AVPs make up the body of control messages, which are used in
the establishment, maintenance, and teardown of control the establishment, maintenance, and teardown of control
connections. This basic construct is sometimes referred to as a connections. This basic construct is sometimes referred to as a
Type-Length-Value (TLV) in some specifications. (See also: Type-Length-Value (TLV) in some specifications. (See also:
Control Connection, Control Message.) Control Connection, Control Message.)
Call (Circuit Up) Call (Circuit Up)
The action of transitioning a circuit on an L2TP Access The action of transitioning a circuit on an L2TP Access
Concentrator (LAC) to an "up" or "active" state. A call may be Concentrator (LAC) to an "up" or "active" state. A call may be
dynamically established through signaling properties (e.g., an dynamically established through signaling properties (e.g., an
incoming or outgoing call through the Public Switched Telephone incoming or outgoing call through the Public Switched Telephone
Network (PSTN)) or statically configured (e.g., provisioning a Network (PSTN)) or statically configured (e.g., provisioning a
Virtual Circuit on an interface). A call is defined by its Virtual Circuit on an interface). A call is defined by its
properties (e.g., type of call, called number, etc.) and its data properties (e.g., type of call, called number, etc.) and its data
traffic. (See also: Circuit, Session, Incoming Call, Outgoing traffic. (See also: Circuit, Session, Incoming Call, Outgoing
Call, Outgoing Call Request.) Call, Outgoing Call Request.)
Circuit Circuit
A general term identifying any one of a wide range of L2 A general term identifying any one of a wide range of L2
connections. A circuit may be virtual in nature (e.g., an ATM connections. A circuit may be virtual in nature (e.g., an ATM
PVC, an ethernet VLAN, or an L2TP session), or it may have direct PVC, an ethernet VLAN, or an L2TP session), or it may have direct
correlation to a physical layer (e.g., an RS-232 serial line). correlation to a physical layer (e.g., an RS-232 serial line).
Circuits may be statically configured with a relatively long-lived Circuits may be statically configured with a relatively long-lived
uptime, or dynamically established with signaling to govern the uptime, or dynamically established with signaling to govern the
establishment, maintenance, and teardown of the circuit. For the establishment, maintenance, and teardown of the circuit. For the
purposes of this document, a statically configured circuit is purposes of this document, a statically configured circuit is
considered to be essentially the same as a very simple, long- considered to be essentially the same as a very simple, long-
lived, dynamic circuit. (See also: Call, Remote System.) lived, dynamic circuit. (See also: Call, Remote System.)
Client Client
(See Remote System.) (See Remote System.)
Control Connection Control Connection
An L2TP control connection is a reliable control channel that is An L2TP control connection is a reliable control channel that is
used to establish, maintain, and release individual L2TP sessions used to establish, maintain, and release individual L2TP sessions
as well as the control connection itself. (See also: Control as well as the control connection itself. (See also: Control
Message, Data Channel.) Message, Data Channel.)
Control Message Control Message
An L2TP message used by the control connection. (See also: An L2TP message used by the control connection. (See also:
Control Connection.) Control Connection.)
Data Message Data Message
Message used by the data channel. (a.k.a. Data Packet, See also: Message used by the data channel. (a.k.a. Data Packet, See also:
Data Channel.) Data Channel.)
Data Channel Data Channel
The channel for L2TP-encapsulated data traffic that passes between The channel for L2TP-encapsulated data traffic that passes between
two LCCEs over a Packet Switched Network (i.e. IP). (See also: two LCCEs over a Packet Switched Network (i.e. IP). (See also:
Control Connection, Data Message.) Control Connection, Data Message.)
Incoming Call Incoming Call
The action of receiving a call (circuit up event) on an LAC. The The action of receiving a call (circuit up event) on an LAC. The
call may have been placed by a remote system (e.g., a phone call call may have been placed by a remote system (e.g., a phone call
over a PSTN), or it may have been triggered by a local event over a PSTN), or it may have been triggered by a local event
(e.g., interesting traffic routed to a virtual interface). An (e.g., interesting traffic routed to a virtual interface). An
incoming call that needs to be tunneled (as determined by the LAC) incoming call that needs to be tunneled (as determined by the LAC)
results in the generation of an L2TP ICRQ message. (See also: results in the generation of an L2TP ICRQ message. (See also:
Call, Outgoing Call, Outgoing Call Request.) Call, Outgoing Call, Outgoing Call Request.)
L2TP Access Concentrator (LAC) L2TP Access Concentrator (LAC)
If an L2TP Control Connection Endpoint (LCCE) is being used to If an L2TP Control Connection Endpoint (LCCE) is being used to
cross-connect an L2TP session directly to a data link, we refer to cross-connect an L2TP session directly to a data link, we refer to
it as an L2TP Access Concentrator (LAC). An LCCE may act as both it as an L2TP Access Concentrator (LAC). An LCCE may act as both
an L2TP Network Server (LNS) for some sessions and an LAC for an L2TP Network Server (LNS) for some sessions and an LAC for
others, so these terms must only be used within the context of a others, so these terms must only be used within the context of a
given set of sessions unless the LCCE is in fact single purpose given set of sessions unless the LCCE is in fact single purpose
for a given topology. (See also: LCCE, LNS.) for a given topology. (See also: LCCE, LNS.)
L2TP Control Connection Endpoint (LCCE) L2TP Control Connection Endpoint (LCCE)
An L2TP node which exists at either end of an L2TP control An L2TP node which exists at either end of an L2TP control
connection. May also be referred to as an LAC or LNS, depending on connection. May also be referred to as an LAC or LNS, depending on
whether tunneled frames are processed at the data link (LAC) or whether tunneled frames are processed at the data link (LAC) or
network layer (LNS). (See also: LAC, LNS.) network layer (LNS). (See also: LAC, LNS.)
L2TP Network Server (LNS) L2TP Network Server (LNS)
If a given L2TP session is terminated at the L2TP node and the If a given L2TP session is terminated at the L2TP node and the
encapsulated network layer (L3) packet processed on a virtual encapsulated network layer (L3) packet processed on a virtual
interface, we refer to this L2TP node as an L2TP Network Server interface, we refer to this L2TP node as an L2TP Network Server
(LNS). A given LCCE may act as both an LNS for some sessions and (LNS). A given LCCE may act as both an LNS for some sessions and
an LAC for others, so these terms must only be used within the an LAC for others, so these terms must only be used within the
context of a given set of sessions unless the LCCE is in fact context of a given set of sessions unless the LCCE is in fact
single purpose for a given topology. (See also: LCCE, LAC.) single purpose for a given topology. (See also: LCCE, LAC.)
Outgoing Call Outgoing Call
The action of placing a call by an LAC, typically in response to The action of placing a call by an LAC, typically in response to
policy directed by the peer in an Outgoing Call Request message. policy directed by the peer in an Outgoing Call Request message.
(See also: Call, Incoming Call, Outgoing Call Request.) (See also: Call, Incoming Call, Outgoing Call Request.)
Outgoing Call Request Outgoing Call Request
A request sent to an LAC to place an outgoing call. The request A request sent to an LAC to place an outgoing call. The request
contains specific information not known a priori by the LAC (i.e., contains specific information not known a priori by the LAC (i.e.,
a number to dial). (See also: Call, Incoming Call, Outgoing a number to dial). (See also: Call, Incoming Call, Outgoing
Call.) Call.)
Packet-Switched Network (PSN) Packet-Switched Network (PSN)
A network that uses packet-switching technology for data delivery. A network that uses packet-switching technology for data delivery.
For L2TPv3, this layer is principally IP. Other examples include For L2TPv3, this layer is principally IP. Other examples include
MPLS, Frame Relay, and ATM. MPLS, Frame Relay, and ATM.
Peer Peer
When used in context with L2TP, Peer refers to the far end of an When used in context with L2TP, Peer refers to the far end of an
L2TP control connection (i.e., the remote LCCE). An LAC's peer L2TP control connection (i.e., the remote LCCE). An LAC's peer
may be either an LNS or another LAC. Similarly, an LNS's peer may may be either an LNS or another LAC. Similarly, an LNS's peer may
be either an LAC or another LNS. (See also: LAC, LCCE, LNS.) be either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
Pseudowire (PW) Pseudowire (PW)
An emulated circuit as it traverses a PSN. There is one An emulated circuit as it traverses a PSN. There is one
Pseudowire per L2TP Session. (See also: Packet-Switched Network, Pseudowire per L2TP Session. (See also: Packet-Switched Network,
Session.) Session.)
Pseudowire Type Pseudowire Type
The payload type being carried within an L2TP session. Examples The payload type being carried within an L2TP session. Examples
include PPP, Ethernet, and Frame Relay. (See also: Session.) include PPP, Ethernet, and Frame Relay. (See also: Session.)
Remote System Remote System
An end-system or router connected by a circuit to an LAC. An end-system or router connected by a circuit to an LAC.
Session Session
An L2TP session is the entity which is created between two LCCEs An L2TP session is the entity which is created between two LCCEs
in order to exchange parameters for and maintain an emulated L2 in order to exchange parameters for and maintain an emulated L2
connection. Multiple sessions may be associated with a single connection. Multiple sessions may be associated with a single
Control Connection. Control Connection.
Zero-Length Body (ZLB) Message Zero-Length Body (ZLB) Message
A control message with only an L2TP header. ZLB messages are used A control message with only an L2TP header. ZLB messages are used
only to acknowledge messages on the L2TP reliable control channel. only to acknowledge messages on the L2TP reliable control channel.
(See also: Control Message.) (See also: Control Message.)
2. Topology 2. Topology
L2TP operates between two L2TP Control Connection Endpoints (LCCEs), L2TP operates between two L2TP Control Connection Endpoints (LCCEs),
tunneling traffic across a packet network. There are three tunneling traffic across a packet network. There are three
predominant tunneling models in which L2TP operates: LAC-LNS (or vice predominant tunneling models in which L2TP operates: LAC-LNS (or vice
versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. versa), LAC-LAC, and LNS-LNS. These models are diagrammed below.
(Dotted lines designate network connections. Solid lines designate (Dotted lines designate network connections. Solid lines designate
circuit connections.) circuit connections.)
Figure 2.0: L2TP Reference Models Figure 2.0: L2TP Reference Models
(a) LAC-LNS Reference Model: On one side, the LAC receives traffic (a) LAC-LNS Reference Model: On one side, the LAC receives traffic
from an L2 circuit, which it forwards via L2TP across an IP or other from an L2 circuit, which it forwards via L2TP across an IP or other
packet-based network. On the other side, an LNS logically terminates packet-based network. On the other side, an LNS logically terminates
the L2 circuit locally and routes network traffic to the home the L2 circuit locally and routes network traffic to the home
network. The action of session establishment is driven by the LAC network. The action of session establishment is driven by the LAC
(as an incoming call) or the LNS (as an outgoing call). (as an incoming call) or the LNS (as an outgoing call).
+-----+ L2 +-----+ +-----+ +-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network] | |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
remote remote
system system
|<-- emulated service -->| |<-- emulated service -->|
|<----------- L2 service ------------>| |<----------- L2 service ------------>|
(b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs.
Each LAC forwards circuit traffic from the remote system to the peer Each LAC forwards circuit traffic from the remote system to the peer
LAC using L2TP, and vice versa. In its simplest form, an LAC acts as LAC using L2TP, and vice versa. In its simplest form, an LAC acts as
a simple cross-connect between a circuit to a remote system and an a simple cross-connect between a circuit to a remote system and an
L2TP session. This model typically involves symmetric establishment; L2TP session. This model typically involves symmetric establishment;
that is, either side of the connection may initiate a session at any that is, either side of the connection may initiate a session at any
time (or simultaneously, in which a tie-breaking mechanism is time (or simultaneously, in which a tie-breaking mechanism is
utilized). utilized).
+-----+ L2 +-----+ +-----+ L2 +-----+ +-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| | | |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
remote remote remote remote
system system system system
|<- emulated service ->| |<- emulated service ->|
|<----------------- L2 service ----------------->| |<----------------- L2 service ----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A
user-level, traffic-generated, or signaled event typically drives user-level, traffic-generated, or signaled event typically drives
session establishment from one side of the tunnel. For example, a session establishment from one side of the tunnel. For example, a
tunnel generated from a PC by a user, or automatically by customer tunnel generated from a PC by a user, or automatically by customer
premises equipment. premises equipment.
+-----+ +-----+ +-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network] [home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+ +-----+ +-----+
|<- emulated service ->| |<- emulated service ->|
|<---- L2 service ---->| |<---- L2 service ---->|
Note: In L2TPv2, user-driven tunneling of this type is often referred Note: In L2TPv2, user-driven tunneling of this type is often referred
to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part
of a software package on a host is sometimes referred to as an "LAC of a software package on a host is sometimes referred to as an "LAC
Client" [RFC2661]. Client" [RFC2661].
3. Protocol Overview 3. Protocol Overview
L2TP utilizes two types of messages, control messages and data L2TP utilizes two types of messages, control messages and data
messages (sometimes referred to as "control packets" and "data messages (sometimes referred to as "control packets" and "data
packets", respectively). Control messages are used in the packets", respectively). Control messages are used in the
establishment, maintenance, and clearing of control connections and establishment, maintenance, and clearing of control connections and
sessions. These messages utilize a reliable control channel within sessions. These messages utilize a reliable control channel within
L2TP to guarantee delivery (see Section 4.2 for details). Data L2TP to guarantee delivery (see Section 4.2 for details). Data
messages are used to encapsulate the L2 traffic being carried over messages are used to encapsulate the L2 traffic being carried over
the L2TP session. Unlike control messages, data messages are not the L2TP session. Unlike control messages, data messages are not
retransmitted when packet loss occurs. retransmitted when packet loss occurs.
The L2TPv3 control message format defined in this document borrows The L2TPv3 control message format defined in this document borrows
largely from L2TPv2. These control messages are used in conjunction largely from L2TPv2. These control messages are used in conjunction
with the associated protocol state machines that govern the dynamic with the associated protocol state machines that govern the dynamic
setup, maintenance, and teardown for L2TP sessions. The data message setup, maintenance, and teardown for L2TP sessions. The data message
format for tunneling data packets may be utilized with or without the format for tunneling data packets may be utilized with or without the
L2TP control channel, either via manual configuration or other L2TP control channel, either via manual configuration or other
signaling methods to pre-configure or distribute L2TP session signaling methods to pre-configure or distribute L2TP session
information. Utilization of the L2TP data message format with other information. Utilization of the L2TP data message format with other
signaling methods is outside the scope of this document. signaling methods is outside the scope of this document.
Figure 3.0: L2TPv3 Structure Figure 3.0: L2TPv3 Structure
+-------------------+ +-----------------------+ +-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message | | Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+ +-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header | | L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+ +-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel | | L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) | | (unreliable) | | (reliable) |
+-------------------+----+-----------------------+ +-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) | | Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+ +------------------------------------------------+
Figure 3.0 depicts the relationship of control messages and data Figure 3.0 depicts the relationship of control messages and data
messages over the L2TP control and data channels, respectively. Data messages over the L2TP control and data channels, respectively. Data
messages are passed over an unreliable data channel, encapsulated by messages are passed over an unreliable data channel, encapsulated by
an L2TP header, and sent over a Packet-Switched Network (PSN) such as an L2TP header, and sent over a Packet-Switched Network (PSN) such as
IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over
a reliable L2TP control channel, which operates over the same PSN. a reliable L2TP control channel, which operates over the same PSN.
The necessary setup for tunneling a session with L2TP consists of two The necessary setup for tunneling a session with L2TP consists of two
steps: (1) Establishing the control connection, and (2) establishing steps: (1) Establishing the control connection, and (2) establishing
a session as triggered by an incoming call or outgoing call. An L2TP a session as triggered by an incoming call or outgoing call. An L2TP
session MUST be established before L2TP can begin to forward session session MUST be established before L2TP can begin to forward session
frames. Multiple sessions may be bound to a single control frames. Multiple sessions may be bound to a single control
connection, and multiple control connections may exist between the connection, and multiple control connections may exist between the
same two LCCEs. same two LCCEs.
3.1 Control Message Types 3.1 Control Message Types
The Message Type AVP (see Section 5.4.1) defines the specific type of The Message Type AVP (see Section 5.4.1) defines the specific type of
control message being sent. control message being sent.
This document defines the following control message types (see This document defines the following control message types (see
Sections 6.1 through 6.13 for details on the construction and use of Sections 6.1 through 6.13 for details on the construction and use of
each message): each message):
Control Connection Management Control Connection Management
0 (reserved) 0 (reserved)
1 (SCCRQ) Start-Control-Connection-Request 1 (SCCRQ) Start-Control-Connection-Request
2 (SCCRP) Start-Control-Connection-Reply 2 (SCCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected 3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification 4 (StopCCN) Stop-Control-Connection-Notification
5 (reserved) 5 (reserved)
6 (HELLO) Hello 6 (HELLO) Hello
TBA-M1 (ACK) Explicit Acknowledgement TBA-M1 (ACK) Explicit Acknowledgement
Call Management Call Management
7 (OCRQ) Outgoing-Call-Request 7 (OCRQ) Outgoing-Call-Request
8 (OCRP) Outgoing-Call-Reply 8 (OCRP) Outgoing-Call-Reply
9 (OCCN) Outgoing-Call-Connected 9 (OCCN) Outgoing-Call-Connected
10 (ICRQ) Incoming-Call-Request 10 (ICRQ) Incoming-Call-Request
11 (ICRP) Incoming-Call-Reply 11 (ICRP) Incoming-Call-Reply
12 (ICCN) Incoming-Call-Connected 12 (ICCN) Incoming-Call-Connected
13 (reserved) 13 (reserved)
14 (CDN) Call-Disconnect-Notify 14 (CDN) Call-Disconnect-Notify
Error Reporting Error Reporting
15 (WEN) WAN-Error-Notify 15 (WEN) WAN-Error-Notify
Link Status Change Reporting Link Status Change Reporting
16 (SLI) Set-Link-Info 16 (SLI) Set-Link-Info
3.2 L2TP Header Formats 3.2 L2TP Header Formats
This section defines header formats for L2TP control messages and This section defines header formats for L2TP control messages and
L2TP data messages. All values are placed into their respective L2TP data messages. All values are placed into their respective
fields and sent in network order (high-order octets first). fields and sent in network order (high-order octets first).
3.2.1 L2TP Control Message Header 3.2.1 L2TP Control Message Header
The L2TP control message header provides information for the reliable The L2TP control message header provides information for the reliable
transport of messages that govern the establishment, maintenance, and transport of messages that govern the establishment, maintenance, and
teardown of L2TP sessions. By default, control messages are sent teardown of L2TP sessions. By default, control messages are sent
over the underlying media in-band with L2TP data messages. over the underlying media in-band with L2TP data messages.
The L2TP control message header is formatted as follows: The L2TP control message header is formatted as follows:
Figure 3.2.1: L2TP Control Message Header Figure 3.2.1: L2TP Control Message Header
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID | | Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr | | Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 1, indicating that this is a control The T bit MUST be set to 1, indicating that this is a control
message. message.
The L and S bits MUST be set to 1, indicating that the Length field The L and S bits MUST be set to 1, indicating that the Length field
and sequence numbers are present. and sequence numbers are present.
The x bits are reserved for future extensions. All reserved bits The x bits are reserved for future extensions. All reserved bits
MUST be set to 0 on outgoing messages and ignored on incoming MUST be set to 0 on outgoing messages and ignored on incoming
messages. messages.
The Ver field indicates the version of the L2TP control message The Ver field indicates the version of the L2TP control message
header described in this document. On sending, this field MUST be header described in this document. On sending, this field MUST be
set to 3 for all messages (unless operating in an environment which set to 3 for all messages (unless operating in an environment which
includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section
4.1 for details). 4.1 for details).
The Length field indicates the total length of the message in octets, The Length field indicates the total length of the message in octets,
always calculated from the start of the control message header itself always calculated from the start of the control message header itself
(beginning with the T bit). (beginning with the T bit).
The Control Connection ID field contains the identifier for the The Control Connection ID field contains the identifier for the
control connection. L2TP control connections are named by control connection. L2TP control connections are named by
identifiers that have local significance only. That is, the same identifiers that have local significance only. That is, the same
control connection will be given unique Control Connection IDs by control connection will be given unique Control Connection IDs by
each LCCE from within each endpoint's own Control Connection ID each LCCE from within each endpoint's own Control Connection ID
number space. As such, the Control Connection ID in each message is number space. As such, the Control Connection ID in each message is
that of the intended recipient, not the sender. Non-zero Control that of the intended recipient, not the sender. Non-zero Control
Connection IDs are selected and exchanged as Assigned Control Connection IDs are selected and exchanged as Assigned Control
Connection ID AVPs during the creation of a control connection. Connection ID AVPs during the creation of a control connection.
Ns indicates the sequence number for this control message, beginning Ns indicates the sequence number for this control message, beginning
at zero and incrementing by one (modulo 2**16) for each message sent. at zero and incrementing by one (modulo 2**16) for each message sent.
See Section 4.2 for more information on using this field. See Section 4.2 for more information on using this field.
Nr indicates the sequence number expected in the next control message Nr indicates the sequence number expected in the next control message
to be received. Thus, Nr is set to the Ns of the last in-order to be received. Thus, Nr is set to the Ns of the last in-order
message received plus one (modulo 2**16). See Section 4.2 for more message received plus one (modulo 2**16). See Section 4.2 for more
information on using this field. information on using this field.
3.2.2 L2TP Data Message 3.2.2 L2TP Data Message
In general, an L2TP data message consists of a (1) Session Header, In general, an L2TP data message consists of a (1) Session Header,
(2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as
depicted below. depicted below.
Figure 3.2.2: L2TP Data Message Header Figure 3.2.2: L2TP Data Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Header | | L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer | | L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Payload ... | Tunnel Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TP Session Header is specific to the encapsulating PSN over The L2TP Session Header is specific to the encapsulating PSN over
which the L2TP traffic is delivered. The Session Header MUST provide which the L2TP traffic is delivered. The Session Header MUST provide
(1) a method of distinguishing traffic among multiple L2TP data (1) a method of distinguishing traffic among multiple L2TP data
sessions and (2) a method of distinguishing data messages from sessions and (2) a method of distinguishing data messages from
control messages. control messages.
Each type of encapsulating PSN MUST define its own session header, Each type of encapsulating PSN MUST define its own session header,
clearly identifying the format of the header and parameters necessary clearly identifying the format of the header and parameters necessary
to setup the session. Section 4.1 defines two session headers, one to setup the session. Section 4.1 defines two session headers, one
for transport over UDP and one for transport over IP. for transport over UDP and one for transport over IP.
The L2 Specific Sublayer is an intermediary layer between the L2TP The L2 Specific Sublayer is an intermediary layer between the L2TP
session header and the start of the tunneled frame. It contains session header and the start of the tunneled frame. It contains
control fields that are used to facilitate the tunneling of each control fields that are used to facilitate the tunneling of each
frame (e.g. sequence numbers or flags). The default L2-Specific frame (e.g. sequence numbers or flags). The default L2-Specific
Sublayer for L2TPv3 is defined in Section 4.6. Sublayer for L2TPv3 is defined in Section 4.6.
The Data Message Header is followed by the Tunnel Payload, including The Data Message Header is followed by the Tunnel Payload, including
any necessary L2 framing as defined in the payload-specific companion any necessary L2 framing as defined in the payload-specific companion
documents. documents.
3.3 Control Connection Management 3.3 Control Connection Management
The L2TP Control Connection handles dynamic establishment, teardown, The L2TP Control Connection handles dynamic establishment, teardown,
and maintenance of the L2TP sessions and of the control connection and maintenance of the L2TP sessions and of the control connection
itself. The reliable delivery of control messages is described in itself. The reliable delivery of control messages is described in
Section 4.2. Section 4.2.
This section describes typical control connection establishment and This section describes typical control connection establishment and
teardown exchanges. It is important to note that, in the diagrams teardown exchanges. It is important to note that, in the diagrams
that follow, the reliable control message delivery mechanism exists that follow, the reliable control message delivery mechanism exists
independently of the L2TP state machine. For instance, Explicit independently of the L2TP state machine. For instance, Explicit
Acknowledgement (ACK) messages may be sent after any of the control Acknowledgement (ACK) messages may be sent after any of the control
messages indicated in the exchanges below if an acknowledgment is not messages indicated in the exchanges below if an acknowledgment is not
piggybacked on a later control message. piggybacked on a later control message.
LCCEs are identified during control connection establishment either LCCEs are identified during control connection establishment either
by the Host Name AVP, the Router ID AVP, or a combination of the two by the Host Name AVP, the Router ID AVP, or a combination of the two
(see Section 5.4.3). The identity of a peer LCCE is central to (see Section 5.4.3). The identity of a peer LCCE is central to
selecting proper configuration parameters (i.e. Hello interval, selecting proper configuration parameters (i.e. Hello interval,
window size, etc.) for a control connection, as well as for window size, etc.) for a control connection, as well as for
determination of how to setup associated sessions within the control determination of how to setup associated sessions within the control
connection, password lookup for control connection authentication, connection, password lookup for control connection authentication,
control connection level tie-breaking, etc. control connection level tie-breaking, etc.
3.3.1 Control Connection Establishment 3.3.1 Control Connection Establishment
Establishment of the control connection involves an exchange of AVPs Establishment of the control connection involves an exchange of AVPs
that identifies the peer and its capabilities. that identifies the peer and its capabilities.
A three-message exchange is used to establish the control connection. A three-message exchange is used to establish the control connection.
The following is a typical message exchange: The following is a typical message exchange:
LCCE A LCCE B LCCE A LCCE B
------ ------ ------ ------
SCCRQ -> SCCRQ ->
<- SCCRP <- SCCRP
SCCCN -> SCCCN ->
3.3.2 Control Connection Teardown 3.3.2 Control Connection Teardown
Control connection teardown may be initiated by either LCCE and is Control connection teardown may be initiated by either LCCE and is
accomplished by sending a single StopCCN control message. As part of accomplished by sending a single StopCCN control message. As part of
the reliable control message delivery mechanism, the recipient of a the reliable control message delivery mechanism, the recipient of a
StopCCN MUST send an ACK message to acknowledge receipt of the StopCCN MUST send an ACK message to acknowledge receipt of the
message and maintain enough control connection state to properly message and maintain enough control connection state to properly
accept StopCCN retransmissions over at least a full retransmission accept StopCCN retransmissions over at least a full retransmission
cycle (in case the ACK message is lost). The recommended time for a cycle (in case the ACK message is lost). The recommended time for a
full retransmission cycle is at least 31 seconds (see Section 4.2). full retransmission cycle is at least 31 seconds (see Section 4.2).
The following is an example of a typical control message exchange: The following is an example of a typical control message exchange:
LCCE A LCCE B LCCE A LCCE B
------ ------ ------ ------
StopCCN -> StopCCN ->
(Clean up) (Clean up)
(Wait) (Wait)
(Clean up) (Clean up)
An implementation may shut down an entire control connection and all An implementation may shut down an entire control connection and all
sessions associated with the control connection by sending the sessions associated with the control connection by sending the
StopCCN. Thus, it is not necessary to clear each session StopCCN. Thus, it is not necessary to clear each session
individually when tearing down the whole control connection. individually when tearing down the whole control connection.
3.4 Session Management 3.4 Session Management
After successful control connection establishment, individual After successful control connection establishment, individual
sessions may be created. Each session corresponds to a single data sessions may be created. Each session corresponds to a single data
stream between the two LCCEs. This section describes the typical stream between the two LCCEs. This section describes the typical
call establishment and teardown exchanges. call establishment and teardown exchanges.
3.4.1 Session Establishment for an Incoming Call 3.4.1 Session Establishment for an Incoming Call
A three-message exchange is used to establish the session. The A three-message exchange is used to establish the session. The
following is a typical sequence of events: following is a typical sequence of events:
LCCE A LCCE B LCCE A LCCE B
------ ------ ------ ------
(Call (Call
Detected) Detected)
ICRQ -> ICRQ ->
<- ICRP <- ICRP
(Call (Call
Accepted) Accepted)
ICCN -> ICCN ->
3.4.2 Session Establishment for an Outgoing Call 3.4.2 Session Establishment for an Outgoing Call
A three-message exchange is used to set up the session. The A three-message exchange is used to set up the session. The
following is a typical sequence of events: following is a typical sequence of events:
LCCE A LCCE B LCCE A LCCE B
------ ------ ------ ------
<- OCRQ <- OCRQ
OCRP -> OCRP ->
(Perform (Perform
Call Call
Operation) Operation)
OCCN -> OCCN ->
(Call Operation (Call Operation
Completed Completed
Successfully) Successfully)
3.4.3 Session Teardown 3.4.3 Session Teardown
Session teardown may be initiated by either the LAC or LNS and is Session teardown may be initiated by either the LAC or LNS and is
accomplished by sending a CDN control message. After the last accomplished by sending a CDN control message. After the last
session is cleared, the control connection MAY be torn down as well session is cleared, the control connection MAY be torn down as well
(and typically is). The following is an example of a typical control (and typically is). The following is an example of a typical control
message exchange: message exchange:
LCCE A LCCE B LCCE A LCCE B
------ ------ ------ ------
CDN -> CDN ->
(Clean up) (Clean up)
(Clean up) (Clean up)
4. Protocol Operation 4. Protocol Operation
4.1 L2TP Over Specific Packet-Switched Networks (PSN) 4.1 L2TP Over Specific Packet-Switched Networks (PSN)
If necessary, L2TP may operate over a variety of Packet Switched If necessary, L2TP may operate over a variety of Packet Switched
Networks. There are two modes described for operation over IPv4, L2TP Networks. There are two modes described for operation over IPv4, L2TP
over IP (Section 4.1.1) and L2TP over UDP (Section 4.1.2). L2TPv3 over IP (Section 4.1.1) and L2TP over UDP (Section 4.1.2). L2TPv3
implementations MUST support L2TP over IP and SHOULD support L2TP implementations MUST support L2TP over IP and SHOULD support L2TP
over UDP for better NAT and FW traversal, and easier migration from over UDP for better NAT and FW traversal, and easier migration from
L2TPv2. L2TPv2.
L2TP over other PSNs may be defined, but the specifics are outside L2TP over other PSNs may be defined, but the specifics are outside
the scope of this document. Examples of L2TPv2 over other PSNs the scope of this document. Examples of L2TPv2 over other PSNs
include [RFC3070] and [RFC3355]. include [RFC3070] and [RFC3355].
The following field definitions are defined for use in all L2TP The following field definitions are defined for use in all L2TP
Session Header encapsulations. Session Header encapsulations.
Session ID Session ID
A 32-bit field containing a non-zero identifier for a session. A 32-bit field containing a non-zero identifier for a session.
L2TP sessions are named by identifiers that have local L2TP sessions are named by identifiers that have local
significance only. That is, the same logical session will be significance only. That is, the same logical session will be
given different Session IDs by each end of the control connection given different Session IDs by each end of the control connection
for the life of the session. When the L2TP control connection is for the life of the session. When the L2TP control connection is
used for session establishment, Session IDs are selected and used for session establishment, Session IDs are selected and
exchanged as Local Session ID AVPs during the creation of a exchanged as Local Session ID AVPs during the creation of a
session. session.
Cookie Cookie
The optional Cookie field contains a variable length (maximum 64 The optional Cookie field contains a variable length (maximum 64
bits), value used to check the association of a received data bits), value used to check the association of a received data
message with the session identified by the Session ID. The Cookie message with the session identified by the Session ID. The Cookie
MUST be set to the configured or signaled random value for this MUST be set to the configured or signaled random value for this
session utilizing all bits in the field. The Cookie provides an session utilizing all bits in the field. The Cookie provides an
additional level of guarantee that a data message has been additional level of guarantee that a data message has been
directed to the proper session by the Session ID. A well-chosen directed to the proper session by the Session ID. A well-chosen
Cookie may prevent inadvertent misdirection of stray packets with Cookie may prevent inadvertent misdirection of stray packets with
recently reused Session IDs, Session IDs subject to packet recently reused Session IDs, Session IDs subject to packet
corruption, etc. The Cookie may also provide protection against corruption, etc. The Cookie may also provide protection against
some specific malicious packet insertion attacks, as described in some specific malicious packet insertion attacks, as described in
section 8.2. section 8.2.
When the L2TP control connection is used for session When the L2TP control connection is used for session
establishment, random Cookie values are selected and exchanged as establishment, random Cookie values are selected and exchanged as
Assigned Cookie AVPs during session creation. Assigned Cookie AVPs during session creation.
4.1.1 L2TPv3 over IP 4.1.1 L2TPv3 over IP
L2TPv3 over IP utilizes the IANA assigned IP protocol ID 115. L2TPv3 over IP utilizes the IANA assigned IP protocol ID 115.
4.1.1.1 L2TPv3 Session Header Over IP 4.1.1.1 L2TPv3 Session Header Over IP
Unlike L2TP over UDP, the L2TPv3 session header over IP is free of Unlike L2TP over UDP, the L2TPv3 session header over IP is free of
any restrictions imposed by coexistence with L2TPv2 and L2F. As any restrictions imposed by coexistence with L2TPv2 and L2F. As
such, the header format has been redesigned to optimize packet such, the header format has been redesigned to optimize packet
processing. The following session header format is utilized when processing. The following session header format is utilized when
operating L2TPv3 over IP: operating L2TPv3 over IP:
Figure 4.1.1.1: L2TPv3 Session Header Over IP Figure 4.1.1.1: L2TPv3 Session Header Over IP
0 1 2 3 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 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 | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)... | Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID and Cookie fields are as defined in Section 4.1. The The Session ID and Cookie fields are as defined in Section 4.1. The
Session ID of zero is reserved for use by L2TP control messages (see Session ID of zero is reserved for use by L2TP control messages (see
Section 4.1.1.2). Section 4.1.1.2).
4.1.1.2 L2TP Control and Data Traffic over IP 4.1.1.2 L2TP Control and Data Traffic over IP
Unlike L2TP over UDP which uses the common T bit to distinguish Unlike L2TP over UDP which uses the common T bit to distinguish
between L2TP control and data packets, L2TP over IP uses the reserved between L2TP control and data packets, L2TP over IP uses the reserved
Session ID of zero (0) when sending control messages. It is presumed Session ID of zero (0) when sending control messages. It is presumed
that checking for the zero Session ID is more efficient -- both in that checking for the zero Session ID is more efficient -- both in
header size for data packets and in processing speed for header size for data packets and in processing speed for
distinguishing between control and data messages -- than checking for distinguishing between control and data messages -- than checking for
the presence of a given single bit. the presence of a given single bit.
The entire control message header over IP, including the zero session The entire control message header over IP, including the zero session
ID, appears as follows: ID, appears as follows:
Figure 4.1.1.2: L2TPv3 Control Message Header Over IP Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) | | (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID | | Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr | | Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Named fields are as defined in Section 3.2.1. Note that the Length Named fields are as defined in Section 3.2.1. Note that the Length
field is still calculated from the beginning of the control message field is still calculated from the beginning of the control message
header, beginning with the T bit. It does NOT include the "(32 bits header, beginning with the T bit. It does NOT include the "(32 bits
of zeros)" depicted above. of zeros)" depicted above.
When operating directly over IP, L2TP packets lose the ability to When operating directly over IP, L2TP packets lose the ability to
take advantage of the UDP checksum as a simple packet integrity take advantage of the UDP checksum as a simple packet integrity
check. This is of particular concern for L2TP control messages. check. This is of particular concern for L2TP control messages.
Control Message Authentication (Section 4.3), even with an empty Control Message Authentication (Section 4.3), even with an empty
password field, provides for a sufficient packet integrity check and password field, provides for a sufficient packet integrity check and
SHOULD always be enabled. SHOULD always be enabled.
4.1.2 L2TP over UDP 4.1.2 L2TP over UDP
L2TPv3 over UDP must consider other L2 tunneling protocols that may L2TPv3 over UDP must consider other L2 tunneling protocols that may
be operating in the same environment, including L2TPv2 [RFC2661] and be operating in the same environment, including L2TPv2 [RFC2661] and
L2F [RFC2341]. L2F [RFC2341].
While there are efficiencies gained by running L2TP directly over IP, While there are efficiencies gained by running L2TP directly over IP,
there are possible side effects as well. For instance, L2TP over IP there are possible side effects as well. For instance, L2TP over IP
is not as NAT-friendly as L2TP over UDP. is not as NAT-friendly as L2TP over UDP.
4.1.2.1 L2TP Session Header Over UDP 4.1.2.1 L2TP Session Header Over UDP
The following session header format is utilized when operating L2TPv3 The following session header format is utilized when operating L2TPv3
over UDP: over UDP:
Figure 4.1.2.1: L2TPv3 Session Header over UDP Figure 4.1.2.1: L2TPv3 Session Header over UDP
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)... | Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 0, indicating that this is a data message. The T bit MUST be set to 0, indicating that this is a data message.
The x bits and Reserved field are reserved for future extensions. The x bits and Reserved field are reserved for future extensions.
All reserved values MUST be set to 0 on outgoing messages and ignored All reserved values MUST be set to 0 on outgoing messages and ignored
on incoming messages. on incoming messages.
The Ver field MUST be set to 3, indicating an L2TPv3 message. The Ver field MUST be set to 3, indicating an L2TPv3 message.
Note that the initial bits 1, 4, 6 and 7 have meaning in L2TPv2 Note that the initial bits 1, 4, 6 and 7 have meaning in L2TPv2
[RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus,
for UDP mode on a system that supports both versions of L2TP, it is for UDP mode on a system that supports both versions of L2TP, it is
important that the Ver field be inspected first to determine the important that the Ver field be inspected first to determine the
Version of the header before acting upon any of these bits. Version of the header before acting upon any of these bits.
The Session ID and Cookie fields are as defined in Section 4.1. The Session ID and Cookie fields are as defined in Section 4.1.
4.1.2.2 UDP Port Selection 4.1.2.2 UDP Port Selection
The method for UDP Port Selection defined in this section is The method for UDP Port Selection defined in this section is
identical to than defined for L2TPv2 [RFC2661]. identical to than defined for L2TPv2 [RFC2661].
When negotiating a control connection over UDP, control messages MUST When negotiating a control connection over UDP, control messages MUST
be sent as UDP datagrams using the registered UDP port 1701 be sent as UDP datagrams using the registered UDP port 1701
[RFC1700]. The initiator of an L2TP control connection picks an [RFC1700]. The initiator of an L2TP control connection picks an
available source UDP port (which may or may not be 1701), and sends available source UDP port (which may or may not be 1701), and sends
to the desired destination address at port 1701. The recipient picks to the desired destination address at port 1701. The recipient picks
a free port on its own system (which may or may not be 1701) and a free port on its own system (which may or may not be 1701) and
sends its reply to the initiator's UDP port and address, setting its sends its reply to the initiator's UDP port and address, setting its
own source port to the free port it found. own source port to the free port it found.
Any subsequent traffic associated with this control connection Any subsequent traffic associated with this control connection
(either control traffic or data traffic from a session established (either control traffic or data traffic from a session established
through this control connection) must use these same UDP ports. through this control connection) must use these same UDP ports.
It has been suggested that having the recipient choose an arbitrary It has been suggested that having the recipient choose an arbitrary
source port (as opposed to using the destination port in the packet source port (as opposed to using the destination port in the packet
initiating the control connection, i.e., 1701) may make it more initiating the control connection, i.e., 1701) may make it more
difficult for L2TP to traverse some NAT devices. Implementations difficult for L2TP to traverse some NAT devices. Implementations
should consider the potential implication of this capability before should consider the potential implication of this capability before
choosing an arbitrary source port. A NAT device that can pass TFTP choosing an arbitrary source port. A NAT device that can pass TFTP
traffic with variant UDP ports should be able to pass L2TP UDP traffic with variant UDP ports should be able to pass L2TP UDP
traffic since both protocols employ similar policies with regard to traffic since both protocols employ similar policies with regard to
UDP port selection. UDP port selection.
4.1.2.3 UDP Checksum 4.1.2.3 UDP Checksum
UDP checksums MUST be enabled for control messages and MAY be enabled UDP checksums MUST be enabled for control messages and MAY be enabled
for data messages. It should be noted that enabling checksums on for data messages. It should be noted that enabling checksums on
data packets may significantly increase the data packet processing data packets may significantly increase the data packet processing
burden. burden.
4.1.3 IP Fragmentation Issues 4.1.3 IP Fragmentation Issues
IP fragmentation may occur as the L2TP packet travels over the IP IP fragmentation may occur as the L2TP packet travels over the IP
substrate. L2TP makes no special efforts defined in this document to substrate. L2TP makes no special efforts defined in this document to
optimize this. optimize this.
4.2 Reliable Delivery of Control Messages 4.2 Reliable Delivery of Control Messages
L2TP provides a lower level reliable delivery service for all control L2TP provides a lower level reliable delivery service for all control
messages. The Nr and Ns fields of the control message header (see messages. The Nr and Ns fields of the control message header (see
Section 3.2.1) belong to this delivery mechanism. The upper level Section 3.2.1) belong to this delivery mechanism. The upper level
functions of L2TP are not concerned with retransmission or ordering functions of L2TP are not concerned with retransmission or ordering
of control messages. The reliable control messaging mechanism is a of control messages. The reliable control messaging mechanism is a
sliding window mechanism that provides control message retransmission sliding window mechanism that provides control message retransmission
and congestion control. Each peer maintains separate sequence number and congestion control. Each peer maintains separate sequence number
state for each control connection. state for each control connection.
The message sequence number, Ns, begins at 0. Each subsequent The message sequence number, Ns, begins at 0. Each subsequent
message is sent with the next increment of the sequence number. The message is sent with the next increment of the sequence number. The
sequence number is thus a free-running counter represented modulo sequence number is thus a free-running counter represented modulo
65536. The sequence number in the header of a received message is 65536. The sequence number in the header of a received message is
considered less than or equal to the last received number if its considered less than or equal to the last received number if its
value lies in the range of the last received number and the preceding value lies in the range of the last received number and the preceding
32767 values, inclusive. For example, if the last received sequence 32767 values, inclusive. For example, if the last received sequence
number was 15, then messages with sequence numbers 0 through 15, as number was 15, then messages with sequence numbers 0 through 15, as
well as 32784 through 65535, would be considered less than or equal. well as 32784 through 65535, would be considered less than or equal.
Such a message would be considered a duplicate of a message already Such a message would be considered a duplicate of a message already
received and ignored from processing. However, in order to ensure received and ignored from processing. However, in order to ensure
that all messages are acknowledged properly (particularly in the case that all messages are acknowledged properly (particularly in the case
of a lost ACK message), receipt of duplicate messages MUST be of a lost ACK message), receipt of duplicate messages MUST be
acknowledged by the reliable delivery mechanism. This acknowledgment acknowledged by the reliable delivery mechanism. This acknowledgment
may either piggybacked on a message in queue or sent explicitly via may either piggybacked on a message in queue or sent explicitly via
an ACK message. an ACK message.
All control messages take up one slot in the control message sequence All control messages take up one slot in the control message sequence
number space, except the ACK message. Thus, Ns is not incremented number space, except the ACK message. Thus, Ns is not incremented
after an ACK message is sent. after an ACK message is sent.
The last received message number, Nr, is used to acknowledge messages The last received message number, Nr, is used to acknowledge messages
received by an L2TP peer. It contains the sequence number of the received by an L2TP peer. It contains the sequence number of the
message the peer expects to receive next (e.g. the last Ns of a non- message the peer expects to receive next (e.g. the last Ns of a non-
ACK message received plus 1, modulo 65536). While the Nr in a ACK message received plus 1, modulo 65536). While the Nr in a
received ACK message is used to flush messages from the local received ACK message is used to flush messages from the local
retransmit queue (see below), the Nr of the next message sent is not retransmit queue (see below), the Nr of the next message sent is not
updated by the Ns of the ACK message. Nr SHOULD be sanity-checked updated by the Ns of the ACK message. Nr SHOULD be sanity-checked
before flushing the retransmit queue. For instance, if the Nr before flushing the retransmit queue. For instance, if the Nr
received in a control message is greater than the last Ns sent plus 1 received in a control message is greater than the last Ns sent plus 1
modulo 65536, the control message is clearly invalid. modulo 65536, the control message is clearly invalid.
The reliable delivery mechanism at a receiving peer is responsible The reliable delivery mechanism at a receiving peer is responsible
for making sure that control messages are delivered in order and for making sure that control messages are delivered in order and
without duplication to the upper level. Messages arriving out of without duplication to the upper level. Messages arriving out of
order may be queued for in-order delivery when the missing messages order may be queued for in-order delivery when the missing messages
are received. Alternatively, they may be discarded, thus requiring a are received. Alternatively, they may be discarded, thus requiring a
retransmission by the peer. When dropping out of order control retransmission by the peer. When dropping out of order control
packets, Nr MAY be updated before the packet is discarded. packets, Nr MAY be updated before the packet is discarded.
Each control connection maintains a queue of control messages to be Each control connection maintains a queue of control messages to be
transmitted to its peer. The message at the front of the queue is transmitted to its peer. The message at the front of the queue is
sent with a given Ns value and is held until a control message sent with a given Ns value and is held until a control message
arrives from the peer in which the Nr field indicates receipt of this arrives from the peer in which the Nr field indicates receipt of this
message. After a period of time (a recommended default is 1 second message. After a period of time (a recommended default is 1 second
but SHOULD be configurable) passes without acknowledgment, the but SHOULD be configurable) passes without acknowledgment, the
message is retransmitted. The retransmitted message contains the message is retransmitted. The retransmitted message contains the
same Ns value, but the Nr value MUST be updated with the sequence same Ns value, but the Nr value MUST be updated with the sequence
number of the next expected message. number of the next expected message.
Each subsequent retransmission of a message MUST employ an Each subsequent retransmission of a message MUST employ an
exponential backoff interval. Thus, if the first retransmission exponential backoff interval. Thus, if the first retransmission
occurred after 1 second, the next retransmission should occur after 2 occurred after 1 second, the next retransmission should occur after 2
seconds has elapsed, then 4 seconds, etc. An implementation MAY seconds has elapsed, then 4 seconds, etc. An implementation MAY
place a cap upon the maximum interval between retransmissions. This place a cap upon the maximum interval between retransmissions. This
cap SHOULD be no less than 8 seconds per retransmission. If no peer cap SHOULD be no less than 8 seconds per retransmission. If no peer
response is detected after several retransmissions (a recommended response is detected after several retransmissions (a recommended
default is 10, but MUST be configurable), the control connection and default is 10, but MUST be configurable), the control connection and
all associated sessions MUST be cleared. As it is the first message all associated sessions MUST be cleared. As it is the first message
to establish a control connection, the SCCRQ MAY employ a different to establish a control connection, the SCCRQ MAY employ a different
retransmission maximum than other control messages in order to help retransmission maximum than other control messages in order to help
facilitate failover to alternate LCCEs in a timely fashion. facilitate failover to alternate LCCEs in a timely fashion.
When a control connection is being shut down for reasons other than When a control connection is being shut down for reasons other than
loss of connectivity, the state and reliable delivery mechanisms MUST loss of connectivity, the state and reliable delivery mechanisms MUST
be maintained and operated for the full retransmission interval after be maintained and operated for the full retransmission interval after
the final message StopCCN message has been sent (e.g. 1 + 2 + 4 + 8 + the final message StopCCN message has been sent (e.g. 1 + 2 + 4 + 8 +
8... seconds), or until the StopCCN message itself has been 8... seconds), or until the StopCCN message itself has been
acknowledged. acknowledged.
A sliding window mechanism is used for control message transmission A sliding window mechanism is used for control message transmission
and retransmission. Consider two peers, A and B. Suppose A and retransmission. Consider two peers, A and B. Suppose A
specifies a Receive Window Size AVP with a value of N in the SCCRQ or specifies a Receive Window Size AVP with a value of N in the SCCRQ or
SCCRP message. B is now allowed to have a maximum of N outstanding SCCRP message. B is now allowed to have a maximum of N outstanding
(e.g. unacknowledged) control messages. Once N messages have been (e.g. unacknowledged) control messages. Once N messages have been
sent, B must wait for an acknowledgment from A that advances the sent, B must wait for an acknowledgment from A that advances the
window before sending new control messages. An implementation may window before sending new control messages. An implementation may
advertise a non-zero receive window as small or as large as it advertise a non-zero receive window as small or as large as it
wishes, depending on its own ability to process incoming messages wishes, depending on its own ability to process incoming messages
before sending an acknowledgement. Each peer MUST limit the number of before sending an acknowledgement. Each peer MUST limit the number of
unacknowledged messages it will send before receiving an unacknowledged messages it will send before receiving an
acknowledgement by this Receive Window Size. The actual internal acknowledgement by this Receive Window Size. The actual internal
unacknowledged message send-queue depth may be further limited by unacknowledged message send-queue depth may be further limited by
local resource allocation or by dynamic slow-start and congestion- local resource allocation or by dynamic slow-start and congestion-
avoidance mechanisms. avoidance mechanisms.
When retransmitting control messages, a slow start and congestion When retransmitting control messages, a slow start and congestion
avoidance window adjustment procedure SHOULD be utilized. A avoidance window adjustment procedure SHOULD be utilized. A
recommended procedure is described in Appendix A. A peer MAY drop recommended procedure is described in Appendix A. A peer MAY drop
messages, but MUST NOT actively delay acknowledgment of messages as a messages, but MUST NOT actively delay acknowledgment of messages as a
technique for flow control of control messages. Appendix B contains technique for flow control of control messages. Appendix B contains
examples of control message transmission, acknowledgment, and examples of control message transmission, acknowledgment, and
retransmission. retransmission.
4.3 Control Connection and Control Message Authentication 4.3 Control Connection and Control Message Authentication
L2TP incorporates an optional authentication and integrity check for L2TP incorporates an optional authentication and integrity check for
all control messages. This mechanism consists of a computed one-way all control messages. This mechanism consists of a computed one-way
hash over the header and body of the L2TP control message, a pre- hash over the header and body of the L2TP control message, a pre-
configured shared secret, and a local and remote nonce (random value) configured shared secret, and a local and remote nonce (random value)
exchanged via the Nonce AVP. This per-message authentication and exchanged via the Nonce AVP. This per-message authentication and
integrity check is designed to perform a mutual authentication integrity check is designed to perform a mutual authentication
between L2TP nodes, integrity checking of all control messages, and between L2TP nodes, integrity checking of all control messages, and
guard against control message spoofing and replay attacks that would guard against control message spoofing and replay attacks that would
otherwise be trivial to mount. otherwise be trivial to mount.
A shared secret (password) MUST exist between communicating L2TP A shared secret (password) MUST exist between communicating L2TP
nodes to obtain the benefit of message or peer authentication. If a nodes to enable the authentication mode. See Section 5.4.3 for
shared secret is not configured on either node, the per-message details on calculation of the Message Digest and construction of the
integrity check may still be performed using an empty shared secret Nonce and Message Digest AVPs.
of zero length. See Section 5.4.3 for details on calculation of the
Message Digest and construction of the Nonce and Message Digest AVPs.
L2TPv3 Control Connection and Control Message Authentication is L2TPv3 Control Connection and Control Message Authentication is
similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a
shared secret for peer authentication, use of a one-way hash shared secret for peer authentication, use of a one-way hash
calculation, and exchange of a random value. The principal difference calculation, and exchange of a random value. The principal difference
is that, instead of computing the hash over selected contents of a is that, instead of computing the hash over selected contents of a
received control message (e.g. the Challenge AVP and Message Type) as received control message (e.g. the Challenge AVP and Message Type) as
in L2TPv2, the entire message is used in the hash in L2TPv3. In in L2TPv2, the entire message is used in the hash in L2TPv3. In
addition, instead of including the hash digest in just the SCCRP and addition, instead of including the hash digest in just the SCCRP and
SCCCN messages, it is now included in all L2TP messages. SCCCN messages, it is now included in all L2TP messages.
The Control Message Authentication mechanism is optional, and may be The Control Message Authentication mechanism is optional, and may be
disabled if both peers agree. For example, if IPsec is already being disabled if both peers agree. For example, if IPsec is already being
used for security and integrity checking between the LCCEs, the L2TP used for security and integrity checking between the LCCEs, the
mechanism defined here becomes redundant and may be disabled. function of the L2TP mechanism becomes redundant and may be disabled.
Presence of the Message Digest AVP in an SCCRQ or SCCRP message
serves as the indication to a peer that Control Message Presence of the Control Message Authentication Nonce AVP in an SCCRQ
Authentication is enabled. If an SCCRQ or SCCRP contains a Message or SCCRP message serves as indication to a peer that Control Message
Digest AVP, the receiver of the message MUST respond with a Message Authentication is enabled. If an SCCRQ or SCCRP contains a Control
Digest AVP in all subsequent messages sent. If an SCCRQ or SCCRP is Message Authentication Nonce AVP, the receiver of the message MUST
received with a missing or incorrect Message Digest AVP value, a respond with a Message Digest AVP in all subsequent messages sent.
StopCCN MAY be sent with the Result Code set to 4 (see Section Control Connection and Control Message Authentication is always
5.4.2). Care should be taken to rate-limit such responses as to not bidirectional, either both sides participate in authentication or
end up in a denial of service situation responding to rogue SCCRQ or neither do.
SCCRP control messages. All other control messages with missing or
incorrect Message Digest AVPs MUST be dropped. If the Control Message Authentication is disabled, the Message Digest
AVP still MAY be sent containing an integrity check of the message.
The integrity check is calculated as in Section 5.4.3, with an empty
and zero length shared secret, local nonce, and remote nonce. If a
erroneous Message Digest AVP is received, it should be assumed that a
bit error has occurred and the control message dropped.
Implementations MAY rate-limit control messages, particularly SCCRQ
messages, upon receipt for performance reasons or to protect against
denial of service attacks.
4.4 Keepalive (Hello) 4.4 Keepalive (Hello)
A keepalive mechanism is employed by L2TP to detect loss of A keepalive mechanism is employed by L2TP to detect loss of
connectivity between a pair of LCCEs. This is accomplished by connectivity between a pair of LCCEs. This is accomplished by
injecting Hello control messages (see Section 6.5) after a period of injecting Hello control messages (see Section 6.5) after a period of
time has elapsed since the last data message or control message was time has elapsed since the last data message or control message was
received on an L2TP session or control connection, respectively. As received on an L2TP session or control connection, respectively. As
with any other control message, if the Hello message is not reliably with any other control message, if the Hello message is not reliably
delivered, the sending LCCE declares that the control connection is delivered, the sending LCCE declares that the control connection is
down and resets its state for the control connection. This behavior down and resets its state for the control connection. This behavior
ensures that a connectivity failure between the LCCEs is detected ensures that a connectivity failure between the LCCEs is detected
independently by each end of a control connection. independently by each end of a control connection.
Since the control channel is operated in-band with data traffic over Since the control channel is operated in-band with data traffic over
the PSN, this single mechanism can be used to infer basic data the PSN, this single mechanism can be used to infer basic data
connectivity between a pair of LCCEs for all sessions associated with connectivity between a pair of LCCEs for all sessions associated with
the control connection. the control connection.
Periodic keepalive for the control connection MUST be implemented by Periodic keepalive for the control connection MUST be implemented by
sending a Hello if a period of time (a recommended default is 60 sending a Hello if a period of time (a recommended default is 60
seconds, but MUST be configurable) has passed without receiving any seconds, but MUST be configurable) has passed without receiving any
message (data or control) from the peer. An LCCE sending Hello message (data or control) from the peer. An LCCE sending Hello
messages across multiple control connections between the same LCCE messages across multiple control connections between the same LCCE
endpoints MUST employ a jittered timer mechanism to prevent grouping endpoints MUST employ a jittered timer mechanism to prevent grouping
of Hello messages. of Hello messages.
4.5 Forwarding Session Data Frames 4.5 Forwarding Session Data Frames
Once session establishment is complete, circuit frames are received Once session establishment is complete, circuit frames are received
at an LCCE, encapsulated in L2TP (with appropriate attention to at an LCCE, encapsulated in L2TP (with appropriate attention to
framing as described in documents for the particular pseudowire framing as described in documents for the particular pseudowire
type), and forwarded over the appropriate session. For every type), and forwarded over the appropriate session. For every
outgoing data message, the sender places the identifier specified in outgoing data message, the sender places the identifier specified in
the Local Session ID AVP (received from peer during session the Local Session ID AVP (received from peer during session
establishment) in the Session ID field of the L2TP data header. In establishment) in the Session ID field of the L2TP data header. In
this manner, session frames are multiplexed and demultiplexed between this manner, session frames are multiplexed and demultiplexed between
a given pair of LCCEs. Multiple control connections may exist a given pair of LCCEs. Multiple control connections may exist
between a given pair of LCCEs, and multiple sessions may be between a given pair of LCCEs, and multiple sessions may be
associated with a given control connection. associated with a given control connection.
The peer LCCE receiving the L2TP data packet identifies the session The peer LCCE receiving the L2TP data packet identifies the session
with which the packet is associated by the Session ID in the data with which the packet is associated by the Session ID in the data
packet's header. The LCCE then checks the Cookie field in the data packet's header. The LCCE then checks the Cookie field in the data
packet against the Cookie value received in the Assigned Cookie AVP packet against the Cookie value received in the Assigned Cookie AVP
during session establishment. It is important for implementers to during session establishment. It is important for implementers to
note that the Cookie field check occurs after looking up the session note that the Cookie field check occurs after looking up the session
context by the Session ID, and as such consists merely of a value context by the Session ID, and as such consists merely of a value
match of the Cookie field and that stored in the retrieved context. match of the Cookie field and that stored in the retrieved context.
There is no need to perform a lookup across the Session ID and Cookie There is no need to perform a lookup across the Session ID and Cookie
as a single value. Any received data packets that contain invalid as a single value. Any received data packets that contain invalid
Session IDs or associated Cookie values MUST be dropped. Finally, Session IDs or associated Cookie values MUST be dropped. Finally,
the LCCE either forwards the network packet within the tunneled frame the LCCE either forwards the network packet within the tunneled frame
(e.g., as an LNS) or switches the frame to a circuit (e.g., as an (e.g., as an LNS) or switches the frame to a circuit (e.g., as an
LAC). LAC).
4.6 Default L2-Specific Sublayer 4.6 Default L2-Specific Sublayer
This document defines a default L2-Specific Sublayer (see Section This document defines a default L2-Specific Sublayer (see Section
3.2.2) format that a pseudowire may use for features such as basic 3.2.2) format that a pseudowire may use for features such as
sequencing support, marking of packets with a single high-priority sequencing support, L2 interworking, OAM, or other per-data-packet
bit, or other general per-data-packet control operations. The operations. The default L2-Specific Sublayer SHOULD be used by a
default L2-Specific Sublayer SHOULD be used by a given PW type to given PW type to support these features if it is adequate, and its
support these features if it is adequate, and its presence is presence is requested by a peer during session negotiation.
requested by a peer during session negotiation. Alternative Alternative sublayers MAY be defined (e.g. an encapsulation with a
sublayers MAY be defined (e.g. an encapsulation with a larger larger Sequence Number field or timing information) and identified
Sequence Number field or timing information) and identified for use for use via the L2-Specific Sublayer Type AVP.
via the L2-Specific Sublayer Type AVP.
Figure 4.6: Default L2-Specific Sublayer Format
0 1 2 3 Figure 4.6: Default L2-Specific Sublayer Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The P (Priority) bit is used to identify a data packet that should be 0 1 2 3
dropped only as a last resort after being received by an L2TP peer. 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
This bit should be set to 1 for any traffic that should be given +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
higher priority than other data traffic in a congested environment. |x|S|x|x|x|x|x|x| Sequence Number |
For example, end-to-end L2 keepalive packets (e.g. PPP keepalives) or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
other control packets vital to the life of the circuit or network may
need special handling by an LCCE upon receipt. This is not a
replacement for, or to be used as, a per-hop QoS method of any sort.
It is only to be used by the L2TP receiving node to prioritize
incoming traffic.
The S (Sequence) bit is set to 1 when the Sequence Number contains a The S (Sequence) bit is set to 1 when the Sequence Number contains a
valid number for this sequenced frame. If the S bit is set to zero, valid number for this sequenced frame. If the S bit is set to zero,
the Sequence Number contents are undefined and MUST be ignored by the the Sequence Number contents are undefined and MUST be ignored by the
receiver. receiver.
The Sequence Number field contains a free-running counter of 2^24 The Sequence Number field contains a free-running counter of 2^24
sequence numbers. If the number in this field is valid, the S bit sequence numbers. If the number in this field is valid, the S bit
MUST be set to 1. The Sequence Number begins at zero, which is a MUST be set to 1. The Sequence Number begins at zero, which is a
valid sequence number. (In this way, implementations inserting valid sequence number. (In this way, implementations inserting
sequence numbers do not have to "skip" zero when incrementing.) The sequence numbers do not have to "skip" zero when incrementing.) The
sequence number in the header of a received message is considered sequence number in the header of a received message is considered
less than or equal to the last received number if its value lies in less than or equal to the last received number if its value lies in
the range of the last received number and the preceding (2^23-1) the range of the last received number and the preceding (2^23-1)
values, inclusive. values, inclusive.
4.6.1 Sequencing Data Packets 4.6.1 Sequencing Data Packets
The Sequence Number field may be used to detect lost, duplicate, or The Sequence Number field may be used to detect lost, duplicate, or
out-of-order packets within a given session. out-of-order packets within a given session.
When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
data channel, this part of the link has the characteristic of being data channel, this part of the link has the characteristic of being
able to reorder, duplicate, or silently drop packets. Reordering may able to reorder, duplicate, or silently drop packets. Reordering may
break some non-IP protocols or L2 control traffic being carried by break some non-IP protocols or L2 control traffic being carried by
the link. Silent dropping or duplication of packets may break the link. Silent dropping or duplication of packets may break
protocols that assume per-packet indications of error, such as TCP protocols that assume per-packet indications of error, such as TCP
header compression. While a common mechanism for packet sequence header compression. While a common mechanism for packet sequence
detection is provided, the sequence dependency characteristics of detection is provided, the sequence dependency characteristics of
individual protocols are outside the scope of this document. individual protocols are outside the scope of this document.
If any protocol being transported by over L2TP data channels cannot If any protocol being transported by over L2TP data channels cannot
tolerate misordering of data packets, packet duplication, or silent tolerate misordering of data packets, packet duplication, or silent
packet loss, sequencing may be enabled on some or all packets by packet loss, sequencing may be enabled on some or all packets by
using the S bit and Sequence Number field defined in the default using the S bit and Sequence Number field defined in the default L2-
L2-Specific Sublayer(see Section 4.6). For a given L2TP session, Specific Sublayer(see Section 4.6). For a given L2TP session, each
each LCCE is responsible for communicating to its peer the level of LCCE is responsible for communicating to its peer the level of
sequencing support that it requires of data packets that it receives. sequencing support that it requires of data packets that it receives.
Mechanisms to advertise this information during session negotiation Mechanisms to advertise this information during session negotiation
are provided (see Data Sequencing AVP in Section 5.4.4). are provided (see Data Sequencing AVP in Section 5.4.4).
When determining whether a packet is in or out of sequence, an When determining whether a packet is in or out of sequence, an
implementation SHOULD utilize a method that is resilient to temporary implementation SHOULD utilize a method that is resilient to temporary
dropouts in connectivity coupled with high per-session packet rates. dropouts in connectivity coupled with high per-session packet rates.
The recommended method is outlined in Appendix C. The recommended method is outlined in Appendix C.
4.7 L2TPv2/v3 Interoperability and Migration 4.7 L2TPv2/v3 Interoperability and Migration
L2TPv2 and L2TPv3 environments should be able to coexist while a L2TPv2 and L2TPv3 environments should be able to coexist while a
migration to L2TPv3 is made. Migration issues are discussed for each migration to L2TPv3 is made. Migration issues are discussed for each
media type in this section. Most issues apply only to media type in this section. Most issues apply only to
implementations that require both L2TPv2 and L2TPv3 operation. implementations that require both L2TPv2 and L2TPv3 operation.
However, even L2TPv3-only implementations must at least be mindful of However, even L2TPv3-only implementations must at least be mindful of
these issues in order to interoperate with implementations that these issues in order to interoperate with implementations that
support both versions. support both versions.
4.7.1 L2TPv3 over IP 4.7.1 L2TPv3 over IP
L2TPv3 implementations running strictly over IP with no desire to L2TPv3 implementations running strictly over IP with no desire to
interoperate with L2TPv2 implementations may safely disregard most interoperate with L2TPv2 implementations may safely disregard most
migration issues from L2TPv2. All control messages and data messages migration issues from L2TPv2. All control messages and data messages
are sent as described in this document, without normative reference are sent as described in this document, without normative reference
to RFC2661. to RFC2661.
If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only
if it is not available, then L2TPv3 over UDP with the automatic if it is not available, then L2TPv3 over UDP with the automatic
fallback as described in section 4.7.3 MUST be used. There is no fallback as described in section 4.7.3 MUST be used. There is no
deterministic method for automatic fallback from L2TPv3 over IP to deterministic method for automatic fallback from L2TPv3 over IP to
either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over
IP is supported by sending an SCCRQ and waiting for a response, but IP is supported by sending an SCCRQ and waiting for a response, but
this could be problematic during periods of packet loss between L2TP this could be problematic during periods of packet loss between L2TP
nodes. nodes.
4.7.2 L2TPv3 over UDP 4.7.2 L2TPv3 over UDP
The format of the L2TPv3 over UDP header is defined in Section The format of the L2TPv3 over UDP header is defined in Section
4.1.2.1. 4.1.2.1.
When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2
and shares the first two octets of header format with L2TPv2. The Ver and shares the first two octets of header format with L2TPv2. The Ver
field is used to distinguish L2TPv2 packets from L2TPv3 packets. If field is used to distinguish L2TPv2 packets from L2TPv3 packets. If
an implementation is capable of operating in L2TPv2 or L2TPv3 modes, an implementation is capable of operating in L2TPv2 or L2TPv3 modes,
it is possible to automatically detect whether a peer can support it is possible to automatically detect whether a peer can support
L2TPv2 or L2TPv3 and operate accordingly. The details of this L2TPv2 or L2TPv3 and operate accordingly. The details of this
fallback capability is defined in the following section. fallback capability is defined in the following section.
4.7.3 Automatic L2TPv2 Fallback 4.7.3 Automatic L2TPv2 Fallback
When running over UDP, an implementation may detect whether a peer is When running over UDP, an implementation may detect whether a peer is
L2TPv3-capable by sending a special SCCRQ that is properly formatted L2TPv3-capable by sending a special SCCRQ that is properly formatted
for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ
with its Ver field set to 2 (for L2TPv2), and ensuring that any with its Ver field set to 2 (for L2TPv2), and ensuring that any
L2TPv3-specific AVPs (i.e. AVPs present within this document and not L2TPv3-specific AVPs (i.e. AVPs present within this document and not
defined within RFC 2661) within the message are sent with each M bit defined within RFC 2661) within the message are sent with each M bit
set to 0, and all L2TPv2 AVPs present as they would be for L2TPv2. set to 0, and all L2TPv2 AVPs present as they would be for L2TPv2.
This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only
implementation. Note that, in both L2TPv2 and L2TPv3, the value implementation. Note that, in both L2TPv2 and L2TPv3, the value
contained in the space of the control message header utilized by the contained in the space of the control message header utilized by the
32-bit Control Connection ID in L2TPv3, and the 16-bit Tunnel ID and 32-bit Control Connection ID in L2TPv3, and the 16-bit Tunnel ID and
16-bit Session ID in L2TPv2, is always 0 for an SCCRQ. This 16-bit Session ID in L2TPv2, is always 0 for an SCCRQ. This
effectively hides the fact that there are a pair of 16-bit fields in effectively hides the fact that there are a pair of 16-bit fields in
L2TPv2, and a single 32-bit field in L2TPv3. L2TPv2, and a single 32-bit field in L2TPv3.
If the peer implementation is L2TPv3-capable, a control message with If the peer implementation is L2TPv3-capable, a control message with
Ver set to 3 and corresponding header and message format will be sent Ver set to 3 and corresponding header and message format will be sent
in response to the SCCRQ. Operation may then continue as L2TPv3. If in response to the SCCRQ. Operation may then continue as L2TPv3. If
a message is received with Ver set to 2, it must be assumed that the a message is received with Ver set to 2, it must be assumed that the
peer implementation is L2TPv2-only and fallback to L2TPv2 mode may peer implementation is L2TPv2-only and fallback to L2TPv2 mode may
safely occur. safely occur.
Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3
implementations over UDP be liberal in acceptance of an SCCRQ control implementations over UDP be liberal in acceptance of an SCCRQ control
message with the Ver field set to 2 or 3 and the presence of message with the Ver field set to 2 or 3 and the presence of L2TPv2-
L2TPv2-specific AVPs. An L2TPv3-only implementation MUST ignore all specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2
L2TPv2 AVPs (e.g. those defined in RFC 2661 and not in this document) AVPs (e.g. those defined in RFC 2661 and not in this document) within
within an SCCRQ with the Ver field set to 2 (even if the M bit is set an SCCRQ with the Ver field set to 2 (even if the M bit is set on the
on the L2TPv2-specific AVPs). L2TPv2-specific AVPs).
5. Control Message Attribute Value Pairs 5. Control Message Attribute Value Pairs
To maximize extensibility while permitting interoperability, a To maximize extensibility while permitting interoperability, a
uniform method for encoding message types is used throughout L2TP. uniform method for encoding message types is used throughout L2TP.
This encoding will be termed AVP (Attribute Value Pair) for the This encoding will be termed AVP (Attribute Value Pair) for the
remainder of this document. remainder of this document.
5.1 AVP Format 5.1 AVP Format
Each AVP is encoded as follows: Each AVP is encoded as follows:
Figure 5.1: AVP Format Figure 5.1: AVP Format
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID | |M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value ... | Attribute Type | Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) | (until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits comprise a bit mask that describes the general The first six bits comprise a bit mask that describes the general
attributes of the AVP. Two bits are defined in this document; the attributes of the AVP. Two bits are defined in this document; the
remaining bits are reserved for future extensions. Reserved bits remaining bits are reserved for future extensions. Reserved bits
MUST be set to 0. An AVP received with a reserved bit set to 1 MUST MUST be set to 0. An AVP received with a reserved bit set to 1 MUST
be treated as an unrecognized AVP. be treated as an unrecognized AVP.
Mandatory (M) bit: Controls the behavior required of an Mandatory (M) bit: Controls the behavior required of an
implementation that receives an unrecognized AVP. The M bit of a implementation that receives an unrecognized AVP. The M bit of a
given AVP MUST only be inspected and acted upon if the AVP is given AVP MUST only be inspected and acted upon if the AVP is
unrecognized (see Section 5.2). unrecognized (see Section 5.2).
Hidden (H) bit: Identifies the hiding of data in the Attribute Value Hidden (H) bit: Identifies the hiding of data in the Attribute Value
field of an AVP. This capability can be used to avoid the passing of field of an AVP. This capability can be used to avoid the passing of
sensitive data, such as user passwords, as cleartext in an AVP. sensitive data, such as user passwords, as cleartext in an AVP.
Section 5.3 describes the procedure for performing AVP hiding. Section 5.3 describes the procedure for performing AVP hiding.
Length: Contains the number of octets (including the Overall Length Length: Contains the number of octets (including the Overall Length
and bit mask fields) contained in this AVP. The Length may be and bit mask fields) contained in this AVP. The Length may be
calculated as 6 + the length of the Attribute Value field in octets. calculated as 6 + the length of the Attribute Value field in octets.
The field itself is 10 bits, permitting a maximum of 1023 octets of The field itself is 10 bits, permitting a maximum of 1023 octets of
data in a single AVP. The minimum Length of an AVP is 6. If the data in a single AVP. The minimum Length of an AVP is 6. If the
Length is 6, then the Attribute Value field is absent. Length is 6, then the Attribute Value field is absent.
Vendor ID: The IANA assigned "SMI Network Management Private Vendor ID: The IANA assigned "SMI Network Management Private
Enterprise Codes" [RFC1700] value. The value 0, corresponding to Enterprise Codes" [RFC1700] value. The value 0, corresponding to
IETF adopted attribute values, is used for all AVPs defined within IETF adopted attribute values, is used for all AVPs defined within
this document. Any vendor wishing to implement its own L2TP this document. Any vendor wishing to implement its own L2TP
extensions can use its own Vendor ID along with private Attribute extensions can use its own Vendor ID along with private Attribute
values, guaranteeing that they will not collide with any other values, guaranteeing that they will not collide with any other
vendor's extensions or future IETF extensions. Note that there are vendor's extensions or future IETF extensions. Note that there are
16 bits allocated for the Vendor ID, thus limiting this feature to 16 bits allocated for the Vendor ID, thus limiting this feature to
the first 65,535 enterprises. the first 65,535 enterprises.
Attribute Type: A 2-octet value with a unique interpretation across Attribute Type: A 2-octet value with a unique interpretation across
all AVPs defined under a given Vendor ID. all AVPs defined under a given Vendor ID.
Attribute Value: This is the actual value as indicated by the Vendor Attribute Value: This is the actual value as indicated by the Vendor
ID and Attribute Type. It follows immediately after the Attribute ID and Attribute Type. It follows immediately after the Attribute
Type field and runs for the remaining octets indicated in the Length Type field and runs for the remaining octets indicated in the Length
(i.e., Length minus 6 octets of header). This field is absent if the (i.e., Length minus 6 octets of header). This field is absent if the
Length is 6. Length is 6.
5.2 Mandatory AVPs and Setting the M Bit 5.2 Mandatory AVPs and Setting the M Bit
If the M bit is set on an AVP that is unrecognized by its recipient, If the M bit is set on an AVP that is unrecognized by its recipient,
the session or control connection associated with the contorl message the session or control connection associated with the contorl message
containing the AVP MUST be shutdown. If the control message containing the AVP MUST be shutdown. If the control message
containing the unrecognized AVP is associated with a session (e.g. an containing the unrecognized AVP is associated with a session (e.g. an
ICRQ, ICRP, ICCN, SLI, etc.) then the session MUST be issued a CDN ICRQ, ICRP, ICCN, SLI, etc.) then the session MUST be issued a CDN
with a Result Code of 2 and Error Code of 8 as defined in section with a Result Code of 2 and Error Code of 8 as defined in section
5.4.2. and shutdown. If the control message containing the 5.4.2. and shutdown. If the control message containing the
unrecognized AVP is associated with establishment or maintenance of a unrecognized AVP is associated with establishment or maintenance of a
Control Connection (e.g. SCCRQ, SCCRP, SCCCN, Hello) then the Control Connection (e.g. SCCRQ, SCCRP, SCCCN, Hello) then the
associated Control Connection MUST be issued a StopCCN with Result associated Control Connection MUST be issued a StopCCN with Result
Code of 2 and Error Code of 8 as defined in section 5.4.2. and Code of 2 and Error Code of 8 as defined in section 5.4.2. and
shutdown. If the M bit is not set on an unrecognized AVP, the AVP shutdown. If the M bit is not set on an unrecognized AVP, the AVP
MUST be ignored when received, processing the control message as if MUST be ignored when received, processing the control message as if
the AVP was not present. the AVP was not present.
Receipt of an unrecognized AVP that has the M bit set is catastrophic Receipt of an unrecognized AVP that has the M bit set is catastrophic
to the session or control connection with which it is associated. to the session or control connection with which it is associated.
Thus, the M bit should only be set for AVPs that are deemed crucial Thus, the M bit should only be set for AVPs that are deemed crucial
to proper operation of the session or control connection by the to proper operation of the session or control connection by the
sender. AVPs that are considered crucial by the sender may vary by sender. AVPs that are considered crucial by the sender may vary by
application and configured options. In no case shall a receiver of application and configured options. In no case shall a receiver of
an AVP "validate" if the M bit is set on a recognized AVP. If the AVP an AVP "validate" if the M bit is set on a recognized AVP. If the AVP
is recognized (as all AVPs defined in this document MUST be for a is recognized (as all AVPs defined in this document MUST be for a
compliant L2TPv3 specification), then by definition the M bit is of compliant L2TPv3 specification), then by definition the M bit is of
no consequence. no consequence.
The sender of an AVP is free to set its M bit to 1 or 0 based on The sender of an AVP is free to set its M bit to 1 or 0 based on
whether the configured application strictly requires the value whether the configured application strictly requires the value
contained in the AVP to be recognized or not. For example, "Automatic contained in the AVP to be recognized or not. For example, "Automatic
L2TPv2 Fallback" (Section 4.7.3), requires the setting of the M bit L2TPv2 Fallback" (Section 4.7.3), requires the setting of the M bit
on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and
desired, and 1 if not. desired, and 1 if not.
The M bit is useful as extra assurance for support of critical AVP The M bit is useful as extra assurance for support of critical AVP
extensions. However, more explicit methods may be available to extensions. However, more explicit methods may be available to
determine support for a given feature rather than using the M bit determine support for a given feature rather than using the M bit
alone. For example, if a new AVP is defined in a message for which alone. For example, if a new AVP is defined in a message for which
there is always a message reply (i.e. an ICRQ, ICRP, SCCRQ or SCCRP there is always a message reply (i.e. an ICRQ, ICRP, SCCRQ or SCCRP
message) rather than simply sending an AVP in the message with the M message) rather than simply sending an AVP in the message with the M
bit set, availability of the extension may be identified by sending bit set, availability of the extension may be identified by sending
an AVP in the request message and expecting a corresponding AVP in a an AVP in the request message and expecting a corresponding AVP in a
reply message. This more explicit method, when possible, is reply message. This more explicit method, when possible, is
preferred. preferred.
The M bit also plays a role in determining whether or not a malformed The M bit also plays a role in determining whether or not a malformed
or out-of-range value within an AVP should be ignored or result in or out-of-range value within an AVP should be ignored or result in
termination of a session or control channel. See Section 7.1 for more termination of a session or control channel. See Section 7.1 for more
details on this. details on this.
5.3 Hiding of AVP Attribute Values 5.3 Hiding of AVP Attribute Values
The H bit in the header of each AVP provides a mechanism to indicate The H bit in the header of each AVP provides a mechanism to indicate
to the receiving peer whether the contents of the AVP are hidden or to the receiving peer whether the contents of the AVP are hidden or
present in cleartext. This feature can be used to hide sensitive present in cleartext. This feature can be used to hide sensitive
control message data such as user passwords, IDs, or other vital control message data such as user passwords, IDs, or other vital
information. information.
The H bit MUST only be set if (1) a shared secret exists between the The H bit MUST only be set if (1) a shared secret exists between the
LCCEs and (2) Control Connection and Control Message Authentication LCCEs and (2) Control Connection and Control Message Authentication
is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a
given control message, a Random Vector AVP must also be present in given control message, a Random Vector AVP must also be present in
the message and MUST precede the first AVP having an H bit of 1. the message and MUST precede the first AVP having an H bit of 1.
The shared secret between LCCEs is used to derive a unique shared key The shared secret between LCCEs is used to derive a unique shared key
for hiding and unhiding calculations. The derived shared key is for hiding and unhiding calculations. The derived shared key is
obtained via a one-way HMAC-MD5 hash [RFC1321] on the shared secret obtained via a one-way HMAC-MD5 hash [RFC1321] on the shared secret
concatenated with a single octet containing the value 1. concatenated with a single octet containing the value 1.
shared_key = HMAC_MD5 (shared_secret | 1) shared_key = HMAC_MD5 (shared_secret | 1)
Hiding an AVP value is done in several steps. The first step is to Hiding an AVP value is done in several steps. The first step is to
take the length and value fields of the original (cleartext) AVP and take the length and value fields of the original (cleartext) AVP and
encode them into a Hidden AVP Subformat as follows: encode them into a Hidden AVP Subformat as follows:
Figure 5.3: Hidden AVP Subformat Figure 5.3: Hidden AVP Subformat
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ... | Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ... ... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value: This is length of the Original
Attribute Value to be obscured in octets. This is necessary to
determine the original length of the Attribute Value that is lost
when the additional Padding is added.
Original Attribute Value: Attribute Value that is to be obscured. Length of Original Attribute Value: This is length of the Original
Attribute Value to be obscured in octets. This is necessary to
determine the original length of the Attribute Value that is lost
when the additional Padding is added.
Padding: Random additional octets used to obscure length of the Original Attribute Value: Attribute Value that is to be obscured.
Attribute Value that is being hidden.
To mask the size of the data being hidden, the resulting subformat Padding: Random additional octets used to obscure length of the
MAY be padded as shown above. Padding does NOT alter the value Attribute Value that is being hidden.
placed in the Length of Original Attribute Value field, but does
alter the length of the resultant AVP that is being created. For
example, if an Attribute Value to be hidden is 4 octets in length,
the unhidden AVP length would be 10 octets (6 + Attribute Value
length). After hiding, the length of the AVP will become 6 +
Attribute Value length + size of the Length of Original Attribute
Value field + Padding. Thus, if Padding is 12 octets, the AVP length
will be 6 + 4 + 2 + 12 = 24 octets.
Next, an MD5 hash is performed (in network byte order) on the To mask the size of the data being hidden, the resulting subformat
concatenation of the following: MAY be padded as shown above. Padding does NOT alter the value
placed in the Length of Original Attribute Value field, but does
alter the length of the resultant AVP that is being created. For
example, if an Attribute Value to be hidden is 4 octets in length,
the unhidden AVP length would be 10 octets (6 + Attribute Value
length). After hiding, the length of the AVP will become 6 +
Attribute Value length + size of the Length of Original Attribute
Value field + Padding. Thus, if Padding is 12 octets, the AVP length
will be 6 + 4 + 2 + 12 = 24 octets.
+ the 2-octet Attribute number of the AVP Next, an MD5 hash is performed (in network byte order) on the
+ the shared key concatenation of the following:
+ an arbitrary length random vector
The value of the random vector used in this hash is passed in the + the 2-octet Attribute number of the AVP
value field of a Random Vector AVP. This Random Vector AVP must be + the shared key
placed in the message by the sender before any hidden AVPs. The same + an arbitrary length random vector
random vector may be used for more than one hidden AVP in the same
message. If a different random vector is used for the hiding of
subsequent AVPs, then a new Random Vector AVP must be placed in the
command message before the first AVP to which it applies.
The MD5 hash value is then XORed with the first 16-octet (or less) The value of the random vector used in this hash is passed in the
segment of the Hidden AVP Subformat and placed in the Attribute Value value field of a Random Vector AVP. This Random Vector AVP must be
field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 placed in the message by the sender before any hidden AVPs. The same
octets, the Subformat is transformed as if the Attribute Value field random vector may be used for more than one hidden AVP in the same
had been padded to 16 octets before the XOR. Only the actual octets message. If a different random vector is used for the hiding of
present in the Subformat are modified, and the length of the AVP is subsequent AVPs, then a new Random Vector AVP must be placed in the
not altered. command message before the first AVP to which it applies.
If the Subformat is longer than 16 octets, a second one-way MD5 hash The MD5 hash value is then XORed with the first 16-octet (or less)
is calculated over a stream of octets consisting of the shared key segment of the Hidden AVP Subformat and placed in the Attribute Value
followed by the result of the first XOR. That hash is XORed with the field of the Hidden AVP. If the Hidden AVP Subformat is less than 16
second 16-octet (or less) segment of the Subformat and placed in the octets, the Subformat is transformed as if the Attribute Value field
corresponding octets of the Value field of the Hidden AVP. had been padded to 16 octets before the XOR. Only the actual octets
present in the Subformat are modified, and the length of the AVP is
not altered.
If necessary, this operation is repeated, with the shared key used If the Subformat is longer than 16 octets, a second one-way MD5 hash
along with each XOR result to generate the next hash to XOR the next is calculated over a stream of octets consisting of the shared key
segment of the value with. followed by the result of the first XOR. That hash is XORed with the
second 16-octet (or less) segment of the Subformat and placed in the
corresponding octets of the Value field of the Hidden AVP.
The hiding method was adapted from [RFC2865], which was taken from If necessary, this operation is repeated, with the shared key used
the "Mixing in the Plaintext" section in the book "Network Security" along with each XOR result to generate the next hash to XOR the next
by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of segment of the value with.
the method follows:
Call the shared key S, the Random Vector RV, and the Attribute Value The hiding method was adapted from [RFC2865], which was taken from
AV. Break the value field into 16-octet chunks p1, p2, etc., with the "Mixing in the Plaintext" section in the book "Network Security"
the last one padded at the end with random data to a 16-octet by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of
boundary. Call the ciphertext blocks c(1), c(2), etc. We will also the method follows:
define intermediate values b1, b2, etc.
b1 = MD5(AV + S + RV) c(1) = p1 xor b1 Call the shared key S, the Random Vector RV, and the Attribute Value
b2 = MD5(S + c(1)) c(2) = p2 xor b2 AV. Break the value field into 16-octet chunks p1, p2, etc., with
. . the last one padded at the end with random data to a 16-octet
. . boundary. Call the ciphertext blocks c(1), c(2), etc. We will also
. . define intermediate values b1, b2, etc.
bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i), where + denotes b1 = MD5(AV + S + RV) c(1) = p1 xor b1
concatenation. b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
On receipt, the random vector is taken from the last Random Vector The String will contain c(1)+c(2)+...+c(i), where + denotes
AVP encountered in the message prior to the AVP to be unhidden. The concatenation.
above process is then reversed to yield the original value.
On receipt, the random vector is taken from the last Random Vector
AVP encountered in the message prior to the AVP to be unhidden. The
above process is then reversed to yield the original value.
5.4 AVP Summary 5.4 AVP Summary
The following sections contain a list of all L2TP AVPs defined in The following sections contain a list of all L2TP AVPs defined in
this document. this document.
Following the name of the AVP is a list indicating the message types Following the name of the AVP is a list indicating the message types
that utilize each AVP. After each AVP title follows a short that utilize each AVP. After each AVP title follows a short
description of the purpose of the AVP, a detail (including a graphic) description of the purpose of the AVP, a detail (including a graphic)
of the format for the Attribute Value, and any additional information of the format for the Attribute Value, and any additional information
needed for proper use of the AVP. needed for proper use of the AVP.
5.4.1 General Control Message AVPs 5.4.1 General Control Message AVPs
Message Type (All Messages) Message Type (All Messages)
The Message Type AVP, Attribute Type 0, identifies the control The Message Type AVP, Attribute Type 0, identifies the control
message herein and defines the context in which the exact meaning of message herein and defines the context in which the exact meaning of
the following AVPs will be determined. the following AVPs will be determined.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type is a 2-octet unsigned integer. The Message Type is a 2-octet unsigned integer.
The Message Type AVP MUST be the first AVP in a message, immediately The Message Type AVP MUST be the first AVP in a message, immediately
following the control message header (defined in Section 3.2.1). See following the control message header (defined in Section 3.2.1). See
Section 3.1 for the list of defined control message types and their Section 3.1 for the list of defined control message types and their
identifiers. identifiers.
The Mandatory (M) bit within the Message Type AVP has special The Mandatory (M) bit within the Message Type AVP has special
meaning. Rather than an indication as to whether the AVP itself meaning. Rather than an indication as to whether the AVP itself
should be ignored if not recognized, it is an indication as to should be ignored if not recognized, it is an indication as to
whether the control message itself should be ignored. If the M bit whether the control message itself should be ignored. If the M bit
is set within the Message Type AVP and the Message Type is unknown to is set within the Message Type AVP and the Message Type is unknown to
the implementation, the control connection MUST be cleared. If the M the implementation, the control connection MUST be cleared. If the M
bit is not set, then the implementation may ignore an unknown message bit is not set, then the implementation may ignore an unknown message
type. The M bit MUST be set to 1 for all message types defined in type. The M bit MUST be set to 1 for all message types defined in
this document. This AVP MAY NOT be hidden (the H bit MUST be 0). this document. This AVP MAY NOT be hidden (the H bit MUST be 0).
The Length of this AVP is 8. The Length of this AVP is 8.
A vendor-specific control message may be defined by setting the A vendor-specific control message may be defined by setting the
Vendor ID of the Message Type AVP to a value other than the IETF Vendor ID of the Message Type AVP to a value other than the IETF
Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be
the first AVP in the control message. the first AVP in the control message.
Message Digest (All Messages) Message Digest (All Messages)
The Message Digest AVP, Attribute Type AVP-TBA-1, is used as an The Message Digest AVP, Attribute Type AVP-TBA-1, is used as an
integrity check and authentication of the L2TP Control Message integrity check and authentication of the L2TP Control Message
header and body. header and body.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Message Digest ... | Digest Type | Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Digest Type is a one octet integer indicating the Digest +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
calculation algorithm: ... (16 or 20 octets) |
0 HMAC-MD5 [RFC1321] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 HMAC-SHA-1 [RFC2104] Where Digest Type is a one octet integer indicating the Digest
calculation algorithm:
0 HMAC-MD5 [RFC1321]
1 HMAC-SHA-1 [RFC2104]
Digest type 0 (HMAC-MD5) MUST be supported, Digest Type 1 (HMAC- Digest type 0 (HMAC-MD5) MUST be supported, Digest Type 1 (HMAC-
SHA-1) MAY be supported. SHA-1) MAY be supported.
The Message Digest is of variable length and contains the result The Message Digest is of variable length and contains the result
of the control message authenticity and integrity calculation. For of the control message authenticity and integrity calculation. For
Digest Type 0 (HMAC-MD5) the length of the digest MUST be 160 Digest Type 0 (HMAC-MD5) the length of the digest MUST be 16
bits. The local_nonce and remote_nonce are advertised via the bytes. For Digest Type 1 (SHA-1) the digest MUST be 20 bytes.
Control Message Authentication Nonce AVP, also defined in this
section.
If Control Connection and Control Message Authentication is If Control Connection and Control Message Authentication is
enabled, the Message Digest AVP MUST present in all messages and enabled, the Message Digest AVP MUST present in all messages and
MUST be placed immediately after the Message Type AVP. This forces MUST be placed immediately after the Message Type AVP. This forces
the Message Digest to be present within each message at a well- the Message Digest to be present within each message at a well-
known and fixed offset. known and fixed offset.
The shared secret between LCCEs is used to derive a unique shared The shared secret between LCCEs is used to derive a unique shared
key for Control Connection and Control Message Authentication key for Control Connection and Control Message Authentication
calculations. The derived shared key is obtained via a one-way calculations. The derived shared key is obtained via a one-way
HMAC-MD5 hash [RFC1321] on the shared secret concatenated with a HMAC-MD5 hash [RFC1321] on the shared secret concatenated with a
single octet containing the value 2. single octet containing the value 2.
shared_key = HMAC_MD5 (shared_secret | 2) shared_key = HMAC_MD5 (shared_secret | 2)
Calculation of the digest is as follows for all messages other Calculation of the digest is as follows for all messages other
than the SCCRQ: than the SCCRQ:
Digest = Hash (local_nonce | remote_nonce | shared_key | Digest = Hash (local_nonce | remote_nonce | shared_key |
control_message) control_message)
Hash: Hashing algorithm identified by the Digest Type Hash: Hashing algorithm identified by the Digest Type
local_nonce: Nonce chosen locally and advertised to the remote local_nonce: Nonce chosen locally and advertised to the remote
LCCE. LCCE.
remote_nonce: Nonce received from the remote LCCE remote_nonce: Nonce received from the remote LCCE
shared_key: Derived shared key for this Control Connection (The local_nonce and remote_nonce are advertised via the
control_message: The entire contents of the L2TP Control Control Message Authentication Nonce AVP, also defined in this
Message, including the Control Message header and all AVPs. section.)
Note that the Control Message header in this case begins after
the 0 Session ID (see Section 4.1.1.2) when running over IP,
and after the UDP header when running over UDP (see Section
4.1.2.1).
When calculating the Message Digest, the Message Digest AVP MUST shared_key: Derived shared key for this Control Connection
be present within the control message with the Digest Type set to
its proper value, but the Message Digest itself set to zeros.
When receiving a control message, the contents of the Message control_message: The entire contents of the L2TP Control
Digest AVP MUST be compared against the expected digest value Message, including the Control Message header and all AVPs.
based on local calculation. This is done by performing the same
digest calculation above, with the local_nonce and remote_nonce
reversed. This message authenticity and integrity checking MUST be
performed before utilizing any information contained within the
control message. If the calculation fails, the message MUST be
dropped.
The SCCRQ has special treatment as it is the initial message Note that the Control Message header in this case begins after
commencing a new Control Connection. As such, there is only one the 0 Session ID (see Section 4.1.1.2) when running over IP,
nonce available. Since the nonce is present within the message and after the UDP header when running over UDP (see Section
itself as part of the Control Message Authentication Nonce AVP, 4.1.2.1).
there is no need to use it in the calculation explicitly.
Calculation of the SCCRQ Digest is performed as follows:
Digest = Hash (shared_key | control_message) When calculating the Message Digest, the Message Digest AVP MUST
be present within the control message with the Digest Type set to
its proper value, but the Message Digest itself set to zeros.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for When receiving a control message, the contents of the Message
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Digest AVP MUST be compared against the expected digest value
Length is 28 for Digest Type 1 (HMAC-MD5), and may vary for other based on local calculation. This is done by performing the same
digest types. digest calculation above, with the local_nonce and remote_nonce
reversed. This message authenticity and integrity checking MUST be
performed before utilizing any information contained within the
control message. If the calculation fails, the message MUST be
dropped.
Control Message Authentication Nonce (SCCRQ, SCCRP) The SCCRQ has special treatment as it is the initial message
commencing a new Control Connection. As such, there is only one
nonce available. Since the nonce is present within the message
itself as part of the Control Message Authentication Nonce AVP,
there is no need to use it in the calculation explicitly.
Calculation of the SCCRQ Digest is performed as follows:
The Control Message Authentication Nonce AVP, Attribute Type Digest = Hash (shared_key | control_message)
AVP-TBA-15, MUST contain a cryptographically random value
[RFC1750]. This value is used for Control Message
Authentication.
The Attribute Value field for this AVP has the following This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
format: this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type
2 (SHA-1). Control Message Authentication Nonce (SCCRQ, SCCRP)
0 1 2 3 The Control Message Authentication Nonce AVP, Attribute Type
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 AVP-TBA-15, MUST contain a cryptographically random value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [RFC1750]. This value is used for Control Message
| Nonce ... (arbitrary number of octets) Authentication.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce is of arbitrary length, though at least 16 octets is The Attribute Value field for this AVP has the following
recommended. The Nonce contains the random value for use in format:
the Control Message Authentication hash calculation (see
Message Digest AVP definition in this section).
If Control Connection and Message Authentication is enabled, 0 1 2 3
this AVP MUST be present in the SCCRQ and SCCRP messages. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit The Nonce is of arbitrary length, though at least 16 octets is
for this AVP SHOULD be set to 1, but MAY vary (see Section recommended. The Nonce contains the random value for use in
5.2). The Length of this AVP is 6 plus the length of the the Control Message Authentication hash calculation (see
Nonce. Message Digest AVP definition in this section).
If Control Connection and Message Authentication is enabled,
this AVP MUST be present in the SCCRQ and SCCRP messages.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit
for this AVP SHOULD be set to 1, but MAY vary (see Section
5.2). The Length of this AVP is 6 plus the length of the Nonce.
Random Vector (All Messages) Random Vector (All Messages)
The Random Vector AVP, Attribute Type 36, MUST contain a The Random Vector AVP, Attribute Type 36, MUST contain a
cryptographically random value [RFC1750]. This value is used for AVP cryptographically random value [RFC1750]. This value is used for AVP
Hiding. Hiding.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ... (arbitrary number of octets) | Random Octet String ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String is of arbitrary length, though at least 16 The Random Octet String is of arbitrary length, though at least 16
octets is recommended. The string contains the random vector for use octets is recommended. The string contains the random vector for use
in computing the MD5 hash to retrieve or hide the Attribute Value of in computing the MD5 hash to retrieve or hide the Attribute Value of
a hidden AVP (see Section 5.3). a hidden AVP (see Section 5.3).
More than one Random Vector AVP may appear in a message, in which More than one Random Vector AVP may appear in a message, in which
case a hidden AVP uses the Random Vector AVP most closely preceding case a hidden AVP uses the Random Vector AVP most closely preceding
it. As such, at least one Random Vector AVP MUST precede the first it. As such, at least one Random Vector AVP MUST precede the first
AVP with the H bit set. AVP with the H bit set.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Random Octet String. Length of this AVP is 6 plus the length of the Random Octet String.
5.4.2 Result and Error Codes 5.4.2 Result and Error Codes
Result Code (StopCCN, CDN) Result Code (StopCCN, CDN)
The Result Code AVP, Attribute Type 1, indicates the reason for The Result Code AVP, Attribute Type 1, indicates the reason for
terminating the control channel or session. terminating the control channel or session.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (optional) | | Result Code | Error Code (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message ... (optional, arbitrary number of octets) | | Error Message ... (optional, arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code is a 2-octet unsigned integer. The optional Error The Result Code is a 2-octet unsigned integer. The optional Error
Code is a 2-octet unsigned integer. An optional Error Message can Code is a 2-octet unsigned integer. An optional Error Message can
follow the Error Code field. Presence of the Error Code and Message follow the Error Code field. Presence of the Error Code and Message
is indicated by the AVP Length field. The Error Message contains an is indicated by the AVP Length field. The Error Message contains an
arbitrary string providing further (human-readable) text associated arbitrary string providing further (human-readable) text associated
with the condition. Human-readable text in all error messages MUST with the condition. Human-readable text in all error messages MUST
be provided in the UTF-8 charset using the Default Language be provided in the UTF-8 charset using the Default Language
[RFC2277]. [RFC2277].
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length is 8 if there is no Error Code or Message, 10 if there is an Length is 8 if there is no Error Code or Message, 10 if there is an
Error Code and no Error Message, or 10 plus the length of the Error Error Code and no Error Message, or 10 plus the length of the Error
Message if there is an Error Code and Message. Message if there is an Error Code and Message.
Defined Result Code values for the StopCCN message are as follows: Defined Result Code values for the StopCCN message are as follows:
0 - Reserved. 0 - Reserved.
1 - General request to clear control connection. 1 - General request to clear control connection.
2 - General error, Error Code indicates the problem. 2 - General error, Error Code indicates the problem.
3 - Control channel already exists. 3 - Control channel already exists.
4 - Requester is not authorized to establish a control channel. 4 - Requester is not authorized to establish a control channel.
5 - The protocol version of the requester is not supported, 5 - The protocol version of the requester is not supported,
Error Code indicates highest version supported. Error Code indicates highest version supported.
6 - Requester is being shut down. 6 - Requester is being shut down.
7 - Finite state machine error or timeout 7 - Finite state machine error or timeout
General Result Code values for the CDN message are as follows: General Result Code values for the CDN message are as follows:
0 - Reserved. 0 - Reserved.
1 - Session disconnected due to loss of carrier or circuit disconnect. 1 - Session disconnected due to loss of carrier or circuit disconnect.
2 - Session disconnected for the reason indicated in Error Code.
3 - Session disconnected for administrative reasons.
4 - Session establishment failed due to lack of appropriate
facilities being available (temporary condition).
5 - Session establishment failed due to lack of appropriate
facilities being available (permanent condition).
6 - 11 Reserved (PPP-specific codes defined outside this document).
RC-TBA-1 - Session not established due to losing tie breaker.
RC-TBA-2 - Session not established due to unsupported PW type.
2 - Session disconnected for the reason indicated in Error Code. RC-TBA-3 - Session not established, sequencing required without valid
3 - Session disconnected for administrative reasons. L2-Specific Sublayer.
4 - Session establishment failed due to lack of appropriate RC-TBA-4 - Finite state machine error or timeout.
facilities being available (temporary condition).
5 - Session establishment failed due to lack of appropriate
facilities being available (permanent condition).
6 - 11 Reserved (PPP-specific codes defined outside this document).
RC-TBA-1 - Session not established due to losing tie breaker.
RC-TBA-2 - Session not established due to unsupported PW type.
RC-TBA-3 - Session not established, sequencing required without valid
L2-Specific Sublayer.
RC-TBA-4 - Finite state machine error or timeout.
Additional service-specific Result Codes are defined outside this Additional service-specific Result Codes are defined outside this
document. document.
The Error Codes defined below pertain to types of errors that are not The Error Codes defined below pertain to types of errors that are not
specific to any particular L2TP request, but rather to protocol or specific to any particular L2TP request, but rather to protocol or
message format errors. If an L2TP reply indicates in its Result Code message format errors. If an L2TP reply indicates in its Result Code
that a general error occurred, the General Error value should be that a general error occurred, the General Error value should be
examined to determine what the error was. The currently defined examined to determine what the error was. The currently defined
General Error codes and their meanings are as follows: General Error codes and their meanings are as follows:
0 - No general error. 0 - No general error.
1 - No control connection exists yet for this pair of LCCEs. 1 - No control connection exists yet for this pair of LCCEs.
2 - Length is wrong. 2 - Length is wrong.
3 - One of the field values was out of range. 3 - One of the field values was out of range.
4 - Insufficient resources to handle this operation now. 4 - Insufficient resources to handle this operation now.
5 - Invalid Session ID. 5 - Invalid Session ID.
6 - A generic vendor-specific error occurred. 6 - A generic vendor-specific error occurred.
7 - Try another. If initiator is aware of other possible responder 7 - Try another. If initiator is aware of other possible responder
destinations, it should try one of them. This can be destinations, it should try one of them. This can be
used to guide an LAC or LNS based on policy. used to guide an LAC or LNS based on policy.
8 - The session or control connection was shut down due to receipt of 8 - The session or control connection was shut down due to receipt of
an unknown AVP with the M bit set (see Section 5.2). The Error an unknown AVP with the M bit set (see Section 5.2). The Error
Message SHOULD contain the attribute of the offending AVP in Message SHOULD contain the attribute of the offending AVP in
(human-readable) text form. (human-readable) text form.
9 - Try another directed. If an LAC or LNS is aware of other possible 9 - Try another directed. If an LAC or LNS is aware of other possible
destinations, it should inform the initiator of the control destinations, it should inform the initiator of the control
connection or session. The Error Message MUST contain a connection or session. The Error Message MUST contain a
comma-separated list of addresses from which the initiator may comma-separated list of addresses from which the initiator may
choose. If the L2TP data channel runs over IPv4, then this would choose. If the L2TP data channel runs over IPv4, then this would
be a comma-separated list of IP addresses in the canonical be a comma-separated list of IP addresses in the canonical
dotted-decimal format (e.g. "10.0.0.1, 10.0.0.2, 10.0.0.3") in the dotted-decimal format (e.g. "10.0.0.1, 10.0.0.2, 10.0.0.3") in the
UTF-8 charset using the Default Language [RFC2277]. If there are UTF-8 charset using the Default Language [RFC2277]. If there are
no servers for the LAC or LNS to suggest, then Error Code 7 should no servers for the LAC or LNS to suggest, then Error Code 7 should
be used. The delimiter between addresses MUST be precisely a be used. The delimiter between addresses MUST be precisely a
single comma and a single space. single comma and a single space.
When a General Error Code of 6 is used, additional information about When a General Error Code of 6 is used, additional information about
the error SHOULD be included in the Error Message field. A vendor- the error SHOULD be included in the Error Message field. A vendor-
specific AVP MAY be sent to more precisely detail a vendor-specific specific AVP MAY be sent to more precisely detail a vendor-specific
problem. problem.
5.4.3 Control Connection Management AVPs 5.4.3 Control Connection Management AVPs
Control Connection Tie Breaker (SCCRQ) Control Connection Tie Breaker (SCCRQ)
The Control Connection Tie Breaker AVP, Attribute Type 5, indicates The Control Connection Tie Breaker AVP, Attribute Type 5, indicates
that the sender desires a single control connection to exist between that the sender desires a single control connection to exist between
a given pair of LCCEs. a given pair of LCCEs.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Tie Breaker Value ... | Control Connection Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) | ... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Connection Tie Breaker Value is an 8-octet random value The Control Connection Tie Breaker Value is an 8-octet random value
that is used to choose a single control connection when two LCCEs that is used to choose a single control connection when two LCCEs
request a control connection concurrently. The recipient of a SCCRQ request a control connection concurrently. The recipient of a SCCRQ
must check to see if a SCCRQ has been sent to the peer; if so, a tie must check to see if a SCCRQ has been sent to the peer; if so, a tie
has been detected. In this case, the LCCE must compare its Control has been detected. In this case, the LCCE must compare its Control
Connection Tie Breaker value with the one received in the SCCRQ. The Connection Tie Breaker value with the one received in the SCCRQ. The
lower value "wins", and the "loser" MUST discard its control lower value "wins", and the "loser" MUST discard its control
connection, sending a StopCCN if the SCCRQ that it had sent was connection, sending a StopCCN if the SCCRQ that it had sent was
acknowledged by the receiving peer. In the case in which a tie acknowledged by the receiving peer. In the case in which a tie
breaker is present on both sides and the value is equal, both sides breaker is present on both sides and the value is equal, both sides
MUST discard their control connections and restart control connection MUST discard their control connections and restart control connection
negotiation with a new, random tie breaker value. negotiation with a new, random tie breaker value.
If a tie breaker is received and an outstanding SCCRQ has no tie If a tie breaker is received and an outstanding SCCRQ has no tie
breaker value, the initiator that included the Control Connection Tie breaker value, the initiator that included the Control Connection Tie
Breaker AVP "wins". If neither side issues a tie breaker, then two Breaker AVP "wins". If neither side issues a tie breaker, then two
separate control connections are opened. separate control connections are opened.
Applications which employ a distinct and well-known initiator have no Applications which employ a distinct and well-known initiator have no
need for tie-breaking, and this AVP MAY be omitted and the tie- need for tie-breaking, and this AVP MAY be omitted and the tie-
breaking functionality disabled. Applications which require tie- breaking functionality disabled. Applications which require tie-
breaking also require that an LCCE be uniquely identifiable upon breaking also require that an LCCE be uniquely identifiable upon
receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via
the Router ID AVP. the Router ID AVP.
Note that in [RFC2661], this AVP was referred to as the "Tie-Breaker Note that in [RFC2661], this AVP was referred to as the "Tie-Breaker
AVP". Here, the AVP serves the same purpose and has the same AVP". Here, the AVP serves the same purpose and has the same
attribute value and composition. The name was changed simply to attribute value and composition. The name was changed simply to
distinguish between the Session and Control Connection Tie Breaker distinguish between the Session and Control Connection Tie Breaker
AVP. AVP.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 14. Length of this AVP is 14.
Host Name (SCCRQ, SCCRP) Host Name (SCCRQ, SCCRP)
The Host Name AVP, Attribute Type 7, indicates the name of the The Host Name AVP, Attribute Type 7, indicates the name of the
issuing LAC or LNS, encoded in the US-ASCII charset. issuing LAC or LNS, encoded in the US-ASCII charset.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name ... (arbitrary number of octets) | Host Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name is of arbitrary length, but MUST be at least 1 octet. The Host Name is of arbitrary length, but MUST be at least 1 octet.
This name should be as broadly unique as possible; for hosts This name should be as broadly unique as possible; for hosts
participating in DNS [RFC1034], a host name with fully qualified participating in DNS [RFC1034], a host name with fully qualified
domain would be appropriate. The Host Name AVP and/or Router ID AVP domain would be appropriate. The Host Name AVP and/or Router ID AVP
MUST be used to identify an LCCE as described in Section 3.3. MUST be used to identify an LCCE as described in Section 3.3.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Host Name. Length of this AVP is 6 plus the length of the Host Name.
Router ID (SCCRQ, SCCRP) Router ID (SCCRQ, SCCRP)
The Router ID AVP, Attribute Type AVP-TBA-2, is an identifier used to The Router ID AVP, Attribute Type AVP-TBA-2, is an identifier used to
identify an LCCE for control connection setup, tie breaking, and/or identify an LCCE for control connection setup, tie breaking, and/or
tunnel authentication. tunnel authentication.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier | | Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Router Identifier is a 4-octet unsigned integer. Its value is The Router Identifier is a 4-octet unsigned integer. Its value is
unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name
AVP and/or Router ID AVP MUST be used to identify an LCCE as AVP and/or Router ID AVP MUST be used to identify an LCCE as
described in Section 3.3. described in Section 3.3.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 10. Length of this AVP is 10.
Vendor Name (SCCRQ, SCCRP) Vendor Name (SCCRQ, SCCRP)
The Vendor Name AVP, Attribute Type 8, contains a vendor-specific The Vendor Name AVP, Attribute Type 8, contains a vendor-specific
(possibly human-readable) string describing the type of LAC or LNS (possibly human-readable) string describing the type of LAC or LNS
being used. being used.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Name ... (arbitrary number of octets) | Vendor Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor Name is the indicated number of octets representing the The Vendor Name is the indicated number of octets representing the
vendor string. Human-readable text for this AVP MUST be provided in vendor string. Human-readable text for this AVP MUST be provided in
the US-ASCII charset [RFC1958, RFC2277]. the US-ASCII charset [RFC1958, RFC2277].
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 6 plus the length of the Vendor Name. (before hiding) of this AVP is 6 plus the length of the Vendor Name.
Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
The Assigned Control Connection ID AVP, Attribute Type AVP-TBA-3, The Assigned Control Connection ID AVP, Attribute Type AVP-TBA-3,
contains the ID being assigned to this control connection by the contains the ID being assigned to this control connection by the
sender. sender.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Control Connection ID | | Assigned Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Control Connection ID is a 4-octet non-zero unsigned The Assigned Control Connection ID is a 4-octet non-zero unsigned
integer. integer.
The Assigned Control Connection ID AVP establishes the identifier The Assigned Control Connection ID AVP establishes the identifier
used to multiplex and demultiplex multiple control connections used to multiplex and demultiplex multiple control connections
between a pair of LCCEs. Once the Assigned Control Connection ID AVP between a pair of LCCEs. Once the Assigned Control Connection ID AVP
has been received by an LCCE, the Control Connection ID specified in has been received by an LCCE, the Control Connection ID specified in
the AVP MUST be included in the Control Connection ID field of all the AVP MUST be included in the Control Connection ID field of all
control packets sent to the peer for the lifetime of the control control packets sent to the peer for the lifetime of the control
connection. Before the Assigned Control Connection ID AVP is connection. Before the Assigned Control Connection ID AVP is
received from a peer, all control messages MUST be sent to that peer received from a peer, all control messages MUST be sent to that peer
with a Control Connection ID value of 0 in the header. Because a with a Control Connection ID value of 0 in the header. Because a
Control Connection ID value of 0 is used in this special manner, the Control Connection ID value of 0 is used in this special manner, the
zero value MUST NOT be sent as an Assigned Control Connection ID zero value MUST NOT be sent as an Assigned Control Connection ID
value. value.
Under certain circumstances, an LCCE may need to send a StopCCN to a Under certain circumstances, an LCCE may need to send a StopCCN to a
peer without having yet received an Assigned Control Connection ID peer without having yet received an Assigned Control Connection ID
AVP from the peer (i.e. SCCRQ sent, no SCCRP received yet). In this AVP from the peer (i.e. SCCRQ sent, no SCCRP received yet). In this
case, the Assigned Control Connection ID AVP that had been sent to case, the Assigned Control Connection ID AVP that had been sent to
the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned
Control Connection ID AVP in the StopCCN. This policy allows the Control Connection ID AVP in the StopCCN. This policy allows the
peer to try to identify the appropriate control connection via a peer to try to identify the appropriate control connection via a
reverse lookup. reverse lookup.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 10. (before hiding) of this AVP is 10.
Receive Window Size (SCCRQ, SCCRP) Receive Window Size (SCCRQ, SCCRP)
The Receive Window Size AVP, Attribute Type 10, specifies the receive The Receive Window Size AVP, Attribute Type 10, specifies the receive
window size being offered to the remote peer. window size being offered to the remote peer.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size | | Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2-octet unsigned integer.
If absent, the peer must assume a Window Size of 4 for its transmit The Window Size is a 2-octet unsigned integer.
window.
The remote peer may send the specified number of control messages If absent, the peer must assume a Window Size of 4 for its transmit
before it must wait for an acknowledgment. See Section 4.2 for more window.
information on reliable control message delivery.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for The remote peer may send the specified number of control messages
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The before it must wait for an acknowledgment. See Section 4.2 for more
Length of this AVP is 8. information on reliable control message delivery.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 8.
Pseudowire Capabilities List (SCCRQ, SCCRP) Pseudowire Capabilities List (SCCRQ, SCCRP)
The Pseudowire Capabilities List (PW Capabilities List) AVP, The Pseudowire Capabilities List (PW Capabilities List) AVP,
Attribute Type AVP-TBA-4, indicates the L2 payload types the sender Attribute Type AVP-TBA-4, indicates the L2 payload types the sender
can support. The specific payload type of a given session is can support. The specific payload type of a given session is
identified by the Pseudowire Type AVP. identified by the Pseudowire Type AVP.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type 0 | ... | | PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PW Type N | | ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined PW types that may appear in this list are managed by IANA and Defined PW types that may appear in this list are managed by IANA and
will appear in associated pseudowire-specific documents for each PW will appear in associated pseudowire-specific documents for each PW
type. type.
If a sender includes a given PW type in the PW Capabilities List AVP, If a sender includes a given PW type in the PW Capabilities List AVP,
the sender assumes full responsibility for supporting that particular the sender assumes full responsibility for supporting that particular
payload, such as any payload-specific AVPs, L2-Specific Sublayer, or payload, such as any payload-specific AVPs, L2-Specific Sublayer, or
control messages that may be defined in the appropriate companion control messages that may be defined in the appropriate companion
document. document.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 8 octets with one PW type specified, (before hiding) of this AVP is 8 octets with one PW type specified,
plus 2 octets for each additional PW type. plus 2 octets for each additional PW type.
Preferred Language (SCCRQ, SCCRP) Preferred Language (SCCRQ, SCCRP)
The Preferred Language AVP, Attribute Type AVP-TBD-14, provides a The Preferred Language AVP, Attribute Type AVP-TBD-14, provides a
method for an LCCE to indicate to the peer the language in which method for an LCCE to indicate to the peer the language in which
human-readable messages it sends SHOULD be composed. This AVP human-readable messages it sends SHOULD be composed. This AVP
contains a single language tag or language range [RFC3066]. contains a single language tag or language range [RFC3066].
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Language... (arbitrary number of octets) | Preferred Language... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Preferred Language is the indicated number of octets representing The Preferred Language is the indicated number of octets representing
the language tag or language range, encoded in the US-ASCII charset. the language tag or language range, encoded in the US-ASCII charset.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 6 plus the length of the Preferred (before hiding) of this AVP is 6 plus the length of the Preferred
Language. Language.
5.4.4 Session Management AVPs 5.4.4 Session Management AVPs
Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
The Local Session ID AVP (analogous to the Assigned Session ID in The Local Session ID AVP (analogous to the Assigned Session ID in
L2TPv2), Attribute Type AVP-TBA-5, contains the identifier being L2TPv2), Attribute Type AVP-TBA-5, contains the identifier being
assigned to this session by the sender. assigned to this session by the sender.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Session ID | | Local Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Local Session ID is a 4-octet non-zero unsigned integer. The Local Session ID is a 4-octet non-zero unsigned integer.
The Local Session ID AVP establishes the two identifiers used to The Local Session ID AVP establishes the two identifiers used to
multiplex and demultiplex sessions between two LCCEs. Each LCCE multiplex and demultiplex sessions between two LCCEs. Each LCCE
chooses any free value it desires, and sends it to the remote LCCE chooses any free value it desires, and sends it to the remote LCCE
using this AVP. The remote LCCE MUST then send all data packets using this AVP. The remote LCCE MUST then send all data packets
associated with this session using this value. Additionally, for all associated with this session using this value. Additionally, for all
session-oriented control messages sent after this AVP is received session-oriented control messages sent after this AVP is received
(e.g. ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this (e.g. ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this
value in the Remote Session ID AVP. value in the Remote Session ID AVP.
Note that a Session ID value is unidirectional. Because each LCCE Note that a Session ID value is unidirectional. Because each LCCE
chooses its Session ID independent of its peer LCCE, the value does chooses its Session ID independent of its peer LCCE, the value does
not have to match in each direction for a given session. not have to match in each direction for a given session.
See Section 4.1 for additional information about the Session ID. See Section 4.1 for additional information about the Session ID.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 10. (before hiding) of this AVP is 10.
Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
The Remote Session ID AVP, Attribute Type AVP-TBA-6, contains the The Remote Session ID AVP, Attribute Type AVP-TBA-6, contains the
identifier that was assigned to this session by the peer. identifier that was assigned to this session by the peer.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID | | Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote Session ID is a 4-octet non-zero unsigned integer. The Remote Session ID is a 4-octet non-zero unsigned integer.
The Remote Session ID AVP MUST be present in all session-level The Remote Session ID AVP MUST be present in all session-level
control messages. The AVP's value echoes the session identifier control messages. The AVP's value echoes the session identifier
advertised by the peer via the Local Session ID AVP. It is the same advertised by the peer via the Local Session ID AVP. It is the same
value that will be used in all transmitted data messages by this side value that will be used in all transmitted data messages by this side
of the session. In most cases, this identifier is sufficient for the of the session. In most cases, this identifier is sufficient for the
peer to look up session-level context for this control message. peer to look up session-level context for this control message.
When a session-level control message must be sent to the peer before When a session-level control message must be sent to the peer before
the Local Session ID AVP has been received, the value of the Remote the Local Session ID AVP has been received, the value of the Remote
Sesson ID AVP MUST be set to zero. Additionally, the Local Session Sesson ID AVP MUST be set to zero. Additionally, the Local Session
ID AVP (sent in a previous control message for this session) MUST be ID AVP (sent in a previous control message for this session) MUST be
included in the control message. The peer must then use the Local included in the control message. The peer must then use the Local
Session ID AVP to perform a reverse lookup to find its session Session ID AVP to perform a reverse lookup to find its session
context. Session-level control messages defined in this document context. Session-level control messages defined in this document
that might be subject to a reverse lookup by a receiving peer include that might be subject to a reverse lookup by a receiving peer include
the CDN, WEN, and SLI. the CDN, WEN, and SLI.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5, but MAY vary AVP SHOULD be set to 1, but MAY vary (see Section 5, but MAY vary
(see Section 5.2). The Length (before hiding) of this AVP is 10. (see Section 5.2). The Length (before hiding) of this AVP is 10.
Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)
The Assigned Cookie AVP, Attribute Type AVP-TBA-7, contains the The Assigned Cookie AVP, Attribute Type AVP-TBA-7, contains the
Cookie value being assigned to this session by the sender. Cookie value being assigned to this session by the sender.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Cookie (32 or 64 bits) ... | Assigned Cookie (32 or 64 bits) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Cookie is a 4-octet or 8-octet random value. The Assigned Cookie is a 4-octet or 8-octet random value.
The Assigned Cookie AVP contains the value used to check the The Assigned Cookie AVP contains the value used to check the
association of a received data message with the session identified by association of a received data message with the session identified by
the Session ID. All data messages sent to a peer MUST use the the Session ID. All data messages sent to a peer MUST use the
Assigned Cookie sent by the peer in this AVP. The value's length (0, Assigned Cookie sent by the peer in this AVP. The value's length (0,
32, or 64 bits) is obtained by the Length of the AVP. 32, or 64 bits) is obtained by the Length of the AVP.
A missing Assigned Cookie AVP or Assigned Cookie Value of zero length A missing Assigned Cookie AVP or Assigned Cookie Value of zero length
indicates that the Cookie field should not be present in any data indicates that the Cookie field should not be present in any data
packets sent to the LCCE sending this AVP. packets sent to the LCCE sending this AVP.
See Section 4.1 for additional information about the Assigned Cookie. See Section 4.1 for additional information about the Assigned Cookie.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP may be 6, 10, or 14 octets. (before hiding) of this AVP may be 6, 10, or 14 octets.
Serial Number (ICRQ, OCRQ) Serial Number (ICRQ, OCRQ)
The Serial Number AVP, Attribute Type 15, contains an identifier The Serial Number AVP, Attribute Type 15, contains an identifier
assigned by the LAC or LNS to this session. assigned by the LAC or LNS to this session.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Serial Number is a 32-bit value. The Serial Number is a 32-bit value.
The Serial Number is intended to be an easy reference for The Serial Number is intended to be an easy reference for
administrators on both ends of a control connection to use when administrators on both ends of a control connection to use when
investigating session failure problems. Serial Numbers should be set investigating session failure problems. Serial Numbers should be set
to progressively increasing values, which are likely to be unique for to progressively increasing values, which are likely to be unique for
a significant period of time across all interconnected LNSs and LACs. a significant period of time across all interconnected LNSs and LACs.
Note that in RFC 2661, this value was referred to as the "Call Serial Note that in RFC 2661, this value was referred to as the "Call Serial
Number AVP". It serves the same purpose and has the same attribute Number AVP". It serves the same purpose and has the same attribute
value and composition. value and composition.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 10. (before hiding) of this AVP is 10.
Remote End ID (ICRQ, OCRQ) Remote End ID (ICRQ, OCRQ)
The Remote End ID AVP, Attribute Type AVP-TBA-8, contains an The Remote End ID AVP, Attribute Type AVP-TBA-8, contains an
identifier used to bind L2TP sessions to a given circuit, interface, identifier used to bind L2TP sessions to a given circuit, interface,
or bridging instance. It also may be used to detect session-level or bridging instance. It also may be used to detect session-level
ties. ties.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote End Identifier ... (arbitrary number of octets) | Remote End Identifier ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote End Identifier field is a variable-length field whose The Remote End Identifier field is a variable-length field whose
value is unique for a given LCCE peer, as described in Section 3.3. value is unique for a given LCCE peer, as described in Section 3.3.
A session-level tie is detected if an LCCE receives an ICRQ or OCRQ A session-level tie is detected if an LCCE receives an ICRQ or OCRQ
with an End ID AVP whose value matches that which was just sent in an with an End ID AVP whose value matches that which was just sent in an
outgoing ICRQ or OCRQ to the same peer. If the two values match, an outgoing ICRQ or OCRQ to the same peer. If the two values match, an
LCCE recognizes that a tie exists (e.g. both LCCEs are attempting to LCCE recognizes that a tie exists (e.g. both LCCEs are attempting to
establish sessions for the same circuit). The tie is broken by the establish sessions for the same circuit). The tie is broken by the
Session Tie Breaker AVP. Session Tie Breaker AVP.
By default, the LAC-LAC cross-connect application (see section By default, the LAC-LAC cross-connect application (see section
2.0(b)) of L2TP over an IP network MUST utilize the Router ID AVP and 2.0(b)) of L2TP over an IP network MUST utilize the Router ID AVP and
Remote End ID AVP to associate a circuit to an L2TP session. Other Remote End ID AVP to associate a circuit to an L2TP session. Other
AVPs MAY be used for LCCE or circuit identification as specified in AVPs MAY be used for LCCE or circuit identification as specified in
companion documents. companion documents.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 6 plus the length of the Remote End (before hiding) of this AVP is 6 plus the length of the Remote End
Identifier value. Identifier value.
Application Code (ICRQ, OCRQ) Application Code (ICRQ, OCRQ)
The Application Code AVP, Attribute Type AVP-TBA-9, is a 2 octet The Application Code AVP, Attribute Type AVP-TBA-9, is a 2 octet
value for enumerating application types for a given L2TP session. value for enumerating application types for a given L2TP session.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Code | | Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Application Code is a 2 octet value used to identify a specific The Application Code is a 2 octet value used to identify a specific
application for an L2TP session, perhaps causing certain values application for an L2TP session, perhaps causing certain values
within AVPs defined in this document to be interpreted or acted upon within AVPs defined in this document to be interpreted or acted upon
in a different manner dictated by the Application Code. For example, in a different manner dictated by the Application Code. For example,
a given Application Code could instruct an LCCE to perform a specific a given Application Code could instruct an LCCE to perform a specific
directory lookup on the Hostname and/or Router ID AVP information directory lookup on the Hostname and/or Router ID AVP information
associated with this session (perhaps even encoding the destination associated with this session (perhaps even encoding the destination
address of the given directory server). address of the given directory server).
An Application Code of 0, or absence of this AVP in any control An Application Code of 0, or absence of this AVP in any control
message, indicates that all AVPs should be interpreted as defined in message, indicates that all AVPs should be interpreted as defined in
this document. this document.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 8. (before hiding) of this AVP is 8.
Session Tie Breaker (ICRQ, OCRQ) Session Tie Breaker (ICRQ, OCRQ)
The Session Tie Breaker AVP, Attribute Type TBD, is used to break The Session Tie Breaker AVP, Attribute Type TBD, is used to break
ties when two peers concurrently attempt to establish a session for ties when two peers concurrently attempt to establish a session for
the same circuit. the same circuit.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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 Tie Breaker Value ... | Session Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) | ... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session Tie Breaker Value is an 8-octet random value that is used The Session Tie Breaker Value is an 8-octet random value that is used
to choose a session when two LCCEs concurrently request a session for to choose a session when two LCCEs concurrently request a session for
the same circuit. A tie is detected by examining the peer's identity the same circuit. A tie is detected by examining the peer's identity
(described in Section 3.3) plus the per-session shared value (described in Section 3.3) plus the per-session shared value
communicated via the End ID AVP. In the case of a tie, the recipient communicated via the End ID AVP. In the case of a tie, the recipient
of an ICRQ or OCRQ must compare the received tie breaker value with of an ICRQ or OCRQ must compare the received tie breaker value with
the one that it sent earlier. The LCCE with the lower value "wins", the one that it sent earlier. The LCCE with the lower value "wins",
and the "loser" MUST send a CDN with result code set to RC-TBA-1 (as and the "loser" MUST send a CDN with result code set to RC-TBA-1 (as
defined in Section 5.4.2) to tear down the session it instigated. In defined in Section 5.4.2) to tear down the session it instigated. In
the case in which a tie is detected, tie breakers are sent by both the case in which a tie is detected, tie breakers are sent by both
sides, and the tie breaker values are equal, both sides MUST discard sides, and the tie breaker values are equal, both sides MUST discard
their sessions and restart session negotiation with new random tie their sessions and restart session negotiation with new random tie
breaker values. breaker values.
If a tie is detected but only one side sends a Session Tie Breaker If a tie is detected but only one side sends a Session Tie Breaker
AVP, the session initiator that included the Session Tie Breaker AVP AVP, the session initiator that included the Session Tie Breaker AVP
"wins". If neither side issues a tie breaker, then both sides MUST "wins". If neither side issues a tie breaker, then both sides MUST
tear down the session. tear down the session.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of
Length of this AVP is 14. this AVP is 14.
Pseudowire Type (ICRQ, OCRQ) Pseudowire Type (ICRQ, OCRQ)
The Pseudowire Type (PW Type) AVP, Attribute Type AVP-TBA-10, The Pseudowire Type (PW Type) AVP, Attribute Type AVP-TBA-10,
indicates the L2 payload type of the packets that will be tunneled indicates the L2 payload type of the packets that will be tunneled
using this L2TP session. using this L2TP session.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | | PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer MUST NOT request an incoming or outgoing call with a PW Type A peer MUST NOT request an incoming or outgoing call with a PW Type
AVP specifying a value not advertised in the PW Capabilities List AVP AVP specifying a value not advertised in the PW Capabilities List AVP
it received during control connection establishment. Attempts to do it received during control connection establishment. Attempts to do
so MUST result in the call being rejected via a CDN with the Result so MUST result in the call being rejected via a CDN with the Result
Code set to RC-TBA-2 (see Section 5.4.2). Code set to RC-TBA-2 (see Section 5.4.2).
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 8. (before hiding) of this AVP is 8.
L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
The L2-Specific Sublayer AVP, Attribute Type AVP-TBA-11, indicates The L2-Specific Sublayer AVP, Attribute Type AVP-TBA-11, indicates
the the presence and format of the L2-Specific Sublayer the sender of the the presence and format of the L2-Specific Sublayer the sender of
this AVP requires on all incoming data packets for this L2TP session. this AVP requires on all incoming data packets for this L2TP session.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer Type | | L2-Specific Sublayer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2-Specific Sublayer Type is a 2-octet unsigned integer with the The L2-Specific Sublayer Type is a 2-octet unsigned integer with the
following values defined in this document: following values defined in this document:
0 - There is no L2-Specific Sublayer present. 0 - There is no L2-Specific Sublayer present.
1 - The default L2-Specific Sublayer (defined in Section 4.6) 1 - The default L2-Specific Sublayer (defined in Section 4.6)
is used. is used.
If this AVP is received and has a value other than zero, the If this AVP is received and has a value other than zero, the
receiving LCCE MUST include the identified L2-Specific Sublayer in receiving LCCE MUST include the identified L2-Specific Sublayer in
its outgoing data messages. If the AVP is not received, it is its outgoing data messages. If the AVP is not received, it is
assumed that there is no sublayer present. assumed that there is no sublayer present.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 8. (before hiding) of this AVP is 8.
Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
The Data Sequencing AVP, Attribute Type AVP-TBA-12, indicates that The Data Sequencing AVP, Attribute Type AVP-TBA-12, indicates that
the sender requires some or all of the data packets that it receives the sender requires some or all of the data packets that it receives
to be sequenced. to be sequenced.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequencing Level | | Data Sequencing Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data Sequencing Level is a 2-octet unsigned integer indicating The Data Sequencing Level is a 2-octet unsigned integer indicating
the degree of incoming data traffic that the sender of this AVP the degree of incoming data traffic that the sender of this AVP
wishes to be marked with sequence numbers. wishes to be marked with sequence numbers.
The following values are valid data sequencing levels: The following values are valid data sequencing levels:
0 - No incoming data packets require sequencing. 0 - No incoming data packets require sequencing.
1 - Only non-IP data packets require sequencing. 1 - Only non-IP data packets require sequencing.
2 - All incoming data packets require sequencing. 2 - All incoming data packets require sequencing.
If a data sequencing level of 0 is specified, there is no need to If a data sequencing level of 0 is specified, there is no need to
send packets with sequence numbers. If sequence numbers are sent, send packets with sequence numbers. If sequence numbers are sent,
they will be ignored upon receipt. If no Data Sequencing AVP is they will be ignored upon receipt. If no Data Sequencing AVP is
received, a data sequencing level of 0 is assumed. received, a data sequencing level of 0 is assumed.
If a data sequencing level of 1 is specified, only non-IP traffic If a data sequencing level of 1 is specified, only non-IP traffic
carried within the tunneled L2 frame should have sequence numbers carried within the tunneled L2 frame should have sequence numbers
applied. Non-IP traffic here refers to any packets that cannot be applied. Non-IP traffic here refers to any packets that cannot be
classified as an IP packet within their respective L2 framing (i.e., classified as an IP packet within their respective L2 framing (i.e.,
a PPP control packet or NETBIOS frame encapsulated by Frame Relay a PPP control packet or NETBIOS frame encapsulated by Frame Relay
before being tunneled). All traffic that can be classified as IP MUST before being tunneled). All traffic that can be classified as IP MUST
be sent with no sequencing (e.g. the S bit in the L2-Specific be sent with no sequencing (e.g. the S bit in the L2-Specific
Sublayer is set to zero). If a packet is unable to be classified at Sublayer is set to zero). If a packet is unable to be classified at
all (e.g. due to it being compressed or encrypted at layer 2) or if all (e.g. due to it being compressed or encrypted at layer 2) or if
an implementation is unable to perform such classification within L2 an implementation is unable to perform such classification within L2
frames, all packets MUST be provided with sequence numbers frames, all packets MUST be provided with sequence numbers
(essentially falling back to a data sequencing level of 2). (essentially falling back to a data sequencing level of 2).
If a data sequencing level of 2 is specified, all traffic MUST be If a data sequencing level of 2 is specified, all traffic MUST be
sequenced. sequenced.
Data sequencing may only be requested when there is an L2-Specific Data sequencing may only be requested when there is an L2-Specific
Sublayer present that can provide sequence numbers. If sequencing is Sublayer present that can provide sequence numbers. If sequencing is
requested without requesting a L2-Specific Sublayer AVP, the session requested without requesting a L2-Specific Sublayer AVP, the session
MUST be disconnected with a Result Code of RC-TBA-3. MUST be disconnected with a Result Code of RC-TBA-3.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 6. (before hiding) of this AVP is 6.
Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
The Tx Connect Speed BPS AVP, Attribute Type 24, contains the speed The Tx Connect Speed BPS AVP, Attribute Type 24, contains the speed
of the facility chosen for the connection attempt. of the facility chosen for the connection attempt.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx Connect Speed BPS | | Tx Connect Speed BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tx Connect Speed BPS is a 4-octet value indicating the speed in The Tx Connect Speed BPS is a 4-octet value indicating the speed in
bits per second. A value of zero indicates that the speed is bits per second. A value of zero indicates that the speed is
indeterminable or that there is no physical point-to-point link. indeterminable or that there is no physical point-to-point link.
When the optional Rx Connect Speed AVP is present, the value in this When the optional Rx Connect Speed AVP is present, the value in this
AVP represents the transmit connect speed from the perspective of the AVP represents the transmit connect speed from the perspective of the
LAC (e.g. data flowing from the LAC to the remote system). When the LAC (e.g. data flowing from the LAC to the remote system). When the
optional Rx Connect Speed AVP is NOT present, the connection speed optional Rx Connect Speed AVP is NOT present, the connection speed
between the remote system and LAC is assumed to be symmetric and is between the remote system and LAC is assumed to be symmetric and is
represented by the single value in this AVP. represented by the single value in this AVP.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 10. (before hiding) of this AVP is 10.
Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
The Rx Connect Speed AVP, Attribute Type 38, represents the speed of The Rx Connect Speed AVP, Attribute Type 38, represents the speed of
the connection from the perspective of the LAC (e.g. data flowing the connection from the perspective of the LAC (e.g. data flowing
from the remote system to the LAC). from the remote system to the LAC).
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Connect Speed BPS | | Rx Connect Speed BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rx Connect Speed BPS is a 4-octet value indicating the speed in bits Rx Connect Speed BPS is a 4-octet value indicating the speed in bits
per second. A value of zero indicates that the speed is per second. A value of zero indicates that the speed is
indeterminable or that there is no physical point-to-point link. indeterminable or that there is no physical point-to-point link.
Presence of this AVP implies that the connection speed may be Presence of this AVP implies that the connection speed may be
asymmetric with respect to the transmit connect speed given in the Tx asymmetric with respect to the transmit connect speed given in the Tx
Connect Speed AVP. Connect Speed AVP.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 10. (before hiding) of this AVP is 10.
Physical Channel ID (ICRQ, ICRP, OCRP) Physical Channel ID (ICRQ, ICRP, OCRP)
The Physical Channel ID AVP, Attribute Type 25, contains the vendor- The Physical Channel ID AVP, Attribute Type 25, contains the vendor-
specific physical channel number used for a call. specific physical channel number used for a call.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID | | Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4-octet value intended to be used for Physical Channel ID is a 4-octet value intended to be used for
logging purposes only. logging purposes only.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 10. (before hiding) of this AVP is 10.
5.4.5 Circuit Status AVPs 5.4.5 Circuit Status AVPs
Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)
The Circuit Status AVP, Attribute Type AVP-TBA-13, indicates the The Circuit Status AVP, Attribute Type AVP-TBA-13, indicates the
initial status of or a status change in the circuit to which the initial status of or a status change in the circuit to which the
session is bound. session is bound.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A| | Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The A (Active) bit indicates whether the circuit is up/active/ready The A (Active) bit indicates whether the circuit is up/active/ready
(1) or down/inactive/not-ready (0). (1) or down/inactive/not-ready (0).
The N (New) bit indicates whether the circuit status indication is The N (New) bit indicates whether the circuit status indication is
for a new circuit (1) or an existing circuit (0). Links which have a for a new circuit (1) or an existing circuit (0). Links which have a
similar mechanism available (e.g. Frame Relay) MUST map the setting similar mechanism available (e.g. Frame Relay) MUST map the setting
of this bit to the associated signaling for that link. Otherwise, the of this bit to the associated signaling for that link. Otherwise, the
New bit SHOULD still be set the first time the L2TP session is New bit SHOULD still be set the first time the L2TP session is
established after provisioning. established after provisioning.
The remaining bits are reserved for future use. Reserved bits MUST The remaining bits are reserved for future use. Reserved bits MUST
be set to 0 when sending and ignored upon receipt. be set to 0 when sending and ignored upon receipt.
The Circuit Status AVP is used to advertise whether a circuit or The Circuit Status AVP is used to advertise whether a circuit or
interface bound to an L2TP session is up and ready to send and/or interface bound to an L2TP session is up and ready to send and/or
receive traffic. Different circuit types have different names for receive traffic. Different circuit types have different names for
status types. For example, HDLC primary and secondary stations refer status types. For example, HDLC primary and secondary stations refer
to a circuit as being "Receive Ready" or "Receive Not Ready", while to a circuit as being "Receive Ready" or "Receive Not Ready", while
Frame Relay refers to a circuit as "Active" or "Inactive". This AVP Frame Relay refers to a circuit as "Active" or "Inactive". This AVP
adopts the latter terminology, though the concept remains the same adopts the latter terminology, though the concept remains the same
regardless of the PW type for the L2TP session. regardless of the PW type for the L2TP session.
In the simplest case, the circuit referred by this AVP is a single In the simplest case, the circuit referred by this AVP is a single
physical interface, port, or circuit depending on application and how physical interface, port, or circuit depending on application and how
the session was setup. The status indication in this AVP may then be the session was setup. The status indication in this AVP may then be
used to provide simple ILMI interworking for a variety of circuit used to provide simple ILMI interworking for a variety of circuit
types. For virtual or multipoint interfaces, the Circuit Status AVP types. For virtual or multipoint interfaces, the Circuit Status AVP
is still utilized, but effectively refers to the state of an internal is still utilized, but effectively refers to the state of an internal
structure or a logical set of circuits. Each PW-specific companion structure or a logical set of circuits. Each PW-specific companion
document MUST then specify precisely how this AVP is translated for document MUST then specify precisely how this AVP is translated for
each circuit type. each circuit type.
If this AVP is received with a Not Active notification for a given If this AVP is received with a Not Active notification for a given
L2TP session, all data traffic for that session MUST cease (or not L2TP session, all data traffic for that session MUST cease (or not
begin) in the direction of the sender of the Circuit Status AVP until begin) in the direction of the sender of the Circuit Status AVP until
the circuit is advertised as Active. the circuit is advertised as Active.
The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP,
OCRQ, and OCRP messages. Often, the circuit type will be marked OCRQ, and OCRP messages. Often, the circuit type will be marked
Active when initiated, but MAY be advertised as Inactive, indicating Active when initiated, but MAY be advertised as Inactive, indicating
that an L2TP session is to be created but that the interface or that an L2TP session is to be created but that the interface or
circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI
control messages all MAY contain this AVP to update the status of the control messages all MAY contain this AVP to update the status of the
circuit after establishment of the L2TP session is requested. circuit after establishment of the L2TP session is requested.
If additional circuit status information is needed for a given PW If additional circuit status information is needed for a given PW
type, PW-specific AVPs MUST be defined in a separate document for type, PW-specific AVPs MUST be defined in a separate document for
that information. This AVP is only for general circuit status that information. This AVP is only for general circuit status
information applicable to all circuit/interface types. information applicable to all circuit/interface types.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 8. (before hiding) of this AVP is 8.
Circuit Errors (WEN) Circuit Errors (WEN)
The Circuit Errors AVP, Attribute Type 34, conveys circuit error The Circuit Errors AVP, Attribute Type 34, conveys circuit error
information to the peer. information to the peer.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns | | Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns | | Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Errors | | Timeout Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors | | Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
Reserved: 2 octets of Reserved data is present (providing longword The following fields are defined:
alignment within the AVP of the following values). Reserved
data MUST be zero on sending and ignored upon receipt.
Hardware Overruns: Number of receive buffer overruns since call
was established.
Buffer Overruns: Number of buffer overruns detected since call was
established.
Timeout Errors: Number of timeouts since call was established.
Alignment Errors: Number of alignment errors since call was
established.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this Reserved: 2 octets of Reserved data is present (providing longword
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length alignment within the AVP of the following values). Reserved
(before hiding) of this AVP is 32. data MUST be zero on sending and ignored upon receipt.
Hardware Overruns: Number of receive buffer overruns since call
was established.
Buffer Overruns: Number of buffer overruns detected since call was
established.
Timeout Errors: Number of timeouts since call was established.
Alignment Errors: Number of alignment errors since call was
established.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length
(before hiding) of this AVP is 32.
6. Control Connection Protocol Specification 6. Control Connection Protocol Specification
The following control messages are used to establish, maintain, and The following control messages are used to establish, maintain, and
tear down L2TP control connections. All data packets are sent in tear down L2TP control connections. All data packets are sent in
network order (high-order octets first). Any "reserved" or "empty" network order (high-order octets first). Any "reserved" or "empty"
fields MUST be sent as 0 values to allow for protocol extensibility. fields MUST be sent as 0 values to allow for protocol extensibility.
The exchanges in which these messages are involved are outlined in The exchanges in which these messages are involved are outlined in
Section 3.3. Section 3.3.
6.1 Start-Control-Connection-Request (SCCRQ) 6.1 Start-Control-Connection-Request (SCCRQ)
Start-Control-Connection-Request (SCCRQ) is a control message used to Start-Control-Connection-Request (SCCRQ) is a control message used to
initiate a control connection between two LCCEs. It is sent by initiate a control connection between two LCCEs. It is sent by
either the LAC or the LNS to begin the control connection either the LAC or the LNS to begin the control connection
establishment process. establishment process.
The following AVPs MUST be present in the SCCRQ: The following AVPs MUST be present in the SCCRQ:
Message Type Message Type
Host Name Host Name
Router ID Router ID
Assigned Control Connection ID Assigned Control Connection ID
Pseudowire Capabilities List Pseudowire Capabilities List
The following AVPs MAY be present in the SCCRQ: The following AVPs MAY be present in the SCCRQ:
Random Vector Random Vector
Nonce Nonce
Message Digest Message Digest
Control Connection Tie Breaker Control Connection Tie Breaker
Vendor Name Vendor Name
Receive Window Size Receive Window Size
Preferred Language Preferred Language
6.2 Start-Control-Connection-Reply (SCCRP) 6.2 Start-Control-Connection-Reply (SCCRP)
Start-Control-Connection-Reply (SCCRP) is the control message sent in Start-Control-Connection-Reply (SCCRP) is the control message sent in
reply to a received SCCRQ message. The SCCRP is used to indicate reply to a received SCCRQ message. The SCCRP is used to indicate
that the SCCRQ was accepted and establishment of the control that the SCCRQ was accepted and establishment of the control
connection should continue. connection should continue.
The following AVPs MUST be present in the SCCRP: The following AVPs MUST be present in the SCCRP:
Message Type Message Type
Host Name Host Name
Router ID Router ID
Assigned Control Connection ID Assigned Control Connection ID
Pseudowire Capabilities List Pseudowire Capabilities List
The following AVPs MAY be present in the SCCRP: The following AVPs MAY be present in the SCCRP:
Random Vector Random Vector
Nonce Nonce
Message Digest Message Digest
Vendor Name Vendor Name
Receive Window Size Receive Window Size
Preferred Language Preferred Language
6.3 Start-Control-Connection-Connected (SCCCN) 6.3 Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) is the control message Start-Control-Connection-Connected (SCCCN) is the control message
sent in reply to an SCCRP. The SCCCN completes the control sent in reply to an SCCRP. The SCCCN completes the control
connection establishment process. connection establishment process.
The following AVP MUST be present in the SCCCN: The following AVP MUST be present in the SCCCN:
Message Type Message Type
The following AVP MAY be present in the SCCCN: The following AVP MAY be present in the SCCCN:
Random Vector Random Vector
Message Digest Message Digest
6.4 Stop-Control-Connection-Notification (StopCCN) 6.4 Stop-Control-Connection-Notification (StopCCN)
Stop-Control-Connection-Notification (StopCCN) is the control message Stop-Control-Connection-Notification (StopCCN) is the control message
sent by either LCCE to inform its peer that the control connection is sent by either LCCE to inform its peer that the control connection is
being shut down and that the control connection should be closed. In being shut down and that the control connection should be closed. In
addition, all active sessions are implicitly cleared (without sending addition, all active sessions are implicitly cleared (without sending
any explicit session control messages). The reason for issuing this any explicit session control messages). The reason for issuing this
request is indicated in the Result Code AVP. There is no explicit request is indicated in the Result Code AVP. There is no explicit
reply to the message, only the implicit ACK that is received by the reply to the message, only the implicit ACK that is received by the
reliable control message delivery layer. reliable control message delivery layer.
The following AVPs MUST be present in the StopCCN: The following AVPs MUST be present in the StopCCN:
Message Type Message Type
Result Code Result Code
The following AVPs MAY be present in the StopCCN: The following AVPs MAY be present in the StopCCN:
Random Vector Random Vector
Message Digest Message Digest
Assigned Control Connection ID Assigned Control Connection ID
Note that the Assigned Control Connection ID MUST be present if the Note that the Assigned Control Connection ID MUST be present if the
StopCCN is sent after an SCCRQ or SCCRP message has been sent. StopCCN is sent after an SCCRQ or SCCRP message has been sent.
6.5 Hello (HELLO) 6.5 Hello (HELLO)
The Hello (HELLO) message is an L2TP control message sent by either The Hello (HELLO) message is an L2TP control message sent by either
peer of a control connection. This control message is used as a peer of a control connection. This control message is used as a
"keepalive" for the control connection. See Section 4.2 for a "keepalive" for the control connection. See Section 4.2 for a
description of the keepalive mechanism. description of the keepalive mechanism.
HELLO messages are global to the control connection. The Session ID HELLO messages are global to the control connection. The Session ID
in a HELLO message MUST be 0. in a HELLO message MUST be 0.
The following AVP MUST be present in the HELLO: The following AVP MUST be present in the HELLO:
Message Type Message Type
The following AVP MAY be present in the HELLO: The following AVP MAY be present in the HELLO:
Random Vector Random Vector
Message Digest Message Digest
6.6 Incoming-Call-Request (ICRQ) 6.6 Incoming-Call-Request (ICRQ)
Incoming-Call-Request (ICRQ) is the control message sent by an LCCE Incoming-Call-Request (ICRQ) is the control message sent by an LCCE
to a peer when an incoming call is detected (although the ICRQ may to a peer when an incoming call is detected (although the ICRQ may
also be sent as a result of a local event). It is the first in a also be sent as a result of a local event). It is the first in a
three-message exchange used for establishing a session via an L2TP three-message exchange used for establishing a session via an L2TP
control connection. control connection.
The ICRQ is used to indicate that a session is to be established The ICRQ is used to indicate that a session is to be established
between an LCCE and a peer. The sender of an ICRQ provides the peer between an LCCE and a peer. The sender of an ICRQ provides the peer
with parameter information for the session. However, the sender with parameter information for the session. However, the sender
makes no demands about how the session is terminated at the peer makes no demands about how the session is terminated at the peer
(i.e. whether the L2 traffic is processed locally, forwarded, etc.). (i.e. whether the L2 traffic is processed locally, forwarded, etc.).
The following AVPs MUST be present in the ICRQ: The following AVPs MUST be present in the ICRQ:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
Serial Number Serial Number
Pseudowire Type Pseudowire Type
Circuit Status Circuit Status
The following AVPs MAY be present in the ICRQ: The following AVPs MAY be present in the ICRQ:
Random Vector Random Vector
Message Digest Message Digest
Assigned Cookie Assigned Cookie
Remote End ID Remote End ID
Application ID Application ID
Session Tie Breaker Session Tie Breaker
L2-Specific Sublayer L2-Specific Sublayer
Data Sequencing Data Sequencing
Tx Connect Speed Tx Connect Speed
Rx Connect Speed Rx Connect Speed
Physical Channel ID Physical Channel ID
6.7 Incoming-Call-Reply (ICRP) 6.7 Incoming-Call-Reply (ICRP)
Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in
response to a received ICRQ. It is the second in the three-message response to a received ICRQ. It is the second in the three-message
exchange used for establishing sessions within an L2TP control exchange used for establishing sessions within an L2TP control
connection. connection.
The ICRP is used to indicate that the ICRQ was successful and that The ICRP is used to indicate that the ICRQ was successful and that
the peer should establish (i.e. answer) the incoming call if it has the peer should establish (i.e. answer) the incoming call if it has
not already done so. It also allows the sender to indicate specific not already done so. It also allows the sender to indicate specific
parameters about the L2TP session. parameters about the L2TP session.
The following AVPs MUST be present in the ICRP: The following AVPs MUST be present in the ICRP:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
Circuit Status Circuit Status
The following AVPs MAY be present in the ICRP: The following AVPs MAY be present in the ICRP:
Random Vector Random Vector
Message Digest Message Digest
Assigned Cookie Assigned Cookie
L2-Specific Sublayer L2-Specific Sublayer
Data Sequencing Data Sequencing
Tx Connect Speed Tx Connect Speed
Rx Connect Speed Rx Connect Speed
Physical Channel ID Physical Channel ID
6.8 Incoming-Call-Connected (ICCN) 6.8 Incoming-Call-Connected (ICCN)
Incoming-Call-Connected (ICCN) is the control message sent by the Incoming-Call-Connected (ICCN) is the control message sent by the
LCCE that originally sent an ICRQ upon receiving an ICRP from its LCCE that originally sent an ICRQ upon receiving an ICRP from its
peer. It is the final message in the three-message exchange used for peer. It is the final message in the three-message exchange used for
establishing L2TP sessions. establishing L2TP sessions.
The ICCN is used to indicate that the ICRP was accepted, that the The ICCN is used to indicate that the ICRP was accepted, that the
call has been established, and that the L2TP session should move to call has been established, and that the L2TP session should move to
the established state. It also allows the sender to indicate the established state. It also allows the sender to indicate
specific parameters about the established call (parameters that may specific parameters about the established call (parameters that may
not have been available at the time the ICRQ is issued). not have been available at the time the ICRQ is issued).
The following AVPs MUST be present in the ICCN: The following AVPs MUST be present in the ICCN:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
The following AVPs MAY be present in the ICCN: The following AVPs MAY be present in the ICCN:
Random Vector Random Vector
Message Digest Message Digest
L2-Specific Sublayer L2-Specific Sublayer
Data Sequencing Data Sequencing
Tx Connect Speed Tx Connect Speed
Rx Connect Speed Rx Connect Speed
Circuit Status Circuit Status
6.9 Outgoing-Call-Request (OCRQ) 6.9 Outgoing-Call-Request (OCRQ)
Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE
to an LAC to indicate that an outbound call at the LAC is to be to an LAC to indicate that an outbound call at the LAC is to be
established based on specific destination information sent in this established based on specific destination information sent in this
message. It is the first in a three-message exchange used for message. It is the first in a three-message exchange used for
establishing a session and placing a call on behalf of the initiating establishing a session and placing a call on behalf of the initiating
LCCE. LCCE.
Note that a call may be any L2 connection requiring well-known Note that a call may be any L2 connection requiring well-known
destination information to be sent from an LCCE to an LAC. This call destination information to be sent from an LCCE to an LAC. This call
could be a dialup connection to the PSTN, an SVC connection, the IP could be a dialup connection to the PSTN, an SVC connection, the IP
address of another LCCE, or any other destination dictated by the address of another LCCE, or any other destination dictated by the
sender of this message. sender of this message.
The following AVPs MUST be present in the OCRQ: The following AVPs MUST be present in the OCRQ:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
Serial Number Serial Number
Pseudowire Type Pseudowire Type
Circuit Status Circuit Status
The following AVPs MAY be present in the OCRQ: The following AVPs MAY be present in the OCRQ:
Random Vector Random Vector
Message Digest Message Digest
Assigned Cookie Assigned Cookie
Remote End ID Remote End ID
Application ID Application ID
Tx Connect Speed Tx Connect Speed
Rx Connect Speed Rx Connect Speed
Session Tie Breaker Session Tie Breaker
L2-Specific Sublayer L2-Specific Sublayer
Data Sequencing Data Sequencing
6.10 Outgoing-Call-Reply (OCRP) 6.10 Outgoing-Call-Reply (OCRP)
Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to
an LCCE in response to a received OCRQ. It is the second in a three- an LCCE in response to a received OCRQ. It is the second in a
message exchange used for establishing a session within an L2TP three-message exchange used for establishing a session within an L2TP
control connection. control connection.
OCRP is used to indicate that the LAC has been able to attempt the OCRP is used to indicate that the LAC has been able to attempt the
outbound call. The message returns any relevant parameters regarding outbound call. The message returns any relevant parameters regarding
the call attempt. Data MUST NOT be forwarded until the OCCN is the call attempt. Data MUST NOT be forwarded until the OCCN is
received indicating that the call has been placed. received indicating that the call has been placed.
The following AVPs MUST be present in the OCRP: The following AVPs MUST be present in the OCRP:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
Circuit Status Circuit Status
The following AVPs MAY be present in the OCRP: The following AVPs MAY be present in the OCRP:
Random Vector Random Vector
Message Digest Message Digest
Assigned Cookie Assigned Cookie
L2-Specific Sublayer L2-Specific Sublayer
Tx Connect Speed Tx Connect Speed
Rx Connect Speed Rx Connect Speed
Data Sequencing Data Sequencing
Physical Channel ID Physical Channel ID
6.11 Outgoing-Call-Connected (OCCN) 6.11 Outgoing-Call-Connected (OCCN)
Outgoing-Call-Connected (OCCN) is the control message sent by an LAC Outgoing-Call-Connected (OCCN) is the control message sent by an LAC
to another LCCE after the OCRP and after the outgoing call has been to another LCCE after the OCRP and after the outgoing call has been
completed. It is the final message in a three-message exchange used completed. It is the final message in a three-message exchange used
for establishing a session. for establishing a session.
OCCN is used to indicate that the result of a requested outgoing call OCCN is used to indicate that the result of a requested outgoing call
was successful. It also provides information to the LCCE who was successful. It also provides information to the LCCE who
requested the call about the particular parameters obtained after the requested the call about the particular parameters obtained after the
call was established. call was established.
The following AVPs MUST be present in the OCCN: The following AVPs MUST be present in the OCCN:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
The following AVPs MAY be present in the OCCN: The following AVPs MAY be present in the OCCN:
Random Vector Random Vector
Message Digest Message Digest
L2-Specific Sublayer L2-Specific Sublayer
Tx Connect Speed Tx Connect Speed
Rx Connect Speed Rx Connect Speed
Data Sequencing Data Sequencing
Circuit Status Circuit Status
6.12 Call-Disconnect-Notify (CDN) 6.12 Call-Disconnect-Notify (CDN)
The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE
to request disconnection of a specific session. Its purpose is to to request disconnection of a specific session. Its purpose is to
inform the peer of the disconnection and the reason for the inform the peer of the disconnection and the reason for the
disconnection. The peer MUST clean up any resources, and does not disconnection. The peer MUST clean up any resources, and does not
send back any indication of success or failure for such cleanup. send back any indication of success or failure for such cleanup.
The following AVPs MUST be present in the CDN: The following AVPs MUST be present in the CDN:
Message Type Message Type
Result Code Result Code
Local Session ID Local Session ID
Remote Session ID Remote Session ID
The following AVP MAY be present in the CDN: The following AVP MAY be present in the CDN:
Random Vector Random Vector
Message Digest Message Digest
6.13 WAN-Error-Notify (WEN) 6.13 WAN-Error-Notify (WEN)
The WAN-Error-Notify (WEN) is a control message sent from an LAC to an The WAN-Error-Notify (WEN) is a control message sent from an LAC to an
LNS to indicate WAN error conditions. The counters in this message LNS to indicate WAN error conditions. The counters in this message
are cumulative. This message should only be sent when an error are cumulative. This message should only be sent when an error
occurs, and not more than once every 60 seconds. The counters are occurs, and not more than once every 60 seconds. The counters are
reset when a new call is established. reset when a new call is established.
The following AVPs MUST be present in the WEN: The following AVPs MUST be present in the WEN:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
Circuit Errors Circuit Errors
The following AVP MAY be present in the WEN: The following AVP MAY be present in the WEN:
Random Vector Random Vector
Message Digest Message Digest
6.14 Set-Link-Info (SLI) 6.14 Set-Link-Info (SLI)
The Set-Link-Info control message is sent by an LCCE to convey link The Set-Link-Info control message is sent by an LCCE to convey link
or circuit status change information regarding the circuit associated or circuit status change information regarding the circuit associated
with this L2TP session. For example, if PPP renegotiates LCP at an with this L2TP session. For example, if PPP renegotiates LCP at an
LNS or between an LAC and a Remote System, or if a forwarded Frame LNS or between an LAC and a Remote System, or if a forwarded Frame
Relay VC transitions to Active or Inactive at an LAC, an SLI message Relay VC transitions to Active or Inactive at an LAC, an SLI message
SHOULD be sent to indicate this event. Precise details of when the SHOULD be sent to indicate this event. Precise details of when the
SLI is sent, what PW type-specific AVPs must be present, and how SLI is sent, what PW type-specific AVPs must be present, and how
those AVPs should be interpreted by the receiving peer are outside those AVPs should be interpreted by the receiving peer are outside
the scope of this document. These details should be described in the the scope of this document. These details should be described in the
associated pseudowire-specific documents that require use of this associated pseudowire-specific documents that require use of this
message. message.
The following AVPs MUST be present in the SLI: The following AVPs MUST be present in the SLI:
Message Type Message Type
Local Session ID Local Session ID
Remote Session ID Remote Session ID
The following AVPs MAY be present in the SLI: The following AVPs MAY be present in the SLI:
Random Vector Random Vector
Message Digest Message Digest
Circuit Status Circuit Status
6.15 Explicit-Acknowledgement (ACK) 6.15 Explicit-Acknowledgement (ACK)
The Explicit Acknowledgement (ACK) message is used only to The Explicit Acknowledgement (ACK) message is used only to
acknowledge receipt of a message or messages on the Control acknowledge receipt of a message or messages on the Control
Connection (e.g. for purposes of updating Ns and Nr values). Receipt Connection (e.g. for purposes of updating Ns and Nr values). Receipt
of this message does not trigger an event for the L2TP protocol state of this message does not trigger an event for the L2TP protocol state
machine. machine.
A message received without any AVPs (including the Message Type AVP), A message received without any AVPs (including the Message Type AVP),
is referred to as a Zero Length Body (ZLB) message, and serves the is referred to as a Zero Length Body (ZLB) message, and serves the
same function as the Explicit Acknowledgement. ZLB messages are only same function as the Explicit Acknowledgement. ZLB messages are only
permitted when the Control Message Authentication defined in Section permitted when the Control Message Authentication defined in Section
4.3 is not enabled. 4.3 is not enabled.
The following AVPs MAY be present in the ACK message: The following AVPs MAY be present in the ACK message:
Message Type Message Type
Message Digest Message Digest
mi.sp mi.sp
7. Control Connection State Machines 7. Control Connection State Machines
The state tables defined in this section govern the exchange of The state tables defined in this section govern the exchange of
control messages defined in Section 6. Tables are defined for control messages defined in Section 6. Tables are defined for
incoming call placement and outgoing call placement, as well as for incoming call placement and outgoing call placement, as well as for
initiation of the control connection itself. The state tables do not initiation of the control connection itself. The state tables do not
encode message timeout and retransmission behavior, as this is encode message timeout and retransmission behavior, as this is
handled in the underlying reliable control message delivery mechanism handled in the underlying reliable control message delivery mechanism
(see Section 4.2). (see Section 4.2).
Timers MAY be employed to enforce a maximum period of time allowed in Timers MAY be employed to enforce a maximum period of time allowed in
a transitional state (i.e. between idle and established). Generally, a transitional state (i.e. between idle and established). Generally,
this is a protection mechanism for cleaning up state when an error this is a protection mechanism for cleaning up state when an error
has occurred, and should be treated as such. The precise period of has occurred, and should be treated as such. The precise period of
time to wait is application dependent and MUST be configurable, with time to wait is application dependent and MUST be configurable, with
the notable default of no timeout at all. If a session is shutdown the notable default of no timeout at all. If a session is shutdown
by a state transition timeout, a CDN MUST be sent with a Result Code by a state transition timeout, a CDN MUST be sent with a Result Code
set to RC-TBA-4 (see Section 5.4.2). If a control connection is set to RC-TBA-4 (see Section 5.4.2). If a control connection is
shutdown by a state transition timeout, a StopCCN MUST be sent with a shutdown by a state transition timeout, a StopCCN MUST be sent with a
Result Code set to 7 (see Section 5.4.2). Result Code set to 7 (see Section 5.4.2).
7.1 Malformed Control Messages 7.1 Malformed Control Messages
Receipt of an invalid or unrecoverable malformed control message Receipt of an invalid or unrecoverable malformed control message
SHOULD be logged appropriately and the control connection cleared to SHOULD be logged appropriately and the control connection cleared to
ensure recovery to a known state. The control connection may then be ensure recovery to a known state. The control connection may then be
restarted by the initiator. An invalid control message is defined as restarted by the initiator. An invalid control message is defined as
(1) a message that contains a Message Type marked as mandatory (see (1) a message that contains a Message Type marked as mandatory (see
Section 5.4.1) but that is unknown to the implementation, or (2) a Section 5.4.1) but that is unknown to the implementation, or (2) a
control message that is received in the wrong state. control message that is received in the wrong state.
Examples of malformed control messages include (1) a message that has Examples of malformed control messages include (1) a message that has
an invalid value in its header, (2) a message that contains an AVP an invalid value in its header, (2) a message that contains an AVP
that is formatted incorrectly or whose value is out of range, and (3) that is formatted incorrectly or whose value is out of range, and (3)
a message that is missing a required AVP. A control message with a a message that is missing a required AVP. A control message with a
malformed header MUST be discarded. malformed header MUST be discarded.
If a malformed AVP is received with the M bit set, the session or If a malformed AVP is received with the M bit set, the session or
control connection MUST be terminated with a proper Result or Error control connection MUST be terminated with a proper Result or Error
Code sent (see Section 5.2). A malformed yet non-mandatory (M bit is Code sent (see Section 5.2). A malformed yet non-mandatory (M bit is
not set) AVP within a control message should be handled like an not set) AVP within a control message should be handled like an
unrecognized non-mandatory AVP. That is, the AVP MUST be ignored unrecognized non-mandatory AVP. That is, the AVP MUST be ignored
(with the exception of logging a local error message), and the (with the exception of logging a local error message), and the
message MUST be accepted. message MUST be accepted.
It is impossible to list all potential malformations of a given It is impossible to list all potential malformations of a given
message. However, an example of a recoverable, malformed AVP might message. However, an example of a recoverable, malformed AVP might
be if the Rx Connect Speed AVP, attribute 38, is received with a be if the Rx Connect Speed AVP, attribute 38, is received with a
length of 8 rather than 10, and the BPS given in 2 octets rather than length of 8 rather than 10, and the BPS given in 2 octets rather than
4. In the Rx Connect Speed is sent with the M bit set to 0, this 4. In the Rx Connect Speed is sent with the M bit set to 0, this
malformation should not be considered catastrophic. As such, the malformation should not be considered catastrophic. As such, the
control message should be accepted as if the AVP had not been control message should be accepted as if the AVP had not been
received (with the exception of a local error message being logged). received (with the exception of a local error message being logged).
This example is by no means a license to create malformed AVPs, but This example is by no means a license to create malformed AVPs, but
simply a guideline for how liberal one should be in acceptance of simply a guideline for how liberal one should be in acceptance of
messages containing errors. messages containing errors.
In the following tables, there are several cases where a protocol In the following tables, there are several cases where a protocol
message is sent and then a "clean up" occurs. Note that, regardless message is sent and then a "clean up" occurs. Note that, regardless
of the initiator of the control connection shutdown, the reliable of the initiator of the control connection shutdown, the reliable
delivery mechanism must be allowed to run (see Section 4.2) before delivery mechanism must be allowed to run (see Section 4.2) before
destroying the control connection. This permits the control destroying the control connection. This permits the control
connection management messages to be reliably delivered to the peer. connection management messages to be reliably delivered to the peer.
Appendix B.1 contains an example of lock-step control connection Appendix B.1 contains an example of lock-step control connection
establishment. establishment.
7.2 Control Connection States 7.2 Control Connection States
The L2TP control connection protocol is not distinguishable between The L2TP control connection protocol is not distinguishable between
the two LCCEs but is distinguishable between the originator and the two LCCEs but is distinguishable between the originator and
receiver. The originating peer is the one that first initiates receiver. The originating peer is the one that first initiates
establishment of the control connection. (In a tie breaker establishment of the control connection. (In a tie breaker
situation, this is the winner of the tie.) Since either the LAC or situation, this is the winner of the tie.) Since either the LAC or
the LNS can be the originator, a collision can occur. See the the LNS can be the originator, a collision can occur. See the
Control Connection Tie Breaker AVP in Section 5.4.3 for a description Control Connection Tie Breaker AVP in Section 5.4.3 for a description
of this and its resolution. of this and its resolution.
State Event Action New State State Event Action New State
----- ----- ------ --------- ----- ----- ------ ---------
idle Local open Send SCCRQ wait-ctl-reply idle Local open Send SCCRQ wait-ctl-reply
request request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable acceptable
idle Receive SCCRQ, Send StopCCN, idle idle Receive SCCRQ, Send StopCCN, idle
not acceptable clean up not acceptable clean up
idle Receive SCCRP Send StopCCN, idle idle Receive SCCRP Send StopCCN, idle
clean up clean up
idle Receive SCCCN Send StopCCN, idle idle Receive SCCCN Send StopCCN, idle
clean up clean up
wait-ctl-reply Receive SCCRP, Send SCCCN, established wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable send control-conn acceptable send control-conn
open event to open event to
waiting sessions waiting sessions
wait-ctl-reply Receive SCCRP, Send StopCCN, idle wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable clean up not acceptable clean up
wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn
lose tie breaker, Clean up losing lose tie breaker, Clean up losing
SCCRQ acceptable connection SCCRQ acceptable connection
wait-ctl-reply Receive SCCRQ, Send StopCCN, idle wait-ctl-reply Receive SCCRQ, Send StopCCN, idle
lose tie breaker, Clean up losing lose tie breaker, Clean up losing
SCCRQ unacceptable connection SCCRQ unacceptable connection
wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply
win tie breaker losing connection win tie breaker losing connection
wait-ctl-reply Receive SCCCN Send StopCCN, idle wait-ctl-reply Receive SCCCN Send StopCCN, idle
clean up clean up
wait-ctl-conn Receive SCCCN, Send control-conn established wait-ctl-conn Receive SCCCN, Send control-conn established
acceptable open event to acceptable open event to
waiting sessions waiting sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable clean up not acceptable clean up
wait-ctl-conn Receive SCCRP, Send StopCCN, idle wait-ctl-conn Receive SCCRP, Send StopCCN, idle
SCCRQ clean up SCCRQ clean up
established Local open Send control-conn established established Local open Send control-conn established
request open event to request open event to
(new call) waiting sessions (new call) waiting sessions
established Administrative Send StopCCN, idle established Administrative Send StopCCN, idle
control-conn clean up control-conn clean up
close event close event
established Receive SCCRQ, Send StopCCN, idle established Receive SCCRQ, Send StopCCN, idle
SCCRP, SCCCN clean up SCCRP, SCCCN clean up
idle, Receive StopCCN Clean up idle idle, Receive StopCCN Clean up idle
wait-ctl-reply, wait-ctl-reply,
wait-ctl-conn, wait-ctl-conn,
established established
The states associated with an LCCE for control connection The states associated with an LCCE for control connection
establishment are as follows: establishment are as follows:
idle idle
Both initiator and recipient start from this state. An initiator Both initiator and recipient start from this state. An initiator
transmits an SCCRQ, while a recipient remains in the idle state transmits an SCCRQ, while a recipient remains in the idle state
until receiving an SCCRQ. until receiving an SCCRQ.
wait-ctl-reply wait-ctl-reply
The originator checks to see if another connection has been The originator checks to see if another connection has been
requested from the same peer, and if so, handles the collision requested from the same peer, and if so, handles the collision
situation described in Section 5.4.3. situation described in Section 5.4.3.
wait-ctl-conn wait-ctl-conn
Awaiting an SCCCN. Upon receipt, the challenge response contained Awaiting an SCCCN. Upon receipt, the challenge response contained
in the message is checked. The control connection is established in the message is checked. The control connection is established
if authentication succeeds; otherwise, it is torn down. if authentication succeeds; otherwise, it is torn down.
established established
An established connection may be terminated by either a local An established connection may be terminated by either a local
condition or the receipt of a StopCCN. In the event of a local condition or the receipt of a StopCCN. In the event of a local
termination, the originator MUST send a StopCCN and clean up the termination, the originator MUST send a StopCCN and clean up the
control connection. If the originator receives a StopCCN, it MUST control connection. If the originator receives a StopCCN, it MUST
also clean up the control connection. also clean up the control connection.
7.3 Incoming Calls 7.3 Incoming Calls
An ICRQ is generated by an LCCE, typically in response to an incoming An ICRQ is generated by an LCCE, typically in response to an incoming
call or a local event. Once the LCCE sends the ICRQ, it waits for a call or a local event. Once the LCCE sends the ICRQ, it waits for a
response from the peer. However, it may choose to postpone response from the peer. However, it may choose to postpone
establishment of the call (e.g. answering the call, bringing up the establishment of the call (e.g. answering the call, bringing up the
circuit) until the peer has indicated with an ICRP that it will circuit) until the peer has indicated with an ICRP that it will
accept the call. The peer may choose not to accept the call if, for accept the call. The peer may choose not to accept the call if, for
instance, there are insufficient resources to handle an additional instance, there are insufficient resources to handle an additional
session. session.
If the peer chooses to accept the call, it responds with an ICRP. If the peer chooses to accept the call, it responds with an ICRP.
When the local LCCE receives the ICRP, it attempts to establish the When the local LCCE receives the ICRP, it attempts to establish the
call. A final call connected message, the ICCN, is sent from the call. A final call connected message, the ICCN, is sent from the
local LCCE to the peer to indicate that the call states for both local LCCE to the peer to indicate that the call states for both
LCCEs should enter the established state. If the call is terminated LCCEs should enter the established state. If the call is terminated
before the peer can accept it, a CDN is sent by the local LCCE to before the peer can accept it, a CDN is sent by the local LCCE to
indicate this condition. indicate this condition.
When a call transitions to a "disconnected" or "down" state, the call When a call transitions to a "disconnected" or "down" state, the call
is cleared normally, and the local LCCE sends a CDN. Similarly, if is cleared normally, and the local LCCE sends a CDN. Similarly, if
the peer wishes to clear a call, it sends a CDN and cleans up its the peer wishes to clear a call, it sends a CDN and cleans up its
session. session.
7.3.1 ICRQ Sender States 7.3.1 ICRQ Sender States
State Event Action New State State Event Action New State
----- ----- ------ --------- ----- ----- ------ ---------
idle Call signal or Initiate local wait-control-conn
ready to receive control-conn
incoming conn open
idle Receive ICCN, Clean up idle idle Call signal or Initiate local wait-control-conn
ICRP, CDN ready to receive control-conn
incoming conn open
wait-control- Bearer line drop Clean up idle idle Receive ICCN, Clean up idle
conn or local close ICRP, CDN
request
wait-control- control-conn-open Send ICRQ wait-reply wait-control- Bearer line drop Clean up idle
conn conn or local close
request
wait-reply Receive ICRP, Send ICCN established wait-control- control-conn-open Send ICRQ wait-reply
acceptable conn
wait-reply Receive ICRP, Send CDN, idle wait-reply Receive ICRP, Send ICCN established
Not acceptable clean up acceptable
wait-reply Receive ICRQ Send CDN, idle wait-reply Receive ICRP, Send CDN, idle
clean up Not acceptable clean up
wait-reply Receive ICRQ, Process as idle wait-reply Receive ICRQ, Process as idle
lose tie breaker ICRQ Recipient lose tie breaker ICRQ Recipient
(Section 7.3.2) (Section 7.3.2)
wait-reply Receive ICRQ, Send CDN wait-reply wait-reply Receive ICRQ, Send CDN wait-reply
win tie breaker for losing win tie breaker for losing
session session
wait-reply Receive CDN, Clean up idle wait-reply Receive CDN, Clean up idle
ICCN ICCN
wait-reply Local close Send CDN, idle wait-reply Local close Send CDN, idle
request clean up request clean up
established Receive CDN Clean up idle established Receive CDN Clean up idle
established Receive ICRQ, Send CDN, idle established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up ICRP, ICCN clean up
established Local close Send CDN, idle established Local close Send CDN, idle
request clean up request clean up
The states associated with the ICRQ sender are as follows: The states associated with the ICRQ sender are as follows:
idle idle
The LCCE detects an incoming call on one of its interfaces (e.g. The LCCE detects an incoming call on one of its interfaces (e.g.
an analog PSTN line rings, or an ATM PVC is provisioned), or a an analog PSTN line rings, or an ATM PVC is provisioned), or a
local event occurs. The LCCE initiates its control connection local event occurs. The LCCE initiates its control connection
establishment state machine and moves to a state waiting for establishment state machine and moves to a state waiting for
confirmation of the existence of a control connection. confirmation of the existence of a control connection.
wait-control-conn wait-control-conn
In this state, the session is waiting for either the control In this state, the session is waiting for either the control
connection to be opened or for verification that the control connection to be opened or for verification that the control
connection is already open. Once an indication that the control connection is already open. Once an indication that the control
connection has been opened is received, session control messages connection has been opened is received, session control messages
may be exchanged. The first of these messages is the ICRQ. may be exchanged. The first of these messages is the ICRQ.
wait-reply wait-reply
The ICRQ sender receives either (1) a CDN indicating the peer is The ICRQ sender receives either (1) a CDN indicating the peer is
not willing to accept the call (general error or do not accept) not willing to accept the call (general error or do not accept)
and moves back into the idle state, or (2) an ICRP indicating the and moves back into the idle state, or (2) an ICRP indicating the
call is accepted. In the latter case, the LCCE sends an ICCN and call is accepted. In the latter case, the LCCE sends an ICCN and
enters the established state. enters the established state.
established established
Data is exchanged over the session. The call may be cleared by Data is exchanged over the session. The call may be cleared by
any of the following: any of the following:
+ An event on the connected interface: The LCCE sends a CDN. + An event on the connected interface: The LCCE sends a CDN.
+ Receipt of a CDN: The LCCE cleans up, disconnecting the call. + Receipt of a CDN: The LCCE cleans up, disconnecting the call.
+ A local reason: The LCCE sends a CDN. + A local reason: The LCCE sends a CDN.
7.3.2 ICRQ Recipient States 7.3.2 ICRQ Recipient States
State Event Action New State State Event Action New State
----- ----- ------ --------- ----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect idle Receive ICRQ, Send ICRP wait-connect
acceptable acceptable
idle Receive ICRQ, Send CDN, idle idle Receive ICRQ, Send CDN, idle
not acceptable clean up not acceptable clean up
idle Receive ICRP Send CDN idle idle Receive ICRP Send CDN idle
clean up clean up
idle Receive ICCN Clean up idle idle Receive ICCN Clean up idle
wait-connect Receive ICCN Prepare for established wait-connect Receive ICCN Prepare for established
acceptable data acceptable data
wait-connect Receive ICCN Send CDN, idle wait-connect Receive ICCN Send CDN, idle
not acceptable clean up not acceptable clean up
wait-connect Receive ICRQ, Send CDN, idle wait-connect Receive ICRQ, Send CDN, idle
ICRP clean up ICRP clean up
idle, Receive CDN Clean up idle idle, Receive CDN Clean up idle
wait-connect, wait-connect,
established established
wait-connect Local close Send CDN, idle wait-connect Local close Send CDN, idle
established request clean up established request clean up
established Receive ICRQ, Send CDN, idle established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up ICRP, ICCN clean up
The states associated with the ICRQ recipient are as follows: The states associated with the ICRQ recipient are as follows:
idle idle
An ICRQ is received. If the request is not acceptable, a CDN is An ICRQ is received. If the request is not acceptable, a CDN is
sent back to the peer LCCE, and the local LCCE remains in the idle sent back to the peer LCCE, and the local LCCE remains in the idle
state. If the ICRQ is acceptable, an ICRP is sent. The session state. If the ICRQ is acceptable, an ICRP is sent. The session
moves to the wait-connect state. moves to the wait-connect state.
wait-connect wait-connect
The local LCCE is waiting for an ICCN from the peer. Upon receipt The local LCCE is waiting for an ICCN from the peer. Upon receipt
of the ICCN, the local LCCE moves to established state. of the ICCN, the local LCCE moves to established state.
established established
The session is terminated either by sending a CDN or by receiving The session is terminated either by sending a CDN or by receiving
a CDN from the peer. Clean up follows on both sides regardless of a CDN from the peer. Clean up follows on both sides regardless of
the initiator. the initiator.
7.4 Outgoing Calls 7.4 Outgoing Calls
Outgoing calls instruct an LAC to place a call. There are three Outgoing calls instruct an LAC to place a call. There are three
messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first
sends an OCRQ to an LAC to request an outgoing call. The LAC MUST sends an OCRQ to an LAC to request an outgoing call. The LAC MUST
respond to the OCRQ with an OCRP once it determines that the proper respond to the OCRQ with an OCRP once it determines that the proper
facilities exist to place the call and that the call is facilities exist to place the call and that the call is
administratively authorized. Once the outbound call is connected, administratively authorized. Once the outbound call is connected,
the LAC sends an OCCN to the peer indicating the final result of the the LAC sends an OCCN to the peer indicating the final result of the
call attempt. call attempt.
7.4.1 OCRQ Sender States 7.4.1 OCRQ Sender States
State Event Action New State State Event Action New State
----- ----- ------ --------- ----- ----- ------ ---------
idle Local open Initiate local wait-control-conn idle Local open Initiate local wait-control-conn
request control-conn-open request control-conn-open
idle Receive OCCN, Clean up idle idle Receive OCCN, Clean up idle
OCRP OCRP
wait-control- control-conn-open Send OCRQ wait-reply wait-control- control-conn-open Send OCRQ wait-reply
conn conn
wait-reply Receive OCRP, none wait-connect wait-reply Receive OCRP, none wait-connect
acceptable acceptable
wait-reply Receive OCRP, Send CDN, idle wait-reply Receive OCRP, Send CDN, idle
not acceptable clean up not acceptable clean up
wait-reply Receive OCCN Send CDN, idle wait-reply Receive OCCN Send CDN, idle
clean up clean up
wait-reply Receive ICRQ, Process as idle wait-reply Receive OCRQ, Process as idle
lose tie breaker OCRQ Recipient lose tie breaker OCRQ Recipient
(Section 7.4.2) (Section 7.4.2)
wait-reply Receive ICRQ, Send CDN wait-reply wait-reply Receive OCRQ, Send CDN wait-reply
win tie breaker for losing win tie breaker for losing
session session
wait-connect Receive OCCN none established wait-connect Receive OCCN none established
wait-connect Receive OCRQ, Send CDN, idle wait-connect Receive OCRQ, Send CDN, idle
OCRP clean up OCRP clean up
idle, Receive CDN Clean up idle idle, Receive CDN Clean up idle
wait-reply, wait-reply,
wait-connect, wait-connect,
established established
established Receive OCRQ, Send CDN, idle established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up OCRP, OCCN clean up
wait-reply, Local close Send CDN, idle wait-reply, Local close Send CDN, idle
wait-connect, request clean up wait-connect, request clean up
established established
wait-control- Local close Clean up idle wait-control- Local close Clean up idle
conn request conn request
The states associated with the OCRQ sender are as follows: The states associated with the OCRQ sender are as follows:
idle, wait-control-conn idle, wait-control-conn
When an outgoing call request is initiated, a control connection When an outgoing call request is initiated, a control connection
is created as described above, if not already present. Once the is created as described above, if not already present. Once the
control connection is established, an OCRQ is sent to the LAC, and control connection is established, an OCRQ is sent to the LAC, and
the session moves into the wait-reply state. the session moves into the wait-reply state.
wait-reply wait-reply
If a CDN is received, the session is cleaned up and returns to If a CDN is received, the session is cleaned up and returns to
idle state. If an OCRP is received, the call is in progress, and idle state. If an OCRP is received, the call is in progress, and
the session moves to the wait-connect state. the session moves to the wait-connect state.
wait-connect wait-connect
If a CDN is received, the session is cleaned up and returns to If a CDN is received, the session is cleaned up and returns to
idle state. If an OCCN is received, the call has succeeded, and idle state. If an OCCN is received, the call has succeeded, and
the session may now exchange data. the session may now exchange data.
established established
If a CDN is received, the session is cleaned up and returns to If a CDN is received, the session is cleaned up and returns to
idle state. Alternatively, if the LCCE chooses to terminate the idle state. Alternatively, if the LCCE chooses to terminate the
session, it sends a CDN to the LAC, cleans up the session, and session, it sends a CDN to the LAC, cleans up the session, and
moves the session to idle state. moves the session to idle state.
7.4.2 OCRQ Recipient (LAC) States 7.4.2 OCRQ Recipient (LAC) States
State Event Action New State State Event Action New State
----- ----- ------ --------- ----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call acceptable Place call
idle Receive OCRQ, Send CDN, idle idle Receive OCRQ, Send CDN, idle
not acceptable clean up not acceptable clean up
idle Receive OCRP Send CDN, idle idle Receive OCRP Send CDN, idle
clean up clean up
idle Receive OCCN, Clean up idle idle Receive OCCN, Clean up idle
CDN CDN
wait-cs-answer Call placement Send OCCN established wait-cs-answer Call placement Send OCCN established
successful successful
wait-cs-answer Call placement Send CDN, idle wait-cs-answer Call placement Send CDN, idle
failed clean up failed clean up
wait-cs-answer Receive OCRQ, Send CDN, idle wait-cs-answer Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up OCRP, OCCN clean up
established Receive OCRQ, Send CDN, idle established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up OCRP, OCCN clean up
wait-cs-answer, Receive CDN Clean up idle wait-cs-answer, Receive CDN Clean up idle
established established
wait-cs-answer, Local close Send CDN, idle wait-cs-answer, Local close Send CDN, idle
established request clean up established request clean up
The states associated with the LAC for outgoing calls are as follows: The states associated with the LAC for outgoing calls are as follows:
idle idle
If the OCRQ is received in error, respond with a CDN. Otherwise, If the OCRQ is received in error, respond with a CDN. Otherwise,
place the call, send an OCRP, and move to the wait-cs-answer place the call, send an OCRP, and move to the wait-cs-answer
state. state.
wait-cs-answer wait-cs-answer
If the call is not completed or a timer expires while waiting for If the call is not completed or a timer expires while waiting for
the call to complete, send a CDN with the appropriate error the call to complete, send a CDN with the appropriate error
condition set, and go to idle state. If a circuit-switched condition set, and go to idle state. If a circuit-switched
connection is established, send an OCCN indicating success, and go connection is established, send an OCCN indicating success, and go
to established state. to established state.
established established
If the LAC receives a CDN from the peer, the call MUST be released If the LAC receives a CDN from the peer, the call MUST be released
via appropriate mechanisms, and the session cleaned up. If the via appropriate mechanisms, and the session cleaned up. If the
call is disconnected because the circuit transitions to a call is disconnected because the circuit transitions to a
"disconnected" or "down" state, the LAC MUST send a CDN to the "disconnected" or "down" state, the LAC MUST send a CDN to the
peer and return to idle state. peer and return to idle state.
7.5 Termination of a Control Connection 7.5 Termination of a Control Connection
The termination of a control connection consists of either peer The termination of a control connection consists of either peer
issuing a StopCCN. The sender of this message SHOULD wait a full issuing a StopCCN. The sender of this message SHOULD wait a full
control message retransmission cycle (e.g. 1 + 2 + 4 + 8 ... seconds) control message retransmission cycle (e.g. 1 + 2 + 4 + 8 ... seconds)
for the acknowledgment of this message before releasing the control for the acknowledgment of this message before releasing the control
information associated with the control connection. The recipient of information associated with the control connection. The recipient of
this message should send an acknowledgment of the message to the this message should send an acknowledgment of the message to the
peer, then release the associated control information. peer, then release the associated control information.
When to release a control connection is an implementation issue and When to release a control connection is an implementation issue and
is not specified in this document. A particular implementation may is not specified in this document. A particular implementation may
use whatever policy is appropriate for determining when to release a use whatever policy is appropriate for determining when to release a
control connection. Some implementations may leave a control control connection. Some implementations may leave a control
connection open for a period of time or perhaps indefinitely after connection open for a period of time or perhaps indefinitely after
the last session for that control connection is cleared. Others may the last session for that control connection is cleared. Others may
choose to disconnect the control connection immediately after the choose to disconnect the control connection immediately after the
last call on the control connection disconnects. last call on the control connection disconnects.
8. Security Considerations 8. Security Considerations
This section addresses some of the security issues that L2TP This section addresses some of the security issues that L2TP
encounters in its operation. encounters in its operation.
8.1 Control Connection Endpoint and Message Security 8.1 Control Connection Endpoint and Message Security
The LCCEs may configure a shared secret (password) in order to The LCCEs may configure a shared secret (password) in order to
perform a mutual authentication of one another, and construct an perform a mutual authentication of one another, and construct an
authentication and integrity check of all arriving Control Messages. authentication and integrity check of all arriving Control Messages.
This mechanism is built-in to L2TPv3, and is described in section 4.3 This mechanism is built-in to L2TPv3, and is described in section 4.3
and in the definition of the Message Digest and Nonce AVPs in section and in the definition of the Message Digest and Nonce AVPs in section
5.4.3. 5.4.3.
This mechanism provides strong mutual peer authentication, and This mechanism provides strong mutual peer authentication, and
authentication and integrity checking for individual Control authentication and integrity checking for individual Control
Messages. Messages.
8.2 Data Channel Security 8.2 Data Channel Security
As described in section 4.1, the Assigned Cookie sent with each data As described in section 4.1, the Assigned Cookie sent with each data
packet MUST be selected in an unpredictable manner (with the added packet MUST be selected in an unpredictable manner (with the added
restriction that two same Cookie values not be selected within a restriction that two same Cookie values not be selected within a
short period of time for a given Session ID). short period of time for a given Session ID).
A 64-bit Cookie provides effective protection against a blind packet A 64-bit Cookie provides effective protection against a blind packet
insertion attack on a given PE. This is useful as a security feature insertion attack on a given PE. This is useful as a security feature
only within networks where sniffing and correlating packets between only within networks where sniffing and correlating packets between
L2TP nodes is considered impossible, though inserting IP packets L2TP nodes is considered impossible, though inserting IP packets
destined to an LCCE may be considered possible (and perhaps trivial destined to an LCCE may be considered possible (and perhaps trivial
by an individual armed with the proper hacking tools). In such cases, by an individual armed with the proper hacking tools). In such cases,
the Cookie provides an effective barrier against packet insertion the Cookie provides an effective barrier against packet insertion
into a VPN by enforcing that a given Session ID match the random 64 into a VPN by enforcing that a given Session ID match the random 64
bit Cookie. A 32 bit Cookie is vulnerable to brute force guessing at bit Cookie. A 32 bit Cookie is vulnerable to brute force guessing at
high packet rates, and as such should not be considered an effective high packet rates, and as such should not be considered an effective
barrier to insertion attacks (it still provides an additional barrier to insertion attacks (it still provides an additional
integrity check for the Session ID, as described in section 4.1). integrity check for the Session ID, as described in section 4.1).
The L2TPv3 Cookie MUST NOT be regarded as a substitute for packet- The L2TPv3 Cookie MUST NOT be regarded as a substitute for packet-
level security such as that of IPsec when operating over an open or level security such as that of IPsec when operating over an open or
untrusted network where packets may be sniffed and values correlated untrusted network where packets may be sniffed and values correlated
to spoofed packets. L2TPv3 does not attempt to provide data packet to spoofed packets. L2TPv3 does not attempt to provide data packet
encryption of any kind (without the aid of IPsec). encryption of any kind (without the aid of IPsec).
8.3 End-to-End Security 8.3 End-to-End Security
Protecting the L2TP packet stream with IPsec does, in turn, also Protecting the L2TP packet stream with IPsec does, in turn, also
protect the data within the tunneled session packets while protect the data within the tunneled session packets while
transported from one LCCE to the other. Such protection MUST NOT be transported from one LCCE to the other. Such protection MUST NOT be
considered a substitution for end-to-end security between considered a substitution for end-to-end security between
communicating hosts or applications. communicating hosts or applications.
8.4 L2TP and IPsec 8.4 L2TP and IPsec
When running over IP, IPsec [RFC2401] provides packet-level security When running over IP, IPsec [RFC2401] provides packet-level security
via ESP [RFC3193]. All L2TP control and data packets for a via ESP [RFC3193]. All L2TP control and data packets for a
particular control connection appear as homogeneous UDP or IP data particular control connection appear as homogeneous UDP or IP data
packets to the IPsec system. packets to the IPsec system.
In addition to IP transport security, IPsec defines a mode of In addition to IP transport security, IPsec defines a mode of
operation that allows tunneling of IP packets. The packet-level operation that allows tunneling of IP packets. The packet-level
encryption and authentication provided by IPsec tunnel mode and that encryption and authentication provided by IPsec tunnel mode and that
provided by L2TP secured with IPsec provide an equivalent level of provided by L2TP secured with IPsec provide an equivalent level of
security for these requirements. security for these requirements.
IPsec also defines access control features that are required of a IPsec also defines access control features that are required of a
compliant IPsec implementation. These features allow filtering of compliant IPsec implementation. These features allow filtering of
packets based upon network and transport layer characteristics such packets based upon network and transport layer characteristics such
as IP address, ports, etc. In the L2TP tunneling model, analogous as IP address, ports, etc. In the L2TP tunneling model, analogous
filtering is logically performed at the network layer above L2TP. filtering is logically performed at the network layer above L2TP.
These network layer access control features may be handled at an LCCE These network layer access control features may be handled at an LCCE
via vendor-specific authorization features based upon the via vendor-specific authorization features based upon the
authenticated user, or at the network layer itself by using IPsec authenticated user, or at the network layer itself by using IPsec
transport mode end-to-end between the communicating hosts. The transport mode end-to-end between the communicating hosts. The
requirements for access control mechanisms are not a part of the L2TP requirements for access control mechanisms are not a part of the L2TP
specification and as such are outside the scope of this document. specification and as such are outside the scope of this document.
8.5 Impact of L2TPv3 Features on RFC 3193 8.5 Impact of L2TPv3 Features on RFC 3193
[RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3
possesses identical characteristics to IPsec as L2TPv2 when running possesses identical characteristics to IPsec as L2TPv2 when running
on UDP/IP. When operating over IP directly, the principles defined on UDP/IP. When operating over IP directly, the principles defined
in [RFC3193] still apply, though references to UDP port selection (in in [RFC3193] still apply, though references to UDP port selection (in
particular Section 4 "IPsec Filtering details when protecting L2TP") particular Section 4 "IPsec Filtering details when protecting L2TP")
become far simpler as there are two less variable parameters (source become far simpler as there are two less variable parameters (source
and destination UDP ports) to be concerned with when applying and destination UDP ports) to be concerned with when applying
filters. Specific details for operating L2TPv3 with IPsec will be filters. Specific details for operating L2TPv3 with IPsec will be
specified in an update to [RFC3193]. specified in an update to [RFC3193].
9. Internationalization Considerations 9. Internationalization Considerations
The Host Name and Vendor Name AVPs are not internationalized. The The Host Name and Vendor Name AVPs are not internationalized. The
Vendor Name AVP, although intended to be human-readable, would seem Vendor Name AVP, although intended to be human-readable, would seem
to fit in the category of "globally visible names" [RFC3066] and so to fit in the category of "globally visible names" [RFC2277] and so
is represented in US-ASCII. is represented in US-ASCII.
The Preferred Language AVP is not mandatory. If an LCCE does not The Preferred Language AVP is not mandatory. If an LCCE does not
signify a language preference by the inclusion of this AVP in the signify a language preference by the inclusion of this AVP in the
SCCRQ or SCCRP, the Preferred Language AVP is unrecognized, or the SCCRQ or SCCRP, the Preferred Language AVP is unrecognized, or the
requested language is not supported by the peer LCCE, the default requested language is not supported by the peer LCCE, the default
language [RFC2277] MUST be used for all internationalized strings language [RFC2277] MUST be used for all internationalized strings
sent by the peer. sent by the peer.
10. IANA Considerations 10. IANA Considerations
This document defines a number of "magic" numbers to be maintained by This document defines a number of "magic" numbers to be maintained by
the IANA. This section explains the criteria to be used by the IANA the IANA. This section explains the criteria to be used by the IANA
to assign additional numbers in each of these lists. The following to assign additional numbers in each of these lists. The following
subsections describe the assignment policy for the namespaces defined subsections describe the assignment policy for the namespaces defined
elsewhere in this document. elsewhere in this document.
10.1 Control Message Attribute Value Pairs (AVPs) 10.1 Control Message Attribute Value Pairs (AVPs)
This number space is managed by IANA as per [RFC3438]. This number space is managed by IANA as per [RFC3438].
New AVPs requiring assignment in this document are defined in the New AVPs requiring assignment in this document are defined in the
"AVP Summary," Section 5.4, with the encoding "AVP-TBA-x," where "x" "AVP Summary," Section 5.4, with the encoding "AVP-TBA-x," where "x"
is 1, 2, 3... is 1, 2, 3...
A summary of the new AVPs follows: A summary of the new AVPs follows:
AVP-TBA-1 Message Digest AVP-TBA-1 Message Digest
AVP-TBA-2 Router ID, AVP-TBA-2 Router ID,
AVP-TBA-3 Assigned Control Connection ID AVP-TBA-3 Assigned Control Connection ID
AVP-TBA-4 Pseudowire Capabilities List AVP-TBA-4 Pseudowire Capabilities List
AVP-TBA-5 Local Session ID AVP-TBA-5 Local Session ID
AVP-TBA-6 Remote Session ID AVP-TBA-6 Remote Session ID
AVP-TBA-7 Assigned Cookie AVP-TBA-7 Assigned Cookie
AVP-TBA-8 Remote End ID AVP-TBA-8 Remote End ID
AVP-TBA-9 Application Code AVP-TBA-9 Application Code
AVP-TBA-10 Pseudowire Type AVP-TBA-10 Pseudowire Type
AVP-TBA-11 L2-Specific Sublayer AVP-TBA-11 L2-Specific Sublayer
AVP-TBA-12 Data Sequencing AVP-TBA-12 Data Sequencing
AVP-TBA-13 Circuit Status AVP-TBA-13 Circuit Status
AVP-TBA-14 Preferred Language AVP-TBA-14 Preferred Language
AVP-TBA-15 Control Message Authentication Nonce AVP-TBA-15 Control Message Authentication Nonce
10.2 Message Type AVP Values 10.2 Message Type AVP Values
This number space is managed by IANA as per [RFC3438]. There is one This number space is managed by IANA as per [RFC3438]. There is one
new message type, defined in section 3.1, necessary to be allocated new message type, defined in section 3.1, necessary to be allocated
for this specification: for this specification:
TBA-M1 (ACK) Explicit Acknowledgement TBA-M1 (ACK) Explicit Acknowledgement
10.3 Result Code AVP Values 10.3 Result Code AVP Values
This number space is managed by IANA as per [RFC3438]. This number space is managed by IANA as per [RFC3438].
New Result Code values for the CDN message are defined in section New Result Code values for the CDN message are defined in section
5.4. Following is a summary: 5.4. Following is a summary:
RC-TBA-1 - Session not established due to losing tie breaker. RC-TBA-1 - Session not established due to losing tie breaker.
RC-TBA-2 - Session not established due to unsupported PW type. RC-TBA-2 - Session not established due to unsupported PW type.
RC-TBA-3 - Session not established, sequencing required without valid RC-TBA-3 - Session not established, sequencing required without valid
L2-Specific Sublayer. L2-Specific Sublayer.
There are a few cases in Section 5 where these values are referred to There are a few cases in Section 5 where these values are referred to
directly within the document text with the RC-TBA-x format. The directly within the document text with the RC-TBA-x format. The
assigned values should be inserted within the text for these cases. assigned values should be inserted within the text for these cases.
10.3.2 Error Code Field Values 10.3.2 Error Code Field Values
This number space is managed by IANA as per [RFC3438]. This number space is managed by IANA as per [RFC3438].
10.4 AVP Header Bits 10.4 AVP Header Bits
There are four remaining reserved bits in the AVP header. Additional There are four remaining reserved bits in the AVP header. Additional
bits should only be assigned via a Standards Action [RFC2434]. bits should only be assigned via a Standards Action [RFC2434].
10.5 L2TP Control Message Header Bits 10.5 L2TP Control Message Header Bits
There are nine remaining reserved bits in the control message header. There are nine remaining reserved bits in the control message header.
Additional bits should only be assigned via a Standards Action Additional bits should only be assigned via a Standards Action
[RFC2434]. [RFC2434].
Care should be taken before using reserved bits 6 and 7 in the L2TPv3 Care should be taken before using reserved bits 6 and 7 in the L2TPv3
control message header since these bits have meaning for L2TPv2 data control message header since these bits have meaning for L2TPv2 data
messages. Using these two bits in L2TPv3 MAY trigger an unforeseen messages. Using these two bits in L2TPv3 MAY trigger an unforeseen
interoperability problem with L2TPv3 implementations based on L2TPv2. interoperability problem with L2TPv3 implementations based on L2TPv2.
Therefore, it is recommended that these two bits be utilized last, Therefore, it is recommended that these two bits be utilized last,
after the other reserved bits have been assigned roles. after the other reserved bits have been assigned roles.
10.6 Pseudowire Types 10.6 Pseudowire Types
The Pseudowire Type (PW Type, Section 5.4) is a two-octet value used The Pseudowire Type (PW Type, Section 5.4) is a two-octet value used
in the Pseudowire Type AVP and Pseudowire Capabilities List AVP in the Pseudowire Type AVP and Pseudowire Capabilities List AVP
defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review
[RFC2434], 32768 to 65535 by a First Come First Served policy [RFC2434], 32768 to 65535 by a First Come First Served policy
[RFC2434]. There are no specific pseudowire types assigned within [RFC2434]. There are no specific pseudowire types assigned within
this document. Each pseudowire-specific document MUST allocate its this document. Each pseudowire-specific document MUST allocate its
own PW types from IANA as necessary. own PW types from IANA as necessary.
10.7 Application Code 10.7 Application Code
The Application Code (Section 5.4) is a two-octet value used in the The Application Code (Section 5.4) is a two-octet value used in the
Application Code AVP. Value 0 is assigned to the base application Application Code AVP. Value 0 is assigned to the base application
defined in this document. Additional Application Codes may be defined in this document. Additional Application Codes may be
assigned by IETF Consensus [RFC2434]. assigned by IETF Consensus [RFC2434].
10.8 Circuit Status Bits 10.8 Circuit Status Bits
The Circuit Status (Section 5.4) field is a 16 bit mask, with the two The Circuit Status (Section 5.4) field is a 16 bit mask, with the two
high order bits assigned. high order bits assigned.
Bit 15 - A (Active) bit Bit 15 - A (Active) bit
Bit 16 - N (New) bit Bit 16 - N (New) bit
Additional bits may be assigned by IETF Consensus [RFC2434]. Additional bits may be assigned by IETF Consensus [RFC2434].
10.9 Default L2-Specific Sublayer bits 10.9 Default L2-Specific Sublayer bits
The Default L2 Specific Sublayer defined in Section 4.6 contains 8 The Default L2 Specific Sublayer defined in Section 4.6 contains 8
bits in the low-order portion of the header, two of which have been bits in the low-order portion of the header, one of which has been
assigned and 6 remain. assigned and 7 remain.
Bit 0 - P (Priority) bit Bit 1 - S (Sequence) bit
Bit 1 - S (Sequence) bit
Additional values may be assigned by IETF Consensus [RFC2434]. Additional values may be assigned by IETF Consensus [RFC2434].
10.10 L2-Specific Sublayer Type 10.10 L2-Specific Sublayer Type
The L2-Specific Sublayer Type is a 2 octet unsigned integer of which The L2-Specific Sublayer Type is a 2 octet unsigned integer of which
two values have been assigned. two values have been assigned.
0 - No L2-Specific Sublayer 0 - No L2-Specific Sublayer
1 - Default L2-Specific Sublayer present 1 - Default L2-Specific Sublayer present
Additional values may be assigned by Expert Review [RFC2434]. Additional values may be assigned by Expert Review [RFC2434].
10.11 Data Sequencing Level 10.11 Data Sequencing Level
The Data Sequencing Level is a 2 octet unsigned integer of which The Data Sequencing Level is a 2 octet unsigned integer of which
three values have been assigned. three values have been assigned.
0 - No incoming data packets require sequencing. 0 - No incoming data packets require sequencing.
1 - Only non-IP data packets require sequencing. 1 - Only non-IP data packets require sequencing.
2 - All incoming data packets require sequencing. 2 - All incoming data packets require sequencing.
Additional values may be assigned by Expert Review [RFC2434]. Additional values may be assigned by Expert Review [RFC2434].
13. Acknowledgments 13. Acknowledgments
Many of the protocol constructs were originally defined in, and the Many of the protocol constructs were originally defined in, and the
text of this document began with, RFC 2661, "L2TPv2". RFC 2661 text of this document began with, RFC 2661, "L2TPv2". RFC 2661
authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and
B. Palter. B. Palter.
The basic concept for L2TP and many of its protocol constructs were The basic concept for L2TP and many of its protocol constructs were
adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these
drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall,
W. Verthein, J. Taarud, W. Little, and G. Zorn. W. Verthein, J. Taarud, W. Little, and G. Zorn.
Danny Mcpherson and Suhail Nanji published the first "L2TP Service Danny Mcpherson and Suhail Nanji published the first "L2TP Service
Type" draft which defined the use of L2TP for tunneling of various L2 Type" draft which defined the use of L2TP for tunneling of various L2
payload types (initially, Ethernet and Frame Relay). payload types (initially, Ethernet and Frame Relay).
The team for splitting RFC 2661 into this base document and the The team for splitting RFC 2661 into this base document and the
companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill
Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided
very helpful review and comment. very helpful review and comment.
Some constructs of L2TPv3 were based in part on UTI (Universal Some constructs of L2TPv3 were based in part on UTI (Universal
Transport Interface), which was originally conceived by Peter Transport Interface), which was originally conceived by Peter
Lothberg and Tony Bates. Lothberg and Tony Bates.
Stewart Bryant and Simon Barber provided valuable input for the Stewart Bryant and Simon Barber provided valuable input for the
L2TPv3 over IP header. L2TPv3 over IP header.
Juha Heinanen provided helpful review, and input for the Application Juha Heinanen provided helpful review, and input for the Application
ID AVP. ID AVP.
Jan Vilhuber, Scott Fluhrer, David McGrew, and Scott Wainner Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, and Skip
contributed to the Control Message and Authentication Mechanism as Booth contributed to the Control Message and Authentication Mechanism
well as general discussions of security. as well as general discussions of security.
James Carlson and Thomas Narten provided very helpful review. James Carlson, Thomas Narten and Maria Dos Santos provided very
helpful review of the final text.
A number of people provided valuable input and effort for RFC2661, on A number of people provided valuable input and effort for RFC2661, on
which this document was based: which this document was based:
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
review at the 43rd IETF in Orlando, FL, which led to improvement of review at the 43rd IETF in Orlando, FL, which led to improvement of
the overall readability and clarity of RFC 2661. the overall readability and clarity of RFC 2661.
Thomas Narten provided a great deal of critical review and Thomas Narten provided a great deal of critical review and
formatting. He wrote the first version of the IANA Considerations formatting. He wrote the first version of the IANA Considerations
section. section.
Dory Leifer made valuable refinements to the protocol definition of Dory Leifer made valuable refinements to the protocol definition of
L2TP and contributed to the editing of early drafts leading to RFC L2TP and contributed to the editing of early drafts leading to RFC
2661. 2661.
Steve Cobb and Evan Caves redesigned the state machine tables. Steve Cobb and Evan Caves redesigned the state machine tables.
Barney Wolff provided a great deal of design input on the endpoint Barney Wolff provided a great deal of design input on the endpoint
authentication mechanism. authentication mechanism.
11. References 11. References
11.1 Normative References 11.1 Normative References
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996. Protocol (CHAP)", RFC 1994, August 1996.
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
January 1997. January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations section in RFCs", BCP 26, RFC 2434, IANA Considerations section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2661] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling [RFC2661] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling
Protocol (L2TP)", RFC 2661, August 1999. Protocol (L2TP)", RFC 2661, August 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W., and Willens, S., [RFC2865] Rigney, C., Rubens, A., Simpson, W., and Willens, S.,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", [RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
RFC 3066, January 2001. RFC 3066, January 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S.,
"Securing L2TP using IPsec", RFC 3193, November 2001. "Securing L2TP using IPsec", RFC 3193, November 2001.
11.2 Informative References 11.2 Informative References
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World", Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1. Prentice Hall, March 1995, ISBN 0-13-061466-1.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
04/16/1992 04/16/1992
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also: RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html. http://www.iana.org/numbers.html.
[RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness [RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994 Recommendations for Security", RFC 1750, December 1994
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997 Message Authentication", RFC 2104, February 1997
[RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S., [RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S.,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, April 1997. RFC 2138, April 1997.
[RFC2341] Valencia, A., Littlewood, M., and Kolar, T., [RFC2341] Valencia, A., Littlewood, M., and Kolar, T.,
"Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341,
May 1998. May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion
Control", RFC 2581, April 1999 Control", RFC 2581, April 1999
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999. RFC 2637, July 1999.
[RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory [RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory
Tunneling via RADIUS", RFC 2809, April 2000. Tunneling via RADIUS", RFC 2809, April 2000.
[RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R.,
"Layer Two Tunneling Protocol (L2TP) over Frame Relay", "Layer Two Tunneling Protocol (L2TP) over Frame Relay",
RFC 3070, February 2001. RFC 3070, February 2001.
[RFC3355] Singh, A., Turner, R., Tio, R., Nanji, S., "Layer Two [RFC3355] Singh, A., Turner, R., Tio, R., Nanji, S., "Layer Two
Tunnelling Protocol (L2TP) Over ATM Adaptation Tunnelling Protocol (L2TP) Over ATM Adaptation
Layer 5 (AAL5)", RFC 3355, August 2002 Layer 5 (AAL5)", RFC 3355, August 2002
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The
Protocols", Addison-Wesley Publishing Company, Inc., Protocols", Addison-Wesley Publishing Company, Inc.,
March 1996, ISBN 0-201-63346-9. March 1996, ISBN 0-201-63346-9.
12. Editors' Addresses 12. Editors' Addresses
Jed Lau Jed Lau
cisco Systems cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
jedlau@cisco.com jedlau@cisco.com
W. Mark Townsley W. Mark Townsley
cisco Systems cisco Systems
mark@townsley.net mark@townsley.net
Ignacio Goyret Ignacio Goyret
Lucent Technologies Lucent Technologies
igoyret@lucent.com igoyret@lucent.com
Appendix A: Control Slow Start and Congestion Avoidance Appendix A: Control Slow Start and Congestion Avoidance
Although each side has indicated the maximum size of its receive Although each side has indicated the maximum size of its receive
window, it is recommended that a slow start and congestion avoidance window, it is recommended that a slow start and congestion avoidance
method be used to transmit control packets. The methods described method be used to transmit control packets. The methods described
here are based upon the TCP congestion avoidance algorithm as here are based upon the TCP congestion avoidance algorithm as
described in section 21.6 of TCP/IP Illustrated, Volume I, by W. described in section 21.6 of TCP/IP Illustrated, Volume I, by W.
Richard Stevens [STEVENS] (this algorithm is also described in Richard Stevens [STEVENS] (this algorithm is also described in
[RFC2581]). [RFC2581]).
Slow start and congestion avoidance make use of several variables. Slow start and congestion avoidance make use of several variables.
The congestion window (CWND) defines the number of packets a sender The congestion window (CWND) defines the number of packets a sender
may send before waiting for an acknowledgment. The size of CWND may send before waiting for an acknowledgment. The size of CWND
expands and contracts as described below. Note, however, that CWND expands and contracts as described below. Note, however, that CWND
is never allowed to exceed the size of the advertised window obtained is never allowed to exceed the size of the advertised window obtained
from the Receive Window AVP. (In the text below, it is assumed any from the Receive Window AVP. (In the text below, it is assumed any
increase will be limited by the Receive Window Size.) The variable increase will be limited by the Receive Window Size.) The variable
SSTHRESH determines when the sender switches from slow start to SSTHRESH determines when the sender switches from slow start to
congestion avoidance. Slow start is used while CWND is less than congestion avoidance. Slow start is used while CWND is less than
SSHTRESH. SSHTRESH.
A sender starts out in the slow start phase. CWND is initialized to A sender starts out in the slow start phase. CWND is initialized to
one packet, and SSHTRESH is initialized to the advertised window one packet, and SSHTRESH is initialized to the advertised window
(obtained from the Receive Window AVP). The sender then transmits (obtained from the Receive Window AVP). The sender then transmits
one packet and waits for its acknowledgment (either explicit or one packet and waits for its acknowledgment (either explicit or
piggybacked). When the acknowledgment is received, the congestion piggybacked). When the acknowledgment is received, the congestion
window is incremented from one to two. During slow start, CWND is window is incremented from one to two. During slow start, CWND is
increased by one packet each time an ACK (explicit ACK message or increased by one packet each time an ACK (explicit ACK message or
piggybacked) is received. Increasing CWND by one on each ACK has the piggybacked) is received. Increasing CWND by one on each ACK has the
effect of doubling CWND with each round trip, resulting in an effect of doubling CWND with each round trip, resulting in an
exponential increase. When the value of CWND reaches SSHTRESH, the exponential increase. When the value of CWND reaches SSHTRESH, the
slow start phase ends and the congestion avoidance phase begins. slow start phase ends and the congestion avoidance phase begins.
During congestion avoidance, CWND expands more slowly. Specifically, During congestion avoidance, CWND expands more slowly. Specifically,
it increases by 1/CWND for every new ACK received. That is, CWND is it increases by 1/CWND for every new ACK received. That is, CWND is
increased by one packet after CWND new ACKs have been received. increased by one packet after CWND new ACKs have been received.
Window expansion during the congestion avoidance phase is effectively Window expansion during the congestion avoidance phase is effectively
linear, with CWND increasing by one packet each round trip. linear, with CWND increasing by one packet each round trip.
When congestion occurs (indicated by the triggering of a When congestion occurs (indicated by the triggering of a
retransmission) one-half of the CWND is saved in SSTHRESH, and CWND retransmission) one-half of the CWND is saved in SSTHRESH, and CWND
is set to one. The sender then reenters the slow start phase. is set to one. The sender then reenters the slow start phase.
Appendix B: Control Message Examples Appendix B: Control Message Examples
B.1: Lock-Step Control Connection Establishment B.1: Lock-Step Control Connection Establishment
In this example, an LCCE establishes a control connection, with the In this example, an LCCE establishes a control connection, with the
exchange involving each side alternating in sending messages. This exchange involving each side alternating in sending messages. This
example shows the final acknowledgment explicitly sent within an ACK example shows the final acknowledgment explicitly sent within an ACK
message. An alternative would be to piggyback the acknowledgment message. An alternative would be to piggyback the acknowledgment
within a message sent as a reply to the ICRQ or OCRQ that will likely within a message sent as a reply to the ICRQ or OCRQ that will likely
follow from the side that initiated the control connection. follow from the side that initiated the control connection.
LCCE A LCCE B LCCE A LCCE B
------ ------ ------ ------
SCCRQ -> SCCRQ ->
Nr: 0, Ns: 0 Nr: 0, Ns: 0
<- SCCRP <- SCCRP
Nr: 1, Ns: 0 Nr: 1, Ns: 0
SCCCN -> SCCCN ->
Nr: 1, Ns: 1 Nr: 1, Ns: 1
<- ACK <- ACK
Nr: 2, Ns: 1 Nr: 2, Ns: 1
B.2: Lost Packet with Retransmission B.2: Lost Packet with Retransmission
An existing control connection has a new session requested by LCCE A. An existing control connection has a new session requested by LCCE A.
The ICRP is lost and must be retransmitted by LCCE B. Note that loss The ICRP is lost and must be retransmitted by LCCE B. Note that loss
of the ICRP has two effects: It not only keeps the upper level state of the ICRP has two effects: It not only keeps the upper level state
machine from progressing, but also keeps LCCE A from seeing a timely machine from progressing, but also keeps LCCE A from seeing a timely
lower level acknowledgment of its ICRQ. lower level acknowledgment of its ICRQ.
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LCCE A's timer started first, so fires first)
LCCE A LCCE B
------ ------
ICRQ -> ICRQ ->
Nr: 1, Ns: 2 Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(Realizing that it has already seen this packet, (pause; LCCE A's timer started first, so fires first)
LCCE B discards the packet and sends an ACK message)
<- ACK ICRQ ->
Nr: 3, Ns: 2 Nr: 1, Ns: 2
(LCCE B's retransmit timer fires) (Realizing that it has already seen this packet,
LCCE B discards the packet and sends an ACK message)
<- ICRP <- ACK
Nr: 3, Ns: 1 Nr: 3, Ns: 2
ICCN ->
Nr: 2, Ns: 3
<- ACK (LCCE B's retransmit timer fires)
Nr: 4, Ns: 2
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ACK
Nr: 4, Ns: 2
Appendix C: Processing Sequence Numbers Appendix C: Processing Sequence Numbers
The Default L2-Specific Sublayer, defined in Section 4.6, provides a The Default L2-Specific Sublayer, defined in Section 4.6, provides a
24-bit field for sequencing of data packets within an L2TP session. 24-bit field for sequencing of data packets within an L2TP session.
L2TP data packets are never retransmitted, so this sequence is used L2TP data packets are never retransmitted, so this sequence is used
only to detect packet order, duplicate packets, or lost packets. only to detect packet order, duplicate packets, or lost packets.
The 24-bit Sequence Number field of the Default L2-Specific Sublayer The 24-bit Sequence Number field of the Default L2-Specific Sublayer
contains a packet sequence number for the associated session. Each contains a packet sequence number for the associated session. Each
sequenced data packet that is sent must contain the sequence number, sequenced data packet that is sent must contain the sequence number,
incremented by one, of the previous sequenced packet sent on a given incremented by one, of the previous sequenced packet sent on a given
L2TP session. Upon receipt, any packet with a sequence number equal L2TP session. Upon receipt, any packet with a sequence number equal
to or greater than the current expected packet (the last received in- to or greater than the current expected packet (the last received
order packet plus one) should be considered "new" and accepted. All in-order packet plus one) should be considered "new" and accepted.
other packets are considered "old" or "duplicate" and discarded. All other packets are considered "old" or "duplicate" and discarded.
Note that the 24-bit sequence number space includes zero as a valid Note that the 24-bit sequence number space includes zero as a valid
sequence number (as such, it may be implemented with a masked 32-bit sequence number (as such, it may be implemented with a masked 32-bit
counter if desired). All new sessions MUST begin sending sequence counter if desired). All new sessions MUST begin sending sequence
numbers at zero. numbers at zero.
Larger or smaller sequence number fields are possible with L2TP if an Larger or smaller sequence number fields are possible with L2TP if an
alternative format to the Default L2-Specific Sublayer defined in alternative format to the Default L2-Specific Sublayer defined in
this document is used. While 24 bits may be adequate in a number of this document is used. While 24 bits may be adequate in a number of
circumstances, a larger sequence number space will be less circumstances, a larger sequence number space will be less
susceptible to sequence number wrapping problems for very high susceptible to sequence number wrapping problems for very high
session data rates across long dropout periods. The sequence number session data rates across long dropout periods. The sequence number
processing recommendations below should hold for any size sequence processing recommendations below should hold for any size sequence
number field. number field.
When detecting whether a packet sequence number is "greater" or When detecting whether a packet sequence number is "greater" or
"less" than a given sequence number value, wrapping of the sequence "less" than a given sequence number value, wrapping of the sequence
number must be considered. This is typically accomplished by keeping number must be considered. This is typically accomplished by keeping
a window of sequence numbers beyond the current expected sequence a window of sequence numbers beyond the current expected sequence
number for determination of whether a packet is "new" or not. The number for determination of whether a packet is "new" or not. The
window may be sized based on the link speed and sequence number space window may be sized based on the link speed and sequence number space
and SHOULD be configurable with a default equal to one half the size and SHOULD be configurable with a default equal to one half the size
of the available number space (e.g. 2^(n-1), where n is the number of of the available number space (e.g. 2^(n-1), where n is the number of
bits available in the sequence number). bits available in the sequence number).
Upon receipt, packets which exactly match the expected sequence Upon receipt, packets which exactly match the expected sequence
number are processed immediately and the next expected sequence number are processed immediately and the next expected sequence
number incremented. Packets that fall within the window for new number incremented. Packets that fall within the window for new
packets may either be processed immediately and the next expected packets may either be processed immediately and the next expected
sequence number updated to one plus that received in the new packet, sequence number updated to one plus that received in the new packet,
or held for a very short period of time in hopes of receiving the or held for a very short period of time in hopes of receiving the
missing packet(s). This 'very short period' should be configurable, missing packet(s). This 'very short period' should be configurable,
with a default corresponding to a time lapse which is at least an with a default corresponding to a time lapse which is at least an
order of magnitude less than the retransmission timeout periods of order of magnitude less than the retransmission timeout periods of
higher layer protocols such as TCP. higher layer protocols such as TCP.
For typical transient packet mis-orderings, dropping out-of-order For typical transient packet mis-orderings, dropping out-of-order
packets alone should suffice and generally requires far less packets alone should suffice and generally requires far less
resources than actively reordering packets within L2TP. An exception resources than actively reordering packets within L2TP. An exception
is a case where a pair of packet fragments are persistently is a case where a pair of packet fragments are persistently
retransmitted and sent out-of-order. For example, if an IP packet has retransmitted and sent out-of-order. For example, if an IP packet has
been fragmented into a very small packet followed by a very large been fragmented into a very small packet followed by a very large
packet before being tunneled by L2TP, it is possible (though packet before being tunneled by L2TP, it is possible (though
admittedly wrong) that the two resulting L2TP packets may be admittedly wrong) that the two resulting L2TP packets may be
consistently mis-ordered by the PSN in transit between L2TP nodes. If consistently mis-ordered by the PSN in transit between L2TP nodes. If
sequence numbers were being enforced at the receiving node without sequence numbers were being enforced at the receiving node without
any buffering of out-of-order packets, then the fragmented IP packet any buffering of out-of-order packets, then the fragmented IP packet
may never reach its destination. It may be worth noting here that may never reach its destination. It may be worth noting here that
this condition is true for any tunneling mechanism of IP packets this condition is true for any tunneling mechanism of IP packets
which include sequence number checking on receipt (i.e. GRE which include sequence number checking on receipt (i.e. GRE
[RFC2890]). [RFC2890]).
Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only
non-IP data packets require sequencing) allows IP data packets being non-IP data packets require sequencing) allows IP data packets being
tunneled by L2TP to not utilize sequence numbers, while utilizing tunneled by L2TP to not utilize sequence numbers, while utilizing
sequence numbers and enforcing packet order for any remaining non-IP sequence numbers and enforcing packet order for any remaining non-IP
data packets. Depending on the requirements of the link-layer being data packets. Depending on the requirements of the link-layer being
tunneled, and the network data traversing the data-link, this is tunneled, and the network data traversing the data-link, this is
sufficient in many cases to enforce packet order on frames which sufficient in many cases to enforce packet order on frames which
require it (such as end-to-end data-link control messages), while not require it (such as end-to-end data-link control messages), while not
on IP packets which are known to be resilient to packet reordering. on IP packets which are known to be resilient to packet reordering.
If a large number of packets (e.g. more than one new packet window) If a large number of packets (e.g. more than one new packet window)
are dropped due to an extended outage, or loss of sequence number are dropped due to an extended outage, or loss of sequence number
state on one side of the connection (perhaps as part of a forwarding state on one side of the connection (perhaps as part of a forwarding
plane reset or failover to a standby node), it is possible that a plane reset or failover to a standby node), it is possible that a
large number of packets will be sent in-order, but be wrongly large number of packets will be sent in-order, but be wrongly
detected by the peer as out-of-order. This can be generally detected by the peer as out-of-order. This can be generally
characterized for a window size, w, sequence number space, s, and characterized for a window size, w, sequence number space, s, and
number of packets lost in transit between L2TP endpoints, p, as number of packets lost in transit between L2TP endpoints, p, as
follows: follows:
If s > p > w, then an additional (s - p) packets that were otherwise If s > p > w, then an additional (s - p) packets that were otherwise
received in-order, will be incorrectly classified as out-of-order and received in-order, will be incorrectly classified as out-of-order and
dropped. Thus, for a sequence number space, s = 128, window size, w = dropped. Thus, for a sequence number space, s = 128, window size, w =
64, and number of lost packets, p = 70; 128 - 70 = 58 additional 64, and number of lost packets, p = 70; 128 - 70 = 58 additional
packets would be dropped after the outage until the sequence number packets would be dropped after the outage until the sequence number
wrapped back to the current expected next sequence number. wrapped back to the current expected next sequence number.
To mitigate this additional packet loss, one MUST inspect the To mitigate this additional packet loss, one MUST inspect the
sequence numbers of packets dropped due to being classified as "old" sequence numbers of packets dropped due to being classified as "old"
and reset the expected sequence number accordingly. This may be and reset the expected sequence number accordingly. This may be
accomplished by counting the number of "old" packets dropped that accomplished by counting the number of "old" packets dropped that
were in sequence among themselves and upon reaching a threshold, were in sequence among themselves and upon reaching a threshold,
resetting the next expected sequence number to that seen in the resetting the next expected sequence number to that seen in the
arriving data packets. Packet timestamps may also be used as an arriving data packets. Packet timestamps may also be used as an
indicator to reset the expected sequence number by detecting a period indicator to reset the expected sequence number by detecting a period
of time over which "old" packets have been received in-sequence. The of time over which "old" packets have been received in-sequence. The
ideal thresholds will vary depending on link speed, sequence number ideal thresholds will vary depending on link speed, sequence number
space, and link tolerance to out-of-order packets, and MUST be space, and link tolerance to out-of-order packets, and MUST be
configurable. configurable.
Appendix D: Intellectual Property Notice Appendix D: Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
Appendix E: Full Copyright Statement Appendix E: Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 774 change blocks. 
3113 lines changed or deleted 3108 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/