GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc3931

Network Working Group J. Lau, Ed. Request for Comments: 3931 M. Townsley, Ed. Category: Standards Track Cisco Systems

                                                        I. Goyret, Ed.
                                                   Lucent Technologies
                                                            March 2005
         Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document describes "version 3" of the Layer Two Tunneling
 Protocol (L2TPv3).  L2TPv3 defines the base control protocol and
 encapsulation for tunneling multiple Layer 2 connections between two
 IP nodes.  Additional documents detail the specifics for each data
 link type being emulated.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Changes from RFC 2661. . . . . . . . . . . . . . . . . .  4
     1.2.  Specification of Requirements. . . . . . . . . . . . . .  4
     1.3.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  5
 2.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
 3.  Protocol Overview. . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Control Message Types. . . . . . . . . . . . . . . . . . 10
     3.2.  L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
           3.2.1.  L2TP Control Message Header. . . . . . . . . . . 11
           3.2.2.  L2TP Data Message. . . . . . . . . . . . . . . . 12
     3.3.  Control Connection Management. . . . . . . . . . . . . . 13
           3.3.1.  Control Connection Establishment . . . . . . . . 14
           3.3.2.  Control Connection Teardown. . . . . . . . . . . 14
     3.4.  Session Management . . . . . . . . . . . . . . . . . . . 15
           3.4.1.  Session Establishment for an Incoming Call . . . 15
           3.4.2.  Session Establishment for an Outgoing Call . . . 15

Lau, et al. Standards Track [Page 1] RFC 3931 L2TPv3 March 2005

           3.4.3.  Session Teardown . . . . . . . . . . . . . . . . 16
 4.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
           4.1.1.  L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
           4.1.2.  L2TP over UDP. . . . . . . . . . . . . . . . . . 18
           4.1.3.  L2TP and IPsec . . . . . . . . . . . . . . . . . 20
           4.1.4.  IP Fragmentation Issues. . . . . . . . . . . . . 21
     4.2.  Reliable Delivery of Control Messages. . . . . . . . . . 23
     4.3.  Control Message Authentication . . . . . . . . . . . . . 25
     4.4.  Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
     4.5.  Forwarding Session Data Frames . . . . . . . . . . . . . 26
     4.6.  Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
           4.6.1.  Sequencing Data Packets. . . . . . . . . . . . . 28
     4.7.  L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
           4.7.1.  L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
           4.7.2.  L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
           4.7.3.  Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
 5.  Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
     5.1.  AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
     5.2.  Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
     5.3.  Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
     5.4.  AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
           5.4.1.  General Control Message AVPs . . . . . . . . . . 36
           5.4.2.  Result and Error Codes . . . . . . . . . . . . . 40
           5.4.3.  Control Connection Management AVPs . . . . . . . 43
           5.4.4.  Session Management AVPs. . . . . . . . . . . . . 48
           5.4.5.  Circuit Status AVPs. . . . . . . . . . . . . . . 57
 6.  Control Connection Protocol Specification. . . . . . . . . . . 59
     6.1.  Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
     6.2.  Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
     6.3.  Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
     6.4.  Stop-Control-Connection-Notification (StopCCN) . . . . . 61
     6.5.  Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
     6.6.  Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
     6.7.  Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
     6.8.  Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
     6.9.  Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
     6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
     6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
     6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
     6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
     6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
     6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
 7.  Control Connection State Machines. . . . . . . . . . . . . . . 68
     7.1.  Malformed AVPs and Control Messages. . . . . . . . . . . 68
     7.2.  Control Connection States. . . . . . . . . . . . . . . . 69
     7.3.  Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
           7.3.1.  ICRQ Sender States . . . . . . . . . . . . . . . 72

Lau, et al. Standards Track [Page 2] RFC 3931 L2TPv3 March 2005

           7.3.2.  ICRQ Recipient States. . . . . . . . . . . . . . 73
     7.4.  Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
           7.4.1.  OCRQ Sender States . . . . . . . . . . . . . . . 75
           7.4.2.  OCRQ Recipient (LAC) States. . . . . . . . . . . 76
     7.5.  Termination of a Control Connection. . . . . . . . . . . 77
 8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 78
     8.1.  Control Connection Endpoint and Message Security . . . . 78
     8.2.  Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
 9.  Internationalization Considerations. . . . . . . . . . . . . . 79
 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
     10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
     10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
     10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
     10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
     10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
     10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
     10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
     10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
     10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
     10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
     11.1. Normative References . . . . . . . . . . . . . . . . . . 85
     11.2. Informative References . . . . . . . . . . . . . . . . . 85
 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
 Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
 Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
 Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94

1. Introduction

 The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism
 for tunneling Layer 2 (L2) "circuits" across a packet-oriented data
 network (e.g., over IP).  L2TP, as originally defined in RFC 2661, is
 a standard method for tunneling Point-to-Point Protocol (PPP)
 [RFC1661] sessions.  L2TP has since been adopted for tunneling a
 number of other L2 protocols.  In order to provide greater
 modularity, this document describes the base L2TP protocol,
 independent of the L2 payload that is being tunneled.
 The base L2TP protocol defined in this document consists of (1) the
 control protocol for dynamic creation, maintenance, and teardown of
 L2TP sessions, and (2) the L2TP data encapsulation to multiplex and
 demultiplex L2 data streams between two L2TP nodes across an IP
 network.  Additional documents are expected to be published for each
 L2 data link emulation type (a.k.a. pseudowire-type) supported by
 L2TP (i.e., PPP, Ethernet, Frame Relay, etc.).  These documents will

Lau, et al. Standards Track [Page 3] RFC 3931 L2TPv3 March 2005

 contain any pseudowire-type specific details that are outside the
 scope of this base specification.
 When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as
 defined in RFC 2661 will be referred to as "L2TPv2", corresponding to
 the value in the Version field of an L2TP header.  (Layer 2
 Forwarding, L2F, [RFC2341] was defined as "version 1".)  At times,
 L2TP as defined in this document will be referred to as "L2TPv3".
 Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in
 general.

1.1. Changes from RFC 2661

 Many of the protocol constructs described in this document are
 carried over from RFC 2661.  Changes include clarifications based on
 years of interoperability and deployment experience as well as
 modifications to either improve protocol operation or provide a
 clearer separation from PPP.  The intent of these modifications is to
 achieve a healthy balance between code reuse, interoperability
 experience, and a directed evolution of L2TP as it is applied to new
 tasks.
 Notable differences between L2TPv2 and L2TPv3 include the following:
    Separation of all PPP-related AVPs, references, etc., including a
    portion of the L2TP data header that was specific to the needs of
    PPP.  The PPP-specific constructs are described in a companion
    document.
    Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
    Session ID and Control Connection ID, respectively.
    Extension of the Tunnel Authentication mechanism to cover the
    entire control message rather than just a portion of certain
    messages.
 Details of these changes and a recommendation for transitioning to
 L2TPv3 are discussed in Section 4.7.

1.2. Specification of Requirements

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

Lau, et al. Standards Track [Page 4] RFC 3931 L2TPv3 March 2005

