| blob | 78f01d7e268c3e4d81d342613062cbf48a6439f9 |
7 Network Working Group W. Townsley
8 Request for Comments: 2661 A. Valencia
9 Category: Standards Track cisco Systems
10 A. Rubens
11 Ascend Communications
12 G. Pall
13 G. Zorn
14 Microsoft Corporation
15 B. Palter
16 Redback Networks
17 August 1999
20 Layer Two Tunneling Protocol "L2TP"
22 Status of this Memo
24 This document specifies an Internet standards track protocol for the
25 Internet community, and requests discussion and suggestions for
26 improvements. Please refer to the current edition of the "Internet
27 Official Protocol Standards" (STD 1) for the standardization state
28 and status of this protocol. Distribution of this memo is unlimited.
30 Copyright Notice
32 Copyright (C) The Internet Society (1999). All Rights Reserved.
34 Abstract
36 This document describes the Layer Two Tunneling Protocol (L2TP). STD
37 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP
38 facilitates the tunneling of PPP packets across an intervening
39 network in a way that is as transparent as possible to both end-users
40 and applications.
42 Table of Contents
44 1.0 Introduction.......................................... 3
45 1.1 Specification of Requirements......................... 4
46 1.2 Terminology........................................... 4
47 2.0 Topology.............................................. 8
48 3.0 Protocol Overview..................................... 9
49 3.1 L2TP Header Format.................................... 9
50 3.2 Control Message Types................................. 11
51 4.0 Control Message Attribute Value Pairs................. 12
52 4.1 AVP Format............................................ 13
53 4.2 Mandatory AVPs........................................ 14
54 4.3 Hiding of AVP Attribute Values........................ 14
58 Townsley, et al. Standards Track [Page 1]
59 \f
60 RFC 2661 L2TP August 1999
63 4.4 AVP Summary........................................... 17
64 4.4.1 AVPs Applicable To All Control Messages.......... 17
65 4.4.2 Result and Error Codes........................... 18
66 4.4.3 Control Connection Management AVPs............... 20
67 4.4.4 Call Management AVPs............................. 27
68 4.4.5 Proxy LCP and Authentication AVPs................ 34
69 4.4.6 Call Status AVPs................................. 39
70 5.0 Protocol Operation.................................... 41
71 5.1 Control Connection Establishment...................... 41
72 5.1.1 Tunnel Authentication............................ 42
73 5.2 Session Establishment................................. 42
74 5.2.1 Incoming Call Establishment...................... 42
75 5.2.2 Outgoing Call Establishment...................... 43
76 5.3 Forwarding PPP Frames................................. 43
77 5.4 Using Sequence Numbers on the Data Channel............ 44
78 5.5 Keepalive (Hello)..................................... 44
79 5.6 Session Teardown...................................... 45
80 5.7 Control Connection Teardown........................... 45
81 5.8 Reliable Delivery of Control Messages................. 46
82 6.0 Control Connection Protocol Specification............. 48
83 6.1 Start-Control-Connection-Request (SCCRQ).............. 48
84 6.2 Start-Control-Connection-Reply (SCCRP)................ 48
85 6.3 Start-Control-Connection-Connected (SCCCN)............ 49
86 6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
87 6.5 Hello (HELLO)......................................... 49
88 6.6 Incoming-Call-Request (ICRQ).......................... 50
89 6.7 Incoming-Call-Reply (ICRP)............................ 51
90 6.8 Incoming-Call-Connected (ICCN)........................ 51
91 6.9 Outgoing-Call-Request (OCRQ).......................... 52
92 6.10 Outgoing-Call-Reply (OCRP)........................... 53
93 6.11 Outgoing-Call-Connected (OCCN)....................... 53
94 6.12 Call-Disconnect-Notify (CDN)......................... 53
95 6.13 WAN-Error-Notify (WEN)............................... 54
96 6.14 Set-Link-Info (SLI).................................. 54
97 7.0 Control Connection State Machines..................... 54
98 7.1 Control Connection Protocol Operation................. 55
99 7.2 Control Connection States............................. 56
100 7.2.1 Control Connection Establishment................. 56
101 7.3 Timing considerations................................. 58
102 7.4 Incoming calls........................................ 58
103 7.4.1 LAC Incoming Call States......................... 60
104 7.4.2 LNS Incoming Call States......................... 62
105 7.5 Outgoing calls........................................ 63
106 7.5.1 LAC Outgoing Call States......................... 64
107 7.5.2 LNS Outgoing Call States......................... 66
108 7.6 Tunnel Disconnection.................................. 67
109 8.0 L2TP Over Specific Media.............................. 67
110 8.1 L2TP over UDP/IP...................................... 68
114 Townsley, et al. Standards Track [Page 2]
115 \f
116 RFC 2661 L2TP August 1999
119 8.2 IP.................................................... 69
120 9.0 Security Considerations............................... 69
121 9.1 Tunnel Endpoint Security.............................. 70
122 9.2 Packet Level Security................................. 70
123 9.3 End to End Security................................... 70
124 9.4 L2TP and IPsec........................................ 71
125 9.5 Proxy PPP Authentication.............................. 71
126 10.0 IANA Considerations.................................. 71
127 10.1 AVP Attributes....................................... 71
128 10.2 Message Type AVP Values.............................. 72
129 10.3 Result Code AVP Values............................... 72
130 10.3.1 Result Code Field Values........................ 72
131 10.3.2 Error Code Field Values......................... 72
132 10.4 Framing Capabilities & Bearer Capabilities........... 72
133 10.5 Proxy Authen Type AVP Values......................... 72
134 10.6 AVP Header Bits...................................... 73
135 11.0 References........................................... 73
136 12.0 Acknowledgments...................................... 74
137 13.0 Authors' Addresses................................... 75
138 Appendix A: Control Channel Slow Start and Congestion
139 Avoidance..................................... 76
140 Appendix B: Control Message Examples...................... 77
141 Appendix C: Intellectual Property Notice.................. 79
142 Full Copyright Statement.................................. 80
144 1.0 Introduction
146 PPP [RFC1661] defines an encapsulation mechanism for transporting
147 multiprotocol packets across layer 2 (L2) point-to-point links.
148 Typically, a user obtains a L2 connection to a Network Access Server
149 (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN,
150 ADSL, etc.) and then runs PPP over that connection. In such a
151 configuration, the L2 termination point and PPP session endpoint
152 reside on the same physical device (i.e., the NAS).
154 L2TP extends the PPP model by allowing the L2 and PPP endpoints to
155 reside on different devices interconnected by a packet-switched
156 network. With L2TP, a user has an L2 connection to an access
157 concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the
158 concentrator then tunnels individual PPP frames to the NAS. This
159 allows the actual processing of PPP packets to be divorced from the
160 termination of the L2 circuit.
162 One obvious benefit of such a separation is that instead of requiring
163 the L2 connection terminate at the NAS (which may require a
164 long-distance toll charge), the connection may terminate at a (local)
165 circuit concentrator, which then extends the logical PPP session over
170 Townsley, et al. Standards Track [Page 3]
171 \f
172 RFC 2661 L2TP August 1999
175 a shared infrastructure such as frame relay circuit or the Internet.
176 From the user's perspective, there is no functional difference between
177 having the L2 circuit terminate in a NAS directly or using L2TP.
179 L2TP may also solve the multilink hunt-group splitting problem.
180 Multilink PPP [RFC1990] requires that all channels composing a
181 multilink bundle be grouped at a single Network Access Server (NAS).
182 Due to its ability to project a PPP session to a location other than
183 the point at which it was physically received, L2TP can be used to
184 make all channels terminate at a single NAS. This allows multilink
185 operation even when the calls are spread across distinct physical
186 NASs.
188 This document defines the necessary control protocol for on-demand
189 creation of tunnels between two nodes and the accompanying
190 encapsulation for multiplexing multiple, tunneled PPP sessions.
192 1.1 Specification of Requirements
194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
196 document are to be interpreted as described in [RFC2119].
198 1.2 Terminology
200 Analog Channel
202 A circuit-switched communication path which is intended to carry
203 3.1 kHz audio in each direction.
205 Attribute Value Pair (AVP)
207 The variable length concatenation of a unique Attribute
208 (represented by an integer) and a Value containing the actual
209 value identified by the attribute. Multiple AVPs make up Control
210 Messages which are used in the establishment, maintenance, and
211 teardown of tunnels.
213 Call
215 A connection (or attempted connection) between a Remote System and
216 LAC. For example, a telephone call through the PSTN. A Call
217 (Incoming or Outgoing) which is successfully established between a
218 Remote System and LAC results in a corresponding L2TP Session
219 within a previously established Tunnel between the LAC and LNS.
220 (See also: Session, Incoming Call, Outgoing Call).
226 Townsley, et al. Standards Track [Page 4]
227 \f
228 RFC 2661 L2TP August 1999
231 Called Number
233 An indication to the receiver of a call as to what telephone
234 number the caller used to reach it.
236 Calling Number
238 An indication to the receiver of a call as to the telephone number
239 of the caller.
241 CHAP
243 Challenge Handshake Authentication Protocol [RFC1994], a PPP
244 cryptographic challenge/response authentication protocol in which
245 the cleartext password is not passed over the line.
247 Control Connection
249 A control connection operates in-band over a tunnel to control the
250 establishment, release, and maintenance of sessions and of the
251 tunnel itself.
253 Control Messages
255 Control messages are exchanged between LAC and LNS pairs,
256 operating in-band within the tunnel protocol. Control messages
257 govern aspects of the tunnel and sessions within the tunnel.
259 Digital Channel
261 A circuit-switched communication path which is intended to carry
262 digital information in each direction.
264 DSLAM
266 Digital Subscriber Line (DSL) Access Module. A network device used
267 in the deployment of DSL service. This is typically a concentrator
268 of individual DSL lines located in a central office (CO) or local
269 exchange.
271 Incoming Call
273 A Call received at an LAC to be tunneled to an LNS (see Call,
274 Outgoing Call).
282 Townsley, et al. Standards Track [Page 5]
283 \f
284 RFC 2661 L2TP August 1999
287 L2TP Access Concentrator (LAC)
289 A node that acts as one side of an L2TP tunnel endpoint and is a
290 peer to the L2TP Network Server (LNS). The LAC sits between an
291 LNS and a remote system and forwards packets to and from each.
292 Packets sent from the LAC to the LNS requires tunneling with the
293 L2TP protocol as defined in this document. The connection from
294 the LAC to the remote system is either local (see: Client LAC) or
295 a PPP link.
297 L2TP Network Server (LNS)
299 A node that acts as one side of an L2TP tunnel endpoint and is a
300 peer to the L2TP Access Concentrator (LAC). The LNS is the
301 logical termination point of a PPP session that is being tunneled
302 from the remote system by the LAC.
304 Management Domain (MD)
306 A network or networks under the control of a single
307 administration, policy or system. For example, an LNS's Management
308 Domain might be the corporate network it serves. An LAC's
309 Management Domain might be the Internet Service Provider that owns
310 and manages it.
312 Network Access Server (NAS)
314 A device providing local network access to users across a remote
315 access network such as the PSTN. An NAS may also serve as an LAC,
316 LNS or both.
318 Outgoing Call
320 A Call placed by an LAC on behalf of an LNS (see Call, Incoming
321 Call).
323 Peer
325 When used in context with L2TP, peer refers to either the LAC or
326 LNS. An LAC's Peer is an LNS and vice versa. When used in context
327 with PPP, a peer is either side of the PPP connection.
329 POTS
331 Plain Old Telephone Service.
338 Townsley, et al. Standards Track [Page 6]
339 \f
340 RFC 2661 L2TP August 1999
343 Remote System
345 An end-system or router attached to a remote access network (i.e.
346 a PSTN), which is either the initiator or recipient of a call.
347 Also referred to as a dial-up or virtual dial-up client.
349 Session
351 L2TP is connection-oriented. The LNS and LAC maintain state for
352 each Call that is initiated or answered by an LAC. An L2TP Session
353 is created between the LAC and LNS when an end-to-end PPP
354 connection is established between a Remote System and the LNS.
355 Datagrams related to the PPP connection are sent over the Tunnel
356 between the LAC and LNS. There is a one to one relationship
357 between established L2TP Sessions and their associated Calls. (See
358 also: Call).
360 Tunnel
362 A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a
363 Control Connection and zero or more L2TP Sessions. The Tunnel
364 carries encapsulated PPP datagrams and Control Messages between
365 the LAC and the LNS.
367 Zero-Length Body (ZLB) Message
369 A control packet with only an L2TP header. ZLB messages are used
370 for explicitly acknowledging packets on the reliable control
371 channel.
394 Townsley, et al. Standards Track [Page 7]
395 \f
396 RFC 2661 L2TP August 1999
399 2.0 Topology
401 The following diagram depicts a typical L2TP scenario. The goal is to
402 tunnel PPP frames between the Remote System or LAC Client and an LNS
403 located at a Home LAN.
405 [Home LAN]
406 [LAC Client]----------+ |
407 ____|_____ +--[Host]
408 | | |
409 [LAC]---------| Internet |-----[LNS]-----+
410 | |__________| |
411 _____|_____ :
412 | |
413 | PSTN |
414 [Remote]--| Cloud |
415 [System] | | [Home LAN]
416 |___________| |
417 | ______________ +---[Host]
418 | | | |
419 [LAC]-------| Frame Relay |---[LNS]-----+
420 | or ATM Cloud | |
421 |______________| :
423 The Remote System initiates a PPP connection across the PSTN Cloud to
424 an LAC. The LAC then tunnels the PPP connection across the Internet,
425 Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is
426 obtained. The Remote System is provided addresses from the HOME LAN
428 via PPP NCP negotiation. Authentication, Authorization and Accounting
429 may be provided by the Home LAN's Management Domain as if the user
430 were connected to a Network Access Server directly.
432 A LAC Client (a Host which runs L2TP natively) may also participate
433 in tunneling to the Home LAN without use of a separate LAC. In this
434 case, the Host containing the LAC Client software already has a
435 connection to the public Internet. A "virtual" PPP connection is then
436 created and the local L2TP LAC Client software creates a tunnel to
437 the LNS. As in the above case, Addressing, Authentication,
438 Authorization and Accounting will be provided by the Home LAN's
439 Management Domain.
450 Townsley, et al. Standards Track [Page 8]
451 \f
452 RFC 2661 L2TP August 1999
455 3.0 Protocol Overview
457 L2TP utilizes two types of messages, control messages and data
458 messages. Control messages are used in the establishment, maintenance
459 and clearing of tunnels and calls. Data messages are used to
460 encapsulate PPP frames being carried over the tunnel. Control
461 messages utilize a reliable Control Channel within L2TP to guarantee
462 delivery (see section 5.1 for details). Data messages are not
463 retransmitted when packet loss occurs.
465 +-------------------+
466 | PPP Frames |
467 +-------------------+ +-----------------------+
468 | L2TP Data Messages| | L2TP Control Messages |
469 +-------------------+ +-----------------------+
470 | L2TP Data Channel | | L2TP Control Channel |
471 | (unreliable) | | (reliable) |
472 +------------------------------------------------+
473 | Packet Transport (UDP, FR, ATM, etc.) |
474 +------------------------------------------------+
476 Figure 3.0 L2TP Protocol Structure
478 Figure 3.0 depicts the relationship of PPP frames and Control
479 Messages over the L2TP Control and Data Channels. PPP Frames are
480 passed over an unreliable Data Channel encapsulated first by an L2TP
481 header and then a Packet Transport such as UDP, Frame Relay, ATM,
482 etc. Control messages are sent over a reliable L2TP Control Channel
483 which transmits packets in-band over the same Packet Transport.
485 Sequence numbers are required to be present in all control messages
486 and are used to provide reliable delivery on the Control Channel.
487 Data Messages may use sequence numbers to reorder packets and detect
488 lost packets.
490 All values are placed into their respective fields and sent in
491 network order (high order octets first).
493 3.1 L2TP Header Format
495 L2TP packets for the control channel and data channel share a common
496 header format. In each case where a field is optional, its space does
497 not exist in the message if the field is marked not present. Note
498 that while optional on data messages, the Length, Ns, and Nr fields
499 marked as optional below, are required to be present on all control
500 messages.
506 Townsley, et al. Standards Track [Page 9]
507 \f
508 RFC 2661 L2TP August 1999
511 This header is formatted:
513 0 1 2 3
514 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
515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
516 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
518 | Tunnel ID | Session ID |
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 | Ns (opt) | Nr (opt) |
521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
522 | Offset Size (opt) | Offset pad... (opt)
523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525 Figure 3.1 L2TP Message Header
527 The Type (T) bit indicates the type of message. It is set to 0 for a
528 data message and 1 for a control message.
530 If the Length (L) bit is 1, the Length field is present. This bit
531 MUST be set to 1 for control messages.
533 The x bits are reserved for future extensions. All reserved bits MUST
534 be set to 0 on outgoing messages and ignored on incoming messages.
536 If the Sequence (S) bit is set to 1 the Ns and Nr fields are present.
537 The S bit MUST be set to 1 for control messages.
539 If the Offset (O) bit is 1, the Offset Size field is present. The O
540 bit MUST be set to 0 (zero) for control messages.
542 If the Priority (P) bit is 1, this data message should receive
543 preferential treatment in its local queuing and transmission. LCP
544 echo requests used as a keepalive for the link, for instance, should
545 generally be sent with this bit set to 1. Without it, a temporary
546 interval of local congestion could result in interference with
547 keepalive messages and unnecessary loss of the link. This feature is
548 only for use with data messages. The P bit MUST be set to 0 for all
549 control messages.
551 Ver MUST be 2, indicating the version of the L2TP data message header
552 described in this document. The value 1 is reserved to permit
553 detection of L2F [RFC2341] packets should they arrive intermixed with
554 L2TP packets. Packets received with an unknown Ver field MUST be
555 discarded.
557 The Length field indicates the total length of the message in octets.
562 Townsley, et al. Standards Track [Page 10]
563 \f
564 RFC 2661 L2TP August 1999
567 Tunnel ID indicates the identifier for the control connection. L2TP
568 tunnels are named by identifiers that have local significance only.
569 That is, the same tunnel will be given different Tunnel IDs by each
570 end of the tunnel. Tunnel ID in each message is that of the intended
571 recipient, not the sender. Tunnel IDs are selected and exchanged as
572 Assigned Tunnel ID AVPs during the creation of a tunnel.
574 Session ID indicates the identifier for a session within a tunnel.
575 L2TP sessions are named by identifiers that have local significance
576 only. That is, the same session will be given different Session IDs
577 by each end of the session. Session ID in each message is that of the
578 intended recipient, not the sender. Session IDs are selected and
579 exchanged as Assigned Session ID AVPs during the creation of a
580 session.
582 Ns indicates the sequence number for this data or control message,
583 beginning at zero and incrementing by one (modulo 2**16) for each
584 message sent. See Section 5.8 and 5.4 for more information on using
585 this field.
587 Nr indicates the sequence number expected in the next control message
588 to be received. Thus, Nr is set to the Ns of the last in-order
589 message received plus one (modulo 2**16). In data messages, Nr is
590 reserved and, if present (as indicated by the S-bit), MUST be ignored
591 upon receipt. See section 5.8 for more information on using this
592 field in control messages.
594 The Offset Size field, if present, specifies the number of octets
595 past the L2TP header at which the payload data is expected to start.
596 Actual data within the offset padding is undefined. If the offset
597 field is present, the L2TP header ends after the last octet of the
598 offset padding.
600 3.2 Control Message Types
602 The Message Type AVP (see section 4.4.1) defines the specific type of
603 control message being sent. Recall from section 3.1 that this is only
604 for control messages, that is, messages with the T-bit set to 1.
618 Townsley, et al. Standards Track [Page 11]
619 \f
620 RFC 2661 L2TP August 1999
623 This document defines the following control message types (see
624 Section 6.1 through 6.14 for details on the construction and use of
625 each message):
627 Control Connection Management
629 0 (reserved)
631 1 (SCCRQ) Start-Control-Connection-Request
632 2 (SCCRP) Start-Control-Connection-Reply
633 3 (SCCCN) Start-Control-Connection-Connected
634 4 (StopCCN) Stop-Control-Connection-Notification
635 5 (reserved)
636 6 (HELLO) Hello
638 Call Management
640 7 (OCRQ) Outgoing-Call-Request
641 8 (OCRP) Outgoing-Call-Reply
642 9 (OCCN) Outgoing-Call-Connected
643 10 (ICRQ) Incoming-Call-Request
644 11 (ICRP) Incoming-Call-Reply
645 12 (ICCN) Incoming-Call-Connected
646 13 (reserved)
647 14 (CDN) Call-Disconnect-Notify
649 Error Reporting
651 15 (WEN) WAN-Error-Notify
653 PPP Session Control
655 16 (SLI) Set-Link-Info
657 4.0 Control Message Attribute Value Pairs
659 To maximize extensibility while still permitting interoperability, a
660 uniform method for encoding message types and bodies is used
661 throughout L2TP. This encoding will be termed AVP (Attribute-Value
662 Pair) in the remainder of this document.
674 Townsley, et al. Standards Track [Page 12]
675 \f
676 RFC 2661 L2TP August 1999
679 4.1 AVP Format
681 Each AVP is encoded as:
683 0 1 2 3
684 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
685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
686 |M|H| rsvd | Length | Vendor ID |
687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
688 | Attribute Type | Attribute Value...
689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
690 [until Length is reached]... |
691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
693 The first six bits are a bit mask, describing the general attributes
694 of the AVP.
696 Two bits are defined in this document, the remaining are reserved for
697 future extensions. Reserved bits MUST be set to 0. An AVP received
698 with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
700 Mandatory (M) bit: Controls the behavior required of an
701 implementation which receives an AVP which it does not recognize. If
702 the M bit is set on an unrecognized AVP within a message associated
703 with a particular session, the session associated with this message
704 MUST be terminated. If the M bit is set on an unrecognized AVP within
705 a message associated with the overall tunnel, the entire tunnel (and
706 all sessions within) MUST be terminated. If the M bit is not set, an
707 unrecognized AVP MUST be ignored. The control message must then
708 continue to be processed as if the AVP had not been present.
710 Hidden (H) bit: Identifies the hiding of data in the Attribute Value
711 field of an AVP. This capability can be used to avoid the passing of
712 sensitive data, such as user passwords, as cleartext in an AVP.
713 Section 4.3 describes the procedure for performing AVP hiding.
715 Length: Encodes the number of octets (including the Overall Length
716 and bitmask fields) contained in this AVP. The Length may be
717 calculated as 6 + the length of the Attribute Value field in octets.
718 The field itself is 10 bits, permitting a maximum of 1023 octets of
719 data in a single AVP. The minimum Length of an AVP is 6. If the
720 length is 6, then the Attribute Value field is absent.
722 Vendor ID: The IANA assigned "SMI Network Management Private
723 Enterprise Codes" [RFC1700] value. The value 0, corresponding to
724 IETF adopted attribute values, is used for all AVPs defined within
725 this document. Any vendor wishing to implement their own L2TP
726 extensions can use their own Vendor ID along with private Attribute
730 Townsley, et al. Standards Track [Page 13]
731 \f
732 RFC 2661 L2TP August 1999
735 values, guaranteeing that they will not collide with any other
736 vendor's extensions, nor with future IETF extensions. Note that there
737 are 16 bits allocated for the Vendor ID, thus limiting this feature
738 to the first 65,535 enterprises.
740 Attribute Type: A 2 octet value with a unique interpretation across
741 all AVPs defined under a given Vendor ID.
743 Attribute Value: This is the actual value as indicated by the Vendor
744 ID and Attribute Type. It follows immediately after the Attribute
745 Type field, and runs for the remaining octets indicated in the Length
746 (i.e., Length minus 6 octets of header). This field is absent if the
747 Length is 6.
749 4.2 Mandatory AVPs
751 Receipt of an unknown AVP that has the M-bit set is catastrophic to
752 the session or tunnel it is associated with. Thus, the M bit should
753 only be defined for AVPs which are absolutely crucial to proper
754 operation of the session or tunnel. Further, in the case where the
755 LAC or LNS receives an unknown AVP with the M-bit set and shuts down
756 the session or tunnel accordingly, it is the full responsibility of
757 the peer sending the Mandatory AVP to accept fault for causing an
758 non-interoperable situation. Before defining an AVP with the M-bit
759 set, particularly a vendor-specific AVP, be sure that this is the
760 intended consequence.
762 When an adequate alternative exists to use of the M-bit, it should be
763 utilized. For example, rather than simply sending an AVP with the M-
764 bit set to determine if a specific extension exists, availability may
765 be identified by sending an AVP in a request message and expecting a
766 corresponding AVP in a reply message.
768 Use of the M-bit with new AVPs (those not defined in this document)
769 MUST provide the ability to configure the associated feature off,
770 such that the AVP is either not sent, or sent with the M-bit not set.
772 4.3 Hiding of AVP Attribute Values
774 The H bit in the header of each AVP provides a mechanism to indicate
775 to the receiving peer whether the contents of the AVP are hidden or
776 present in cleartext. This feature can be used to hide sensitive
777 control message data such as user passwords or user IDs.
779 The H bit MUST only be set if a shared secret exists between the LAC
780 and LNS. The shared secret is the same secret that is used for tunnel
781 authentication (see Section 5.1.1). If the H bit is set in any
786 Townsley, et al. Standards Track [Page 14]
787 \f
788 RFC 2661 L2TP August 1999
791 AVP(s) in a given control message, a Random Vector AVP must also be
792 present in the message and MUST precede the first AVP having an H bit
793 of 1.
795 Hiding an AVP value is done in several steps. The first step is to
796 take the length and value fields of the original (cleartext) AVP and
797 encode them into a Hidden AVP Subformat as follows:
799 0 1 2 3
800 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
801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 | Length of Original Value | Original Attribute Value ...
803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804 ... | Padding ...
805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
807 Length of Original Attribute Value: This is length of the Original
808 Attribute Value to be obscured in octets. This is necessary to
809 determine the original length of the Attribute Value which is lost
810 when the additional Padding is added.
812 Original Attribute Value: Attribute Value that is to be obscured.
814 Padding: Random additional octets used to obscure length of the
815 Attribute Value that is being hidden.
817 To mask the size of the data being hidden, the resulting subformat
818 MAY be padded as shown above. Padding does NOT alter the value placed
819 in the Length of Original Attribute Value field, but does alter the
820 length of the resultant AVP that is being created. For example, If an
821 Attribute Value to be hidden is 4 octets in length, the unhidden AVP
822 length would be 10 octets (6 + Attribute Value length). After hiding,
823 the length of the AVP will become 6 + Attribute Value length + size
824 of the Length of Original Attribute Value field + Padding. Thus, if
825 Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24
826 octets.
828 Next, An MD5 hash is performed on the concatenation of:
830 + the 2 octet Attribute number of the AVP
831 + the shared secret
832 + an arbitrary length random vector
834 The value of the random vector used in this hash is passed in the
835 value field of a Random Vector AVP. This Random Vector AVP must be
836 placed in the message by the sender before any hidden AVPs. The same
837 random vector may be used for more than one hidden AVP in the same
842 Townsley, et al. Standards Track [Page 15]
843 \f
844 RFC 2661 L2TP August 1999
847 message. If a different random vector is used for the hiding of
848 subsequent AVPs then a new Random Vector AVP must be placed in the
849 command message before the first AVP to which it applies.
851 The MD5 hash value is then XORed with the first 16 octet (or less)
852 segment of the Hidden AVP Subformat and placed in the Attribute Value
853 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16
854 octets, the Subformat is transformed as if the Attribute Value field
855 had been padded to 16 octets before the XOR, but only the actual
856 octets present in the Subformat are modified, and the length of the
857 AVP is not altered.
859 If the Subformat is longer than 16 octets, a second one-way MD5 hash
860 is calculated over a stream of octets consisting of the shared secret
861 followed by the result of the first XOR. That hash is XORed with the
862 second 16 octet (or less) segment of the Subformat and placed in the
863 corresponding octets of the Value field of the Hidden AVP.
865 If necessary, this operation is repeated, with the shared secret used
866 along with each XOR result to generate the next hash to XOR the next
867 segment of the value with.
869 The hiding method was adapted from RFC 2138 [RFC2138] which was taken
870 from the "Mixing in the Plaintext" section in the book "Network
871 Security" by Kaufman, Perlman and Speciner [KPS]. A detailed
872 explanation of the method follows:
874 Call the shared secret S, the Random Vector RV, and the Attribute
875 Value AV. Break the value field into 16-octet chunks p1, p2, etc.
876 with the last one padded at the end with random data to a 16-octet
877 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also
878 define intermediate values b1, b2, etc.
880 b1 = MD5(AV + S + RV) c(1) = p1 xor b1
881 b2 = MD5(S + c(1)) c(2) = p2 xor b2
882 . .
883 . .
884 . .
885 bi = MD5(S + c(i-1)) c(i) = pi xor bi
887 The String will contain c(1)+c(2)+...+c(i) where + denotes
888 concatenation.
890 On receipt, the random vector is taken from the last Random Vector
891 AVP encountered in the message prior to the AVP to be unhidden. The
892 above process is then reversed to yield the original value.
898 Townsley, et al. Standards Track [Page 16]
899 \f
900 RFC 2661 L2TP August 1999
903 4.4 AVP Summary
905 The following sections contain a list of all L2TP AVPs defined in
906 this document.
908 Following the name of the AVP is a list indicating the message types
909 that utilize each AVP. After each AVP title follows a short
910 description of the purpose of the AVP, a detail (including a graphic)
911 of the format for the Attribute Value, and any additional information
912 needed for proper use of the avp.
914 4.4.1 AVPs Applicable To All Control Messages
916 Message Type (All Messages)
918 The Message Type AVP, Attribute Type 0, identifies the control
919 message herein and defines the context in which the exact meaning
920 of the following AVPs will be determined.
922 The Attribute Value field for this AVP has the following format:
924 0 1
925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
927 | Message Type |
928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
930 The Message Type is a 2 octet unsigned integer.
932 The Message Type AVP MUST be the first AVP in a message,
933 immediately following the control message header (defined in
934 section 3.1). See Section 3.2 for the list of defined control
935 message types and their identifiers.
937 The Mandatory (M) bit within the Message Type AVP has special
938 meaning. Rather than an indication as to whether the AVP itself
939 should be ignored if not recognized, it is an indication as to
940 whether the control message itself should be ignored. Thus, if the
941 M-bit is set within the Message Type AVP and the Message Type is
942 unknown to the implementation, the tunnel MUST be cleared. If the
943 M-bit is not set, then the implementation may ignore an unknown
944 message type. The M-bit MUST be set to 1 for all message types
945 defined in this document. This AVP may not be hidden (the H-bit
946 MUST be 0). The Length of this AVP is 8.
954 Townsley, et al. Standards Track [Page 17]
955 \f
956 RFC 2661 L2TP August 1999
959 Random Vector (All Messages)
961 The Random Vector AVP, Attribute Type 36, is used to enable the
962 hiding of the Attribute Value of arbitrary AVPs.
964 The Attribute Value field for this AVP has the following format:
966 0 1 2 3
967 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
968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
969 | Random Octet String ...
970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
972 The Random Octet String may be of arbitrary length, although a
973 random vector of at least 16 octets is recommended. The string
974 contains the random vector for use in computing the MD5 hash to
975 retrieve or hide the Attribute Value of a hidden AVP (see Section
976 4.2).
978 More than one Random Vector AVP may appear in a message, in which
979 case a hidden AVP uses the Random Vector AVP most closely
980 preceding it. This AVP MUST precede the first AVP with the H bit
981 set.
983 The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be
984 hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the
985 length of the Random Octet String.
987 4.4.2 Result and Error Codes
989 Result Code (CDN, StopCCN)
991 The Result Code AVP, Attribute Type 1, indicates the reason for
992 terminating the control channel or session.
994 The Attribute Value field for this AVP has the following format:
996 0 1 2 3
997 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
998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
999 | Result Code | Error Code (opt) |
1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1001 | Error Message (opt) ...
1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1004 The Result Code is a 2 octet unsigned integer. The optional Error
1005 Code is a 2 octet unsigned integer. An optional Error Message can
1006 follow the Error Code field. Presence of the Error Code and
1010 Townsley, et al. Standards Track [Page 18]
1011 \f
1012 RFC 2661 L2TP August 1999
1015 Message are indicated by the AVP Length field. The Error Message
1016 contains an arbitrary string providing further (human readable)
1017 text associated with the condition. Human readable text in all
1018 error messages MUST be provided in the UTF-8 charset using the
1019 Default Language [RFC2277].
1021 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1022 this AVP MUST be set to 1. The Length is 8 if there is no Error
1023 Code or Message, 10 if there is an Error Code and no Error Message
1024 or 10 + the length of the Error Message if there is an Error Code
1025 and Message.
1027 Defined Result Code values for the StopCCN message are:
1029 0 - Reserved
1030 1 - General request to clear control connection
1031 2 - General error--Error Code indicates the problem
1032 3 - Control channel already exists
1033 4 - Requester is not authorized to establish a control
1034 channel
1035 5 - The protocol version of the requester is not
1036 supported
1037 Error Code indicates highest version supported
1038 6 - Requester is being shut down
1039 7 - Finite State Machine error
1041 Defined Result Code values for the CDN message are:
1043 0 - Reserved
1044 1 - Call disconnected due to loss of carrier
1045 2 - Call disconnected for the reason indicated
1046 in error code
1047 3 - Call disconnected for administrative reasons
1048 4 - Call failed due to lack of appropriate facilities
1049 being available (temporary condition)
1050 5 - Call failed due to lack of appropriate facilities being
1051 available (permanent condition)
1052 6 - Invalid destination
1053 7 - Call failed due to no carrier detected
1054 8 - Call failed due to detection of a busy signal
1055 9 - Call failed due to lack of a dial tone
1056 10 - Call was not established within time allotted by LAC
1057 11 - Call was connected but no appropriate framing was
1058 detected
1060 The Error Codes defined below pertain to types of errors that are
1061 not specific to any particular L2TP request, but rather to
1062 protocol or message format errors. If an L2TP reply indicates in
1066 Townsley, et al. Standards Track [Page 19]
1067 \f
1068 RFC 2661 L2TP August 1999
1071 its Result Code that a general error occurred, the General Error
1072 value should be examined to determine what the error was. The
1073 currently defined General Error codes and their meanings are:
1075 0 - No general error
1076 1 - No control connection exists yet for this LAC-LNS pair
1077 2 - Length is wrong
1078 3 - One of the field values was out of range or
1079 reserved field was non-zero
1080 4 - Insufficient resources to handle this operation now
1081 5 - The Session ID is invalid in this context
1082 6 - A generic vendor-specific error occurred in the LAC
1083 7 - Try another. If LAC is aware of other possible LNS
1084 destinations, it should try one of them. This can be
1085 used to guide an LAC based on LNS policy, for instance,
1086 the existence of multilink PPP bundles.
1087 8 - Session or tunnel was shutdown due to receipt of an unknown
1088 AVP with the M-bit set (see section 4.2). The Error Message
1089 SHOULD contain the attribute of the offending AVP in (human
1090 readable) text form.
1092 When a General Error Code of 6 is used, additional information
1093 about the error SHOULD be included in the Error Message field.
1095 4.4.3 Control Connection Management AVPs
1097 Protocol Version (SCCRP, SCCRQ)
1099 The Protocol Version AVP, Attribute Type 2, indicates the L2TP
1100 protocol version of the sender.
1102 The Attribute Value field for this AVP has the following format:
1104 0 1
1105 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1107 | Ver | Rev |
1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1110 The Ver field is a 1 octet unsigned integer containing the value
1111 1. Rev field is a 1 octet unsigned integer containing 0. This
1112 pertains to L2TP protocol version 1, revision 0. Note this is not
1113 the same version number that is included in the header of each
1114 message.
1116 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1117 this AVP MUST be set to 1. The Length of this AVP is 8.
1122 Townsley, et al. Standards Track [Page 20]
1123 \f
1124 RFC 2661 L2TP August 1999
1127 Framing Capabilities (SCCRP, SCCRQ)
1129 The Framing Capabilities AVP, Attribute Type 3, provides the peer
1130 with an indication of the types of framing that will be accepted
1131 or requested by the sender.
1133 The Attribute Value field for this AVP has the following format:
1135 0 1 2 3
1136 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
1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1138 | Reserved for future framing type definitions |A|S|
1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1141 The Attribute Value field is a 32-bit mask, with two bits defined.
1142 If bit A is set, asynchronous framing is supported. If bit S is
1143 set, synchronous framing is supported.
1145 A peer MUST NOT request an incoming or outgoing call with a
1146 Framing Type AVP specifying a value not advertised in the Framing
1147 Capabilities AVP it received during control connection
1148 establishment. Attempts to do so will result in the call being
1149 rejected.
1151 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1152 this AVP MUST be set to 1. The Length (before hiding) is 10.
1154 Bearer Capabilities (SCCRP, SCCRQ)
1156 The Bearer Capabilities AVP, Attribute Type 4, provides the peer
1157 with an indication of the bearer device types supported by the
1158 hardware interfaces of the sender for outgoing calls.
1160 The Attribute Value field for this AVP has the following format:
1162 0 1 2 3
1163 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
1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1165 | Reserved for future bearer type definitions |A|D|
1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1168 This is a 32-bit mask, with two bits defined. If bit A is set,
1169 analog access is supported. If bit D is set, digital access is
1170 supported.
1178 Townsley, et al. Standards Track [Page 21]
1179 \f
1180 RFC 2661 L2TP August 1999
1183 An LNS should not request an outgoing call specifying a value in
1184 the Bearer Type AVP for a device type not advertised in the Bearer
1185 Capabilities AVP it received from the LAC during control
1186 connection establishment. Attempts to do so will result in the
1187 call being rejected.
1189 This AVP MUST be present if the sender can place outgoing calls
1190 when requested.
1192 Note that an LNS that cannot act as an LAC as well will not
1193 support hardware devices for handling incoming and outgoing calls
1194 and should therefore set the A and D bits of this AVP to 0, or
1195 should not send the AVP at all. An LNS that can also act as an LAC
1196 and place outgoing calls should set A or D as appropriate.
1197 Presence of this message is not a guarantee that a given outgoing
1198 call will be placed by the sender if requested, just that the
1199 physical capability exists.
1201 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1202 this AVP MUST be set to 1. The Length (before hiding) is 10.
1204 Tie Breaker (SCCRQ)
1206 The Tie Breaker AVP, Attribute Type 5, indicates that the sender
1207 wishes a single tunnel to exist between the given LAC-LNS pair.
1209 The Attribute Value field for this AVP has the following format:
1211 0 1 2 3
1212 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
1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1214 | Tie Break Value...
1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1216 ...(64 bits) |
1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1219 The Tie Breaker Value is an 8 octet value that is used to choose a
1220 single tunnel where both LAC and LNS request a tunnel
1221 concurrently. The recipient of a SCCRQ must check to see if a
1222 SCCRQ has been sent to the peer, and if so, must compare its Tie
1223 Breaker value with the received one. The lower value "wins", and
1224 the "loser" MUST silently discard its tunnel. In the case where a
1225 tie breaker is present on both sides, and the value is equal, both
1226 sides MUST discard their tunnels.
1234 Townsley, et al. Standards Track [Page 22]
1235 \f
1236 RFC 2661 L2TP August 1999
1239 If a tie breaker is received, and an outstanding SCCRQ had no tie
1240 breaker value, the initiator which included the Tie Breaker AVP
1241 "wins". If neither side issues a tie breaker, then two separate
1242 tunnels are opened.
1244 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1245 this AVP MUST be set to 0. The Length of this AVP is 14.
1247 Firmware Revision (SCCRP, SCCRQ)
1249 The Firmware Revision AVP, Attribute Type 6, indicates the
1250 firmware revision of the issuing device.
1252 The Attribute Value field for this AVP has the following format:
1254 0 1
1255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1257 | Firmware Revision |
1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1260 The Firmware Revision is a 2 octet unsigned integer encoded in a
1261 vendor specific format.
1263 For devices which do not have a firmware revision (general purpose
1264 computers running L2TP software modules, for instance), the
1265 revision of the L2TP software module may be reported instead.
1267 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1268 this AVP MUST be set to 0. The Length (before hiding) is 8.
1270 Host Name (SCCRP, SCCRQ)
1272 The Host Name AVP, Attribute Type 7, indicates the name of the
1273 issuing LAC or LNS.
1275 The Attribute Value field for this AVP has the following format:
1277 0 1 2 3
1278 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
1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1280 | Host Name ... (arbitrary number of octets)
1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1283 The Host Name is of arbitrary length, but MUST be at least 1
1284 octet.
1290 Townsley, et al. Standards Track [Page 23]
1291 \f
1292 RFC 2661 L2TP August 1999
1295 This name should be as broadly unique as possible; for hosts
1296 participating in DNS [RFC1034], a hostname with fully qualified
1297 domain would be appropriate.
1299 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1300 this AVP MUST be set to 1. The Length of this AVP is 6 plus the
1301 length of the Host Name.
1303 Vendor Name (SCCRP, SCCRQ)
1305 The Vendor Name AVP, Attribute Type 8, contains a vendor specific
1306 (possibly human readable) string describing the type of LAC or LNS
1307 being used.
1309 The Attribute Value field for this AVP has the following format:
1311 0 1 2 3
1312 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
1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1314 | Vendor Name ...(arbitrary number of octets)
1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1317 The Vendor Name is the indicated number of octets representing the
1318 vendor string. Human readable text for this AVP MUST be provided
1319 in the UTF-8 charset using the Default Language [RFC2277].
1321 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1322 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1323 is 6 plus the length of the Vendor Name.
1325 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
1327 The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being
1328 assigned to this tunnel by the sender.
1330 The Attribute Value field for this AVP has the following format:
1332 0 1
1333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1335 | Assigned Tunnel ID |
1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1338 The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.
1340 The Assigned Tunnel ID AVP establishes a value used to multiplex
1341 and demultiplex multiple tunnels between the LNS and LAC. The L2TP
1342 peer MUST place this value in the Tunnel ID header field of all
1346 Townsley, et al. Standards Track [Page 24]
1347 \f
1348 RFC 2661 L2TP August 1999
1351 control and data messages that it subsequently transmits over the
1352 associated tunnel. Before the Assigned Tunnel ID AVP is received
1353 from a peer, messages MUST be sent to that peer with a Tunnel ID
1354 value of 0 in the header of all control messages.
1356 In the StopCCN control message, the Assigned Tunnel ID AVP MUST be
1357 the same as the Assigned Tunnel ID AVP first sent to the receiving
1358 peer, permitting the peer to identify the appropriate tunnel even
1359 if a StopCCN is sent before an Assigned Tunnel ID AVP is received.
1361 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1362 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1363 is 8.
1365 Receive Window Size (SCCRQ, SCCRP)
1367 The Receive Window Size AVP, Attribute Type 10, specifies the
1368 receive window size being offered to the remote peer.
1370 The Attribute Value field for this AVP has the following format:
1372 0 1
1373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1375 | Window Size |
1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1378 The Window Size is a 2 octet unsigned integer.
1380 If absent, the peer must assume a Window Size of 4 for its
1381 transmit window. The remote peer may send the specified number of
1382 control messages before it must wait for an acknowledgment.
1384 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1385 this AVP MUST be set to 1. The Length of this AVP is 8.
1387 Challenge (SCCRP, SCCRQ)
1389 The Challenge AVP, Attribute Type 11, indicates that the issuing
1390 peer wishes to authenticate the tunnel endpoints using a CHAP-
1391 style authentication mechanism.
1402 Townsley, et al. Standards Track [Page 25]
1403 \f
1404 RFC 2661 L2TP August 1999
1407 The Attribute Value field for this AVP has the following format:
1409 0 1 2 3
1410 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
1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1412 | Challenge ... (arbitrary number of octets)
1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1415 The Challenge is one or more octets of random data.
1417 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1418 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1419 is 6 plus the length of the Challenge.
1421 Challenge Response (SCCCN, SCCRP)
1423 The Response AVP, Attribute Type 13, provides a response to a
1424 challenge received.
1426 The Attribute Value field for this AVP has the following format:
1428 0 1 2 3
1429 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
1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1431 | Response ...
1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1437 ... (16 octets) |
1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1440 The Response is a 16 octet value reflecting the CHAP-style
1441 [RFC1994] response to the challenge.
1443 This AVP MUST be present in an SCCRP or SCCCN if a challenge was
1444 received in the preceding SCCRQ or SCCRP. For purposes of the ID
1445 value in the CHAP response calculation, the value of the Message
1446 Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for
1447 an SCCCN).
1449 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1450 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1451 is 22.
1458 Townsley, et al. Standards Track [Page 26]
1459 \f
1460 RFC 2661 L2TP August 1999
1463 4.4.4 Call Management AVPs
1465 Q.931 Cause Code (CDN)
1467 The Q.931 Cause Code AVP, Attribute Type 12, is used to give
1468 additional information in case of unsolicited call disconnection.
1470 The Attribute Value field for this AVP has the following format:
1472 0 1 2 3
1473 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
1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1475 | Cause Code | Cause Msg | Advisory Msg...
1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1478 Cause Code is the returned Q.931 Cause code, and Cause Msg is the
1479 returned Q.931 message code (e.g., DISCONNECT) associated with the
1480 Cause Code. Both values are returned in their native ITU
1481 encodings [DSS1]. An additional ASCII text Advisory Message may
1482 also be included (presence indicated by the AVP Length) to further
1483 explain the reason for disconnecting.
1485 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1486 this AVP MUST be set to 1. The Length of this AVP is 9, plus the
1487 size of the Advisory Message.
1489 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
1491 The Assigned Session ID AVP, Attribute Type 14, encodes the ID
1492 being assigned to this session by the sender.
1494 The Attribute Value field for this AVP has the following format:
1496 0 1
1497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1499 | Assigned Session ID |
1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1502 The Assigned Session ID is a 2 octet non-zero unsigned integer.
1504 The Assigned Session ID AVP is establishes a value used to
1505 multiplex and demultiplex data sent over a tunnel between the LNS
1506 and LAC. The L2TP peer MUST place this value in the Session ID
1507 header field of all control and data messages that it subsequently
1508 transmits over the tunnel that belong to this session. Before the
1514 Townsley, et al. Standards Track [Page 27]
1515 \f
1516 RFC 2661 L2TP August 1999
1519 Assigned Session ID AVP is received from a peer, messages MUST be
1520 sent to that peer with a Session ID of 0 in the header of all
1521 control messages.
1523 In the CDN control message, the same Assigned Session ID AVP first
1524 sent to the receiving peer is used, permitting the peer to
1525 identify the appropriate tunnel even if CDN is sent before an
1526 Assigned Session ID is received.
1528 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1529 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1530 is 8.
1532 Call Serial Number (ICRQ, OCRQ)
1534 The Call Serial Number AVP, Attribute Type 15, encodes an
1535 identifier assigned by the LAC or LNS to this call.
1537 The Attribute Value field for this AVP has the following format:
1539 0 1 2 3
1540 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
1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1542 | Call Serial Number |
1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545 The Call Serial Number is a 32 bit value.
1547 The Call Serial Number is intended to be an easy reference for
1548 administrators on both ends of a tunnel to use when investigating
1549 call failure problems. Call Serial Numbers should be set to
1550 progressively increasing values, which are likely to be unique for
1551 a significant period of time across all interconnected LNSs and
1552 LACs.
1554 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1555 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1556 is 10.
1558 Minimum BPS (OCRQ)
1560 The Minimum BPS AVP, Attribute Type 16, encodes the lowest
1561 acceptable line speed for this call.
1570 Townsley, et al. Standards Track [Page 28]
1571 \f
1572 RFC 2661 L2TP August 1999
1575 The Attribute Value field for this AVP has the following format:
1577 0 1 2 3
1578 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
1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1580 | Minimum BPS |
1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1583 The Minimum BPS is a 32 bit value indicates the speed in bits per
1584 second.
1586 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1587 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1588 is 10.
1590 Maximum BPS (OCRQ)
1592 The Maximum BPS AVP, Attribute Type 17, encodes the highest
1593 acceptable line speed for this call.
1595 The Attribute Value field for this AVP has the following format:
1597 0 1 2 3
1598 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
1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1600 | Maximum BPS |
1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1603 The Maximum BPS is a 32 bit value indicates the speed in bits per
1604 second.
1606 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1607 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1608 is 10.
1610 Bearer Type (ICRQ, OCRQ)
1612 The Bearer Type AVP, Attribute Type 18, encodes the bearer type
1613 for the incoming or outgoing call.
1615 The Attribute Value field for this AVP has the following format:
1617 0 1 2 3
1618 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
1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1620 | Reserved for future Bearer Types |A|D|
1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1626 Townsley, et al. Standards Track [Page 29]
1627 \f
1628 RFC 2661 L2TP August 1999
1631 The Bearer Type is a 32-bit bit mask, which indicates the bearer
1632 capability of the call (ICRQ) or required for the call (OCRQ). If
1633 set, bit A indicates that the call refers to an analog channel. If
1634 set, bit D indicates that the call refers to a digital channel.
1635 Both may be set, indicating that the call was either
1636 indistinguishable, or can be placed on either type of channel.
1638 Bits in the Value field of this AVP MUST only be set by the LNS
1639 for an OCRQ if it was set in the Bearer Capabilities AVP received
1640 from the LAC during control connection establishment.
1642 It is valid to set neither the A nor D bits in an ICRQ. Such a
1643 setting may indicate that the call was not received over a
1644 physical link (e.g if the LAC and PPP are located in the same
1645 subsystem).
1647 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1648 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1649 is 10.
1651 Framing Type (ICCN, OCCN, OCRQ)
1653 The Framing Type AVP, Attribute Type 19, encodes the framing type
1654 for the incoming or outgoing call.
1656 The Attribute Value field for this AVP has the following format:
1658 0 1 2 3
1659 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
1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1661 | Reserved for future Framing Types |A|S|
1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1664 The Framing Type is a 32-bit mask, which indicates the type of PPP
1665 framing requested for an OCRQ, or the type of PPP framing
1666 negotiated for an OCCN or ICCN. The framing type MAY be used as an
1667 indication to PPP on the LNS as to what link options to use for
1668 LCP negotiation [RFC1662].
1670 Bit A indicates asynchronous framing. Bit S indicates synchronous
1671 framing. For an OCRQ, both may be set, indicating that either type
1672 of framing may be used.
1674 Bits in the Value field of this AVP MUST only be set by the LNS
1675 for an OCRQ if it was set in the Framing Capabilities AVP received
1676 from the LAC during control connection establishment.
1682 Townsley, et al. Standards Track [Page 30]
1683 \f
1684 RFC 2661 L2TP August 1999
1687 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1688 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1689 is 10.
1691 Called Number (ICRQ, OCRQ)
1693 The Called Number AVP, Attribute Type 21, encodes the telephone
1694 number to be called for an OCRQ, and the Called number for an
1695 ICRQ.
1697 The Attribute Value field for this AVP has the following format:
1699 0 1 2 3
1700 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
1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1702 | Called Number... (arbitrary number of octets) |
1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1705 The Called Number is an ASCII string. Contact between the
1706 administrator of the LAC and the LNS may be necessary to
1707 coordinate interpretation of the value needed in this AVP.
1709 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1710 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1711 is 6 plus the length of the Called Number.
1713 Calling Number (ICRQ)
1715 The Calling Number AVP, Attribute Type 22, encodes the originating
1716 number for the incoming call.
1718 The Attribute Value field for this AVP has the following format:
1720 0 1 2 3
1721 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
1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1723 | Calling Number... (arbitrary number of octets) |
1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1726 Calling Number is an ASCII string. Contact between the
1727 administrator of the LAC and the LNS may be necessary to
1728 coordinate interpretation of the value in this AVP.
1730 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1731 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1732 is 6 plus the length of the Calling Number.
1738 Townsley, et al. Standards Track [Page 31]
1739 \f
1740 RFC 2661 L2TP August 1999
1743 Sub-Address (ICRQ, OCRQ)
1745 The Sub-Address AVP, Attribute Type 23, encodes additional dialing
1746 information.
1748 The Attribute Value field for this AVP has the following format:
1750 0 1 2 3
1751 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
1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1753 | Sub-Address ... (arbitrary number of octets) |
1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1756 The Sub-Address is an ASCII string. Contact between the
1757 administrator of the LAC and the LNS may be necessary to
1758 coordinate interpretation of the value in this AVP.
1760 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1761 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1762 is 6 plus the length of the Sub-Address.
1764 (Tx) Connect Speed (ICCN, OCCN)
1766 The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the
1767 speed of the facility chosen for the connection attempt.
1769 The Attribute Value field for this AVP has the following format:
1771 0 1 2 3
1772 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
1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1774 | BPS |
1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1777 The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
1778 in bits per second.
1780 When the optional Rx Connect Speed AVP is present, the value in
1781 this AVP represents the transmit connect speed, from the
1782 perspective of the LAC (e.g. data flowing from the LAC to the
1783 remote system). When the optional Rx Connect Speed AVP is NOT
1784 present, the connection speed between the remote system and LAC is
1785 assumed to be symmetric and is represented by the single value in
1786 this AVP.
1788 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1789 this AVP MUST be set to 1. The Length (before hiding) of this AVP
1790 is 10.
1794 Townsley, et al. Standards Track [Page 32]
1795 \f
1796 RFC 2661 L2TP August 1999
1799 Rx Connect Speed (ICCN, OCCN)
1801 The Rx Connect Speed AVP, Attribute Type 38, represents the speed
1802 of the connection from the perspective of the LAC (e.g. data
1803 flowing from the remote system to the LAC).
1805 The Attribute Value field for this AVP has the following format:
1807 0 1 2 3
1808 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
1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1810 | BPS (H) | BPS (L) |
1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1813 BPS is a 4 octet value indicating the speed in bits per second.
1815 Presence of this AVP implies that the connection speed may be
1816 asymmetric with respect to the transmit connect speed given in the
1817 (Tx) Connect Speed AVP.
1819 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
1820 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1821 is 10.
1823 Physical Channel ID (ICRQ, OCRP)
1825 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor
1826 specific physical channel number used for a call.
1828 The Attribute Value field for this AVP has the following format:
1830 0 1 2 3
1831 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
1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1833 | Physical Channel ID |
1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1836 Physical Channel ID is a 4 octet value intended to be used for
1837 logging purposes only.
1839 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1840 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1841 is 10.
1850 Townsley, et al. Standards Track [Page 33]
1851 \f
1852 RFC 2661 L2TP August 1999
1855 Private Group ID (ICCN)
1857 The Private Group ID AVP, Attribute Type 37, is used by the LAC to
1858 indicate that this call is to be associated with a particular
1859 customer group.
1861 The Attribute Value field for this AVP has the following format:
1863 0 1 2 3
1864 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
1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1866 | Private Group ID ... (arbitrary number of octets) |
1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1869 The Private Group ID is a string of octets of arbitrary length.
1871 The LNS MAY treat the PPP session as well as network traffic
1872 through this session in a special manner determined by the peer.
1873 For example, if the LNS is individually connected to several
1874 private networks using unregistered addresses, this AVP may be
1875 included by the LAC to indicate that a given call should be
1876 associated with one of the private networks.
1878 The Private Group ID is a string corresponding to a table in the
1879 LNS that defines the particular characteristics of the selected
1880 group. A LAC MAY determine the Private Group ID from a RADIUS
1881 response, local configuration, or some other source.
1883 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
1884 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1885 is 6 plus the length of the Private Group ID.
1887 Sequencing Required (ICCN, OCCN)
1889 The Sequencing Required AVP, Attribute Type 39, indicates to the
1890 LNS that Sequence Numbers MUST always be present on the data
1891 channel.
1893 This AVP has no Attribute Value field.
1895 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
1896 this AVP MUST be set to 1. The Length of this AVP is 6.
1898 4.4.5 Proxy LCP and Authentication AVPs
1900 The LAC may have answered the call and negotiated LCP with the
1901 remote system, perhaps in order to establish the system's apparent
1902 identity. In this case, these AVPs may be included to indicate the
1906 Townsley, et al. Standards Track [Page 34]
1907 \f
1908 RFC 2661 L2TP August 1999
1911 link properties the remote system initially requested, properties
1912 the remote system and LAC ultimately negotiated, as well as PPP
1913 authentication information sent and received by the LAC. This
1914 information may be used to initiate the PPP LCP and authentication
1915 systems on the LNS, allowing PPP to continue without renegotiation
1916 of LCP. Note that the LNS policy may be to enter an additional
1917 round of LCP negotiation and/or authentication if the LAC is not
1918 trusted.
1920 Initial Received LCP CONFREQ (ICCN)
1922 In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
1923 provides the LNS with the Initial CONFREQ received by the LAC from
1924 the PPP Peer.
1926 The Attribute Value field for this AVP has the following format:
1928 0 1 2 3
1929 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
1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1931 | LCP CONFREQ... (arbitrary number of octets) |
1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1934 LCP CONFREQ is a copy of the body of the initial CONFREQ received,
1935 starting at the first option within the body of the LCP message.
1937 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1938 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1939 is 6 plus the length of the CONFREQ.
1941 Last Sent LCP CONFREQ (ICCN)
1943 In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the
1944 LNS with the Last CONFREQ sent by the LAC to the PPP Peer.
1946 The Attribute Value field for this AVP has the following format:
1948 0 1 2 3
1949 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
1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1951 | LCP CONFREQ... (arbitrary number of octets) |
1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1954 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
1955 the client to complete LCP negotiation, starting at the first
1956 option within the body of the LCP message.
1962 Townsley, et al. Standards Track [Page 35]
1963 \f
1964 RFC 2661 L2TP August 1999
1967 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1968 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1969 is 6 plus the length of the CONFREQ.
1971 Last Received LCP CONFREQ (ICCN)
1973 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
1974 LNS with the Last CONFREQ received by the LAC from the PPP Peer.
1976 The Attribute Value field for this AVP has the following format:
1978 0 1 2 3
1979 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
1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1981 | LCP CONFREQ... (arbitrary number of octets) |
1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1984 The LCP CONFREQ is a copy of the body of the final CONFREQ
1985 received from the client to complete LCP negotiation, starting at
1986 the first option within the body of the LCP message.
1988 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
1989 this AVP MUST be set to 0. The Length (before hiding) of this AVP
1990 is 6 plus the length of the CONFREQ.
1992 Proxy Authen Type (ICCN)
1994 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
1995 authentication should be used.
1997 The Attribute Value field for this AVP has the following format:
1999 0 1
2000 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2002 | Authen Type |
2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2005 Authen Type is a 2 octet unsigned integer, holding:
2007 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
2008 this AVP MUST be set to 0. The Length (before hiding) of this AVP
2009 is 8.
2018 Townsley, et al. Standards Track [Page 36]
2019 \f
2020 RFC 2661 L2TP August 1999
2023 Defined Authen Type values are:
2024 0 - Reserved
2025 1 - Textual username/password exchange
2026 2 - PPP CHAP
2027 3 - PPP PAP
2028 4 - No Authentication
2029 5 - Microsoft CHAP Version 1 (MSCHAPv1)
2031 This AVP MUST be present if proxy authentication is to be
2032 utilized. If it is not present, then it is assumed that this
2033 peer cannot perform proxy authentication, requiring
2034 a restart of the authentication phase at the LNS if the client
2035 has already entered this phase with the
2036 LAC (which may be determined by the Proxy LCP AVP if present).
2038 Associated AVPs for each type of authentication follow.
2040 Proxy Authen Name (ICCN)
2042 The Proxy Authen Name AVP, Attribute Type 30, specifies the name
2043 of the authenticating client when using proxy authentication.
2045 The Attribute Value field for this AVP has the following format:
2047 0 1 2 3
2048 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
2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2050 | Authen Name... (arbitrary number of octets) |
2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2053 Authen Name is a string of octets of arbitrary length. It
2054 contains the name specified in the client's authentication
2055 response.
2057 This AVP MUST be present in messages containing a Proxy Authen
2058 Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable
2059 to employ AVP hiding for obscuring the cleartext name.
2061 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
2062 this AVP MUST be set to 0. The Length (before hiding) is 6 plus
2063 the length of the cleartext name.
2065 Proxy Authen Challenge (ICCN)
2067 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
2068 challenge sent by the LAC to the PPP Peer, when using proxy
2069 authentication.
2074 Townsley, et al. Standards Track [Page 37]
2075 \f
2076 RFC 2661 L2TP August 1999
2079 The Attribute Value field for this AVP has the following format:
2081 0 1 2 3
2082 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
2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2084 | Challenge... (arbitrary number of octets) |
2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2087 The Challenge is a string of one or more octets.
2089 This AVP MUST be present for Proxy Authen Types 2 and 5. The
2090 Challenge field contains the CHAP challenge presented to the
2091 client by the LAC.
2093 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
2094 this AVP MUST be set to 0. The Length (before hiding) of this AVP
2095 is 6, plus the length of the Challenge.
2097 Proxy Authen ID (ICCN)
2099 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value
2100 of the PPP Authentication that was started between the LAC and the
2101 PPP Peer, when proxy authentication is being used.
2103 The Attribute Value field for this AVP has the following format:
2105 0 1
2106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2108 | Reserved | ID |
2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2111 ID is a 2 octet unsigned integer, the most significant octet MUST
2112 be 0.
2114 The Proxy Authen ID AVP MUST be present for Proxy authen types 2,
2115 3 and 5. For 2 and 5, the ID field contains the byte ID value
2116 presented to the client by the LAC in its Challenge. For 3, it is
2117 the Identifier value of the Authenticate-Request.
2119 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
2120 this AVP MUST be set to 0.
2122 Proxy Authen Response (ICCN)
2124 The Proxy Authen Response AVP, Attribute Type 33, specifies the
2125 PPP Authentication response received by the LAC from the PPP Peer,
2126 when proxy authentication is used.
2130 Townsley, et al. Standards Track [Page 38]
2131 \f
2132 RFC 2661 L2TP August 1999
2135 The Attribute Value field for this AVP has the following format:
2137 0 1 2 3
2138 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
2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2140 | Response... (arbitrary number of octets) |
2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2143 The Response is a string of octets.
2145 This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
2146 Response field contains the client's response to the challenge.
2147 For Proxy authen types 2 and 5, this field contains the response
2148 value received by the LAC. For types 1 or 3, it contains the clear
2149 text password received from the client by the LAC. In the case of
2150 cleartext passwords, AVP hiding is recommended.
2152 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
2153 this AVP MUST be set to 0. The Length (before hiding) of this AVP
2154 is 6 plus the length of the Response.
2156 4.4.6 Call Status AVPs
2158 Call Errors (WEN)
2160 The Call Errors AVP, Attribute Type 34, is used by the LAC to send
2161 error information to the LNS.
2163 The Attribute Value field for this AVP has the following format:
2165 0 1 2 3
2166 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
2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2168 | Reserved | CRC Errors (H) |
2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2170 | CRC Errors (L) | Framing Errors (H) |
2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2172 | Framing Errors (L) | Hardware Overruns (H) |
2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2174 | Hardware Overruns (L) | Buffer Overruns (H) |
2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2176 | Buffer Overruns (L) | Time-out Errors (H) |
2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2178 | Time-out Errors (L) | Alignment Errors (H) |
2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2180 | Alignment Errors (L) |
2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2186 Townsley, et al. Standards Track [Page 39]
2187 \f
2188 RFC 2661 L2TP August 1999
2191 The following fields are defined:
2193 Reserved - Not used, MUST be 0
2194 CRC Errors - Number of PPP frames received with CRC errors
2195 since call was established
2196 Framing Errors - Number of improperly framed PPP packets
2197 received
2198 Hardware Overruns - Number of receive buffer over-runs since
2199 call was established
2200 Buffer Overruns - Number of buffer over-runs detected since
2201 call was established
2202 Time-out Errors - Number of time-outs since call was
2203 established
2204 Alignment Errors - Number of alignment errors since call was
2205 established
2207 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
2208 this AVP MUST be set to 1. The Length (before hiding) of this AVP
2209 is 32.
2211 ACCM (SLI)
2213 The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC
2214 of the ACCM negotiated with the PPP Peer by the LNS.
2216 The Attribute Value field for this AVP has the following format:
2218 0 1 2 3
2219 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
2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2221 | Reserved | Send ACCM (H) |
2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2223 | Send ACCM (L) | Receive ACCM (H) |
2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2225 | Receive ACCM (L) |
2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2228 Send ACCM and Receive ACCM are each 4 octet values preceded by a 2
2229 octet reserved quantity. The send ACCM value should be used by the
2230 LAC to process packets it sends on the connection. The receive
2231 ACCM value should be used by the LAC to process incoming packets
2232 on the connection. The default values used by the LAC for both
2233 these fields are 0xFFFFFFFF. The LAC should honor these fields
2234 unless it has specific configuration information to indicate that
2235 the requested mask must be modified to permit operation.
2237 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
2238 this AVP MUST be set to 1. The Length of this AVP is 16.
2242 Townsley, et al. Standards Track [Page 40]
2243 \f
2244 RFC 2661 L2TP August 1999
2247 5.0 Protocol Operation
2249 The necessary setup for tunneling a PPP session with L2TP consists of
2250 two steps, (1) establishing the Control Connection for a Tunnel, and
2251 (2) establishing a Session as triggered by an incoming or outgoing
2252 call request. The Tunnel and corresponding Control Connection MUST be
2253 established before an incoming or outgoing call is initiated. An L2TP
2254 Session MUST be established before L2TP can begin to tunnel PPP
2255 frames. Multiple Sessions may exist across a single Tunnel and
2256 multiple Tunnels may exist between the same LAC and LNS.
2258 +-----+ +-----+
2259 | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
2260 | LAC | | LNS |
2261 | #######Control Connection######## |
2262 [Remote] | | | |
2263 [System]------Call----------*============L2TP Session=============* |
2264 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
2265 | | | |
2266 [Remote] | | | |
2267 [System]------Call----------*============L2TP Session=============* |
2268 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
2269 | | | |
2270 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
2271 +-----+ +-----+
2273 Figure 5.1 Tunneling PPP
2275 5.1 Control Connection Establishment
2277 The Control Connection is the initial connection that must be
2278 achieved between an LAC and LNS before sessions may be brought up.
2279 Establishment of the control connection includes securing the
2280 identity of the peer, as well as identifying the peer's L2TP version,
2281 framing, and bearer capabilities, etc.
2283 A three message exchange is utilized to setup the control connection.
2284 Following is a typical message exchange:
2286 LAC or LNS LAC or LNS
2287 ---------- ----------
2288 SCCRQ ->
2289 <- SCCRP
2290 SCCCN ->
2291 <- ZLB ACK
2293 The ZLB ACK is sent if there are no further messages waiting in queue
2294 for that peer.
2298 Townsley, et al. Standards Track [Page 41]
2299 \f
2300 RFC 2661 L2TP August 1999
2303 5.1.1 Tunnel Authentication
2305 L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel
2306 authentication system during control connection establishment. If an
2307 LAC or LNS wishes to authenticate the identity of the peer it is
2308 contacting or being contacted by, a Challenge AVP is included in the
2309 SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or
2310 SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP
2311 or SCCCN, respectively. If the expected response and response
2312 received from a peer does not match, establishment of the tunnel MUST
2313 be disallowed.
2315 To participate in tunnel authentication, a single shared secret MUST
2316 exist between the LAC and LNS. This is the same shared secret used
2317 for AVP hiding (see Section 4.3). See Section 4.4.3 for details on
2318 construction of the Challenge and Response AVPs.
2320 5.2 Session Establishment
2322 After successful control connection establishment, individual
2323 sessions may be created. Each session corresponds to single PPP
2324 stream between the LAC and LNS. Unlike control connection
2325 establishment, session establishment is directional with respect to
2326 the LAC and LNS. The LAC requests the LNS to accept a session for an
2327 incoming call, and the LNS requests the LAC to accept a session for
2328 placing an outgoing call.
2330 5.2.1 Incoming Call Establishment
2332 A three message exchange is employed to setup the session. Following
2333 is a typical sequence of events:
2335 LAC LNS
2336 --- ---
2337 (Call
2338 Detected)
2340 ICRQ ->
2341 <- ICRP
2342 ICCN ->
2343 <- ZLB ACK
2345 The ZLB ACK is sent if there are no further messages waiting in queue
2346 for that peer.
2354 Townsley, et al. Standards Track [Page 42]
2355 \f
2356 RFC 2661 L2TP August 1999
2359 5.2.2 Outgoing Call Establishment
2361 A three message exchange is employed to setup the session. Following
2362 is a typical sequence of events:
2364 LAC LNS
2365 --- ---
2366 <- OCRQ
2367 OCRP ->
2369 (Perform
2370 Call
2371 Operation)
2373 OCCN ->
2374 <- ZLB ACK
2376 The ZLB ACK is sent if there are no further messages waiting in queue
2377 for that peer.
2379 5.3 Forwarding PPP Frames
2381 Once tunnel establishment is complete, PPP frames from the remote
2382 system are received at the LAC, stripped of CRC, link framing, and
2383 transparency bytes, encapsulated in L2TP, and forwarded over the
2384 appropriate tunnel. The LNS receives the L2TP packet, and processes
2385 the encapsulated PPP frame as if it were received on a local PPP
2386 interface.
2388 The sender of a message associated with a particular session and
2389 tunnel places the Session ID and Tunnel ID (specified by its peer) in
2390 the Session ID and Tunnel ID header for all outgoing messages. In
2391 this manner, PPP frames are multiplexed and demultiplexed over a
2392 single tunnel between a given LNS-LAC pair. Multiple tunnels may
2393 exist between a given LNS-LAC pair, and multiple sessions may exist
2394 within a tunnel.
2396 The value of 0 for Session ID and Tunnel ID is special and MUST NOT
2397 be used as an Assigned Session ID or Assigned Tunnel ID. For the
2398 cases where a Session ID has not yet been assigned by the peer (i.e.,
2399 during establishment of a new session or tunnel), the Session ID
2400 field MUST be sent as 0, and the Assigned Session ID AVP within the
2401 message MUST be used to identify the session. Similarly, for cases
2402 where the Tunnel ID has not yet been assigned from the peer, the
2403 Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to
2404 identify the tunnel.
2410 Townsley, et al. Standards Track [Page 43]
2411 \f
2412 RFC 2661 L2TP August 1999
2415 5.4 Using Sequence Numbers on the Data Channel
2417 Sequence numbers are defined in the L2TP header for control messages
2418 and optionally for data messages (see Section 3.1). These are used to
2419 provide a reliable control message transport (see Section 5.8) and
2420 optional data message sequencing. Each peer maintains separate
2421 sequence numbers for the control connection and each individual data
2422 session within a tunnel.
2424 Unlike the L2TP control channel, the L2TP data channel does not use
2425 sequence numbers to retransmit lost data messages. Rather, data
2426 messages may use sequence numbers to detect lost packets and/or
2427 restore the original sequence of packets that may have been reordered
2428 during transport. The LAC may request that sequence numbers be
2429 present in data messages via the Sequencing Required AVP (see Section
2430 4.4.6). If this AVP is present during session setup, sequence numbers
2431 MUST be present at all times. If this AVP is not present, sequencing
2432 presence is under control of the LNS. The LNS controls enabling and
2433 disabling of sequence numbers by sending a data message with or
2434 without sequence numbers present at any time during the life of a
2435 session. Thus, if the LAC receives a data message without sequence
2436 numbers present, it MUST stop sending sequence numbers in future data
2437 messages. If the LAC receives a data message with sequence numbers
2438 present, it MUST begin sending sequence numbers in future outgoing
2439 data messages. If the LNS enables sequencing after disabling it
2440 earlier in the session, the sequence number state picks up where it
2441 left off before.
2443 The LNS may initiate disabling of sequencing at any time during the
2444 session (including the first data message sent). It is recommended
2445 that for connections where reordering or packet loss may occur,
2446 sequence numbers always be enabled during the initial negotiation
2447 stages of PPP and disabled only when and if the risk is considered
2448 acceptable. For example, if the PPP session being tunneled is not
2449 utilizing any stateful compression or encryption protocols and is
2450 only carrying IP (as determined by the PPP NCPs that are
2451 established), then the LNS might decide to disable sequencing as IP
2452 is tolerant to datagram loss and reordering.
2454 5.5 Keepalive (Hello)
2456 A keepalive mechanism is employed by L2TP in order to differentiate
2457 tunnel outages from extended periods of no control or data activity
2458 on a tunnel. This is accomplished by injecting Hello control messages
2459 (see Section 6.5) after a specified period of time has elapsed since
2460 the last data or control message was received on a tunnel. As for any
2461 other control message, if the Hello message is not reliably delivered
2462 then the tunnel is declared down and is reset. The transport reset
2466 Townsley, et al. Standards Track [Page 44]
2467 \f
2468 RFC 2661 L2TP August 1999
2471 mechanism along with the injection of Hello messages ensures that a
2472 connectivity failure between the LNS and the LAC will be detected at
2473 both ends of a tunnel.
2475 5.6 Session Teardown
2477 Session teardown may be initiated by either the LAC or LNS and is
2478 accomplished by sending a CDN control message. After the last session
2479 is cleared, the control connection MAY be torn down as well (and
2480 typically is). Following is an example of a typical control message
2481 exchange:
2483 LAC or LNS LAC or LNS
2485 CDN ->
2486 (Clean up)
2488 <- ZLB ACK
2489 (Clean up)
2491 5.7 Control Connection Teardown
2493 Control connection teardown may be initiated by either the LAC or LNS
2494 and is accomplished by sending a single StopCCN control message. The
2495 receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of
2496 the message and maintain enough control connection state to properly
2497 accept StopCCN retransmissions over at least a full retransmission
2498 cycle (in case the ZLB ACK is lost). The recommended time for a full
2499 retransmission cycle is 31 seconds (see section 5.8). Following is an
2500 example of a typical control message exchange:
2502 LAC or LNS LAC or LNS
2504 StopCCN ->
2505 (Clean up)
2507 <- ZLB ACK
2508 (Wait)
2509 (Clean up)
2511 An implementation may shut down an entire tunnel and all sessions on
2512 the tunnel by sending the StopCCN. Thus, it is not necessary to clear
2513 each session individually when tearing down the whole tunnel.
2522 Townsley, et al. Standards Track [Page 45]
2523 \f
2524 RFC 2661 L2TP August 1999
2527 5.8 Reliable Delivery of Control Messages
2529 L2TP provides a lower level reliable transport service for all
2530 control messages. The Nr and Ns fields of the control message header
2531 (see section 3.1) belong to this transport. The upper level
2532 functions of L2TP are not concerned with retransmission or ordering
2533 of control messages. The reliable control message is a sliding window
2534 transport that provides control message retransmission and congestion
2535 control. Each peer maintains separate sequence number state for the
2536 control connection within a tunnel.
2538 The message sequence number, Ns, begins at 0. Each subsequent message
2539 is sent with the next increment of the sequence number. The sequence
2540 number is thus a free running counter represented modulo 65536. The
2541 sequence number in the header of a received message is considered
2542 less than or equal to the last received number if its value lies in
2543 the range of the last received number and the preceding 32767 values,
2544 inclusive. For example, if the last received sequence number was 15,
2545 then messages with sequence numbers 0 through 15, as well as 32784
2546 through 65535, would be considered less than or equal. Such a message
2547 would be considered a duplicate of a message already received and
2548 ignored from processing. However, in order to ensure that all
2549 messages are acknowledged properly (particularly in the case of a
2550 lost ZLB ACK message), receipt of duplicate messages MUST be
2551 acknowledged by the reliable transport. This acknowledgement may
2552 either piggybacked on a message in queue, or explicitly via a ZLB
2553 ACK.
2555 All control messages take up one slot in the control message sequence
2556 number space, except the ZLB acknowledgement. Thus, Ns is not
2557 incremented after a ZLB message is sent.
2559 The last received message number, Nr, is used to acknowledge messages
2560 received by an L2TP peer. It contains the sequence number of the
2561 message the peer expects to receive next (e.g. the last Ns of a non-
2562 ZLB message received plus 1, modulo 65536). While the Nr in a
2563 received ZLB is used to flush messages from the local retransmit
2564 queue (see below), Nr of the next message sent is not be updated by
2565 the Ns of the ZLB.
2567 The reliable transport at a receiving peer is responsible for making
2568 sure that control messages are delivered in order and without
2569 duplication to the upper level. Messages arriving out of order may be
2570 queued for in-order delivery when the missing messages are received,
2571 or they may be discarded requiring a retransmission by the peer.
2578 Townsley, et al. Standards Track [Page 46]
2579 \f
2580 RFC 2661 L2TP August 1999
2583 Each tunnel maintains a queue of control messages to be transmitted
2584 to its peer. The message at the front of the queue is sent with a
2585 given Ns value, and is held until a control message arrives from the
2586 peer in which the Nr field indicates receipt of this message. After a
2587 period of time (a recommended default is 1 second) passes without
2588 acknowledgement, the message is retransmitted. The retransmitted
2589 message contains the same Ns value, but the Nr value MUST be updated
2590 with the sequence number of the next expected message.
2592 Each subsequent retransmission of a message MUST employ an
2593 exponential backoff interval. Thus, if the first retransmission
2594 occurred after 1 second, the next retransmission should occur after 2
2595 seconds has elapsed, then 4 seconds, etc. An implementation MAY place
2596 a cap upon the maximum interval between retransmissions. This cap
2597 MUST be no less than 8 seconds per retransmission. If no peer
2598 response is detected after several retransmissions, (a recommended
2599 default is 5, but SHOULD be configurable), the tunnel and all
2600 sessions within MUST be cleared.
2602 When a tunnel is being shut down for reasons other than loss of
2603 connectivity, the state and reliable delivery mechanisms MUST be
2604 maintained and operated for the full retransmission interval after
2605 the final message exchange has occurred.
2607 A sliding window mechanism is used for control message transmission.
2608 Consider two peers A & B. Suppose A specifies a Receive Window Size
2609 AVP with a value of N in the SCCRQ or SCCRP messages. B is now
2610 allowed to have up to N outstanding control messages. Once N have
2611 been sent, it must wait for an acknowledgment that advances the
2612 window before sending new control messages. An implementation may
2613 support a receive window of only 1 (i.e., by sending out a Receive
2614 Window Size AVP with a value of 1), but MUST accept a window of up to
2615 4 from its peer (e.g. have the ability to send 4 messages before
2616 backing off). A value of 0 for the Receive Window Size AVP is
2617 invalid.
2619 When retransmitting control messages, a slow start and congestion
2620 avoidance window adjustment procedure SHOULD be utilized. The
2621 recommended procedure for this is described in Appendix A.
2623 A peer MUST NOT withhold acknowledgment of messages as a technique
2624 for flow controlling control messages. An L2TP implementation is
2625 expected to be able to keep up with incoming control messages,
2626 possibly responding to some with errors reflecting an inability to
2627 honor the requested action.
2629 Appendix B contains examples of control message transmission,
2630 acknowledgement, and retransmission.
2634 Townsley, et al. Standards Track [Page 47]
2635 \f
2636 RFC 2661 L2TP August 1999
2639 6.0 Control Connection Protocol Specification
2641 The following control connection messages are used to establish,
2642 clear and maintain L2TP tunnels. All data is sent in network order
2643 (high order octets first). Any "reserved" or "empty" fields MUST be
2644 sent as 0 values to allow for protocol extensibility.
2646 6.1 Start-Control-Connection-Request (SCCRQ)
2648 Start-Control-Connection-Request (SCCRQ) is a control message used to
2649 initialize a tunnel between an LNS and an LAC. It is sent by either
2650 the LAC or the LNS to being the tunnel establishment process.
2652 The following AVPs MUST be present in the SCCRQ:
2654 Message Type AVP
2655 Protocol Version
2656 Host Name
2657 Framing Capabilities
2658 Assigned Tunnel ID
2660 The Following AVPs MAY be present in the SCCRQ:
2662 Bearer Capabilities
2663 Receive Window Size
2664 Challenge
2665 Tie Breaker
2666 Firmware Revision
2667 Vendor Name
2669 6.2 Start-Control-Connection-Reply (SCCRP)
2671 Start-Control-Connection-Reply (SCCRP) is a control message sent in
2672 reply to a received SCCRQ message. SCCRP is used to indicate that the
2673 SCCRQ was accepted and establishment of the tunnel should continue.
2675 The following AVPs MUST be present in the SCCRP:
2677 Message Type
2678 Protocol Version
2679 Framing Capabilities
2680 Host Name
2681 Assigned Tunnel ID
2690 Townsley, et al. Standards Track [Page 48]
2691 \f
2692 RFC 2661 L2TP August 1999
2695 The following AVPs MAY be present in the SCCRP:
2697 Bearer Capabilities
2698 Firmware Revision
2699 Vendor Name
2700 Receive Window Size
2701 Challenge
2702 Challenge Response
2704 6.3 Start-Control-Connection-Connected (SCCCN)
2706 Start-Control-Connection-Connected (SCCCN) is a control message sent
2707 in reply to an SCCRP. SCCCN completes the tunnel establishment
2708 process.
2710 The following AVP MUST be present in the SCCCN:
2712 Message Type
2714 The following AVP MAY be present in the SCCCN:
2716 Challenge Response
2718 6.4 Stop-Control-Connection-Notification (StopCCN)
2720 Stop-Control-Connection-Notification (StopCCN) is a control message
2721 sent by either the LAC or LNS to inform its peer that the tunnel is
2722 being shutdown and the control connection should be closed. In
2723 addition, all active sessions are implicitly cleared (without sending
2724 any explicit call control messages). The reason for issuing this
2725 request is indicated in the Result Code AVP. There is no explicit
2726 reply to the message, only the implicit ACK that is received by the
2727 reliable control message transport layer.
2729 The following AVPs MUST be present in the StopCCN:
2731 Message Type
2732 Assigned Tunnel ID
2733 Result Code
2735 6.5 Hello (HELLO)
2737 The Hello (HELLO) message is an L2TP control message sent by either
2738 peer of a LAC-LNS control connection. This control message is used as
2739 a "keepalive" for the tunnel.
2746 Townsley, et al. Standards Track [Page 49]
2747 \f
2748 RFC 2661 L2TP August 1999
2751 The sending of HELLO messages and the policy for sending them are
2752 left up to the implementation. A peer MUST NOT expect HELLO messages
2753 at any time or interval. As with all messages sent on the control
2754 connection, the receiver will return either a ZLB ACK or an
2755 (unrelated) message piggybacking the necessary acknowledgement
2756 information.
2758 Since a HELLO is a control message, and control messages are reliably
2759 sent by the lower level transport, this keepalive function operates
2760 by causing the transport level to reliably deliver a message. If a
2761 media interruption has occurred, the reliable transport will be
2762 unable to deliver the HELLO across, and will clean up the tunnel.
2764 Keepalives for the tunnel MAY be implemented by sending a HELLO if a
2765 period of time (a recommended default is 60 seconds, but SHOULD be
2766 configurable) has passed without receiving any message (data or
2767 control) from the peer.
2769 HELLO messages are global to the tunnel. The Session ID in a HELLO
2770 message MUST be 0.
2772 The Following AVP MUST be present in the HELLO message:
2774 Message Type
2776 6.6 Incoming-Call-Request (ICRQ)
2778 Incoming-Call-Request (ICRQ) is a control message sent by the LAC to
2779 the LNS when an incoming call is detected. It is the first in a three
2780 message exchange used for establishing a session within an L2TP
2781 tunnel.
2783 ICRQ is used to indicate that a session is to be established between
2784 the LAC and LNS for this call and provides the LNS with parameter
2785 information for the session. The LAC may defer answering the call
2786 until it has received an ICRP from the LNS indicating that the
2787 session should be established. This mechanism allows the LNS to
2788 obtain sufficient information about the call before determining
2789 whether it should be answered or not. Alternatively, the LAC may
2790 answer the call, negotiate LCP and PPP authentication, and use the
2791 information gained to choose the LNS. In this case, the call has
2792 already been answered by the time the ICRP message is received; the
2793 LAC simply spoofs the "call indication" and "call answer" steps in
2794 this case.
2802 Townsley, et al. Standards Track [Page 50]
2803 \f
2804 RFC 2661 L2TP August 1999
2807 The following AVPs MUST be present in the ICRQ:
2809 Message Type
2810 Assigned Session ID
2811 Call Serial Number
2813 The following AVPs MAY be present in the ICRQ:
2815 Bearer Type
2816 Physical Channel ID
2817 Calling Number
2818 Called Number
2819 Sub-Address
2821 6.7 Incoming-Call-Reply (ICRP)
2823 Incoming-Call-Reply (ICRP) is a control message sent by the LNS to
2824 the LAC in response to a received ICRQ message. It is the second in
2825 the three message exchange used for establishing sessions within an
2826 L2TP tunnel.
2828 ICRP is used to indicate that the ICRQ was successful and for the LAC
2829 to answer the call if it has not already done so. It also allows the
2830 LNS to indicate necessary parameters for the L2TP session.
2832 The following AVPs MUST be present in the ICRP:
2834 Message Type
2835 Assigned Session ID
2837 6.8 Incoming-Call-Connected (ICCN)
2839 Incoming-Call-Connected (ICCN) is a control message sent by the LAC
2840 to the LNS in response to a received ICRP message. It is the third
2841 message in the three message exchange used for establishing sessions
2842 within an L2TP tunnel.
2844 ICCN is used to indicate that the ICRP was accepted, the call has
2845 been answered, and that the L2TP session should move to the
2846 established state. It also provides additional information to the
2847 LNS about parameters used for the answered call (parameters that may
2848 not always available at the time the ICRQ is issued).
2850 The following AVPs MUST be present in the ICCN:
2852 Message Type
2853 (Tx) Connect Speed
2854 Framing Type
2858 Townsley, et al. Standards Track [Page 51]
2859 \f
2860 RFC 2661 L2TP August 1999
2863 The following AVPs MAY be present in the ICCN:
2865 Initial Received LCP CONFREQ
2866 Last Sent LCP CONFREQ
2867 Last Received LCP CONFREQ
2868 Proxy Authen Type
2869 Proxy Authen Name
2870 Proxy Authen Challenge
2871 Proxy Authen ID
2872 Proxy Authen Response
2873 Private Group ID
2874 Rx Connect Speed
2875 Sequencing Required
2877 6.9 Outgoing-Call-Request (OCRQ)
2879 Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to
2880 the LAC to indicate that an outbound call from the LAC is to be
2881 established. It is the first in a three message exchange used for
2882 establishing a session within an L2TP tunnel.
2884 OCRQ is used to indicate that a session is to be established between
2885 the LNS and LAC for this call and provides the LAC with parameter
2886 information for both the L2TP session, and the call that is to be
2887 placed
2889 An LNS MUST have received a Bearer Capabilities AVP during tunnel
2890 establishment from an LAC in order to request an outgoing call to
2891 that LAC.
2893 The following AVPs MUST be present in the OCRQ:
2895 Message Type
2896 Assigned Session ID
2897 Call Serial Number
2898 Minimum BPS
2899 Maximum BPS
2900 Bearer Type
2901 Framing Type
2902 Called Number
2904 The following AVPs MAY be present in the OCRQ:
2906 Sub-Address
2914 Townsley, et al. Standards Track [Page 52]
2915 \f
2916 RFC 2661 L2TP August 1999
2919 6.10 Outgoing-Call-Reply (OCRP)
2921 Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to
2922 the LNS in response to a received OCRQ message. It is the second in a
2923 three message exchange used for establishing a session within an L2TP
2924 tunnel.
2926 OCRP is used to indicate that the LAC is able to attempt the outbound
2927 call and returns certain parameters regarding the call attempt.
2929 The following AVPs MUST be present in the OCRP:
2931 Message Type
2932 Assigned Session ID
2934 The following AVPs MAY be present in the OCRP:
2936 Physical Channel ID
2938 6.11 Outgoing-Call-Connected (OCCN)
2940 Outgoing-Call-Connected (OCCN) is a control message sent by the LAC
2941 to the LNS following the OCRP and after the outgoing call has been
2942 completed. It is the final message in a three message exchange used
2943 for establishing a session within an L2TP tunnel.
2945 OCCN is used to indicate that the result of a requested outgoing call
2946 was successful. It also provides information to the LNS about the
2947 particular parameters obtained after the call was established.
2949 The following AVPs MUST be present in the OCCN:
2951 Message Type
2952 (Tx) Connect Speed
2953 Framing Type
2955 The following AVPs MAY be present in the OCCN:
2957 Rx Connect Speed
2958 Sequencing Required
2960 6.12 Call-Disconnect-Notify (CDN)
2962 The Call-Disconnect-Notify (CDN) message is an L2TP control message
2963 sent by either the LAC or LNS to request disconnection of a specific
2964 call within the tunnel. Its purpose is to inform the peer of the
2970 Townsley, et al. Standards Track [Page 53]
2971 \f
2972 RFC 2661 L2TP August 1999
2975 disconnection and the reason why the disconnection occurred. The peer
2976 MUST clean up any resources, and does not send back any indication of
2977 success or failure for such cleanup.
2979 The following AVPs MUST be present in the CDN:
2981 Message Type
2982 Result Code
2983 Assigned Session ID
2985 The following AVPs MAY be present in the CDN:
2987 Q.931 Cause Code
2989 6.13 WAN-Error-Notify (WEN)
2991 The WAN-Error-Notify message is an L2TP control message sent by the
2992 LAC to the LNS to indicate WAN error conditions (conditions that
2993 occur on the interface supporting PPP). The counters in this message
2994 are cumulative. This message should only be sent when an error
2995 occurs, and not more than once every 60 seconds. The counters are
2996 reset when a new call is established.
2998 The following AVPs MUST be present in the WEN:
3000 Message Type
3001 Call Errors
3003 6.14 Set-Link-Info (SLI)
3005 The Set-Link-Info message is an L2TP control message sent by the LNS
3006 to the LAC to set PPP-negotiated options. These options can change
3007 at any time during the life of the call, thus the LAC MUST be able to
3008 update its internal call information and behavior on an active PPP
3009 session.
3011 The following AVPs MUST be present in the SLI:
3013 Message Type
3014 ACCM
3016 7.0 Control Connection State Machines
3018 The control messages defined in section 6 are exchanged by way of
3019 state tables defined in this section. Tables are defined for incoming
3020 call placement, outgoing call placement, as well as for initiation of
3026 Townsley, et al. Standards Track [Page 54]
3027 \f
3028 RFC 2661 L2TP August 1999
3031 the tunnel itself. The state tables do not encode timeout and
3032 retransmission behavior, as this is handled in the underlying
3033 semantics defined in Section 5.8.
3035 7.1 Control Connection Protocol Operation
3037 This section describes the operation of various L2TP control
3038 connection functions and the Control Connection messages which are
3039 used to support them.
3041 Receipt of an invalid or unrecoverable malformed control message
3042 should be logged appropriately and the control connection cleared to
3043 ensure recovery to a known state. The control connection may then be
3044 restarted by the initiator.
3046 An invalid control message is defined as a message which contains a
3047 Message Type that is marked mandatory (see Section 4.4.1) and is
3048 unknown to the implementation, or a control message that is received
3049 in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ).
3051 Examples of a malformed control message include one that has an
3052 invalid value in its header, contains an AVP that is formatted
3053 incorrectly or whose value is out of range, or a message that is
3054 missing a required AVP. A control message with a malformed header
3055 should be discarded. A control message with an invalid AVP should
3056 look to the M-bit for that AVP to determine whether the error is
3057 recoverable or not.
3059 A malformed yet recoverable non-mandatory (M-bit is not set) AVP
3060 within a control message should be treated in a similar manner as an
3061 unrecognized non-mandatory AVP. Thus, if a malformed AVP is received
3062 with the M-bit set, the session or tunnel should be terminated with a
3063 proper Result or Error Code sent. If the M-bit is not set, the AVP
3064 should be ignored (with the exception of logging a local error
3065 message) and the message accepted.
3067 This MUST NOT be considered a license to send malformed AVPs, but
3068 simply a guide towards how to handle an improperly formatted message
3069 if one is received. It is impossible to list all potential
3070 malformations of a given message and give advice for each. That said,
3071 one example of a recoverable, malformed AVP might be if the Rx
3072 Connect Speed AVP, attribute 38, is received with a length of 8
3073 rather than 10 and the BPS given in 2 octets rather than 4. Since the
3074 Rx Connect Speed is non-mandatory, this condition should not be
3075 considered catastrophic. As such, the control message should be
3076 accepted as if the AVP had not been received (with the exception of a
3077 local error message being logged).
3082 Townsley, et al. Standards Track [Page 55]
3083 \f
3084 RFC 2661 L2TP August 1999
3087 In several cases in the following tables, a protocol message is sent,
3088 and then a "clean up" occurs. Note that regardless of the initiator
3089 of the tunnel destruction, the reliable delivery mechanism must be
3090 allowed to run (see Section 5.8) before destroying the tunnel. This
3091 permits the tunnel management messages to be reliably delivered to
3092 the peer.
3094 Appendix B.1 contains an example of lock-step tunnel establishment.
3096 7.2 Control Connection States
3098 The L2TP control connection protocol is not distinguishable between
3099 the LNS and LAC, but is distinguishable between the originator and
3100 receiver. The originating peer is the one which first initiates
3101 establishment of the tunnel (in a tie breaker situation, this is the
3102 winner of the tie). Since either LAC or LNS can be the originator, a
3103 collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a
3104 description of this and its resolution.
3106 7.2.1 Control Connection Establishment
3108 State Event Action New State
3109 ----- ----- ------ ---------
3110 idle Local Send SCCRQ wait-ctl-reply
3111 Open request
3113 idle Receive SCCRQ, Send SCCRP wait-ctl-conn
3114 acceptable
3116 idle Receive SCCRQ, Send StopCCN, idle
3117 not acceptable Clean up
3119 idle Receive SCCRP Send StopCCN idle
3120 Clean up
3122 idle Receive SCCCN Clean up idle
3124 wait-ctl-reply Receive SCCRP, Send SCCCN, established
3125 acceptable Send tunnel-open
3126 event to waiting
3127 sessions
3129 wait-ctl-reply Receive SCCRP, Send StopCCN, idle
3130 not acceptable Clean up
3132 wait-ctl-reply Receive SCCRQ, Clean up, idle
3133 lose tie-breaker Re-queue SCCRQ
3134 for idle state
3138 Townsley, et al. Standards Track [Page 56]
3139 \f
3140 RFC 2661 L2TP August 1999
3143 wait-ctl-reply Receive SCCCN Send StopCCN idle
3144 Clean up
3146 wait-ctl-conn Receive SCCCN, Send tunnel-open established
3147 acceptable event to waiting
3148 sessions
3150 wait-ctl-conn Receive SCCCN, Send StopCCN, idle
3151 not acceptable Clean up
3153 wait-ctl-conn Receive SCCRP, Send StopCCN, idle
3154 SCCRQ Clean up
3156 established Local Send tunnel-open established
3157 Open request event to waiting
3158 (new call) sessions
3160 established Admin Send StopCCN idle
3161 Tunnel Close Clean up
3163 established Receive SCCRQ, Send StopCCN idle
3164 SCCRP, SCCCN Clean up
3166 idle Receive StopCCN Clean up idle
3167 wait-ctl-reply,
3168 wait-ctl-conn,
3169 established
3171 The states associated with the LNS or LAC for control connection
3172 establishment are:
3174 idle
3175 Both initiator and recipient start from this state. An initiator
3176 transmits an SCCRQ, while a recipient remains in the idle state
3177 until receiving an SCCRQ.
3179 wait-ctl-reply
3180 The originator checks to see if another connection has been
3181 requested from the same peer, and if so, handles the collision
3182 situation described in Section 5.8.
3184 When an SCCRP is received, it is examined for a compatible
3185 version. If the version of the reply is lower than the version
3186 sent in the request, the older (lower) version should be used
3187 provided it is supported. If the version in the reply is earlier
3188 and supported, the originator moves to the established state. If
3194 Townsley, et al. Standards Track [Page 57]
3195 \f
3196 RFC 2661 L2TP August 1999
3199 the version is earlier and not supported, a StopCCN MUST be sent
3200 to the peer and the originator cleans up and terminates the
3201 tunnel.
3203 wait-ctl-conn
3204 This is where an SCCCN is awaited; upon receipt, the challenge
3205 response is checked. The tunnel either is established, or is torn
3206 down if an authorization failure is detected.
3208 established
3209 An established connection may be terminated by either a local
3210 condition or the receipt of a Stop-Control-Connection-
3211 Notification. In the event of a local termination, the originator
3212 MUST send a Stop-Control-Connection-Notification and clean up the
3213 tunnel.
3215 If the originator receives a Stop-Control-Connection-Notification
3216 it MUST also clean up the tunnel.
3218 7.3 Timing considerations
3220 Due to the real-time nature of telephone signaling, both the LNS and
3221 LAC should be implemented with multi-threaded architectures such that
3222 messages related to multiple calls are not serialized and blocked.
3223 The call and connection state figures do not specify exceptions
3224 caused by timers. These are addressed in Section 5.8.
3226 7.4 Incoming calls
3228 An Incoming-Call-Request message is generated by the LAC when an
3229 incoming call is detected (for example, an associated telephone line
3230 rings). The LAC selects a Session ID and serial number and indicates
3231 the call bearer type. Modems should always indicate analog call type.
3232 ISDN calls should indicate digital when unrestricted digital service
3233 or rate adaption is used and analog if digital modems are involved.
3234 Calling Number, Called Number, and Subaddress may be included in the
3235 message if they are available from the telephone network.
3237 Once the LAC sends the Incoming-Call-Request, it waits for a response
3238 from the LNS but it does not necessarily answer the call from the
3239 telephone network yet. The LNS may choose not to accept the call if:
3241 - No resources are available to handle more sessions
3242 - The dialed, dialing, or subaddress fields do not correspond to
3243 an authorized user
3244 - The bearer service is not authorized or supported
3250 Townsley, et al. Standards Track [Page 58]
3251 \f
3252 RFC 2661 L2TP August 1999
3255 If the LNS chooses to accept the call, it responds with an Incoming-
3256 Call-Reply. When the LAC receives the Incoming-Call-Reply, it
3257 attempts to connect the call. A final call connected message from
3258 the LAC to the LNS indicates that the call states for both the LAC
3259 and the LNS should enter the established state. If the call
3260 terminated before the LNS could accept it, a Call-Disconnect-Notify
3261 is sent by the LAC to indicate this condition.
3263 When the dialed-in client hangs up, the call is cleared normally and
3264 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to
3265 clear a call, it sends a Call-Disconnect-Notify message and cleans up
3266 its session.
3306 Townsley, et al. Standards Track [Page 59]
3307 \f
3308 RFC 2661 L2TP August 1999
3311 7.4.1 LAC Incoming Call States
3313 State Event Action New State
3314 ----- ----- ------ ---------
3315 idle Bearer Ring or Initiate local wait-tunnel
3316 Ready to indicate tunnel open
3317 incoming conn.
3319 idle Receive ICCN, Clean up idle
3320 ICRP, CDN
3322 wait-tunnel Bearer line drop Clean up idle
3323 or local close
3324 request
3326 wait-tunnel tunnel-open Send ICRQ wait-reply
3328 wait-reply Receive ICRP, Send ICCN established
3329 acceptable
3331 wait-reply Receive ICRP, Send CDN, idle
3332 Not acceptable Clean up
3334 wait-reply Receive ICRQ Send CDN idle
3335 Clean up
3337 wait-reply Receive CDN Clean up idle
3338 ICCN
3340 wait-reply Local Send CDN, idle
3341 close request or Clean up
3342 Bearer line drop
3344 established Receive CDN Clean up idle
3346 established Receive ICRQ, Send CDN, idle
3347 ICRP, ICCN Clean up
3349 established Bearer line Send CDN, idle
3350 drop or local Clean up
3351 close request
3362 Townsley, et al. Standards Track [Page 60]
3363 \f
3364 RFC 2661 L2TP August 1999
3367 The states associated with the LAC for incoming calls are:
3369 idle
3370 The LAC detects an incoming call on one of its interfaces.
3371 Typically this means an analog line is ringing or an ISDN TE has
3372 detected an incoming Q.931 SETUP message. The LAC initiates its
3373 tunnel establishment state machine, and moves to a state waiting
3374 for confirmation of the existence of a tunnel.
3376 wait-tunnel
3377 In this state the session is waiting for either the control
3378 connection to be opened or for verification that the tunnel is
3379 already open. Once an indication that the tunnel has/was opened,
3380 session control messages may be exchanged. The first of these is
3381 the Incoming-Call-Request.
3383 wait-reply
3384 The LAC receives either a CDN message indicating the LNS is not
3385 willing to accept the call (general error or don't accept) and
3386 moves back into the idle state, or an Incoming-Call-Reply message
3387 indicating the call is accepted, the LAC sends an Incoming-Call-
3388 Connected message and enters the established state.
3390 established
3391 Data is exchanged over the tunnel. The call may be cleared
3392 following:
3393 + An event on the connected interface: The LAC sends a Call-
3394 Disconnect-Notify message
3395 + Receipt of a Call-Disconnect-Notify message: The LAC cleans
3396 up, disconnecting the call.
3397 + A local reason: The LAC sends a Call-Disconnect-Notify
3398 message.
3418 Townsley, et al. Standards Track [Page 61]
3419 \f
3420 RFC 2661 L2TP August 1999
3423 7.4.2 LNS Incoming Call States
3425 State Event Action New State
3426 ----- ----- ------ ---------
3427 idle Receive ICRQ, Send ICRP wait-connect
3428 acceptable
3430 idle Receive ICRQ, Send CDN, idle
3431 not acceptable Clean up
3433 idle Receive ICRP Send CDN idle
3434 Clean up
3436 idle Receive ICCN Clean up idle
3438 wait-connect Receive ICCN Prepare for established
3439 acceptable data
3441 wait-connect Receive ICCN Send CDN, idle
3442 not acceptable Clean up
3444 wait-connect Receive ICRQ, Send CDN idle
3445 ICRP Clean up
3447 idle, Receive CDN Clean up idle
3448 wait-connect,
3449 established
3451 wait-connect Local Send CDN, idle
3452 established Close request Clean up
3454 established Receive ICRQ, Send CDN idle
3455 ICRP, ICCN Clean up
3457 The states associated with the LNS for incoming calls are:
3459 idle
3460 An Incoming-Call-Request message is received. If the request is
3461 not acceptable, a Call-Disconnect-Notify is sent back to the LAC
3462 and the LNS remains in the idle state. If the Incoming-Call-
3463 Request message is acceptable, an Incoming-Call-Reply is sent. The
3464 session moves to the wait-connect state.
3466 wait-connect
3467 If the session is still connected on the LAC, the LAC sends an
3468 Incoming-Call-Connected message to the LNS which then moves into
3469 established state. The LAC may send a Call-Disconnect-Notify to
3470 indicate that the incoming caller could not be connected. This
3474 Townsley, et al. Standards Track [Page 62]
3475 \f
3476 RFC 2661 L2TP August 1999
3479 could happen, for example, if a telephone user accidentally places
3480 a standard voice call to an LAC resulting in a handshake failure
3481 on the called modem.
3483 established
3484 The session is terminated either by receipt of a Call-Disconnect-
3485 Notify message from the LAC or by sending a Call-Disconnect-
3486 Notify. Clean up follows on both sides regardless of the
3487 initiator.
3489 7.5 Outgoing calls
3491 Outgoing calls are initiated by an LNS and instruct an LAC to place a
3492 call. There are three messages for outgoing calls: Outgoing-Call-
3493 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS
3494 sends an Outgoing-Call-Request specifying the dialed party phone
3495 number, subaddress and other parameters. The LAC MUST respond to the
3496 Outgoing-Call-Request message with an Outgoing-Call-Reply message
3497 once the LAC determines that the proper facilities exist to place the
3498 call and the call is administratively authorized. For example, is
3499 this LNS allowed to dial an international call? Once the outbound
3500 call is connected, the LAC sends an Outgoing-Call-Connected message
3501 to the LNS indicating the final result of the call attempt:
3530 Townsley, et al. Standards Track [Page 63]
3531 \f
3532 RFC 2661 L2TP August 1999
3535 7.5.1 LAC Outgoing Call States
3537 State Event Action New State
3538 ----- ----- ------ ---------
3539 idle Receive OCRQ, Send OCRP, wait-cs-answer
3540 acceptable Open bearer
3542 idle Receive OCRQ, Send CDN, idle
3543 not acceptable Clean up
3545 idle Receive OCRP Send CDN idle
3546 Clean up
3548 idle Receive OCCN, Clean up idle
3549 CDN
3551 wait-cs-answer Bearer answer, Send OCCN established
3552 framing detected
3554 wait-cs-answer Bearer failure Send CDN, idle
3555 Clean up
3557 wait-cs-answer Receive OCRQ, Send CDN idle
3558 OCRP, OCCN Clean up
3560 established Receive OCRQ, Send CDN idle
3561 OCRP, OCCN Clean up
3563 wait-cs-answer, Receive CDN Clean up idle
3564 established
3566 established Bearer line drop, Send CDN, idle
3567 Local close Clean up
3568 request
3570 The states associated with the LAC for outgoing calls are:
3572 idle
3573 If Outgoing-Call-Request is received in error, respond with a
3574 Call-Disconnect-Notify. Otherwise, allocate a physical channel and
3575 send an Outgoing-Call-Reply. Place the outbound call and move to
3576 the wait-cs-answer state.
3578 wait-cs-answer
3579 If the call is not completed or a timer expires waiting for the
3580 call to complete, send a Call-Disconnect-Notify with the
3581 appropriate error condition set and go to idle state. If a circuit
3586 Townsley, et al. Standards Track [Page 64]
3587 \f
3588 RFC 2661 L2TP August 1999
3591 switched connection is established and framing is detected, send
3592 an Outgoing-Call-Connected indicating success and go to
3593 established state.
3595 established
3596 If a Call-Disconnect-Notify is received by the LAC, the telco call
3597 MUST be released via appropriate mechanisms and the session
3598 cleaned up. If the call is disconnected by the client or the
3599 called interface, a Call-Disconnect-Notify message MUST be sent to
3600 the LNS. The sender of the Call-Disconnect-Notify message returns
3601 to the idle state after sending of the message is complete.
3642 Townsley, et al. Standards Track [Page 65]
3643 \f
3644 RFC 2661 L2TP August 1999
3647 7.5.2 LNS Outgoing Call States
3649 State Event Action New State
3650 ----- ----- ------ ---------
3651 idle Local Initiate local wait-tunnel
3652 open request tunnel-open
3654 idle Receive OCCN, Clean up idle
3655 OCRP, CDN
3657 wait-tunnel tunnel-open Send OCRQ wait-reply
3659 wait-reply Receive OCRP, none wait-connect
3660 acceptable
3662 wait-reply Receive OCRP, Send CDN idle
3663 not acceptable Clean up
3665 wait-reply Receive OCCN, Send CDN idle
3666 OCRQ Clean up
3668 wait-connect Receive OCCN none established
3670 wait-connect Receive OCRQ, Send CDN idle
3671 OCRP Clean up
3673 idle, Receive CDN, Clean up idle
3674 wait-reply,
3675 wait-connect,
3676 established
3678 established Receive OCRQ, Send CDN idle
3679 OCRP, OCCN Clean up
3681 wait-reply, Local Send CDN idle
3682 wait-connect, Close request Clean up
3683 established
3685 wait-tunnel Local Clean up idle
3686 Close request
3688 The states associated with the LNS for outgoing calls are:
3690 idle, wait-tunnel
3691 When an outgoing call is initiated, a tunnel is first created,
3692 much as the idle and wait-tunnel states for an LAC incoming call.
3693 Once a tunnel is established, an Outgoing-Call-Request message is
3694 sent to the LAC and the session moves into the wait-reply state.
3698 Townsley, et al. Standards Track [Page 66]
3699 \f
3700 RFC 2661 L2TP August 1999
3703 wait-reply
3704 If a Call-Disconnect-Notify is received, an error occurred, and
3705 the session is cleaned up and returns to idle. If an Outgoing-
3706 Call-Reply is received, the call is in progress and the session
3707 moves to the wait-connect state.
3709 wait-connect
3710 If a Call-Disconnect-Notify is received, the call failed; the
3711 session is cleaned up and returns to idle. If an Outgoing-Call-
3712 Connected is received, the call has succeeded and the session may
3713 now exchange data.
3715 established
3716 If a Call-Disconnect-Notify is received, the call has been
3717 terminated for the reason indicated in the Result and Cause Codes;
3718 the session moves back to the idle state. If the LNS chooses to
3719 terminate the session, it sends a Call-Disconnect-Notify to the
3720 LAC and then cleans up and idles its session.
3722 7.6 Tunnel Disconnection
3724 The disconnection of a tunnel consists of either peer issuing a
3725 Stop-Control-Connection-Notification. The sender of this Notification
3726 should wait a finite period of time for the acknowledgment of this
3727 message before releasing the control information associated with the
3728 tunnel. The recipient of this Notification should send an
3729 acknowledgment of the Notification and then release the associated
3730 control information.
3732 When to release a tunnel is an implementation issue and is not
3733 specified in this document. A particular implementation may use
3734 whatever policy is appropriate for determining when to release a
3735 control connection. Some implementations may leave a tunnel open for
3736 a period of time or perhaps indefinitely after the last session for
3737 that tunnel is cleared. Others may choose to disconnect the tunnel
3738 immediately after the last user connection on the tunnel disconnects.
3740 8.0 L2TP Over Specific Media
3742 L2TP is self-describing, operating at a level above the media over
3743 which it is carried. However, some details of its connection to media
3744 are required to permit interoperable implementations. The following
3745 sections describe details needed to permit interoperability over
3746 specific media.
3754 Townsley, et al. Standards Track [Page 67]
3755 \f
3756 RFC 2661 L2TP August 1999
3759 8.1 L2TP over UDP/IP
3761 L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP
3762 packet, including payload and L2TP header, is sent within a UDP
3763 datagram. The initiator of an L2TP tunnel picks an available source
3764 UDP port (which may or may not be 1701), and sends to the desired
3765 destination address at port 1701. The recipient picks a free port on
3766 its own system (which may or may not be 1701), and sends its reply to
3767 the initiator's UDP port and address, setting its own source port to
3768 the free port it found. Once the source and destination ports and
3769 addresses are established, they MUST remain static for the life of
3770 the tunnel.
3772 It has been suggested that having the recipient choose an arbitrary
3773 source port (as opposed to using the destination port in the packet
3774 initiating the tunnel, i.e., 1701) may make it more difficult for
3775 L2TP to traverse some NAT devices. Implementors should consider the
3776 potential implication of this before before choosing an arbitrary
3777 source port.
3779 IP fragmentation may occur as the L2TP packet travels over the IP
3780 substrate. L2TP makes no special efforts to optimize this. A LAC
3781 implementation MAY cause its LCP to negotiate for a specific MRU,
3782 which could optimize for LAC environments in which the MTU's of the
3783 path over which the L2TP packets are likely to travel have a
3784 consistent value.
3786 The default for any L2TP implementation is that UDP checksums MUST be
3787 enabled for both control and data messages. An L2TP implementation
3788 MAY provide an option to disable UDP checksums for data messages. It
3789 is recommended that UDP checksums always be enabled on control
3790 packets.
3792 Port 1701 is used for both L2F [RFC2341] and L2TP packets. The
3793 Version field in each header may be used to discriminate between the
3794 two packet types (L2F uses a value of 1, and the L2TP version
3795 described in this document uses a value of 2). An L2TP implementation
3796 running on a system which does not support L2F MUST silently discard
3797 all L2F packets.
3799 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has
3800 the characteristic of being able to reorder or silently drop packets.
3801 The former may break non-IP protocols being carried by PPP,
3802 especially LAN-centric ones such as bridging. The latter may break
3803 protocols which assume per-packet indication of error, such as TCP
3804 header compression. Sequencing may be handled by using L2TP data
3805 message sequence numbers if any protocol being transported by the PPP
3810 Townsley, et al. Standards Track [Page 68]
3811 \f
3812 RFC 2661 L2TP August 1999
3815 tunnel cannot tolerate reordering. The sequence dependency
3816 characteristics of individual protocols are outside the scope of this
3817 document.
3819 Allowing packets to be dropped silently is perhaps more problematic
3820 with some protocols. If PPP reliable delivery [RFC1663] is enabled,
3821 no upper PPP protocol will encounter lost packets. If L2TP sequence
3822 numbers are enabled, L2TP can detect the packet loss. In the case of
3823 an LNS, the PPP and L2TP stacks are both present within the LNS, and
3824 packet loss signaling may occur precisely as if a packet was received
3825 with a CRC error. Where the LAC and PPP stack are co-resident, this
3826 technique also applies. Where the LAC and PPP client are physically
3827 distinct, the analogous signaling MAY be accomplished by sending a
3828 packet with a CRC error to the PPP client. Note that this would
3829 greatly increase the complexity of debugging client line problems,
3830 since the client statistics could not distinguish between true media
3831 errors and LAC-initiated ones. Further, this technique is not
3832 possible on all hardware.
3834 If VJ compression is used, and neither PPP reliable delivery nor
3835 sequence numbers are enabled, each lost packet results in a 1 in
3836 2**16 chance of a TCP segment being forwarded with incorrect contents
3837 [RFC1144]. Where the combination of the packet loss rate with this
3838 statistical exposure is unacceptable, TCP header compression SHOULD
3839 NOT be used.
3841 In general, it is wise to remember that the L2TP/UDP/IP transport is
3842 an unreliable transport. As with any PPP media that is subject to
3843 loss, care should be taken when using protocols that are particularly
3844 loss-sensitive. Such protocols include compression and encryption
3845 protocols that employ history.
3847 8.2 IP
3849 When operating in IP environments, L2TP MUST offer the UDP
3850 encapsulation described in 8.1 as its default configuration for IP
3851 operation. Other configurations (perhaps corresponding to a
3852 compressed header format) MAY be defined and made available as a
3853 configurable option.
3855 9.0 Security Considerations
3857 L2TP encounters several security issues in its operation. The
3858 general approach of L2TP to these issues is documented here.
3866 Townsley, et al. Standards Track [Page 69]
3867 \f
3868 RFC 2661 L2TP August 1999
3871 9.1 Tunnel Endpoint Security
3873 The tunnel endpoints may optionally perform an authentication
3874 procedure of one another during tunnel establishment. This
3875 authentication has the same security attributes as CHAP, and has
3876 reasonable protection against replay and snooping during the tunnel
3877 establishment process. This mechanism is not designed to provide any
3878 authentication beyond tunnel establishment; it is fairly simple for a
3879 malicious user who can snoop the tunnel stream to inject packets once
3880 an authenticated tunnel establishment has been completed
3881 successfully.
3883 For authentication to occur, the LAC and LNS MUST share a single
3884 secret. Each side uses this same secret when acting as authenticatee
3885 as well as authenticator. Since a single secret is used, the tunnel
3886 authentication AVPs include differentiating values in the CHAP ID
3887 fields for each message digest calculation to guard against replay
3888 attacks.
3890 The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3)
3891 SHOULD be selected in an unpredictable manner rather than
3892 sequentially or otherwise. Doing so will help deter hijacking of a
3893 session by a malicious user who does not have access to packet traces
3894 between the LAC and LNS.
3896 9.2 Packet Level Security
3898 Securing L2TP requires that the underlying transport make available
3899 encryption, integrity and authentication services for all L2TP
3900 traffic. This secure transport operates on the entire L2TP packet
3901 and is functionally independent of PPP and the protocol being carried
3902 by PPP. As such, L2TP is only concerned with confidentiality,
3903 authenticity, and integrity of the L2TP packets between its tunnel
3905 endpoints (the LAC and LNS), not unlike link-layer encryption being
3906 concerned only about protecting the confidentiality of traffic
3907 between its physical endpoints.
3909 9.3 End to End Security
3911 Protecting the L2TP packet stream via a secure transport does, in
3912 turn, also protect the data within the tunneled PPP packets while
3913 transported from the LAC to the LNS. Such protection should not be
3914 considered a substitution for end-to-end security between
3915 communicating hosts or applications.
3922 Townsley, et al. Standards Track [Page 70]
3923 \f
3924 RFC 2661 L2TP August 1999
3927 9.4 L2TP and IPsec
3929 When running over IP, IPsec provides packet-level security via ESP
3930 and/or AH. All L2TP control and data packets for a particular tunnel
3931 appear as homogeneous UDP/IP data packets to the IPsec system.
3933 In addition to IP transport security, IPsec defines a mode of
3934 operation that allows tunneling of IP packets. The packet level
3935 encryption and authentication provided by IPsec tunnel mode and that
3936 provided by L2TP secured with IPsec provide an equivalent level of
3937 security for these requirements.
3939 IPsec also defines access control features that are required of a
3940 compliant IPsec implementation. These features allow filtering of
3941 packets based upon network and transport layer characteristics such
3942 as IP address, ports, etc. In the L2TP tunneling model, analogous
3943 filtering is logically performed at the PPP layer or network layer
3944 above L2TP. These network layer access control features may be
3945 handled at the LNS via vendor-specific authorization features based
3946 upon the authenticated PPP user, or at the network layer itself by
3947 using IPsec transport mode end-to-end between the communicating
3948 hosts. The requirements for access control mechanisms are not a part
3949 of the L2TP specification and as such are outside the scope of this
3950 document.
3952 9.5 Proxy PPP Authentication
3954 L2TP defines AVPs that MAY be exchanged during session establishment
3955 to provide forwarding of PPP authentication information obtained at
3956 the LAC to the LNS for validation (see Section 4.4.5). This implies a
3957 direct trust relationship of the LAC on behalf of the LNS. If the
3958 LNS chooses to implement proxy authentication, it MUST be able to be
3959 configured off, requiring a new round a PPP authentication initiated
3960 by the LNS (which may or may not include a new round of LCP
3961 negotiation).
3963 10.0 IANA Considerations
3965 This document defines a number of "magic" numbers to be maintained by
3966 the IANA. This section explains the criteria to be used by the IANA
3967 to assign additional numbers in each of these lists. The following
3968 subsections describe the assignment policy for the namespaces defined
3969 elsewhere in this document.
3971 10.1 AVP Attributes
3973 As defined in Section 4.1, AVPs contain vendor ID, Attribute and
3974 Value fields. For vendor ID value of 0, IANA will maintain a registry
3978 Townsley, et al. Standards Track [Page 71]
3979 \f
3980 RFC 2661 L2TP August 1999
3983 of assigned Attributes and in some case also values. Attributes 0-39
3984 are assigned as defined in Section 4.4. The remaining values are
3985 available for assignment through IETF Consensus [RFC 2434].
3987 10.2 Message Type AVP Values
3989 As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0)
3990 have an associated value maintained by IANA. Values 0-16 are defined
3991 in Section 3.2, the remaining values are available for assignment via
3992 IETF Consensus [RFC 2434]
3994 10.3 Result Code AVP Values
3996 As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1)
3997 contain three fields. Two of these fields (the Result Code and Error
3998 Code fields) have associated values maintained by IANA.
4000 10.3.1 Result Code Field Values
4002 The Result Code AVP may be included in CDN and StopCCN messages. The
4003 allowable values for the Result Code field of the AVP differ
4004 depending upon the value of the Message Type AVP. For the StopCCN
4005 message, values 0-7 are defined in Section 4.4.2; for the StopCCN
4006 message, values 0-11 are defined in the same section. The remaining
4007 values of the Result Code field for both messages are available for
4008 assignment via IETF Consensus [RFC 2434].
4010 10.3.2 Error Code Field Values
4012 Values 0-7 are defined in Section 4.4.2. Values 8-32767 are
4013 available for assignment via IETF Consensus [RFC 2434]. The remaining
4014 values of the Error Code field are available for assignment via First
4015 Come First Served [RFC 2434].
4017 10.4 Framing Capabilities & Bearer Capabilities
4019 The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in
4020 Section 4.4.3) both contain 32-bit bitmasks. Additional bits should
4021 only be defined via a Standards Action [RFC 2434].
4023 10.5 Proxy Authen Type AVP Values
4025 The Proxy Authen Type AVP (Attribute Type 29) has an associated value
4026 maintained by IANA. Values 0-5 are defined in Section 4.4.5, the
4027 remaining values are available for assignment via First Come First
4028 Served [RFC 2434].
4034 Townsley, et al. Standards Track [Page 72]
4035 \f
4036 RFC 2661 L2TP August 1999
4039 10.6 AVP Header Bits
4041 There are four remaining reserved bits in the AVP header. Additional
4042 bits should only be assigned via a Standards Action [RFC 2434].
4044 11.0 References
4046 [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System
4047 No. 1 (DSS 1) - ISDN user-network interface layer 3
4048 specification for basic call control", Rec. Q.931(I.451),
4049 May 1998
4051 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
4052 Security: Private Communications in a Public World",
4053 Prentice Hall, March 1995, ISBN 0-13-061466-1
4055 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
4056 1981.
4058 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
4059 STD 13, RFC 1034, November 1987.
4061 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
4062 Serial Links", RFC 1144, February 1990.
4064 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
4065 RFC 1661, July 1994.
4067 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
4068 July 1994.
4070 [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
4072 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
4073 1700, October 1994. See also:
4074 http://www.iana.org/numbers.html
4075 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
4076 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
4077 August 1996.
4079 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
4080 Protocol (CHAP)", RFC 1994, August 1996.
4082 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
4083 and E. Lear, "Address Allocation for Private Internets",
4084 BCP 5, RFC 1918, February 1996.
4090 Townsley, et al. Standards Track [Page 73]
4091 \f
4092 RFC 2661 L2TP August 1999
4095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4096 Requirement Levels", BCP 14, RFC 2119, March 1997.
4098 [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
4099 Authentication Dial In User Service (RADIUS)", RFC 2138,
4100 April 1997.
4102 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
4103 Languages", BCP 18, RFC 2277, January 1998.
4105 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
4106 Forwarding (Protocol) L2F", RFC 2341, May 1998.
4108 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
4109 Internet Protocol", RFC 2401, November 1998.
4111 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
4112 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
4113 October 1998.
4115 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
4116 and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
4117 RFC 2637, July 1999.
4119 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
4120 Protocols", Addison-Wesley Publishing Company, Inc., March
4121 1996, ISBN 0-201-63346-9
4123 12.0 Acknowledgments
4125 The basic concept for L2TP and many of its protocol constructs were
4126 adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A.
4127 Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein,
4128 J. Taarud, W. Little, and G. Zorn.
4130 Dory Leifer made valuable refinements to the protocol definition of
4131 L2TP and contributed to the editing of this document.
4133 Steve Cobb and Evan Caves redesigned the state machine tables.
4135 Barney Wolff provided a great deal of design input on the endpoint
4136 authentication mechanism.
4138 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
4139 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
4140 review at the 43rd IETF in Orlando, FL., which led to improvement of
4141 the overall readability and clarity of this document.
4146 Townsley, et al. Standards Track [Page 74]
4147 \f
4148 RFC 2661 L2TP August 1999
4151 13.0 Authors' Addresses
4153 Gurdeep Singh Pall
4154 Microsoft Corporation
4155 Redmond, WA
4157 EMail: gurdeep@microsoft.com
4160 Bill Palter
4161 RedBack Networks, Inc
4162 1389 Moffett Park Drive
4163 Sunnyvale, CA 94089
4165 EMail: palter@zev.net
4168 Allan Rubens
4169 Ascend Communications
4170 1701 Harbor Bay Parkway
4171 Alameda, CA 94502
4173 EMail: acr@del.com
4176 W. Mark Townsley
4177 cisco Systems
4178 7025 Kit Creek Road
4179 PO Box 14987
4180 Research Triangle Park, NC 27709
4182 EMail: townsley@cisco.com
4185 Andrew J. Valencia
4186 cisco Systems
4187 170 West Tasman Drive
4188 San Jose CA 95134-1706
4190 EMail: vandys@cisco.com
4193 Glen Zorn
4194 Microsoft Corporation
4195 One Microsoft Way
4196 Redmond, WA 98052
4198 EMail: gwz@acm.org
4202 Townsley, et al. Standards Track [Page 75]
4203 \f
4204 RFC 2661 L2TP August 1999
4207 Appendix A: Control Channel Slow Start and Congestion Avoidance
4209 Although each side has indicated the maximum size of its receive
4210 window, it is recommended that a slow start and congestion avoidance
4211 method be used to transmit control packets. The methods described
4212 here are based upon the TCP congestion avoidance algorithm as
4213 described in section 21.6 of TCP/IP Illustrated, Volume I, by W.
4214 Richard Stevens [STEVENS].
4216 Slow start and congestion avoidance make use of several variables.
4217 The congestion window (CWND) defines the number of packets a sender
4218 may send before waiting for an acknowledgment. The size of CWND
4219 expands and contracts as described below. Note however, that CWND is
4220 never allowed to exceed the size of the advertised window obtained
4221 from the Receive Window AVP (in the text below, it is assumed any
4222 increase will be limited by the Receive Window Size). The variable
4223 SSTHRESH determines when the sender switches from slow start to
4224 congestion avoidance. Slow start is used while CWND is less than
4225 SSHTRESH.
4227 A sender starts out in the slow start phase. CWND is initialized to
4228 one packet, and SSHTRESH is initialized to the advertised window
4229 (obtained from the Receive Window AVP). The sender then transmits
4230 one packet and waits for its acknowledgement (either explicit or
4231 piggybacked). When the acknowledgement is received, the congestion
4232 window is incremented from one to two. During slow start, CWND is
4233 increased by one packet each time an ACK (explicit ZLB or
4234 piggybacked) is received. Increasing CWND by one on each ACK has the
4235 effect of doubling CWND with each round trip, resulting in an
4236 exponential increase. When the value of CWND reaches SSHTRESH, the
4237 slow start phase ends and the congestion avoidance phase begins.
4239 During congestion avoidance, CWND expands more slowly. Specifically,
4240 it increases by 1/CWND for every new ACK received. That is, CWND is
4241 increased by one packet after CWND new ACKs have been received.
4242 Window expansion during the congestion avoidance phase is effectively
4243 linear, with CWND increasing by one packet each round trip.
4245 When congestion occurs (indicated by the triggering of a
4246 retransmission) one half of the CWND is saved in SSTHRESH, and CWND
4247 is set to one. The sender then reenters the slow start phase.
4258 Townsley, et al. Standards Track [Page 76]
4259 \f
4260 RFC 2661 L2TP August 1999
4263 Appendix B: Control Message Examples
4265 B.1: Lock-step tunnel establishment
4267 In this example, an LAC establishes a tunnel, with the exchange
4268 involving each side alternating in sending messages. This example
4269 shows the final acknowledgment explicitly sent within a ZLB ACK
4270 message. An alternative would be to piggyback the acknowledgement
4271 within a message sent as a reply to the ICRQ or OCRQ that will likely
4272 follow from the side that initiated the tunnel.
4274 LAC or LNS LNS or LAC
4275 ---------- ----------
4277 SCCRQ ->
4278 Nr: 0, Ns: 0
4279 <- SCCRP
4280 Nr: 1, Ns: 0
4281 SCCCN ->
4282 Nr: 1, Ns: 1
4283 <- ZLB
4284 Nr: 2, Ns: 1
4286 B.2: Lost packet with retransmission
4288 An existing tunnel has a new session requested by the LAC. The ICRP
4289 is lost and must be retransmitted by the LNS. Note that loss of the
4290 ICRP has two impacts: not only does it keep the upper level state
4291 machine from progressing, but it also keeps the LAC from seeing a
4292 timely lower level acknowledgment of its ICRQ.
4294 LAC LNS
4295 --- ---
4297 ICRQ ->
4298 Nr: 1, Ns: 2
4300 (packet lost) <- ICRP
4301 Nr: 3, Ns: 1
4303 (pause; LAC's timer started first, so fires first)
4305 ICRQ ->
4306 Nr: 1, Ns: 2
4308 (Realizing that it has already seen this packet,
4309 the LNS discards the packet and sends a ZLB)
4314 Townsley, et al. Standards Track [Page 77]
4315 \f
4316 RFC 2661 L2TP August 1999
4319 <- ZLB
4320 Nr: 3, Ns: 2
4322 (LNS's retransmit timer fires)
4324 <- ICRP
4325 Nr: 3, Ns: 1
4326 ICCN ->
4327 Nr: 2, Ns: 3
4329 <- ZLB
4330 Nr: 4, Ns: 2
4370 Townsley, et al. Standards Track [Page 78]
4371 \f
4372 RFC 2661 L2TP August 1999
4375 Appendix C: Intellectual Property Notice
4377 The IETF takes no position regarding the validity or scope of any
4378 intellectual property or other rights that might be claimed to
4379 pertain to the implementation or use of the technology described in
4380 this document or the extent to which any license under such rights
4381 might or might not be available; neither does it represent that it
4382 has made any effort to identify any such rights. Information on the
4383 IETF's procedures with respect to rights in standards-track and
4384 standards-related documentation can be found in BCP-11. Copies of
4385 claims of rights made available for publication and any assurances of
4386 licenses to be made available, or the result of an attempt made to
4387 obtain a general license or permission for the use of such
4388 proprietary rights by implementers or users of this specification can
4389 be obtained from the IETF Secretariat."
4391 The IETF invites any interested party to bring to its attention any
4392 copyrights, patents or patent applications, or other proprietary
4393 rights which may cover technology that may be required to practice
4394 this standard. Please address the information to the IETF Executive
4395 Director.
4397 The IETF has been notified of intellectual property rights claimed in
4398 regard to some or all of the specification contained in this
4399 document. For more information consult the online list of claimed
4400 rights.
4426 Townsley, et al. Standards Track [Page 79]
4427 \f
4428 RFC 2661 L2TP August 1999
4431 Full Copyright Statement
4433 Copyright (C) The Internet Society (1999). All Rights Reserved.
4435 This document and translations of it may be copied and furnished to
4436 others, and derivative works that comment on or otherwise explain it
4437 or assist in its implementation may be prepared, copied, published
4438 and distributed, in whole or in part, without restriction of any
4439 kind, provided that the above copyright notice and this paragraph are
4440 included on all such copies and derivative works. However, this
4441 document itself may not be modified in any way, such as by removing
4442 the copyright notice or references to the Internet Society or other
4443 Internet organizations, except as needed for the purpose of
4444 developing Internet standards in which case the procedures for
4445 copyrights defined in the Internet Standards process must be
4446 followed, or as required to translate it into languages other than
4447 English.
4449 The limited permissions granted above are perpetual and will not be
4450 revoked by the Internet Society or its successors or assigns.
4452 This document and the information contained herein is provided on an
4453 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
4454 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
4455 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
4456 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
4457 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
4459 Acknowledgement
4461 Funding for the RFC Editor function is currently provided by the
4462 Internet Society.
4482 Townsley, et al. Standards Track [Page 80]
4483 \f