SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or
(3) the requested language is not supported by the peer LCCE, the
default language [RFC2277] MUST be used for all internationalized
strings sent by the peer.
10. IANA Considerations
This document defines a number of "magic" numbers to be maintained by
the IANA. This section explains the criteria used by the IANA to
assign additional numbers in each of these lists. The following
subsections describe the assignment policy for the namespaces defined
elsewhere in this document.
Sections 10.1 through 10.3 are requests for new values already
managed by IANA according to [RFC3438].
The remaining sections are for new registries that have been added to
the existing L2TP registry and are maintained by IANA accordingly.
10.1. Control Message Attribute Value Pairs (AVPs)
This number space is managed by IANA as per [RFC3438].
A summary of the new AVPs follows:
Control Message Attribute Value Pairs
Attribute
Type Description
--------- ------------------
58 Extended Vendor ID AVP
59 Message Digest
60 Router ID
61 Assigned Control Connection ID
62 Pseudowire Capabilities List
63 Local Session ID
64 Remote Session ID
65 Assigned Cookie
66 Remote End ID
68 Pseudowire Type
69 L2-Specific Sublayer
70 Data Sequencing
71 Circuit Status
72 Preferred Language
73 Control Message Authentication Nonce
74 Tx Connect Speed
75 Rx Connect Speed
10.2. Message Type AVP Values
This number space is managed by IANA as per [RFC3438]. There is one
new message type, defined in Section 3.1, that was allocated for this
specification:
Message Type AVP (Attribute Type 0) Values
------------------------------------------
Control Connection Management
20 (ACK) Explicit Acknowledgement
10.3. Result Code AVP Values
This number space is managed by IANA as per [RFC3438].
New Result Code values for the CDN message are defined in Section
5.4. The following is a summary:
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
General Error Codes
13 - Session not established due to losing
tie breaker (L2TPv3).
14 - Session not established due to unsupported
PW type (L2TPv3).
15 - Session not established, sequencing required
without valid L2-Specific Sublayer (L2TPv3).
16 - Finite state machine error or timeout.
10.4. AVP Header Bits
This is a new registry for IANA to maintain.
Leading Bits of the L2TP AVP Header
-----------------------------------
There six bits at the beginning of the L2TP AVP header. New bits are
assigned via Standards Action [RFC2434].
Bit 0 - Mandatory (M bit)
Bit 1 - Hidden (H bit)
Bit 2 - Reserved
Bit 3 - Reserved
Bit 4 - Reserved
Bit 5 - Reserved
10.5. L2TP Control Message Header Bits
This is a new registry for IANA to maintain.
Leading Bits of the L2TP Control Message Header
-----------------------------------------------
There are 12 bits at the beginning of the L2TP Control Message
Header. Reserved bits should only be defined by Standard
Action [RFC2434].
Bit 0 - Message Type (T bit)
Bit 1 - Length Field is Present (L bit)
Bit 2 - Reserved
Bit 3 - Reserved
Bit 4 - Sequence Numbers Present (S bit)
Bit 5 - Reserved
Bit 6 - Offset Field is Present [RFC2661]
Bit 7 - Priority Bit (P bit) [RFC2661]
Bit 8 - Reserved
Bit 9 - Reserved
Bit 10 - Reserved
Bit 11 - Reserved
10.6. Pseudowire Types
This is a new registry for IANA to maintain, there are no values
assigned within this document to maintain.
L2TPv3 Pseudowire Types
-----------------------
The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value
used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP
defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review
[RFC2434], while 32768 to 65535 are assigned by a First Come First
Served policy [RFC2434]. There are no specific pseudowire types
assigned within this document. Each pseudowire-specific document
must allocate its own PW types from IANA as necessary.
10.7. Circuit Status Bits
This is a new registry for IANA to maintain.
Circuit Status Bits
-------------------
The Circuit Status field is a 16-bit mask, with the two low order
bits assigned. Additional bits may be assigned by IETF Consensus
[RFC2434].
Bit 14 - New (N bit)
Bit 15 - Active (A bit)
10.8. Default L2-Specific Sublayer bits
This is a new registry for IANA to maintain.
Default L2-Specific Sublayer Bits
---------------------------------
The Default L2-Specific Sublayer contains 8 bits in the low-order
portion of the header. Reserved bits may be assigned by IETF
Consensus [RFC2434].
Bit 0 - Reserved
Bit 1 - Sequence (S bit)
Bit 2 - Reserved
Bit 3 - Reserved
Bit 4 - Reserved
Bit 5 - Reserved
Bit 6 - Reserved
Bit 7 - Reserved
10.9. L2-Specific Sublayer Type
This is a new registry for IANA to maintain.
L2-Specific Sublayer Type
-------------------------
The L2-Specific Sublayer Type is a 2-octet unsigned integer.
Additional values may be assigned by Expert Review [RFC2434].
0 - No L2-Specific Sublayer
1 - Default L2-Specific Sublayer present
10.10. Data Sequencing Level
This is a new registry for IANA to maintain.
Data Sequencing Level
---------------------
The Data Sequencing Level is a 2-octet unsigned integer
Additional values may be assigned by Expert Review [RFC2434].
0 - No incoming data packets require sequencing.
1 - Only non-IP data packets require sequencing.
2 - All incoming data packets require sequencing.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
and Palter, B., "Layer Two Tunneling Layer Two Tunneling
Protocol (L2TP)", RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S.,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
Assigned Numbers Authority (IANA) Considerations Update",
BCP 68, RFC 3438, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
11.2. Informative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
January 1997.
[RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer
Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999.
[RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for
Literal IPv6 Addresses in URL’s", RFC 2732, December 1999.
[RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory
Tunneling via RADIUS", RFC 2809, April 2000.
[RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two
Tunneling Protocol (L2TP) over Frame Relay", RFC 3070,
February 2001.
[RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two
Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5
(AAL5)", RFC 3355, August 2002.
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The
Protocols", Addison-Wesley Publishing Company, Inc., March
1996, ISBN 0-201-63346-9.
12. Acknowledgments
Many of the protocol constructs were originally defined in, and the
text of this document began with, RFC 2661, "L2TPv2". RFC 2661
authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and
B. Palter.
The basic concept for L2TP and many of its protocol constructs were
adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these
versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G.
Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn.
Danny Mcpherson and Suhail Nanji published the first "L2TP Service
Type" version, which defined the use of L2TP for tunneling of various
L2 payload types (initially, Ethernet and Frame Relay).
The team for splitting RFC 2661 into this base document and the
companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill
Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided
very helpful review and comment.
Some constructs of L2TPv3 were based in part on UTI (Universal
Transport Interface), which was originally conceived by Peter
Lothberg and Tony Bates.
Stewart Bryant and Simon Barber provided valuable input for the
L2TPv3 over IP header.
Juha Heinanen provided helpful review in the early stages of this
effort.
Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth
and Maria Dos Santos contributed to the Control Message
Authentication Mechanism as well as general discussions of security.
James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted
Hardie, and Pekka Savola provided very helpful review of the final
versions of text.
Russ Housley provided valuable review and comment on security,
particularly with respect to the Control Message Authentication
mechanism.
Pekka Savola contributed to proper alignment with IPv6 and inspired
much of Section 4.1.4 on fragmentation.
Aside of his original influence and co-authorship of RFC 2661, Glen
Zorn helped get all of the language and character references straight
in this document.
A number of people provided valuable input and effort for RFC 2661,
on which this document was based:
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
review at the 43rd IETF in Orlando, FL, which led to improvement of
the overall readability and clarity of RFC 2661.
Thomas Narten provided a great deal of critical review and
formatting. He wrote the first version of the IANA Considerations
section.
Dory Leifer made valuable refinements to the protocol definition of
L2TP and contributed to the editing of early versions leading to RFC
2661.
Steve Cobb and Evan Caves redesigned the state machine tables.
Barney Wolff provided a great deal of design input on the original
endpoint authentication mechanism.
Appendix A: Control Slow Start and Congestion Avoidance
Although each side has indicated the maximum size of its receive
window, it is recommended that a slow start and congestion avoidance
method be used to transmit control packets. The methods described
here are based upon the TCP congestion avoidance algorithm as
described in Section 21.6 of TCP/IP Illustrated, Volume I, by W.
Richard Stevens [STEVENS] (this algorithm is also described in
[RFC2581]).
Slow start and congestion avoidance make use of several variables.
The congestion window (CWND) defines the number of packets a sender
may send before waiting for an acknowledgment. The size of CWND
expands and contracts as described below. Note, however, that CWND
is never allowed to exceed the size of the advertised window obtained
from the Receive Window AVP. (In the text below, it is assumed any
increase will be limited by the Receive Window Size.) The variable
SSTHRESH determines when the sender switches from slow start to
congestion avoidance. Slow start is used while CWND is less than
SSHTRESH.
A sender starts out in the slow start phase. CWND is initialized to
one packet, and SSHTRESH is initialized to the advertised window
(obtained from the Receive Window AVP). The sender then transmits
one packet and waits for its acknowledgment (either explicit or
piggybacked). When the acknowledgment is received, the congestion
window is incremented from one to two. During slow start, CWND is
increased by one packet each time an ACK (explicit ACK message or
piggybacked) is received. Increasing CWND by one on each ACK has the
effect of doubling CWND with each round trip, resulting in an
exponential increase. When the value of CWND reaches SSHTRESH, the
slow start phase ends and the congestion avoidance phase begins.
During congestion avoidance, CWND expands more slowly. Specifically,
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.
Window expansion during the congestion avoidance phase is effectively
linear, with CWND increasing by one packet each round trip.
When congestion occurs (indicated by the triggering of a
retransmission) one-half of the CWND is saved in SSTHRESH, and CWND
is set to one. The sender then reenters the slow start phase.
Appendix B: Control Message Examples
B.1: Lock-Step Control Connection Establishment
In this example, an LCCE establishes a control connection, with the
exchange involving each side alternating in sending messages. This
example shows the final acknowledgment explicitly sent within an ACK
message. An alternative would be to piggyback the acknowledgment
within a message sent as a reply to the ICRQ or OCRQ that will likely
follow from the side that initiated the control connection.
LCCE A LCCE B
------ ------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ACK
Nr: 2, Ns: 1
B.2: Lost Packet with Retransmission
An existing control connection has a new session requested by LCCE A.
The ICRP is lost and must be retransmitted by LCCE B. Note that loss
of the ICRP has two effects: It not only keeps the upper level state
machine from progressing, but also keeps LCCE A from seeing a timely
lower level acknowledgment of its ICRQ.
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LCCE A’s timer started first, so fires first)
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet,
LCCE B discards the packet and sends an ACK message)
<- ACK
Nr: 3, Ns: 2
(LCCE B’s retransmit timer fires)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ACK
Nr: 4, Ns: 2
Appendix C: Processing Sequence Numbers
The Default L2-Specific Sublayer, defined in Section 4.6, provides a
24-bit field for sequencing of data packets within an L2TP session.
L2TP data packets are never retransmitted, so this sequence is used
only to detect packet order, duplicate packets, or lost packets.
The 24-bit Sequence Number field of the Default L2-Specific Sublayer
contains a packet sequence number for the associated session. Each
sequenced data packet that is sent must contain the sequence number,
incremented by one, of the previous sequenced packet sent on a given
L2TP session. Upon receipt, any packet with a sequence number equal
to or greater than the current expected packet (the last received
in-order packet plus one) should be considered "new" and accepted.
All other packets are considered "old" or "duplicate" and discarded.
Note that the 24-bit sequence number space includes zero as a valid
sequence number (as such, it may be implemented with a masked 32-bit
counter if desired). All new sessions MUST begin sending sequence
numbers at zero.
Larger or smaller sequence number fields are possible with L2TP if an
alternative format to the Default L2-Specific Sublayer defined in
this document is used. While 24 bits may be adequate in a number of
circumstances, a larger sequence number space will be less
susceptible to sequence number wrapping problems for very high
session data rates across long dropout periods. The sequence number
processing recommendations below should hold for any size sequence
number field.
When detecting whether a packet sequence number is "greater" or
"less" than a given sequence number value, wrapping of the sequence
number must be considered. This is typically accomplished by keeping
a window of sequence numbers beyond the current expected sequence
number for determination of whether a packet is "new" or not. The
window may be sized based on the link speed and sequence number space
and SHOULD be configurable with a default equal to one half the size
of the available number space (e.g., 2^(n-1), where n is the number
of bits available in the sequence number).
Upon receipt, packets that exactly match the expected sequence number
are processed immediately and the next expected sequence number
incremented. Packets that fall within the window for new packets may
either be processed immediately and the next expected sequence number
updated to one plus that received in the new packet, or held for a
very short period of time in hopes of receiving the missing
packet(s). This "very short period" should be configurable, with a
default corresponding to a time lapse that is at least an order of
magnitude less than the retransmission timeout periods of higher
layer protocols such as TCP.
For typical transient packet mis-orderings, dropping out-of-order
packets alone should suffice and generally requires far less
resources than actively reordering packets within L2TP. An exception
is a case in which a pair of packet fragments are persistently
retransmitted and sent out-of-order. For example, if an IP packet
has been fragmented into a very small packet followed by a very large
packet before being tunneled by L2TP, it is possible (though
admittedly wrong) that the two resulting L2TP packets may be
consistently mis-ordered by the PSN in transit between L2TP nodes.
If sequence numbers were being enforced at the receiving node without
any buffering of out-of-order packets, then the fragmented IP packet
may never reach its destination. It may be worth noting here that
this condition is true for any tunneling mechanism of IP packets that
includes sequence number checking on receipt (i.e., GRE [RFC2890]).
Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only
non-IP data packets require sequencing) allows IP data packets being
tunneled by L2TP to not utilize sequence numbers, while utilizing
sequence numbers and enforcing packet order for any remaining non-IP
data packets. Depending on the requirements of the link layer being
tunneled and the network data traversing the data link, this is
sufficient in many cases to enforce packet order on frames that
require it (such as end-to-end data link control messages), while not
on IP packets that are known to be resilient to packet reordering.
If a large number of packets (i.e., more than one new packet window)
are dropped due to an extended outage or loss of sequence number