1.3. Terminology

 Attribute Value Pair (AVP)
    The variable-length concatenation of a unique Attribute
    (represented by an integer), a length field, and a Value
    containing the actual value identified by the attribute.  Zero or
    more AVPs make up the body of control messages, which are used in
    the establishment, maintenance, and teardown of control
    connections.  This basic construct is sometimes referred to as a
    Type-Length-Value (TLV) in some specifications.  (See also:
    Control Connection, Control Message.)
 Call (Circuit Up)
    The action of transitioning a circuit on an L2TP Access
    Concentrator (LAC) to an "up" or "active" state.  A call may be
    dynamically established through signaling properties (e.g., an
    incoming or outgoing call through the Public Switched Telephone
    Network (PSTN)) or statically configured (e.g., provisioning a
    Virtual Circuit on an interface).  A call is defined by its
    properties (e.g., type of call, called number, etc.) and its data
    traffic.  (See also: Circuit, Session, Incoming Call, Outgoing
    Call, Outgoing Call Request.)
 Circuit
    A general term identifying any one of a wide range of L2
    connections.  A circuit may be virtual in nature (e.g., an ATM
    PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct
    correlation to a physical layer (e.g., an RS-232 serial line).
    Circuits may be statically configured with a relatively long-lived
    uptime, or dynamically established with signaling to govern the
    establishment, maintenance, and teardown of the circuit.  For the
    purposes of this document, a statically configured circuit is
    considered to be essentially the same as a very simple, long-
    lived, dynamic circuit.  (See also: Call, Remote System.)
 Client
    (See Remote System.)
 Control Connection
    An L2TP control connection is a reliable control channel that is
    used to establish, maintain, and release individual L2TP sessions
    as well as the control connection itself.  (See also: Control
    Message, Data Channel.)

Lau, et al. Standards Track [Page 5] RFC 3931 L2TPv3 March 2005

 Control Message
    An L2TP message used by the control connection.  (See also:
    Control Connection.)
 Data Message
    Message used by the data channel.  (a.k.a. Data Packet, See also:
    Data Channel.)
 Data Channel
    The channel for L2TP-encapsulated data traffic that passes between
    two LCCEs over a Packet-Switched Network (i.e., IP).  (See also:
    Control Connection, Data Message.)
 Incoming Call
    The action of receiving a call (circuit up event) on an LAC.  The
    call may have been placed by a remote system (e.g., a phone call
    over a PSTN), or it may have been triggered by a local event
    (e.g., interesting traffic routed to a virtual interface).  An
    incoming call that needs to be tunneled (as determined by the LAC)
    results in the generation of an L2TP ICRQ message.  (See also:
    Call, Outgoing Call, Outgoing Call Request.)
 L2TP Access Concentrator (LAC)
    If an L2TP Control Connection Endpoint (LCCE) is being used to
    cross-connect an L2TP session directly to a data link, we refer to
    it as an L2TP Access Concentrator (LAC).  An LCCE may act as both
    an L2TP Network Server (LNS) for some sessions and an LAC for
    others, so these terms must only be used within the context of a
    given set of sessions unless the LCCE is in fact single purpose
    for a given topology.  (See also: LCCE, LNS.)
 L2TP Control Connection Endpoint (LCCE)
    An L2TP node that exists at either end of an L2TP control
    connection.  May also be referred to as an LAC or LNS, depending
    on whether tunneled frames are processed at the data link (LAC) or
    network layer (LNS).  (See also: LAC, LNS.)
 L2TP Network Server (LNS)
    If a given L2TP session is terminated at the L2TP node and the
    encapsulated network layer (L3) packet processed on a virtual
    interface, we refer to this L2TP node as an L2TP Network Server

Lau, et al. Standards Track [Page 6] RFC 3931 L2TPv3 March 2005

    (LNS).  A given LCCE may act as both an LNS for some sessions and
    an LAC for others, so these terms must only be used within the
    context of a given set of sessions unless the LCCE is in fact
    single purpose for a given topology.  (See also: LCCE, LAC.)
 Outgoing Call
    The action of placing a call by an LAC, typically in response to
    policy directed by the peer in an Outgoing Call Request.  (See
    also: Call, Incoming Call, Outgoing Call Request.)
 Outgoing Call Request
    A request sent to an LAC to place an outgoing call.  The request
    contains specific information not known a priori by the LAC (e.g.,
    a number to dial).  (See also: Call, Incoming Call, Outgoing
    Call.)
 Packet-Switched Network (PSN)
    A network that uses packet switching technology for data delivery.
    For L2TPv3, this layer is principally IP.  Other examples include
    MPLS, Frame Relay, and ATM.
 Peer
    When used in context with L2TP, Peer refers to the far end of an
    L2TP control connection (i.e., the remote LCCE).  An LAC's peer
    may be either an LNS or another LAC.  Similarly, an LNS's peer may
    be either an LAC or another LNS.  (See also: LAC, LCCE, LNS.)
 Pseudowire (PW)
    An emulated circuit as it traverses a PSN.  There is one
    Pseudowire per L2TP Session.  (See also: Packet-Switched Network,
    Session.)
 Pseudowire Type
    The payload type being carried within an L2TP session.  Examples
    include PPP, Ethernet, and Frame Relay.  (See also: Session.)
 Remote System
    An end system or router connected by a circuit to an LAC.

Lau, et al. Standards Track [Page 7] RFC 3931 L2TPv3 March 2005

 Session
    An L2TP session is the entity that is created between two LCCEs in
    order to exchange parameters for and maintain an emulated L2
    connection.  Multiple sessions may be associated with a single
    Control Connection.
 Zero-Length Body (ZLB) Message
    A control message with only an L2TP header.  ZLB messages are used
    only to acknowledge messages on the L2TP reliable control
    connection.  (See also: Control Message.)

2. Topology

 L2TP operates between two L2TP Control Connection Endpoints (LCCEs),
 tunneling traffic across a packet network.  There are three
 predominant tunneling models in which L2TP operates: LAC-LNS (or vice
 versa), LAC-LAC, and LNS-LNS.  These models are diagrammed below.
 (Dotted lines designate network connections.  Solid lines designate
 circuit connections.)
                   Figure 2.0: L2TP Reference Models
 (a) LAC-LNS Reference Model: On one side, the LAC receives traffic
 from an L2 circuit, which it forwards via L2TP across an IP or other
 packet-based network.  On the other side, an LNS logically terminates
 the L2 circuit locally and routes network traffic to the home
 network.  The action of session establishment is driven by the LAC
 (as an incoming call) or the LNS (as an outgoing call).
  +-----+  L2  +-----+                        +-----+
  |     |------| LAC |.........[ IP ].........| LNS |...[home network]
  +-----+      +-----+                        +-----+
  remote
  system
                     |<-- emulated service -->|
        |<----------- L2 service ------------>|
 (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs.
 Each LAC forwards circuit traffic from the remote system to the peer
 LAC using L2TP, and vice versa.  In its simplest form, an LAC acts as
 a simple cross-connect between a circuit to a remote system and an
 L2TP session.  This model typically involves symmetric establishment;
 that is, either side of the connection may initiate a session at any
 time (or simultaneously, in which a tie breaking mechanism is
 utilized).

Lau, et al. Standards Track [Page 8] RFC 3931 L2TPv3 March 2005

 +-----+  L2  +-----+                      +-----+  L2  +-----+
 |     |------| LAC |........[ IP ]........| LAC |------|     |
 +-----+      +-----+                      +-----+      +-----+
 remote                                                 remote
 system                                                 system
                    |<- emulated service ->|
       |<----------------- L2 service ----------------->|
 (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs.  A
 user-level, traffic-generated, or signaled event typically drives
 session establishment from one side of the tunnel.  For example, a
 tunnel generated from a PC by a user, or automatically by customer
 premises equipment.
                 +-----+                      +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
                 +-----+                      +-----+
                       |<- emulated service ->|
                       |<---- L2 service ---->|
 Note: In L2TPv2, user-driven tunneling of this type is often referred
 to as "voluntary tunneling" [RFC2809].  Further, an LNS acting as
 part of a software package on a host is sometimes referred to as an
 "LAC Client" [RFC2661].

3. Protocol Overview

 L2TP is comprised of two types of messages, control messages and data
 messages (sometimes referred to as "control packets" and "data
 packets", respectively).  Control messages are used in the
 establishment, maintenance, and clearing of control connections and
 sessions.  These messages utilize a reliable control channel within
 L2TP to guarantee delivery (see Section 4.2 for details).  Data
 messages are used to encapsulate the L2 traffic being carried over
 the L2TP session.  Unlike control messages, data messages are not
 retransmitted when packet loss occurs.
 The L2TPv3 control message format defined in this document borrows
 largely from L2TPv2.  These control messages are used in conjunction
 with the associated protocol state machines that govern the dynamic
 setup, maintenance, and teardown for L2TP sessions.  The data message
 format for tunneling data packets may be utilized with or without the
 L2TP control channel, either via manual configuration or via other
 signaling methods to pre-configure or distribute L2TP session
 information.  Utilization of the L2TP data message format with other
 signaling methods is outside the scope of this document.

Lau, et al. Standards Track [Page 9] RFC 3931 L2TPv3 March 2005

                     Figure 3.0: L2TPv3 Structure
           +-------------------+    +-----------------------+
           | Tunneled Frame    |    | L2TP Control Message  |
           +-------------------+    +-----------------------+
           | L2TP Data Header  |    | L2TP Control Header   |
           +-------------------+    +-----------------------+
           | L2TP Data Channel |    | L2TP Control Channel  |
           | (unreliable)      |    | (reliable)            |
           +-------------------+----+-----------------------+
           | Packet-Switched Network (IP, FR, MPLS, etc.)   |
           +------------------------------------------------+
 Figure 3.0 depicts the relationship of control messages and data
 messages over the L2TP control and data channels, respectively.  Data
 messages are passed over an unreliable data channel, encapsulated by
 an L2TP header, and sent over a Packet-Switched Network (PSN) such as
 IP, UDP, Frame Relay, ATM, MPLS, etc.  Control messages are sent over
 a reliable L2TP control channel, which operates over the same PSN.
 The necessary setup for tunneling a session with L2TP consists of two
 steps: (1) Establishing the control connection, and (2) establishing
 a session as triggered by an incoming call or outgoing call.  An L2TP
 session MUST be established before L2TP can begin to forward session
 frames.  Multiple sessions may be bound to a single control
 connection, and multiple control connections may exist between the
 same two LCCEs.

3.1. Control Message Types

 The Message Type AVP (see Section 5.4.1) defines the specific type of
 control message being sent.
 This document defines the following control message types (see
 Sections 6.1 through 6.15 for details on the construction and use of
 each message):
 Control Connection Management
     0  (reserved)
     1  (SCCRQ)    Start-Control-Connection-Request
     2  (SCCRP)    Start-Control-Connection-Reply
     3  (SCCCN)    Start-Control-Connection-Connected
     4  (StopCCN)  Stop-Control-Connection-Notification
     5  (reserved)
     6  (HELLO)    Hello
    20  (ACK)      Explicit Acknowledgement

Lau, et al. Standards Track [Page 10] RFC 3931 L2TPv3 March 2005

 Call Management
     7  (OCRQ)     Outgoing-Call-Request
     8  (OCRP)     Outgoing-Call-Reply
     9  (OCCN)     Outgoing-Call-Connected
    10  (ICRQ)     Incoming-Call-Request
    11  (ICRP)     Incoming-Call-Reply
    12  (ICCN)     Incoming-Call-Connected
    13  (reserved)
    14  (CDN)      Call-Disconnect-Notify
 Error Reporting
    15  (WEN)      WAN-Error-Notify
 Link Status Change Reporting
    16  (SLI)      Set-Link-Info

3.2. L2TP Header Formats

 This section defines header formats for L2TP control messages and
 L2TP data messages.  All values are placed into their respective
 fields and sent in network order (high-order octets first).

3.2.1. L2TP Control Message Header

 The L2TP control message header provides information for the reliable
 transport of messages that govern the establishment, maintenance, and
 teardown of L2TP sessions.  By default, control messages are sent
 over the underlying media in-band with L2TP data messages.
 The L2TP control message header is formatted as follows:
               Figure 3.2.1: L2TP Control Message Header
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |T|L|x|x|S|x|x|x|x|x|x|x|  Ver  |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Control Connection ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Ns              |               Nr              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The T bit MUST be set to 1, indicating that this is a control
 message.

Lau, et al. Standards Track [Page 11] RFC 3931 L2TPv3 March 2005

 The L and S bits MUST be set to 1, indicating that the Length field
 and sequence numbers are present.
 The x bits are reserved for future extensions.  All reserved bits
 MUST be set to 0 on outgoing messages and ignored on incoming
 messages.
 The Ver field indicates the version of the L2TP control message
 header described in this document.  On sending, this field MUST be
 set to 3 for all messages (unless operating in an environment that
 includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section
 4.1 for details).
 The Length field indicates the total length of the message in octets,
 always calculated from the start of the control message header itself
 (beginning with the T bit).
 The Control Connection ID field contains the identifier for the
 control connection.  L2TP control connections are named by
 identifiers that have local significance only.  That is, the same
 control connection will be given unique Control Connection IDs by
 each LCCE from within each endpoint's own Control Connection ID
 number space.  As such, the Control Connection ID in each message is
 that of the intended recipient, not the sender.  Non-zero Control
 Connection IDs are selected and exchanged as Assigned Control
 Connection ID AVPs during the creation of a control connection.
 Ns indicates the sequence number for this control message, beginning
 at zero and incrementing by one (modulo 2**16) for each message sent.
 See Section 4.2 for more information on using this field.
 Nr indicates the sequence number expected in the next control message
 to be received.  Thus, Nr is set to the Ns of the last in-order
 message received plus one (modulo 2**16).  See Section 4.2 for more
 information on using this field.

3.2.2. L2TP Data Message

 In general, an L2TP data message consists of a (1) Session Header,
 (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as
 depicted below.

Lau, et al. Standards Track [Page 12] RFC 3931 L2TPv3 March 2005

                Figure 3.2.2: L2TP Data Message Header
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      L2TP Session Header                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      L2-Specific Sublayer                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Tunnel Payload                      ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The L2TP Session Header is specific to the encapsulating PSN over
 which the L2TP traffic is delivered.  The Session Header MUST provide
 (1) a method of distinguishing traffic among multiple L2TP data
 sessions and (2) a method of distinguishing data messages from
 control messages.
 Each type of encapsulating PSN MUST define its own session header,
 clearly identifying the format of the header and parameters necessary
 to setup the session.  Section 4.1 defines two session headers, one
 for transport over UDP and one for transport over IP.
 The L2-Specific Sublayer is an intermediary layer between the L2TP
 session header and the start of the tunneled frame.  It contains
 control fields that are used to facilitate the tunneling of each
 frame (e.g., sequence numbers or flags).  The Default L2-Specific
 Sublayer for L2TPv3 is defined in Section 4.6.
 The Data Message Header is followed by the Tunnel Payload, including
 any necessary L2 framing as defined in the payload-specific companion
 documents.

3.3. Control Connection Management

 The L2TP control connection handles dynamic establishment, teardown,
 and maintenance of the L2TP sessions and of the control connection
 itself.  The reliable delivery of control messages is described in
 Section 4.2.
 This section describes typical control connection establishment and
 teardown exchanges.  It is important to note that, in the diagrams
 that follow, the reliable control message delivery mechanism exists
 independently of the L2TP state machine.  For instance, Explicit
 Acknowledgement (ACK) messages may be sent after any of the control
 messages indicated in the exchanges below if an acknowledgment is not
 piggybacked on a later control message.

Lau, et al. Standards Track [Page 13] RFC 3931 L2TPv3 March 2005

 LCCEs are identified during control connection establishment either
 by the Host Name AVP, the Router ID AVP, or a combination of the two
 (see Section 5.4.3).  The identity of a peer LCCE is central to
 selecting proper configuration parameters (i.e., Hello interval,
 window size, etc.) for a control connection, as well as for
 determining how to set up associated sessions within the control
 connection, password lookup for control connection authentication,
 control connection level tie breaking, etc.

3.3.1. Control Connection Establishment

 Establishment of the control connection involves an exchange of AVPs
 that identifies the peer and its capabilities.
 A three-message exchange is used to establish the control connection.
 The following is a typical message exchange:
    LCCE A      LCCE B
    ------      ------
    SCCRQ ->
                <- SCCRP
    SCCCN ->

3.3.2. Control Connection Teardown

 Control connection teardown may be initiated by either LCCE and is
 accomplished by sending a single StopCCN control message.  As part of
 the reliable control message delivery mechanism, the recipient of a
 StopCCN MUST send an ACK message to acknowledge receipt of the
 message and maintain enough control connection state to properly
 accept StopCCN retransmissions over at least a full retransmission
 cycle (in case the ACK message is lost).  The recommended time for a
 full retransmission cycle is at least 31 seconds (see Section 4.2).
 The following is an example of a typical control message exchange:
    LCCE A      LCCE B
    ------      ------
    StopCCN ->
    (Clean up)
                (Wait)
                (Clean up)
 An implementation may shut down an entire control connection and all
 sessions associated with the control connection by sending the
 StopCCN.  Thus, it is not necessary to clear each session
 individually when tearing down the whole control connection.

Lau, et al. Standards Track [Page 14] RFC 3931 L2TPv3 March 2005

3.4. Session Management

 After successful control connection establishment, individual
 sessions may be created.  Each session corresponds to a single data
 stream between the two LCCEs.  This section describes the typical
 call establishment and teardown exchanges.

3.4.1. Session Establishment for an Incoming Call

 A three-message exchange is used to establish the session.  The
 following is a typical sequence of events:
    LCCE A      LCCE B
    ------      ------
    (Call
     Detected)
    ICRQ ->
               <- ICRP
    (Call
     Accepted)
    ICCN ->

3.4.2. Session Establishment for an Outgoing Call

 A three-message exchange is used to set up the session.  The
 following is a typical sequence of events:
    LCCE A      LCCE B
    ------      ------
               <- OCRQ
    OCRP ->
    (Perform
     Call
     Operation)
    OCCN ->
    (Call Operation
     Completed
     Successfully)

Lau, et al. Standards Track [Page 15] RFC 3931 L2TPv3 March 2005

3.4.3. Session Teardown

 Session teardown may be initiated by either the LAC or LNS and is
 accomplished by sending a CDN control message.  After the last
 session is cleared, the control connection MAY be torn down as well
 (and typically is).  The following is an example of a typical control
 message exchange:
    LCCE A      LCCE B
    ------      ------
    CDN ->
    (Clean up)
                (Clean up)

4. Protocol Operation

4.1. L2TP Over Specific Packet-Switched Networks (PSNs)

 L2TP may operate over a variety of PSNs.  There are two modes
 described for operation over IP, L2TP directly over IP (see Section
 4.1.1) and L2TP over UDP (see Section 4.1.2).  L2TPv3 implementations
 MUST support L2TP over IP and SHOULD support L2TP over UDP for better
 NAT and firewall traversal, and for easier migration from L2TPv2.
 L2TP over other PSNs may be defined, but the specifics are outside
 the scope of this document.  Examples of L2TPv2 over other PSNs
 include [RFC3070] and [RFC3355].
 The following field definitions are defined for use in all L2TP
 Session Header encapsulations.
 Session ID
    A 32-bit field containing a non-zero identifier for a session.
    L2TP sessions are named by identifiers that have local
    significance only.  That is, the same logical session will be
    given different Session IDs by each end of the control connection
    for the life of the session.  When the L2TP control connection is
    used for session establishment, Session IDs are selected and
    exchanged as Local Session ID AVPs during the creation of a
    session.  The Session ID alone provides the necessary context for
    all further packet processing, including the presence, size, and
    value of the Cookie, the type of L2-Specific Sublayer, and the
    type of payload being tunneled.

Lau, et al. Standards Track [Page 16] RFC 3931 L2TPv3 March 2005

 Cookie
    The optional Cookie field contains a variable-length value
    (maximum 64 bits) used to check the association of a received data
    message with the session identified by the Session ID.  The Cookie
    MUST be set to the configured or signaled random value for this
    session.  The Cookie provides an additional level of guarantee
    that a data message has been directed to the proper session by the
    Session ID.  A well-chosen Cookie may prevent inadvertent
    misdirection of stray packets with recently reused Session IDs,
    Session IDs subject to packet corruption, etc.  The Cookie may
    also provide protection against some specific malicious packet
    insertion attacks, as described in Section 8.2.
    When the L2TP control connection is used for session
    establishment, random Cookie values are selected and exchanged as
    Assigned Cookie AVPs during session creation.

4.1.1. L2TPv3 over IP

 L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol
 ID 115.

4.1.1.1. L2TPv3 Session Header Over IP

 Unlike L2TP over UDP, the L2TPv3 session header over IP is free of
 any restrictions imposed by coexistence with L2TPv2 and L2F.  As
 such, the header format has been designed to optimize packet
 processing.  The following session header format is utilized when
 operating L2TPv3 over IP:
             Figure 4.1.1.1: L2TPv3 Session Header Over IP
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Session ID                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Cookie (optional, maximum 64 bits)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Session ID and Cookie fields are as defined in Section 4.1.  The
 Session ID of zero is reserved for use by L2TP control messages (see
 Section 4.1.1.2).

Lau, et al. Standards Track [Page 17] RFC 3931 L2TPv3 March 2005

4.1.1.2. L2TP Control and Data Traffic over IP

 Unlike L2TP over UDP, which uses the T bit to distinguish between
 L2TP control and data packets, L2TP over IP uses the reserved Session
 ID of zero (0) when sending control messages.  It is presumed that
 checking for the zero Session ID is more efficient -- both in header
 size for data packets and in processing speed for distinguishing
 between control and data messages -- than checking a single bit.
 The entire control message header over IP, including the zero session
 ID, appears as follows:
         Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      (32 bits of zeros)                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |T|L|x|x|S|x|x|x|x|x|x|x|  Ver  |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Control Connection ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Ns              |               Nr              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Named fields are as defined in Section 3.2.1.  Note that the Length
 field is still calculated from the beginning of the control message
 header, beginning with the T bit.  It does NOT include the "(32 bits
 of zeros)" depicted above.
 When operating directly over IP, L2TP packets lose the ability to
 take advantage of the UDP checksum as a simple packet integrity
 check, which is of particular concern for L2TP control messages.
 Control Message Authentication (see Section 4.3), even with an empty
 password field, provides for a sufficient packet integrity check and
 SHOULD always be enabled.

4.1.2. L2TP over UDP

 L2TPv3 over UDP must consider other L2 tunneling protocols that may
 be operating in the same environment, including L2TPv2 [RFC2661] and
 L2F [RFC2341].
 While there are efficiencies gained by running L2TP directly over IP,
 there are possible side effects as well.  For instance, L2TP over IP
 is not as NAT-friendly as L2TP over UDP.

Lau, et al. Standards Track [Page 18] RFC 3931 L2TPv3 March 2005

4.1.2.1. L2TP Session Header Over UDP

 The following session header format is utilized when operating L2TPv3
 over UDP:
            Figure 4.1.2.1: L2TPv3 Session Header over UDP
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |T|x|x|x|x|x|x|x|x|x|x|x|  Ver  |          Reserved             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Session ID                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Cookie (optional, maximum 64 bits)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The T bit MUST be set to 0, indicating that this is a data message.
 The x bits and Reserved field are reserved for future extensions.
 All reserved values MUST be set to 0 on outgoing messages and ignored
 on incoming messages.
 The Ver field MUST be set to 3, indicating an L2TPv3 message.
 Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2
 [RFC2661], and are deprecated and marked as reserved in L2TPv3.
 Thus, for UDP mode on a system that supports both versions of L2TP,
 it is important that the Ver field be inspected first to determine
 the Version of the header before acting upon any of these bits.
 The Session ID and Cookie fields are as defined in Section 4.1.

4.1.2.2. UDP Port Selection

 The method for UDP Port Selection defined in this section is
 identical to that defined for L2TPv2 [RFC2661].
 When negotiating a control connection over UDP, control messages MUST
 be sent as UDP datagrams using the registered UDP port 1701
 [RFC1700].  The initiator of an L2TP control connection picks an
 available source UDP port (which may or may not be 1701) and sends to
 the desired destination address at port 1701.  The recipient picks a
 free port on its own system (which may or may not be 1701) and sends
 its reply to the initiator's UDP port and address, setting its own
 source port to the free port it found.

Lau, et al. Standards Track [Page 19] RFC 3931 L2TPv3 March 2005

 Any subsequent traffic associated with this control connection
 (either control traffic or data traffic from a session established
 through this control connection) must use these same UDP ports.
 It has been suggested that having the recipient choose an arbitrary
 source port (as opposed to using the destination port in the packet
 initiating the control connection, i.e., 1701) may make it more
 difficult for L2TP to traverse some NAT devices.  Implementations
 should consider the potential implication of this capability before
 choosing an arbitrary source port.  A NAT device that can pass TFTP
 traffic with variant UDP ports should be able to pass L2TP UDP
 traffic since both protocols employ similar policies with regard to
 UDP port selection.

4.1.2.3. UDP Checksum

 The tunneled frames that L2TP carry often have their own checksums or
 integrity checks, rendering the UDP checksum redundant for much of
 the L2TP data message contents.  Thus, UDP checksums MAY be disabled
 in order to reduce the associated packet processing burden at the
 L2TP endpoints.
 The L2TP header itself does not have its own checksum or integrity
 check.  However, use of the L2TP Session ID and Cookie pair guards
 against accepting an L2TP data message if corruption of the Session
 ID or associated Cookie has occurred.  When the L2-Specific Sublayer
 is present in the L2TP header, there is no built-in integrity check
 for the information contained therein if UDP checksums or some other
 integrity check is not employed.  IPsec (see Section 4.1.3) may be
 used for strong integrity protection of the entire contents of L2TP
 data messages.
 UDP checksums MUST be enabled for L2TP control messages.

4.1.3. L2TP and IPsec

 The L2TP data channel does not provide cryptographic security of any
 kind.  If the L2TP data channel operates over a public or untrusted
 IP network where privacy of the L2TP data is of concern or
 sophisticated attacks against L2TP are expected to occur, IPsec
 [RFC2401] MUST be made available to secure the L2TP traffic.
 Either L2TP over UDP or L2TP over IP may be secured with IPsec.
 [RFC3193] defines the recommended method for securing L2TPv2.  L2TPv3
 possesses identical characteristics to IPsec as L2TPv2 when running
 over UDP and implementations MUST follow the same recommendation.
 When operating over IP directly, [RFC3193] still applies, though
 references to UDP source and destination ports (in particular, those

Lau, et al. Standards Track [Page 20] RFC 3931 L2TPv3 March 2005

 in Section 4, "IPsec Filtering details when protecting L2TP") may be
 ignored.  Instead, the selectors used to identify L2TPv3 traffic are
 simply the source and destination IP addresses for the tunnel
 endpoints together with the L2TPv3 IP protocol type, 115.
 In addition to IP transport security, IPsec defines a mode of
 operation that allows tunneling of IP packets.  The packet-level
 encryption and authentication provided by IPsec tunnel mode and that
 provided by L2TP secured with IPsec provide an equivalent level of
 security for these requirements.
 IPsec also defines access control features that are required of a
 compliant IPsec implementation.  These features allow filtering of
 packets based upon network and transport layer characteristics such
 as IP address, ports, etc.  In the L2TP tunneling model, analogous
 filtering may be performed at the network layer above L2TP.  These
 network layer access control features may be handled at an LCCE via
 vendor-specific authorization features, or at the network layer
 itself by using IPsec transport mode end-to-end between the
 communicating hosts.  The requirements for access control mechanisms
 are not a part of the L2TP specification, and as such, are outside
 the scope of this document.
 Protecting the L2TP packet stream with IPsec does, in turn, also
 protect the data within the tunneled session packets while
 transported from one LCCE to the other.  Such protection must not be
 considered a substitution for end-to-end security between
 communicating hosts or applications.

4.1.4. IP Fragmentation Issues

 Fragmentation and reassembly in network equipment generally require
 significantly greater resources than sending or receiving a packet as
 a single unit.  As such, fragmentation and reassembly should be
 avoided whenever possible.  Ideal solutions for avoiding
 fragmentation include proper configuration and management of MTU
 sizes among the Remote System, the LCCE, and the IP network, as well
 as adaptive measures that operate with the originating host (e.g.,
 [RFC1191], [RFC1981]) to reduce the packet sizes at the source.
 An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
 example, if an IPv4 packet arrives at an LCCE from a Remote System
 that, after encapsulation with its associated framing, L2TP, and IP,
 does not fit in the available path MTU towards its LCCE peer, the
 local LCCE may perform IPv4 fragmentation on the packet before tunnel
 encapsulation.  This creates two (or more) L2TP packets, each

Lau, et al. Standards Track [Page 21] RFC 3931 L2TPv3 March 2005

 carrying an IPv4 fragment with its associated framing.  This
 ultimately has the effect of placing the burden of fragmentation on
 the LCCE, while reassembly occurs on the IPv4 destination host.
 If an IPv6 packet arrives at an LCCE from a Remote System that, after
 encapsulation with associated framing, L2TP and IP, does not fit in
 the available path MTU towards its L2TP peer, the Generic Packet
 Tunneling specification [RFC2473], Section 7.1 SHOULD be followed.
 In this case, the LCCE should either send an ICMP Packet Too Big
 message to the data source, or fragment the resultant L2TP/IP packet
 (for reassembly by the L2TP peer).
 If the amount of traffic requiring fragmentation and reassembly is
 rather light, or there are sufficiently optimized mechanisms at the
 tunnel endpoints, fragmentation of the L2TP/IP packet may be
 sufficient for accommodating mismatched MTUs that cannot be managed
 by more efficient means.  This method effectively emulates a larger
 MTU between tunnel endpoints and should work for any type of L2-
 encapsulated packet.  Note that IPv6 does not support "in-flight"
 fragmentation of data packets.  Thus, unlike IPv4, the MTU of the
 path towards an L2TP peer must be known in advance (or the last
 resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6
 fragmentation may occur at the LCCE.
 In summary, attempting to control the source MTU by communicating
 with the originating host, forcing that an MTU be sufficiently large
 on the path between LCCE peers to tunnel a frame from any other
 interface without fragmentation, fragmenting IP packets before
 encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP
 packet between the tunnel endpoints, are all valid methods for
 managing MTU mismatches.  Some are clearly better than others
 depending on the given deployment.  For example, a passive monitoring
 application using L2TP would certainly not wish to have ICMP messages
 sent to a traffic source.  Further, if the links connecting a set of
 LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that
 the MTU of all links being tunneled by L2TP have smaller MTUs (e.g.,
 1500 bytes), then any IP fragmentation and reassembly enabled on the
 participating LCCEs would never be utilized.  An implementation MUST
 implement at least one of the methods described in this section for
 managing mismatched MTUs, based on careful consideration of how the
 final product will be deployed.
 L2TP-specific fragmentation and reassembly methods, which may or may
 not depend on the characteristics of the type of link being tunneled
 (e.g., judicious packing of ATM cells), may be defined as well, but
 these methods are outside the scope of this document.

Lau, et al. Standards Track [Page 22] RFC 3931 L2TPv3 March 2005

4.2. Reliable Delivery of Control Messages

 L2TP provides a lower level reliable delivery service for all control
 messages.  The Nr and Ns fields of the control message header (see
 Section 3.2.1) belong to this delivery mechanism.  The upper level
 functions of L2TP are not concerned with retransmission or ordering
 of control messages.  The reliable control messaging mechanism is a
 sliding window mechanism that provides control message retransmission
 and congestion control.  Each peer maintains separate sequence number
 state for each control connection.
 The message sequence number, Ns, begins at 0.  Each subsequent
 message is sent with the next increment of the sequence number.  The
 sequence number is thus a free-running counter represented modulo
 65536.  The 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 the range of the last received number and the preceding
 32767 values, inclusive.  For example, if the last received sequence
 number was 15, then messages with sequence numbers 0 through 15, as
 well as 32784 through 65535, would be considered less than or equal.
 Such a message would be considered a duplicate of a message already
 received and ignored from processing.  However, in order to ensure
 that all messages are acknowledged properly (particularly in the case
 of a lost ACK message), receipt of duplicate messages MUST be
 acknowledged by the reliable delivery mechanism.  This acknowledgment
 may either piggybacked on a message in queue or sent explicitly via
 an ACK message.
 All control messages take up one slot in the control message sequence
 number space, except the ACK message.  Thus, Ns is not incremented
 after an ACK message is sent.
 The last received message number, Nr, is used to acknowledge messages
 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-ACK message received plus 1, modulo 65536).  While the Nr in a
 received ACK message is used to flush messages from the local
 retransmit queue (see below), the Nr of the next message sent is not
 updated by the Ns of the ACK message.  Nr SHOULD be sanity-checked
 before flushing the retransmit queue.  For instance, if the Nr
 received in a control message is greater than the last Ns sent plus 1
 modulo 65536, the control message is clearly invalid.
 The reliable delivery mechanism at a receiving peer is responsible
 for making sure that control messages are delivered in order and
 without duplication to the upper level.  Messages arriving out-of-
 order may be queued for in-order delivery when the missing messages

Lau, et al. Standards Track [Page 23] RFC 3931 L2TPv3 March 2005

 are received.  Alternatively, they may be discarded, thus requiring a
 retransmission by the peer.  When dropping out-of-order control
 packets, Nr MAY be updated before the packet is discarded.
 Each control connection maintains a queue of control messages to be
 transmitted to its peer.  The message at the front of the queue is
 sent with a given Ns value and is held until a control message
 arrives from the peer in which the Nr field indicates receipt of this
 message.  After a period of time (a recommended default is 1 second
 but SHOULD be configurable) passes without acknowledgment, the
 message is retransmitted.  The retransmitted message contains the
 same Ns value, but the Nr value MUST be updated with the sequence
 number of the next expected message.
 Each subsequent retransmission of a message MUST employ an
 exponential backoff interval.  Thus, if the first retransmission
 occurred after 1 second, the next retransmission should occur after 2
 seconds has elapsed, then 4 seconds, etc.  An implementation MAY
 place a cap upon the maximum interval between retransmissions.  This
 cap SHOULD be no less than 8 seconds per retransmission.  If no peer
 response is detected after several retransmissions (a recommended
 default is 10, but MUST be configurable), the control connection and
 all associated sessions MUST be cleared.  As it is the first message
 to establish a control connection, the SCCRQ MAY employ a different
 retransmission maximum than other control messages in order to help
 facilitate failover to alternate LCCEs in a timely fashion.
 When a control connection is being shut down for reasons other than
 loss of connectivity, the state and reliable delivery mechanisms MUST
 be maintained and operated for the full retransmission interval after
 the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8
 + 8... seconds), or until the StopCCN message itself has been
 acknowledged.
 A sliding window mechanism is used for control message transmission
 and retransmission.  Consider two peers, A and B.  Suppose A
 specifies a Receive Window Size AVP with a value of N in the SCCRQ or
 SCCRP message.  B is now allowed to have a maximum of N outstanding
 (i.e., unacknowledged) control messages.  Once N messages have been
 sent, B must wait for an acknowledgment from A that advances the
 window before sending new control messages.  An implementation may
 advertise a non-zero receive window as small or as large as it
 wishes, depending on its own ability to process incoming messages
 before sending an acknowledgement.  Each peer MUST limit the number
 of unacknowledged messages it will send before receiving an
 acknowledgement by this Receive Window Size.  The actual internal

Lau, et al. Standards Track [Page 24] RFC 3931 L2TPv3 March 2005

 unacknowledged message send-queue depth may be further limited by
 local resource allocation or by dynamic slow-start and congestion-
 avoidance mechanisms.
 When retransmitting control messages, a slow start and congestion
 avoidance window adjustment procedure SHOULD be utilized.  A
 recommended procedure is described in Appendix A.  A peer MAY drop
 messages, but MUST NOT actively delay acknowledgment of messages as a
 technique for flow control of control messages.  Appendix B contains
 examples of control message transmission, acknowledgment, and
 retransmission.

4.3. Control Message Authentication

 L2TP incorporates an optional authentication and integrity check for
 all control messages.  This mechanism consists of a computed one-way
 hash over the header and body of the L2TP control message, a pre-
 configured shared secret, and a local and remote nonce (random value)
 exchanged via the Control Message Authentication Nonce AVP. This
 per-message authentication and integrity check is designed to perform
 a mutual authentication between L2TP nodes, perform integrity
 checking of all control messages, and guard against control message
 spoofing and replay attacks that would otherwise be trivial to mount.
 At least one shared secret (password) MUST exist between
 communicating L2TP nodes to enable Control Message Authentication.
 See Section 5.4.3 for details on calculation of the Message Digest
 and construction of the Control Message Authentication Nonce and
 Message Digest AVPs.
 L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661]
 Tunnel Authentication in its use of a shared secret and one-way hash
 calculation.  The principal difference is that, instead of computing
 the hash over selected contents of a received control message (e.g.,
 the Challenge AVP and Message Type) as in L2TPv2, the entire message
 is used in the hash in L2TPv3.  In addition, instead of including the
 hash digest in just the SCCRP and SCCCN messages, it is now included
 in all L2TP messages.
 The Control Message Authentication mechanism is optional, and may be
 disabled if both peers agree.  For example, if IPsec is already being
 used for security and integrity checking between the LCCEs, the
 function of the L2TP mechanism becomes redundant and may be disabled.
 Presence of the Control Message Authentication Nonce AVP in an SCCRQ
 or SCCRP message serves as indication to a peer that Control Message
 Authentication is enabled.  If an SCCRQ or SCCRP contains a Control
 Message Authentication Nonce AVP, the receiver of the message MUST

Lau, et al. Standards Track [Page 25] RFC 3931 L2TPv3 March 2005

 respond with a Message Digest AVP in all subsequent messages sent.
 Control Message Authentication is always bidirectional; either both
 sides participate in authentication, or neither does.
 If Control Message Authentication is disabled, the Message Digest AVP
 still MAY be sent as an integrity check of the message.  The
 integrity check is calculated as in Section 5.4.3, with an empty
 zero-length shared secret, local nonce, and remote nonce.  If an
 invalid Message Digest is received, it should be assumed that the
 message has been corrupted in transit and the message dropped
 accordingly.
 Implementations MAY rate-limit control messages, particularly SCCRQ
 messages, upon receipt for performance reasons or for protection
 against denial of service attacks.

4.4. Keepalive (Hello)

 L2TP employs a keepalive mechanism to detect loss of connectivity
 between a pair of LCCEs.  This is accomplished by injecting Hello
 control messages (see Section 6.5) after a period of time has elapsed
 since the last data message or control message was received on an
 L2TP session or control connection, respectively.  As with any other
 control message, if the Hello message is not reliably delivered, the
 sending LCCE declares that the control connection is down and resets
 its state for the control connection.  This behavior ensures that a
 connectivity failure between the LCCEs is detected independently by
 each end of a control connection.
 Since the control channel is operated in-band with data traffic over
 the PSN, this single mechanism can be used to infer basic data
 connectivity between a pair of LCCEs for all sessions associated with
 the control connection.
 Periodic keepalive for the control connection MUST be implemented by
 sending a Hello if a period of time (a recommended default is 60
 seconds, but MUST be configurable) has passed without receiving any
 message (data or control) from the peer.  An LCCE sending Hello
 messages across multiple control connections between the same LCCE
 endpoints MUST employ a jittered timer mechanism to prevent grouping
 of Hello messages.

4.5. Forwarding Session Data Frames

 Once session establishment is complete, circuit frames are received
 at an LCCE, encapsulated in L2TP (with appropriate attention to
 framing, as described in documents for the particular pseudowire
 type), and forwarded over the appropriate session.  For every

Lau, et al. Standards Track [Page 26] RFC 3931 L2TPv3 March 2005

 outgoing data message, the sender places the identifier specified in
 the Local Session ID AVP (received from peer during session
 establishment) in the Session ID field of the L2TP data header.  In
 this manner, session frames are multiplexed and demultiplexed between
 a given pair of LCCEs.  Multiple control connections may exist
 between a given pair of LCCEs, and multiple sessions may be
 associated with a given control connection.
 The peer LCCE receiving the L2TP data packet identifies the session
 with which the packet is associated by the Session ID in the data
 packet's header.  The LCCE then checks the Cookie field in the data
 packet against the Cookie value received in the Assigned Cookie AVP
 during session establishment.  It is important for implementers to
 note that the Cookie field check occurs after looking up the session
 context by the Session ID, and as such, consists merely of a value
 match of the Cookie field and that stored in the retrieved context.
 There is no need to perform a lookup across the Session ID and Cookie
 as a single value.  Any received data packets that contain invalid
 Session IDs or associated Cookie values MUST be dropped.  Finally,
 the LCCE either forwards the network packet within the tunneled frame
 (e.g., as an LNS) or switches the frame to a circuit (e.g., as an
 LAC).

4.6. Default L2-Specific Sublayer

 This document defines a Default L2-Specific Sublayer format (see
 Section 3.2.2) that a pseudowire may use for features such as
 sequencing support, L2 interworking, OAM, or other per-data-packet
 operations.  The Default L2-Specific Sublayer SHOULD be used by a
 given PW type to support these features if it is adequate, and its
 presence is requested by a peer during session negotiation.
 Alternative sublayers MAY be defined (e.g., an encapsulation with a
 larger Sequence Number field or timing information) and identified
 for use via the L2-Specific Sublayer Type AVP.
            Figure 4.6: Default L2-Specific Sublayer Format
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |x|S|x|x|x|x|x|x|              Sequence Number                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The S (Sequence) bit is set to 1 when the Sequence Number contains a
 valid number for this sequenced frame.  If the S bit is set to zero,
 the Sequence Number contents are undefined and MUST be ignored by the
 receiver.

Lau, et al. Standards Track [Page 27] RFC 3931 L2TPv3 March 2005

 The Sequence Number field contains a free-running counter of 2^24
 sequence numbers.  If the number in this field is valid, the S bit
 MUST be set to 1.  The Sequence Number begins at zero, which is a
 valid sequence number.  (In this way, implementations inserting
 sequence numbers do not have to "skip" zero when incrementing.)  The
 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
 the range of the last received number and the preceding (2^23-1)
 values, inclusive.

4.6.1. Sequencing Data Packets

 The Sequence Number field may be used to detect lost, duplicate, or
 out-of-order packets within a given session.
 When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
 data channel, this part of the link has the characteristic of being
 able to reorder, duplicate, or silently drop packets.  Reordering may
 break some non-IP protocols or L2 control traffic being carried by
 the link.  Silent dropping or duplication of packets may break
 protocols that assume per-packet indications of error, such as TCP
 header compression.  While a common mechanism for packet sequence
 detection is provided, the sequence dependency characteristics of
 individual protocols are outside the scope of this document.
 If any protocol being transported by over L2TP data channels cannot
 tolerate misordering of data packets, packet duplication, or silent
 packet loss, sequencing may be enabled on some or all packets by
 using the S bit and Sequence Number field defined in the Default L2-
 Specific Sublayer (see Section 4.6).  For a given L2TP session, each
 LCCE is responsible for communicating to its peer the level of
 sequencing support that it requires of data packets that it receives.
 Mechanisms to advertise this information during session negotiation
 are provided (see Data Sequencing AVP in Section 5.4.4).
 When determining whether a packet is in or out of sequence, an
 implementation SHOULD utilize a method that is resilient to temporary
 dropouts in connectivity coupled with high per-session packet rates.
 The recommended method is outlined in Appendix C.

4.7. L2TPv2/v3 Interoperability and Migration

 L2TPv2 and L2TPv3 environments should be able to coexist while a
 migration to L2TPv3 is made.  Migration issues are discussed for each
 media type in this section.  Most issues apply only to
 implementations that require both L2TPv2 and L2TPv3 operation.

Lau, et al. Standards Track [Page 28] RFC 3931 L2TPv3 March 2005

 However, even L2TPv3-only implementations must at least be mindful of
 these issues in order to interoperate with implementations that
 support both versions.

4.7.1. L2TPv3 over IP

 L2TPv3 implementations running strictly over IP with no desire to
 interoperate with L2TPv2 implementations may safely disregard most
 migration issues from L2TPv2.  All control messages and data messages
 are sent as described in this document, without normative reference
 to RFC 2661.
 If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only
 if it is not available, then L2TPv3 over UDP with automatic fallback
 (see Section 4.7.3) MUST be used.  There is no deterministic method
 for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3
 over UDP.  One could infer whether L2TPv3 over IP is supported by
 sending an SCCRQ and waiting for a response, but this could be
 problematic during periods of packet loss between L2TP nodes.

4.7.2. L2TPv3 over UDP

 The format of the L2TPv3 over UDP header is defined in Section
 4.1.2.1.
 When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2
 and shares the first two octets of header format with L2TPv2.  The
 Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets.
 If an implementation is capable of operating in L2TPv2 or L2TPv3
 modes, it is possible to automatically detect whether a peer can
 support L2TPv2 or L2TPv3 and operate accordingly.  The details of
 this fallback capability is defined in the following section.

4.7.3. Automatic L2TPv2 Fallback

 When running over UDP, an implementation may detect whether a peer is
 L2TPv3-capable by sending a special SCCRQ that is properly formatted
 for both L2TPv2 and L2TPv3.  This is accomplished by sending an SCCRQ
 with its Ver field set to 2 (for L2TPv2), and ensuring that any
 L2TPv3-specific AVPs (i.e., AVPs present within this document and not
 defined within RFC 2661) in the message are sent with each M bit set
 to 0, and that all L2TPv2 AVPs are present as they would be for
 L2TPv2.  This is done so that L2TPv3 AVPs will be ignored by an
 L2TPv2-only implementation.  Note that, in both L2TPv2 and L2TPv3,
 the value contained in the space of the control message header
 utilized by the 32-bit Control Connection ID in L2TPv3, and the 16-
 bit Tunnel ID and

Lau, et al. Standards Track [Page 29] RFC 3931 L2TPv3 March 2005

 16-bit Session ID in L2TPv2, are always 0 for an SCCRQ.  This
 effectively hides the fact that there are a pair of 16-bit fields in
 L2TPv2, and a single 32-bit field in L2TPv3.
 If the peer implementation is L2TPv3-capable, a control message with
 the Ver field set to 3 and an L2TPv3 header and message format will
 be sent in response to the SCCRQ.  Operation may then continue as
 L2TPv3.  If a message is received with the Ver field set to 2, it
 must be assumed that the peer implementation is L2TPv2-only, thus
 enabling fallback to L2TPv2 mode to safely occur.
 Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3
 implementations over UDP be liberal in accepting an SCCRQ control
 message with the Ver field set to 2 or 3 and the presence of L2TPv2-
 specific AVPs.  An L2TPv3-only implementation MUST ignore all L2TPv2
 AVPs (e.g., those defined in RFC 2661 and not in this document)
 within an SCCRQ with the Ver field set to 2 (even if the M bit is set
 on the L2TPv2-specific AVPs).

5. Control Message Attribute Value Pairs

 To maximize extensibility while permitting interoperability, a
 uniform method for encoding message types is used throughout L2TP.
 This encoding will be termed AVP (Attribute Value Pair) for the
 remainder of this document.

5.1. AVP Format

 Each AVP is encoded as follows:
                        Figure 5.1: AVP Format
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |M|H| rsvd  |      Length       |           Vendor ID           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Attribute Type        |        Attribute Value ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     (until Length is reached)                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The first six bits comprise a bit mask that describes the general
 attributes of the AVP.  Two bits are defined in this document; the
 remaining bits are reserved for future extensions.  Reserved bits
 MUST be set to 0 when sent and ignored upon receipt.

Lau, et al. Standards Track [Page 30] RFC 3931 L2TPv3 March 2005

 Mandatory (M) bit: Controls the behavior required of an
 implementation that receives an unrecognized AVP.  The M bit of a
 given AVP MUST only be inspected and acted upon if the AVP is
 unrecognized (see Section 5.2).
 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
 sensitive data, such as user passwords, as cleartext in an AVP.
 Section 5.3 describes the procedure for performing AVP hiding.
 Length: Contains the number of octets (including the Overall Length
 and bit mask fields) contained in this AVP.  The Length may be
 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
 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.
 Vendor ID: The IANA-assigned "SMI Network Management Private
 Enterprise Codes" [RFC1700] value.  The value 0, corresponding to
 IETF-adopted attribute values, is used for all AVPs defined within
 this document.  Any vendor wishing to implement its own L2TP
 extensions can use its own Vendor ID along with private Attribute
 values, guaranteeing that they will not collide with any other
 vendor's extensions or future IETF extensions.  Note that there are
 16 bits allocated for the Vendor ID, thus limiting this feature to
 the first 65,535 enterprises.
 Attribute Type: A 2-octet value with a unique interpretation across
 all AVPs defined under a given Vendor ID.
 Attribute Value: This is the actual value as indicated by the Vendor
 ID and Attribute Type.  It follows immediately after the Attribute
 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
 Length is 6.
 In the event that the 16-bit Vendor ID space is exhausted, vendor-
 specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the
 following manner:

Lau, et al. Standards Track [Page 31] RFC 3931 L2TPv3 March 2005

               Figure 5.2: Extended Vendor ID AVP Format
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |M|H| rsvd  |      Length       |               0               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              58               |       32-bit Vendor ID     ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |        Attribute Type         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Attribute Value                       ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  (until Length is reached)                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space
 within the Attribute Value field.  Multiple AVPs of this type may
 exist in any message.  The 16-bit Vendor ID MUST be 0, indicating
 that this is an IETF-defined AVP, and the Attribute Type MUST be 58,
 indicating that what follows is a vendor-specific AVP with a 32-bit
 Vendor ID code.  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 of the AVP is 12
 plus the length of the Attribute Value.

5.2. Mandatory AVPs and Setting the M Bit

 If the M bit is set on an AVP that is unrecognized by its recipient,
 the session or control connection associated with the control message
 containing the AVP MUST be shut down.  If the control message
 containing the unrecognized AVP is associated with a session (e.g.,
 an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a
 CDN with a Result Code of 2 and Error Code of 8 (as defined in
 Section 5.4.2) and shut down.  If the control message containing the
 unrecognized AVP is associated with establishment or maintenance of a
 Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the
 associated Control Connection MUST be issued a StopCCN with Result
 Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut
 down.  If the M bit is not set on an unrecognized AVP, the AVP MUST
 be ignored when received, processing the control message as if the
 AVP were not present.
 Receipt of an unrecognized AVP that has the M bit set is catastrophic
 to the session or control connection with which it is associated.
 Thus, the M bit should only be set for AVPs that are deemed crucial
 to proper operation of the session or control connection by the
 sender.  AVPs that are considered crucial by the sender may vary by
 application and configured options.  In no case shall a receiver of

Lau, et al. Standards Track [Page 32] RFC 3931 L2TPv3 March 2005

 an AVP "validate" if the M bit is set on a recognized AVP.  If the
 AVP is recognized (as all AVPs defined in this document MUST be for a
 compliant L2TPv3 specification), then by definition, the M bit is of
 no consequence.
 The sender of an AVP is free to set its M bit to 1 or 0 based on
 whether the configured application strictly requires the value
 contained in the AVP to be recognized or not.  For example,
 "Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of
 the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is
 supported and desired, and 1 if not.
 The M bit is useful as extra assurance for support of critical AVP
 extensions.  However, more explicit methods may be available to
 determine support for a given feature rather than using the M bit
 alone.  For example, if a new AVP is defined in a message for which
 there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP
 message), rather than simply sending an AVP in the message with the M
 bit set, availability of the extension may be identified by sending
 an AVP in the request message and expecting a corresponding AVP in a
 reply message.  This more explicit method, when possible, is
 preferred.
 The M bit also plays a role in determining whether or not a malformed
 or out-of-range value within an AVP should be ignored or should
 result in termination of a session or control connection (see Section
 7.1 for more details).

5.3. Hiding of AVP Attribute Values

 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
 present in cleartext.  This feature can be used to hide sensitive
 control message data such as user passwords, IDs, or other vital
 information.
 The H bit MUST only be set if (1) a shared secret exists between the
 LCCEs and (2) Control Message Authentication is enabled (see Section
 4.3).  If the H bit is set in any AVP(s) in a given control message,
 at least one Random Vector AVP must also be present in the message
 and MUST precede the first AVP having an H bit of 1.

Lau, et al. Standards Track [Page 33] RFC 3931 L2TPv3 March 2005

 The shared secret between LCCEs is used to derive a unique shared key
 for hiding and unhiding calculations.  The derived shared key is
 obtained via an HMAC-MD5 keyed hash [RFC2104], with the key
 consisting of the shared secret, and with the data being hashed
 consisting of a single octet containing the value 1.
       shared_key = HMAC_MD5 (shared_secret, 1)
 Hiding an AVP value is done in several steps.  The first step is to
 take the length and value fields of the original (cleartext) AVP and
 encode them into the Hidden AVP Subformat, which appears as follows:
                   Figure 5.3: Hidden AVP Subformat
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Length of Original Value    |   Original Attribute Value ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ...              |             Padding ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Length of Original Attribute Value: This is length of the Original
 Attribute Value to be obscured in octets.  This is necessary to
 determine the original length of the Attribute Value that is lost
 when the additional Padding is added.
 Original Attribute Value: Attribute Value that is to be obscured.
 Padding: Random additional octets used to obscure length of the
 Attribute Value that is being hidden.
 To mask the size of the data being hidden, the resulting subformat
 MAY be padded as shown above.  Padding does NOT alter the value
 placed in the Length of Original Attribute Value field, but does
 alter the length of the resultant AVP that is being created.  For
 example, if an Attribute Value to be hidden is 4 octets in length,
 the unhidden AVP length would be 10 octets (6 + Attribute Value
 length).  After hiding, the length of the AVP would become 6 +
 Attribute Value length + size of the Length of Original Attribute
 Value field + Padding.  Thus, if Padding is 12 octets, the AVP length
 would be 6 + 4 + 2 + 12 = 24 octets.

Lau, et al. Standards Track [Page 34] RFC 3931 L2TPv3 March 2005

 Next, an MD5 [RFC1321] hash is performed (in network byte order) on
 the concatenation of the following:
       + the 2-octet Attribute number of the AVP
       + the shared key
       + an arbitrary length random vector
 The value of the random vector used in this hash is passed in the
 value field of a Random Vector AVP.  This Random Vector AVP must be
 placed in the message by the sender before any hidden AVPs.  The same
 random vector may be used for more than one hidden AVP in the same
 message, but not for hiding two or more instances of an AVP with the
 same Attribute Type unless the Attribute Values in the two AVPs are
 also identical.  When a different random vector is used for the
 hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in
 the control message before the first AVP to which it applies.
 The MD5 hash value is then XORed with the first 16-octet (or less)
 segment of the Hidden AVP Subformat and placed in the Attribute Value
 field of the Hidden AVP.  If the Hidden AVP Subformat is less than 16
 octets, the Subformat is transformed as if the Attribute Value field
 had been padded to 16 octets before the XOR.  Only the actual octets
 present in the Subformat are modified, and the length of the AVP is
 not altered.
 If the Subformat is longer than 16 octets, a second one-way MD5 hash
 is calculated over a stream of octets consisting of the shared key
 followed by the result of the first XOR.  That hash is XORed with the
 second 16-octet (or less) segment of the Subformat and placed in the
 corresponding octets of the Value field of the Hidden AVP.
 If necessary, this operation is repeated, with the shared key used
 along with each XOR result to generate the next hash to XOR the next
 segment of the value with.
 The hiding method was adapted from [RFC2865], which was taken from
 the "Mixing in the Plaintext" section in the book "Network Security"
 by Kaufman, Perlman and Speciner [KPS].  A detailed explanation of
 the method follows:
 Call the shared key S, the Random Vector RV, and the Attribute Type
 A.  Break the value field into 16-octet chunks p_1, p_2, etc., 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
 define intermediate values b_1, b_2, etc.

Lau, et al. Standards Track [Page 35] RFC 3931 L2TPv3 March 2005

    b_1 = MD5 (A + S + RV)   c_1 = p_1 xor b_1
    b_2 = MD5 (S + c_1)      c_2 = p_2 xor b_2
              .                      .
              .                      .
              .                      .
    b_i = MD5 (S + c_i-1)    c_i = p_i xor b_i
 The String will contain c_1 + c_2 +...+ c_i, where "+" denotes
 concatenation.
 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
 above process is then reversed to yield the original value.

5.4. AVP Summary

 The following sections contain a list of all L2TP AVPs defined in
 this document.
 Following the name of the AVP is a list indicating the message types
 that utilize each AVP.  After each AVP title follows a short
 description of the purpose of the AVP, a detail (including a graphic)
 of the format for the Attribute Value, and any additional information
 needed for proper use of the AVP.

5.4.1. General Control Message AVPs

 Message Type (All Messages)
    The Message Type AVP, Attribute Type 0, identifies the control
    message herein and defines the context in which the exact meaning
    of the following AVPs will be determined.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Message Type          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Message Type is a 2-octet unsigned integer.
    The Message Type AVP MUST be the first AVP in a message,
    immediately following the control message header (defined in
    Section 3.2.1).  See Section 3.1 for the list of defined control
    message types and their identifiers.

Lau, et al. Standards Track [Page 36] RFC 3931 L2TPv3 March 2005

    The Mandatory (M) bit within the Message Type AVP has special
    meaning.  Rather than an indication as to whether the AVP itself
    should be ignored if not recognized, it is an indication as to
    whether the control message itself should be ignored.  If the M
    bit is set within the Message Type AVP and the Message Type is
    unknown to the implementation, the control connection MUST be
    cleared.  If the M bit is not set, then the implementation may
    ignore an unknown message type.  The M bit MUST be set to 1 for
    all message types defined in this document.  This AVP MUST NOT be
    hidden (the H bit MUST be 0).  The Length of this AVP is 8.
    A vendor-specific control message may be defined by setting the
    Vendor ID of the Message Type AVP to a value other than the IETF
    Vendor ID of 0 (see Section 5.1).  The Message Type AVP MUST still
    be the first AVP in the control message.
 Message Digest (All Messages)
    The Message Digest AVP, Attribute Type 59 is used as an integrity
    and authentication check of the L2TP Control Message header and
    body.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Digest Type  | Message Digest ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      ... (16 or 20 octets)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Digest Type is a one-octet integer indicating the Digest
    calculation algorithm:
       0 HMAC-MD5 [RFC2104]
       1 HMAC-SHA-1 [RFC2104]
    Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1
    (HMAC-SHA-1) SHOULD be supported.
    The Message Digest is of variable length and contains the result
    of the control message authentication and integrity calculation.
    For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16

Lau, et al. Standards Track [Page 37] RFC 3931 L2TPv3 March 2005

    bytes.  For Digest Type 1 (HMAC-SHA-1) the length of the digest
    MUST be 20 bytes.
    If Control Message Authentication is enabled, at least one Message
    Digest AVP MUST be present in all messages and MUST be placed
    immediately after the Message Type AVP.  This forces the Message
    Digest AVP to begin at a well-known and fixed offset.  A second
    Message Digest AVP MAY be present in a message and MUST be placed
    directly after the first Message Digest AVP.
    The shared secret between LCCEs is used to derive a unique shared
    key for Control Message Authentication calculations.  The derived
    shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with
    the key consisting of the shared secret, and with the data being
    hashed consisting of a single octet containing the value 2.
       shared_key = HMAC_MD5 (shared_secret, 2)
    Calculation of the Message Digest is as follows for all messages
    other than the SCCRQ (where "+" refers to concatenation):
       Message Digest = HMAC_Hash (shared_key, local_nonce +
                                   remote_nonce + control_message)
       HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type
       (MD5 or SHA1)
       local_nonce: Nonce chosen locally and advertised to the remote
       LCCE.
       remote_nonce: Nonce received from the remote LCCE
       (The local_nonce and remote_nonce are advertised via the
       Control Message Authentication Nonce AVP, also defined in this
       section.)
       shared_key: Derived shared key for this control connection
       control_message: The entire contents of the L2TP control
       message, including the control message header and all AVPs.
       Note that the control message header in this case begins after
       the all-zero Session ID when running over IP (see Section
       4.1.1.2), and after the UDP header when running over UDP (see
       Section 4.1.2.1).
    When calculating the Message Digest, the Message Digest AVP MUST
    be present within the control message with the Digest Type set to
    its proper value, but the Message Digest itself set to zeros.

Lau, et al. Standards Track [Page 38] RFC 3931 L2TPv3 March 2005

    When receiving a control message, the contents of the Message
    Digest AVP MUST be compared against the expected digest value
    based on local calculation.  This is done by performing the same
    digest calculation above, with the local_nonce and remote_nonce
    reversed.  This message authenticity and integrity checking MUST
    be performed before utilizing any information contained within the
    control message.  If the calculation fails, the message MUST be
    dropped.
    The SCCRQ has special treatment as it is the initial message
    commencing a new control connection.  As such, there is only one
    nonce available.  Since the nonce is present within the message
    itself as part of the Control Message Authentication Nonce AVP,
    there is no need to use it in the calculation explicitly.
    Calculation of the SCCRQ Message Digest is performed as follows:
       Message Digest = HMAC_Hash (shared_key, control_message)
    To allow for graceful switchover to a new shared secret or hash
    algorithm, two Message Digest AVPs MAY be present in a control
    message, and two shared secrets MAY be configured for a given
    LCCE.  If two Message Digest AVPs are received in a control
    message, the message MUST be accepted if either Message Digest is
    valid.  If two shared secrets are configured, each (separately)
    MUST be used for calculating a digest to be compared to the
    Message Digest(s) received.  When calculating a digest for a
    control message, the Value field for both of the Message Digest
    AVPs MUST be set to zero.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type
    2 (HMAC-SHA-1).
 Control Message Authentication Nonce (SCCRQ, SCCRP)
    The Control Message Authentication Nonce AVP, Attribute Type 73,
    MUST contain a cryptographically random value [RFC1750].  This
    value is used for Control Message Authentication.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Nonce ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lau, et al. Standards Track [Page 39] RFC 3931 L2TPv3 March 2005

    The Nonce is of arbitrary length, though at least 16 octets is
    recommended.  The Nonce contains the random value for use in the
    Control Message Authentication hash calculation (see Message
    Digest AVP definition in this section).
    If Control Message Authentication is enabled, this AVP MUST be
    present in the SCCRQ and SCCRP messages.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length of this AVP is 6 plus the length of the Nonce.
 Random Vector (All Messages)
    The Random Vector AVP, Attribute Type 36, MUST contain a
    cryptographically random value [RFC1750].  This value is used for
    AVP Hiding.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Random Octet String ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Random Octet String is of arbitrary length, though at least 16
    octets is recommended.  The string contains the random vector for
    use in computing the MD5 hash to retrieve or hide the Attribute
    Value of a hidden AVP (see Section 5.3).
    More than one Random Vector AVP may appear in a message, in which
    case a hidden AVP uses the Random Vector AVP most closely
    preceding it.  As such, at least one Random Vector AVP MUST
    precede the first AVP with the H bit set.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length of this AVP is 6 plus the length of the Random Octet
    String.

5.4.2. Result and Error Codes

 Result Code (StopCCN, CDN)
    The Result Code AVP, Attribute Type 1, indicates the reason for
    terminating the control connection or session.

Lau, et al. Standards Track [Page 40] RFC 3931 L2TPv3 March 2005

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Result Code          |     Error Code (optional)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Error Message ... (optional, arbitrary number of octets)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Result Code is a 2-octet unsigned integer.  The optional Error
    Code is a 2-octet unsigned integer.  An optional Error Message can
    follow the Error Code field.  Presence of the Error Code and
    Message is indicated by the AVP Length field.  The Error Message
    contains an arbitrary string providing further (human-readable)
    text associated with the condition.  Human-readable text in all
    error messages MUST be provided in the UTF-8 charset [RFC3629]
    using the Default Language [RFC2277].
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length is 8 if there is no Error Code or Message, 10 if there is
    an Error Code and no Error Message, or 10 plus the length of the
    Error Message if there is an Error Code and Message.
    Defined Result Code values for the StopCCN message are as follows:
       0 - Reserved.
       1 - General request to clear control connection.
       2 - General error, Error Code indicates the problem.
       3 - Control connection already exists.
       4 - Requester is not authorized to establish a control
           connection.
       5 - The protocol version of the requester is not supported,
           Error Code indicates highest version supported.
       6 - Requester is being shut down.
       7 - Finite state machine error or timeout
    General Result Code values for the CDN message are as follows:
       0 - Reserved.
       1 - Session disconnected due to loss of carrier or
           circuit disconnect.
       2 - Session disconnected for the reason indicated in Error
           Code.
       3 - Session disconnected for administrative reasons.
       4 - Session establishment failed due to lack of appropriate
           facilities being available (temporary condition).

Lau, et al. Standards Track [Page 41] RFC 3931 L2TPv3 March 2005

       5 - Session establishment failed due to lack of appropriate
           facilities being available (permanent condition).
      13 - Session not established due to losing tie breaker.
      14 - Session not established due to unsupported PW type.
      15 - Session not established, sequencing required without
           valid L2-Specific Sublayer.
      16 - Finite state machine error or timeout.
    Additional service-specific Result Codes are defined outside this
    document.
    The Error Codes defined below pertain to types of errors that are
    not specific to any particular L2TP request, but rather to
    protocol or message format errors.  If an L2TP reply indicates in
    its Result Code that a General Error occurred, the General Error
    value should be examined to determine what the error was.  The
    currently defined General Error codes and their meanings are as
    follows:
    0 - No General Error.
    1 - No control connection exists yet for this pair of LCCEs.
    2 - Length is wrong.
    3 - One of the field values was out of range.
    4 - Insufficient resources to handle this operation now.
    5 - Invalid Session ID.
    6 - A generic vendor-specific error occurred.
    7 - Try another.  If initiator is aware of other possible
        responder destinations, it should try one of them.  This can
        be used to guide an LAC or LNS based on policy.
    8 - The session or control connection was shut down due to receipt
        of an unknown AVP with the M bit set (see Section 5.2).  The
        Error Message SHOULD contain the attribute of the offending
        AVP in (human-readable) text form.
    9 - Try another directed.  If an LAC or LNS is aware of other
        possible destinations, it should inform the initiator of the
        control connection or session.  The Error Message MUST contain
        a comma-separated list of addresses from which the initiator
        may choose.  If the L2TP data channel runs over IPv4, then
        this would be a comma-separated list of IP addresses in the
        canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2,
        192.0.2.3") in the UTF-8 charset [RFC3629] using the Default
        Language [RFC2277].  If there are no servers for the LAC or
        LNS to suggest, then Error Code 7 should be used.  For IPv4,
        the delimiter between addresses MUST be precisely a single
        comma and a single space.  For IPv6, each literal address MUST
        be enclosed in "[" and "]" characters, following the encoding
        described in [RFC2732].

Lau, et al. Standards Track [Page 42] RFC 3931 L2TPv3 March 2005

    When a General Error Code of 6 is used, additional information
    about the error SHOULD be included in the Error Message field.  A
    vendor-specific AVP MAY be sent to more precisely detail a
    vendor-specific problem.

5.4.3. Control Connection Management AVPs

 Control Connection Tie Breaker (SCCRQ)
    The Control Connection Tie Breaker AVP, Attribute Type 5,
    indicates that the sender desires a single control connection to
    exist between a given pair of LCCEs.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Control Connection Tie Breaker Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                               ... (64 bits)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Control Connection Tie Breaker Value is an 8-octet random
    value that is used to choose a single control connection when two
    LCCEs request a control connection concurrently.  The recipient of
    a SCCRQ must check to see if a SCCRQ has been sent to the peer; if
    so, a tie has been detected.  In this case, the LCCE must compare
    its Control Connection Tie Breaker value with the one received in
    the SCCRQ.  The lower value "wins", and the "loser" MUST discard
    its control connection.  A StopCCN SHOULD be sent by the winner as
    an explicit rejection for the losing SCCRQ.  In the case in which
    a tie breaker is present on both sides and the value is equal,
    both sides MUST discard their control connections and restart
    control connection negotiation with a new, random tie breaker
    value.
    If a tie breaker is received and an outstanding SCCRQ has no tie
    breaker value, the initiator that included the Control Connection
    Tie Breaker AVP "wins".  If neither side issues a tie breaker,
    then two separate control connections are opened.
    Applications that employ a distinct and well-known initiator have
    no need for tie breaking, and MAY omit this AVP or disable tie
    breaking functionality.  Applications that require tie breaking
    also require that an LCCE be uniquely identifiable upon receipt of
    an SCCRQ.  For L2TP over IP, this MUST be accomplished via the
    Router ID AVP.

Lau, et al. Standards Track [Page 43] RFC 3931 L2TPv3 March 2005

    Note that in [RFC2661], this AVP is referred to as the "Tie
    Breaker AVP" and is applicable only to a control connection.  In
    L2TPv3, the AVP serves the same purpose of tie breaking, but is
    applicable to a control connection or a session.  The Control
    Connection Tie Breaker AVP (present only in Control Connection
    messages) and Session Tie Breaker AVP (present only in Session
    messages), are described separately in this document, but share
    the same Attribute type of 5.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    length of this AVP is 14.
 Host Name (SCCRQ, SCCRP)
    The Host Name AVP, Attribute Type 7, indicates the name of the
    issuing LAC or LNS, encoded in the US-ASCII charset.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Host Name ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Host Name is of arbitrary length, but MUST be at least 1
    octet.
    This name should be as broadly unique as possible; for hosts
    participating in DNS [RFC1034], a host name with fully qualified
    domain would be appropriate.  The Host Name AVP and/or Router ID
    AVP MUST be used to identify an LCCE as described in Section 3.3.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length of this AVP is 6 plus the length of the Host Name.
 Router ID (SCCRQ, SCCRP)
    The Router ID AVP, Attribute Type 60, is an identifier used to
    identify an LCCE for control connection setup, tie breaking,
    and/or tunnel authentication.

Lau, et al. Standards Track [Page 44] RFC 3931 L2TPv3 March 2005

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Router Identifier                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Router Identifier is a 4-octet unsigned integer.  Its value is
    unique for a given LCCE, per Section 8.1 of [RFC2072].  The Host
    Name AVP and/or Router ID AVP MUST be used to identify an LCCE as
    described in Section 3.3.
    Implementations MUST NOT assume that Router Identifier is a valid
    IP address.  The Router Identifier for L2TP over IPv6 can be
    obtained from an IPv4 address (if available) or via unspecified
    implementation-specific means.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length of this AVP is 10.
 Vendor Name (SCCRQ, SCCRP)
    The Vendor Name AVP, Attribute Type 8, contains a vendor-specific
    (possibly human-readable) string describing the type of LAC or LNS
    being used.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Vendor Name ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Vendor Name is the indicated number of octets representing the
    vendor string.  Human-readable text for this AVP MUST be provided
    in the US-ASCII charset [RFC1958, RFC2277].
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 6 plus the length of the
    Vendor Name.

Lau, et al. Standards Track [Page 45] RFC 3931 L2TPv3 March 2005

 Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
    The Assigned Control Connection ID AVP, Attribute Type 61,
    contains the ID being assigned to this control connection by the
    sender.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Assigned Control Connection ID                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Assigned Control Connection ID is a 4-octet non-zero unsigned
    integer.
    The Assigned Control Connection ID AVP establishes the identifier
    used to multiplex and demultiplex multiple control connections
    between a pair of LCCEs.  Once the Assigned Control Connection ID
    AVP has been received by an LCCE, the Control Connection ID
    specified in the AVP MUST be included in the Control Connection ID
    field of all control packets sent to the peer for the lifetime of
    the control connection.  Before the Assigned Control Connection ID
    AVP is received from a peer, all control messages MUST be sent to
    that peer with a Control Connection ID value of 0 in the header.
    Because a Control Connection ID value of 0 is used in this special
    manner, the zero value MUST NOT be sent as an Assigned Control
    Connection ID value.
    Under certain circumstances, an LCCE may need to send a StopCCN to
    a peer without having yet received an Assigned Control Connection
    ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet).
    In this case, the Assigned Control Connection ID AVP that had been
    sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the
    Assigned Control Connection ID AVP in the StopCCN.  This policy
    allows the peer to try to identify the appropriate control
    connection via a reverse lookup.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 10.
 Receive Window Size (SCCRQ, SCCRP)
    The Receive Window Size AVP, Attribute Type 10, specifies the
    receive window size being offered to the remote peer.

Lau, et al. Standards Track [Page 46] RFC 3931 L2TPv3 March 2005

    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Window Size           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Window Size is a 2-octet unsigned integer.
    If absent, the peer must assume a Window Size of 4 for its
    transmit window.
    The remote peer may send the specified number of control messages
    before it must wait for an acknowledgment.  See Section 4.2 for
    more information on reliable control message delivery.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length of this AVP is 8.
 Pseudowire Capabilities List (SCCRQ, SCCRP)
    The Pseudowire Capabilities List (PW Capabilities List) AVP,
    Attribute Type 62, indicates the L2 payload types the sender can
    support.  The specific payload type of a given session is
    identified by the Pseudowire Type AVP.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           PW Type 0           |             ...               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ...              |          PW Type N            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Defined PW types that may appear in this list are managed by IANA
    and will appear in associated pseudowire-specific documents for
    each PW type.
    If a sender includes a given PW type in the PW Capabilities List
    AVP, the sender assumes full responsibility for supporting that
    particular payload, such as any payload-specific AVPs, L2-Specific
    Sublayer, or control messages that may be defined in the
    appropriate companion document.

Lau, et al. Standards Track [Page 47] RFC 3931 L2TPv3 March 2005

    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 8 octets with one PW type
    specified, plus 2 octets for each additional PW type.
 Preferred Language (SCCRQ, SCCRP)
    The Preferred Language AVP, Attribute Type 72, provides a method
    for an LCCE to indicate to the peer the language in which human-
    readable messages it sends SHOULD be composed.  This AVP contains
    a single language tag or language range [RFC3066].
    The Attribute Value field for this AVP has the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Preferred Language... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Preferred Language is the indicated number of octets
    representing the language tag or language range, encoded in the
    US-ASCII charset.
    It is not required to send a Preferred Language AVP.  If (1) an
    LCCE does not signify a language preference by the inclusion of
    this AVP in the 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.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 6 plus the length of the
    Preferred Language.

5.4.4. Session Management AVPs

 Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
    The Local Session ID AVP (analogous to the Assigned Session ID in
    L2TPv2), Attribute Type 63, contains the identifier being assigned
    to this session by the sender.

Lau, et al. Standards Track [Page 48] RFC 3931 L2TPv3 March 2005

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Local Session ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Local Session ID is a 4-octet non-zero unsigned integer.
    The Local Session ID AVP establishes the two identifiers used to
    multiplex and demultiplex sessions between two LCCEs.  Each LCCE
    chooses any free value it desires, and sends it to the remote LCCE
    using this AVP.  The remote LCCE MUST then send all data packets
    associated with this session using this value.  Additionally, for
    all session-oriented control messages sent after this AVP is
    received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST
    echo this value in the Remote Session ID AVP.
    Note that a Session ID value is unidirectional.  Because each LCCE
    chooses its Session ID independent of its peer LCCE, the value
    does not have to match in each direction for a given session.
    See Section 4.1 for additional information about the Session ID.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2).
    The Length (before hiding) of this AVP is 10.
 Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
    The Remote Session ID AVP, Attribute Type 64, contains the
    identifier that was assigned to this session by the peer.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Remote Session ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Remote Session ID is a 4-octet non-zero unsigned integer.
    The Remote Session ID AVP MUST be present in all session-level
    control messages.  The AVP's value echoes the session identifier
    advertised by the peer via the Local Session ID AVP.  It is the
    same value that will be used in all transmitted data messages by

