Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3931


Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Part 5 of 5, p. 78 to 94
Prev RFC Part


prevText      Top      Up      ToC       Page 78 
8.  Security Considerations

   This section addresses some of the security issues that L2TP
   encounters in its operation.

8.1.  Control Connection Endpoint and Message Security

   If a shared secret (password) exists between two LCCEs, it may be
   used to perform a mutual authentication between the two LCCEs, and
   construct an authentication and integrity check of arriving L2TP
   control messages.  The mechanism provided by L2TPv3 is described in
   Section 4.3 and in the definition of the Message Digest and Control
   Message Authentication Nonce AVPs in Section 5.4.1.

   This control message security mechanism provides for (1) mutual
   endpoint authentication, and (2) individual control message integrity
   and authenticity checking.  Mutual endpoint authentication ensures
   that an L2TPv3 control connection is only established between two
   endpoints that are configured with the proper password.  The
   individual control message and integrity check guards against
   accidental or intentional packet corruption (i.e., those caused by a
   control message spoofing or man-in-the-middle attack).

   The shared secret that is used for all control connection, control
   message, and AVP security features defined in this document never
   needs to be sent in the clear between L2TP tunnel endpoints.

8.2.  Data Packet Spoofing

   Packet spoofing for any type of Virtual Private Network (VPN)
   protocol is of particular concern as insertion of carefully
   constructed rogue packets into the VPN transit network could result
   in a violation of VPN traffic separation, leaking data into a
   customer VPN.  This is complicated by the fact that it may be
   particularly difficult for the operator of the VPN to even be aware
   that it has become a point of transit into or between customer VPNs.

   L2TPv3 provides traffic separation for its VPNs via a 32-bit Session
   ID in the L2TPv3 data header.  When present, the L2TPv3 Cookie
   (described in Section 4.1), provides an additional check to ensure
   that an arriving packet is intended for the identified session.
   Thus, use of a Cookie with the Session ID provides an extra guarantee
   that the Session ID lookup was performed properly and that the
   Session ID itself was not corrupted in transit.

Top      Up      ToC       Page 79 
   In the presence of a blind packet spoofing attack, the Cookie may
   also provide security against inadvertent leaking of frames into a
   customer VPN.  To illustrate the type of security that it is provided
   in this case, consider comparing the validation of a 64-bit Cookie in
   the L2TPv3 header to the admission of packets that match a given
   source and destination IP address pair.  Both the source and
   destination IP address pair validation and Cookie validation consist
   of a fast check on cleartext header information on all arriving
   packets.  However, since L2TPv3 uses its own value, it removes the
   requirement for one to maintain a list of (potentially several)
   permitted or denied IP addresses, and moreover, to guard knowledge of
   the permitted IP addresses from hackers who may obtain and spoof
   them.  Further, it is far easier to change a compromised L2TPv3
   Cookie than a compromised IP address," and a cryptographically random
   [RFC1750] value is far less likely to be discovered by brute-force
   attacks compared to an IP address.

   For protection against brute-force, blind, insertion attacks, a 64-
   bit Cookie MUST be used with all sessions.  A 32-bit Cookie is
   vulnerable to brute-force guessing at high packet rates, and as such,
   should not be considered an effective barrier to blind insertion
   attacks (though it is still useful as an additional verification of a
   successful Session ID lookup).  The Cookie provides no protection
   against a sophisticated man-in-the-middle attacker who can sniff and
   correlate captured data between nodes for use in a coordinated

   The Assigned Cookie AVP is used to signal the value and size of the
   Cookie that must be present in all data packets for a given session.
   Each Assigned Cookie MUST be selected in a cryptographically random
   manner [RFC1750] such that a series of Assigned Cookies does not
   provide any indication of what a future Cookie will be.

   The L2TPv3 Cookie must not be regarded as a substitute for security
   such as that provided by IPsec when operating over an open or
   untrusted network where packets may be sniffed, decoded, and
   correlated for use in a coordinated attack.  See Section 4.1.3 for
   more information on running L2TP over IPsec.

9.  Internationalization Considerations

   The Host Name and Vendor Name AVPs are not internationalized.  The
   Vendor Name AVP, although intended to be human-readable, would seem
   to fit in the category of "globally visible names" [RFC2277] and so
   is represented in US-ASCII.

   If (1) an LCCE does not signify a language preference by the
   inclusion of a Preferred Language AVP (see Section 5.4.3) in the

Top      Up      ToC       Page 80 
   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

      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

Top      Up      ToC       Page 81 
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

   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.

Top      Up      ToC       Page 82 
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

Top      Up      ToC       Page 83 
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

   Bit 14 - New (N bit)
   Bit 15 - Active (A bit)

Top      Up      ToC       Page 84 
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.

Top      Up      ToC       Page 85 
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.

Top      Up      ToC       Page 86 
   [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

   [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.

Top      Up      ToC       Page 87 
   [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

   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.

Top      Up      ToC       Page 88 
   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

   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

   Dory Leifer made valuable refinements to the protocol definition of
   L2TP and contributed to the editing of early versions leading to RFC

   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.

Top      Up      ToC       Page 89 
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

   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

   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.

Top      Up      ToC       Page 90 
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

Top      Up      ToC       Page 91 
      (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).

Top      Up      ToC       Page 92 
   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
   state on one side of the connection (perhaps as part of a forwarding
   plane reset or failover to a standby node), it is possible that a
   large number of packets will be sent in-order, but be wrongly
   detected by the peer as out-of-order.  This can be generally
   characterized for a window size, w, sequence number space, s, and
   number of packets lost in transit between L2TP endpoints, p, as

Top      Up      ToC       Page 93 
   If s > p > w, then an additional (s - p) packets that were otherwise
   received in-order, will be incorrectly classified as out-of-order and
   dropped.  Thus, for a sequence number space, s = 128, window size, w
   = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional
   packets would be dropped after the outage until the sequence number
   wrapped back to the current expected next sequence number.

   To mitigate this additional packet loss, one MUST inspect the
   sequence numbers of packets dropped due to being classified as "old"
   and reset the expected sequence number accordingly.  This may be
   accomplished by counting the number of "old" packets dropped that
   were in sequence among themselves and, upon reaching a threshold,
   resetting the next expected sequence number to that seen in the
   arriving data packets.  Packet timestamps may also be used as an
   indicator to reset the expected sequence number by detecting a period
   of time over which "old" packets have been received in-sequence.  The
   ideal thresholds will vary depending on link speed, sequence number
   space, and link tolerance to out-of-order packets, and MUST be

Editors' Addresses

   Jed Lau
   cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134


   W. Mark Townsley
   cisco Systems


   Ignacio Goyret
   Lucent Technologies


Top      Up      ToC       Page 94 
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-


   Funding for the RFC Editor function is currently provided by the
   Internet Society.