< draft-ietf-l2tpext-l2tp-base-02.txt   draft-ietf-l2tpext-l2tp-base-03.txt >
Network Working Group J. Lau Network Working Group J. Lau
Internet-Draft M. Townsley Internet-Draft M. Townsley
Category: Standards Track A. Valencia Category: Standards Track A. Valencia
<draft-ietf-l2tpext-l2tp-base-02.txt> G. Zorn <draft-ietf-l2tpext-l2tp-base-03.txt> G. Zorn
cisco Systems cisco Systems
I. Goyret I. Goyret
Lucent Technologies Lucent Technologies
G. Pall G. Pall
Microsoft Corporation Microsoft Corporation
A. Rubens A. Rubens
Nexthop Nexthop
B. Palter B. Palter
Redback Networks Redback Networks
March 2002 June 2002
Layer Two Tunneling Protocol (Version 3) "L2TPv3" Layer Two Tunneling Protocol (Version 3) "L2TPv3"
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 (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document describes the Layer Two Tunneling Protocol (L2TP). This document describes the Layer Two Tunneling Protocol (L2TP).
L2TP tunnels Layer 2 packets across an intervening network in a way L2TP tunnels Layer 2 packets across an intervening network in a way
that is as transparent as possible to both end-users and that is as transparent as possible to both end users and
applications. applications.
Acknowledgments Acknowledgments
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 are adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these
A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall,
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 multiple Type" draft which defined the use of L2TP for tunneling of multiple
L2 payload types. This step led to the eventual creation of this L2 payload types. This step led to the eventual creation of this
document and the modularization of L2TP and PPP tunneling with L2TP. document and the modularization of L2TP and PPP tunneling with L2TP.
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.
Stewart Bryant and Simon Barber provided input for the new L2TPv3 Stewart Bryant and Simon Barber provided input for the new L2TPv3
over IP header. over IP header.
This document was based upon RFC 2661, for which a number of people This document was based upon RFC 2661, for which a number of people
provided valuable input and effort: provided valuable input and effort:
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, formatting, Thomas Narten provided a great deal of critical review and
and wrote the IANA Considerations section. formatting. He originally wrote the IANA Considerations 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 L2TP and contributed to the editing of early drafts leading to RFC
RFC2661. 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.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 5 1. Introduction............................................. 5
1.1 Changes from RFC 2661................................ 5 1.1 Changes from RFC 2661................................ 5
1.2 Specification of Requirements........................ 6 1.2 Specification of Requirements........................ 6
1.3 Terminology.......................................... 6 1.3 Terminology.......................................... 6
2. Topology................................................. 9 2. Topology................................................. 9
3. Protocol Overview........................................ 10 3. Protocol Overview........................................ 11
3.1 Control Message Types................................ 11 3.1 Control Message Types................................ 12
3.2 L2TP Header Formats.................................. 12 3.2 L2TP Header Formats.................................. 13
3.2.1 L2TP Control Message Header..................... 12 3.2.1 L2TP Control Message Header..................... 13
3.2.2 L2TP Data Message............................... 14 3.2.2 L2TP Data Message............................... 14
3.3 Control Connection Management........................ 15 3.3 Control Connection Management........................ 15
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................................ 17 3.4.3 Session Teardown................................ 17
4. Protocol Operation....................................... 17 4. Protocol Operation....................................... 17
4.1 L2TP Over Specific Packet Switched Networks (PSNs)... 17 4.1 L2TP Over Specific Packet-Switched Networks (PSN).... 17
4.1.1 L2TP over IP.................................... 18 4.1.1 L2TP over IP.................................... 18
4.1.2 L2TP over UDP................................... 19 4.1.2 L2TP over UDP................................... 20
4.1.3 IP Fragmentation Issues......................... 21 4.1.3 IP Fragmentation Issues......................... 22
4.2 Reliable Delivery of Control Messages................ 21 4.2 Reliable Delivery of Control Messages................ 22
4.3 Tunnel Endpoint Authentication....................... 24 4.3 Control Connection Authentication.................... 24
4.4 Keepalive (Hello).................................... 24 4.4 Keepalive (Hello).................................... 25
4.5 Forwarding Session Data Frames....................... 25 4.5 Forwarding Session Data Frames....................... 25
4.6 Default L2-Specific Sublayer.......................... 25 4.6 Default PW Control Encapsulation..................... 26
4.6.1 Sequencing Data Packets.......................... 27 4.6.1 Sequencing Data Packets......................... 27
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.................................. 28
4.7.2 L2TPv3 over UDP................................. 28 4.7.2 L2TPv3 over UDP................................. 28
4.7.3 Automatic L2TPv2 Fallback....................... 28 4.7.3 Automatic L2TPv2 Fallback....................... 28
5. Control Message Attribute Value Pairs.................... 29 5. Control Message Attribute Value Pairs.................... 29
5.1 AVP Format........................................... 29 5.1 AVP Format........................................... 29
5.2 Mandatory AVPs....................................... 30 5.2 Mandatory AVPs....................................... 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 AVPs Applicable to All Control Messages......... 33 5.4.1 AVPs Applicable to All Control Messages......... 33
5.4.2 Result and Error Codes.......................... 35 5.4.2 Result and Error Codes.......................... 35
5.4.3 Control Connection Management AVPs.............. 37 5.4.3 Control Connection Management AVPs.............. 37
5.4.4 Session Management AVPs......................... 43 5.4.4 Session Management AVPs......................... 42
5.4.5 Circuit Status AVPs............................. 52 5.4.5 Circuit Status AVPs............................. 50
6. Control Connection Protocol Specification................ 53 6. Control Connection Protocol Specification................ 52
6.1 Start-Control-Connection-Request (SCCRQ)............. 53 6.1 Start-Control-Connection-Request (SCCRQ)............. 52
6.2 Start-Control-Connection-Reply (SCCRP)............... 53 6.2 Start-Control-Connection-Reply (SCCRP)............... 52
6.3 Start-Control-Connection-Connected (SCCCN)........... 54 6.3 Start-Control-Connection-Connected (SCCCN)........... 53
6.4 Stop-Control-Connection-Notification (StopCCN)....... 54 6.4 Stop-Control-Connection-Notification (StopCCN)....... 53
6.5 Hello (HELLO)........................................ 55 6.5 Hello (HELLO)........................................ 54
6.6 Incoming-Call-Request (ICRQ)......................... 55 6.6 Incoming-Call-Request (ICRQ)......................... 54
6.7 Incoming-Call-Reply (ICRP)........................... 55 6.7 Incoming-Call-Reply (ICRP)........................... 55
6.8 Incoming-Call-Connected (ICCN)....................... 56 6.8 Incoming-Call-Connected (ICCN)....................... 55
6.9 Outgoing-Call-Request (OCRQ)......................... 56 6.9 Outgoing-Call-Request (OCRQ)......................... 56
6.10 Outgoing-Call-Reply (OCRP).......................... 57 6.10 Outgoing-Call-Reply (OCRP).......................... 57
6.11 Outgoing-Call-Connected (OCCN)...................... 58 6.11 Outgoing-Call-Connected (OCCN)...................... 57
6.12 Call-Disconnect-Notify (CDN)........................ 58 6.12 Call-Disconnect-Notify (CDN)........................ 58
6.13 WAN-Error-Notify (WEN).............................. 59 6.13 WAN-Error-Notify (WEN).............................. 58
6.14 Set-Link-Info (SLI).................................. 59 6.14 Set-Link-Info (SLI)................................. 58
7. Control Connection State Machines........................ 59 7. Control Connection State Machines........................ 59
7.1 Malformed Control Messages........................... 59 7.1 Malformed Control Messages........................... 59
7.2 Timing Considerations................................ 60 7.2 Timing Considerations................................ 60
7.3 Control Connection States............................ 61 7.3 Control Connection States............................ 60
7.4 Incoming Calls....................................... 62 7.4 Incoming Calls....................................... 62
7.4.1 ICRQ Sender States.............................. 63 7.4.1 ICRQ Sender States.............................. 63
7.4.2 ICRQ Recipient States........................... 65 7.4.2 ICRQ Recipient States........................... 64
7.5 Outgoing Calls....................................... 66 7.5 Outgoing Calls....................................... 65
7.5.1 OCRQ Sender States.............................. 66 7.5.1 OCRQ Sender States.............................. 65
7.5.2 OCRQ Recipient (LAC) States..................... 67 7.5.2 OCRQ Recipient (LAC) States..................... 67
7.6 Termination of a Control Connection.................. 68 7.6 Termination of a Control Connection.................. 68
8. Security Considerations.................................. 69 8. Security Considerations.................................. 68
8.1 Control Connection Endpoint Security................. 69 8.1 Control Connection Endpoint Security................. 68
8.2 Packet Level Security................................ 70 8.2 Packet-Level Security................................ 69
8.3 End-to-End Security.................................. 70 8.3 End-to-End Security.................................. 69
8.4 L2TP and IPsec....................................... 70 8.4 L2TP and IPsec....................................... 69
8.5 Impact of L2TPv3 Features on RFC 3193................ 71 8.5 Impact of L2TPv3 Features on RFC 3193................ 70
9. IANA Considerations...................................... 71 9. IANA Considerations...................................... 70
9.1 AVP Attributes....................................... 71 9.1 AVP Attributes....................................... 70
9.2 Message Type AVP Values.............................. 71 9.2 Message Type AVP Values.............................. 71
9.3 Result Code AVP Values............................... 71 9.3 Result Code AVP Values............................... 71
9.3.1 Result Code Field Values........................ 71 9.3.1 Result Code Field Values........................ 71
9.3.2 Error Code Field Values......................... 72 9.3.2 Error Code Field Values......................... 71
9.4 AVP Header Bits...................................... 72 9.4 AVP Header Bits...................................... 71
9.5 L2TP Control Message Header Bits..................... 71
10. References.............................................. 72 10. References.............................................. 72
11. Editors' Addresses...................................... 74 11. Editors' Addresses...................................... 74
Appendix A: Control Slow Start and Congestion Avoidance...... 74 Appendix A: Control Slow Start and Congestion Avoidance...... 74
Appendix B: Control Message Examples......................... 75 Appendix B: Control Message Examples......................... 75
Appendix C: Intellectual Property Notice..................... 77 Appendix C: Intellectual Property Notice..................... 77
Appendix D: Full Copyright Statement......................... 77
1. Introduction 1. Introduction
The Layer Two Tunneling Protocol (L2TP) provides a dynamic tunneling The Layer Two Tunneling Protocol (L2TP) provides a dynamic tunneling
mechanism for multiple Layer 2 (L2) circuits across a packet-oriented mechanism for multiple Layer 2 (L2) circuits across a packet-oriented
data network. L2TP, as originally defined in RFC 2661, describes a data network. L2TP, as originally defined in RFC 2661, is a standard
standard method for tunneling PPP sessions. L2TP has since been method for tunneling PPP sessions. L2TP has since been adopted for
adopted for tunneling a number of other L2 protocols. In order to tunneling a number of other L2 protocols. In order to provide
provide greater modularity, this document describes the base L2TP greater modularity, this document describes the base L2TP protocol,
protocol, independent of the L2 payload that is being tunneled. independent of the L2 payload that is being tunneled.
The base L2TP protocol consists of (1) the control protocol for The base L2TP protocol consists of (1) the control protocol for
dynamic creation, maintenance, and teardown of L2TP sessions, and (2) dynamic creation, maintenance, and teardown of L2TP sessions, and (2)
the L2TP data encapsulation to multiplex and demultiplex L2 data the L2TP data encapsulation to multiplex and demultiplex L2 data
streams between IP-connected L2TP nodes. streams between two L2TP peers.
1.1 Changes from RFC 2661 1.1 Changes from RFC 2661
Most of the protocol constructs described in this document are Most 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, interoperability experience achieve a healthy balance between code, interoperability experience
with RFC 2661, and a thoughtful and directed evolution of the with RFC 2661, and a thoughtful and directed evolution of the
protocol as it is applied to new tasks. protocol as it is applied to new 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 control message header. the value in the Version field of an L2TP control message header.
(L2F is defined as "version 1".) At times, L2TP as defined in this (L2F is defined as "version 1".) At times, L2TP as defined in this
document will be referred to as "L2TPv3". Otherwise, the acronym document will be referred to as "L2TPv3". Otherwise, the acronym
"L2TP" will refer to L2TPv3 or L2TP in general. "L2TP" will refer to L2TPv3 or L2TP in general.
Notable differences between L2TPv2 and L2TPv3 include: Notable differences between L2TPv2 and L2TPv3 include the following:
- 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. Session ID and Control Connection ID, respectively.
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].
skipping to change at page 6, line 39 skipping to change at page 6, line 42
"active" state. A call may be dynamically established through "active" state. A call may be dynamically established through
signaling properties (e.g. an incoming or outgoing call through signaling properties (e.g. an incoming or outgoing call through
the PSTN) or statically configured (e.g. provisioning a VC on an the PSTN) or statically configured (e.g. provisioning a VC on an
interface). A call is defined by its properties (e.g. type of interface). A call is defined by its properties (e.g. type of
call, called number, etc.) and its data traffic. (See also: call, called number, etc.) and its data traffic. (See also:
Circuit, Session, Incoming Call, Outgoing Call, Outgoing Call Circuit, Session, Incoming Call, Outgoing Call, Outgoing Call
Request.) Request.)
CHAP CHAP
Challenge Handshake Authentication Protocol [RFC1994], a point- Challenge Handshake Authentication Protocol [RFC1994], a point-to-
to-point cryptographic challenge/response authentication protocol point cryptographic challenge/response authentication protocol in
in which the cleartext password is not passed over the line. which the cleartext password is not passed over the line.
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 PVC connections. A circuit may be virtual in nature (e.g. an ATM PVC
or an L2TP session), or it may have direct correlation to a or an L2TP session), or it may have direct correlation to a
physical layer (e.g. an RS-232 serial line). Circuits may be physical layer (e.g. an RS-232 serial line). Circuits may be
statically configured with a relatively long-lived uptime, or statically configured with a relatively long-lived uptime, or
dynamically established with some type of control channel dynamically established with some type of control channel
governing the establishment, maintenance, and teardown of the governing the establishment, maintenance, and teardown of the
skipping to change at page 7, line 38 skipping to change at page 7, line 41
The channel of L2TP-encapsulated L2 traffic that passes between The channel of L2TP-encapsulated L2 traffic that passes between
two LCCEs, utilizing a specific data encapsulation method. L2TP two LCCEs, utilizing a specific data encapsulation method. L2TP
defines one base encapsulation method for L2 traffic, although defines one base encapsulation method for L2 traffic, although
others may be used as well. (See also: Control Connection, Data others may be used as well. (See also: Control Connection, Data
Message.) Message.)
Dominant LCCE Dominant LCCE
The LCCE that either solely initiated establishment of a control The LCCE that either solely initiated establishment of a control
connection or won the tie breaker during control connection connection or won the tie-breaker during control connection
establishment. (See also: LCCE, Section 5.4.3.) establishment. (See also: LCCE, Section 5.4.3.)
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 (e.g. over a PSTN), or it may have been triggered by a local event (e.g.
interesting traffic routed to a virtual interface). An incoming interesting traffic routed to a virtual interface). An incoming
call that needs to be tunneled (as determined by the LAC) results call that needs to be tunneled (as determined by the LAC) results
in the generation of an L2TP ICRQ message. (See also: Call, in the generation of an L2TP ICRQ message. (See also: Call,
skipping to change at page 8, line 41 skipping to change at page 8, line 42
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 for the LAC in placing the call, contains specific information for the LAC in placing the call,
information that is typically not known a priori by the LAC. (See information that is typically not known a priori by the LAC. (See
also: Call, Incoming Call, Outgoing Call.) also: Call, Incoming Call, Outgoing Call.)
Packet-Switched Network (PSN) Packet-Switched Network (PSN)
A network layer that uses packet-switching technology for data A network layer that uses packet-switching technology for data
delivery (e.g. an IP network). delivery. This layer is principally IP. Other examples include
MPLS, FR, 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 far LCCE). An LAC's peer may be L2TP control connection (i.e. the far LCCE). An LAC's peer may be
either an LNS or another LAC. Similarly, an LNS's peer 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.) either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
Pseudowire (PW)
An emulated circuit as it traverses a PSN. There is one
Pseudowire per L2TP Session. (See also: Packet-Switched Network,
Session.)
Pseudowire Type
The payload type being carried within an L2TP session. Examples
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 created by a particular L2TP control connection An L2TP session is created by a particular L2TP control connection
between two LCCEs when a circuit is successfully established. The between two LCCEs when a circuit is successfully established. The
circuit may either pass through (LAC) or terminate locally (LNS) circuit may either pass through (LAC) or terminate locally (LNS)
on the LCCEs, which maintain state for the circuit. There is a on the LCCEs, which maintain state for the circuit. There is a
one-to-one relationship between established L2TP sessions and one-to-one relationship between established L2TP sessions and
their associated circuits. (See also: Circuit, LAC, LCCE, LNS.) their associated circuits. (See also: Circuit, LAC, LCCE, LNS.)
Zero-Length Body (ZLB) Message Zero-Length Body (ZLB) Message
A control packet with only an L2TP header. ZLB messages are used A control message with only an L2TP header. ZLB messages are used
for explicitly acknowledging packets on the reliable control for explicitly acknowledging packets on the reliable control
channel. channel. (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 circuit traffic across a packet network. An L2TP Network tunneling circuit traffic across a packet network. An L2TP Network
Server (LNS) is an LCCE that decapsulates tunneled L2 traffic and Server (LNS) is an LCCE that decapsulates tunneled L2 traffic and
directs it as incoming data towards a virtual L2 interface. In directs it as incoming data towards a virtual L2 interface. In
contrast, an L2TP Access Concentrator (LAC) is an LCCE that merely contrast, an L2TP Access Concentrator (LAC) is an LCCE that merely
forwards tunneled traffic directly to a circuit (which may even be forwards tunneled traffic directly to a circuit (which may even be
another L2TP session). another L2TP session).
skipping to change at page 10, line 23 skipping to change at page 10, line 41
+-----+ L2 +-----+ +-----+ L2 +-----+ +-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |...[packet network]...| LAC |------| | | |------| LAC |...[packet network]...| 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. (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs.
Each LNS logically terminates the L2TP session locally, requiring Rather than forwarding traffic directly over a circuit, each LNS
virtual L2 interfaces for each L2TP session on each side of the L2TP logically terminates the tunneled L2TP session locally. In this
session. A user-level or traffic-generated event typically drives manner, both sides have virtual interfaces associated with each L2TP
session establishment from one side of the control connection. Also session. A user-level, traffic-generated, or signaled event
known as "voluntary tunneling" [RFC2809]. typically drives session establishment from one side of the tunnel.
Also known as "voluntary tunneling" (see [RFC2809]).
+-----+ +-----+ +-----+ +-----+
[home network]...| LNS |...[packet network]...| LNS |...[home network] [home network]...| LNS |...[packet network]...| LNS |...[home network]
+-----+ +-----+ +-----+ +-----+
|<- emulated service ->| |<- emulated service ->|
|<---- L2 service ---->| |<---- L2 service ---->|
Note: If an LNS initiates session establishment due to an event Note: If an LNS initiates session establishment due to an event
(generally user-driven), the LNS is sometimes referred to as a "LAC (generally user-driven), the LNS is sometimes referred to as a "LAC
Client" as defined in [RFC2661]. Client" as defined in [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. Control messages are used in the establishment, messages. Control messages are used in the establishment,
maintenance, and clearing of control connections and calls. These maintenance, and clearing of control connections and sessions. These
messages utilize a reliable control channel within L2TP to guarantee messages utilize a reliable control channel within L2TP to guarantee
delivery (see Section 4.2 for details). Data messages are used to delivery (see Section 4.2 for details). Data messages are used to
encapsulate the L2 traffic being carried over the L2TP session. encapsulate the L2 traffic being carried over the L2TP session.
Unlike control messages, data messages are not retransmitted when Unlike control messages, data messages are not retransmitted when
packet loss occurs. packet loss occurs.
While both the L2TP control channel and the L2TP data channel are While both the L2TP control channel and the L2TP data channel are
defined strictly in this document, the L2TP data channel MAY be defined strictly in this document, the L2TP data channel MAY be
substituted with a different L2 tunneling encapsulation whose format substituted with a different L2 tunneling encapsulation whose format
can negotiated by the L2TP control connection. Furthermore, the L2TP can negotiated by the L2TP control connection. Furthermore, the L2TP
data channel MAY be used without the control channel, if so desired. data channel MAY be used without the control channel, if so desired.
However, it is strongly recommended that such practice be limited to However, it is strongly recommended that such practice be limited to
relatively small-scale deployments, or deployments in which some relatively small-scale deployments or deployments in which some other
other form of automatic control information distribution is employed. form of automatic control information distribution is employed.
Figure 3.0: L2TPv3 Structure Figure 3.0: L2TPv3 Structure
+-------------------+ +-------------------+
| L2 Frames | | L2 Frames |
+-------------------+ +-----------------------+ +-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages | | L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+ +-------------------+ +-----------------------+
| 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 messages are passed over an unreliable data channel, encapsulated by
first by an L2TP header and sent over a Packet Switched Network (PSN) an L2TP header, and sent over a Packet-Switched Network (PSN) such as
such as IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over
sent over a reliable L2TP control channel, which operates in-band a reliable L2TP control channel, which operates over the same PSN.
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, if required, and (2)
a session as triggered by an incoming call or outgoing call. The establishing a session as triggered by an incoming call or outgoing
control connection MUST be established before an incoming or outgoing call. An L2TP session MUST be established before L2TP can begin to
call is initiated. An L2TP session MUST be established before L2TP forward session frames. Multiple sessions may be bound to a single
can begin to forward session frames. Multiple sessions may be bound control connection, and multiple control connections may exist
to a single control connection, and multiple control connections may between the same two LCCEs.
exist between the 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):
skipping to change at page 12, line 26 skipping to change at page 12, line 48
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. As such, over the underlying media in-band with L2TP data messages. As such,
L2TP also includes a default method (borrowing from RFC 2661 by L2TP also includes a default method (borrowing from RFC 2661 by
utilizing the high bit of the first octet in the L2TP header) that utilizing the high bit of the first octet in the L2TP header) that
may be used to distinguish L2TP control messages from L2TP data may be used to distinguish L2TP control messages from L2TP data
messages. Other methods for distinguishing between control and data messages. Other methods for distinguishing control and data messages
MAY be utilized for specific media (an example is L2TP over IP as MAY be utilized for specific media (e.g. L2TP over IP, as defined in
defined in 4.1). Section 4.1.1).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 8 skipping to change at page 14, line 30
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) Tunnel Header, (2) In general, an L2TP data message consists of a (1) Session Header,
an L2-Specific Sublayer (when needed), and (3) the Tunneled L2 Frame, (2) an optional PW Control Encapsulation, and (3) the Tunneled L2
as depicted below. Frame, as depicted below.
Figure 3.2.2: L2TP Data Message Figure 3.2.2: L2TP Data Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Switched Network (PSN) Delivery Header | | L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Tunnel Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer | | PW Control Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunneled L2 Frame | | Tunneled Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Packet Switched Network is any network layer that uses packet- The L2TP Session Header is specific to the PSN over which the L2TP
switching technology for data delivery. This is principally IP, but traffic is delivered. The Session Header SHOULD provide (1) a method
may be MPLS, FR, ATM, or any other packet-switched network. of distinguishing traffic among multiple L2TP data sessions and (2) a
method of distinguishing data messages from control messages
(assuming the messages are received in-band).
The L2TP Tunnel Header is specific to the PSN over which the L2TP Each type of PSN MUST define its own session header, clearly
traffic is delivered. The tunnel header MUST, at a minimum, provide identifying the format of the header and parameters necessary to
(1) a 32-bit longword-aligned Session ID field to uniquely identify a setup the session. Section 4.1 defines two session headers, one for
tunneled stream of data, and (2) a method of distinguishing data transport over UDP and one for transport over IP.
messages from control messages. Each type of PSN MUST define its own
tunnel header, clearly identifying the format of the header and
parameters necessary to setup the session. Section 4.1 defines two
tunnel headers, one for transport over UDP and one for transport over
IP. Either of these formats MAY be used for other PSNs, but the
actual definition of such remains outside the scope of this document.
The L2-specific sublayer is an intermediary layer between the fixed The PW Control Encapsulation is an intermediary layer between the
L2TP tunnel header and the start of the inner L2 frame. It may L2TP session header and the start of the tunneled frame. It SHOULD
contain control fields that the are used to facilitate the tunneling contain control fields that are used to facilitate the tunneling of
of the L2 frames (e.g. offset bytes or sequence numbers). Since the each frames (e.g. sequence numbers). The default PW control
sublayer is specific to each L2 payload that may be tunneled using encapsulation for L2TPv3 is defined in Section 4.6.
the L2TP data encapsulation, the format of the sublayer is determined
by the Pseudo Wire Type AVP (see Section 5.4.4), which identifies the
L2 payload. Specific sublayer formats are defined in the appropriate
L2 payload-specific companion documents. A default L2-Sublayer is
defined in Section 4.6.
The tunneled L2 frame consists of the encapsulated L2 traffic, The Tunneled Frame consists of PW data traffic, including any
including any necessary L2 framing as defined in the payload-specific necessary L2 framing as defined in the payload-specific companion
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 the typical control connection establishment This section describes the typical control connection establishment
and teardown exchanges. It is important to note that, in the and teardown exchanges. It is important to note that, in the
diagrams that follow, the reliable control message delivery mechanism diagrams that follow, the reliable control message delivery mechanism
exists independently of the L2TP state machine. For instance, ZLB exists independently of the L2TP state machine. For instance, ZLB
ACKs may be sent after any of the control messages indicated in the ACKs may be sent after any of the control messages indicated in the
exchanges below if an acknowledgement is not piggybacked on a later exchanges below if an acknowledgment is not piggybacked on a later
control message. control message.
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:
skipping to change at page 17, line 25 skipping to change at page 17, line 36
CDN -> CDN ->
(Clean up) (Clean up)
(Clean up) (Clean up)
4. Protocol Operation 4. Protocol Operation
This section addresses various operational issues in both the control This section addresses various operational issues in both the control
connection and data channel of L2TP. connection and data channel of L2TP.
4.1 L2TP Over Specific Packet Switched Networks (PSNs) 4.1 L2TP Over Specific Packet-Switched Networks (PSN)
L2TP is designed to allow operation over a variety of Packet Switched L2TP is designed to allow operation over a variety of PSNs. The L2TP
Networks. In consideration of any specific characteristics of an Session Header encapsulation MAY vary for a given PSN.
underlying PSN, the actual L2TP Tunnel Header encapsulation may vary.
For instance, a payload length field for data packets traversing a
UDP or IP network is unnecessary as this is readily available from
the underlying layer.
This document describes the standard method for operation of L2TP This document describes the standard method for operation of L2TP
over IPv4 networks. There are two modes described, L2TP over IP over IPv4 networks. There are two modes described, L2TP over IP
(section 4.1.1) and L2TP over UDP (section 4.1.2). L2TPv3 (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, integration with IPsec over UDP for better NAT and FW traversal, integration with IPsec
[RFC3193], and easier migration from L2TPv2. [RFC3193], and easier migration from 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. Whenever possible, the field definitions the scope of this document. Examples of L2TPv2 over other PSNs
in this section should be used as they are described here. Examples include [RFC3070] and [L2TPAAL5].
of L2TPv2 over other PSNs include [RFC3070], and [L2TPAAL5].
The following field definitions are defined for use in all L2TP The following field definitions are defined for use in all L2TP
Tunnel Header encapsulations. Session Header encapsulations.
Session ID Session ID
A 32-bit field containing a non-zero identifier for a session. L2TP A 32-bit field containing a non-zero identifier for a session.
sessions are named by identifiers that have local significance only. L2TP sessions are named by identifiers that have local
significance only. That is, the same logical session will be
That is, the same logical session will be given different Session IDs given different Session IDs by each end of the control connection
by each end of the tunnel for the life of the session. When the L2TP for the life of the session. When the L2TP control connection is
control connection is used for session establishment, Session IDs are used for session establishment, Session IDs are selected and
selected and exchanged as Local Session ID AVPs during the creation exchanged as Local Session ID AVPs during the creation of a
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), longword-aligned value used to check the association of a bits), longword-aligned value used to check the association of a
received data message with the session identified by the Session ID. received data message with the session identified by the Session
The Cookie MUST be configured with a random value utilizing all bits ID. The Cookie MUST be configured with a random value utilizing
in the field. The Cookie provides an additional level of guarantee, all bits in the field. The Cookie provides an additional level of
beyond the Session ID lookup, that a data message has been directed guarantee, beyond the Session ID lookup, that a data message has
to the proper session. A well-chosen Cookie may prevent inadvertent been directed to the proper session. A well-chosen Cookie may
misdirection of stray packets with recently reused Session IDs, prevent inadvertent misdirection of stray packets with recently
Session IDs subject to packet corruption, etc. reused Session IDs, Session IDs subject to packet corruption, etc.
When the L2TP control connection is used for session establishment, When the L2TP control connection is used for session
random Cookie values are selected and exchanged as Assigned Cookie establishment, random Cookie values are selected and exchanged as
AVPs during the creation of a session. The maximum size of the Assigned Cookie AVPs during the creation of a session. The
Cookie field is 64 bits. maximum size of the Cookie field is 64 bits.
4.1.1 L2TP over IP 4.1.1 L2TP over IP
L2TP over IP utilizes the IANA assigned IP protocol ID 115. L2TP over IP utilizes the IANA assigned IP protocol ID 115.
4.1.1.1 L2TP over IP Tunnel Header 4.1.1.1 L2TP over IP Session Header
Unlike L2TP over UDP, the L2TPv3 tunnel header over IP is free of any Unlike L2TP over UDP, the L2TPv3 session header over IP is free of
restrictions imposed by coexistence with L2TPv2 and L2F. As such, any restrictions imposed by coexistence with L2TPv2 and L2F. As
the header format has been redesigned to optimize packet processing. such, the header format has been redesigned to optimize packet
The following tunnel header format is utilized when operating L2TPv3 processing. The following session header format is utilized when
over IP: operating L2TPv3 over IP:
Figure 4.1.1.1: L2TPv3 over IP Tunnel Header Figure 4.1.1.1: L2TPv3 over IP Session 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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).
It should be noted that the absence of the Version and Flags fields, It should be noted that the absence of the Version and Flags fields,
which are present in L2TP over UDP, prevents straightforward version which are present in L2TP over UDP, prevents straightforward version
extension flexibility for data messages. However, given the freedom extensibility for data messages. However, given the freedom of
of setting the first 32 bits in the data message header here, this setting the first 32 bits in the data message header (i.e. the
limitation can be alleviated with an acceptable workaround if an Session ID field), an acceptable workaround to this limitation can be
extension to the demultiplexing capabilities of L2TP is ever in need devised if an extension to the demultiplexing capabilities of L2TP is
of further revision. In contrast, the control message header still ever in need of further revision. In contrast, the control message
retains all version checking ability. header still retains all version checking ability.
4.1.1.2 L2TP Control and Data Traffic over IP 4.1.1.2 L2TP Control and Data Traffic over IP
As shown in Section 4.1.1.1, there are no Version and Flags fields in As shown in Section 4.1.1.1, there are no Version and Flags fields in
the L2TP Tunnel Header over IP. Specifically, the T bit does not the L2TP Session Header over IP. Specifically, the T bit does not
exist to distinguish control packets and data packets. Instead, all exist to distinguish control packets and data packets. Instead, all
control packets are sent over the reserved session ID of 0. It is control packets are sent over the reserved session ID of 0. It is
presumed that this method is more efficient -- both in header size presumed that this method is more efficient -- both in header size
for data packets and in processing speed for distinguishing control for data packets and in processing speed for distinguishing control
messages -- than checking for the presence of certain bits. messages -- than checking for the presence of certain bits.
Thus, the entire control message header over IP, including the zero The entire control message header over IP, including the zero session
session ID, appears as follows: ID, appears as follows:
Figure 4.1.1.2: L2TPv3 over IP Control Message Header Figure 4.1.1.2: L2TPv3 over IP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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. The length calculation does NOT header, beginning with the T bit. It does NOT include the "(32 bits
include the "(32 bits of zeros)" depicted above. of zeros)" depicted above.
4.1.2 L2TP over UDP 4.1.2 L2TP over UDP
L2TPv3 over UDP must take into careful consideration other L2 L2TPv3 over UDP must consider other L2 tunneling protocols that may
tunneling protocols that may be operating in the same environment, be operating in the same environment, including L2TPv2 [RFC2661] and
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, in some there are possible side effects as well. For instance, L2TP over IP
circumstances, L2TP over IP may not be as NAT-friendly as L2TP over is not as NAT-friendly as L2TP over UDP. Also, control messages
UDP. Also, control messages transmitted over IP are not protected by transmitted over IP are not protected by a network-layer checksum as
a network-layer checksum as they are with UDP. As such, and for they are with UDP.
easier migration from L2TPv2, this mode over operation is provided.
4.1.2.1 L2TP over UDP Tunnel Header 4.1.2.1 L2TP over UDP Session Header
The following tunnel 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 over UDP Tunnel Header Figure 4.1.2.1: L2TPv3 over UDP Session 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|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)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 4 skipping to change at page 21, line 39
4.1.2.2 L2TP over UDP Port Selection 4.1.2.2 L2TP over UDP Port Selection
L2TPv3 utilizes the same UDP port selection method as defined in L2TPv3 utilizes the same UDP port selection method as defined in
L2TPv2 [RFC2661]. L2TPv2 [RFC2661].
When negotiating a control connection over UDP, control messages When negotiating a control connection over UDP, control messages
first must be sent as UDP datagrams using the registered UDP port first must be sent as UDP datagrams using the registered UDP port
1701 [RFC1700]. The initiator of an L2TP control connection picks an 1701 [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. This through this control connection) must use these same UDP ports. This
method has some inefficiencies with regard to packet processing. method has some inefficiencies with regard to packet processing.
However, it is the most NAT-friendly method since there is only one However, it is the most NAT-friendly method since there is only one
entry in the NAT table to be kept valid, and the control connection entry in the NAT table to be kept valid, and the control connection
can provide a keepalive to ensure that the NAT entry remains valid. can provide a keepalive to ensure that the NAT entry remains valid.
Also, firewalls can be configured to pass all control and data Also, firewalls can be configured to pass all control and data
traffic with a single entry rather than separate entries for control traffic with a single entry rather than separate entries for control
and for data. and for data.
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 before choosing an should consider the potential implication of this capability before
arbitrary source port. Any NAT device that can pass TFTP traffic choosing an arbitrary source port. Any NAT device that can pass TFTP
should be able to pass L2TP UDP traffic as they employ similar traffic should be able to pass L2TP UDP traffic since both protocols
policies with regard to UDP port selection. employ similar policies with regard to 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, however, that enabling for data messages. It should be noted, however, that enabling
checksums on data packets may significantly increase packet checksums on data packets may significantly increase packet
processing burden. processing burden.
4.1.3 IP Fragmentation Issues 4.1.3 IP Fragmentation Issues
skipping to change at page 22, line 18 skipping to change at page 22, line 51
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 ZLB ACK message), receipt of duplicate messages MUST be of a lost ZLB ACK message), receipt of duplicate messages MUST be
acknowledged by the reliable delivery mechanism. This acknowledged by the reliable delivery mechanism. This acknowledgment
acknowledgement may either piggybacked on a message in queue or sent may either piggybacked on a message in queue or sent explicitly via a
explicitly via a ZLB ACK. ZLB ACK.
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 ZLB acknowledgement. Thus, Ns is not number space, except the ZLB acknowledgment. Thus, Ns is not
incremented after a ZLB message is sent. incremented after a ZLB 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-
ZLB message received plus 1, modulo 65536). While the Nr in a ZLB message received plus 1, modulo 65536). While the Nr in a
received ZLB is used to flush messages from the local retransmit received ZLB is used to flush messages from the local retransmit
queue (see below), the Nr of the next message sent is not updated by queue (see below), the Nr of the next message sent is not updated by
the Ns of the ZLB. As a precaution, Nr should be sanity-checked the Ns of the ZLB. As a precaution, 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, it 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)
passes without acknowledgement, the message is retransmitted. The passes without acknowledgment, the message is retransmitted. The
retransmitted message contains the same Ns value, but the Nr value retransmitted message contains the same Ns value, but the Nr value
MUST be updated with the sequence number of the next expected MUST be updated with the sequence number of the next expected
message. 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 MUST be no less than 8 seconds per retransmission. If no peer cap MUST be no less than 8 seconds per retransmission. If no peer
skipping to change at page 23, line 38 skipping to change at page 24, line 23
sending out a Receive Window Size AVP with a value of 1), but MUST sending out a Receive Window Size AVP with a value of 1), but MUST
accept a window of up to 4 from its peer (i.e. have the ability to accept a window of up to 4 from its peer (i.e. have the ability to
send 4 messages before backing off). A value of 0 for the Receive send 4 messages before backing off). A value of 0 for the Receive
Window Size AVP is invalid. Window Size AVP is invalid.
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. recommended procedure is described in Appendix A.
A peer MUST NOT withhold acknowledgment of messages as a technique A peer MUST NOT withhold acknowledgment of messages as a technique
for flow controlling control messages. An L2TP implementation is for flow control of control messages. An L2TP implementation is
expected to be able to keep up with incoming control messages, expected to be able to keep up with incoming control messages,
possibly responding to some with errors reflecting an inability to possibly responding to some with errors reflecting an inability to
honor the requested action. honor the requested actions.
In addition, a peer MUST NOT withhold acknowledgement of messages in In addition, a peer MUST NOT withhold acknowledgment of messages in
order to maintain state in the L2TP state machine. Conversely, the order to maintain state in the L2TP state machine. Conversely, the
L2TP state machine MUST be capable of maintaining state if a ZLB ACK L2TP state machine MUST be capable of maintaining state if a ZLB ACK
is received in response to a control message. However, determining is received in response to a control message. However, determining
when a state should no longer be maintained (e.g. how long to wait in when a state should no longer be maintained (e.g. how long to wait in
wait-reply state for an ICRP from the peer) before destroying a wait-reply state for an ICRP from the peer) before destroying a
session or control connection is an issue that is left to each session or control connection is an issue that is left to each
implementation. implementation.
Appendix B contains examples of control message transmission, Appendix B contains examples of control message transmission,
acknowledgement, and retransmission. acknowledgment, and retransmission.
4.3 Tunnel Endpoint Authentication 4.3 Control Connection Authentication
L2TP incorporates a simple, optional, CHAP-like [RFC1994] L2TP incorporates a simple, optional, CHAP-like [RFC1994]
authentication system for each LCCE during control connection authentication system for each LCCE during control connection
establishment. If an LAC or LNS wishes to authenticate the identity establishment. If an LAC or LNS wishes to authenticate the identity
of its peer, a Challenge AVP is included in the SCCRQ or SCCRP of its peer, a Challenge AVP is included in the SCCRQ or SCCRP
message. If a Challenge AVP is received in an SCCRQ or SCCRP, a message. If a Challenge AVP is received in an SCCRQ or SCCRP, a
Challenge Response AVP MUST be sent in the following SCCRP or SCCCN, Challenge Response AVP MUST be sent in the following SCCRP or SCCCN,
respectively. If the expected response received from a peer does not respectively. If the expected response received from a peer does not
match, establishment of the control connection MUST be disallowed. match, establishment of the control connection MUST be disallowed.
To participate in LCCE authentication, a single shared secret MUST To participate in LCCE authentication, a single shared secret MUST
exist between the two LCCEs. This is the same shared secret used for exist between the two LCCEs. This is the same shared secret used for
AVP hiding (see Section 5.3). See Section 5.4.3 for details on AVP hiding (see Section 5.3). See Section 5.4.3 for details on
construction of the Challenge and Response AVPs. construction of the Challenge and Response AVPs.
4.4 Keepalive (Hello) 4.4 Keepalive (Hello)
A keepalive mechanism is employed by L2TP in order to differentiate A keepalive mechanism is employed by L2TP to detect loss of
control connection outages from extended periods of no control or connectivity between a pair of LCCEs. This detection is accomplished
data activity on a control connection. This is accomplished by by injecting Hello control messages (see Section 6.5) after a
injecting Hello control messages (see Section 6.5) after a specified specified period of time has elapsed since the last data message or
period of time has elapsed since the last data message or control control message was received on an L2TP session or control
message was received on an L2TP session or control connection, connection, respectively. As with any other control message, if the
respectively. As for any other control message, if the Hello message Hello message is not reliably delivered, the sending LCCE declares
is not reliably delivered, the control connection is declared down that the control connection is down and resets its state for the
and is reset. The delivery reset mechanism along with the injection control connection. This behavior ensures that a connectivity
of Hello messages ensures that a connectivity failure between the failure between the LCCEs is detected independently by each end of a
LCCEs will be detected at both ends of a control connection. control connection.
The sending of Hello messages and the policy for sending them are The sending of Hello messages and the policy for sending them are
left up to the implementation. A peer MUST NOT expect Hello messages left up to the implementation. A peer MUST NOT expect Hello messages
at any time or interval. As with all messages sent on the control at any time or interval. As with all messages sent on the control
connection, the receiver will return either a ZLB ACK or an connection, the receiver will return either a ZLB ACK or an
(unrelated) message piggybacking the necessary acknowledgement (unrelated) message piggybacking the necessary acknowledgment
information. information.
Since a Hello is a control message, and since control messages are If the control channel is operated in-band with data traffic over the
reliably sent by the lower level delivery mechanism, this keepalive PSN, this single mechanism can be used to infer basic data
function operates by causing the reliable delivery of a message. If connectivity between a pair of LCCEs for all sessions associated with
a media interruption has occurred, the delivery mechanism will be the control connection.
unable to deliver the Hello across and will clean up the control
connection. Since the control channel is operated in-band with all
data traffic over the PSN, this single mechanism can be used to infer
basic connectivity between tunnel endpoints for all sessions
associated with a control connection. Thus, per-session keepalives
are considered redundant unless they are sent end-to-end from or to a
remote system beyond the L2TP tunnel.
Keepalives for the control connection MAY be implemented by sending a Keepalives for the control connection MAY be implemented by sending a
Hello if a period of time (a recommended default is 60 seconds, but Hello if a period of time (a recommended default is 60 seconds, but
SHOULD be configurable) has passed without receiving any message SHOULD be configurable) has passed without receiving any message
(data or control) from the peer. An LCCE sending Hello messages (data or control) from the peer. An LCCE sending Hello messages
across multiple control connections between the same LCCE endpoints across multiple control connections between the same LCCE endpoints
SHOULD employ a jittered timer mechanism. SHOULD employ a jittered timer mechanism.
4.5 Forwarding Session Data Frames 4.5 Forwarding Session Data Frames
Once session establishment is complete, L2 frames are received at an Once session establishment is complete, circuit frames are received
LCCE, encapsulated in L2TP (with appropriate attention to framing and at an LCCE, encapsulated in L2TP (with appropriate attention to
L2 dependencies as described in documents for the particular Pseudo framing as described in documents for the particular pseudowire
Wire 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 the same 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. Any received data packets that contain during session establishment. Any received data packets that contain
invalid Session IDs or associated Cookie values MUST be dropped. invalid Session IDs or associated Cookie values MUST be dropped.
Finally, the LCCE either processes the encapsulated session frame Finally, the LCCE either processes the encapsulated session frame
locally (i.e. as an LNS) or forwards the frame to a circuit (i.e. as locally (i.e. as an LNS) or forwards the frame to a circuit (i.e. as
an LAC). an LAC).
4.6 Default L2-Specific Sublayer 4.6 Default PW Control Encapsulation
L2TP provides a default mechanism that a specific Pseudo Wire Type This document defines a default PW control encapsulation (see Section
MAY use for basic sequencing support, offset of the Tunneled L2 3.2.2) format that a pseudowire may use for features such as basic
Frame, and marking of packets with a single high-priority bit. As sequencing support, marking of packets with a single high-priority
each PW-Type is different, each has different needs regarding these bit, or other general PW-specific per-packet control operations. The
features. This format is being provided as a suggestion for PW- default control encapsulation SHOULD be used by a given PW type to
specific documents, and SHOULD be used as a common method for support support these features if it is adequate, and its presence is
of these features if it is adequate for the given PW-Type. If this requested by a peer during session negotiation. Alternative PW
mechanism is not well-suited for a particular Pseudo Wire Type, or control encapsulations MAY be defined (e.g. an encapsulation with a
where there may be overlapping functionality at another layer (such larger Sequence Number field) and identified for use via the PW
as sequencing for a PW which is using RTP) the mechanism defined here Control Encapsulation Type AVP.
may be omitted and another L2-specific layer identified for that
particular Pseudo Wire Type.
This header is not a part of the base L2TP Tunnel Header (see Section Figure 4.6: Default PW Control Encapsulation Format
3.2.2), and its presence or lack of presence for a given PW-Type is
defined within the scope of the PW-Specific companion documents. PW-
Specific documents for L2TP may refer to this document and section as
a default method for PW support of some or all of these features.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|S|x|x| OffSz | Sequence Number | |P|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset padding... (optional, up to 15 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The P (Priority) bit is used to identify a data packet which should The P (Priority) bit is used to identify a data packet that should be
be dropped only as a last resort after being received by an L2TP dropped only as a last resort after being received by an L2TP peer.
peer. This bit should be set to 1 for any layer-2 traffic which This bit should be set to 1 for any traffic that should be given
should be given higher priority in a congested environment. For higher priority than other data traffic in a congested environment.
example end-to-end keepalive packets, or other control packets vital For example, end-to-end L2 keepalive packets (e.g. LCP keepalives) or
to the life of the circuit may need special handling by a tunnel other control packets vital to the life of the circuit may need
endpoint upon receipt. This is not a replacement for, or to be used special handling by an LCCE upon receipt. This is not a replacement
as, a per-hop QoS method of any sort. It is only to be used by the for, or to be used as, a per-hop QoS method of any sort. It is only
L2TP receiving node to prioritize incoming traffic. 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 OffSz (Offset Size) field defines the number of bytes of padding
that exist after the Sequence Number, and before the beginning of the
L2 frame. This may be used to ensure alignment of an inner L3 packet
in cases where the L2 framing itself may not be word-aligned. This is
generally of most use when sending packets to an LNS which is going
to route the framed L3 packet locally rather than sending it out
another data link.
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 (thus, implementations inserting sequence valid sequence number. (In this way, implementations inserting
numbers do not have to "skip" zero when incrementing). The sequence sequence numbers do not have to "skip" zero when incrementing.) The
number in the header of a received message is considered less than or sequence number in the header of a received message is considered
equal to the last received number if its value lies in the range of less than or equal to the last received number if its value lies in
the last received number and the preceding (2^23 - 1) values, the range of the last received number and the preceding (2^23-1)
inclusive. values, inclusive.
See Section 4.6.1 for more information on sequencing layer 2 frames.
4.6.1 Sequencing Data Packets 4.6.1 Sequencing Data Packets
The Sequence Number field may be used to detect lost packets and/or The Sequence Number field may be used to detect lost packets and/or
restore the original sequence of packets that may have been reordered restore the original sequence of packets that may have been reordered
during traversal of the packet network. during traversal of the packet network.
When Layer 2 frames are carried over an L2TP-over-IP or L2TP-over- When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
UDP/IP data channel, this part of the link has the characteristic of data channel, this part of the link has the characteristic of being
being able to reorder or silently drop packets. Reordering may break able to reorder or silently drop packets. Reordering may break some
some non-IP protocols or layer 2 control traffic being carried by the non-IP protocols or L2 control traffic being carried by the link.
link. Silent dropping of packets may break protocols that assume Silent dropping of packets may break protocols that assume per-packet
per-packet indication of error, such as TCP header compression. indication of error, such as TCP header compression. The sequence
dependency characteristics of 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, sequencing may be turned on some or all packets tolerate misordering, sequencing may be enabled on some or all
by using the sequence number field and S bit defined in section 4.6. packets by using the S bit and Sequence Number field defined in the
The sequence dependency characteristics of individual protocols are default PW control encapsulation (see Section 4.6). For a given L2TP
outside the scope of this document. L2TP takes the very basic and session, each LCCE is responsible for communicating to its peer the
simple approach that by default it is always up to the sender as to level of sequencing support that it requires of data packets that it
which packets it will try and apply sequence numbers to, and up to receives. Mechanisms to advertise this information during session
the receiver as to how much attention will be paid to any sequenced negotiation are provided (see, in particular, the Data Sequencing AVP
packets being processed. L2TP provides mechanisms to advertise this in Section 5.4.4). PW-specific documents MAY place greater
information to both sides of the connection (see Section 5.4.4) to constraints on sequence number enforcement than those defined here.
help with debugging or to adjust sequencing policy according to the
advertised policy of one's peer. PW-specific documents MAY place
greater constraints on sequence number enforcement than those defined
here.
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 be mindful of these However, even L2TPv3-only implementations must be mindful of these
issues in order to interoperate with implementations that support issues in order to interoperate with implementations that support
both versions. both versions.
skipping to change at page 28, line 16 skipping to change at page 28, line 25
over IP to try to initiate an L2TPv3 control connection. If the over IP to try to initiate an L2TPv3 control connection. If the
SCCRQ elicits no response, the implementation may fall back to L2TPv2 SCCRQ elicits no response, the implementation may fall back to L2TPv2
operation, as defined in [RFC2661]. Fallback to L2TPv2 should be operation, as defined in [RFC2661]. Fallback to L2TPv2 should be
seamless and occur automatically. (See Section 4.7.3 for further seamless and occur automatically. (See Section 4.7.3 for further
details.) details.)
4.7.2 L2TPv3 over UDP 4.7.2 L2TPv3 over UDP
In order to allow simultaneous operation with L2TPv2, L2TPv3 uses the In order to allow simultaneous operation with L2TPv2, L2TPv3 uses the
same UDP port (port 1701) as L2TPv2 and shares the first two octets same UDP port (port 1701) as L2TPv2 and shares the first two octets
of header format (via the tunnel header) with L2TPv2. Furthermore, of header format (via the session header) with L2TPv2. Furthermore,
though the control message and data message headers have changed, an though the control message and data message headers have changed, an
LCCE sends an SCCRQ that looks enough like an L2TPv2 SCCRQ to be LCCE sends an SCCRQ that looks enough like an L2TPv2 SCCRQ to be
accepted by both L2TPv2 and L2TPv3 implementations. If the response accepted by both L2TPv2 and L2TPv3 implementations. If the response
to the SCCRQ is a properly formatted L2TPv3 message, then operation to the SCCRQ is a properly formatted L2TPv3 message, then operation
can continue as described in this document for an L2TPv3 can continue as described in this document for an L2TPv3
implementation. If the response is a properly formatted L2TPv2 implementation. If the response is a properly formatted L2TPv2
message, then an L2TPv2 mode of operation must be adopted. message, then an L2TPv2 mode of operation must be adopted.
4.7.3 Automatic L2TPv2 Fallback 4.7.3 Automatic L2TPv2 Fallback
skipping to change at page 29, line 10 skipping to change at page 29, line 15
The auto-detection mode requires that an L2TPv3-only implementation The auto-detection mode requires that an L2TPv3-only implementation
be liberal in its acceptance of SCCRQ control messages with the Ver be liberal in its acceptance of SCCRQ control messages with the Ver
field set to 2. Thus, an L2TPv3 over UDP implementation MUST allow field set to 2. Thus, an L2TPv3 over UDP implementation MUST allow
receipt of an SCCRQ with Ver field of 2 or Ver field of 3. receipt of an SCCRQ with Ver field of 2 or Ver field of 3.
5. Control Message Attribute Value Pairs 5. Control Message Attribute Value Pairs
To maximize extensibility while still permitting interoperability, a To maximize extensibility while still permitting interoperability, a
uniform method for encoding message types and bodies is used uniform method for encoding message types and bodies is used
throughout L2TP. This encoding will be termed AVP (Attribute Value throughout L2TP. This encoding will be termed AVP (Attribute Value
Pair) in the remainder of this document. Pair) for the remainder of this document.
5.1 AVP Format 5.1 AVP Format
Each AVP is encoded as: Each AVP is encoded as follows:
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 describe 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 AVP that is unrecognized or implementation that receives an unrecognized or malformed AVP. The M
malformed. The M bit of a given AVP should only be checked if the bit of a given AVP should only be checked if the AVP is unrecognized
AVP is unrecognized or malformed. If the M bit is set on an or malformed. If the M bit is set on an unrecognized or malformed
unrecognized or malformed AVP in a control message associated with a AVP in a control message associated with a particular session, the
particular session, the session MUST be terminated. If the M bit is session MUST be terminated. If the M bit is set on an unrecognized
set on an unrecognized or malformed AVP within a control message or malformed AVP within a control message associated with a control
associated with a control connection, the control connection (and all connection, the control connection (and all sessions bound to the
sessions bound to the control connection) MUST be terminated. If the control connection) MUST be terminated. If the M bit is not set, an
M bit is not set, an unrecognized AVP MUST be ignored. The control unrecognized AVP MUST be ignored. The control message must then
message must then continue to be processed as if the AVP had not been continue to be processed as if the AVP had not been present.
present.
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: Encodes the number of octets (including the Overall Length Length: Encodes 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
skipping to change at page 30, line 37 skipping to change at page 30, line 42
5.2 Mandatory AVPs 5.2 Mandatory AVPs
Receipt of an unrecognized or malformed AVP that has the M bit set is Receipt of an unrecognized or malformed AVP that has the M bit set is
catastrophic to the session or control connection with which it is catastrophic to the session or control connection with which it is
associated. Thus, the M bit should only be defined for AVPs that are associated. Thus, the M bit should only be defined for AVPs that are
absolutely crucial to proper operation of the session or control absolutely crucial to proper operation of the session or control
connection. Furthermore, in the case in which the LAC or LNS connection. Furthermore, in the case in which the LAC or LNS
receives an unknown AVP with the M bit set and shuts down the session receives an unknown AVP with the M bit set and shuts down the session
or control connection accordingly, it is the full responsibility of or control connection accordingly, it is the full responsibility of
the peer sending the Mandatory AVP to accept fault for causing a the peer sending the Mandatory AVP to accept fault for causing a non-
non-interoperable situation. Before defining an AVP with the M bit interoperable situation. Before defining an AVP with the M bit set,
set, particularly a vendor-specific AVP, be sure that this is the particularly a vendor-specific AVP, be sure that this consequence is
intended consequence. intended.
When an adequate alternative exists to use of the M bit, it should be When an adequate alternative exists to use of the M bit, it should be
utilized. For example, rather than simply sending an AVP with the M utilized. For example, rather than simply sending an AVP with the M
bit set to determine if a specific extension exists, availability may bit set to determine if a specific extension exists, availability may
be identified by sending an AVP in a request message and expecting a be identified by sending an AVP in a request message and expecting a
corresponding AVP in a reply message. corresponding AVP in a reply message.
Use of the M bit with new AVPs (i.e. those not defined in this Use of the M bit with new AVPs (i.e. those not defined in this
document) MUST provide the ability to configure the associated document) MUST provide the ability to configure the associated
feature off, such that the AVP either is not sent or is sent with the feature off, such that the AVP either is not sent or is sent with the
M bit not set. M bit not set.
On the other side, the recipient of a control message should only On the receiving side, the recipient of a control message should only
check the M bit of an AVP when the AVP is determined to be check the M bit of an AVP when the AVP is determined to be
unrecognized or malformed. The M bit should not be checked for a unrecognized or malformed. The M bit should not be checked for a
recognized and well-formatted AVP. This rule prevents the recognized and well-formatted AVP. This rule prevents the
possibility of a valid AVP resulting in a session or control possibility of a valid AVP resulting in a session or control
connection teardown, simply because its M bit was set to a value that connection teardown simply because its M bit was set to a value that
was unexpected by the receiving LCCE. was unexpected by the receiving LCCE.
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 or user IDs. control message data such as user passwords or user IDs.
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
skipping to change at page 31, line 36 skipping to change at page 31, line 41
messages). To do otherwise runs the risk of AVP data being utilized messages). To do otherwise runs the risk of AVP data being utilized
without verifying the integrity of the shared secret. If the H bit without verifying the integrity of the shared secret. If the H bit
is set in any AVP(s) in a given control message, a Random Vector AVP is set in any AVP(s) in a given control message, a Random Vector AVP
must also be present in the message and MUST precede the first AVP must also be present in the message and MUST precede the first AVP
having an H bit of 1. having an H bit of 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
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 Length of Original Attribute Value: This is length of the Original
Attribute Value to be obscured in octets. This is necessary to Attribute Value to be obscured in octets. This is necessary to
skipping to change at page 34, line 18 skipping to change at page 34, line 28
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 or malformed, it is an indication should be ignored if not recognized or malformed, it is an indication
as to whether the control message itself should be ignored. If the M as to whether the control message itself should be ignored. If the M
bit is set within the Message Type AVP and the Message Type is bit is set within the Message Type AVP and the Message Type is
unknown to the implementation, the control connection MUST be unknown to the implementation, the control connection MUST be
cleared. If the M bit is not set, then the implementation may ignore cleared. If the M bit is not set, then the implementation may ignore
an unknown message type. The M bit MUST be set to 1 for all message an unknown message 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 types defined in this document. This AVP MAY NOT be hidden (the H
bit MUST be 0). The Length of this AVP is 8. bit MUST be 0). 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.
Random Vector (All Messages) Random Vector (All Messages)
The Random Vector AVP, Attribute Type 36, is used to enable the The Random Vector AVP, Attribute Type 36, is used to enable the
skipping to change at page 35, line 7 skipping to change at page 35, line 15
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. This AVP MUST precede the first AVP with the H bit set. it. This AVP MUST precede the first AVP with the H bit set.
The M bit for this AVP SHOULD be set to 1. This AVP MUST NOT be The M bit for this AVP SHOULD be set to 1. This AVP MUST NOT be
hidden (the H bit MUST be 0). The Length of this AVP is 6 plus the hidden (the H bit MUST be 0). The Length of this AVP is 6 plus the
length of the Random Octet String. length of the Random Octet String.
5.4.2 Result and Error Codes 5.4.2 Result and Error Codes
Result Code (CDN, StopCCN) 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) |
skipping to change at page 35, line 39 skipping to change at page 35, line 47
[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. The Length is 8 if there is no Error this AVP SHOULD be set to 1. The Length is 8 if there is no Error
Code or Message, 10 if there is an Error Code and no Error Message, Code or Message, 10 if there is an Error Code and no Error Message,
or 10 + the length of the Error Message if there is an Error Code and or 10 + the length of the Error Message if there is an Error Code and
Message. 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 7 - Finite State Machine error.
General Result Code values for the CDN message are as follows. General Result Code values for the CDN message are as follows:
Additional service-specific error codes are defined outside this
document.
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 2 - Session disconnected for the reason indicated in Error Code.
in Error Code 3 - Session disconnected for administrative reasons.
3 - Session disconnected for administrative reasons 4 - Session establishment failed due to lack of appropriate
4 - Session establishment failed due to lack of appropriate facilities being available (temporary condition).
facilities being available (temporary condition) 5 - Session establishment failed due to lack of appropriate
5 - Session establishment failed due to lack of appropriate facilities being available (permanent condition).
facilities being available (permanent condition) 6 - 11 Reserved (PPP-specific codes defined outside this document).
6 - 11 Reserved (PPP-specific codes defined outside this document) RC-TBA1 - Session not established due to losing tie-breaker.
TBA - Session was not established due to losing tie breaker RC-TBA2 - Session not established due to unsupported PW type.
TBA - Session was not established due to unsupported PW-Type combination RC-TBA3 - Session not established, sequencing required without valid
PW control encapsulation.
Additional service-specific Result Codes are defined outside this
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 shutdown 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 (i.e. "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. the error SHOULD be included in the Error Message field.
Furthermore, a vendor-specific AVP MAY be sent to indicate the Furthermore, a vendor-specific AVP MAY be sent to indicate the
problem more precisely. problem more precisely.
5.4.3 Control Connection Management AVPs 5.4.3 Control Connection Management AVPs
Protocol Version (SCCRP, SCCRQ) Control Connection Tie-Breaker (SCCRQ)
The Protocol Version AVP, Attribute Type 2, indicates the L2TP
protocol version of the sender.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver field is a 1-octet unsigned integer containing the value 1.
Rev field is a 1-octet unsigned integer containing 0. This pertains
to L2TP version 1, revision 0. Note this is not the same version
number that is included in the header of each message.
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1. The Length of this AVP is 8.
Tie Breaker (SCCRQ)
The Tie Breaker AVP, Attribute Type 5, indicates that the sender The Control Connection Tie-Breaker AVP, Attribute Type 5, indicates
desires a single control connection to exist between the given LCCE that the sender desires a single control connection to exist between
pair. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Breaker Value... | Control Connection Tie-Breaker Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) | ...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tie Breaker Value is an 8-octet value that is used to choose a The Control Connection Tie-Breaker Value is an 8-octet random value
single control connection when two LCCEs request a control connection that is used to choose a single control connection when two LCCEs
concurrently. The recipient of a SCCRQ must check to see if a SCCRQ request a control connection concurrently. The recipient of a SCCRQ
has been sent to the peer, and if so, must compare its Tie Breaker must check to see if a SCCRQ has been sent to the peer, and if so,
value with the received one. The lower value "wins", and the "loser" must compare its Control Connection Tie-Breaker value with the
MUST silently discard its control connection. In the case in which a received one. The lower value "wins", and the "loser" MUST discard
tie breaker is present on both sides and the value is equal, both its control connection, sending a StopCCN if the SCCRQ that it had
sent was 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 MUST discard their control connections and restart control sides MUST discard their control connections and restart control
connection negotiation. connection 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 Tie Breaker AVP breaker value, the initiator that included the Control Connection
"wins". If neither side issues a tie breaker, then two separate Tie-Breaker AVP "wins". If neither side issues a tie-breaker, then
control connections are opened. two separate control connections are opened.
In the case of a tie, the "winner" of the tie is declared the Tie-breaker values MUST be random values.
"dominant LCCE". Session-level ties, as detected by End Identifier
AVP, are always won by the dominant LCCE. If there is no tie, the
dominant LCCE is always the initiator of the control connection (the
sender of the SCCRQ).
Tie breaker values MUST be random values. Note that in RFC 2661, this value was referred to as the Tie-Breaker
AVP. Here, the AVP serves the same purpose and has the same
attribute value and composition.
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 0. The Length of this AVP is 14. this AVP SHOULD be set to 0. The Length of this AVP is 14.
Firmware Revision (SCCRP, SCCRQ) Host Name (SCCRQ, SCCRP)
The Firmware Revision AVP, Attribute Type 6, indicates the firmware
revision of the issuing device.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Firmware Revision is a 2-octet unsigned integer encoded in a
vendor-specific format.
For devices that do not have a firmware revision, the revision of the
L2TP software module or system software module may be reported
instead.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) is 8.
Host Name (SCCRP, SCCRQ)
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. issuing LAC or LNS.
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... | Host Name...
skipping to change at page 39, line 26 skipping to change at page 38, line 40
participating in DNS [RFC1034], a hostname with fully qualified participating in DNS [RFC1034], a hostname with fully qualified
domain would be appropriate. The Host Name MAY be used to identify domain would be appropriate. The Host Name MAY be used to identify
LCCE configuration, including the shared secret for LCCE LCCE configuration, including the shared secret for LCCE
authentication (if enabled) and any other options defined for the authentication (if enabled) and any other options defined for the
control connection. control connection.
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. The Length of this AVP is 6 plus the this AVP SHOULD be set to 1. The Length of this AVP is 6 plus the
length of the Host Name. length of the Host Name.
Vendor Name (SCCRP, SCCRQ) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 39 skipping to change at page 39, line 4
(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... | Vendor Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 UTF-8 charset using the Default Language [RFC2277]. the UTF-8 charset using the Default Language [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. The Length (before hiding) of this AVP is 6 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6
plus the length of the Vendor Name. plus the length of the Vendor Name.
Assigned Control Connection ID (SCCRP, SCCRQ, StopCCN) Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
The Assigned Control Connection ID AVP, Attribute Type TBA, encodes The Assigned Control Connection ID AVP, Attribute Type TBA, encodes
the ID being assigned to this control connection by the sender. the ID being assigned to this control connection 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 Control Connection ID | | Assigned Control Connection ID |
skipping to change at page 40, line 33 skipping to change at page 39, line 45
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 (i.e. in the SCCRQ) MUST be sent as the Assigned Control the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned
Connection ID AVP in the StopCCN. This policy allows the peer to try Control Connection ID AVP in the StopCCN. This policy allows the
to identify the appropriate control connection via a reverse lookup. peer to try to identify the appropriate control connection via a
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 (see Section 4.7.3). The Length (before AVP SHOULD be set to 1 (see Section 4.7.3). The Length (before
hiding) of this AVP is 10. hiding) of this AVP is 10.
Receive Window Size (SCCRP, SCCRQ) 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 |
skipping to change at page 41, line 4 skipping to change at page 40, line 18
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. The Window Size is a 2-octet unsigned integer.
If absent, the peer must assume a Window Size of 4 for its transmit If absent, the peer must assume a Window Size of 4 for its transmit
window. The remote peer may send the specified number of control window. The remote peer may send the specified number of control
messages before it must wait for an acknowledgment. messages before it must wait for an acknowledgment. See Section 4.2
for more information on reliable control message delivery.
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. The Length of this AVP is 8. this AVP SHOULD be set to 1. The Length of this AVP is 8.
Challenge (SCCRP, SCCRQ) Challenge (SCCRQ, SCCRP)
The Challenge AVP, Attribute Type 11, indicates that the issuing peer The Challenge AVP, Attribute Type 11, indicates that the issuing peer
wishes to authenticate the LCCE using a CHAP-style authentication wishes to authenticate the LCCE using a CHAP-style authentication
mechanism. mechanism.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... | Challenge...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data. The Challenge is one or more octets of random data.
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. The Length (before hiding) of this AVP is 6 AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 6
plus the length of the Challenge. plus the length of the Challenge.
Challenge Response (SCCCN, SCCRP) Challenge Response (SCCRP, SCCCN)
The Response AVP, Attribute Type 13, provides a response to a The Response AVP, Attribute Type 13, provides a response to a
challenge received. challenge received.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... | Response...
skipping to change at page 42, line 4 skipping to change at page 41, line 19
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... | Response...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(16 octets) | ...(16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16-octet value reflecting the CHAP-style [RFC1994] The Response is a 16-octet value reflecting the CHAP-style [RFC1994]
response to the challenge. response to the challenge.
This AVP MUST be present in an SCCRP or SCCCN if a challenge was This AVP MUST be present in an SCCRP or SCCCN if a challenge was
received in the preceding SCCRQ or SCCRP, respectively. For purposes received in the preceding SCCRQ or SCCRP, respectively. For purposes
of the ID value in the CHAP response calculation, the value of the of the ID value in the CHAP response calculation, the value of the
Message Type AVP for this message is used (e.g. 2 for an SCCRP, 3 for Message Type AVP for this message is used (e.g. 2 for an SCCRP, 3 for
an SCCCN). an SCCCN).
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. The Length (before hiding) of this AVP is AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
22. 22.
Pseudo Wire Transmit Capabilities List (SCCRP, SCCRQ) Pseudowire Capabilities List (SCCRQ, SCCRP)
The Pseudo Wire Transmit Capabilities List AVP, Attribute Type TBA,
indicates the L2 payload types the sender of this AVP can transmit.
The specific payload type of a given session is identified by the
Pseudo Wire Type AVP.
Often, the Pseudo Wire Transmit Capabilities List will be the same as The Pseudowire Capabilities List (PW Capabilities List) AVP,
the Pseudo Wire Receive Capabilities List. The case where it is not Attribute Type TBA, indicates the L2 payload types the sender can
is limited to where one might be able to support receiving data of support. The specific payload type of a given session is identified
one pseudowire type, but not transmission of that same pseudowire by the Pseudowire Type AVP.
type. This could be due to data plane limitations, or other factors.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudo Wire Type 0 | ... | | PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Pseudo Wire Type N | | ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined Pseudo Wire Types that may be included in this list may be Defined PW types that may appear in this list are outside the scope
found in section 5.4.4, Psuedo Wire Type AVP. of this document and are managed by IANA. Values 0 to 32767 are
assignable by IETF Consensus [RFC2434]. The remaining values may be
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this assigned on a First Come First Served basis [RFC2434].
AVP SHOULD be set to 1 (see Section 4.7.3). The Length (before
hiding) of this AVP is 8 octets with one Pseudo Wire Type specified,
plus 2 octets for each additional Pseudo Wire Type.
Pseudo Wire Receive Capabilities List (SCCRP, SCCRQ)
The Pseudo Wire Receive Capabilities List AVP, Attribute Type TBA,
indicates the L2 payload types that will be accepted by the sender of
this AVP. The specific payload type of a given session is identified
by the Pseudo Wire Type AVP.
Often, the Pseudo Wire Receive Capabilities List will be the same as
the Pseudo Wire Transmit Capabilities List. The case where it is not
is limited to where one might be able to support receiving data of
one pseudowire type, but not transmission of that same pseudowire
type. This could be due to data plane limitations, or other factors.
The Attribute Value field for this AVP has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudo Wire Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Pseudo Wire Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined Pseudo Wire Types that may be included in this list may be found in If a sender includes a given PW type in the PW Capabilities List AVP,
section 5.4.4, Psuedo Wire Type AVP. the sender assumes full responsibility for supporting that particular
payload, such as any payload-specific AVPs, PW control encapsulation,
or control messages that may be defined in the appropriate companion
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 (see Section 4.7.3). The Length (before AVP SHOULD be set to 1 (see Section 4.7.3). The Length (before
hiding) of this AVP is 8 octets with one Pseudo Wire Type specified, hiding) of this AVP is 8 octets with one PW type specified, plus 2
plus 2 octets for each additional Pseudo Wire Type. octets for each additional PW type.
5.4.4 Session Management AVPs 5.4.4 Session Management AVPs
Local Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ, SLI, WEN, occn, iccn) 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 TBA, encodes the ID being assigned to this L2TPv2), Attribute Type TBA, encodes the identifier being assigned to
session by the sender. 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 identifier used to multiplex The Local Session ID AVP establishes the identifier used to multiplex
and demultiplex both data and control connection traffic for a given and demultiplex both data and control traffic for a given session
session between two LCCEs. The local session lookup mechanism between two LCCEs. The local LCCE chooses a free value that it sends
chooses a free value that it expects to see in all received data to the remote LCCE using the Local Session ID AVP. The local LCCE
messages for this session, as well as an AVP in any subsequent then expects to see this value in the Session ID field of all
session-level control messages. The receiving LCCE MUST use this received data messages for this session. Additionally, for all
value as the Session ID in the header of all data messages sent to subsequent session-level control messages received, the local LCCE
this peer. In addition, the receiving LCCE MUST echo this value back expects to see this session ID value echoed in the Remote Session ID
as the Remote Session ID AVP in all session-related control messages, AVP. On the other side, upon first receiving the Local Session ID
allowing efficient session context lookup when processing these AVP in a control message, the remote LCCE MUST use this value for all
control messages. subsequent messages sent to the local LCCE for this session. The
value must appear in the Session ID field in the header of all
outgoing data messages for this session, and as the Remote Session ID
AVP of all outgoing control messages for this 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 MUST be 1 for implementations that support only L2TPv3 (see AVP MUST be 1 for implementations that support only L2TPv3 (see
Section 4.7 for L2TPv2 migration issues). The Length (before hiding) Section 4.7 for L2TPv2 migration issues). The Length (before hiding)
of this AVP is 10. of this AVP is 10.
Remote Session ID (CDN, ICRP, ICRQ, ICCN, OCRP, OCRQ, OCCN, WEN, SLI) Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
The Remote Session ID AVP, Attribute Type TBA, encodes the ID that The Remote Session ID AVP, Attribute Type TBA, encodes the identifier
was assigned to this session by the peer. 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 echoes the session identifier advertised by The Remote Session ID AVP MUST be present in all session-level
the peer via the Local Session ID AVP. It is the same value that will control messages. The AVP's value echoes the session identifier
be used in all transmitted data messages by this side of the session. advertised by the peer via the Local Session ID AVP. It is the same
In most cases, this is sufficient for our peer to lookup session- value that will be used in all transmitted data messages by this side
level context to apply this control message to. The cases where this of the session. In most cases, this identifier is sufficient for the
is not sufficient involve sending a session-level message before a peer to look up session-level context for this control message.
Local Session ID AVP is received from a peer. In these cases, the
Local Session ID AVP will have to be used, and a "reverse lookup" on
session context performed.
The Remote Session ID MUST be present in all session-level control
messages. In cases where a Local Session ID AVP has not been received
from our peer, its value is set to zero to indicate this. If the
Remote Session ID is set to zero, the Local Session ID AVP containing
our previously advertised Session ID MUST be included in the control
messages being sent.
Examples of valid messages defined in this document that might be When a session-level control message must be sent to the peer before
subject to a reverse lookup due to the Local Session ID AVP not being the Local Session ID AVP has been received from the peer, the value
received from our peer include the CDN, WEN and SLI. of the Remote 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 included in the control message. The peer must then
use the Local Session ID AVP to perform a "reverse lookup" to find
its session context. Session-level control messages defined in this
document that might be subject to a reverse lookup by a receiving
peer include 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 MUST be 1 for implementations that support only L2TPv3 (see AVP MUST be 1 for implementations that support only L2TPv3 (see
Section 4.7 for L2TPv2 migration issues). The Length (before hiding) Section 4.7 for L2TPv2 migration issues). The Length (before hiding)
of this AVP is 10. of this AVP is 10.
Assigned Cookie (ICRP, ICRQ, OCRP, OCRQ) Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)
The Assigned Cookie AVP, Attribute Type TBA, encodes the Cookie value The Assigned Cookie AVP, Attribute Type TBA, encodes the Cookie value
being assigned to this session by the sender. 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. A Cookie value 32, or 64 bits) is obtained by the Length of the AVP. A cookie value
of zero length serves as positive acknowledgement that the Cookie of zero length serves as positive acknowledgment that the Cookie
field should not be present in any data packets sent to this LCCE. field should not be present in any data packets sent to this LCCE.
The Assigned Cookie AVP MAY not be sent, which has the same effect as The Assigned Cookie AVP MAY not be sent, which has the same effect as
sending the AVP to designate a Cookie value of zero length. sending the AVP to designate a cookie value of zero length.
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 MUST be 1 for implementations that support only L2TPv3 (see AVP MUST be 1 for implementations that support only L2TPv3 (see
Section 4.7 for L2TPv2 migration issues). The Length (before hiding) Section 4.7 for L2TPv2 migration issues). The Length (before hiding)
of this AVP may be 6, 10, or 14 octets. of this AVP may be 6, 10, or 14 octets.
Session Serial Number (ICRQ, OCRQ) Session Serial Number (ICRQ, OCRQ)
The Session Serial Number AVP, Attribute Type 15, encodes an The Session Serial Number AVP, Attribute Type 15, encodes an
identifier assigned by the LAC or LNS to this session. identifier 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:
skipping to change at page 46, line 20 skipping to change at page 44, line 52
The Session Serial Number is a 32-bit value. The Session Serial Number is a 32-bit value.
The Session Serial Number is intended to be an easy reference for The Session 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. Session Serial Numbers investigating session failure problems. Session Serial Numbers
should be set to progressively increasing values, which are likely to should be set to progressively increasing values, which are likely to
be unique for a significant period of time across all interconnected be unique for a significant period of time across all interconnected
LNSs and LACs. LNSs and LACs.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 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
value and composition.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
10. 10.
Note that in [RFC2661] this value was referred to as the Call Serial End Identifier (ICRQ, OCRQ)
Number. It serves the same purpose and has the same attribute value
and composition.
End Identifier AVP (ICRQ, OCRQ)
The End Identifier AVP, Attribute Type TBA, encodes an identifier The End Identifier AVP, Attribute Type TBA, encodes an identifier
assigned by the LAC or LNS to detect ties in session establishment used to associate an attachment circuit with a request for an L2TP
for the same circuit. session. This AVP allows an LCCE to determine when a session request
"tie" has occurred.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Identifier ... (arbitrary number of octets) | End Identifier ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The End Identifier contains interface, circuit, and other Use of the End Identifier AVP implies that the session follows the
information, depending on the circuit that is being tunneled. For "LAC-LAC" reference model. The End Identifier MUST contain
example, the field may be a simple 4 octet binary value, or an ASCII interface, circuit, or remote system information, depending on the
string. Specification of this format is outside the scope of this circuit that is being tunneled. For example, the field may be a
document. simple 4-octet binary value, a VPN Identifier (as described in
[RFC2764]), or an ASCII string. In the simplest case, this value is
one that is locally configured, though a directory query MAY be made
with this value to obtain additional information about this session
request.
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 Identifier AVP whose value and length matches the End with an End Identifier AVP whose value and length matches the End
Identifier AVP that was just sent in an outgoing ICRQ or OCRQ to the Identifier AVP that was just sent in an outgoing ICRQ or OCRQ to the
same peer. If the two End Identifier values match, an LCCE same peer. If the two values match, an LCCE recognizes that a tie
recognizes that a tie exists (i.e. both LCCEs are attempting to exists (i.e. both LCCEs are attempting to establish sessions for the
establish sessions for the same circuit). The tie is broken by the same circuit). The tie is broken by the dominant LCCE, as determined
dominant LCCE. The "losing" LCCE must send a CDN to its peer to by the Session Tie-Breaker AVP.
cancel the ICRQ or OCRQ that it had sent to the peer.
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. The Length (before hiding) of this AVP is 6 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6
plus the length of the End Identifier value. plus the length of the End Identifier value.
Minimum BPS (OCRQ) Session Tie-Breaker (ICRQ, OCRQ)
The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable The Session Tie-Breaker AVP, Attribute Type TBD, is used to break
line speed for this call. ties when two peers concurrently attempt to establish a session for
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS | | Session Tie-Breaker Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32-bit value indicates the speed in bits per The Session Tie-Breaker Value is an 8-octet random value that is used
second. to choose a session when two LCCEs concurrently request a session for
the same circuit, as determined by the End Identifier AVP. The
recipient of an ICRQ or OCRQ must check to see if an ICRQ or OCRQ,
respectively, already has been sent to the peer for the same circuit,
and if so, must compare its Session Tie-Breaker Value with the one
received. The lower value "wins", and the "loser" MUST send a CDN
with result code set to RC-TBA1 (as defined in Section 5.4.2) to tear
down the session it instigated. In the case in which a tie-breaker
is present on both sides and the value is equal, both sides MUST
discard their sessions and restart session negotiation with new
random Session Tie-Breaker Values.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this If a tie-breaker is received and an outstanding ICRQ/OCRQ has no tie
AVP SHOULD be set to 1. The Length (before hiding) of this AVP is breaker value, the initiator that included the Session Tie-Breaker
10. AVP "wins". If neither side issues a tie breaker, then both sessions
MUST be torn down.
Maximum BPS (OCRQ) This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 0. The Length of this AVP is 14.
The Maximum BPS AVP, Attribute Type 17, encodes the highest Pseudowire Type (ICRQ, OCRQ)
acceptable line speed for this call.
The Pseudowire Type (PW Type) AVP, Attribute Type TBA, indicates the
L2 payload type of the packets that will be tunneled 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 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS | | PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32-bit value indicates the speed in bits per A peer MUST NOT request an incoming or outgoing call with a PW Type
second. AVP specifying a value not advertised in the PW Capabilities List AVP
it received during control connection establishment. Attempts to do
so MUST result in the call being rejected via a CDN with the Result
Code set to RC-TBA2 (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. The Length (before hiding) of this AVP is AVP MUST be 1 for implementations that support only L2TPv3 (see
10. Section 4.7 for L2TPv2 migration issues). The Length (before hiding)
of this AVP is 8.
Pseudo Wire Type (ICRQ, OCRQ) Pseudowire Control Encapsulation (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
The Pseudo Wire Type (PW-Type) AVP, Attribute Type TBA, indicates the The Pseudowire Control Encapsulation (PW Control Encapsulation) AVP,
L2 payload type for packets being transmitted by the sender of this Attribute Type TBA, indicates the type of PW control encapsulation
AVP into the L2TP tunnel. the sender of this AVP requires to be present on all incoming data
packets for this L2TP session.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Control Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Encapsulation Type is a 2-octet unsigned integer with the
following values defined in this document:
0 - There is no control encapsulation present.
1 - The default PW control encapsulation (defined in Section 4.6)
is used.
If this AVP is included in any of the above control messages and has
a value other than zero, the receiving LCCE MUST include the
identified control encapsulation in its outgoing data messages.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8.
Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
The Data Sequencing AVP, Attribute Type TBA, indicates that the
sender requires some or all of the incoming data packets 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudo Wire Type | | Data Sequencing Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined Pseudo Wire Types that may be included in the Pseudo Wire The Data Sequencing Level is a 2-octet unsigned integer indicating
Capabilities List are as follows: the degree of incoming data traffic that the sender of this AVP
wishes to be marked with sequence numbers.
0 - PPP The following values are valid data sequencing levels:
1 - Frame Relay
2 - Ethernet
Additional Types are to be managed by IANA. Values 0 - 32767 are 0 - No incoming data require sequencing.
assignable by IETF Consensus [RFC2434]. The remaining values may be 1 - Only non-IP data require sequencing.
assigned on a First Come First Served basis [RFC2434]. 2 - All incoming data require sequencing.
A peer MUST NOT request an incoming or outgoing call with a Pseudo If a data sequencing level of 0 is specified, there is no need to
Wire Type AVP specifying a value not advertised in the Pseudo Wire send packets with sequence numbers. If sequence numbers are sent,
Receive Capabilities List AVP it received during control connection they will be ignored upon receipt.
establishment. Attempts to do so will result in the call being
rejected.
While it may be possible to transmit and receive different pseudowire If a data sequencing level of 1 is specified, only non-IP traffic
types in either direction across a single L2TP session, it is not carried within the given PW-specific framing should have sequence
required nor recommended as common practice. Thus, if the Pseudo Wire numbers applied. All traffic that can be classified as IP SHOULD be
Type AVP in an ICRQ and ICRP do not match, the session MAY be sent with no sequencing. If a packet is unable to be classified at
disconnected via a CDN with a "session not established due to all or if an implementation is unable to perform such classification,
unsupported PW-Type combination" Result Code defined in Section all packets MUST be provided with sequence numbers (essentially, a
5.4.2. If asymmetric PW-Types are attempted, it should be understood data sequencing level of 2).
in advance that the combination is supported by both vendors. In an
ideal implementation, any PW Type identified in the Pseudo Wire
Receive/Transmit Capabilities List would be usable in all possible
combinations, but it is understood that this might be an unreasonable
goal for some equipment and even some PW-Type Combinations in
general.
This AVP may be hidden (the H bit may be 0 or 1). The M bit for this If a data sequencing level of 2 is specified, all traffic MUST be
AVP MUST be 1 for implementations that support only L2TPv3 (see sequenced.
Section 4.7 for L2TPv2 migration issues). The Length (before hiding)
of this AVP is 8.
Tx Connect Speed (ICCN, OCCN) The method of sequencing is dependent upon the PW type and the PW
control encapsulation. If the PW does not have any other data
sequencing abilities above L2TP, a PW control encapsulation with
sequence number support MUST be requested. Thus, in most cases, it
is a protocol violation to send the Data Sequencing AVP without also
specifying a PW control encapsulation that can be used to provide
sequencing support. If such a violation occurs, the session SHOULD
be disconnected with a Result Code of RC-TBA3.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6.
Tx Connect Speed (ICRQ, ICRP, ICCN)
The Tx Connect Speed BPS AVP, Attribute Type 24, encodes the speed of The Tx Connect Speed BPS AVP, Attribute Type 24, encodes the speed of
the facility chosen for the connection attempt. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) | | BPS (H) | BPS (L) |
skipping to change at page 49, line 30 skipping to change at page 49, line 24
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 1. The Length (before hiding) of this AVP is AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
10. 10.
Rx Connect Speed (ICCN, OCCN) Rx Connect Speed (ICRQ, ICRP, ICCN)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 50, line 9 skipping to change at page 49, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS is a 4-octet value indicating the speed in bits per second. A BPS is a 4-octet value indicating the speed in bits per second. A
value of zero indicates that the speed is indeterminable or that value of zero indicates that the speed is indeterminable or that
there is no physical point-to-point link. 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. The Length (before hiding) of this AVP is AVP SHOULD be set to 0. The Length (before hiding) of this AVP is
10. 10.
Physical Channel ID (ICRQ, OCRP) Physical Channel ID (ICRQ, ICRP, OCRP)
The Physical Channel ID AVP, Attribute Type 25, encodes the vendor- The Physical Channel ID AVP, Attribute Type 25, encodes 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. The Length (before hiding) of this AVP is AVP SHOULD be set to 0. The Length (before hiding) of this AVP is
10. 10.
Private Group ID (ICCN) 5.4.5 Circuit Status AVPs
The Private Group ID AVP, Attribute Type 37, is used by the LAC to
indicate that this call is to be associated with a particular
customer group.
The Attribute Value field for this AVP has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length.
The LNS MAY treat the session as well as network traffic through this
session in a special manner determined by the peer. For example, if
the LNS is individually connected to several private networks using
unregistered addresses, this AVP may be included by the LAC to
indicate that a given call should be associated with one of the
private networks.
The Private Group ID is a string corresponding to a table in the LNS
that defines the particular characteristics of the selected group. A
LAC MAY determine the Private Group ID from a RADIUS response, local
configuration, or some other source.
This AVP may be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6
plus the length of the Private Group ID.
Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP) Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)
The Data Sequencing AVP, Attribute TBA, identifies the sequencing The Circuit Status AVP, Attribute Type TBA, indicates the initial
that will be provided by the sender of this AVP (Seq Send) as well as status of or a status change in the circuit to which the session is
the level to which received data sequence numbers will be honored bound.
(Seq Receive).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq Send | Seq Receive | | Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Seq Send is one octet field identifying what type of sequencing will The A (Active) bit indicates whether the circuit is up/active/ready
be provided for data packets on this session. The following values (1) or down/inactive/not-ready (0).
and sequencing modes are defined:
0 - No data traffic will have sequence numbers The N (New) bit indicates whether the circuit status indication is
1 - Selected data traffic will have sequence numbers for a new circuit (1) or an existing circuit (0).
2 - All data traffic will have sequence numbers
Seq Receive is a one octet field identifying what sequence numbers The remaining bits are reserved for future use. Reserved bits MUST
will be honored (by dropping out of order packets or actively be set to 0 when sending and ignored upon receipt.
reordering packets) for this session when they are sent by the peer.
The following values and sequencing modes are defined:
0 - All sequence numbers on data traffic will be ignored The Circuit Status AVP is used to advertise whether a circuit or
1 - Sequence numbers on selected data traffic will be honored interface bound to an L2TP session is up and ready to send and/or
2 - All sequence numbers will be honored receive traffic. Various circuit types have different names for
these status types. For instance, HDLC primary and secondary
stations refer to a circuit as being "Receive Ready" or "Receive Not
Ready", while Frame Relay refers to a circuit as "Active" or
"Inactive". This AVP adopts the latter terminology, though the
concept remains the same regardless of the PW type being tunneled.
It is always up to the sender of a each individual data packet as to The Circuit Status MUST be advertised in this AVP when an L2TP
what packets will include sequence numbers and which will not. session is initiated by an ICRQ or OCRQ. Often, the circuit type
However, based on the information provided in these AVPs, the sender will be marked Active when initiated, but MAY be advertised as
may wish to alter its policy. For example, if one side of a session Inactive, indicating that an L2TP session is to be created but that
sends a Seq Receive of zero, indicating that all sequence numbers on the interface or circuit is still not ready to pass traffic. The
data traffic would be ignored, its peer may decide to disable sending ICCN, OCCN, and SLI control messages all MAY contain this AVP to
of sequence numbers for that session. Note that this AVP may be update the status of the circuit after establishment of the L2TP
present in an ICRQ or ICCN. If it is present in both, the ICCN always session is requested.
takes precedence. If this AVP is never received in any control
message before establishment of a session, the default of 0 for both
values is assumed (no sequence numbers sent, and all received
sequence numbers will be ignored). For more information on data
sequencing, please see Section 4.6.
This AVP may be used for any basic sequencing field for any PW-type, If additional circuit status information is needed for a given PW
even if the format of the default L2-Specific sublayer defined in type, PW-specific AVPs MUST be defined in a separate document for
section 4.6 is not utilized. that information. This AVP is only for general circuit status
information applicable to all circuit/interface types.
5.4.5 Circuit Status AVPs This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (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
skipping to change at page 53, line 6 skipping to change at page 52, line 13
alignment within the AVP of the following values). Reserved alignment within the AVP of the following values). Reserved
data MUST be zero on sending and ignored upon receipt. data MUST be zero on sending and ignored upon receipt.
Hardware Overruns: Number of receive buffer overruns since call Hardware Overruns: Number of receive buffer overruns since call
was established. was established.
Buffer Overruns: Number of buffer overruns detected since call was Buffer Overruns: Number of buffer overruns detected since call was
established. established.
Timeout Errors: Number of timeouts since call was established. Timeout Errors: Number of timeouts since call was established.
Alignment Errors: Number of alignment errors since call was Alignment Errors: Number of alignment errors since call was
established. established.
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. The Length (before hiding) of this AVP is AVP SHOULD be set to 1. The Length (before hiding) of this AVP is
32. 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 are sent in network tear down L2TP control connections. All data are sent in network
order (high order octets first). Any "reserved" or "empty" fields order (high-order octets first). Any "reserved" or "empty" fields
MUST be sent as 0 values to allow for protocol extensibility. 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 AVP Message Type AVP
Protocol Version
Host Name Host Name
Assigned Control Connection ID Assigned Control Connection ID
Pseudo Wire Transmit Capabilities List Pseudowire Capabilities List
Pseudo Wire Receive Capabilities List
The following AVPs MAY be present in the SCCRQ: The following AVPs MAY be present in the SCCRQ:
Receive Window Size Receive Window Size
Challenge Challenge
Tie Breaker Control Connection Tie-Breaker
Firmware Revision
Vendor Name Vendor Name
6.2 Start-Control-Connection-Reply (SCCRP) 6.2 Start-Control-Connection-Reply (SCCRP)
Start-Control-Connection-Reply (SCCRP) is a 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
Protocol Version
Host Name Host Name
Assigned Control Connection ID Assigned Control Connection ID
Pseudo Wire Transmit Capabilities List Pseudowire Capabilities List
Pseudo Wire Receive Capabilities List
The following AVPs MAY be present in the SCCRP: The following AVPs MAY be present in the SCCRP:
Firmware Revision Firmware Revision
Vendor Name Vendor Name
Receive Window Size Receive Window Size
Challenge Challenge
Challenge Response Challenge Response
6.3 Start-Control-Connection-Connected (SCCCN) 6.3 Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) is a control message sent Start-Control-Connection-Connected (SCCCN) is the control message
in reply to an SCCRP. The SCCCN completes the control connection sent in reply to an SCCRP. The SCCCN completes the control
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:
Challenge Response Challenge Response
6.4 Stop-Control-Connection-Notification (StopCCN) 6.4 Stop-Control-Connection-Notification (StopCCN)
Stop-Control-Connection-Notification (StopCCN) is a 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
Additionally, the Assigned Control Connection ID AVP MUST be present The following AVP MAY be present in the StopCCN:
in the StopCCN if it has been sent in a previous message (see Section
5.4.3). Assigned Control Connection ID
Note that the Assigned Control Connection ID MUST be present if the
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
6.6 Incoming-Call-Request (ICRQ) 6.6 Incoming-Call-Request (ICRQ)
Incoming-Call-Request (ICRQ) is a control message sent by an LCCE to Incoming-Call-Request (ICRQ) is the control message sent by an LCCE
a peer when an incoming call is detected (although the ICRQ may also to a peer when an incoming call is detected (although the ICRQ may
be sent as a result of a local event). It is the first in a three- also be sent as a result of a local event). It is the first in a
message exchange used for establishing a session via an L2TP control three-message exchange used for establishing a session via an L2TP
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
Call Serial Number Call Serial Number
Pseudo Wire Type Pseudowire Type
Pseudowire Control Encapsulation
Data Sequencing
Circuit Status
The following AVP MAY be present in the ICRQ: The following AVP MAY be present in the ICRQ:
Assigned Cookie Assigned Cookie
End Identifier End Identifier
Session Tie-Breaker
Physical Channel ID Physical Channel ID
Data Sequencing Tx Connect Speed
Rx Connect Speed
6.7 Incoming-Call-Reply (ICRP) 6.7 Incoming-Call-Reply (ICRP)
Incoming-Call-Reply (ICRP) is a control message sent by an LCCE in Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in
response to an ICRQ. It is the second in the three-message exchange response to a received ICRQ. It is the second in the three-message
used for establishing sessions within an L2TP control connection. exchange used for establishing sessions within an L2TP control
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 (e.g. 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
Pseudo Wire Type Pseudowire Control Encapsulation
Data Sequencing
Circuit Status
The following AVP MAY be present in the ICRP: The following AVP MAY be present in the ICRP:
Assigned Cookie Assigned Cookie
End Identifier Physical Channel ID
Data Sequencing Tx Connect Speed
Rx Connect Speed
6.8 Incoming-Call-Connected (ICCN) 6.8 Incoming-Call-Connected (ICCN)
Incoming-Call-Connected (ICCN) is a control message sent by the LCCE Incoming-Call-Connected (ICCN) is the control message sent by the
who originally sent an ICRQ, upon receiving an ICRP from its peer. LCCE that originally sent an ICRQ upon receiving an ICRP from its
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 sessions within an L2TP control connection. 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
Remote Session ID Remote Session ID
Tx Connect Speed
The following AVPs MAY be present in the ICCN: The following AVPs MAY be present in the ICCN:
Local Session ID Pseudowire Control Encapsulation
Private Group ID
Rx Connect Speed
Data Sequencing Data Sequencing
Circuit Status
Tx Connect Speed
Rx Connect Speed
6.9 Outgoing-Call-Request (OCRQ) 6.9 Outgoing-Call-Request (OCRQ)
Outgoing-Call-Request (OCRQ) is a control message sent by an LCCE to Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE
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 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
Call Serial Number Call Serial Number
Minimum BPS Pseudowire Type
Maximum BPS Pseudowire Control Encapsulation
Pseudo Wire Data Sequencing
Circuit Status
The following AVPs MAY be present in the OCRQ: The following AVPs MAY be present in the OCRQ:
Assigned Cookie Assigned Cookie
End Identifier End Identifier
Data Sequencing Session Tie-Breaker
6.10 Outgoing-Call-Reply (OCRP) 6.10 Outgoing-Call-Reply (OCRP)
Outgoing-Call-Reply (OCRP) is a control message sent by an LAC to an Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to
LCCE in response to an OCRQ. It is the second in a three-message an LCCE in response to a received OCRQ. It is the second in a three-
exchange used for establishing a session within an L2TP control message exchange used for establishing a session within an L2TP
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
Pseudowire Control Encapsulation
Data Sequencing
Circuit Status
The following AVPs MAY be present in the OCRP: The following AVPs MAY be present in the OCRP:
Assigned Cookie Assigned Cookie
End Identifier
Physical Channel ID Physical Channel ID
6.11 Outgoing-Call-Connected (OCCN) 6.11 Outgoing-Call-Connected (OCCN)
Outgoing-Call-Connected (OCCN) is a control message sent by an LAC to Outgoing-Call-Connected (OCCN) is the control message sent by an LAC
the an LCCE following 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 within an L2TP control connection. 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
Remote Session ID Remote Session ID
Tx Connect Speed
The following AVPs MAY be present in the OCCN: The following AVPs MAY be present in the OCCN:
Local Session ID Pseudowire Control Encapsulation
Rx Connect Speed
Data Sequencing Data Sequencing
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
Local Session ID Local Session ID
Remote Session ID Remote Session ID
Result Code Result Code
Additionally, the Local Session ID AVP MUST be present in the CDN if
it has been sent in a previous message (see Section 5.4.4).
The following AVPs MAY be present in the CDN:
Q.931 Cause Code
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 The WAN-Error-Notify (WEN) is a control message sent from an LAC to an
an LNS to indicate WAN error conditions. The counters in this LNS to indicate WAN error conditions. The counters in this message
message are cumulative. This message should only be sent when an are cumulative. This message should only be sent when an error
error occurs, and not more than once every 60 seconds. The counters occurs, and not more than once every 60 seconds. The counters are
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
Circuit Errors Circuit Errors
Local Session ID Local Session ID
Remote Session ID Remote Session ID
6.14 Set-Link-Info (SLI) 6.14 Set-Link-Info (SLI)
The Set-Link-Info control message is sent by an LAC to indicate a link The Set-Link-Info control message is sent by an LCCE to convey link
status change has taken place for the circuit associated with this L2TP or circuit status change information regarding the circuit associated
session. For example, if PPP renegotiates LCP or a Frame Relay VC with this L2TP session. For example, if PPP renegotiates LCP or a
transitions to Active or Inactive, an SLI message should be sent to Frame Relay VC transitions to Active or Inactive, an SLI message
indicate this event. Precise details of when the SLI is sent, the SHOULD be sent to indicate this event. Precise details of when the
PW-specific AVPs that must be present and their interpretation should be described in the SLI is sent, what PW type-specific AVPs must be present, and how
associated PW-specific documents that require use of this message. those AVPs should be interpreted by the receiving peer are outside
the scope of this document. These details should be described in the
associated payload-specific documents that require use of this
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:
Circuit Status
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 timeout and retransmission behavior, as this is handled in the encode timeout and retransmission behavior, as this is handled in the
underlying reliable control message delivery mechanism (see Section underlying reliable control message delivery mechanism (see Section
4.2). 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. restarted by the initiator.
An invalid control message is defined as (1) a message that contains a An invalid control message is defined as (1) a message that contains
Message Type marked as mandatory (see Section 5.4.1) but that is a Message Type marked as mandatory (see Section 5.4.1) but that is
unknown to the implementation, or (2) a control message that is unknown to the implementation, or (2) a control message that is
received in the wrong state. 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. A malformed yet non-mandatory (M bit is not set) AVP Code sent. A malformed yet non-mandatory (M bit is not set) AVP
within a control message should be handled like an unrecognized within a control message should be handled like an unrecognized non-
non-mandatory AVP. That is, the AVP MUST be ignored (with the mandatory AVP. That is, the AVP MUST be ignored (with the exception
exception of logging a local error message), and the message MUST be of logging a local error message), and the message MUST be accepted.
accepted.
This policy MUST NOT be considered a license to send malformed AVPs, This policy MUST NOT be considered a license to send malformed AVPs,
but rather, a guide towards how to handle an improperly formatted but rather, a guide towards how to handle an improperly formatted
message if one is received. It is impossible to list all potential message if one is received. It is impossible to list all potential
malformations of a given message and give advice for each. That said, malformations of a given message and give advice for each. That
one example of a recoverable, malformed AVP might be if the Rx Connect said, one example of a recoverable, malformed AVP might be if the Rx
Speed AVP, attribute 38, is received with a length of 8 rather than Connect Speed AVP, attribute 38, is received with a length of 8
10, and the BPS given in 2 octets rather than 4. Since the Rx Connect rather than 10, and the BPS given in 2 octets rather than 4. Since
Speed is non-mandatory, this condition should not be considered the Rx Connect Speed is non-mandatory, this condition should not be
catastrophic. As such, the control message should be accepted as if considered catastrophic. As such, the control message should be
the AVP had not been received (with the exception of a local error accepted as if the AVP had not been received (with the exception of a
message being logged). local error message being logged).
In several cases in the following tables, a protocol message is sent, In several cases in the following tables, a protocol message is sent,
and then a "clean up" occurs. Note that, regardless of the initiator and then a "clean up" occurs. Note that, regardless of the initiator
of the control connection destruction, the reliable delivery mechanism of the control connection destruction, the reliable delivery
must be allowed to run (see Section 4.2) before destroying the control mechanism must be allowed to run (see Section 4.2) before destroying
connection. This permits the control connection management messages the control connection. This permits the control connection
to be reliably delivered to the peer. 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 Timing Considerations 7.2 Timing Considerations
Due to the real-time nature of L2 circuit signaling, an LCCE should be Due to the real-time nature of L2 circuit signaling, an LCCE should
implemented using a multi-threaded architecture such that messages be implemented using a multi-threaded architecture such that messages
related to multiple calls are not serialized and blocked. The call related to multiple calls are not serialized and blocked. The call
and connection state figures do not specify exceptions caused by and connection state figures do not specify exceptions caused by
timers. timers.
7.3 Control Connection States 7.3 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 situation, establishment of the control connection. (In a tie-breaker
this is the winner of the tie.) Since either the LAC or the LNS can situation, this is the winner of the tie.) Since either the LAC or
be the originator, a collision can occur. See the Tie Breaker AVP in the LNS can be the originator, a collision can occur. See the
Section 5.4.3 for a description of this and its resolution. Control Connection Tie-Breaker AVP in Section 5.4.3 for a description
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
skipping to change at page 61, line 40 skipping to change at page 61, line 16
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, Clean up, idle wait-ctl-reply Receive SCCRQ, Clean up, idle
lose tie breaker re-queue SCCRQ lose tie-breaker re-queue SCCRQ
for idle state for idle state
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
skipping to change at page 64, line 33 skipping to change at page 64, line 11
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-connection wait-control-connection
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 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
skipping to change at page 70, line 5 skipping to change at page 69, line 27
traces between the LCCEs. traces between the LCCEs.
The Assigned Cookie value MUST be selected in an unpredictable The Assigned Cookie value MUST be selected in an unpredictable
manner. However, the Cookie MUST not be regarded as packet-level manner. However, the Cookie MUST not be regarded as packet-level
authentication or security of any kind. It should be used for authentication or security of any kind. It should be used for
nothing more than simple configuration error detection and nothing more than simple configuration error detection and
identification of misrouted packets. Since the Cookie is sent and identification of misrouted packets. Since the Cookie is sent and
advertised in the clear, it is by no means a true packet-level advertised in the clear, it is by no means a true packet-level
security measure, such as that offered by IPsec. security measure, such as that offered by IPsec.
8.2 Packet Level Security 8.2 Packet-Level Security
Securing L2TP requires that the underlying transport make available Securing L2TP requires that the underlying transport make available
encryption, integrity, and authentication services for all L2TP encryption, integrity, and authentication services for all L2TP
traffic. This secure transport operates on the entire L2TP packet traffic. This secure transport operates on the entire L2TP packet
and is functionally independent of the data being carried on an L2TP and is functionally independent of the data being carried on an L2TP
data session. As such, L2TP is only concerned with confidentiality, data session. As such, L2TP is only concerned with confidentiality,
authenticity, and integrity of the L2TP packets between two LCCEs, authenticity, and integrity of the L2TP packets between two LCCEs,
not unlike link-layer encryption being concerned only about not unlike link layer encryption being concerned only about
protecting the confidentiality of traffic between its physical protecting the confidentiality of traffic between the physical
endpoints. endpoints.
8.3 End-to-End Security 8.3 End-to-End Security
Protecting the L2TP packet stream via a secure transport does, in Protecting the L2TP packet stream via a secure transport does, in
turn, also protect the data within the tunneled session packets while turn, also protect the data within the tunneled session packets while
transported from one LCCE to the other. Such protection should not transported from one LCCE to the other. Such protection should not
be considered a substitution for end-to-end security between be 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 provides packet-level security via ESP When running over IP, IPsec provides packet-level security via ESP
[RFC3193]. All L2TP control and data packets for a particular control [RFC3193]. All L2TP control and data packets for a particular
connection appear as homogeneous UDP/IP data packets to the IPsec control connection appear as homogeneous UDP/IP data packets to the
system. 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
skipping to change at page 71, line 7 skipping to change at page 70, line 26
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 RFC2661 L2TP. [RFC3193] defines the recommended method for securing L2TP as defined
L2TP as defined in this document should posses the same interface to in [RFC2661]. L2TP as defined in this document should possess the
IPsec as RFC2661 when running on UDP/IP. UDP has the added advantage same interface to IPsec as [RFC2661] when running on UDP/IP. UDP has
of being able to provide a native method for IPsec to distinguish the added advantage of being able to provide a native method for
multiple Security Associations (presumably with different policies) IPsec to distinguish multiple Security Associations (presumably with
between the same tunnel endpoints without having to extend the different policies) between the same control connection endpoints
definitions of IPsec or allocate additional IP addresses between without having to extend the definitions of IPsec or allocate
endpoints. Therefore, when securing L2TP with IPsec via RFC3193, additional IP addresses between endpoints. Therefore, when securing
L2TPv3 MUST operate over UDP/IP as described in section 4.1.2. L2TP with IPsec via [RFC3193], L2TPv3 MUST operate over UDP/IP as
described in Section 4.1.2.
9. IANA Considerations 9. 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.
9.1 AVP Attributes 9.1 AVP Attributes
skipping to change at page 72, line 18 skipping to change at page 71, line 40
9.3.2 Error Code Field Values 9.3.2 Error Code Field Values
Values 0-9 are defined in Section 5.4.2. The remaining values are Values 0-9 are defined in Section 5.4.2. The remaining values are
available for assignment upon Expert Review [RFC2434]. available for assignment upon Expert Review [RFC2434].
9.4 AVP Header Bits 9.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].
9.5 L2TP Control Message Header Bits
There are nine remaining reserved bits in the control message header.
Additional bits should only be assigned via a Standards Action
[RFC2434].
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
messages. Using these two bits in L2TPv3 MAY trigger an unforeseen
interoperability problem with L2TPv3 implementations based on L2TPv2.
Therefore, it is recommended that these two bits be utilized last,
after the other reserved bits have been assigned roles.
10. References 10. References
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System
No. 1 (DSS 1) - ISDN user-network interface layer 3 No. 1 (DSS 1) - ISDN user-network interface layer 3
specification for basic call control", Rec. Q.931(I.451), specification for basic call control", Rec. Q.931(I.451),
May 1998 May 1998.
[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.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. September 1981.
[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.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990. Serial Links", RFC 1144, February 1990.
[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.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994. July 1994.
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
1700, October 1994. See also: RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html http://www.iana.org/numbers.html.
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, Coradetti, T., "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996. August 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.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and Lear, E., "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[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.
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote [RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S.,
Authentication Dial In User Service (RADIUS)", RFC 2138, "Remote Authentication Dial In User Service (RADIUS)",
April 1997. RFC 2138, April 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.
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two [RFC2341] Valencia, A., Littlewood, M., and Kolar, T.,
Forwarding (Protocol) L2F", RFC 2341, May 1998. "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341,
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.
[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.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999. RFC 2637, July 1999.
[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.
[RFC3193] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Finland, T., Armitage, G.,
L2TP using IPsec," RFC 3193, November 2001. and Malis, A., "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
[RFC3070] V. Rawat, R. Tio, S. Nanji, R. Verma, "Layer Two Tunneling Protocol [RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory
(L2TP) over Frame Relay," RFC 3070, February 2001. Tunneling via RADIUS", RFC 2809, April 2000.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S.,
Protocols", Addison-Wesley Publishing Company, Inc., March "Securing L2TP using IPsec", RFC 3193, November 2001.
1996, ISBN 0-201-63346-9
[L2TPAAL5] M. Davison, A. Lin, A. Singh, J. Stephens, R. Turner, R. Tio, S. Nanji, [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R.,
"L2TP Over AAL5," Internet Draft, August 2001, "Layer Two Tunneling Protocol (L2TP) over Frame Relay",
draft-ietf-l2tpext-l2tp-atm-02.txt. RFC 3070, February 2001.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The
Protocols", Addison-Wesley Publishing Company, Inc.,
March 1996, ISBN 0-201-63346-9.
[L2TPAAL5] Davison, M., Lin, A., Singh, A., Stephens, J., Turner, R.,
Tio, R., and Nanji, S., "L2TP Over AAL5," Internet Draft,
August 2001, draft-ietf-l2tpext-l2tp-atm-02.txt.
11. Editors' Addresses 11. 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
Gurdeep Singh Pall Gurdeep Singh Pall
skipping to change at page 75, line 5 skipping to change at page 75, line 5
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 described in section 21.6 of TCP/IP Illustrated, Volume I, by
W. Richard Stevens [STEVENS]. W. Richard Stevens [STEVENS].
Slow start and congestion avoidance make use of several variables. Slow start and congestion avoidance make use of several variables. The
The congestion window (CWND) defines the number of packets a sender congestion window (CWND) defines the number of packets a sender may send
may send before waiting for an acknowledgment. The size of CWND before waiting for an acknowledgment. The size of CWND expands and
expands and contracts as described below. Note however, that CWND is contracts as described below. Note, however, that CWND is never allowed to
never allowed to exceed the size of the advertised window obtained exceed the size of the advertised window obtained from the Receive Window
from the Receive Window AVP (in the text below, it is assumed any AVP. (In the text below, it is assumed any increase will be limited by the
increase will be limited by the Receive Window Size). The variable Receive Window Size.) The variable SSTHRESH determines when the sender
SSTHRESH determines when the sender switches from slow start to switches from slow start to congestion avoidance. Slow start is used while
congestion avoidance. Slow start is used while CWND is less than 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
one packet, and SSHTRESH is initialized to the advertised window packet, and SSHTRESH is initialized to the advertised window (obtained from
(obtained from the Receive Window AVP). The sender then transmits one the Receive Window AVP). The sender then transmits one packet and waits
packet and waits for its acknowledgement (either explicit or for its acknowledgment (either explicit or piggybacked). When the
piggybacked). When the acknowledgement is received, the congestion acknowledgment is received, the congestion window is incremented from one
window is incremented from one to two. During slow start, CWND is to two. During slow start, CWND is increased by one packet each time an
increased by one packet each time an ACK (explicit ZLB or piggybacked) ACK (explicit ZLB or piggybacked) is received. Increasing CWND by one on
is received. Increasing CWND by one on each ACK has the effect of each ACK has the effect of doubling CWND with each round trip, resulting in
doubling CWND with each round trip, resulting in an exponential an exponential increase. When the value of CWND reaches SSHTRESH, the slow
increase. When the value of CWND reaches SSHTRESH, the slow start start phase ends and the congestion avoidance phase begins.
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)
retransmission) one half of the CWND is saved in SSTHRESH, and CWND is one-half of the CWND is saved in SSTHRESH, and CWND is set to one. The
set to one. The sender then reenters the slow start phase. 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
example shows the final acknowledgment explicitly sent within a ZLB shows the final acknowledgment explicitly sent within a ZLB ACK message.
ACK message. An alternative would be to piggyback the acknowledgement An alternative would be to piggyback the acknowledgment within a message
within a message sent as a reply to the ICRQ or OCRQ that will likely sent as a reply to the ICRQ or OCRQ that will likely follow from the side
follow from the side that initiated the control connection. 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
<- ZLB <- ZLB
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 impacts: 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 LCCE A LCCE B
------ ------ ------ ------
ICRQ -> ICRQ ->
Nr: 1, Ns: 2 Nr: 1, Ns: 2
(packet lost) <- ICRP (packet lost) <- ICRP
Nr: 3, Ns: 1 Nr: 3, Ns: 1
skipping to change at page 77, line 19 skipping to change at page 77, line 19
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 D: Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 289 change blocks. 
873 lines changed or deleted 830 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/