Lau, et al. Standards Track [Page 49] RFC 3931 L2TPv3 March 2005

    this side of the session.  In most cases, this identifier is
    sufficient for the peer to look up session-level context for this
    control message.
    When a session-level control message must be sent to the peer
    before the Local Session ID AVP has been received, the value of
    the Remote Session ID AVP MUST be set to zero.  Additionally, the
    Local Session ID AVP (sent in a previous control message for this
    session) MUST be included in the control message.  The peer must
    then use the Local Session ID AVP to perform a reverse lookup to
    find its session context.  Session-level control messages defined
    in this document that might be subject to a reverse lookup by a
    receiving peer include the CDN, WEN, and SLI.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 10.
 Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)
    The Assigned Cookie AVP, Attribute Type 65, contains the Cookie
    value being assigned to this session by the sender.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Assigned Cookie (32 or 64 bits) ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Assigned Cookie is a 4-octet or 8-octet random value.
    The Assigned Cookie AVP contains the value used to check the
    association of a received data message with the session identified
    by the Session ID.  All data messages sent to a peer MUST use the
    Assigned Cookie sent by the peer in this AVP.  The value's length
    (0, 32, or 64 bits) is obtained by the length of the AVP.
    A missing Assigned Cookie AVP or Assigned Cookie Value of zero
    length indicates that the Cookie field should not be present in
    any data packets sent to the LCCE sending this AVP.
    See Section 4.1 for additional information about the Assigned
    Cookie.

