< draft-ietf-pppext-l2tp-15.txt   draft-ietf-pppext-l2tp-16.txt >
Network Working Group W. M. Townsley Network Working Group W. M. Townsley
Internet-Draft A. Valencia Internet-Draft A. Valencia
Category: Standards Track cisco Systems Category: Standards Track cisco Systems
<draft-ietf-pppext-l2tp-15.txt> A. Rubens <draft-ietf-pppext-l2tp-16.txt> A. Rubens
Ascend Communications Ascend Communications
G. S. Pall G. S. Pall
G. Zorn G. Zorn
Microsoft Corporation Microsoft Corporation
B. Palter B. Palter
Redback Networks Redback Networks
May 1999 June 1999
Layer Two Tunneling Protocol "L2TP" Layer Two Tunneling Protocol "L2TP"
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 43
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft- The distribution of this memo is unlimited. It is filed as <draft-
ietf-pppext-l2tp-15.txt> and expires November 30, 1999. Please send ietf-pppext-l2tp-16.txt> and expires December 31, 1999. Please send
comments to the L2TP mailing list (l2tp@ipsec.org). comments to the L2TP mailing list (l2tp@ipsec.org).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document describes the Layer Two Tunneling Protocol (L2TP). RFC This document describes the Layer Two Tunneling Protocol (L2TP). RFC
1661 specifies multi-protocol access via PPP [RFC1661]. L2TP 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP
facilitates the tunneling of PPP packets across an intervening facilitates the tunneling of PPP packets across an intervening
network in a way that is as transparent as possible to both end-users network in a way that is as transparent as possible to both end-users
and applications. and applications.
Table of Contents Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 Status of this Memo.......................................... 1
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.0 Introduction.......................................... 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Specification of Requirements......................... 5
2.0 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Terminology........................................... 5
3.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 2.0 Topology.............................................. 8
3.1 L2TP Header Format . . . . . . . . . . . . . . . . . . . . 9 3.0 Protocol Overview..................................... 9
3.2 Control Message Types . . . . . . . . . . . . . . . . . . 11 3.1 L2TP Header Format.................................... 10
4.0 Control Message Attribute Value Pairs . . . . . . . . . . 12 3.2 Control Message Types................................. 12
4.1 AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 12 4.0 Control Message Attribute Value Pairs................. 13
4.2 Hiding of AVP Values . . . . . . . . . . . . . . . . . . . 13 4.1 AVP Format............................................ 13
4.3 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Mandatory AVPs........................................ 14
4.3.1 AVPs Applicable To All Control Messages . . . . . . . . . 16 4.3 Hiding of AVP Attribute Values........................ 15
4.3.2 Result and Error Codes . . . . . . . . . . . . . . . . . . 17 4.4 AVP Summary........................................... 17
4.3.3 Control Connection Management AVPs . . . . . . . . . . . . 19 5.0 Protocol Operation.................................... 40
4.3.4 Call Management AVPs . . . . . . . . . . . . . . . . . . . 25 5.1 Control Connection Establishment...................... 41
4.3.5 Proxy LCP and Authentication AVPs . . . . . . . . . . . . 32 5.2 Session Establishment................................. 42
4.3.6 Call Status AVPs . . . . . . . . . . . . . . . . . . . . . 37 5.3 Forwarding PPP Frames................................. 43
5.0 Protocol Operation . . . . . . . . . . . . . . . . . . . . 38 5.4 Using Sequence Numbers on the Data Channel............ 43
5.1 Control Connection Establishment . . . . . . . . . . . . . 39 5.5 Keepalive (Hello)..................................... 44
5.1.1 Tunnel Authentication . . . . . . . . . . . . . . . . . . 39 5.6 Session Teardown...................................... 45
5.2 Session Establishment . . . . . . . . . . . . . . . . . . 40 5.7 Control Connection Teardown........................... 45
5.2.1 Incoming Call Establishment . . . . . . . . . . . . . . . 40 5.8 Reliable Delivery of Control Messages................. 45
5.2.2 Outgoing Call Establishment . . . . . . . . . . . . . . . 40 6.0 Control Connection Protocol Specification............. 47
5.3 Forwarding PPP Frames . . . . . . . . . . . . . . . . . . 41 6.1 Start-Control-Connection-Request (SCCRQ).............. 48
5.4 Using Sequence Numbers on the Data Channel . . . . . . . . 41 6.2 Start-Control-Connection-Reply (SCCRP)................ 48
5.5 Keepalive (Hello) . . . . . . . . . . . . . . . . . . . . 42 6.3 Start-Control-Connection-Connected (SCCCN)............ 49
5.6 Session Teardown . . . . . . . . . . . . . . . . . . . . . 43 6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
5.7 Control Connection Teardown . . . . . . . . . . . . . . . 43 6.5 Hello (HELLO)......................................... 49
5.8 Reliable Delivery of Control Messages . . . . . . . . . . 43 6.6 Incoming-Call-Request (ICRQ).......................... 50
6.0 Control Connection Protocol Specification . . . . . . . . 45 6.7 Incoming-Call-Reply (ICRP)............................ 51
6.1 Start-Control-Connection-Request (SCCRQ) . . . . . . . . . 45 6.8 Incoming-Call-Connected (ICCN)........................ 51
6.2 Start-Control-Connection-Reply (SCCRP) . . . . . . . . . . 46 6.9 Outgoing-Call-Request (OCRQ).......................... 52
6.3 Start-Control-Connection-Connected (SCCCN) . . . . . . . . 46 6.10 Outgoing-Call-Reply (OCRP)........................... 52
6.4 Stop-Control-Connection-Notification (StopCCN) . . . . . . 47 6.11 Outgoing-Call-Connected (OCCN)....................... 53
6.5 Hello (HELLO) . . . . . . . . . . . . . . . . . . . . . . 47 6.12 Call-Disconnect-Notify (CDN)......................... 53
6.6 Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . . 48 6.13 WAN-Error-Notify (WEN)............................... 53
6.7 Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 48 6.14 Set-Link-Info (SLI).................................. 54
6.8 Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . . 49 7.0 Control Connection State Machines..................... 54
6.9 Outgoing-Call-Request (ICRQ) . . . . . . . . . . . . . . . 49 7.1 Control Connection Protocol Operation................. 54
6.10 Outgoing-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 50 7.2 Control Connection States............................. 55
6.11 Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . . 50 7.2.1 Control Connection Establishment................. 55
6.12 Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . . 51 7.3 Timing considerations................................. 57
6.13 WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . . 51 7.4 Incoming calls........................................ 58
6.14 Set-Link-Info (SLI) . . . . . . . . . . . . . . . . . . . 52 7.4.1 LAC Incoming Call States......................... 58
7.0 Control Connection State Machines . . . . . . . . . . . . 52 7.4.2 LNS Incoming Call States......................... 60
7.1 Control Connection Protocol Operation . . . . . . . . . . 52 7.5 Outgoing calls........................................ 61
7.2 Control Connection States . . . . . . . . . . . . . . . . 52 7.5.1 LAC Outgoing Call States......................... 62
7.2.1 Control Connection Establishment . . . . . . . . . . . . . 52 7.5.2 LNS Outgoing Call States......................... 63
7.3 Timing considerations . . . . . . . . . . . . . . . . . . 55 7.6 Tunnel Disconnection.................................. 64
7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 55 8.0 L2TP Over Specific Media.............................. 65
7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . . 56 8.1 L2TP over UDP/IP...................................... 65
7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . . 58 8.2 IP.................................................... 66
7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 59 9.0 Security Considerations............................... 67
7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . . 59 9.1 Tunnel Endpoint Security.............................. 67
7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . . 61 9.2 Packet Level Security................................. 67
7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 62 9.3 End to End Security................................... 67
8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 62 9.4 L2TP and IPsec........................................ 68
8.1 L2TP over UDP/IP . . . . . . . . . . . . . . . . . . . . . 63 9.5 Proxy PPP Authentication.............................. 68
8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 10.0 IANA Considerations.................................. 68
9.0 Security Considerations . . . . . . . . . . . . . . . . . . 64 10.1 AVP Attributes....................................... 69
9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . . 64 10.2 Message Type AVP Values.............................. 69
9.2 Packet Level Security . . . . . . . . . . . . . . . . . . . 65 10.3 Result Code AVP Values............................... 69
9.3 End to End Security . . . . . . . . . . . . . . . . . . . . 65 10.3.1 Result Code Field Values........................ 69
9.4 L2TP and IPsec . . . . . . . . . . . . . . . . . . . . . . . 66 10.3.2 Error Code Field Values......................... 69
9.5 Proxy PPP Authentication . . . . . . . . . . . . . . . . . . 66 10.4 Framing Capabilities & Bearer Capabilities........... 69
10.0 IANA Considerations . . . . . . . . . . . . . . . . . . . 66 10.5 Proxy Authen Type AVP Values......................... 69
10.1 AVP Attribute Type Values . . . . . . . . . . . . . . . . 66 10.6 AVP Header Bits...................................... 70
10.2 Message AVP Values . . . . . . . . . . . . . . . . . . . . 67 11.0 References........................................... 70
10.3 Result Code AVP Values . . . . . . . . . . . . . . . . . . 67 12.0 Acknowledgments...................................... 71
10.4 Framing Capabilities & Bearer Capabilities . . . . . . . . 67 13.0 Author's Addresses................................... 72
10.5 Proxy Authen Type AVP Values . . . . . . . . . . . . . . . 67
10.6 AVP Header Bits . . . . . . . . . . . . . . . . . . . . . 67 Appendix A: Control Channel Slow Start and Congestion Avoidance 73
11.0 References . . . . . . . . . . . . . . . . . . . . . . . . 68
12.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 69 Appendix B: Control Message Examples......................... 73
13.0 Author's Addresses . . . . . . . . . . . . . . . . . . . . 70
Appendix A: Control Channel Slow Start and Congestion Appendix C: Intellectual Property Notice..................... 75
Avoidance . . . . . . . . . . . . . . . . . . . . . 70
Appendix B: Control Message Examples . . . . . . . . . . . . . . 71
Appendix C: Intellectual Property Notice . . . . . . . . . . . . 73
1.0 Introduction 1.0 Introduction
PPP [RFC1661] defines an encapsulation mechanism for transporting PPP [RFC1661] defines an encapsulation mechanism for transporting
multiprotocol packets across layer 2 (L2) point-to-point links. multiprotocol packets across layer 2 (L2) point-to-point links.
Typically, a user obtains a L2 connection to a Network Access Server Typically, a user obtains a L2 connection to a Network Access Server
(NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN,
ADSL, etc.) and then runs PPP over that connection. In such a ADSL, etc.) and then runs PPP over that connection. In such a
configuration, the L2 termination point and PPP session endpoint configuration, the L2 termination point and PPP session endpoint
reside on the same physical device (i.e., the NAS). reside on the same physical device (i.e., the NAS).
skipping to change at page 9, line 37 skipping to change at page 10, line 37
Data Messages may use sequence numbers to reorder packets and detect Data Messages may use sequence numbers to reorder packets and detect
lost packets. lost packets.
All values are placed into their respective fields and sent in All values are placed into their respective fields and sent in
network order (high order octets first). network order (high order octets first).
3.1 L2TP Header Format 3.1 L2TP Header Format
L2TP packets for the control channel and data channel share a common L2TP packets for the control channel and data channel share a common
header format. In each case where a field is optional, its space does header format. In each case where a field is optional, its space does
not exist in the message if the field is marked not present. This not exist in the message if the field is marked not present. Note
header is formatted: that while optional on data messages, the Length, Ns, and Nr fields
marked as optional below, are required to be present on all control
messages.
This header is formatted:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID | | Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) | | Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 23 skipping to change at page 12, line 28
field in control messages. field in control messages.
The Offset Size field, if present, specifies the number of octets The Offset Size field, if present, specifies the number of octets
past the L2TP header at which the payload data is expected to start. past the L2TP header at which the payload data is expected to start.
Actual data within the offset padding is undefined. If the offset Actual data within the offset padding is undefined. If the offset
field is present, the L2TP header ends after the last octet of the field is present, the L2TP header ends after the last octet of the
offset padding. offset padding.
3.2 Control Message Types 3.2 Control Message Types
The Message Type AVP (see section 4.3.1) defines the specific type of The Message Type AVP (see section 4.4.1) defines the specific type of
control message being sent. Recall from section 3.1 that this is only control message being sent. Recall from section 3.1 that this is only
for control messages, that is, messages with the T-bit set to 1. for control messages, that is, messages with the T-bit set to 1.
This document defines the following control message types (see This document defines the following control message types (see
Section 6.1 through 6.14 for details on the construction and use of Section 6.1 through 6.14 for details on the construction and use of
each message): each message):
Control Connection Management Control Connection Management
0 (reserved) 0 (reserved)
skipping to change at page 13, line 8 skipping to change at page 14, line 12
with a particular session, the session associated with this message with a particular session, the session associated with this message
MUST be terminated. If the M bit is set on an unrecognized AVP within MUST be terminated. If the M bit is set on an unrecognized AVP within
a message associated with the overall tunnel, the entire tunnel (and a message associated with the overall tunnel, the entire tunnel (and
all sessions within) MUST be terminated. If the M bit is not set, an all sessions within) MUST be terminated. If the M bit is not set, an
unrecognized AVP MUST be ignored. The control message must then unrecognized AVP MUST be ignored. The control message must then
continue to be processed as if the AVP had not been present. continue to be processed as if the AVP had not been present.
Hidden (H) bit: Identifies the hiding of data in the Attribute Value Hidden (H) bit: Identifies the hiding of data in the Attribute Value
field of an AVP. This capability can be used to avoid the passing of field of an AVP. This capability can be used to avoid the passing of
sensitive data, such as user passwords, as cleartext in an AVP. sensitive data, such as user passwords, as cleartext in an AVP.
Section 4.2 describes the procedure for performing AVP hiding. Section 4.3 describes the procedure for performing AVP hiding.
Length: Encodes the number of octets (including the Overall Length Length: Encodes the number of octets (including the Overall Length
and bitmask fields) contained in this AVP. The Length may be and bitmask fields) contained in this AVP. The Length may be
calculated as 6 + the length of the Attribute Value field in octets. calculated as 6 + the length of the Attribute Value field in octets.
The field itself is 10 bits, permitting a maximum of 1023 octets of The field itself is 10 bits, permitting a maximum of 1023 octets of
data in a single AVP. The minimum Length of an AVP is 6. If the data in a single AVP. The minimum Length of an AVP is 6. If the
length is 6, then the Attribute Value field is absent. length is 6, then the Attribute Value field is absent.
Vendor ID: The IANA assigned "SMI Network Management Private Vendor ID: The IANA assigned "SMI Network Management Private
Enterprise Codes" [RFC1700] value. The value 0, corresponding to Enterprise Codes" [RFC1700] value. The value 0, corresponding to
skipping to change at page 13, line 36 skipping to change at page 14, line 40
Attribute Type: A 2 octet value with a unique interpretation across Attribute Type: A 2 octet value with a unique interpretation across
all AVPs defined under a given Vendor ID. all AVPs defined under a given Vendor ID.
Attribute Value: This is the actual value as indicated by the Vendor Attribute Value: This is the actual value as indicated by the Vendor
ID and Attribute Type. It follows immediately after the Attribute ID and Attribute Type. It follows immediately after the Attribute
Type field, and runs for the remaining octets indicated in the Length Type field, and runs for the remaining octets indicated in the Length
(i.e., Length minus 6 octets of header). This field is absent if the (i.e., Length minus 6 octets of header). This field is absent if the
Length is 6. Length is 6.
4.2 Hiding of AVP Attribute Values 4.2 Mandatory AVPs
Receipt of an unknown AVP that has the M-bit set is catastrophic to
the session or tunnel it is associated with. Thus, the M bit should
only be defined for AVPs which are absolutely crucial to proper
operation of the session or tunnel. Further, in the case where the
LAC or LNS receives an unknown AVP with the M-bit set and shuts down
the session or tunnel accordingly, it is the full responsibility of
the peer sending the Mandatory AVP to accept fault for causing an
non-interoperable situation. Before defining an AVP with the M-bit
set, particularly a vendor-specific AVP, be sure that this is the
intended consequence.
When an adequate alternative exists to use of the M-bit, it should be
utilized. For example, rather than simply sending an AVP with the M-
bit set to determine if a specific extension exists, availability may
be identified by sending an AVP in a request message and expecting a
corresponding AVP in a reply message.
Use of the M-bit with new AVPs (those not defined in this document)
MUST provide the ability to configure the associated feature off,
such that the AVP is either not sent, or sent with the M-bit not set.
4.3 Hiding of AVP Attribute Values
The H bit in the header of each AVP provides a mechanism to indicate The H bit in the header of each AVP provides a mechanism to indicate
to the receiving peer whether the contents of the AVP are hidden or to the receiving peer whether the contents of the AVP are hidden or
present in cleartext. This feature can be used to hide sensitive present in cleartext. This feature can be used to hide sensitive
control message data such as user passwords or user IDs. control message data such as user passwords or user IDs.
The H bit MUST only be set if a shared secret exists between the LAC The H bit MUST only be set if a shared secret exists between the LAC
and LNS. The shared secret is the same secret that is used for tunnel and LNS. The shared secret is the same secret that is used for tunnel
authentication (see Section 5.1.1). If the H bit is set in any authentication (see Section 5.1.1). If the H bit is set in any
AVP(s) in a given control message, a Random Vector AVP must also be AVP(s) in a given control message, a Random Vector AVP must also be
skipping to change at page 15, line 24 skipping to change at page 17, line 4
along with each XOR result to generate the next hash to XOR the next along with each XOR result to generate the next hash to XOR the next
segment of the value with. segment of the value with.
The hiding method was adapted from RFC 2138 [RFC2138] which was taken The hiding method was adapted from RFC 2138 [RFC2138] which was taken
from from the "Mixing in the Plaintext" section in the book "Network from from the "Mixing in the Plaintext" section in the book "Network
Security" by Kaufman, Perlman and Speciner [KPS]. A detailed Security" by Kaufman, Perlman and Speciner [KPS]. A detailed
explanation of the method follows: explanation of the method follows:
Call the shared secret S, the Random Vector RV, and the Attribute Call the shared secret S, the Random Vector RV, and the Attribute
Value AV. Break the value field into 16-octet chunks p1, p2, etc. Value AV. Break the value field into 16-octet chunks p1, p2, etc.
with the last one padded at the end with random data to a 16-octet with the last one padded at the end with random data to a 16-octet
boundary. Call the ciphertext blocks c(1), c(2), etc. We will also boundary. Call the ciphertext blocks c(1), c(2), etc. We will also
define intermediate values b1, b2, etc. define intermediate values b1, b2, etc.
b1 = MD5(AV + S + RV) c(1) = p1 xor b1 b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2 b2 = MD5(S + c(1)) c(2) = p2 xor b2
. . . .
. . . .
. . . .
bi = MD5(S + c(i-1)) c(i) = pi xor bi bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i) where + denotes The String will contain c(1)+c(2)+...+c(i) where + denotes
concatenation. concatenation.
On receipt, the random vector is taken from the last Random Vector On receipt, the random vector is taken from the last Random Vector
AVP encountered in the message prior to the AVP to be unhidden. The AVP encountered in the message prior to the AVP to be unhidden. The
above process is then reversed to yield the original value. above process is then reversed to yield the original value.
4.3 AVP Summary 4.4 AVP Summary
The following sections contain a list of all L2TP AVPs defined in The following sections contain a list of all L2TP AVPs defined in
this document. this document.
Following the name of the AVP is a list indicating the message types Following the name of the AVP is a list indicating the message types
that utilize each AVP. After each AVP title follows a short that utilize each AVP. After each AVP title follows a short
description of the purpose of the AVP, a detail (including a graphic) description of the purpose of the AVP, a detail (including a graphic)
of the format for the Attribute Value, and any additional information of the format for the Attribute Value, and any additional information
needed for proper use of the avp. needed for proper use of the avp.
4.3.1 AVPs Applicable To All Control Messages 4.4.1 AVPs Applicable To All Control Messages
Message Type (All Messages) Message Type (All Messages)
The Message Type AVP, Attribute Type 0, identifies the control The Message Type AVP, Attribute Type 0, identifies the control
message herein and defines the context in which the exact meaning message herein and defines the context in which the exact meaning
of the following AVPs will be determined. of the following AVPs will be determined.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
skipping to change at page 17, line 18 skipping to change at page 18, line 47
More than one Random Vector AVP may appear in a message, in which More than one Random Vector AVP may appear in a message, in which
case a hidden AVP uses the Random Vector AVP most closely case a hidden AVP uses the Random Vector AVP most closely
preceeding it. This AVP MUST precede the first AVP with the H bit preceeding it. This AVP MUST precede the first AVP with the H bit
set. set.
The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be
hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the
length of the Random Octet String. length of the Random Octet String.
4.3.2 Result and Error Codes 4.4.2 Result and Error Codes
Result Code (CDN, StopCCN) Result Code (CDN, StopCCN)
The Result Code AVP, Attribute Type 1, indicates the reason for The Result Code AVP, Attribute Type 1, indicates the reason for
terminating the control channel or session. terminating the control channel or session.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 19, line 4 skipping to change at page 20, line 33
2 - Length is wrong 2 - Length is wrong
3 - One of the field values was out of range or 3 - One of the field values was out of range or
reserved field was non-zero reserved field was non-zero
4 - Insufficient resources to handle this operation now 4 - Insufficient resources to handle this operation now
5 - The Session ID is invalid in this context 5 - The Session ID is invalid in this context
6 - A generic vendor-specific error occurred in the LAC 6 - A generic vendor-specific error occurred in the LAC
7 - Try another. If LAC is aware of other possible LNS 7 - Try another. If LAC is aware of other possible LNS
destinations, it should try one of them. This can be destinations, it should try one of them. This can be
used to guide an LAC based on LNS policy, for instance, used to guide an LAC based on LNS policy, for instance,
the existence of multilink PPP bundles. the existence of multilink PPP bundles.
8 - Session or tunnel was shutdown due to receipt of an unknown
AVP with the M-bit set (see section 4.2). The Error Message
SHOULD contain the attribute of the offending AVP in (human
readable) text form.
When a General Error Code of 6 is used, additional information When a General Error Code of 6 is used, additional information
about the error SHOULD be included in the Error Message field. about the error SHOULD be included in the Error Message field.
4.3.3 Control Connection Management AVPs 4.4.3 Control Connection Management AVPs
Protocol Version (SCCRP, SCCRQ) Protocol Version (SCCRP, SCCRQ)
The Protocol Version AVP, Attribute Type 2, indicates the L2TP The Protocol Version AVP, Attribute Type 2, indicates the L2TP
protocol version of the sender. protocol version of the sender.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
skipping to change at page 24, line 8 skipping to change at page 25, line 50
| Window Size | | Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2 octet unsigned integer. The Window Size is a 2 octet unsigned integer.
If absent, the peer must assume a Window Size of 4 for its If absent, the peer must assume a Window Size of 4 for its
transmit window. The remote peer may send the specified number of transmit window. The remote peer may send the specified number of
control messages before it must wait for an acknowledgment. control messages before it must wait for an acknowledgment.
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
this AVP MUST be set to 0. The Length of this AVP is 8. this AVP MUST be set to 1. The Length of this AVP is 8.
Challenge (SCCRP, SCCRQ) Challenge (SCCRP, SCCRQ)
The Challenge AVP, Attribute Type 11, indicates that the issuing The Challenge AVP, Attribute Type 11, indicates that the issuing
peer wishes to authenticate the tunnel endpoints using a CHAP- peer wishes to authenticate the tunnel endpoints using a CHAP-
style authentication mechanism. style authentication mechanism.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets) | Challenge ... (arbitrary number of octets)
skipping to change at page 25, line 15 skipping to change at page 27, line 6
This AVP MUST be present in an SCCRP or SCCCN if a challenge was This AVP MUST be present in an SCCRP or SCCCN if a challenge was
received in the preceeding SCCRQ or SCCRP. For purposes of the ID received in the preceeding SCCRQ or SCCRP. For purposes of the ID
value in the CHAP response calculation, the value of the Message value in the CHAP response calculation, the value of the Message
Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for
an SCCCN). an SCCCN).
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 22. is 22.
4.3.4 Call Management AVPs 4.4.4 Call Management AVPs
Q.931 Cause Code (CDN) Q.931 Cause Code (CDN)
The Q.931 Cause Code AVP, Attribute Type 12, is used to give The Q.931 Cause Code AVP, Attribute Type 12, is used to give
additional information in case of unsolicited call disconnection. additional information in case of unsolicited call disconnection.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 32, line 5 skipping to change at page 33, line 44
| Physical Channel ID | | Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4 octet value intended to be used for Physical Channel ID is a 4 octet value intended to be used for
logging purposes only. logging purposes only.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 10. is 10.
Private Group ID (ICCN) Private Group ID (ICCN)
The Private Group ID AVP, Attribute Type 37, is used by the LAC to The Private Group ID AVP, Attribute Type 37, is used by the LAC to
indicate that this call is to be associated with a particular indicate that this call is to be associated with a particular
customer group. customer group.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) | | Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length. The Private Group ID is a string of octets of arbitrary length.
The LNS MAY treat the PPP session as well as network traffic through The LNS MAY treat the PPP session as well as network traffic
this session in a special manner determined by the peer. For example, through this session in a special manner determined by the peer.
if the LNS is individually connected to several private networks For example, if the LNS is individually connected to several
using unregistered addresses, this AVP may be included by the LAC to private networks using unregistered addresses, this AVP may be
indicate that a given call should be associated with one of the included by the LAC to indicate that a given call should be
private networks. associated with one of the private networks.
The Private Group ID is a string corresponding to a table in the LNS The Private Group ID is a string corresponding to a table in the
that defines the particular characteristics of the selected group. A LNS that defines the particular characteristics of the selected
LAC MAY determine the Private Group ID from a RADIUS response, local group. A LAC MAY determine the Private Group ID from a RADIUS
configuration, or some other source. response, local configuration, or some other source.
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 this AVP MUST be set to 0. The Length (before hiding) of this AVP
plus the length of the Private Group ID. is 6 plus the length of the Private Group ID.
Sequencing Required (ICCN, OCCN) Sequencing Required (ICCN, OCCN)
The Sequencing Required AVP, Attribute Type 39, indicates to the LNS The Sequencing Required AVP, Attribute Type 39, indicates to the
that Sequence Numbers MUST always be present on the data channel. LNS that Sequence Numbers MUST always be present on the data
channel.
This AVP has no Attribute Value field. This AVP has no Attribute Value field.
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
this AVP MUST be set to 1. The Length of this AVP is 6. this AVP MUST be set to 1. The Length of this AVP is 6.
4.3.5 Proxy LCP and Authentication AVPs 4.4.5 Proxy LCP and Authentication AVPs
The LAC may have answered the call and negotiated LCP with the remote The LAC may have answered the call and negotiated LCP with the
system, perhaps in order to establish the system's apparent identity. remote system, perhaps in order to establish the system's apparent
In this case, these AVPs may be included to indicate the link identity. In this case, these AVPs may be included to indicate the
properties the remote system initially requested, properties the link properties the remote system initially requested, properties
remote system and LAC ultimately negotiated, as well as PPP the remote system and LAC ultimately negotiated, as well as PPP
authentication information sent and received by the LAC. This authentication information sent and received by the LAC. This
information may be used to initiate the PPP LCP and authentication information may be used to initiate the PPP LCP and authentication
systems on the LNS, allowing PPP to continue without renegotiation of systems on the LNS, allowing PPP to continue without renegotiation
LCP. Note that the LNS policy may be to enter an additional round of of LCP. Note that the LNS policy may be to enter an additional
LCP negotiation and/or authentication if the LAC is not trusted. round of LCP negotiation and/or authentication if the LAC is not
trusted.
Initial Received LCP CONFREQ (ICCN) Initial Received LCP CONFREQ (ICCN)
In the Initial Received LCP CONFREQ AVP, Attribute Type 26, In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
provides the LNS with the Initial CONFREQ received by the LAC from provides the LNS with the Initial CONFREQ received by the LAC from
the PPP Peer. the PPP Peer.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
skipping to change at page 35, line 4 skipping to change at page 36, line 45
this AVP MUST be set to 0. The Length (before hiding) of this AVP this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 8. is 8.
Defined Authen Type values are: Defined Authen Type values are:
0 - Reserved 0 - Reserved
1 - Textual username/password exchange 1 - Textual username/password exchange
2 - PPP CHAP 2 - PPP CHAP
3 - PPP PAP 3 - PPP PAP
4 - No Authentication 4 - No Authentication
5 - Microsoft CHAP Version 1 (MSCHAPv1) 5 - Microsoft CHAP Version 1 (MSCHAPv1)
This AVP MUST be present if proxy authentication is to be This AVP MUST be present if proxy authentication is to be
utilized. If it is not present, then it is assumed that this utilized. If it is not present, then it is assumed that this
peer cannot perform proxy authentication, requiring peer cannot perform proxy authentication, requiring
a restart of the authentication phase at the LNS if the client a restart of the authentication phase at the LNS if the client
has already entered this phase with the has already entered this phase with the
LAC (which may be determined by the Proxy LCP AVP if present).. LAC (which may be determined by the Proxy LCP AVP if present).
Associated AVPs for each type of authentication follow. Associated AVPs for each type of authentication follow.
Proxy Authen Name (ICCN) Proxy Authen Name (ICCN)
The Proxy Authen Name AVP, Attribute Type 30, specifies the name The Proxy Authen Name AVP, Attribute Type 30, specifies the name
of the authenticating client when using proxy authentication. of the authenticating client when using proxy authentication.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
skipping to change at page 37, line 4 skipping to change at page 38, line 45
PPP Authentication response received by the LAC from the PPP Peer, PPP Authentication response received by the LAC from the PPP Peer,
when proxy authentication is used. when proxy authentication is used.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) | | Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a string of octets. The Response is a string of octets.
This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
Response field contains the client's response to the challenge. Response field contains the client's response to the challenge.
For Proxy authen types 2 and 5, this field contains the response For Proxy authen types 2 and 5, this field contains the response
value received by the LAC. For types 1 or 3, it contains the clear value received by the LAC. For types 1 or 3, it contains the clear
text password received from the client by the LAC. In the case of text password received from the client by the LAC. In the case of
cleartext passwords, AVP hiding is recommended. cleartext passwords, AVP hiding is recommended.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the Response. is 6 plus the length of the Response.
4.3.6 Call Status AVPs 4.4.6 Call Status AVPs
Call Errors (WEN) Call Errors (WEN)
The Call Errors AVP, Attribute Type 34, is used by the LAC to send The Call Errors AVP, Attribute Type 34, is used by the LAC to send
error information to the LNS. error information to the LNS.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 38, line 12 skipping to change at page 40, line 6
received received
Hardware Overruns - Number of receive buffer over-runs since Hardware Overruns - Number of receive buffer over-runs since
call was established call was established
Buffer Overruns - Number of buffer over-runs detected since Buffer Overruns - Number of buffer over-runs detected since
call was established call was established
Time-out Errors - Number of time-outs since call was Time-out Errors - Number of time-outs since call was
established established
Alignment Errors - Number of alignment errors since call was Alignment Errors - Number of alignment errors since call was
established established
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
AVP MUST be set to 1. The Length (before hiding) of this AVP is 32. this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 32.
ACCM (SLI) ACCM (SLI)
The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC
of the ACCM negotiated with the PPP Peer by the LNS. of the ACCM negotiated with the PPP Peer by the LNS.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 40, line 12 skipping to change at page 42, line 8
an LAC or LNS wishes to authenticate the identity of the peer it an LAC or LNS wishes to authenticate the identity of the peer it
is contacting or being contacted by, a Challenge AVP is included is contacting or being contacted by, a Challenge AVP is included
in the SCCRQ or SCCRP message. If a Challenge AVP is received in in the SCCRQ or SCCRP message. If a Challenge AVP is received in
an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the
following SCCRP or SCCCN, respectively. If the expected response following SCCRP or SCCCN, respectively. If the expected response
and response received from a peer does not match, establishment of and response received from a peer does not match, establishment of
the tunnel MUST be disallowed. the tunnel MUST be disallowed.
To participate in tunnel authentication, a single shared secret To participate in tunnel authentication, a single shared secret
MUST exist between the LAC and LNS. This is the same shared secret MUST exist between the LAC and LNS. This is the same shared secret
used for AVP hiding (see Section 4.2). See Section 4.3.3 for used for AVP hiding (see Section 4.3). See Section 4.4.3 for
details on construction of the Challenge and Response AVPs. details on construction of the Challenge and Response AVPs.
5.2 Session Establishment 5.2 Session Establishment
After successful control connection establishment, individual After successful control connection establishment, individual
sessions may be created. Each session corresponds to single PPP sessions may be created. Each session corresponds to single PPP
stream between the LAC and LNS. Unlike control connection stream between the LAC and LNS. Unlike control connection
establishment, session establishment is directional with respect to establishment, session establishment is directional with respect to
the LAC and LNS. The LAC requests the LNS to accept a session for an the LAC and LNS. The LAC requests the LNS to accept a session for an
incoming call, and the LNS requests the LAC to accept a session for incoming call, and the LNS requests the LAC to accept a session for
skipping to change at page 42, line 13 skipping to change at page 44, line 13
optional data message sequencing. Each peer maintains separate optional data message sequencing. Each peer maintains separate
sequence numbers for the control connection and each individual data sequence numbers for the control connection and each individual data
session within a tunnel. session within a tunnel.
Unlike the L2TP control channel, the L2TP data channel does not use Unlike the L2TP control channel, the L2TP data channel does not use
sequence numbers to retransmit lost data messages. Rather, data sequence numbers to retransmit lost data messages. Rather, data
messages may use sequence numbers to detect lost packets and/or messages may use sequence numbers to detect lost packets and/or
restore the original sequence of packets that may have been reordered restore the original sequence of packets that may have been reordered
during transport. The LAC may request that sequence numbers be during transport. The LAC may request that sequence numbers be
present in data messages via the Sequencing Required AVP (see Section present in data messages via the Sequencing Required AVP (see Section
4.3.6). If this AVP is present during session setup, sequence numbers 4.4.6). If this AVP is present during session setup, sequence numbers
MUST be present at all times. If this AVP is not present, sequencing MUST be present at all times. If this AVP is not present, sequencing
presence is under control of the LNS. The LNS controls enabling and presence is under control of the LNS. The LNS controls enabling and
disabling of sequence numbers by sending a data message with or disabling of sequence numbers by sending a data message with or
without sequence numbers present at any time during the life of a without sequence numbers present at any time during the life of a
session. Thus, if the LAC receives a data message without sequence session. Thus, if the LAC receives a data message without sequence
numbers present, it MUST stop sending sequence numbers in future data numbers present, it MUST stop sending sequence numbers in future data
messages. If the LAC receives a data message with sequence numbers messages. If the LAC receives a data message with sequence numbers
present, it MUST begin sending sequence numbers in future outgoing present, it MUST begin sending sequence numbers in future outgoing
data messages. If the LNS enables sequencing after disabling it data messages. If the LNS enables sequencing after disabling it
earlier in the session, the sequence number state picks up where it earlier in the session, the sequence number state picks up where it
skipping to change at page 44, line 17 skipping to change at page 46, line 17
The message sequence number, Ns, begins at 0. Each subsequent message The message sequence number, Ns, begins at 0. Each subsequent message
is sent with the next increment of the sequence number. The sequence is sent with the next increment of the sequence number. The sequence
number is thus a free running counter represented modulo 65536. The number is thus a free running counter represented modulo 65536. The
sequence number in the header of a received message is considered sequence number in the header of a received message is considered
less than or equal to the last received number if its value lies in less than or equal to the last received number if its value lies in
the range of the last received number and the preceding 32767 values, the range of the last received number and the preceding 32767 values,
inclusive. For example, if the last received sequence number was 15, inclusive. For example, if the last received sequence number was 15,
then messages with sequence numbers 0 through 15, as well as 32784 then messages with sequence numbers 0 through 15, as well as 32784
through 65535, would be considered less than or equal. Such a message through 65535, would be considered less than or equal. Such a message
would be considered a duplicate of a message already received and would be considered a duplicate of a message already received and
dropped silently. ignored from processing. However, in order to ensure that all
messages are ackowledged properly (particularly in the case of a lost
ZLB ACK message), receipt of duplicate messages MUST be acknowledged
by the reliable transport. This acknowledgement may either
piggybacked on a message in queue, or explicitly via a ZLB ACK.
All control messages take up one slot in the control message sequence All control messages take up one slot in the control message sequence
number space, except the ZLB acknowledgement. Thus, Ns is not number space, except the ZLB acknowledgement. Thus, Ns is not
incremented after a ZLB message is sent. incremented after a ZLB message is sent.
The last received message number, Nr, is used to acknowledge messages The last received message number, Nr, is used to acknowledge messages
received by an L2TP peer. It contains the sequence number of the received by an L2TP peer. It contains the sequence number of the
message the peer expects to receive next (e.g. the last Ns of a non- message the peer expects to receive next (e.g. the last Ns of a non-
ZLB message received plus 1, modulo 65536). While the Nr in a ZLB message received plus 1, modulo 65536). While the Nr in a
received ZLB is used to flush messages from the local retransmit received ZLB is used to flush messages from the local retransmit
skipping to change at page 52, line 39 skipping to change at page 54, line 47
This section describes the operation of various L2TP control This section describes the operation of various L2TP control
connection functions and the Control Connection messages which are connection functions and the Control Connection messages which are
used to support them. used to support them.
Receipt of an invalid or unrecoverably malformed control message Receipt of an invalid or unrecoverably malformed control message
should be logged appropriately and the control connection cleared to should be logged appropriately and the control connection cleared to
ensure recovery to a known state. The control connection may then be ensure recovery to a known state. The control connection may then be
restarted by the initator. restarted by the initator.
An invalid control message is defined as a message which contains a An invalid control message is defined as a message which contains a
Message Type that is marked mandatory (see Section 4.3.1) and is Message Type that is marked mandatory (see Section 4.4.1) and is
unknown to the implementation, or a control message that is received unknown to the implementation, or a control message that is received
in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ).
Examples of a malformed control message include one that has an Examples of a malformed control message include one that has an
invalid value in its header, contains an AVP that is formatted invalid value in its header, contains an AVP that is formatted
incorrectly or whose value is out of range, or a message that is incorrectly or whose value is out of range, or a message that is
missing a required AVP. A control message with a malformed header missing a required AVP. A control message with a malformed header
should be discarded. A control message with an invalid AVP should should be discarded. A control message with an invalid AVP should
look to the M-bit for that AVP to determine whether the error is look to the M-bit for that AVP to determine whether the error is
recoverable or not. recoverable or not.
skipping to change at page 53, line 38 skipping to change at page 55, line 47
Appendix B.1 contains an example of lock-step tunnel establishment. Appendix B.1 contains an example of lock-step tunnel establishment.
7.2 Control Connection States 7.2 Control Connection States
The L2TP control connection protocol is not distinguishable between The L2TP control connection protocol is not distinguishable between
the LNS and LAC, but is distinguishable between the originator and the LNS and LAC, but is distinguishable between the originator and
receiver. The originating peer is the one which first initiates receiver. The originating peer is the one which first initiates
establishment of the tunnel (in a tie breaker situation, this is the establishment of the tunnel (in a tie breaker situation, this is the
winner of the tie). Since either LAC or LNS can be the originator, a winner of the tie). Since either LAC or LNS can be the originator, a
collision can occur. See the Tie Breaker AVP in Section 4.3.3 for a collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a
description of this and its resolution. description of this and its resolution.
7.2.1 Control Connection Establishment 7.2.1 Control Connection Establishment
State Event Action New State State Event Action New State
----- ----- ------ --------- ----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply idle Local Send SCCRQ wait-ctl-reply
Open request Open request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable acceptable
idle Receive SCCRQ, Send StopCCN, idle idle Receive SCCRQ, Send StopCCN, idle
not acceptable Clean up not acceptable Clean up
skipping to change at page 65, line 19 skipping to change at page 67, line 31
an authenticated tunnel establishment has been completed an authenticated tunnel establishment has been completed
successfully. successfully.
For authentication to occur, the LAC and LNS MUST share a single For authentication to occur, the LAC and LNS MUST share a single
secret. Each side uses this same secret when acting as authenticatee secret. Each side uses this same secret when acting as authenticatee
as well as authenticator. Since a single secret is used, the tunnel as well as authenticator. Since a single secret is used, the tunnel
authentication AVPs include differentiating values in the CHAP ID authentication AVPs include differentiating values in the CHAP ID
fields for each message digest calculation to guard against replay fields for each message digest calculation to guard against replay
attacks. attacks.
The Assigned Tunnel ID and Assigned Session ID (See Section 4.3.3) The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3)
SHOULD be selected in an unpredictable manner rather than SHOULD be selected in an unpredictable manner rather than
sequentially or otherwise. Doing so will help deter hijacking of a sequentially or otherwise. Doing so will help deter hijacking of a
session by a malicious user who does not have access to packet traces session by a malicious user who does not have access to packet traces
between the LAC and LNS. between the LAC and LNS.
9.2 Packet Level Security 9.2 Packet Level Security
Securing L2TP requires that the underlying transport make available Securing L2TP requires that the underlying transport make available
encryption, integrity and authentication services for all L2TP encryption, integrity and authentication services for all L2TP
traffic. This secure transport operates on the entire L2TP packet traffic. This secure transport operates on the entire L2TP packet
skipping to change at page 66, line 26 skipping to change at page 68, line 38
upon the authenticated PPP user, or at the network layer itself by upon the authenticated PPP user, or at the network layer itself by
using IPsec transport mode end-to-end between the communicating using IPsec transport mode end-to-end between the communicating
hosts. The requirements for access control mechanisms are not a part hosts. The requirements for access control mechanisms are not a part
of the L2TP specification and as such are outside the scope of this of the L2TP specification and as such are outside the scope of this
document. document.
9.5 Proxy PPP Authentication 9.5 Proxy PPP Authentication
L2TP defines AVPs that MAY be exchanged during session establishment L2TP defines AVPs that MAY be exchanged during session establishment
to provide forwarding of PPP authentication information obtained at to provide forwarding of PPP authentication information obtained at
the LAC to the LNS for validation (see Section 4.3.5). This implies a the LAC to the LNS for validation (see Section 4.4.5). This implies a
direct trust relationship of the LAC on behalf of the LNS. If the direct trust relationship of the LAC on behalf of the LNS. If the
LNS chooses to implement proxy authentication, it MUST be able to be LNS chooses to implement proxy authentication, it MUST be able to be
configured off, requiring a new round a PPP authentication initiated configured off, requiring a new round a PPP authentication initiated
by the LNS (which may or may not include a new round of LCP by the LNS (which may or may not include a new round of LCP
negotiation). negotiation).
10.0 IANA Considerations 10.0 IANA Considerations
This document defines a number of "magic" numbers to be maintained by This document defines a number of "magic" numbers to be maintained by
the IANA. This section explains the criteria to be used by the IANA the IANA. This section explains the criteria to be used by the IANA
to assign additional numbers in each of these lists. The following to assign additional numbers in each of these lists. The following
subsections describe the assignment policy for the namespaces defined subsections describe the assignment policy for the namespaces defined
elsewhere in this document. elsewhere in this document.
10.1 AVP Attributes 10.1 AVP Attributes
As defined in Section 4.1, AVPs contain vendor ID, Attribute and As defined in Section 4.1, AVPs contain vendor ID, Attribute and
Value fields. For vendor ID value of 0, IANA will maintain a registry Value fields. For vendor ID value of 0, IANA will maintain a registry
of assigned Attributes and in some case also values. Attributes 0-39 of assigned Attributes and in some case also values. Attributes 0-39
are assigned as defined in Section 4.3. The remaining values are are assigned as defined in Section 4.4. The remaining values are
available for assignment through IETF Consensus [RFC 2434]. available for assignment through IETF Consensus [RFC 2434].
10.2 Message Type AVP Values 10.2 Message Type AVP Values
As defined in Section 4.3.1, Message Type AVPs (Attribute Type 0) As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0)
have an associated value maintained by IANA. Values 0-16 are defined have an associated value maintained by IANA. Values 0-16 are defined
in Section 3.2, the remaining values are available for assignment via in Section 3.2, the remaining values are available for assignment via
IETF Consensus [RFC 2434] IETF Consensus [RFC 2434]
10.3 Result Code AVP Values 10.3 Result Code AVP Values
As defined in Section 4.3.2, Result Code AVPs (Attribute Type 1) As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1)
contain three fields. Two of these fields (the Result Code and Error contain three fields. Two of these fields (the Result Code and Error
Code fields) have associated values maintained by IANA. Code fields) have associated values maintained by IANA.
10.3.1 Result Code Field Values 10.3.1 Result Code Field Values
The Result Code AVP may be included in CDN and StopCCN messages. The The Result Code AVP may be included in CDN and StopCCN messages. The
allowable values for the Result Code field of the AVP differ allowable values for the Result Code field of the AVP differ
depending upon the value of the Message Type AVP. For the StopCCN depending upon the value of the Message Type AVP. For the StopCCN
message, values 0-7 are defined in Section 4.3.2; for the StopCCN message, values 0-7 are defined in Section 4.4.2; for the StopCCN
message, values 0-11 are defined in the same section. The remaining message, values 0-11 are defined in the same section. The remaining
values of the Result Code field for both messages are available for values of the Result Code field for both messages are available for
assignment via IETF Consensus [RFC 2434]. assignment via IETF Consensus [RFC 2434].
10.3.1 Error Code Field Values 10.3.2 Error Code Field Values
Values 0-7 are defined in Section 4.3.2. Values 8-32767 are Values 0-7 are defined in Section 4.4.2. Values 8-32767 are
available for assignment via IETF Consensus [RFC 2434]. The remaining available for assignment via IETF Consensus [RFC 2434]. The remaining
values of the Error Code field are available for assignment via First values of the Error Code field are available for assignment via First
Come First Served [RFC 2434]. Come First Served [RFC 2434].
10.4 Framing Capabilities & Bearer Capabilities 10.4 Framing Capabilities & Bearer Capabilities
The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in
Section 4.3.3) both contain 32-bit bitmasks. Additional bits should Section 4.4.3) both contain 32-bit bitmasks. Additional bits should
only be defined via a Standards Action [RFC 2434]. only be defined via a Standards Action [RFC 2434].
10.5 Proxy Authen Type AVP Values 10.5 Proxy Authen Type AVP Values
The Proxy Authen Type AVP (Attribute Type 29) has an associated value The Proxy Authen Type AVP (Attribute Type 29) has an associated value
maintained by IANA. Values 0-5 are defined in Section 4.3.5, the maintained by IANA. Values 0-5 are defined in Section 4.4.5, the
remaining values are available for assignment via First Come First remaining values are available for assignment via First Come First
Served [RFC 2434]. Served [RFC 2434].
10.6 AVP Header Bits 10.6 AVP Header Bits
There are four remaining reserved bits in the AVP header. Additional There are four remaining reserved bits in the AVP header. Additional
bits should only be assigned via a Standards Action [RFC 2434]. bits should only be assigned via a Standards Action [RFC 2434].
11.0 References 11.0 References
skipping to change at page 71, line 43 skipping to change at page 74, line 4
it increases by 1/CWND for every new ACK received. That is, CWND is it increases by 1/CWND for every new ACK received. That is, CWND is
increased by one packet after CWND new ACKs have been received. Win- increased by one packet after CWND new ACKs have been received. Win-
dow expansion during the congestion avoidance phase is effectively dow expansion during the congestion avoidance phase is effectively
linear, with CWND increasing by one packet each round trip. linear, with CWND increasing by one packet each round trip.
When congestion occurs (indicated by the triggering of a retransmis- When congestion occurs (indicated by the triggering of a retransmis-
sion) one half of the CWND is saved in SSTHRESH, and CWND is set to sion) one half of the CWND is saved in SSTHRESH, and CWND is set to
one. The sender then reenters the slow start phase. one. The sender then reenters the slow start phase.
Appendix B: Control Message Examples Appendix B: Control Message Examples
B.1: Lock-step tunnel establishment B.1: Lock-step tunnel establishment
In this example, an LAC establishes a tunnel, with the exchange In this example, an LAC establishes a tunnel, with the exchange
involving each side alternating in sending messages. This example involving each side alternating in sending messages. This example
is contrived, in that the final acknowledgment in the example is shows the final acknowledgment explicitly sent within a ZLB ACK
explicitly sent within a zero-length message, although most typi- message. An alternative would be to piggyback the acknowledgement
cally the acknowledgment would have been included in the process- within a message sent as a reply to the ICRQ or OCRQ that will
ing of the Incoming-Call-Request which had prompted the LAC to likely follow from the side that initiated the tunnel.
initiate the tunnel in the first place.
LAC or LNS LNS or LAC LAC or LNS LNS or LAC
---------- ---------- ---------- ----------
SCCRQ -> SCCRQ ->
Nr: 0, Ns: 0 Nr: 0, Ns: 0
<- SCCRP <- SCCRP
Nr: 1, Ns: 0 Nr: 1, Ns: 0
SCCCN -> SCCCN ->
Nr: 1, Ns: 1 Nr: 1, Ns: 1
 End of changes. 56 change blocks. 
162 lines changed or deleted 197 lines changed or added

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