5268 lines
209 KiB
Plaintext
5268 lines
209 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|