Lau, et al. Standards Track [Page 50] RFC 3931 L2TPv3 March 2005

    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP may be 6, 10, or 14 octets.
 Serial Number (ICRQ, OCRQ)
    The Serial Number AVP, Attribute Type 15, contains an identifier
    assigned by the LAC or LNS to this session.
    The Attribute Value field for this AVP has the following format:
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Serial Number                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Serial Number is a 32-bit value.
    The Serial Number is intended to be an easy reference for
    administrators on both ends of a control connection to use when
    investigating session failure problems.  Serial Numbers should be
    set to progressively increasing values, which are likely to be
    unique for a significant period of time across all interconnected
    LNSs and LACs.
    Note that in RFC 2661, this value was referred to as the "Call
    Serial Number AVP".  It serves the same purpose and has the same
    attribute value and composition.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 10.
 Remote End ID (ICRQ, OCRQ)
    The Remote End ID AVP, Attribute Type 66, contains an identifier
    used to bind L2TP sessions to a given circuit, interface, or
    bridging instance.  It also may be used to detect session-level
    ties.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Remote End Identifier ... (arbitrary number of octets)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lau, et al. Standards Track [Page 51] RFC 3931 L2TPv3 March 2005

    The Remote End Identifier field is a variable-length field whose
    value is unique for a given LCCE peer, as described in Section
    3.3.
    A session-level tie is detected if an LCCE receives an ICRQ or
    OCRQ with an End ID AVP whose value matches that which was just
    sent in an outgoing ICRQ or OCRQ to the same peer.  If the two
    values match, an LCCE recognizes that a tie exists (i.e., both
    LCCEs are attempting to establish sessions for the same circuit).
    The tie is broken by the Session Tie Breaker AVP.
    By default, the LAC-LAC cross-connect application (see Section
    2(b)) of L2TP over an IP network MUST utilize the Router ID AVP
    and Remote End ID AVP to associate a circuit to an L2TP session.
    Other AVPs MAY be used for LCCE or circuit identification as
    specified in companion documents.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 6 plus the length of the
    Remote End Identifier value.
 Session Tie Breaker (ICRQ, OCRQ)
    The Session Tie Breaker AVP, Attribute Type 5, is used to break
    ties when two peers concurrently attempt to establish a session
    for the same circuit.
    The Attribute Value field for this AVP has the following format:
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Session Tie Breaker Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                               ... (64 bits)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Session Tie Breaker Value is an 8-octet random value that is
    used to choose a session when two LCCEs concurrently request a
    session for the same circuit.  A tie is detected by examining the
    peer's identity (described in Section 3.3) plus the per-session
    shared value communicated via the End ID AVP.  In the case of a
    tie, the recipient of an ICRQ or OCRQ must compare the received
    tie breaker value with the one that it sent earlier.  The LCCE
    with the lower value "wins" and MUST send a CDN with result code
    set to 13 (as defined in Section 5.4.2) in response to the losing
    ICRQ or OCRQ.  In the case in which a tie is detected, tie

Lau, et al. Standards Track [Page 52] RFC 3931 L2TPv3 March 2005

    breakers are sent by both sides, and the tie breaker values are
    equal, both sides MUST discard their sessions and restart session
    negotiation with new random tie breaker values.
    If a tie is detected but only one side sends a Session Tie Breaker
    AVP, the session initiator that included the Session Tie Breaker
    AVP "wins".  If neither side issues a tie breaker, then both sides
    MUST tear down the session.
    This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length of this AVP is 14.
 Pseudowire Type (ICRQ, OCRQ)
    The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates
    the L2 payload type of the packets that will be tunneled using
    this L2TP session.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           PW Type             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A peer MUST NOT request an incoming or outgoing call with a PW
    Type AVP specifying a value not advertised in the PW Capabilities
    List AVP it received during control connection establishment.
    Attempts to do so MUST result in the call being rejected via a CDN
    with the Result Code set to 14 (see Section 5.4.2).
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 8.
 L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
    The L2-Specific Sublayer AVP, Attribute Type 69, indicates the
    presence and format of the L2-Specific Sublayer the sender of this
    AVP requires on all incoming data packets for this L2TP session.
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   L2-Specific Sublayer Type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lau, et al. Standards Track [Page 53] RFC 3931 L2TPv3 March 2005

    The L2-Specific Sublayer Type is a 2-octet unsigned integer with
    the following values defined in this document:
       0 - There is no L2-Specific Sublayer present.
       1 - The Default L2-Specific Sublayer (defined in Section 4.6)
           is used.
    If this AVP is received and has a value other than zero, the
    receiving LCCE MUST include the identified L2-Specific Sublayer in
    its outgoing data messages.  If the AVP is not received, it is
    assumed that there is no sublayer present.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 8.
 Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
    The Data Sequencing AVP, Attribute Type 70, indicates that the
    sender requires some or all of the data packets that it receives
    to be sequenced.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Data Sequencing Level     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Data Sequencing Level is a 2-octet unsigned integer indicating
    the degree of incoming data traffic that the sender of this AVP
    wishes to be marked with sequence numbers.
    Defined Data Sequencing Levels are as follows:
       0 - No incoming data packets require sequencing.
       1 - Only non-IP data packets require sequencing.
       2 - All incoming data packets require sequencing.
    If a Data Sequencing Level of 0 is specified, there is no need to
    send packets with sequence numbers.  If sequence numbers are sent,
    they will be ignored upon receipt.  If no Data Sequencing AVP is
    received, a Data Sequencing Level of 0 is assumed.
    If a Data Sequencing Level of 1 is specified, only non-IP traffic
    carried within the tunneled L2 frame should have sequence numbers
    applied.  Non-IP traffic here refers to any packets that cannot be

Lau, et al. Standards Track [Page 54] RFC 3931 L2TPv3 March 2005

    classified as an IP packet within their respective L2 framing
    (e.g., a PPP control packet or NETBIOS frame encapsulated by Frame
    Relay before being tunneled).  All traffic that can be classified
    as IP MUST be sent with no sequencing (i.e., the S bit in the L2-
    Specific Sublayer is set to zero).  If a packet is unable to be
    classified at all (e.g., because it has been compressed or
    encrypted at layer 2) or if an implementation is unable to perform
    such classification within L2 frames, all packets MUST be provided
    with sequence numbers (essentially falling back to a Data
    Sequencing Level of 2).
    If a Data Sequencing Level of 2 is specified, all traffic MUST be
    sequenced.
    Data sequencing may only be requested when there is an L2-Specific
    Sublayer present that can provide sequence numbers.  If sequencing
    is requested without requesting a L2-Specific Sublayer AVP, the
    session MUST be disconnected with a Result Code of 15 (see Section
    5.4.2).
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 8.
 Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
    The Tx Connect Speed BPS AVP, Attribute Type 74, contains the
    speed of the facility chosen for the connection attempt.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Connect Speed in bps...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ...Connect Speed in bps (64 bits)             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The Tx Connect Speed BPS is an 8-octet value indicating the speed
    in bits per second.  A value of zero indicates that the speed is
    indeterminable or that there is no physical point-to-point link.
    When the optional Rx Connect Speed AVP is present, the value in
    this AVP represents the transmit connect speed from the
    perspective of the LAC (i.e., data flowing from the LAC to the
    remote system).  When the optional Rx Connect Speed AVP is NOT
    present, the connection speed between the remote system and LAC is

Lau, et al. Standards Track [Page 55] RFC 3931 L2TPv3 March 2005

    assumed to be symmetric and is represented by the single value in
    this AVP.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 14.
 Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
    The Rx Connect Speed AVP, Attribute Type 75, represents the speed
    of the connection from the perspective of the LAC (i.e., data
    flowing from the remote system to the LAC).
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Connect Speed in bps...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ...Connect Speed in bps (64 bits)             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Connect Speed BPS is an 8-octet value indicating the speed in bits
    per second.  A value of zero indicates that the speed is
    indeterminable or that there is no physical point-to-point link.
    Presence of this AVP implies that the connection speed may be
    asymmetric with respect to the transmit connect speed given in the
    Tx Connect Speed AVP.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 14.
 Physical Channel ID (ICRQ, ICRP, OCRP)
    The Physical Channel ID AVP, Attribute Type 25, contains the
    vendor-specific physical channel number used for a call.
    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Physical Channel ID                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lau, et al. Standards Track [Page 56] RFC 3931 L2TPv3 March 2005

    Physical Channel ID is a 4-octet value intended to be used for
    logging purposes only.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 10.

5.4.5. Circuit Status AVPs

 Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)
    The Circuit Status AVP, Attribute Type 71, indicates the initial
    status of or a status change in the circuit to which the session
    is bound.
    The Attribute Value field for this AVP has the following format:
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Reserved          |N|A|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The A (Active) bit indicates whether the circuit is
    up/active/ready (1) or down/inactive/not-ready (0).
    The N (New) bit indicates whether the circuit status indication is
    for a new circuit (1) or an existing circuit (0).  Links that have
    a similar mechanism available (e.g., Frame Relay) MUST map the
    setting of this bit to the associated signaling for that link.
    Otherwise, the New bit SHOULD still be set the first time the L2TP
    session is established after provisioning.
    The remaining bits are reserved for future use.  Reserved bits
    MUST be set to 0 when sending and ignored upon receipt.
    The Circuit Status AVP is used to advertise whether a circuit or
    interface bound to an L2TP session is up and ready to send and/or
    receive traffic.  Different circuit types have different names for
    status types.  For example, HDLC primary and secondary stations
    refer to a circuit as being "Receive Ready" or "Receive Not
    Ready", while Frame Relay refers to a circuit as "Active" or
    "Inactive".  This AVP adopts the latter terminology, though the
    concept remains the same regardless of the PW type for the L2TP
    session.

Lau, et al. Standards Track [Page 57] RFC 3931 L2TPv3 March 2005

    In the simplest case, the circuit to which this AVP refers is a
    single physical interface, port, or circuit, depending on the
    application and the session setup.  The status indication in this
    AVP may then be used to provide simple ILMI interworking for a
    variety of circuit types.  For virtual or multipoint interfaces,
    the Circuit Status AVP is still utilized, but in this case, it
    refers to the state of an internal structure or a logical set of
    circuits.  Each PW-specific companion document MUST specify
    precisely how this AVP is translated for each circuit type.
    If this AVP is received with a Not Active notification for a given
    L2TP session, all data traffic for that session MUST cease (or not
    begin) in the direction of the sender of the Circuit Status AVP
    until the circuit is advertised as Active.
    The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP,
    OCRQ, and OCRP messages.  Often, the circuit type will be marked
    Active when initiated, but subsequently MAY be advertised as
    Inactive.  This indicates that an L2TP session is to be created,
    but that the interface or circuit is still not ready to pass
    traffic.  The ICCN, OCCN, and SLI control messages all MAY contain
    this AVP to update the status of the circuit after establishment
    of the L2TP session is requested.
    If additional circuit status information is needed for a given PW
    type, any new PW-specific AVPs MUST be defined in a separate
    document.  This AVP is only for general circuit status information
    generally applicable to all circuit/interface types.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 8.
 Circuit Errors (WEN)
    The Circuit Errors AVP, Attribute Type 34, conveys circuit error
    information to the peer.

Lau, et al. Standards Track [Page 58] RFC 3931 L2TPv3 March 2005

    The Attribute Value field for this AVP has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                                   |             Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Hardware Overruns                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Buffer Overruns                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Timeout Errors                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Alignment Errors                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The following fields are defined:
    Reserved: 2 octets of Reserved data is present (providing longword
       alignment within the AVP of the following values).  Reserved
       data MUST be zero on sending and ignored upon receipt.
    Hardware Overruns: Number of receive buffer overruns since call
       was established.
    Buffer Overruns: Number of buffer overruns detected since call was
       established.
    Timeout Errors: Number of timeouts since call was established.
    Alignment Errors: Number of alignment errors since call was
       established.
    This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
    this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
    Length (before hiding) of this AVP is 32.

6. Control Connection Protocol Specification

 The following control messages are used to establish, maintain, and
 tear down L2TP control connections.  All data packets are sent in
 network order (high-order octets first).  Any "reserved" or "empty"
 fields MUST be sent as 0 values to allow for protocol extensibility.
 The exchanges in which these messages are involved are outlined in
 Section 3.3.

Lau, et al. Standards Track [Page 59] RFC 3931 L2TPv3 March 2005

6.1. Start-Control-Connection-Request (SCCRQ)

 Start-Control-Connection-Request (SCCRQ) is a control message used to
 initiate a control connection between two LCCEs.  It is sent by
 either the LAC or the LNS to begin the control connection
 establishment process.
 The following AVPs MUST be present in the SCCRQ:
    Message Type
    Host Name
    Router ID
    Assigned Control Connection ID
    Pseudowire Capabilities List
 The following AVPs MAY be present in the SCCRQ:
    Random Vector
    Control Message Authentication Nonce
    Message Digest
    Control Connection Tie Breaker
    Vendor Name
    Receive Window Size
    Preferred Language

6.2. Start-Control-Connection-Reply (SCCRP)

 Start-Control-Connection-Reply (SCCRP) is the control message sent in
 reply to a received SCCRQ message.  The SCCRP is used to indicate
 that the SCCRQ was accepted and that establishment of the control
 connection should continue.
 The following AVPs MUST be present in the SCCRP:
    Message Type
    Host Name
    Router ID
    Assigned Control Connection ID
    Pseudowire Capabilities List
 The following AVPs MAY be present in the SCCRP:
    Random Vector
    Control Message Authentication Nonce
    Message Digest
    Vendor Name
    Receive Window Size
    Preferred Language

Lau, et al. Standards Track [Page 60] RFC 3931 L2TPv3 March 2005

6.3. Start-Control-Connection-Connected (SCCCN)

 Start-Control-Connection-Connected (SCCCN) is the control message
 sent in reply to an SCCRP.  The SCCCN completes the control
 connection establishment process.
 The following AVP MUST be present in the SCCCN:
    Message Type
 The following AVP MAY be present in the SCCCN:
    Random Vector
    Message Digest

6.4. Stop-Control-Connection-Notification (StopCCN)

 Stop-Control-Connection-Notification (StopCCN) is the control message
 sent by either LCCE to inform its peer that the control connection is
 being shut down and that the control connection should be closed.  In
 addition, all active sessions are implicitly cleared (without sending
 any explicit session control messages).  The reason for issuing this
 request is indicated in the Result Code AVP.  There is no explicit
 reply to the message, only the implicit ACK that is received by the
 reliable control message delivery layer.
 The following AVPs MUST be present in the StopCCN:
    Message Type
    Result Code
 The following AVPs MAY be present in the StopCCN:
    Random Vector
    Message Digest
    Assigned Control Connection ID
 Note that the Assigned Control Connection ID MUST be present if the
 StopCCN is sent after an SCCRQ or SCCRP message has been sent.

6.5. Hello (HELLO)

 The Hello (HELLO) message is an L2TP control message sent by either
 peer of a control connection.  This control message is used as a
 "keepalive" for the control connection.  See Section 4.2 for a
 description of the keepalive mechanism.

Lau, et al. Standards Track [Page 61] RFC 3931 L2TPv3 March 2005

 HELLO messages are global to the control connection.  The Session ID
 in a HELLO message MUST be 0.
 The following AVP MUST be present in the HELLO:
    Message Type
 The following AVP MAY be present in the HELLO:
    Random Vector
    Message Digest

6.6. Incoming-Call-Request (ICRQ)

 Incoming-Call-Request (ICRQ) is the control message sent by an LCCE
 to a peer when an incoming call is detected (although the ICRQ may
 also be sent as a result of a local event).  It is the first in a
 three-message exchange used for establishing a session via an L2TP
 control connection.
 The ICRQ is used to indicate that a session is to be established
 between an LCCE and a peer.  The sender of an ICRQ provides the peer
 with parameter information for the session.  However, the sender
 makes no demands about how the session is terminated at the peer
 (i.e., whether the L2 traffic is processed locally, forwarded, etc.).
 The following AVPs MUST be present in the ICRQ:
    Message Type
    Local Session ID
    Remote Session ID
    Serial Number
    Pseudowire Type
    Remote End ID
    Circuit Status
 The following AVPs MAY be present in the ICRQ:
    Random Vector
    Message Digest
    Assigned Cookie
    Session Tie Breaker
    L2-Specific Sublayer
    Data Sequencing
    Tx Connect Speed
    Rx Connect Speed
    Physical Channel ID

Lau, et al. Standards Track [Page 62] RFC 3931 L2TPv3 March 2005

6.7. Incoming-Call-Reply (ICRP)

 Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in
 response to a received ICRQ.  It is the second in the three-message
 exchange used for establishing sessions within an L2TP control
 connection.
 The ICRP is used to indicate that the ICRQ was successful and that
 the peer should establish (i.e., answer) the incoming call if it has
 not already done so.  It also allows the sender to indicate specific
 parameters about the L2TP session.
 The following AVPs MUST be present in the ICRP:
    Message Type
    Local Session ID
    Remote Session ID
    Circuit Status
 The following AVPs MAY be present in the ICRP:
    Random Vector
    Message Digest
    Assigned Cookie
    L2-Specific Sublayer
    Data Sequencing
    Tx Connect Speed
    Rx Connect Speed
    Physical Channel ID

6.8. Incoming-Call-Connected (ICCN)

 Incoming-Call-Connected (ICCN) is the control message sent by the
 LCCE that originally sent an ICRQ upon receiving an ICRP from its
 peer.  It is the final message in the three-message exchange used for
 establishing L2TP sessions.
 The ICCN is used to indicate that the ICRP was accepted, that the
 call has been established, and that the L2TP session should move to
 the established state.  It also allows the sender to indicate
 specific parameters about the established call (parameters that may
 not have been available at the time the ICRQ was issued).
 The following AVPs MUST be present in the ICCN:
    Message Type
    Local Session ID
    Remote Session ID

Lau, et al. Standards Track [Page 63] RFC 3931 L2TPv3 March 2005

 The following AVPs MAY be present in the ICCN:
    Random Vector
    Message Digest
    L2-Specific Sublayer
    Data Sequencing
    Tx Connect Speed
    Rx Connect Speed
    Circuit Status

6.9. Outgoing-Call-Request (OCRQ)

 Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE
 to an LAC to indicate that an outbound call at the LAC is to be
 established based on specific destination information sent in this
 message.  It is the first in a three-message exchange used for
 establishing a session and placing a call on behalf of the initiating
 LCCE.
 Note that a call may be any L2 connection requiring well-known
 destination information to be sent from an LCCE to an LAC.  This call
 could be a dialup connection to the PSTN, an SVC connection, the IP
 address of another LCCE, or any other destination dictated by the
 sender of this message.
 The following AVPs MUST be present in the OCRQ:
    Message Type
    Local Session ID
    Remote Session ID
    Serial Number
    Pseudowire Type
    Remote End ID
    Circuit Status
 The following AVPs MAY be present in the OCRQ:
    Random Vector
    Message Digest
    Assigned Cookie
    Tx Connect Speed
    Rx Connect Speed
    Session Tie Breaker
    L2-Specific Sublayer
    Data Sequencing

Lau, et al. Standards Track [Page 64] RFC 3931 L2TPv3 March 2005

6.10. Outgoing-Call-Reply (OCRP)

 Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to
 an LCCE in response to a received OCRQ.  It is the second in a
 three-message exchange used for establishing a session within an L2TP
 control connection.
 OCRP is used to indicate that the LAC has been able to attempt the
 outbound call.  The message returns any relevant parameters regarding
 the call attempt.  Data MUST NOT be forwarded until the OCCN is
 received, which indicates that the call has been placed.
 The following AVPs MUST be present in the OCRP:
    Message Type
    Local Session ID
    Remote Session ID
    Circuit Status
 The following AVPs MAY be present in the OCRP:
    Random Vector
    Message Digest
    Assigned Cookie
    L2-Specific Sublayer
    Tx Connect Speed
    Rx Connect Speed
    Data Sequencing
    Physical Channel ID

6.11. Outgoing-Call-Connected (OCCN)

 Outgoing-Call-Connected (OCCN) is the control message sent by an LAC
 to another LCCE after the OCRP and after the outgoing call has been
 completed.  It is the final message in a three-message exchange used
 for establishing a session.
 OCCN is used to indicate that the result of a requested outgoing call
 was successful.  It also provides information to the LCCE who
 requested the call about the particular parameters obtained after the
 call was established.
 The following AVPs MUST be present in the OCCN:
    Message Type
    Local Session ID
    Remote Session ID

Lau, et al. Standards Track [Page 65] RFC 3931 L2TPv3 March 2005

 The following AVPs MAY be present in the OCCN:
    Random Vector
    Message Digest
    L2-Specific Sublayer
    Tx Connect Speed
    Rx Connect Speed
    Data Sequencing
    Circuit Status

6.12. Call-Disconnect-Notify (CDN)

 The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE
 to request disconnection of a specific session.  Its purpose is to
 inform the peer of the disconnection and the reason for the
 disconnection.  The peer MUST clean up any resources, and does not
 send back any indication of success or failure for such cleanup.
 The following AVPs MUST be present in the CDN:
    Message Type
    Result Code
    Local Session ID
    Remote Session ID
 The following AVP MAY be present in the CDN:
    Random Vector
    Message Digest

6.13. WAN-Error-Notify (WEN)

 The WAN-Error-Notify (WEN) is a control message sent from an LAC to
 an LNS to indicate WAN error conditions.  The counters in this
 message are cumulative.  This message should only be sent when an
 error occurs, and not more than once every 60 seconds.  The counters
 are reset when a new call is established.
 The following AVPs MUST be present in the WEN:
    Message Type
    Local Session ID
    Remote Session ID
    Circuit Errors

Lau, et al. Standards Track [Page 66] RFC 3931 L2TPv3 March 2005

 The following AVP MAY be present in the WEN:
    Random Vector
    Message Digest

6.14. Set-Link-Info (SLI)

 The Set-Link-Info control message is sent by an LCCE to convey link
 or circuit status change information regarding the circuit associated
 with this L2TP session.  For example, if PPP renegotiates LCP at an
 LNS or between an LAC and a Remote System, or if a forwarded Frame
 Relay VC transitions to Active or Inactive at an LAC, an SLI message
 SHOULD be sent to indicate this event.  Precise details of when the
 SLI is sent, what PW type-specific AVPs must be present, and how
 those AVPs should be interpreted by the receiving peer are outside
 the scope of this document.  These details should be described in the
 associated pseudowire-specific documents that require use of this
 message.
 The following AVPs MUST be present in the SLI:
    Message Type
    Local Session ID
    Remote Session ID
 The following AVPs MAY be present in the SLI:
    Random Vector
    Message Digest
    Circuit Status

6.15. Explicit-Acknowledgement (ACK)

 The Explicit Acknowledgement (ACK) message is used only to
 acknowledge receipt of a message or messages on the control
 connection (e.g., for purposes of updating Ns and Nr values).
 Receipt of this message does not trigger an event for the L2TP
 protocol state machine.
 A message received without any AVPs (including the Message Type AVP),
 is referred to as a Zero Length Body (ZLB) message, and serves the
 same function as the Explicit Acknowledgement.  ZLB messages are only
 permitted when Control Message Authentication defined in Section 4.3
 is not enabled.

Lau, et al. Standards Track [Page 67] RFC 3931 L2TPv3 March 2005

 The following AVPs MAY be present in the ACK message:
    Message Type
    Message Digest

7. Control Connection State Machines

 The state tables defined in this section govern the exchange of
 control messages defined in Section 6.  Tables are defined for
 incoming call placement and outgoing call placement, as well as for
 initiation of the control connection itself.  The state tables do not
 encode timeout and retransmission behavior, as this is handled in the
 underlying reliable control message delivery mechanism (see Section
 4.2).

7.1. Malformed AVPs and Control Messages

 Receipt of an invalid or unrecoverable malformed control message
 SHOULD be logged appropriately and the control connection cleared to
 ensure recovery to a known state.  The control connection may then be
 restarted by the initiator.
 An invalid control message is defined as (1) a message that contains
 a Message Type marked as mandatory (see Section 5.4.1) but that is
 unknown to the implementation, or (2) a control message that is
 received in the wrong state.
 Examples of malformed control messages include (1) a message that has
 an invalid value in its header, (2) a message that contains an AVP
 that is formatted incorrectly or whose value is out of range, and (3)
 a message that is missing a required AVP.  A control message with a
 malformed header MUST be discarded.
 When possible, a malformed AVP should be treated as an unrecognized
 AVP (see Section 5.2).  Thus, an attempt to inspect the M bit SHOULD
 be made to determine the importance of the malformed AVP, and thus,
 the severity of the malformation to the entire control message.  If
 the M bit can be reasonably inspected within the malformed AVP and is
 determined to be set, then as with an unrecognized AVP, the
 associated session or control connection MUST be shut down.  If the M
 bit is inspected and is found to be 0, the AVP MUST be ignored
 (assuming recovery from the AVP malformation is indeed possible).
 This policy must not be considered as a license to send malformed
 AVPs, but rather, as a guide towards how to handle an improperly
 formatted message if one is received.  It is impossible to list all
 potential malformations of a given message and give advice for each.
 One example of a malformed AVP situation that should be recoverable

Lau, et al. Standards Track [Page 68] RFC 3931 L2TPv3 March 2005

 is if the Rx Connect Speed AVP is received with a length of 10 rather
 than 14, implying that the connect speed bits-per-second is being
 formatted in 4 octets rather than 8.  If the AVP does not have its M
 bit set (as would typically be the case), this condition is not
 considered catastrophic.  As such, the control message should be
 accepted as though the AVP were not present (though a local error
 message may be logged).
 In several cases in the following tables, a protocol message is sent,
 and then a "clean up" occurs.  Note that, regardless of the initiator
 of the control connection destruction, the reliable delivery
 mechanism must be allowed to run (see Section 4.2) before destroying
 the control connection.  This permits the control connection
 management messages to be reliably delivered to the peer.
 Appendix B.1 contains an example of lock-step control connection
 establishment.

7.2. Control Connection States

 The L2TP control connection protocol is not distinguishable between
 the two LCCEs but is distinguishable between the originator and
 receiver.  The originating peer is the one that first initiates
 establishment of the control connection.  (In a tie breaker
 situation, this is the winner of the tie.)  Since either the LAC or
 the LNS can be the originator, a collision can occur.  See the
 Control Connection Tie Breaker AVP in Section 5.4.3 for a description
 of this and its resolution.
 State           Event              Action              New State
 -----           -----              ------              ---------
 idle            Local open         Send SCCRQ          wait-ctl-reply
                 request
 idle            Receive SCCRQ,     Send SCCRP          wait-ctl-conn
                 acceptable
 idle            Receive SCCRQ,     Send StopCCN,       idle
                 not acceptable     clean up
 idle            Receive SCCRP      Send StopCCN,       idle
                                    clean up
 idle            Receive SCCCN      Send StopCCN,       idle
                                    clean up

Lau, et al. Standards Track [Page 69] RFC 3931 L2TPv3 March 2005

 wait-ctl-reply  Receive SCCRP,     Send SCCCN,         established
                 acceptable         send control-conn
                                    open event to
                                    waiting sessions
 wait-ctl-reply  Receive SCCRP,     Send StopCCN,       idle
                 not acceptable     clean up
 wait-ctl-reply  Receive SCCRQ,     Send SCCRP,         wait-ctl-conn
                 lose tie breaker,  Clean up losing
                 SCCRQ acceptable   connection
 wait-ctl-reply  Receive SCCRQ,     Send StopCCN,       idle
                 lose tie breaker,  Clean up losing
                 SCCRQ unacceptable connection
 wait-ctl-reply  Receive SCCRQ,     Send StopCCN for    wait-ctl-reply
                 win tie breaker    losing connection
 wait-ctl-reply  Receive SCCCN      Send StopCCN,       idle
                                    clean up
 wait-ctl-conn   Receive SCCCN,     Send control-conn   established
                 acceptable         open event to
                                    waiting sessions
 wait-ctl-conn   Receive SCCCN,     Send StopCCN,       idle
                 not acceptable     clean up
 wait-ctl-conn   Receive SCCRQ,     Send StopCCN,       idle
                 SCCRP              clean up
 established     Local open         Send control-conn   established
                 request            open event to
                 (new call)         waiting sessions
 established     Administrative     Send StopCCN,       idle
                 control-conn       clean up
                 close event
 established     Receive SCCRQ,     Send StopCCN,       idle
                 SCCRP, SCCCN       clean up
 idle,           Receive StopCCN    Clean up            idle
 wait-ctl-reply,
 wait-ctl-conn,
 established

Lau, et al. Standards Track [Page 70] RFC 3931 L2TPv3 March 2005

 The states associated with an LCCE for control connection
 establishment are as follows:
 idle
    Both initiator and recipient start from this state.  An initiator
    transmits an SCCRQ, while a recipient remains in the idle state
    until receiving an SCCRQ.
 wait-ctl-reply
    The originator checks to see if another connection has been
    requested from the same peer, and if so, handles the collision
    situation described in Section 5.4.3.
 wait-ctl-conn
    Awaiting an SCCCN.  If the SCCCN is valid, the control connection
    is established; otherwise, it is torn down (sending a StopCCN with
    the proper result and/or error code).
 established
    An established connection may be terminated by either a local
    condition or the receipt of a StopCCN.  In the event of a local
    termination, the originator MUST send a StopCCN and clean up the
    control connection.  If the originator receives a StopCCN, it MUST
    also clean up the control connection.

7.3. Incoming Calls

 An ICRQ is generated by an LCCE, typically in response to an incoming
 call or a local event.  Once the LCCE sends the ICRQ, it waits for a
 response from the peer.  However, it may choose to postpone
 establishment of the call (e.g., answering the call, bringing up the
 circuit) until the peer has indicated with an ICRP that it will
 accept the call.  The peer may choose not to accept the call if, for
 instance, there are insufficient resources to handle an additional
 session.
 If the peer chooses to accept the call, it responds with an ICRP.
 When the local LCCE receives the ICRP, it attempts to establish the
 call.  A final call connected message, the ICCN, is sent from the
 local LCCE to the peer to indicate that the call states for both
 LCCEs should enter the established state.  If the call is terminated
 before the peer can accept it, a CDN is sent by the local LCCE to
 indicate this condition.
 When a call transitions to a "disconnected" or "down" state, the call
 is cleared normally, and the local LCCE sends a CDN.  Similarly, if
 the peer wishes to clear a call, it sends a CDN and cleans up its
 session.

Lau, et al. Standards Track [Page 71] RFC 3931 L2TPv3 March 2005

7.3.1. ICRQ Sender States

 State           Event              Action           New State
 -----           -----              ------           ---------
 idle            Call signal or     Initiate local   wait-control-conn
                 ready to receive   control-conn
                 incoming conn      open
 idle            Receive ICCN,      Clean up         idle
                 ICRP, CDN
 wait-control-   Bearer line drop   Clean up         idle
 conn            or local close
                 request
 wait-control-   control-conn-open  Send ICRQ        wait-reply
 conn
 wait-reply      Receive ICRP,      Send ICCN        established
                 acceptable
 wait-reply      Receive ICRP,      Send CDN,        idle
                 Not acceptable     clean up
 wait-reply      Receive ICRQ,      Process as       idle
                 lose tie breaker   ICRQ Recipient
                                    (Section 7.3.2)
 wait-reply      Receive ICRQ,      Send CDN         wait-reply
                 win tie breaker    for losing
                                    session
 wait-reply      Receive CDN,       Clean up         idle
                 ICCN
 wait-reply      Local close        Send CDN,        idle
                 request            clean up
 established     Receive CDN        Clean up         idle
 established     Receive ICRQ,      Send CDN,        idle
                 ICRP, ICCN         clean up
 established     Local close        Send CDN,        idle
                 request            clean up

Lau, et al. Standards Track [Page 72] RFC 3931 L2TPv3 March 2005

 The states associated with the ICRQ sender are as follows:
 idle
    The LCCE detects an incoming call on one of its interfaces (e.g.,
    an analog PSTN line rings, or an ATM PVC is provisioned), or a
    local event occurs.  The LCCE initiates its control connection
    establishment state machine and moves to a state waiting for
    confirmation of the existence of a control connection.
 wait-control-conn
    In this state, the session is waiting for either the control
    connection to be opened or for verification that the control
    connection is already open.  Once an indication that the control
    connection has been opened is received, session control messages
    may be exchanged.  The first of these messages is the ICRQ.
 wait-reply
    The ICRQ sender receives either (1) a CDN indicating the peer is
    not willing to accept the call (general error or do not accept)
    and moves back into the idle state, or (2) an ICRP indicating the
    call is accepted.  In the latter case, the LCCE sends an ICCN and
    enters the established state.
 established
    Data is exchanged over the session.  The call may be cleared by
    any of the following:
       + An event on the connected interface: The LCCE sends a CDN.
       + Receipt of a CDN: The LCCE cleans up, disconnecting the call.
       + A local reason: The LCCE sends a CDN.

7.3.2. ICRQ Recipient States

 State           Event              Action            New State
 -----           -----              ------            ---------
 idle            Receive ICRQ,      Send ICRP         wait-connect
                 acceptable
 idle            Receive ICRQ,      Send CDN,         idle
                 not acceptable     clean up
 idle            Receive ICRP       Send CDN          idle
                                    clean up
 idle            Receive ICCN       Clean up          idle
 wait-connect    Receive ICCN,      Prepare for       established
                 acceptable         data

Lau, et al. Standards Track [Page 73] RFC 3931 L2TPv3 March 2005

 wait-connect    Receive ICCN,      Send CDN,         idle
                 not acceptable     clean up
 wait-connect    Receive ICRQ,      Send CDN,         idle
                 ICRP               clean up
 idle,           Receive CDN        Clean up          idle
 wait-connect,
 established
 wait-connect    Local close        Send CDN,         idle
 established     request            clean up
 established     Receive ICRQ,      Send CDN,         idle
                 ICRP, ICCN         clean up
 The states associated with the ICRQ recipient are as follows:
 idle
    An ICRQ is received.  If the request is not acceptable, a CDN is
    sent back to the peer LCCE, and the local LCCE remains in the idle
    state.  If the ICRQ is acceptable, an ICRP is sent.  The session
    moves to the wait-connect state.
 wait-connect
    The local LCCE is waiting for an ICCN from the peer.  Upon receipt
    of the ICCN, the local LCCE moves to established state.
 established
    The session is terminated either by sending a CDN or by receiving
    a CDN from the peer.  Clean up follows on both sides regardless of
    the initiator.

7.4. Outgoing Calls

 Outgoing calls instruct an LAC to place a call.  There are three
 messages for outgoing calls: OCRQ, OCRP, and OCCN.  An LCCE first
 sends an OCRQ to an LAC to request an outgoing call.  The LAC MUST
 respond to the OCRQ with an OCRP once it determines that the proper
 facilities exist to place the call and that the call is
 administratively authorized.  Once the outbound call is connected,
 the LAC sends an OCCN to the peer indicating the final result of the
 call attempt.

Lau, et al. Standards Track [Page 74] RFC 3931 L2TPv3 March 2005

7.4.1. OCRQ Sender States

 State          Event              Action            New State
 -----          -----              ------            ---------
 idle           Local open         Initiate local    wait-control-conn
                request            control-conn-open
 idle           Receive OCCN,      Clean up          idle
                OCRP
 wait-control-  control-conn-open  Send OCRQ         wait-reply
 conn
 wait-reply     Receive OCRP,      none              wait-connect
                acceptable
 wait-reply     Receive OCRP,      Send CDN,         idle
                not acceptable     clean up
 wait-reply     Receive OCCN       Send CDN,         idle
                                   clean up
 wait-reply     Receive OCRQ,      Process as        idle
                lose tie breaker   OCRQ Recipient
                                   (Section 7.4.2)
 wait-reply     Receive OCRQ,      Send CDN          wait-reply
                win tie breaker    for losing
                                   session
 wait-connect   Receive OCCN       none              established
 wait-connect   Receive OCRQ,      Send CDN,         idle
                OCRP               clean up
 idle,          Receive CDN        Clean up          idle
 wait-reply,
 wait-connect,
 established
 established    Receive OCRQ,      Send CDN,         idle
                OCRP, OCCN         clean up
 wait-reply,    Local close        Send CDN,         idle
 wait-connect,  request            clean up
 established

Lau, et al. Standards Track [Page 75] RFC 3931 L2TPv3 March 2005

 wait-control-  Local close        Clean up          idle
 conn           request
 The states associated with the OCRQ sender are as follows:
 idle, wait-control-conn
    When an outgoing call request is initiated, a control connection
    is created as described above, if not already present.  Once the
    control connection is established, an OCRQ is sent to the LAC, and
    the session moves into the wait-reply state.
 wait-reply
    If a CDN is received, the session is cleaned up and returns to
    idle state.  If an OCRP is received, the call is in progress, and
    the session moves to the wait-connect state.
 wait-connect
    If a CDN is received, the session is cleaned up and returns to
    idle state.  If an OCCN is received, the call has succeeded, and
    the session may now exchange data.
 established
    If a CDN is received, the session is cleaned up and returns to
    idle state.  Alternatively, if the LCCE chooses to terminate the
    session, it sends a CDN to the LAC, cleans up the session, and
    moves the session to idle state.

7.4.2. OCRQ Recipient (LAC) States

 State           Event              Action            New State
 -----           -----              ------            ---------
 idle            Receive OCRQ,      Send OCRP,        wait-cs-answer
                 acceptable         Place call
 idle            Receive OCRQ,      Send CDN,         idle
                 not acceptable     clean up
 idle            Receive OCRP       Send CDN,         idle
                                    clean up
 idle            Receive OCCN,      Clean up          idle
                 CDN
 wait-cs-answer  Call placement     Send OCCN         established
                 successful
 wait-cs-answer  Call placement     Send CDN,         idle
                 failed             clean up

Lau, et al. Standards Track [Page 76] RFC 3931 L2TPv3 March 2005

 wait-cs-answer  Receive OCRQ,      Send CDN,         idle
                 OCRP, OCCN         clean up
 established     Receive OCRQ,      Send CDN,         idle
                 OCRP, OCCN         clean up
 wait-cs-answer, Receive CDN        Clean up          idle
 established
 wait-cs-answer, Local close        Send CDN,         idle
 established     request            clean up
 The states associated with the LAC for outgoing calls are as follows:
 idle
    If the OCRQ is received in error, respond with a CDN.  Otherwise,
    place the call, send an OCRP, and move to the wait-cs-answer
    state.
 wait-cs-answer
    If the call is not completed or a timer expires while waiting for
    the call to complete, send a CDN with the appropriate error
    condition set, and go to idle state.  If a circuit-switched
    connection is established, send an OCCN indicating success, and go
    to established state.
 established
    If the LAC receives a CDN from the peer, the call MUST be released
    via appropriate mechanisms, and the session cleaned up.  If the
    call is disconnected because the circuit transitions to a
    "disconnected" or "down" state, the LAC MUST send a CDN to the
    peer and return to idle state.

7.5. Termination of a Control Connection

 The termination of a control connection consists of either peer
 issuing a StopCCN.  The sender of this message SHOULD wait a full
 control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ...
 seconds) for the acknowledgment of this message before releasing the
 control information associated with the control connection.  The
 recipient of this message should send an acknowledgment of the
 message to the peer, then release the associated control information.
 When to release a control connection is an implementation issue and
 is not specified in this document.  A particular implementation may
 use whatever policy is appropriate for determining when to release a
 control connection.  Some implementations may leave a control
 connection open for a period of time or perhaps indefinitely after

Lau, et al. Standards Track [Page 77] RFC 3931 L2TPv3 March 2005

 the last session for that control connection is cleared.  Others may
 choose to disconnect the control connection immediately after the
 last call on the control connection disconnects.

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.

Lau, et al. Standards Track [Page 78] RFC 3931 L2TPv3 March 2005

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

Lau, et al. Standards Track [Page 79] RFC 3931 L2TPv3 March 2005

 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

Lau, et al. Standards Track [Page 80] RFC 3931 L2TPv3 March 2005

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.

Lau, et al. Standards Track [Page 81] RFC 3931 L2TPv3 March 2005

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

Lau, et al. Standards Track [Page 82] RFC 3931 L2TPv3 March 2005

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)

Lau, et al. Standards Track [Page 83] RFC 3931 L2TPv3 March 2005

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.

Lau, et al. Standards Track [Page 84] RFC 3931 L2TPv3 March 2005

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.

Lau, et al. Standards Track [Page 85] RFC 3931 L2TPv3 March 2005

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

Lau, et al. Standards Track [Page 86] RFC 3931 L2TPv3 March 2005

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

Lau, et al. Standards Track [Page 87] RFC 3931 L2TPv3 March 2005

 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.

Lau, et al. Standards Track [Page 88] RFC 3931 L2TPv3 March 2005

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.

Lau, et al. Standards Track [Page 89] RFC 3931 L2TPv3 March 2005

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

Lau, et al. Standards Track [Page 90] RFC 3931 L2TPv3 March 2005

    (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).

Lau, et al. Standards Track [Page 91] RFC 3931 L2TPv3 March 2005

 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
 follows:

Lau, et al. Standards Track [Page 92] RFC 3931 L2TPv3 March 2005

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

Editors' Addresses

 Jed Lau
 cisco Systems
 170 W. Tasman Drive
 San Jose, CA  95134
 EMail: jedlau@cisco.com
 W. Mark Townsley
 cisco Systems
 EMail: mark@townsley.net
 Ignacio Goyret
 Lucent Technologies
 EMail: igoyret@lucent.com

Lau, et al. Standards Track [Page 93] RFC 3931 L2TPv3 March 2005

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
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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
 http://www.ietf.org/ipr.
 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-
 ipr@ietf.org.

Acknowledgement

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

Lau, et al. Standards Track [Page 94]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3931.txt · Last modified: 2005/03/04 00:35 (external edit)