started work on L2TPv2 server

25 files changed, 11609 insertions, 66 deletions

diff --git a/accel-pptpd/accel-pptp.conf b/accel-pptpd/accel-pptp.conf
index 8ca7c61..bf8cdd4 100644
--- a/accel-pptpd/accel-pptp.conf
+++ b/accel-pptpd/accel-pptp.conf
@@ -2,8 +2,9 @@
 #path=/usr/local/lib/accel-pptp
 log_file
 #log_pgsql
-pptp
+#pptp
 #pppoe
+l2tp
 auth_pap
 auth_chap_md5
 auth_mschap_v1
@@ -31,6 +32,9 @@ echo-failure=3
 echo-interval=30
 verbose=1
 
+[ltp]
+#dictionary=/usr/local/share/accel-pptp/dictionary
+
 [pppoe]
 interface=eth0
 verbose=1
diff --git a/accel-pptpd/ctrl/CMakeLists.txt b/accel-pptpd/ctrl/CMakeLists.txt
index d63a825..fa7acdc 100644
--- a/accel-pptpd/ctrl/CMakeLists.txt
+++ b/accel-pptpd/ctrl/CMakeLists.txt
@@ -1,9 +1,3 @@
-INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
-
-ADD_LIBRARY(pptp SHARED pptp.c)
-ADD_LIBRARY(pppoe SHARED pppoe.c)
-
-INSTALL(TARGETS pptp pppoe
-	LIBRARY DESTINATION usr/lib/accel-pptp
-)
-
+ADD_SUBDIRECTORY(pptp)
+ADD_SUBDIRECTORY(pppoe)
+#ADD_SUBDIRECTORY(l2tp)
diff --git a/accel-pptpd/ctrl/l2tp/CMakeLists.txt b/accel-pptpd/ctrl/l2tp/CMakeLists.txt
new file mode 100644
index 0000000..8a64d5f
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/CMakeLists.txt
@@ -0,0 +1,11 @@
+INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
+
+ADD_DEFINITIONS(-DDICTIONARY="${CMAKE_INSTALL_PREFIX}/usr/share/accel-pptp/l2tp/dictionary")
+
+ADD_LIBRARY(l2tp SHARED
+	l2tp.c
+	dict.c
+	packet.c
+)
+
+INSTALL(TARGETS l2tp LIBRARY DESTINATION usr/lib/accel-pptp)
diff --git a/accel-pptpd/ctrl/l2tp/attr_defs.h b/accel-pptpd/ctrl/l2tp/attr_defs.h
new file mode 100644
index 0000000..e799157
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/attr_defs.h
@@ -0,0 +1,73 @@
+#ifndef __ATTR_DEFS_H
+#define __ATTR_DEFS_H
+
+#define Message_Type 0
+#define Random_Vector 36
+#define Result_Code 1
+#define Protocol_Version 2
+#define Framing_Capabilities 3
+#define Bearer_Capabilities 4
+#define Tie_Breaker 5
+#define Firmware_Revision 6
+#define Host_Name 7
+#define Vendor_Name 8
+#define Assigned_Tunnel_ID 9
+#define Recv_Window_Size 10
+#define Challenge 11
+#define Challenge_Response 13
+#define Cause_Code 12
+#define Assigned_Session_ID 14
+#define Call_Serial_Number 15
+#define Minimum_BPS 16
+#define Maximum_BPS 17
+#define Bearer_Type 18
+#define Framing_Type 19
+#define Called_Number 21
+#define Calling_Number 22
+#define Sub_Address 23
+#define TX_Speed 24
+#define RX_Speed 38
+#define Physical_Channel_ID 25
+#define Private_Group_ID 37
+#define Sequencing_Required 39
+#define Init_Recv_LCP 26
+#define Last_Sent_LCP 27
+#define Last_Recv_LCP 28
+#define Proxy_Authen_Type 29
+#define Proxy_Authen_Name 30
+#define Proxy_Authen_Challenge 31
+#define Proxy_Authen_ID 32
+#define Proxy_Authen_Response 33
+#define Call_Errors 34
+#define ACCM 35
+#define Message_Type_Start_Ctrl_Conn_Request 1
+#define Message_Type_Start_Ctrl_Conn_Reply 2
+#define Message_Type_Start_Ctrl_Conn_Connected 3
+#define Message_Type_Stop_Ctrl_Conn_Notify 4
+#define Message_Type_Hello 6
+#define Message_Type_Outgoing_Call_Request 7
+#define Message_Type_Outgoing_Call_Reply 8
+#define Message_Type_Outgoing_Call_Connected 9
+#define Message_Type_Incoming_Call_Request 10
+#define Message_Type_Incoming_Call_Reply 11
+#define Message_Type_Incoming_Call_Connected 12
+#define Message_Type_Call_Disconnect_Notify 14
+#define Message_Type_WAN_Error_Notify 15
+#define Message_Type_Set_Link_Info 16
+#define Message_Digest 59
+#define Router_ID 60
+#define Assigned_Connection_ID 61
+#define Pseudowire_Capabilities 62
+#define Prefered_Language 72
+#define Local_Session_ID 63
+#define Remote_Session_ID 64
+#define Assigned_Cookie 65
+#define Remote_End_ID 66
+#define Pseudowire_Type 68
+#define L2_Specific_Sublayer 69
+#define Data_Sequencing 70
+#define TX_Connect_Speeed 74
+#define RX_Connect_Speeed 75
+#define Circuit_Status 71
+
+#endif
diff --git a/accel-pptpd/ctrl/l2tp/dict.c b/accel-pptpd/ctrl/l2tp/dict.c
new file mode 100644
index 0000000..a0ca999
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/dict.c
@@ -0,0 +1,271 @@
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <limits.h>
+#include <unistd.h>
+
+#include "list.h"
+#include "l2tp.h"
+#include "log.h"
+#include "triton.h"
+
+#include "memdebug.h"
+
+struct l2tp_dict_t
+{
+	struct list_head items;
+};
+
+static struct l2tp_dict_t *dict;
+
+#define BUF_SIZE 1024
+static char *path, *fname1, *buf;
+
+struct l2tp_dict_attr_t *l2tp_dict_find_attr_by_name(const char *name)
+{
+	struct l2tp_dict_attr_t *attr;
+
+	list_for_each_entry(attr, &dict->items, entry) {
+		if (!strcmp(attr->name, name))
+			return attr;
+	}
+
+	return NULL;
+}
+
+struct l2tp_dict_attr_t *l2tp_dict_find_attr_by_id(int id)
+{
+	struct l2tp_dict_attr_t *attr;
+
+	list_for_each_entry(attr, &dict->items, entry) {
+		if (attr->id == id)
+			return attr;
+	}
+
+	return NULL;
+}
+
+struct l2tp_dict_value_t *l2tp_dict_find_value(struct l2tp_dict_attr_t *attr, l2tp_value_t val)
+{
+	struct l2tp_dict_value_t *v;
+
+	list_for_each_entry(v, &attr->values, entry) {
+		switch (attr->type) {
+			case ATTR_TYPE_INT16:
+				if (v->val.int16 == val.int16)
+					return v;
+				break;
+			case ATTR_TYPE_INT32:
+				if (v->val.int32 == val.int32)
+					return v;
+				break;
+		}
+	}
+
+	return NULL;
+}
+
+static char *skip_word(char *ptr)
+{
+	for(; *ptr; ptr++)
+		if (*ptr == ' ' || *ptr == '\t' || *ptr == '\n') 
+			break;
+	return ptr;
+}
+
+static char *skip_space(char *ptr)
+{
+	for(; *ptr; ptr++)
+		if (*ptr != ' ' && *ptr != '\t')
+			break;
+	return ptr;
+}
+
+static int split(char *buf, char **ptr)
+{
+	int i;
+
+	for (i = 0; i < 6; i++) {
+		buf = skip_word(buf);
+		if (!*buf)
+			return i;
+		
+		*buf = 0;
+		
+		buf = skip_space(buf + 1);
+		if (!*buf)
+			return i;
+
+		ptr[i] = buf;
+	}
+
+	buf = skip_word(buf);
+	//if (*buf == '\n')
+		*buf = 0;
+	//else if (*buf)
+	//	return -1;
+
+	return i;
+}
+
+
+static int dict_load(const char *fname)
+{
+	FILE *f;
+	char *ptr[6], *endptr;
+	struct l2tp_dict_attr_t *attr;
+	struct l2tp_dict_value_t *value;
+	struct list_head *items;
+	int r, n, i;
+
+	f = fopen(fname, "r");
+	if (!f) {
+		log_emerg("l2tp: open '%s': %s\n", fname, strerror(errno));
+		return -1;
+	}
+
+	items = &dict->items;
+	while (fgets(buf, BUF_SIZE, f)) {
+		n++;
+		if (buf[0] == '#' || buf[0] == '\n' || buf[0] == 0)
+			continue;
+
+		r = split(buf, ptr);
+
+		if (!strcmp(buf, "$INCLUDE")) {
+			if (r != 1)
+				goto out_syntax;
+
+			for (i = strlen(path) - 1; i; i--) {
+				if (path[i] == '/') {
+					path[i + 1] = 0;
+					break;
+				}
+			}
+
+			strcpy(fname1, path);
+			strcat(fname1, ptr[0]);
+
+			if (dict_load(fname1))
+				goto out_err;
+		} else if (!strcmp(buf, "ATTRIBUTE")) {
+			if (r < 3)
+				goto out_syntax;
+			
+			attr = malloc(sizeof(*attr));
+			memset(attr, 0, sizeof(*attr));
+			list_add_tail(&attr->entry, items);
+			INIT_LIST_HEAD(&attr->values);
+			
+			attr->name = strdup(ptr[0]);
+			attr->id = strtol(ptr[1], &endptr, 10);
+			if (*endptr != 0)
+				goto out_syntax;
+
+			if (!strcmp(ptr[2], "none"))
+				attr->type = ATTR_TYPE_NONE;
+			else if (!strcmp(ptr[2], "int16"))
+				attr->type = ATTR_TYPE_INT16;
+			else if (!strcmp(ptr[2], "int32"))
+				attr->type = ATTR_TYPE_INT32;
+			else if (!strcmp(ptr[2], "int64"))
+				attr->type = ATTR_TYPE_INT64;
+			else if (!strcmp(ptr[2], "octets"))
+				attr->type = ATTR_TYPE_OCTETS;
+			else if (!strcmp(ptr[2], "string"))
+				attr->type = ATTR_TYPE_STRING;
+			else
+				goto out_syntax;
+
+			attr->M = -1;
+			attr->H = -1;
+
+			for (i = 3; i < r; i++) {
+				if (!strcmp(ptr[i], "M=0"))
+					attr->M = 0;
+				else if (!strcmp(ptr[i], "M=1"))
+					attr->M = 1;
+				else if (!strcmp(ptr[i], "H=0"))
+					attr->H = 0;
+				else if (!strcmp(ptr[i], "H=1"))
+					attr->H = 1;
+				else
+					goto out_syntax;
+			}
+		} else if (!strcmp(buf, "VALUE")) {
+			if (r != 3)
+				goto out_syntax;
+			
+			attr = l2tp_dict_find_attr_by_name(ptr[0]);
+			if (!attr) {
+				log_emerg("l2tp:%s:%i: attribute not found\n", fname, n);
+				goto out_err;
+			}
+
+			value = malloc(sizeof(*value));
+			memset(value, 0, sizeof(*value));
+			list_add_tail(&value->entry, &attr->values);
+
+			value->name = strdup(ptr[1]);
+			switch (attr->type) {
+				case ATTR_TYPE_INT16:
+				case ATTR_TYPE_INT32:
+					value->val.int16 = strtol(ptr[2], &endptr, 10);
+					if (*endptr != 0)
+						goto out_syntax;
+					break;
+				case ATTR_TYPE_STRING:
+					value->val.string = strdup(ptr[2]);
+					break;
+			}
+		} else
+			goto out_syntax;
+	}
+
+	fclose(f);
+
+	return 0;
+
+out_syntax:
+	log_emerg("l2tp:%s:%i: syntaxis error\n", fname, n);
+out_err:
+	fclose(f);
+	return -1;
+}
+
+static int l2tp_dict_load(const char *fname)
+{
+	int r;
+
+	dict = _malloc(sizeof(*dict));
+	memset(dict, 0, sizeof(*dict));
+	INIT_LIST_HEAD(&dict->items);
+
+	path = _malloc(PATH_MAX);
+	fname1 = _malloc(PATH_MAX);
+	buf = _malloc(BUF_SIZE);
+
+	strcpy(path, fname);
+
+	r = dict_load(fname);
+
+	_free(buf);
+	_free(fname1);
+	_free(path);
+
+	return r;
+}
+
+static void __init dict_init(void)
+{
+	char *opt;
+
+	opt = conf_get_opt("l2tp", "dictionary");
+	if (!opt)
+		opt = DICTIONARY;
+
+	if (l2tp_dict_load(opt))
+		_exit(EXIT_FAILURE);
+}
+
diff --git a/accel-pptpd/ctrl/l2tp/dict/dictionary b/accel-pptpd/ctrl/l2tp/dict/dictionary
new file mode 100644
index 0000000..f5d7c42
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/dict/dictionary
@@ -0,0 +1,2 @@
+$INCLUDE dictionary.rfc2661
+$INCLUDE dictionary.rfc3931
diff --git a/accel-pptpd/ctrl/l2tp/dict/dictionary.rfc2661 b/accel-pptpd/ctrl/l2tp/dict/dictionary.rfc2661
new file mode 100644
index 0000000..434b55d
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/dict/dictionary.rfc2661
@@ -0,0 +1,55 @@
+ATTRIBUTE     Message-Type                0     int16     H=0
+ATTRIBUTE     Random-Vector              36     octets    M=1 H=0
+ATTRIBUTE     Result-Code                 1     octets    M=1 H=0
+ATTRIBUTE     Protocol-Version            2     int16     M=1 H=0
+ATTRIBUTE     Framing-Capabilities        3     int32     M=1
+ATTRIBUTE     Bearer-Capabilities         4     int32     M=1
+ATTRIBUTE     Tie-Breaker                 5     int64     M=1
+ATTRIBUTE     Firmware-Revision           6     int16     M=0
+ATTRIBUTE     Host-Name                   7     string    M=1
+ATTRIBUTE     Vendor-Name                 8     string    M=0
+ATTRIBUTE     Assigned-Tunnel-ID          9     int16     M=1
+ATTRIBUTE     Recv-Window-Size           10     int16     M=1
+ATTRIBUTE     Challenge                  11		  octets    M=1
+ATTRIBUTE     Challenge-Response         13     octets    M=1
+ATTRIBUTE     Cause-Code                 12     int32     M=1 H=0
+ATTRIBUTE     Assigned-Session-ID        14     int16     M=1
+ATTRIBUTE     Call-Serial-Number         15     int32     M=1
+ATTRIBUTE     Minimum-BPS                16     int32     M=1
+ATTRIBUTE     Maximum-BPS                17     int32     M=1
+ATTRIBUTE     Bearer-Type                18     int32     M=1
+ATTRIBUTE     Framing-Type               19     int32     M=1
+ATTRIBUTE     Called-Number              21     string    M=1
+ATTRIBUTE     Calling-Number             22     string    M=1
+ATTRIBUTE     Sub-Address                23     string    M=1
+ATTRIBUTE     TX-Speed                   24     int32     M=1
+ATTRIBUTE     RX-Speed                   38     int32     M=1
+ATTRIBUTE     Physical-Channel-ID        25     int32     M=0
+ATTRIBUTE     Private-Group-ID           37     int32     M=0
+ATTRIBUTE     Sequencing-Required        39     none      M=1 H=0
+ATTRIBUTE     Init-Recv-LCP              26     octets    M=0
+ATTRIBUTE     Last-Sent-LCP              27     octets    M=0
+ATTRIBUTE     Last-Recv-LCP              28     octets    M=0
+ATTRIBUTE     Proxy-Authen-Type          29     int16     M=0
+ATTRIBUTE     Proxy-Authen-Name          30     string    M=0
+ATTRIBUTE     Proxy-Authen-Challenge     31     octets    M=0
+ATTRIBUTE     Proxy-Authen-ID            32     int16     M=0
+ATTRIBUTE     Proxy-Authen-Response      33     octets    M=0
+ATTRIBUTE     Call-Errors                34     octets    M=1
+ATTRIBUTE     ACCM                       35     octets    M=1
+
+VALUE     Message-Type     Start-Ctrl-Conn-Request     1
+VALUE     Message-Type     Start-Ctrl-Conn-Reply       2
+VALUE     Message-Type     Start-Ctrl-Conn-Connected   3
+VALUE     Message-Type     Stop-Ctrl-Conn-Notify       4
+VALUE     Message-Type     Hello                       6
+VALUE     Message-Type     Outgoing-Call-Request       7
+VALUE     Message-Type     Outgoing-Call-Reply         8
+VALUE     Message-Type     Outgoing-Call-Connected     9
+VALUE     Message-Type     Incoming-Call-Request      10
+VALUE     Message-Type     Incoming-Call-Reply        11
+VALUE     Message-Type     Incoming-Call-Connected    12
+VALUE     Message-Type     Call-Disconnect-Notify     14
+VALUE     Message-Type     WAN-Error-Notify           15
+VALUE     Message-Type     Set-Link-Info              16
+
diff --git a/accel-pptpd/ctrl/l2tp/dict/dictionary.rfc3931 b/accel-pptpd/ctrl/l2tp/dict/dictionary.rfc3931
new file mode 100644
index 0000000..d6ad410
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/dict/dictionary.rfc3931
@@ -0,0 +1,15 @@
+ATTRIBUTE     Message-Digest               59      octets     M=1 H=0
+ATTRIBUTE     Router-ID                    60      int32      H=0
+ATTRIBUTE     Assigned-Connection-ID       61      int32
+ATTRIBUTE     Pseudowire-Capabilities      62      octets
+ATTRIBUTE     Prefered-Language            72      octets
+ATTRIBUTE     Local-Session-ID             63      int32
+ATTRIBUTE     Remote-Session-ID            64      int32
+ATTRIBUTE     Assigned-Cookie              65      octets
+ATTRIBUTE     Remote-End-ID                66      octets
+ATTRIBUTE     Pseudowire-Type              68      int16
+ATTRIBUTE     L2-Specific-Sublayer         69      int16
+ATTRIBUTE     Data-Sequencing              70      int16
+ATTRIBUTE     TX-Connect-Speeed            74      int64
+ATTRIBUTE     RX-Connect-Speeed            75      int64
+ATTRIBUTE     Circuit-Status               71      int16
diff --git a/accel-pptpd/ctrl/l2tp/dict2c.py b/accel-pptpd/ctrl/l2tp/dict2c.py
new file mode 100644
index 0000000..ff0961e
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/dict2c.py
@@ -0,0 +1,20 @@
+import sys,re
+
+hdr = file(sys.argv[2],'w')
+
+def process(fname, hdr):
+	for line in file(fname):
+		if line[:-1].strip() == '':
+			continue
+		if line[0] == '#':
+			continue
+		f = re.compile('[$.a-zA-Z0-9\-]+').findall(line)
+		if f[0] == 'ATTRIBUTE' or f[0] == 'VENDOR':
+			hdr.write('#define {0} {1}\n'.format(f[1].replace('-','_').replace('.','_'), f[2]))
+		elif f[0] == 'VALUE':
+			hdr.write('#define {0}_{1} {2}\n'.format(f[1].replace('-','_').replace('.','_'), f[2].replace('-','_'),f[3]))
+		elif f[0] == '$INCLUDE':
+			process(f[1], hdr)
+
+if __name__ == '__main__':
+	process(sys.argv[1], hdr)
diff --git a/accel-pptpd/ctrl/l2tp/l2tp.c b/accel-pptpd/ctrl/l2tp/l2tp.c
new file mode 100644
index 0000000..7548411
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/l2tp.c
@@ -0,0 +1,732 @@
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <stdarg.h>
+#include <errno.h>
+#include <string.h>
+#include <fcntl.h>
+#include <time.h>
+#include <pthread.h>
+#include <arpa/inet.h>
+#include <netinet/in.h>
+#include <sys/socket.h>
+
+#include "triton.h"
+#include "mempool.h"
+#include "log.h"
+#include "ppp.h"
+#include "events.h"
+#include "utils.h"
+
+#include "memdebug.h"
+
+#include "l2tp.h"
+#include "attr_defs.h"
+
+#define STATE_WAIT_SCCCN 1
+#define STATE_WAIT_OCRQ  2
+#define STATE_WAIT_OCCN  3
+#define STATE_PPP        4
+#define STATE_CLOSE      0
+
+int conf_verbose = 0;
+int conf_timeout = 5;
+int conf_retransmit = 5;
+const char *conf_host_name = "accel-pptp";
+
+struct l2tp_serv_t
+{
+	struct triton_context_t ctx;
+	struct triton_md_handler_t hnd;
+	struct sockaddr_in addr;
+};
+
+struct l2tp_conn_t
+{
+	struct triton_context_t ctx;
+	struct triton_timer_t timeout_timer;
+	struct triton_timer_t echo_timer;
+
+	pthread_mutex_t lock;
+
+	int sock;
+	struct sockaddr_in addr;
+	uint16_t tid;
+	uint16_t sid;
+	uint16_t peer_tid;
+	uint16_t peer_sid;
+	uint32_t framing_cap;
+
+	struct l2tp_packet_t *last_pack;
+	int retransmit;
+	uint16_t Ns, Nr;
+	struct list_head recv_queue;
+	struct list_head send_queue;
+
+	int state;
+
+	struct ppp_ctrl_t ctrl;
+	struct ppp_t ppp;
+};
+
+static pthread_mutex_t l2tp_lock = PTHREAD_MUTEX_INITIALIZER;
+static struct l2tp_conn_t **l2tp_conn;
+static uint16_t l2tp_tid;
+
+static mempool_t l2tp_conn_pool;
+
+static void l2tp_timeout(struct triton_timer_t *t);
+static void l2tp_send_SCCRP(struct l2tp_conn_t *conn);
+static void l2tp_send(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack);
+
+static struct l2tp_conn_t *l2tp_conn_lookup(uint16_t tid)
+{
+	struct l2tp_conn_t *conn;
+	pthread_mutex_lock(&conn->lock);
+	conn = l2tp_conn[tid];
+	if (conn)
+		pthread_mutex_lock(&conn->lock);
+	pthread_mutex_unlock(&conn->lock);
+
+	return conn;
+}
+
+static void l2tp_disconnect(struct l2tp_conn_t *conn)
+{
+	close(conn->sock);
+
+	if (conn->timeout_timer.tpd)
+		triton_timer_del(&conn->timeout_timer);
+
+	if (conn->echo_timer.tpd)
+		triton_timer_del(&conn->echo_timer);
+
+	if (conn->state == STATE_PPP) {
+		conn->state = STATE_CLOSE;
+		ppp_terminate(&conn->ppp, 1);
+	}
+
+	pthread_mutex_lock(&l2tp_lock);
+	pthread_mutex_lock(&conn->lock);
+	l2tp_conn[conn->tid] = NULL;
+	pthread_mutex_unlock(&l2tp_lock);
+	pthread_mutex_unlock(&conn->lock);
+
+	triton_event_fire(EV_CTRL_FINISHED, &conn->ppp);
+	
+	if (conf_verbose)
+		log_ppp_info("disconnected\n");
+
+	triton_context_unregister(&conn->ctx);
+
+	if (conn->last_pack)
+		l2tp_packet_free(conn->last_pack);
+
+	if (conn->ppp.chan_name)
+		_free(conn->ppp.chan_name);
+	
+	_free(conn->ctrl.calling_station_id);
+	_free(conn->ctrl.called_station_id);
+	
+	mempool_free(conn);
+}
+
+static void l2tp_terminate(struct l2tp_conn_t *conn, int res, int err)
+{
+	struct l2tp_packet_t *pack;
+	struct l2tp_avp_result_code rc = {res, err};
+
+	pack = l2tp_packet_alloc(2, Message_Type_Stop_Ctrl_Conn_Notify, &conn->addr);
+	if (!pack) {
+		l2tp_disconnect(conn);
+		return;
+	}
+	
+	if (l2tp_packet_add_int16(pack, Assigned_Tunnel_ID, conn->tid))
+		goto out_err;
+	if (l2tp_packet_add_octets(pack, Result_Code, (uint8_t *)&rc, sizeof(rc)))
+		goto out_err;
+
+	l2tp_send(conn, pack);
+
+	return;
+
+out_err:
+	l2tp_packet_free(pack);
+	l2tp_disconnect(conn);
+}
+
+static void l2tp_alloc(struct l2tp_serv_t *serv, struct l2tp_packet_t *pack, struct l2tp_attr_t *assigned_tid, struct l2tp_attr_t *framing_cap)
+{
+	struct l2tp_conn_t *conn;
+	uint16_t tid;
+
+	conn = mempool_alloc(l2tp_conn_pool);
+	if (!conn) {
+		log_emerg("l2tp: out of memory\n");
+		return;
+	}
+
+	memset(conn, 0, sizeof(*conn));
+
+	pthread_mutex_lock(&l2tp_lock);
+	for (tid = l2tp_tid + 1; tid != l2tp_tid; tid++) {
+		if (tid == L2TP_MAX_TID)
+			tid = 1;
+		if (!l2tp_conn[tid]) {
+			l2tp_conn[tid] = conn;
+			conn->tid = tid;
+			break;
+		}
+	}
+	pthread_mutex_unlock(&l2tp_lock);
+
+	if (!conn->tid) {
+		if (conf_verbose)
+			log_warn("l2tp: no free tid available\n");
+		mempool_free(conn);
+		return;
+	}
+
+	INIT_LIST_HEAD(&conn->recv_queue);
+	INIT_LIST_HEAD(&conn->send_queue);
+
+	conn->sock = dup(serv->hnd.fd);
+	memcpy(&conn->addr, &pack->addr, sizeof(pack->addr));
+	conn->peer_tid = assigned_tid->val.uint16;
+	conn->framing_cap = framing_cap->val.uint32;
+
+	conn->timeout_timer.expire = l2tp_timeout;
+	conn->timeout_timer.period = conf_timeout * 1000;
+	conn->ctrl.ctx = &conn->ctx;
+	conn->ctrl.name = "l2tp";
+
+	conn->ctrl.calling_station_id = _malloc(17);
+	conn->ctrl.called_station_id = _malloc(17);
+	u_inet_ntoa(conn->addr.sin_addr.s_addr, conn->ctrl.calling_station_id);
+	u_inet_ntoa(serv->addr.sin_addr.s_addr, conn->ctrl.called_station_id);
+
+	ppp_init(&conn->ppp);
+	conn->ppp.ctrl = &conn->ctrl;
+
+	triton_context_register(&conn->ctx, &conn->ppp);
+	triton_context_wakeup(&conn->ctx);
+
+	if (conf_verbose) {
+		log_switch(&conn->ctx, &conn->ppp);
+		log_ppp_info("recv ");
+		l2tp_packet_print(pack);
+	}
+
+	triton_context_call(&conn->ctx, (triton_event_func)l2tp_send_SCCRP, conn);
+}
+
+static int l2tp_connect(struct l2tp_conn_t *conn)
+{
+
+	return 0;
+}
+
+static void l2tp_timeout(struct triton_timer_t *t)
+{
+	struct l2tp_conn_t *conn = container_of(t, typeof(*conn), timeout_timer);
+	struct l2tp_packet_t *pack;
+
+	if (!list_empty(&conn->send_queue)) {
+		log_ppp_debug("l2tp: retransmit (%i)\n", conn->retransmit);
+		if (++conn->retransmit <= conf_retransmit) {
+			pack = list_entry(conn->send_queue.next, typeof(*pack), entry);
+			pack->hdr.Nr = htons(conn->Nr + 1);
+			if (conf_verbose) {
+				log_ppp_info("send ");
+				l2tp_packet_print(conn->last_pack);
+			}
+			if (l2tp_packet_send(conn->sock, conn->last_pack) == 0)
+				return;
+		}
+	}
+	
+	l2tp_disconnect(conn);
+}
+
+static void l2tp_send(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+	conn->retransmit = 0;
+
+	pack->hdr.tid = htons(conn->peer_tid);
+	pack->hdr.sid = htons(conn->peer_sid);
+	pack->hdr.Nr = htons(conn->Nr + 1);
+	pack->hdr.Ns = htons(conn->Ns++);
+
+	if (conf_verbose) {
+		log_ppp_info("send ");
+		l2tp_packet_print(conn->last_pack);
+	}
+
+	if (l2tp_packet_send(conn->sock, pack))
+		goto out_err;
+
+	if (!conn->timeout_timer.tpd)
+		triton_timer_add(&conn->ctx, &conn->timeout_timer, 0);
+
+	if (!list_empty(&pack->attrs))
+		list_add_tail(&pack->entry, &conn->send_queue);
+	
+	return;
+
+out_err:
+	l2tp_packet_free(pack);
+	l2tp_disconnect(conn);
+}
+
+static void l2tp_send_ZLB(struct l2tp_conn_t *conn)
+{
+	struct l2tp_packet_t *pack;
+
+	pack = l2tp_packet_alloc(2, 0, &conn->addr);
+	if (!pack) {
+		l2tp_disconnect(conn);
+		return;
+	}
+
+	l2tp_send(conn, pack);
+
+	return;
+}
+
+static void l2tp_send_SCCRP(struct l2tp_conn_t *conn)
+{
+	struct l2tp_packet_t *pack;
+
+	pack = l2tp_packet_alloc(2, Message_Type_Start_Ctrl_Conn_Reply, &conn->addr);
+	if (!pack) {
+		l2tp_disconnect(conn);
+		return;
+	}
+	
+	if (l2tp_packet_add_int16(pack, Protocol_Version, L2TP_V2_PROTOCOL_VERSION))
+		goto out_err;
+	if (l2tp_packet_add_string(pack, Host_Name, conf_host_name))
+		goto out_err;
+	if (l2tp_packet_add_int32(pack, Framing_Capabilities, conn->framing_cap))
+		goto out_err;
+	if (l2tp_packet_add_int16(pack, Assigned_Tunnel_ID, conn->tid))
+		goto out_err;
+
+
+	l2tp_send(conn, pack);
+
+	conn->state = STATE_WAIT_SCCCN;
+
+	return;
+
+out_err:
+	l2tp_packet_free(pack);
+	l2tp_disconnect(conn);
+}
+
+static void l2tp_send_OCRP(struct l2tp_conn_t *conn)
+{
+	struct l2tp_packet_t *pack;
+
+	pack = l2tp_packet_alloc(2, Message_Type_Outgoing_Call_Reply, &conn->addr);
+	if (!pack) {
+		l2tp_disconnect(conn);
+		return;
+	}
+	
+	conn->sid = 1;
+
+	if (l2tp_packet_add_int16(pack, Assigned_Session_ID, conn->sid))
+		goto out_err;
+
+	l2tp_send(conn, pack);
+
+	return;
+
+out_err:
+	l2tp_packet_free(pack);
+	l2tp_disconnect(conn);
+}
+
+static void l2tp_recv_SCCRQ(struct l2tp_serv_t *serv, struct l2tp_packet_t *pack)
+{
+	struct l2tp_attr_t *attr;
+	struct l2tp_attr_t *protocol_version = NULL;
+	struct l2tp_attr_t *assigned_tid = NULL;
+	struct l2tp_attr_t *assigned_cid = NULL;
+	struct l2tp_attr_t *framing_cap = NULL;
+	struct l2tp_attr_t *router_id = NULL;
+	
+	list_for_each_entry(attr, &pack->attrs, entry) {
+		switch (attr->attr->id) {
+			case Protocol_Version:
+				protocol_version = attr;
+				break;
+			case Framing_Capabilities:
+				framing_cap = attr;
+				break;
+			case Assigned_Tunnel_ID:
+				assigned_tid = attr;
+				break;
+			case Challenge:
+				if (conf_verbose)
+					log_warn("l2tp: Challenge in SCCRQ is not supported\n");
+				return;
+			case Assigned_Connection_ID:
+				assigned_cid = attr;
+				break;
+			case Router_ID:
+				router_id = attr;
+				break;
+			case Message_Digest:
+				if (conf_verbose)
+					log_warn("l2tp: Message-Digest is not supported\n");
+				return;
+		}
+	}
+
+	if (assigned_tid) {
+		if (!protocol_version) {
+			if (conf_verbose)
+				log_warn("l2tp: SCCRQ: no Protocol-Version present in message\n");
+			return;
+		}
+		if (protocol_version->val.uint16 != L2TP_V2_PROTOCOL_VERSION) {
+			if (conf_verbose)
+				log_warn("l2tp: protocol version %02x is not supported\n", protocol_version->val.uint16);
+			return;
+		}
+		if (!framing_cap) {
+			if (conf_verbose)
+				log_warn("l2tp: SCCRQ: no Framing-Capabilities present in message\n");
+			return;
+		}
+		
+		l2tp_alloc(serv, pack, assigned_tid, framing_cap);
+
+	} else if (assigned_cid) {
+		// not yet implemented
+		return;
+	} else {
+		if (conf_verbose)
+			log_warn("l2tp: SCCRQ: no Assigned-Tunnel-ID or Assigned-Connection-ID present in message\n");
+		return;
+	}
+}
+
+static void l2tp_recv_SCCCN(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+	if (conn->state == STATE_WAIT_SCCCN) {
+		l2tp_send_ZLB(conn);
+		conn->state = STATE_WAIT_OCRQ;
+	}
+	else
+		log_ppp_warn("l2tp: unexpected SCCCN\n");
+}
+
+static void l2tp_recv_StopCCN(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+
+}
+
+static void l2tp_recv_HELLO(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+
+}
+
+static void l2tp_recv_OCRQ(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+	struct l2tp_attr_t *attr;
+	struct l2tp_attr_t *assigned_sid = NULL;
+
+	if (conn->state != STATE_WAIT_OCRQ) {
+		log_ppp_warn("l2tp: unexpected OCRQ\n");
+		return;
+	}
+
+	list_for_each_entry(attr, &pack->attrs, entry) {
+		switch(attr->attr->id) {
+			case Assigned_Session_ID:
+				assigned_sid = attr;
+				break;
+			case Call_Serial_Number:
+			case Minimum_BPS:
+			case Maximum_BPS:
+			case Bearer_Type:
+			case Framing_Type:
+			case Called_Number:
+			case Sub_Address:
+				break;
+			default:
+				if (attr->M) {
+					if (conf_verbose) {
+						log_ppp_warn("l2tp: OCRQ: unknown attribute %i\n", attr->attr->id);
+						l2tp_terminate(conn, 2, 8);
+						return;
+					}
+				}
+		}
+	}
+
+	if (!assigned_sid) {
+		if (conf_verbose)
+			log_ppp_warn("l2tp: OCRQ: no Assigned-Session-ID attribute present in message\n");
+		l2tp_terminate(conn, 2, 0);
+		return;
+	}
+
+	l2tp_send_OCRP(conn);
+
+	conn->peer_sid = assigned_sid->val.uint16;
+
+	l2tp_connect(conn);
+}
+
+static void l2tp_recv_OCCN(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+
+}
+
+static void l2tp_recv_CDN(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+
+}
+
+static void l2tp_recv_SLI(struct l2tp_conn_t *conn, struct l2tp_packet_t *pack)
+{
+
+}
+
+static void l2tp_ctx_recv(struct l2tp_conn_t *conn)
+{
+	struct l2tp_packet_t *pack;
+	struct l2tp_attr_t *msg_type;
+
+	pthread_mutex_lock(&conn->lock);
+	if (list_empty(&conn->recv_queue)) {
+		pthread_mutex_unlock(&conn->lock);
+		return;
+	}
+	pack = list_entry(conn->recv_queue.next, typeof(*pack), entry);
+	list_del(&pack->entry);
+	pthread_mutex_unlock(&conn->lock);
+
+	if (conf_verbose) {
+		log_ppp_info("recv ");
+		l2tp_packet_print(pack);
+	}
+
+	if (ntohs(pack->hdr.Ns) == conn->Nr + 1) {
+		conn->Nr++;
+		if (!list_empty(&conn->send_queue)) {
+			pack = list_entry(conn->send_queue.next, typeof(*pack), entry);
+			list_del(&pack->entry);
+			l2tp_packet_free(pack);
+			conn->retransmit = 0;
+		}
+		if (!list_empty(&conn->send_queue))
+			triton_timer_mod(&conn->timeout_timer, 0);
+		else if (conn->timeout_timer.tpd)
+			triton_timer_del(&conn->timeout_timer);
+	} else {
+		if (ntohs(pack->hdr.Ns) < conn->Nr + 1 || (ntohs(pack->hdr.Ns > 32767 && conn->Nr + 1 < 32767))) {
+			log_ppp_debug("duplicate packet\n");
+			l2tp_send_ZLB(conn);
+		} else
+			log_ppp_debug("reordered packet\n");
+		l2tp_packet_free(pack);
+		return;
+	}
+
+	if (list_empty(&pack->attrs)) {
+		l2tp_packet_free(pack);
+		return;
+	}
+
+	msg_type = list_entry(pack->attrs.next, typeof(*msg_type), entry);
+
+	if (msg_type->attr->id != Message_Type) {
+		if (conf_verbose)
+			log_ppp_error("l2tp: first attribute is not Message-Type, dropping connection...\n");
+		goto drop;
+	}
+
+	switch (msg_type->val.uint16) {
+		case Message_Type_Start_Ctrl_Conn_Connected:
+			l2tp_recv_SCCCN(conn, pack);
+			break;
+		case Message_Type_Stop_Ctrl_Conn_Notify:
+			l2tp_recv_StopCCN(conn, pack);
+			break;
+		case Message_Type_Hello:
+			l2tp_recv_HELLO(conn, pack);
+			break;
+		case Message_Type_Outgoing_Call_Request:
+			l2tp_recv_OCRQ(conn, pack);
+			break;
+		case Message_Type_Outgoing_Call_Connected:
+			l2tp_recv_OCCN(conn, pack);
+			break;
+		case Message_Type_Call_Disconnect_Notify:
+			l2tp_recv_CDN(conn, pack);
+			break;
+		case Message_Type_Set_Link_Info:
+			l2tp_recv_SLI(conn, pack);
+			break;
+		case Message_Type_Start_Ctrl_Conn_Reply:
+		case Message_Type_Outgoing_Call_Reply:
+		case Message_Type_Incoming_Call_Request:
+		case Message_Type_Incoming_Call_Reply:
+		case Message_Type_Incoming_Call_Connected:
+		case Message_Type_WAN_Error_Notify:
+			if (conf_verbose)
+				log_warn("l2tp: unexpected Message-Type %i\n", msg_type->val.uint16);
+			break;
+		default:
+			if (conf_verbose)
+				log_warn("l2tp: unknown Message-Type %i\n", msg_type->val.uint16);
+			if (msg_type->M)
+				l2tp_terminate(conn, 2, 8);
+	}
+
+	l2tp_packet_free(pack);
+
+	return;
+
+drop:
+	l2tp_packet_free(pack);
+	l2tp_disconnect(conn);
+}
+
+static int l2tp_udp_read(struct triton_md_handler_t *h)
+{
+	struct l2tp_serv_t *serv = container_of(h, typeof(*serv), hnd);
+	struct l2tp_packet_t *pack;
+	struct l2tp_attr_t *msg_type;
+	struct l2tp_conn_t *conn = NULL;
+
+	while (1) {
+		pack = NULL;
+
+		if (l2tp_recv(h->fd, &pack))
+			break;
+
+		if (!pack)
+			continue;
+
+		if (pack->hdr.ver == 2 && pack->hdr.tid) {
+				conn = l2tp_conn_lookup(ntohs(pack->hdr.tid));
+				if (!conn) {
+					if (conf_verbose)
+						log_warn("l2tp: tunnel %i not found\n", ntohs(pack->hdr.tid));
+					goto skip;
+				}
+				
+				list_add_tail(&pack->entry, &conn->recv_queue);
+				triton_context_call(&conn->ctx, (triton_event_func)l2tp_ctx_recv, conn);
+				pthread_mutex_unlock(&conn->lock);
+				continue;
+		}
+
+		if (list_empty(&pack->attrs)) {
+			if (conf_verbose)
+				log_warn("l2tp: to Message-Type attribute present\n");
+			goto skip;
+		}
+
+		msg_type = list_entry(pack->attrs.next, typeof(*msg_type), entry);
+		if (msg_type->attr->id != Message_Type) {
+			if (conf_verbose)
+				log_warn("l2tp: first attribute is not Message-Type\n");
+			goto skip;
+		}
+
+		if (msg_type->val.uint16 == Message_Type_Start_Ctrl_Conn_Request)
+				l2tp_recv_SCCRQ(serv, pack);
+		else {
+			if (conf_verbose) {
+				log_warn("recv (unexpected) ");
+				l2tp_packet_print(pack);
+			}
+		}
+skip:
+		l2tp_packet_free(pack);
+	}
+
+	return 0;
+}
+
+static void l2tp_udp_close(struct triton_context_t *ctx)
+{
+	struct l2tp_serv_t *serv = container_of(ctx, typeof(*serv), ctx);
+}
+
+static struct l2tp_serv_t udp_serv =
+{
+	.hnd.read=l2tp_udp_read,
+	.ctx.close=l2tp_udp_close,
+};
+
+/*static struct l2tp_serv_t ip_serv =
+{
+	.hnd.read=l2t_ip_read,
+	.ctx.close=l2tp_ip_close,
+};*/
+
+static void start_udp_server(void)
+{
+  struct sockaddr_in addr;
+	char *opt;
+
+	udp_serv.hnd.fd = socket(PF_INET, SOCK_DGRAM, 0);
+  if (udp_serv.hnd.fd < 0) {
+    log_emerg("l2tp: socket: %s\n", strerror(errno));
+    return;
+  }
+  addr.sin_family = AF_INET;
+  addr.sin_port = htons(L2TP_PORT);
+
+	opt = conf_get_opt("l2tp", "bind");
+	if (opt)
+		addr.sin_addr.s_addr = inet_addr(opt);
+	else
+		addr.sin_addr.s_addr = htonl(INADDR_ANY);
+  
+  setsockopt(udp_serv.hnd.fd, SOL_SOCKET, SO_REUSEADDR, &udp_serv.hnd.fd, 4);  
+  if (bind (udp_serv.hnd.fd, (struct sockaddr *) &addr, sizeof (addr)) < 0) {
+    log_emerg("l2tp: failed to bind socket: %s\n", strerror(errno));
+		close(udp_serv.hnd.fd);
+    return;
+  }
+
+	if (fcntl(udp_serv.hnd.fd, F_SETFL, O_NONBLOCK)) {
+    log_emerg("pptp: failed to set nonblocking mode: %s\n", strerror(errno));
+		close(udp_serv.hnd.fd);
+    return;
+	}
+
+	memcpy(&udp_serv.addr, &addr, sizeof(addr));
+
+	triton_context_register(&udp_serv.ctx, NULL);
+	triton_md_register_handler(&udp_serv.ctx, &udp_serv.hnd);
+	triton_md_enable_handler(&udp_serv.hnd, MD_MODE_READ);
+	triton_context_wakeup(&udp_serv.ctx);
+}
+
+static void __init l2tp_init(void)
+{
+	char *opt;
+
+	l2tp_conn = malloc(L2TP_MAX_TID * sizeof(void *));
+	memset(l2tp_conn, 0, L2TP_MAX_TID * sizeof(void *));
+
+	l2tp_conn_pool = mempool_create(sizeof(struct l2tp_conn_t));
+
+	opt = conf_get_opt("l2tp", "verbose");
+	if (opt && atoi(opt) > 0)
+		conf_verbose = 1;
+
+	start_udp_server();
+}
+
diff --git a/accel-pptpd/ctrl/l2tp/l2tp.h b/accel-pptpd/ctrl/l2tp/l2tp.h
new file mode 100644
index 0000000..a99bdc3
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/l2tp.h
@@ -0,0 +1,84 @@
+#ifndef __L2TP_H
+#define __L2TP_H
+
+#include <netinet/in.h>
+
+#include "list.h"
+#include "l2tp_prot.h"
+
+#define ATTR_TYPE_NONE    0
+#define ATTR_TYPE_INT16   1
+#define ATTR_TYPE_INT32   2
+#define ATTR_TYPE_INT64   3
+#define ATTR_TYPE_OCTETS  4
+#define ATTR_TYPE_STRING  5
+
+#define L2TP_MAX_PACKET_SIZE 65536
+#define L2TP_MAX_TID 65534
+
+#define L2TP_V2_PROTOCOL_VERSION ( 1 << 8 | 0 )
+
+typedef union
+{
+	uint32_t uint32;
+	int32_t  int32;
+	uint16_t uint16;
+	int16_t  int16;
+	uint64_t uint64;
+	uint8_t *octets;
+	char    *string;
+} l2tp_value_t;
+
+struct l2tp_dict_attr_t
+{
+	struct list_head entry;
+	const char *name;
+	int id;
+	int type;
+	int M;
+	int H;
+	struct list_head values;
+};
+
+struct l2tp_dict_value_t
+{
+	struct list_head entry;
+	const char *name;
+	l2tp_value_t val;
+};
+
+struct l2tp_attr_t
+{
+	struct list_head entry;
+	struct l2tp_dict_attr_t *attr;
+	int M:1;
+	int H:1;
+	int length;
+	l2tp_value_t val;
+};
+
+struct l2tp_packet_t
+{
+	struct list_head entry;
+	struct sockaddr_in addr;
+	struct l2tp_hdr_t hdr;
+	struct list_head attrs;
+};
+
+extern int conf_verbose;
+
+struct l2tp_dict_attr_t *l2tp_dict_find_attr_by_name(const char *name);
+struct l2tp_dict_attr_t *l2tp_dict_find_attr_by_id(int id);
+struct l2tp_dict_value_t *l2tp_dict_find_value(struct l2tp_dict_attr_t *attr, l2tp_value_t val);
+
+int l2tp_recv(int fd, struct l2tp_packet_t **);
+void l2tp_packet_free(struct l2tp_packet_t *);
+void l2tp_packet_print(struct l2tp_packet_t *);
+struct l2tp_packet_t *l2tp_packet_alloc(int ver, int msg_type, struct sockaddr_in *addr);
+int l2tp_packet_send(int sock, struct l2tp_packet_t *);
+int l2tp_packet_add_int16(struct l2tp_packet_t *pack, int id, int16_t val);
+int l2tp_packet_add_int32(struct l2tp_packet_t *pack, int id, int32_t val);
+int l2tp_packet_add_string(struct l2tp_packet_t *pack, int id, const char *val);
+int l2tp_packet_add_octets(struct l2tp_packet_t *pack, int id, const uint8_t *val, int size);
+
+#endif
diff --git a/accel-pptpd/ctrl/l2tp/l2tp_prot.h b/accel-pptpd/ctrl/l2tp/l2tp_prot.h
new file mode 100644
index 0000000..1c1d9da
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/l2tp_prot.h
@@ -0,0 +1,55 @@
+#ifndef __L2TP_PROT_H
+#define __L2TP_PROT_H
+
+#include <stdint.h>
+
+#define L2TP_PORT 1701
+
+struct l2tp_hdr_t
+{
+	uint8_t P:1;
+	uint8_t O:1;
+	uint8_t reserved2:1;
+	uint8_t S:1;
+	uint8_t reserved1:2;
+	uint8_t L:1;
+	uint8_t T:1;
+	uint8_t ver:4;
+	uint8_t reserved3:4;
+	uint16_t length;
+	union {
+		struct {
+			uint16_t tid;
+			uint16_t sid;
+		};
+		uint32_t cid;
+	};
+	uint16_t Ns;
+	uint16_t Nr;
+} __attribute__((packed));
+
+/*#define L2TP_T(hdr) (hdr->flags >> 15)
+#define L2TP_L(hdr) ((hdr->flags >> 14) & 1)
+#define L2TP_S(hdr) ((hdr->flags >> 10) & 1)
+#define L2TP_O(hdr) ((hdr->flags >> 8) & 1)
+#define L2TP_VER(hdr) (hdr->flags & 0xf)*/
+
+struct l2tp_avp_t
+{
+	uint16_t length:10;
+	uint16_t reserved:4;
+	uint16_t H:1;
+	uint16_t M:1;
+	uint16_t vendor;
+	uint16_t type;
+	uint8_t val[0];
+} __attribute__((packed));
+
+struct l2tp_avp_result_code
+{
+	uint16_t result_code;
+	uint16_t error_code;
+} __attribute__((packed));
+
+#endif
+
diff --git a/accel-pptpd/ctrl/l2tp/packet.c b/accel-pptpd/ctrl/l2tp/packet.c
new file mode 100644
index 0000000..e0ff65a
--- /dev/null
+++ b/accel-pptpd/ctrl/l2tp/packet.c
@@ -0,0 +1,457 @@
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <arpa/inet.h>
+
+#include "triton.h"
+#include "log.h"
+#include "mempool.h"
+#include "memdebug.h"
+
+#include "l2tp.h"
+#include "attr_defs.h"
+
+static mempool_t attr_pool;
+static mempool_t pack_pool;
+static mempool_t buf_pool;
+
+void l2tp_packet_print(struct l2tp_packet_t *pack)
+{
+	struct l2tp_attr_t *attr;
+	struct l2tp_dict_value_t *val;
+
+	if (pack->hdr.ver == 2)
+		log_ppp_info("[L2TP tid=%i sid=%i Ns=%i Nr=%i",
+			pack->hdr.tid, pack->hdr.sid, pack->hdr.Ns, pack->hdr.Nr);
+	else
+		log_ppp_info("[L2TP cid=%u Ns=%i Nr=%i",
+			pack->hdr.cid, pack->hdr.Ns, pack->hdr.Nr);
+
+	list_for_each_entry(attr, &pack->attrs, entry) {
+		log_ppp_info(" <%s", attr->attr->name);
+		val = l2tp_dict_find_value(attr->attr, attr->val);
+		if (val)
+			log_ppp_info(" %s", val->name);
+		else {
+			switch (attr->attr->type) {
+				case ATTR_TYPE_INT16:
+					log_ppp_info(" %i", attr->val.int16);
+					break;
+				case ATTR_TYPE_INT32:
+					log_ppp_info(" %i", attr->val.int32);
+					break;
+				case ATTR_TYPE_STRING:
+					log_ppp_info(" %s", attr->val.string);
+					break;
+			}
+		}
+		log_ppp_info(">");
+	}
+
+	log_ppp_info("]\n");
+}
+
+struct l2tp_packet_t *l2tp_packet_alloc(int ver, int msg_type, struct sockaddr_in *addr)
+{
+	struct l2tp_packet_t *pack = mempool_alloc(pack_pool);
+	if (!pack)
+		return NULL;
+	
+	memset(pack, 0, sizeof(*pack));
+	INIT_LIST_HEAD(&pack->attrs);
+	pack->hdr.ver = ver;
+	pack->hdr.T = 1;
+	pack->hdr.L = 1;
+	pack->hdr.S = 1;
+	memcpy(&pack->addr, addr, sizeof(*addr));
+
+	if (msg_type) {
+		if (l2tp_packet_add_int16(pack, Message_Type, msg_type)) {
+			mempool_free(pack);
+			return NULL;
+		}
+	}
+
+	return pack;
+}
+
+void l2tp_packet_free(struct l2tp_packet_t *pack)
+{
+	struct l2tp_attr_t *attr;
+
+	while (!list_empty(&pack->attrs)) {
+		attr = list_entry(pack->attrs.next, typeof(*attr), entry);
+		if (attr->attr->type == ATTR_TYPE_OCTETS || attr->attr->type == ATTR_TYPE_STRING)
+			_free(attr->val.octets);
+		list_del(&attr->entry);
+		mempool_free(attr);
+	}
+
+	mempool_free(pack);
+}
+
+int l2tp_recv(int fd, struct l2tp_packet_t **p)
+{
+	int n, length;
+	uint8_t *buf = mempool_alloc(buf_pool);
+	struct l2tp_hdr_t *hdr = (struct l2tp_hdr_t *)buf;
+	struct l2tp_avp_t *avp;
+	struct l2tp_dict_attr_t *da;
+	struct l2tp_attr_t *attr, *RV = NULL;
+	uint8_t *ptr = (uint8_t *)(hdr + 1);
+	struct l2tp_packet_t *pack;
+	struct sockaddr_in addr;
+	socklen_t len = sizeof(addr);
+
+	if (!buf) {
+		log_emerg("l2tp: out of memory\n");
+		return 0;
+	}
+
+	n = recvfrom(fd, buf, L2TP_MAX_PACKET_SIZE, 0, &addr, &len);
+
+	if (n < 0) {
+		if (errno == EAGAIN)
+			return -1;
+		log_error("l2tp: recv: %s\n", strerror(errno));
+		return 0;
+	}
+
+	if (n < sizeof(*hdr)) {
+		if (conf_verbose)
+			log_warn("l2tp: short packet received (%i/%i)\n", n, sizeof(*hdr));
+		goto out_err;
+	}
+
+	if (n < ntohs(hdr->length)) {
+		if (conf_verbose)
+			log_warn("l2tp: short packet received (%i/%i)\n", n, ntohs(hdr->length));
+		goto out_err;
+	}
+
+	if (hdr->T == 0)
+		goto out_err_hdr;
+
+	if (hdr->ver == 2) {
+		if (hdr->L == 0) {
+			if (conf_verbose)
+				log_warn("l2tp: incorrect message received (L=0)\n");
+			goto out_err_hdr;
+		}
+
+		if (hdr->S == 0) {
+			if (conf_verbose)
+				log_warn("l2tp: incorrect message received (S=0)\n");
+			goto out_err_hdr;
+		}
+
+		if (hdr->O == 1) {
+			if (conf_verbose)
+				log_warn("l2tp: incorrect message received (O=1)\n");
+			goto out_err_hdr;
+		}
+	} else if (hdr->ver != 3) {
+		if (conf_verbose)
+			log_warn("l2tp: protocol version %i is not supported\n", hdr->ver);
+		goto out_err_hdr;
+	}
+
+	pack = mempool_alloc(pack_pool);
+	if (!pack) {
+		log_emerg("l2tp: out of memory\n");
+		mempool_free(buf);
+		return -1;
+	}
+
+	memset(pack, 0, sizeof(*pack));
+	INIT_LIST_HEAD(&pack->attrs);
+
+	memcpy(&pack->addr, &addr, sizeof(addr));
+	memcpy(&pack->hdr, hdr, sizeof(*hdr));
+	length = ntohs(hdr->length) - sizeof(*hdr);
+
+	while (length) {
+		*(uint16_t *)ptr = ntohs(*(uint16_t *)ptr);
+		avp = (struct l2tp_avp_t *)ptr;
+
+		if (avp->length > length) {
+			if (conf_verbose)
+				log_warn("l2tp: incorrect avp received (exceeds message length)\n");
+			goto out_err;
+		}
+
+		da = l2tp_dict_find_attr_by_id(ntohs(avp->type));
+		if (!da) {
+			if (conf_verbose)
+				log_warn("l2tp: unknown avp received (type=%i, M=%u)\n", ntohs(avp->type), avp->M);
+			if (avp->M)
+				goto out_err;
+		} else {
+			if (da->M != -1 && da->M != avp->M) {
+				if (conf_verbose)
+					log_warn("l2tp: incorrect avp received (type=%i, M=%i, must be %i)\n", ntohs(avp->type), avp->M, da->M);
+				goto out_err;
+			}
+
+			if (da->H != -1 && da->H != avp->H) {
+				if (conf_verbose)
+					log_warn("l2tp: incorrect avp received (type=%i, H=%i, must be %i)\n", ntohs(avp->type), avp->H, da->H);
+				goto out_err;
+			}
+
+			if (avp->H) {
+				if (!RV) {
+					if (conf_verbose)
+						log_warn("l2tp: incorrect avp received (type=%i, H=1, but Random-Vector is not received)\n", ntohs(avp->type));
+					goto out_err;
+				} else {
+					if (conf_verbose)
+						log_warn("l2tp: hidden avp received (type=%i)\n", ntohs(avp->type));
+				}
+			}
+
+			attr = mempool_alloc(attr_pool);
+			memset(attr, 0, sizeof(*attr));
+			list_add_tail(&attr->entry, &pack->attrs);
+
+			attr->attr = da;
+			attr->M = avp->M;
+			attr->H = avp->H;
+			attr->length = avp->length - sizeof(*avp);
+			
+			if (attr->attr->id == Random_Vector)
+				RV = attr;
+
+			switch (da->type) {
+				case ATTR_TYPE_INT16:
+					if (avp->length != sizeof(*avp) + 2)
+						goto out_err_len;
+					attr->val.uint16 = ntohs(*(uint16_t *)avp->val);
+					break;
+				case ATTR_TYPE_INT32:
+					if (avp->length != sizeof(*avp) + 4)
+						goto out_err_len;
+					attr->val.uint32 = ntohl(*(uint32_t *)avp->val);
+					break;
+				case ATTR_TYPE_INT64:
+					if (avp->length != sizeof(*avp) + 8)
+						goto out_err_len;
+					attr->val.uint64 = *(uint64_t *)avp->val;
+					break;
+				case ATTR_TYPE_OCTETS:
+					attr->val.octets = _malloc(attr->length);
+					if (!attr->val.octets)
+						goto out_err_mem;
+					memcpy(attr->val.octets, avp->val, attr->length);
+					break;
+				case ATTR_TYPE_STRING:
+					attr->val.string = _malloc(attr->length + 1);
+					if (!attr->val.string)
+						goto out_err_mem;
+					memcpy(attr->val.string, avp->val, attr->length);
+					attr->val.string[attr->length] = 0;
+					break;
+			}
+		}
+
+		ptr += avp->length;
+		length -= avp->length;
+	}
+
+	*p = pack;
+
+	mempool_free(buf);
+
+	return 0;
+
+out_err:
+	l2tp_packet_free(pack);
+out_err_hdr:
+	mempool_free(buf);
+	return 0;
+out_err_len:
+	if (conf_verbose)
+		log_warn("l2tp: incorrect avp received (type=%i, incorrect length %i)\n", ntohs(avp->type), avp->length);
+	goto out_err;
+out_err_mem:
+	log_emerg("l2tp: out of memory\n");
+	goto out_err;
+}
+
+int l2tp_packet_send(int sock, struct l2tp_packet_t *pack)
+{
+	uint8_t *buf = mempool_alloc(buf_pool);
+	struct l2tp_avp_t *avp;
+	struct l2tp_attr_t *attr;
+	uint8_t *ptr;
+	int n;
+	int len = sizeof(pack->hdr);
+
+	if (!buf) {
+		log_emerg("l2tp: out of memory\n");
+		return -1;
+	}
+
+	memset(buf, 0, L2TP_MAX_PACKET_SIZE);
+
+	ptr = buf + sizeof(pack->hdr);
+
+	list_for_each_entry(attr, &pack->attrs, entry) {
+		if (len + sizeof(*avp) + attr->length >= L2TP_MAX_PACKET_SIZE) {
+			log_error("l2tp: cann't send packet (exceeds maximum size)\n");
+			mempool_free(buf);
+			return -1;
+		}
+		avp = (struct l2tp_avp_t *)ptr;
+		avp->type = htons(attr->attr->id);
+		avp->M = attr->M;
+		avp->H = attr->H;
+		avp->length = sizeof(*avp) + attr->length;
+		*(uint16_t *)ptr = htons(*(uint16_t *)ptr);
+		switch (attr->attr->type) {
+			case ATTR_TYPE_INT16:
+				*(int16_t *)avp->val = htons(attr->val.int16);
+				break;
+			case ATTR_TYPE_INT32:
+				*(int32_t *)avp->val = htonl(attr->val.int32);
+				break;
+			case ATTR_TYPE_STRING:
+			case ATTR_TYPE_OCTETS:
+				memcpy(avp->val, attr->val.string, attr->length);
+				break;
+		}
+
+		ptr += sizeof(*avp) + attr->length;
+		len += sizeof(*avp) + attr->length;
+	}
+
+	pack->hdr.length = htons(len);
+	memcpy(buf, &pack->hdr, sizeof(pack->hdr));
+
+	n = sendto(sock, buf, ntohs(pack->hdr.length), 0, &pack->addr, sizeof(pack->addr));
+	
+	mempool_free(buf);
+
+	if (n < 0) {
+		if (errno == EAGAIN) {
+			if (conf_verbose)
+				log_warn("l2tp: buffer overflow (packet lost)\n");
+		} else {
+			if (conf_verbose)
+				log_warn("l2tp: sendto: %s\n", strerror(errno));
+			return -1;
+		}
+	}
+
+	if (n != ntohs(pack->hdr.length)) {
+		if (conf_verbose)
+			log_warn("l2tp: short write (%i/%i)\n", n, ntohs(pack->hdr.length));
+	}
+
+	return 0;
+}
+
+static struct l2tp_attr_t *attr_alloc(int id)
+{
+	struct l2tp_attr_t *attr;
+	struct l2tp_dict_attr_t *da;
+
+	da = l2tp_dict_find_attr_by_id(id);
+	if (!da)
+		return NULL;
+
+	attr = mempool_alloc(attr_pool);
+	if (!attr) {
+		log_emerg("l2tp: out of memory\n");
+		return NULL;
+	}
+
+	memset(attr, 0, sizeof(*attr));
+
+	attr->attr = da;
+
+	if (da->M != -1)
+		attr->M = da->M;
+	if (da->H != -1)
+		attr->H = da->H;
+
+	return attr;
+}
+
+int l2tp_packet_add_int16(struct l2tp_packet_t *pack, int id, int16_t val)
+{
+	struct l2tp_attr_t *attr = attr_alloc(id);
+
+	if (!attr)
+		return -1;
+
+	attr->length = 2;
+	attr->val.int16 = val;
+	list_add_tail(&attr->entry, &pack->attrs);
+
+	return 0;
+}
+int l2tp_packet_add_int32(struct l2tp_packet_t *pack, int id, int32_t val)
+{
+	struct l2tp_attr_t *attr = attr_alloc(id);
+
+	if (!attr)
+		return -1;
+
+	attr->length = 4;
+	attr->val.int32 = val;
+	list_add_tail(&attr->entry, &pack->attrs);
+
+	return 0;
+}
+int l2tp_packet_add_string(struct l2tp_packet_t *pack, int id, const char *val)
+{
+	struct l2tp_attr_t *attr = attr_alloc(id);
+
+	if (!attr)
+		return -1;
+
+	attr->length = strlen(val);
+	attr->val.string = _strdup(val);
+	if (!attr->val.string) {
+		log_emerg("l2tp: out of memory\n");
+		mempool_free(attr);
+		return -1;
+	}
+	memcpy(attr->val.string, val, attr->length);
+	list_add_tail(&attr->entry, &pack->attrs);
+
+	return 0;
+}
+
+int l2tp_packet_add_octets(struct l2tp_packet_t *pack, int id, const uint8_t *val, int size)
+{
+	struct l2tp_attr_t *attr = attr_alloc(id);
+
+	if (!attr)
+		return -1;
+
+	attr->length = size;
+	attr->val.octets = _malloc(size);
+	if (!attr->val.string) {
+		log_emerg("l2tp: out of memory\n");
+		mempool_free(attr);
+		return -1;
+	}
+	memcpy(attr->val.octets, val, attr->length);
+	list_add_tail(&attr->entry, &pack->attrs);
+
+	return 0;
+}
+
+static void __init init(void)
+{
+	attr_pool = mempool_create(sizeof(struct l2tp_attr_t));
+	pack_pool = mempool_create(sizeof(struct l2tp_packet_t));
+	buf_pool = mempool_create(L2TP_MAX_PACKET_SIZE);
+}
+
diff --git a/accel-pptpd/ctrl/pppoe/CMakeLists.txt b/accel-pptpd/ctrl/pppoe/CMakeLists.txt
new file mode 100644
index 0000000..dd0f9cd
--- /dev/null
+++ b/accel-pptpd/ctrl/pppoe/CMakeLists.txt
@@ -0,0 +1,5 @@
+INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
+
+ADD_LIBRARY(pppoe SHARED pppoe.c)
+
+INSTALL(TARGETS pppoe LIBRARY DESTINATION usr/lib/accel-pptp)
diff --git a/accel-pptpd/ctrl/pppoe.c b/accel-pptpd/ctrl/pppoe/pppoe.c
index d59a317..30769b5 100644
--- a/accel-pptpd/ctrl/pppoe.c
+++ b/accel-pptpd/ctrl/pppoe/pppoe.c
@@ -678,62 +678,65 @@ static int pppoe_serv_read(struct triton_md_handler_t *h)
 	struct pppoe_hdr *hdr = (struct pppoe_hdr *)(pack + ETH_HLEN);
 	int n;
 
-	n = read(h->fd, pack, sizeof(pack));
-	if (n < 0) {
-		log_error("pppoe: read: %s\n", strerror(errno));
-		return 0;
-	}
+	while (1) {
+		n = read(h->fd, pack, sizeof(pack));
+		if (n < 0) {
+			if (errno == EAGAIN)
+				break;
+			log_error("pppoe: read: %s\n", strerror(errno));
+			return 0;
+		}
 
-	if (n < ETH_HLEN + sizeof(*hdr)) {
-		if (conf_verbose)
-			log_warn("pppoe: short packet received (%i)\n", n);
-		return 0;
-	}
+		if (n < ETH_HLEN + sizeof(*hdr)) {
+			if (conf_verbose)
+				log_warn("pppoe: short packet received (%i)\n", n);
+			return 0;
+		}
 
-	if (memcmp(ethhdr->h_dest, bc_addr, ETH_ALEN) && memcmp(ethhdr->h_dest, serv->hwaddr, ETH_ALEN))
-		return 0;
+		if (memcmp(ethhdr->h_dest, bc_addr, ETH_ALEN) && memcmp(ethhdr->h_dest, serv->hwaddr, ETH_ALEN))
+			return 0;
 
-	if (!memcmp(ethhdr->h_source, bc_addr, ETH_ALEN)) {
-		if (conf_verbose)
-			log_warn("pppoe: discarding packet (host address is broadcast)\n");
-		return 0;
-	}
+		if (!memcmp(ethhdr->h_source, bc_addr, ETH_ALEN)) {
+			if (conf_verbose)
+				log_warn("pppoe: discarding packet (host address is broadcast)\n");
+			return 0;
+		}
 
-	if ((ethhdr->h_source[0] & 1) != 0) {
-		if (conf_verbose)
-			log_warn("pppoe: discarding packet (host address is not unicast)\n");
-		return 0;
-	}
+		if ((ethhdr->h_source[0] & 1) != 0) {
+			if (conf_verbose)
+				log_warn("pppoe: discarding packet (host address is not unicast)\n");
+			return 0;
+		}
 
-	if (n < ETH_HLEN + sizeof(*hdr) + ntohs(hdr->length)) {
-		if (conf_verbose)
-			log_warn("pppoe: short packet received\n");
-		return 0;
-	}
+		if (n < ETH_HLEN + sizeof(*hdr) + ntohs(hdr->length)) {
+			if (conf_verbose)
+				log_warn("pppoe: short packet received\n");
+			return 0;
+		}
 
-	if (hdr->ver != 1) {
-		if (conf_verbose)
-			log_warn("pppoe: discarding packet (unsupported version %i)\n", hdr->ver);
-		return 0;
-	}
-	
-	if (hdr->type != 1) {
-		if (conf_verbose)
-			log_warn("pppoe: discarding packet (unsupported type %i)\n", hdr->type);
-	}
+		if (hdr->ver != 1) {
+			if (conf_verbose)
+				log_warn("pppoe: discarding packet (unsupported version %i)\n", hdr->ver);
+			return 0;
+		}
+		
+		if (hdr->type != 1) {
+			if (conf_verbose)
+				log_warn("pppoe: discarding packet (unsupported type %i)\n", hdr->type);
+		}
 
-	switch (hdr->code) {
-		case CODE_PADI:
-			pppoe_recv_PADI(serv, pack, n);
-			break;
-		case CODE_PADR:
-			pppoe_recv_PADR(serv, pack, n);
-			break;
-		case CODE_PADT:
-			pppoe_recv_PADT(serv, pack);
-			break;
+		switch (hdr->code) {
+			case CODE_PADI:
+				pppoe_recv_PADI(serv, pack, n);
+				break;
+			case CODE_PADR:
+				pppoe_recv_PADR(serv, pack, n);
+				break;
+			case CODE_PADT:
+				pppoe_recv_PADT(serv, pack);
+				break;
+		}
 	}
-
 	return 0;
 }
 
@@ -811,6 +814,11 @@ static void pppoe_start_server(const char *ifname)
 		goto out_err;
 	}
 
+	if (fcntl(sock, F_SETFL, O_NONBLOCK)) {
+    log_emerg("pppoe: failed to set nonblocking mode: %s\n", strerror(errno));
+		goto out_err;
+	}
+
 	serv->ctx.close = pppoe_serv_close;
 	serv->hnd.fd = sock;
 	serv->hnd.read = pppoe_serv_read;
diff --git a/accel-pptpd/ctrl/pppoe.h b/accel-pptpd/ctrl/pppoe/pppoe.h
index 0506108..0506108 100644
--- a/accel-pptpd/ctrl/pppoe.h
+++ b/accel-pptpd/ctrl/pppoe/pppoe.h
diff --git a/accel-pptpd/ctrl/pptp/CMakeLists.txt b/accel-pptpd/ctrl/pptp/CMakeLists.txt
new file mode 100644
index 0000000..19e53b2
--- /dev/null
+++ b/accel-pptpd/ctrl/pptp/CMakeLists.txt
@@ -0,0 +1,5 @@
+INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
+
+ADD_LIBRARY(pptp SHARED pptp.c)
+
+INSTALL(TARGETS pptp LIBRARY DESTINATION usr/lib/accel-pptp )
diff --git a/accel-pptpd/ctrl/pptp.c b/accel-pptpd/ctrl/pptp/pptp.c
index 1151dab..1151dab 100644
--- a/accel-pptpd/ctrl/pptp.c
+++ b/accel-pptpd/ctrl/pptp/pptp.c
diff --git a/accel-pptpd/ctrl/pptp_prot.h b/accel-pptpd/ctrl/pptp/pptp_prot.h
index ee8cb34..ee8cb34 100644
--- a/accel-pptpd/ctrl/pptp_prot.h
+++ b/accel-pptpd/ctrl/pptp/pptp_prot.h
diff --git a/accel-pptpd/radius/CMakeLists.txt b/accel-pptpd/radius/CMakeLists.txt
index b82512e..6872ee6 100644
--- a/accel-pptpd/radius/CMakeLists.txt
+++ b/accel-pptpd/radius/CMakeLists.txt
@@ -8,7 +8,7 @@ SET(sources
 	dm_coa.c
 )
 
-ADD_DEFINITIONS(-DDICT_PATH="${CMAKE_INSTALL_PREFIX}/usr/share/accel-pptp/dictionary")
+ADD_DEFINITIONS(-DDICTIONARY="${CMAKE_INSTALL_PREFIX}/usr/share/accel-pptp/radius/dictionary")
 
 ADD_LIBRARY(radius SHARED ${sources})
 
@@ -16,5 +16,5 @@ INSTALL(TARGETS radius
 	LIBRARY DESTINATION usr/lib/accel-pptp
 )
 FILE(GLOB dict "${CMAKE_CURRENT_SOURCE_DIR}/dict/*")
-INSTALL(FILES ${dict} DESTINATION usr/share/accel-pptp)
+INSTALL(FILES ${dict} DESTINATION usr/share/accel-pptp/radius)
 
diff --git a/accel-pptpd/radius/acct.c b/accel-pptpd/radius/acct.c
index a8346ed..d855d12 100644
--- a/accel-pptpd/radius/acct.c
+++ b/accel-pptpd/radius/acct.c
@@ -4,6 +4,8 @@
 #include <errno.h>
 #include <unistd.h>
 #include <sys/ioctl.h>
+#include <netinet/in.h>
+#include <linux/if.h>
 #include <linux/if_ppp.h>
 #include <openssl/md5.h>
 
diff --git a/accel-pptpd/radius/dict.c b/accel-pptpd/radius/dict.c
index 54cf895..0d63a83 100644
--- a/accel-pptpd/radius/dict.c
+++ b/accel-pptpd/radius/dict.c
@@ -79,7 +79,7 @@ static int dict_load(const char *fname)
 
 	f = fopen(fname, "r");
 	if (!f) {
-		log_error("radius: open dictioanary '%s': %s\n", fname, strerror(errno));
+		log_emerg("radius: open dictioanary '%s': %s\n", fname, strerror(errno));
 		return -1;
 	}
 	
@@ -94,7 +94,7 @@ static int dict_load(const char *fname)
 			if (!strcmp(buf, "BEGIN-VENDOR")) {
 				vendor = rad_dict_find_vendor_name(ptr[0]);
 				if (!vendor) {
-					log_error("radius:%s:%i: vendor not found\n", fname, n);
+					log_emerg("radius:%s:%i: vendor not found\n", fname, n);
 					goto out_err;
 				}
 				items = &vendor->items;
@@ -156,13 +156,13 @@ static int dict_load(const char *fname)
 				else if (!strcmp(ptr[2], "octets"))
 					attr->type = ATTR_TYPE_OCTETS;
 				else {
-					log_error("radius:%s:%i: unknown attribute type\n", fname, n);
+					log_emerg("radius:%s:%i: unknown attribute type\n", fname, n);
 					goto out_err;
 				}
 			} else if (!strcmp(buf, "VALUE")) {
 				attr = find_attr(items, ptr[0]);
 				if (!attr) {
-					log_error("radius:%s:%i: unknown attribute\n", fname, n);
+					log_emerg("radius:%s:%i: unknown attribute\n", fname, n);
 					goto out_err;
 				}
 				val = malloc(sizeof(*val));
@@ -200,7 +200,7 @@ static int dict_load(const char *fname)
 	return 0;
 
 out_err_syntax:
-	log_error("radius:%s:%i: syntaxis error\n", fname, n);
+	log_emerg("radius:%s:%i: syntaxis error\n", fname, n);
 out_err:
 	fclose(f);
 	return -1;
diff --git a/accel-pptpd/radius/radius.c b/accel-pptpd/radius/radius.c
index 9f5c7ff..817071e 100644
--- a/accel-pptpd/radius/radius.c
+++ b/accel-pptpd/radius/radius.c
@@ -309,7 +309,7 @@ static int parse_server(const char *opt, char **name, int *port, char **secret)
 static void __init radius_init(void)
 {
 	char *opt;
-	char *dict = DICT_PATH;
+	char *dict = DICTIONARY;
 
 	rpd_pool = mempool_create(sizeof(struct radius_pd_t));
 
diff --git a/rfc/rfc2661.txt b/rfc/rfc2661.txt
new file mode 100644
index 0000000..78f01d7
--- /dev/null
+++ b/rfc/rfc2661.txt
@@ -0,0 +1,4483 @@
+
+
+
+
+
+
+Network Working Group                                        W. Townsley
+Request for Comments: 2661                                   A. Valencia
+Category: Standards Track                                  cisco Systems
+                                                               A. Rubens
+                                                   Ascend Communications
+                                                                 G. Pall
+                                                                 G. Zorn
+                                                   Microsoft Corporation
+                                                               B. Palter
+                                                        Redback Networks
+                                                             August 1999
+
+
+                  Layer Two Tunneling Protocol "L2TP"
+
+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 (1999).  All Rights Reserved.
+
+Abstract
+
+   This document describes the Layer Two Tunneling Protocol (L2TP).  STD
+   51, RFC 1661 specifies multi-protocol access via PPP [RFC1661].  L2TP
+   facilitates the tunneling of PPP packets across an intervening
+   network in a way that is as transparent as possible to both end-users
+   and applications.
+
+Table of Contents
+
+   1.0 Introduction..........................................    3
+   1.1 Specification of Requirements.........................    4
+   1.2 Terminology...........................................    4
+   2.0 Topology..............................................    8
+   3.0 Protocol Overview.....................................    9
+   3.1 L2TP Header Format....................................    9
+   3.2 Control Message Types.................................   11
+   4.0 Control Message Attribute Value Pairs.................   12
+   4.1 AVP Format............................................   13
+   4.2 Mandatory AVPs........................................   14
+   4.3 Hiding of AVP Attribute Values........................   14
+
+
+
+Townsley, et al.            Standards Track                     [Page 1]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   4.4 AVP Summary...........................................   17
+      4.4.1 AVPs Applicable To All Control Messages..........   17
+      4.4.2 Result and Error Codes...........................   18
+      4.4.3 Control Connection Management AVPs...............   20
+      4.4.4 Call Management AVPs.............................   27
+      4.4.5 Proxy LCP and Authentication AVPs................   34
+      4.4.6 Call Status AVPs.................................   39
+   5.0 Protocol Operation....................................   41
+   5.1 Control Connection Establishment......................   41
+      5.1.1 Tunnel Authentication............................   42
+   5.2 Session Establishment.................................   42
+      5.2.1 Incoming Call Establishment......................   42
+      5.2.2 Outgoing Call Establishment......................   43
+   5.3 Forwarding PPP Frames.................................   43
+   5.4 Using Sequence Numbers on the Data Channel............   44
+   5.5 Keepalive (Hello).....................................   44
+   5.6 Session Teardown......................................   45
+   5.7 Control Connection Teardown...........................   45
+   5.8 Reliable Delivery of Control Messages.................   46
+   6.0 Control Connection Protocol Specification.............   48
+   6.1 Start-Control-Connection-Request (SCCRQ)..............   48
+   6.2 Start-Control-Connection-Reply (SCCRP)................   48
+   6.3 Start-Control-Connection-Connected (SCCCN)............   49
+   6.4 Stop-Control-Connection-Notification (StopCCN)........   49
+   6.5 Hello (HELLO).........................................   49
+   6.6 Incoming-Call-Request (ICRQ)..........................   50
+   6.7 Incoming-Call-Reply (ICRP)............................   51
+   6.8 Incoming-Call-Connected (ICCN)........................   51
+   6.9 Outgoing-Call-Request (OCRQ)..........................   52
+   6.10 Outgoing-Call-Reply (OCRP)...........................   53
+   6.11 Outgoing-Call-Connected (OCCN).......................   53
+   6.12 Call-Disconnect-Notify (CDN).........................   53
+   6.13 WAN-Error-Notify (WEN)...............................   54
+   6.14 Set-Link-Info (SLI)..................................   54
+   7.0 Control Connection State Machines.....................   54
+   7.1 Control Connection Protocol Operation.................   55
+   7.2 Control Connection States.............................   56
+      7.2.1 Control Connection Establishment.................   56
+   7.3 Timing considerations.................................   58
+   7.4 Incoming calls........................................   58
+      7.4.1 LAC Incoming Call States.........................   60
+      7.4.2 LNS Incoming Call States.........................   62
+   7.5 Outgoing calls........................................   63
+      7.5.1 LAC Outgoing Call States.........................   64
+      7.5.2 LNS Outgoing Call States.........................   66
+   7.6 Tunnel Disconnection..................................   67
+   8.0 L2TP Over Specific Media..............................   67
+   8.1 L2TP over UDP/IP......................................   68
+
+
+
+Townsley, et al.            Standards Track                     [Page 2]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   8.2 IP....................................................   69
+   9.0 Security Considerations...............................   69
+   9.1 Tunnel Endpoint Security..............................   70
+   9.2 Packet Level Security.................................   70
+   9.3 End to End Security...................................   70
+   9.4 L2TP and IPsec........................................   71
+   9.5 Proxy PPP Authentication..............................   71
+   10.0 IANA Considerations..................................   71
+   10.1 AVP Attributes.......................................   71
+   10.2 Message Type AVP Values..............................   72
+   10.3 Result Code AVP Values...............................   72
+      10.3.1 Result Code Field Values........................   72
+      10.3.2 Error Code Field Values.........................   72
+   10.4 Framing Capabilities & Bearer Capabilities...........   72
+   10.5 Proxy Authen Type AVP Values.........................   72
+   10.6 AVP Header Bits......................................   73
+   11.0 References...........................................   73
+   12.0 Acknowledgments......................................   74
+   13.0 Authors' Addresses...................................   75
+   Appendix A: Control Channel Slow Start and Congestion
+               Avoidance.....................................   76
+   Appendix B: Control Message Examples......................   77
+   Appendix C: Intellectual Property Notice..................   79
+   Full Copyright Statement..................................   80
+
+1.0 Introduction
+
+   PPP [RFC1661] defines an encapsulation mechanism for transporting
+   multiprotocol packets across layer 2 (L2) point-to-point links.
+   Typically, a user obtains a L2 connection to a Network Access Server
+   (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN,
+   ADSL, etc.)  and then runs PPP over that connection. In such a
+   configuration, the L2 termination point and PPP session endpoint
+   reside on the same physical device (i.e., the NAS).
+
+   L2TP extends the PPP model by allowing the L2 and PPP endpoints to
+   reside on different devices interconnected by a packet-switched
+   network.  With L2TP, a user has an L2 connection to an access
+   concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the
+   concentrator then tunnels individual PPP frames to the NAS. This
+   allows the actual processing of PPP packets to be divorced from the
+   termination of the L2 circuit.
+
+   One obvious benefit of such a separation is that instead of requiring
+   the L2 connection terminate at the NAS (which may require a
+   long-distance toll charge), the connection may terminate at a (local)
+   circuit concentrator, which then extends the logical PPP session over
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 3]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   a shared infrastructure such as frame relay circuit or the Internet.
+   From the user's perspective, there is no functional difference between
+   having the L2 circuit terminate in a NAS directly or using L2TP.
+
+   L2TP may also solve the multilink hunt-group splitting problem.
+   Multilink PPP [RFC1990] requires that all channels composing a
+   multilink bundle be grouped at a single Network Access Server (NAS).
+   Due to its ability to project a PPP session to a location other than
+   the point at which it was physically received, L2TP can be used to
+   make all channels terminate at a single NAS. This allows multilink
+   operation even when the calls are spread across distinct physical
+   NASs.
+
+   This document defines the necessary control protocol for on-demand
+   creation of tunnels between two nodes and the accompanying
+   encapsulation for multiplexing multiple, tunneled PPP sessions.
+
+1.1 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].
+
+1.2 Terminology
+
+   Analog Channel
+
+      A circuit-switched communication path which is intended to carry
+      3.1 kHz audio in each direction.
+
+   Attribute Value Pair (AVP)
+
+      The variable length concatenation of a unique Attribute
+      (represented by an integer) and a Value containing the actual
+      value identified by the attribute. Multiple AVPs make up Control
+      Messages which are used in the establishment, maintenance, and
+      teardown of tunnels.
+
+   Call
+
+      A connection (or attempted connection) between a Remote System and
+      LAC.  For example, a telephone call through the PSTN. A Call
+      (Incoming or Outgoing) which is successfully established between a
+      Remote System and LAC results in a corresponding L2TP Session
+      within a previously established Tunnel between the LAC and LNS.
+      (See also: Session, Incoming Call, Outgoing Call).
+
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 4]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Called Number
+
+      An indication to the receiver of a call as to what telephone
+      number the caller used to reach it.
+
+   Calling Number
+
+      An indication to the receiver of a call as to the telephone number
+      of the caller.
+
+   CHAP
+
+      Challenge Handshake Authentication Protocol [RFC1994], a PPP
+      cryptographic challenge/response authentication protocol in which
+      the cleartext password is not passed over the line.
+
+   Control Connection
+
+      A control connection operates in-band over a tunnel to control the
+      establishment, release, and maintenance of sessions and of the
+      tunnel itself.
+
+   Control Messages
+
+      Control messages are exchanged between LAC and LNS pairs,
+      operating in-band within the tunnel protocol. Control messages
+      govern aspects of the tunnel and sessions within the tunnel.
+
+   Digital Channel
+
+      A circuit-switched communication path which is intended to carry
+      digital information in each direction.
+
+   DSLAM
+
+      Digital Subscriber Line (DSL) Access Module. A network device used
+      in the deployment of DSL service. This is typically a concentrator
+      of individual DSL lines located in a central office (CO) or local
+      exchange.
+
+   Incoming Call
+
+      A Call received at an LAC to be tunneled to an LNS (see Call,
+      Outgoing Call).
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 5]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   L2TP Access Concentrator (LAC)
+
+      A node that acts as one side of an L2TP tunnel endpoint and is a
+      peer to the L2TP Network Server (LNS).  The LAC sits between an
+      LNS and a remote system and forwards packets to and from each.
+      Packets sent from the LAC to the LNS requires tunneling with the
+      L2TP protocol as defined in this document.  The connection from
+      the LAC to the remote system is either local (see: Client LAC) or
+      a PPP link.
+
+   L2TP Network Server (LNS)
+
+      A node that acts as one side of an L2TP tunnel endpoint and is a
+      peer to the L2TP Access Concentrator (LAC).  The LNS is the
+      logical termination point of a PPP session that is being tunneled
+      from the remote system by the LAC.
+
+   Management Domain (MD)
+
+      A network or networks under the control of a single
+      administration, policy or system. For example, an LNS's Management
+      Domain might be the corporate network it serves. An LAC's
+      Management Domain might be the Internet Service Provider that owns
+      and manages it.
+
+   Network Access Server (NAS)
+
+      A device providing local network access to users across a remote
+      access network such as the PSTN. An NAS may also serve as an LAC,
+      LNS or both.
+
+   Outgoing Call
+
+      A Call placed by an LAC on behalf of an LNS (see Call, Incoming
+      Call).
+
+   Peer
+
+      When used in context with L2TP, peer refers to either the LAC or
+      LNS. An LAC's Peer is an LNS and vice versa. When used in context
+      with PPP, a peer is either side of the PPP connection.
+
+   POTS
+
+      Plain Old Telephone Service.
+
+
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 6]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Remote System
+
+      An end-system or router attached to a remote access network (i.e.
+      a PSTN), which is either the initiator or recipient of a call.
+      Also referred to as a dial-up or virtual dial-up client.
+
+   Session
+
+      L2TP is connection-oriented. The LNS and LAC maintain state for
+      each Call that is initiated or answered by an LAC. An L2TP Session
+      is created between the LAC and LNS when an end-to-end PPP
+      connection is established between a Remote System and the LNS.
+      Datagrams related to the PPP connection are sent over the Tunnel
+      between the LAC and LNS. There is a one to one relationship
+      between established L2TP Sessions and their associated Calls. (See
+      also: Call).
+
+   Tunnel
+
+      A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a
+      Control Connection and zero or more L2TP Sessions. The Tunnel
+      carries encapsulated PPP datagrams and Control Messages between
+      the LAC and the LNS.
+
+   Zero-Length Body (ZLB) Message
+
+      A control packet with only an L2TP header. ZLB messages are used
+      for explicitly acknowledging packets on the reliable control
+      channel.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 7]
+
+RFC 2661                          L2TP                       August 1999
+
+
+2.0 Topology
+
+   The following diagram depicts a typical L2TP scenario. The goal is to
+   tunnel PPP frames between the Remote System or LAC Client and an LNS
+   located at a Home LAN.
+
+                                                    [Home LAN]
+            [LAC Client]----------+                     |
+                              ____|_____                +--[Host]
+                             |          |               |
+               [LAC]---------| Internet |-----[LNS]-----+
+                 |           |__________|               |
+            _____|_____                                 :
+           |           |
+           |  PSTN     |
+ [Remote]--|  Cloud    |
+ [System]  |           |                            [Home LAN]
+           |___________|                                |
+                 |          ______________              +---[Host]
+                 |         |              |             |
+               [LAC]-------| Frame Relay  |---[LNS]-----+
+                           | or ATM Cloud |             |
+                           |______________|             :
+
+   The Remote System initiates a PPP connection across the PSTN Cloud to
+   an LAC. The LAC then tunnels the PPP connection across the Internet,
+   Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is
+   obtained. The Remote System is provided addresses from the HOME LAN
+
+   via PPP NCP negotiation. Authentication, Authorization and Accounting
+   may be provided by the Home LAN's Management Domain as if the user
+   were connected to a Network Access Server directly.
+
+   A LAC Client (a Host which runs L2TP natively) may also participate
+   in tunneling to the Home LAN without use of a separate LAC. In this
+   case, the Host containing the LAC Client software already has a
+   connection to the public Internet. A "virtual" PPP connection is then
+   created and the local L2TP LAC Client software creates a tunnel to
+   the LNS. As in the above case, Addressing, Authentication,
+   Authorization and Accounting will be provided by the Home LAN's
+   Management Domain.
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 8]
+
+RFC 2661                          L2TP                       August 1999
+
+
+3.0 Protocol Overview
+
+   L2TP utilizes two types of messages, control messages and data
+   messages. Control messages are used in the establishment, maintenance
+   and clearing of tunnels and calls. Data messages are used to
+   encapsulate PPP frames being carried over the tunnel. Control
+   messages utilize a reliable Control Channel within L2TP to guarantee
+   delivery (see section 5.1 for details). Data messages are not
+   retransmitted when packet loss occurs.
+
+   +-------------------+
+   | PPP Frames        |
+   +-------------------+    +-----------------------+
+   | L2TP Data Messages|    | L2TP Control Messages |
+   +-------------------+    +-----------------------+
+   | L2TP Data Channel |    | L2TP Control Channel  |
+   | (unreliable)      |    | (reliable)            |
+   +------------------------------------------------+
+   |      Packet Transport (UDP, FR, ATM, etc.)     |
+   +------------------------------------------------+
+
+   Figure 3.0 L2TP Protocol Structure
+
+   Figure 3.0 depicts the relationship of PPP frames and Control
+   Messages over the L2TP Control and Data Channels. PPP Frames are
+   passed over an unreliable Data Channel encapsulated first by an L2TP
+   header and then a Packet Transport such as UDP, Frame Relay, ATM,
+   etc. Control messages are sent over a reliable L2TP Control Channel
+   which transmits packets in-band over the same Packet Transport.
+
+   Sequence numbers are required to be present in all control messages
+   and are used to provide reliable delivery on the Control Channel.
+   Data Messages may use sequence numbers to reorder packets and detect
+   lost packets.
+
+   All values are placed into their respective fields and sent in
+   network order (high order octets first).
+
+3.1 L2TP Header Format
+
+   L2TP packets for the control channel and data channel share a common
+   header format. In each case where a field is optional, its space does
+   not exist in the message if the field is marked not present. Note
+   that while optional on data messages, the Length, Ns, and Nr fields
+   marked as optional below, are required to be present on all control
+   messages.
+
+
+
+
+
+Townsley, et al.            Standards Track                     [Page 9]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   This header is formatted:
+
+    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|O|P|x|x|x|x|  Ver  |          Length (opt)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tunnel ID           |           Session ID          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             Ns (opt)          |             Nr (opt)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Offset Size (opt)        |    Offset pad... (opt)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 3.1 L2TP Message Header
+
+   The Type (T) bit indicates the type of message. It is set to 0 for a
+   data message and 1 for a control message.
+
+   If the Length (L) bit is 1, the Length field is present. This bit
+   MUST be set to 1 for control messages.
+
+   The x bits are reserved for future extensions. All reserved bits MUST
+   be set to 0 on outgoing messages and ignored on incoming messages.
+
+   If the Sequence (S) bit is set to 1 the Ns and Nr fields are present.
+   The S bit MUST be set to 1 for control messages.
+
+   If the Offset (O) bit is 1, the Offset Size field is present. The O
+   bit MUST be set to 0 (zero) for control messages.
+
+   If the Priority (P) bit is 1, this data message should receive
+   preferential treatment in its local queuing and transmission.  LCP
+   echo requests used as a keepalive for the link, for instance, should
+   generally be sent with this bit set to 1. Without it, a temporary
+   interval of local congestion could result in interference with
+   keepalive messages and unnecessary loss of the link. This feature is
+   only for use with data messages. The P bit MUST be set to 0 for all
+   control messages.
+
+   Ver MUST be 2, indicating the version of the L2TP data message header
+   described in this document. The value 1 is reserved to permit
+   detection of L2F [RFC2341] packets should they arrive intermixed with
+   L2TP packets. Packets received with an unknown Ver field MUST be
+   discarded.
+
+   The Length field indicates the total length of the message in octets.
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 10]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Tunnel ID indicates the identifier for the control connection. L2TP
+   tunnels are named by identifiers that have local significance only.
+   That is, the same tunnel will be given different Tunnel IDs by each
+   end of the tunnel. Tunnel ID in each message is that of the intended
+   recipient, not the sender. Tunnel IDs are selected and exchanged as
+   Assigned Tunnel ID AVPs during the creation of a tunnel.
+
+   Session ID indicates the identifier for a session within a tunnel.
+   L2TP sessions are named by identifiers that have local significance
+   only. That is, the same session will be given different Session IDs
+   by each end of the session. Session ID in each message is that of the
+   intended recipient, not the sender. Session IDs are selected and
+   exchanged as Assigned Session ID AVPs during the creation of a
+   session.
+
+   Ns indicates the sequence number for this data or control message,
+   beginning at zero and incrementing by one (modulo 2**16) for each
+   message sent. See Section 5.8 and 5.4 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). In data messages, Nr is
+   reserved and, if present (as indicated by the S-bit), MUST be ignored
+   upon receipt. See section 5.8 for more information on using this
+   field in control messages.
+
+   The Offset Size field, if present, specifies the number of octets
+   past the L2TP header at which the payload data is expected to start.
+   Actual data within the offset padding is undefined. If the offset
+   field is present, the L2TP header ends after the last octet of the
+   offset padding.
+
+3.2 Control Message Types
+
+   The Message Type AVP (see section 4.4.1) defines the specific type of
+   control message being sent. Recall from section 3.1 that this is only
+   for control messages, that is, messages with the T-bit set to 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 11]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   This document defines the following control message types (see
+   Section 6.1 through 6.14 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
+
+   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
+
+   PPP Session Control
+
+      16 (SLI)      Set-Link-Info
+
+4.0 Control Message Attribute Value Pairs
+
+   To maximize extensibility while still permitting interoperability, a
+   uniform method for encoding message types and bodies is used
+   throughout L2TP.  This encoding will be termed AVP (Attribute-Value
+   Pair) in the remainder of this document.
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 12]
+
+RFC 2661                          L2TP                       August 1999
+
+
+4.1 AVP Format
+
+   Each AVP is encoded as:
+
+    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 are a bit mask, describing the general attributes
+   of the AVP.
+
+   Two bits are defined in this document, the remaining are reserved for
+   future extensions.  Reserved bits MUST be set to 0. An AVP received
+   with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
+
+   Mandatory (M) bit: Controls the behavior required of an
+   implementation which receives an AVP which it does not recognize. If
+   the M bit is set on an unrecognized AVP within a message associated
+   with a particular session, the session associated with this message
+   MUST be terminated. If the M bit is set on an unrecognized AVP within
+   a message associated with the overall tunnel, the entire tunnel (and
+   all sessions within) MUST be terminated. If the M bit is not set, an
+   unrecognized AVP MUST be ignored. The control message must then
+   continue to be processed as if the AVP had not been present.
+
+   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 4.3 describes the procedure for performing AVP hiding.
+
+   Length: Encodes the number of octets (including the Overall Length
+   and bitmask 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 their own L2TP
+   extensions can use their own Vendor ID along with private Attribute
+
+
+
+Townsley, et al.            Standards Track                    [Page 13]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   values, guaranteeing that they will not collide with any other
+   vendor's extensions, nor with 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.
+
+4.2 Mandatory AVPs
+
+   Receipt of an unknown AVP that has the M-bit set is catastrophic to
+   the session or tunnel it is associated with. Thus, the M bit should
+   only be defined for AVPs which are absolutely crucial to proper
+   operation of the session or tunnel. Further, in the case where the
+   LAC or LNS receives an unknown AVP with the M-bit set and shuts down
+   the session or tunnel accordingly, it is the full responsibility of
+   the peer sending the Mandatory AVP to accept fault for causing an
+   non-interoperable situation. Before defining an AVP with the M-bit
+   set, particularly a vendor-specific AVP, be sure that this is the
+   intended consequence.
+
+   When an adequate alternative exists to use of the M-bit, it should be
+   utilized. For example, rather than simply sending an AVP with the M-
+   bit set to determine if a specific extension exists, availability may
+   be identified by sending an AVP in a request message and expecting a
+   corresponding AVP in a reply message.
+
+   Use of the M-bit with new AVPs (those not defined in this document)
+   MUST provide the ability to configure the associated feature off,
+   such that the AVP is either not sent, or sent with the M-bit not set.
+
+4.3 Hiding of AVP Attribute Values
+
+   The H bit in the header of each AVP provides a mechanism to indicate
+   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 or user IDs.
+
+   The H bit MUST only be set if a shared secret exists between the LAC
+   and LNS. The shared secret is the same secret that is used for tunnel
+   authentication (see Section 5.1.1).  If the H bit is set in any
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 14]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   AVP(s) in a given control message, a Random Vector AVP must also be
+   present in the message and MUST precede the first AVP having an H bit
+   of 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 a Hidden AVP Subformat as follows:
+
+    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 which 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 will become 6 + Attribute Value length + size
+   of the Length of Original Attribute Value field + Padding. Thus, if
+   Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24
+   octets.
+
+   Next, An MD5 hash is performed on the concatenation of:
+
+   + the 2 octet Attribute number of the AVP
+   + the shared secret
+   + 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
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 15]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   message. If a different random vector is used for the hiding of
+   subsequent AVPs then a new Random Vector AVP must be placed in the
+   command 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, but 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 secret
+   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 secret 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 RFC 2138 [RFC2138] 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 secret S, the Random Vector RV, and the Attribute
+   Value AV. Break the value field into 16-octet chunks p1, p2, etc.
+   with the last one padded at the end with random data to a 16-octet
+   boundary.  Call the ciphertext blocks c(1), c(2), etc.  We will also
+   define intermediate values b1, b2, etc.
+
+          b1 = MD5(AV + S + RV)   c(1) = p1 xor b1
+          b2 = MD5(S  + c(1))     c(2) = p2 xor b2
+                      .                       .
+                      .                       .
+                      .                       .
+          bi = MD5(S  + c(i-1))   c(i) = pi xor bi
+
+   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.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 16]
+
+RFC 2661                          L2TP                       August 1999
+
+
+4.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.
+
+4.4.1 AVPs Applicable To All Control Messages
+
+   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.1). See Section 3.2 for the list of defined control
+      message types and their identifiers.
+
+      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. Thus, if the
+      M-bit is set within the Message Type AVP and the Message Type is
+      unknown to the implementation, the tunnel 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 may not be hidden (the H-bit
+      MUST be 0).  The Length of this AVP is 8.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 17]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Random Vector (All Messages)
+
+      The Random Vector AVP, Attribute Type 36, is used to enable the
+      hiding of the Attribute Value of arbitrary AVPs.
+
+      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 ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Random Octet String may be of arbitrary length, although a
+      random vector of 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
+      4.2).
+
+      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.  This AVP MUST precede the first AVP with the H bit
+      set.
+
+      The M-bit for this AVP MUST be set to 1.  This AVP MUST NOT be
+      hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the
+      length of the Random Octet String.
+
+4.4.2 Result and Error Codes
+
+   Result Code (CDN, StopCCN)
+
+      The Result Code AVP, Attribute Type 1, indicates the reason for
+      terminating the control channel or session.
+
+      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 (opt)       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Error Message (opt) ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      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
+
+
+
+Townsley, et al.            Standards Track                    [Page 18]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      Message are 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 using the
+      Default Language [RFC2277].
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
+      this AVP MUST be set to 1.  The Length is 8 if there is no Error
+      Code or Message, 10 if there is an Error Code and no Error Message
+      or 10 + the length of the Error Message if there is an Error Code
+      and Message.
+
+      Defined Result Code values for the StopCCN message are:
+
+         0 - Reserved
+         1 - General request to clear control connection
+         2 - General error--Error Code indicates the problem
+         3 - Control channel already exists
+         4 - Requester is not authorized to establish a control
+             channel
+         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
+
+      Defined Result Code values for the CDN message are:
+
+         0 - Reserved
+         1 - Call disconnected due to loss of carrier
+         2 - Call disconnected for the reason indicated
+             in error code
+         3 - Call disconnected for administrative reasons
+         4 - Call failed due to lack of appropriate facilities
+             being available (temporary condition)
+         5 - Call failed due to lack of appropriate facilities being
+             available (permanent condition)
+         6 - Invalid destination
+         7 - Call failed due to no carrier detected
+         8 - Call failed due to detection of a busy signal
+         9 - Call failed due to lack of a dial tone
+         10 - Call was not established within time allotted by LAC
+         11 - Call was connected but no appropriate framing was
+              detected
+
+      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
+
+
+
+Townsley, et al.            Standards Track                    [Page 19]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      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:
+
+         0 - No general error
+         1 - No control connection exists yet for this LAC-LNS pair
+         2 - Length is wrong
+         3 - One of the field values was out of range or
+             reserved field was non-zero
+         4 - Insufficient resources to handle this operation now
+         5 - The Session ID is invalid in this context
+         6 - A generic vendor-specific error occurred in the LAC
+         7 - Try another.  If LAC is aware of other possible LNS
+             destinations, it should try one of them.  This can be
+             used to guide an LAC based on LNS policy, for instance,
+             the existence of multilink PPP bundles.
+         8 - Session or tunnel was shutdown due to receipt of an unknown
+             AVP with the M-bit set (see section 4.2). The Error Message
+             SHOULD contain the attribute of the offending AVP in (human
+             readable) text form.
+
+      When a General Error Code of 6 is used, additional information
+      about the error SHOULD be included in the Error Message field.
+
+4.4.3 Control Connection Management AVPs
+
+   Protocol Version (SCCRP, SCCRQ)
+
+      The Protocol Version AVP, Attribute Type 2, indicates the L2TP
+      protocol version of the sender.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Ver      |     Rev       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Ver field is a 1 octet unsigned integer containing the value
+      1. Rev field is a 1 octet unsigned integer containing 0. This
+      pertains to L2TP protocol version 1, revision 0. Note this is not
+      the same version number that is included in the header of each
+      message.
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
+      this AVP MUST be set to 1.  The Length of this AVP is 8.
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 20]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Framing Capabilities (SCCRP, SCCRQ)
+
+      The Framing Capabilities AVP, Attribute Type 3, provides the peer
+      with an indication of the types of framing that will be accepted
+      or requested 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Reserved for future framing type definitions          |A|S|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Attribute Value field is a 32-bit mask, with two bits defined.
+      If bit A is set, asynchronous framing is supported. If bit S is
+      set, synchronous framing is supported.
+
+      A peer MUST NOT request an incoming or outgoing call with a
+      Framing Type AVP specifying a value not advertised in the Framing
+      Capabilities AVP it received during control connection
+      establishment.  Attempts to do so will result in the call being
+      rejected.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) is 10.
+
+   Bearer Capabilities (SCCRP, SCCRQ)
+
+      The Bearer Capabilities AVP, Attribute Type 4, provides the peer
+      with an indication of the bearer device types supported by the
+      hardware interfaces of the sender for outgoing calls.
+
+      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 for future bearer type definitions           |A|D|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      This is a 32-bit mask, with two bits defined. If bit A is set,
+      analog access is supported. If bit D is set, digital access is
+      supported.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 21]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      An LNS should not request an outgoing call specifying a value in
+      the Bearer Type AVP for a device type not advertised in the Bearer
+      Capabilities AVP it received from the LAC during control
+      connection establishment. Attempts to do so will result in the
+      call being rejected.
+
+      This AVP MUST be present if the sender can place outgoing calls
+      when requested.
+
+      Note that an LNS that cannot act as an LAC as well will not
+      support hardware devices for handling incoming and outgoing calls
+      and should therefore set the A and D bits of this AVP to 0, or
+      should not send the AVP at all. An LNS that can also act as an LAC
+      and place outgoing calls should set A or D as appropriate.
+      Presence of this message is not a guarantee that a given outgoing
+      call will be placed by the sender if requested, just that the
+      physical capability exists.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) is 10.
+
+   Tie Breaker (SCCRQ)
+
+      The Tie Breaker AVP, Attribute Type 5, indicates that the sender
+      wishes a single tunnel to exist between the given LAC-LNS pair.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Tie Break Value...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                                 ...(64 bits)         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Tie Breaker Value is an 8 octet value that is used to choose a
+      single tunnel where both LAC and LNS request a tunnel
+      concurrently. The recipient of a SCCRQ must check to see if a
+      SCCRQ has been sent to the peer, and if so, must compare its Tie
+      Breaker value with the received one. The lower value "wins", and
+      the "loser" MUST silently discard its tunnel. In the case where a
+      tie breaker is present on both sides, and the value is equal, both
+      sides MUST discard their tunnels.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 22]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      If a tie breaker is received, and an outstanding SCCRQ had no tie
+      breaker value, the initiator which included the Tie Breaker AVP
+      "wins". If neither side issues a tie breaker, then two separate
+      tunnels are opened.
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
+      this AVP MUST be set to 0.  The Length of this AVP is 14.
+
+   Firmware Revision (SCCRP, SCCRQ)
+
+      The Firmware Revision AVP, Attribute Type 6, indicates the
+      firmware revision of the issuing device.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       Firmware Revision       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Firmware Revision is a 2 octet unsigned integer encoded in a
+      vendor specific format.
+
+      For devices which do not have a firmware revision (general purpose
+      computers running L2TP software modules, for instance), the
+      revision of the L2TP software module may be reported instead.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) is 8.
+
+   Host Name (SCCRP, SCCRQ)
+
+      The Host Name AVP, Attribute Type 7, indicates the name of the
+      issuing LAC or LNS.
+
+      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.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 23]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      This name should be as broadly unique as possible; for hosts
+      participating in DNS [RFC1034], a hostname with fully qualified
+      domain would be appropriate.
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
+      this AVP MUST be set to 1.  The Length of this AVP is 6 plus the
+      length of the Host Name.
+
+   Vendor Name (SCCRP, SCCRQ)
+
+      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 UTF-8 charset using the Default Language [RFC2277].
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Vendor Name.
+
+   Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
+
+      The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being
+      assigned to this tunnel by the sender.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Assigned Tunnel ID       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.
+
+      The Assigned Tunnel ID AVP establishes a value used to multiplex
+      and demultiplex multiple tunnels between the LNS and LAC. The L2TP
+      peer MUST place this value in the Tunnel ID header field of all
+
+
+
+Townsley, et al.            Standards Track                    [Page 24]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      control and data messages that it subsequently transmits over the
+      associated tunnel.  Before the Assigned Tunnel ID AVP is received
+      from a peer, messages MUST be sent to that peer with a Tunnel ID
+      value of 0 in the header of all control messages.
+
+      In the StopCCN control message, the Assigned Tunnel ID AVP MUST be
+      the same as the Assigned Tunnel ID AVP first sent to the receiving
+      peer, permitting the peer to identify the appropriate tunnel even
+      if a StopCCN is sent before an Assigned Tunnel ID AVP is received.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 8.
+
+   Receive Window Size (SCCRQ, SCCRP)
+
+      The Receive Window Size AVP, Attribute Type 10, specifies the
+      receive window size being offered to the remote peer.
+
+      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.
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
+      this AVP MUST be set to 1.  The Length of this AVP is 8.
+
+   Challenge (SCCRP, SCCRQ)
+
+      The Challenge AVP, Attribute Type 11, indicates that the issuing
+      peer wishes to authenticate the tunnel endpoints using a CHAP-
+      style authentication mechanism.
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 25]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Challenge ... (arbitrary number of octets)
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Challenge is one or more octets of random data.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Challenge.
+
+   Challenge Response (SCCCN, SCCRP)
+
+      The Response AVP, Attribute Type 13, provides a response to a
+      challenge received.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Response ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                              ... (16 octets)         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Response is a 16 octet value reflecting the CHAP-style
+      [RFC1994] response to the challenge.
+
+      This AVP MUST be present in an SCCRP or SCCCN if a challenge was
+      received in the preceding SCCRQ or SCCRP. For purposes of the ID
+      value in the CHAP response calculation, the value of the Message
+      Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for
+      an SCCCN).
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 22.
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 26]
+
+RFC 2661                          L2TP                       August 1999
+
+
+4.4.4 Call Management AVPs
+
+   Q.931 Cause Code (CDN)
+
+      The Q.931 Cause Code AVP, Attribute Type 12, is used to give
+      additional information in case of unsolicited call disconnection.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Cause Code           |   Cause Msg   | Advisory Msg...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Cause Code is the returned Q.931 Cause code, and Cause Msg is the
+      returned Q.931 message code (e.g., DISCONNECT) associated with the
+      Cause Code.  Both values are returned in their native ITU
+      encodings [DSS1]. An additional ASCII text Advisory Message may
+      also be included (presence indicated by the AVP Length) to further
+      explain the reason for disconnecting.
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
+      this AVP MUST be set to 1.  The Length of this AVP is 9, plus the
+      size of the Advisory Message.
+
+   Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
+
+      The Assigned Session ID AVP, Attribute Type 14, encodes the ID
+      being assigned to this session by the sender.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Assigned Session ID       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Assigned Session ID is a 2 octet non-zero unsigned integer.
+
+      The Assigned Session ID AVP is establishes a value used to
+      multiplex and demultiplex data sent over a tunnel between the LNS
+      and LAC. The L2TP peer MUST place this value in the Session ID
+      header field of all control and data messages that it subsequently
+      transmits over the tunnel that belong to this session.  Before the
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 27]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      Assigned Session ID AVP is received from a peer, messages MUST be
+      sent to that peer with a Session ID of 0 in the header of all
+      control messages.
+
+      In the CDN control message, the same Assigned Session ID AVP first
+      sent to the receiving peer is used, permitting the peer to
+      identify the appropriate tunnel even if CDN is sent before an
+      Assigned Session ID is received.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 8.
+
+   Call Serial Number (ICRQ, OCRQ)
+
+      The Call Serial Number AVP, Attribute Type 15, encodes an
+      identifier assigned by the LAC or LNS to this 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Call Serial Number                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Call Serial Number is a 32 bit value.
+
+      The Call Serial Number is intended to be an easy reference for
+      administrators on both ends of a tunnel to use when investigating
+      call failure problems. Call 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.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 10.
+
+   Minimum BPS (OCRQ)
+
+      The Minimum BPS AVP, Attribute Type 16, encodes the lowest
+      acceptable line speed for this call.
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 28]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Minimum BPS                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The  Minimum BPS is a 32 bit value indicates the speed in bits per
+      second.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 10.
+
+   Maximum BPS (OCRQ)
+
+      The Maximum BPS AVP, Attribute Type 17, encodes the highest
+      acceptable line speed for this 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Maximum BPS                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Maximum BPS is a 32 bit value indicates the speed in bits per
+      second.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 10.
+
+   Bearer Type (ICRQ, OCRQ)
+
+      The Bearer Type AVP, Attribute Type 18,  encodes the bearer type
+      for the incoming or outgoing 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Reserved for future Bearer Types                |A|D|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 29]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      The Bearer Type is a 32-bit bit mask, which indicates the bearer
+      capability of the call (ICRQ) or required for the call (OCRQ). If
+      set, bit A indicates that the call refers to an analog channel. If
+      set, bit D indicates that the call refers to a digital channel.
+      Both may be set, indicating that the call was either
+      indistinguishable, or can be placed on either type of channel.
+
+      Bits in the Value field of this AVP MUST only be set by the LNS
+      for an OCRQ if it was set in the Bearer Capabilities AVP received
+      from the LAC during control connection establishment.
+
+      It is valid to set neither the A nor D bits in an ICRQ. Such a
+      setting may indicate that the call was not received over a
+      physical link (e.g if the LAC and PPP are located in the same
+      subsystem).
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 10.
+
+   Framing Type (ICCN, OCCN, OCRQ)
+
+      The Framing Type AVP, Attribute Type 19, encodes the framing type
+      for the incoming or outgoing 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Reserved for future Framing Types               |A|S|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Framing Type is a 32-bit mask, which indicates the type of PPP
+      framing requested for an OCRQ, or the type of PPP framing
+      negotiated for an OCCN or ICCN. The framing type MAY be used as an
+      indication to PPP on the LNS as to what link options to use for
+      LCP negotiation [RFC1662].
+
+      Bit A indicates asynchronous framing. Bit S indicates synchronous
+      framing. For an OCRQ, both may be set, indicating that either type
+      of framing may be used.
+
+      Bits in the Value field of this AVP MUST only be set by the LNS
+      for an OCRQ if it was set in the Framing Capabilities AVP received
+      from the LAC during control connection establishment.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 30]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 10.
+
+   Called Number (ICRQ, OCRQ)
+
+      The Called Number AVP, Attribute Type 21, encodes the telephone
+      number to be called for an OCRQ, and the Called number for an
+      ICRQ.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Called Number... (arbitrary number of octets)                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Called Number is an ASCII string. Contact between the
+      administrator of the LAC and the LNS may be necessary to
+      coordinate interpretation of the value needed in this AVP.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Called Number.
+
+   Calling Number (ICRQ)
+
+      The Calling Number AVP, Attribute Type 22, encodes the originating
+      number for the incoming 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Calling Number... (arbitrary number of octets)                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Calling Number is an ASCII string. Contact between the
+      administrator of the LAC and the LNS may be necessary to
+      coordinate interpretation of the value in this AVP.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Calling Number.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 31]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Sub-Address (ICRQ, OCRQ)
+
+      The Sub-Address AVP, Attribute Type 23, encodes additional dialing
+      information.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Sub-Address ... (arbitrary number of octets)                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Sub-Address is an ASCII string. Contact between the
+      administrator of the LAC and the LNS may be necessary to
+      coordinate interpretation of the value in this AVP.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Sub-Address.
+
+   (Tx) Connect Speed (ICCN, OCCN)
+
+      The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             BPS                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
+      in bits per second.
+
+      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 (e.g. 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
+      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 MUST be set to 1.  The Length (before hiding) of this AVP
+      is 10.
+
+
+
+Townsley, et al.            Standards Track                    [Page 32]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Rx Connect Speed (ICCN, OCCN)
+
+      The Rx Connect Speed AVP, Attribute Type 38, represents the speed
+      of the connection from the perspective of the LAC (e.g. 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           BPS (H)             |            BPS (L)            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      BPS is a 4 octet value indicating the speed in bits per second.
+
+      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 1 or 0).  The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 10.
+
+   Physical Channel ID (ICRQ, OCRP)
+
+      The Physical Channel ID AVP, Attribute Type 25, encodes 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                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      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 MUST be set to 0.  The Length (before hiding) of this AVP
+      is 10.
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 33]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Private Group ID (ICCN)
+
+      The Private Group ID AVP, Attribute Type 37, is used by the LAC to
+      indicate that this call is to be associated with a particular
+      customer group.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Private Group ID ... (arbitrary number of octets)           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Private Group ID is a string of octets of arbitrary length.
+
+      The LNS MAY treat the PPP session as well as network traffic
+      through this session in a special manner determined by the peer.
+      For example, if the LNS is individually connected to several
+      private networks using unregistered addresses, this AVP may be
+      included by the LAC to indicate that a given call should be
+      associated with one of the private networks.
+
+      The Private Group ID is a string corresponding to a table in the
+      LNS that defines the particular characteristics of the selected
+      group.  A LAC MAY determine the Private Group ID from a RADIUS
+      response, local configuration, or some other source.
+
+      This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Private Group ID.
+
+   Sequencing Required (ICCN, OCCN)
+
+      The Sequencing Required AVP, Attribute Type 39, indicates to the
+      LNS that Sequence Numbers MUST always be present on the data
+      channel.
+
+      This AVP has no Attribute Value field.
+
+      This AVP MUST NOT be hidden (the H-bit MUST be 0).  The M-bit for
+      this AVP MUST be set to 1.  The Length of this AVP is 6.
+
+4.4.5 Proxy LCP and Authentication AVPs
+
+      The LAC may have answered the call and negotiated LCP with the
+      remote system, perhaps in order to establish the system's apparent
+      identity. In this case, these AVPs may be included to indicate the
+
+
+
+Townsley, et al.            Standards Track                    [Page 34]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      link properties the remote system initially requested, properties
+      the remote system and LAC ultimately negotiated, as well as PPP
+      authentication information sent and received by the LAC. This
+      information may be used to initiate the PPP LCP and authentication
+      systems on the LNS, allowing PPP to continue without renegotiation
+      of LCP. Note that the LNS policy may be to enter an additional
+      round of LCP negotiation and/or authentication if the LAC is not
+      trusted.
+
+   Initial Received LCP CONFREQ (ICCN)
+
+      In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
+      provides the LNS with the Initial CONFREQ received by the LAC from
+      the PPP 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | LCP CONFREQ... (arbitrary number of octets)                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      LCP CONFREQ is a copy of the body of the initial CONFREQ received,
+      starting at the first option within the body of the LCP message.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6 plus the length of the CONFREQ.
+
+   Last Sent LCP CONFREQ (ICCN)
+
+      In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the
+      LNS with the Last CONFREQ sent by the LAC to the PPP 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | LCP CONFREQ... (arbitrary number of octets)                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
+      the client to complete LCP negotiation, starting at the first
+      option within the body of the LCP message.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 35]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6 plus the length of the CONFREQ.
+
+   Last Received LCP CONFREQ (ICCN)
+
+      The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
+      LNS with the Last CONFREQ received by the LAC from the PPP 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | LCP CONFREQ... (arbitrary number of octets)                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The LCP CONFREQ is a copy of the body of the final CONFREQ
+      received from the client to complete LCP negotiation, starting at
+      the first option within the body of the LCP message.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6 plus the length of the CONFREQ.
+
+   Proxy Authen Type (ICCN)
+
+      The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
+      authentication should be used.
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Authen Type          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Authen Type is a 2 octet unsigned integer, holding:
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 8.
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 36]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      Defined Authen Type values are:
+         0 - Reserved
+         1 - Textual username/password exchange
+         2 - PPP CHAP
+         3 - PPP PAP
+         4 - No Authentication
+         5 - Microsoft CHAP Version 1 (MSCHAPv1)
+
+         This AVP MUST be present if proxy authentication is to be
+         utilized. If it is not present, then it is assumed that this
+         peer cannot perform proxy authentication, requiring
+         a restart of the authentication phase at the LNS if the client
+         has already entered this phase with the
+         LAC (which may be determined by the Proxy LCP AVP if present).
+
+      Associated AVPs for each type of authentication follow.
+
+   Proxy Authen Name (ICCN)
+
+      The Proxy Authen Name AVP, Attribute Type 30, specifies the name
+      of the authenticating client when using proxy 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Authen Name... (arbitrary number of octets)                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Authen Name is a string of octets of arbitrary length.  It
+      contains the name specified in the client's authentication
+      response.
+
+      This AVP MUST be present in messages containing a Proxy Authen
+      Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable
+      to employ AVP hiding for obscuring the cleartext name.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) is 6 plus
+      the length of the cleartext name.
+
+   Proxy Authen Challenge (ICCN)
+
+      The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
+      challenge sent by the LAC to the PPP Peer, when using proxy
+      authentication.
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 37]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Challenge... (arbitrary number of octets)                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Challenge is a string of one or more octets.
+
+      This AVP MUST be present for Proxy Authen Types 2 and 5. The
+      Challenge field contains the CHAP challenge presented to the
+      client by the LAC.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6, plus the length of the Challenge.
+
+   Proxy Authen ID (ICCN)
+
+      The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value
+      of the PPP Authentication that was started between the LAC and the
+      PPP Peer, when proxy authentication is being used.
+
+      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    |      ID       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      ID is a 2 octet unsigned integer, the most significant octet MUST
+      be 0.
+
+      The Proxy Authen ID AVP MUST be present for Proxy authen types 2,
+      3 and 5. For 2 and 5, the ID field contains the byte ID value
+      presented to the client by the LAC in its Challenge. For 3, it is
+      the Identifier value of the Authenticate-Request.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.
+
+   Proxy Authen Response (ICCN)
+
+      The Proxy Authen Response AVP, Attribute Type 33, specifies the
+      PPP Authentication response received by the LAC from the PPP Peer,
+      when proxy authentication is used.
+
+
+
+Townsley, et al.            Standards Track                    [Page 38]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Response... (arbitrary number of octets)                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Response is a string of octets.
+
+      This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
+      Response field contains the client's response to the challenge.
+      For Proxy authen types 2 and 5, this field contains the response
+      value received by the LAC. For types 1 or 3, it contains the clear
+      text password received from the client by the LAC.  In the case of
+      cleartext passwords, AVP hiding is recommended.
+
+      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
+      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
+      is 6 plus the length of the Response.
+
+4.4.6 Call Status AVPs
+
+   Call Errors (WEN)
+
+      The Call Errors AVP, Attribute Type 34, is used by the LAC to send
+      error information to the LNS.
+
+      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              |        CRC Errors (H)         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         CRC Errors (L)        |        Framing Errors (H)     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Framing Errors (L)    |        Hardware Overruns (H)  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Hardware Overruns (L) |        Buffer Overruns (H)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Buffer Overruns  (L)  |        Time-out Errors (H)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Time-out Errors (L)   |        Alignment Errors (H)   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Alignment Errors (L)  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 39]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      The following fields are defined:
+
+         Reserved - Not used, MUST be 0
+         CRC Errors - Number of PPP frames received with CRC errors
+            since call was established
+         Framing Errors - Number of improperly framed PPP packets
+            received
+         Hardware Overruns - Number of receive buffer over-runs since
+            call was established
+         Buffer Overruns - Number of buffer over-runs detected since
+            call was established
+         Time-out Errors - Number of time-outs 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 MUST be set to 1.  The Length (before hiding) of this AVP
+      is 32.
+
+   ACCM (SLI)
+
+      The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC
+      of the ACCM negotiated with the PPP Peer by the LNS.
+
+      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             |    Send ACCM (H)              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Send ACCM   (L)      |    Receive ACCM (H)           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Receive ACCM  (L)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Send ACCM and Receive ACCM are each 4 octet values preceded by a 2
+      octet reserved quantity. The send ACCM value should be used by the
+      LAC to process packets it sends on the connection. The receive
+      ACCM value should be used by the LAC to process incoming packets
+      on the connection. The default values used by the LAC for both
+      these fields are 0xFFFFFFFF. The LAC should honor these fields
+      unless it has specific configuration information to indicate that
+      the requested mask must be modified to permit operation.
+
+      This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
+      this AVP MUST be set to 1.  The Length of this AVP is 16.
+
+
+
+Townsley, et al.            Standards Track                    [Page 40]
+
+RFC 2661                          L2TP                       August 1999
+
+
+5.0 Protocol Operation
+
+   The necessary setup for tunneling a PPP session with L2TP consists of
+   two steps, (1) establishing the Control Connection for a Tunnel, and
+   (2) establishing a Session as triggered by an incoming or outgoing
+   call request. The Tunnel and corresponding Control Connection MUST be
+   established before an incoming or outgoing call is initiated. An L2TP
+   Session MUST be established before L2TP can begin to tunnel PPP
+   frames. Multiple Sessions may exist across a single Tunnel and
+   multiple Tunnels may exist between the same LAC and LNS.
+
+                          +-----+                               +-----+
+                          |     |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~|     |
+                          | LAC |                               | LNS |
+                          |     #######Control Connection########     |
+ [Remote]                 |     |                               |     |
+ [System]------Call----------*============L2TP Session=============*  |
+   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
+                          |     |                               |     |
+ [Remote]                 |     |                               |     |
+ [System]------Call----------*============L2TP Session=============*  |
+   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
+                          |     |                               |     |
+                          |     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|     |
+                          +-----+                               +-----+
+
+ Figure 5.1 Tunneling PPP
+
+5.1 Control Connection Establishment
+
+   The Control Connection is the initial connection that must be
+   achieved between an LAC and LNS before sessions may be brought up.
+   Establishment of the control connection includes securing the
+   identity of the peer, as well as identifying the peer's L2TP version,
+   framing, and bearer capabilities, etc.
+
+   A three message exchange is utilized to setup the control connection.
+   Following is a typical message exchange:
+
+      LAC or LNS  LAC or LNS
+      ----------  ----------
+      SCCRQ ->
+                  <- SCCRP
+      SCCCN ->
+                  <- ZLB ACK
+
+   The ZLB ACK is sent if there are no further messages waiting in queue
+   for that peer.
+
+
+
+Townsley, et al.            Standards Track                    [Page 41]
+
+RFC 2661                          L2TP                       August 1999
+
+
+5.1.1 Tunnel Authentication
+
+   L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel
+   authentication system during control connection establishment. If an
+   LAC or LNS wishes to authenticate the identity of the peer it is
+   contacting or being contacted by, a Challenge AVP is included in the
+   SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or
+   SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP
+   or SCCCN, respectively. If the expected response and response
+   received from a peer does not match, establishment of the tunnel MUST
+   be disallowed.
+
+   To participate in tunnel authentication, a single shared secret MUST
+   exist between the LAC and LNS. This is the same shared secret used
+   for AVP hiding (see Section 4.3).  See Section 4.4.3 for details on
+   construction of the Challenge and Response AVPs.
+
+5.2 Session Establishment
+
+   After successful control connection establishment, individual
+   sessions may be created. Each session corresponds to single PPP
+   stream between the LAC and LNS. Unlike control connection
+   establishment, session establishment is directional with respect to
+   the LAC and LNS. The LAC requests the LNS to accept a session for an
+   incoming call, and the LNS requests the LAC to accept a session for
+   placing an outgoing call.
+
+5.2.1 Incoming Call Establishment
+
+   A three message exchange is employed to setup the session.  Following
+   is a typical sequence of events:
+
+      LAC         LNS
+      ---         ---
+      (Call
+       Detected)
+
+      ICRQ ->
+               <- ICRP
+      ICCN ->
+               <- ZLB ACK
+
+   The ZLB ACK is sent if there are no further messages waiting in queue
+   for that peer.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 42]
+
+RFC 2661                          L2TP                       August 1999
+
+
+5.2.2 Outgoing Call Establishment
+
+   A three message exchange is employed to setup the session.  Following
+   is a typical sequence of events:
+
+      LAC         LNS
+      ---         ---
+               <- OCRQ
+      OCRP ->
+
+      (Perform
+       Call
+       Operation)
+
+      OCCN ->
+               <- ZLB ACK
+
+   The ZLB ACK is sent if there are no further messages waiting in queue
+   for that peer.
+
+5.3 Forwarding PPP Frames
+
+   Once tunnel establishment is complete, PPP frames from the remote
+   system are received at the LAC, stripped of CRC, link framing, and
+   transparency bytes, encapsulated in L2TP, and forwarded over the
+   appropriate tunnel. The LNS receives the L2TP packet, and processes
+   the encapsulated PPP frame as if it were received on a local PPP
+   interface.
+
+   The sender of a message associated with a particular session and
+   tunnel places the Session ID and Tunnel ID (specified by its peer) in
+   the Session ID and Tunnel ID header for all outgoing messages. In
+   this manner, PPP frames are multiplexed and demultiplexed over a
+   single tunnel between a given LNS-LAC pair. Multiple tunnels may
+   exist between a given LNS-LAC pair, and multiple sessions may exist
+   within a tunnel.
+
+   The value of 0 for Session ID and Tunnel ID is special and MUST NOT
+   be used as an Assigned Session ID or Assigned Tunnel ID.  For the
+   cases where a Session ID has not yet been assigned by the peer (i.e.,
+   during establishment of a new session or tunnel), the Session ID
+   field MUST be sent as 0, and the Assigned Session ID AVP within the
+   message MUST be used to identify the session. Similarly, for cases
+   where the Tunnel ID has not yet been assigned from the peer, the
+   Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to
+   identify the tunnel.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 43]
+
+RFC 2661                          L2TP                       August 1999
+
+
+5.4 Using Sequence Numbers on the Data Channel
+
+   Sequence numbers are defined in the L2TP header for control messages
+   and optionally for data messages (see Section 3.1). These are used to
+   provide a reliable control message transport (see Section 5.8) and
+   optional data message sequencing. Each peer maintains separate
+   sequence numbers for the control connection and each individual data
+   session within a tunnel.
+
+   Unlike the L2TP control channel, the L2TP data channel does not use
+   sequence numbers to retransmit lost data messages. Rather, data
+   messages may use sequence numbers to detect lost packets and/or
+   restore the original sequence of packets that may have been reordered
+   during transport.  The LAC may request that sequence numbers be
+   present in data messages via the Sequencing Required AVP (see Section
+   4.4.6). If this AVP is present during session setup, sequence numbers
+   MUST be present at all times. If this AVP is not present, sequencing
+   presence is under control of the LNS. The LNS controls enabling and
+   disabling of sequence numbers by sending a data message with or
+   without sequence numbers present at any time during the life of a
+   session. Thus, if the LAC receives a data message without sequence
+   numbers present, it MUST stop sending sequence numbers in future data
+   messages. If the LAC receives a data message with sequence numbers
+   present, it MUST begin sending sequence numbers in future outgoing
+   data messages. If the LNS enables sequencing after disabling it
+   earlier in the session, the sequence number state picks up where it
+   left off before.
+
+   The LNS may initiate disabling of sequencing at any time during the
+   session (including the first data message sent). It is recommended
+   that for connections where reordering or packet loss may occur,
+   sequence numbers always be enabled during the initial negotiation
+   stages of PPP and disabled only when and if the risk is considered
+   acceptable. For example, if the PPP session being tunneled is not
+   utilizing any stateful compression or encryption protocols and is
+   only carrying IP (as determined by the PPP NCPs that are
+   established), then the LNS might decide to disable sequencing as IP
+   is tolerant to datagram loss and reordering.
+
+5.5 Keepalive (Hello)
+
+   A keepalive mechanism is employed by L2TP in order to differentiate
+   tunnel outages from extended periods of no control or data activity
+   on a tunnel. This is accomplished by injecting Hello control messages
+   (see Section 6.5) after a specified period of time has elapsed since
+   the last data or control message was received on a tunnel. As for any
+   other control message, if the Hello message is not reliably delivered
+   then the tunnel is declared down and is reset. The transport reset
+
+
+
+Townsley, et al.            Standards Track                    [Page 44]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   mechanism along with the injection of Hello messages ensures that a
+   connectivity failure between the LNS and the LAC will be detected at
+   both ends of a tunnel.
+
+5.6 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). Following is an example of a typical control message
+   exchange:
+
+      LAC or LNS  LAC or LNS
+
+      CDN ->
+      (Clean up)
+
+                  <- ZLB ACK
+                     (Clean up)
+
+5.7 Control Connection Teardown
+
+   Control connection teardown may be initiated by either the LAC or LNS
+   and is accomplished by sending a single StopCCN control message. The
+   receiver of a StopCCN MUST send a ZLB ACK 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 ZLB ACK is lost). The recommended time for a full
+   retransmission cycle is 31 seconds (see section 5.8). Following is an
+   example of a typical control message exchange:
+
+      LAC or LNS  LAC or LNS
+
+      StopCCN ->
+      (Clean up)
+
+                  <- ZLB ACK
+                     (Wait)
+                     (Clean up)
+
+   An implementation may shut down an entire tunnel and all sessions on
+   the tunnel by sending the StopCCN. Thus, it is not necessary to clear
+   each session individually when tearing down the whole tunnel.
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 45]
+
+RFC 2661                          L2TP                       August 1999
+
+
+5.8 Reliable Delivery of Control Messages
+
+   L2TP provides a lower level reliable transport service for all
+   control messages. The Nr and Ns fields of the control message header
+   (see section 3.1) belong to this transport.  The upper level
+   functions of L2TP are not concerned with retransmission or ordering
+   of control messages. The reliable control message is a sliding window
+   transport that provides control message retransmission and congestion
+   control.  Each peer maintains separate sequence number state for the
+   control connection within a tunnel.
+
+   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 ZLB ACK message), receipt of duplicate messages MUST be
+   acknowledged by the reliable transport. This acknowledgement may
+   either piggybacked on a message in queue, or explicitly via a ZLB
+   ACK.
+
+   All control messages take up one slot in the control message sequence
+   number space, except the ZLB acknowledgement. Thus, Ns is not
+   incremented after a ZLB 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-
+   ZLB message received plus 1, modulo 65536).  While the Nr in a
+   received ZLB is used to flush messages from the local retransmit
+   queue (see below), Nr of the next message sent is not be updated by
+   the Ns of the ZLB.
+
+   The reliable transport 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 are received,
+   or they may be discarded requiring a retransmission by the peer.
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 46]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   Each tunnel 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) passes without
+   acknowledgement, 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
+   MUST be no less than 8 seconds per retransmission.  If no peer
+   response is detected after several retransmissions, (a recommended
+   default is 5, but SHOULD be configurable), the tunnel and all
+   sessions within MUST be cleared.
+
+   When a tunnel 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 exchange has occurred.
+
+   A sliding window mechanism is used for control message transmission.
+   Consider two peers A & B. Suppose A specifies a Receive Window Size
+   AVP with a value of N in the SCCRQ or SCCRP messages. B is now
+   allowed to have up to N outstanding control messages. Once N have
+   been sent, it must wait for an acknowledgment that advances the
+   window before sending new control messages.  An implementation may
+   support a receive window of only 1 (i.e., by sending out a Receive
+   Window Size AVP with a value of 1), but MUST accept a window of up to
+   4 from its peer (e.g. have the ability to send 4 messages before
+   backing off). A value of 0 for the Receive Window Size AVP is
+   invalid.
+
+   When retransmitting control messages, a slow start and congestion
+   avoidance window adjustment procedure SHOULD be utilized. The
+   recommended procedure for this is described in Appendix A.
+
+   A peer MUST NOT withhold acknowledgment of messages as a technique
+   for flow controlling control messages.  An L2TP implementation is
+   expected to be able to keep up with incoming control messages,
+   possibly responding to some with errors reflecting an inability to
+   honor the requested action.
+
+   Appendix B contains examples of control message transmission,
+   acknowledgement, and retransmission.
+
+
+
+Townsley, et al.            Standards Track                    [Page 47]
+
+RFC 2661                          L2TP                       August 1999
+
+
+6.0 Control Connection Protocol Specification
+
+   The following control connection messages are used to establish,
+   clear and maintain L2TP tunnels. All data is sent in network order
+   (high order octets first). Any "reserved" or "empty" fields MUST be
+   sent as 0 values to allow for protocol extensibility.
+
+6.1 Start-Control-Connection-Request (SCCRQ)
+
+   Start-Control-Connection-Request (SCCRQ) is a control message used to
+   initialize a tunnel between an LNS and an LAC. It is sent by either
+   the LAC or the LNS to being the tunnel establishment process.
+
+   The following AVPs MUST be present in the SCCRQ:
+
+      Message Type AVP
+      Protocol Version
+      Host Name
+      Framing Capabilities
+      Assigned Tunnel ID
+
+   The Following AVPs MAY be present in the SCCRQ:
+
+      Bearer Capabilities
+      Receive Window Size
+      Challenge
+      Tie Breaker
+      Firmware Revision
+      Vendor Name
+
+6.2 Start-Control-Connection-Reply (SCCRP)
+
+   Start-Control-Connection-Reply (SCCRP) is a control message sent in
+   reply to a received SCCRQ message. SCCRP is used to indicate that the
+   SCCRQ was accepted and establishment of the tunnel should continue.
+
+   The following AVPs MUST be present in the SCCRP:
+
+      Message Type
+      Protocol Version
+      Framing Capabilities
+      Host Name
+      Assigned Tunnel ID
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 48]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   The following AVPs MAY be present in the SCCRP:
+
+      Bearer Capabilities
+      Firmware Revision
+      Vendor Name
+      Receive Window Size
+      Challenge
+      Challenge Response
+
+6.3 Start-Control-Connection-Connected (SCCCN)
+
+   Start-Control-Connection-Connected (SCCCN) is a control message sent
+   in reply to an SCCRP. SCCCN completes the tunnel establishment
+   process.
+
+   The following AVP MUST be present in the SCCCN:
+
+      Message Type
+
+   The following AVP MAY be present in the SCCCN:
+
+      Challenge Response
+
+6.4 Stop-Control-Connection-Notification (StopCCN)
+
+   Stop-Control-Connection-Notification (StopCCN) is a control message
+   sent by either the LAC or LNS to inform its peer that the tunnel is
+   being shutdown and the control connection should be closed. In
+   addition, all active sessions are implicitly cleared (without sending
+   any explicit call 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 transport layer.
+
+   The following AVPs MUST be present in the StopCCN:
+
+      Message Type
+      Assigned Tunnel ID
+      Result Code
+
+6.5 Hello (HELLO)
+
+   The Hello (HELLO) message is an L2TP control message sent by either
+   peer of a LAC-LNS control connection. This control message is used as
+   a "keepalive" for the tunnel.
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 49]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   The sending of HELLO messages and the policy for sending them are
+   left up to the implementation. A peer MUST NOT expect HELLO messages
+   at any time or interval. As with all messages sent on the control
+   connection, the receiver will return either a ZLB ACK or an
+   (unrelated) message piggybacking the necessary acknowledgement
+   information.
+
+   Since a HELLO is a control message, and control messages are reliably
+   sent by the lower level transport, this keepalive function operates
+   by causing the transport level to reliably deliver a message. If a
+   media interruption has occurred, the reliable transport will be
+   unable to deliver the HELLO across, and will clean up the tunnel.
+
+   Keepalives for the tunnel MAY be implemented by sending a HELLO if a
+   period of time (a recommended default is 60 seconds, but SHOULD be
+   configurable) has passed without receiving any message (data or
+   control) from the peer.
+
+   HELLO messages are global to the tunnel. The Session ID in a HELLO
+   message MUST be 0.
+
+   The Following AVP MUST be present in the HELLO message:
+
+      Message Type
+
+6.6 Incoming-Call-Request (ICRQ)
+
+   Incoming-Call-Request (ICRQ) is a control message sent by the LAC to
+   the LNS when an incoming call is detected. It is the first in a three
+   message exchange used for establishing a session within an L2TP
+   tunnel.
+
+   ICRQ is used to indicate that a session is to be established between
+   the LAC and LNS for this call and provides the LNS with parameter
+   information for the session.  The LAC may defer answering the call
+   until it has received an ICRP from the LNS indicating that the
+   session should be established.  This mechanism allows the LNS to
+   obtain sufficient information about the call before determining
+   whether it should be answered or not. Alternatively, the LAC may
+   answer the call, negotiate LCP and PPP authentication, and use the
+   information gained to choose the LNS. In this case, the call has
+   already been answered by the time the ICRP message is received; the
+   LAC simply spoofs the "call indication" and "call answer" steps in
+   this case.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 50]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   The following AVPs MUST be present in the ICRQ:
+
+      Message Type
+      Assigned Session ID
+      Call Serial Number
+
+   The following AVPs MAY be present in the ICRQ:
+
+      Bearer Type
+      Physical Channel ID
+      Calling Number
+      Called Number
+      Sub-Address
+
+6.7 Incoming-Call-Reply (ICRP)
+
+   Incoming-Call-Reply (ICRP) is a control message sent by the LNS to
+   the LAC in response to a received ICRQ message. It is the second in
+   the three message exchange used for establishing sessions within an
+   L2TP tunnel.
+
+   ICRP is used to indicate that the ICRQ was successful and for the LAC
+   to answer the call if it has not already done so. It also allows the
+   LNS to indicate necessary parameters for the L2TP session.
+
+   The following AVPs MUST be present in the ICRP:
+
+      Message Type
+      Assigned Session ID
+
+6.8 Incoming-Call-Connected (ICCN)
+
+   Incoming-Call-Connected (ICCN) is a control message sent by the LAC
+   to the LNS in response to a received ICRP message. It is the third
+   message in the three message exchange used for establishing sessions
+   within an L2TP tunnel.
+
+   ICCN is used to indicate that the ICRP was accepted, the call has
+   been answered, and that the L2TP session should move to the
+   established state.  It also provides additional information to the
+   LNS about parameters used for the answered call (parameters that may
+   not always available at the time the ICRQ is issued).
+
+   The following AVPs MUST be present in the ICCN:
+
+      Message Type
+      (Tx) Connect Speed
+      Framing Type
+
+
+
+Townsley, et al.            Standards Track                    [Page 51]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   The following AVPs MAY be present in the ICCN:
+
+      Initial Received LCP CONFREQ
+      Last Sent LCP CONFREQ
+      Last Received LCP CONFREQ
+      Proxy Authen Type
+      Proxy Authen Name
+      Proxy Authen Challenge
+      Proxy Authen ID
+      Proxy Authen Response
+      Private Group ID
+      Rx Connect Speed
+      Sequencing Required
+
+6.9 Outgoing-Call-Request (OCRQ)
+
+   Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to
+   the LAC to indicate that an outbound call from the LAC is to be
+   established. It is the first in a three message exchange used for
+   establishing a session within an L2TP tunnel.
+
+   OCRQ is used to indicate that a session is to be established between
+   the LNS and LAC for this call and provides the LAC with parameter
+   information for both the L2TP session, and the call that is to be
+   placed
+
+   An LNS MUST have received a Bearer Capabilities AVP during tunnel
+   establishment from an LAC in order to request an outgoing call to
+   that LAC.
+
+   The following AVPs MUST be present in the OCRQ:
+
+      Message Type
+      Assigned Session ID
+      Call Serial Number
+      Minimum BPS
+      Maximum BPS
+      Bearer Type
+      Framing Type
+      Called Number
+
+   The following AVPs MAY be present in the OCRQ:
+
+      Sub-Address
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 52]
+
+RFC 2661                          L2TP                       August 1999
+
+
+6.10 Outgoing-Call-Reply (OCRP)
+
+   Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to
+   the LNS in response to a received OCRQ message. It is the second in a
+   three message exchange used for establishing a session within an L2TP
+   tunnel.
+
+   OCRP is used to indicate that the LAC is able to attempt the outbound
+   call and returns certain parameters regarding the call attempt.
+
+   The following AVPs MUST be present in the OCRP:
+
+      Message Type
+      Assigned Session ID
+
+   The following AVPs MAY be present in the OCRP:
+
+      Physical Channel ID
+
+6.11 Outgoing-Call-Connected (OCCN)
+
+   Outgoing-Call-Connected (OCCN) is a control message sent by the LAC
+   to the LNS following 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 within an L2TP tunnel.
+
+   OCCN is used to indicate that the result of a requested outgoing call
+   was successful. It also provides information to the LNS about the
+   particular parameters obtained after the call was established.
+
+   The following AVPs MUST be present in the OCCN:
+
+      Message Type
+      (Tx) Connect Speed
+      Framing Type
+
+   The following AVPs MAY be present in the OCCN:
+
+      Rx Connect Speed
+      Sequencing Required
+
+6.12 Call-Disconnect-Notify (CDN)
+
+   The Call-Disconnect-Notify (CDN) message is an L2TP control message
+   sent by either the LAC or LNS to request disconnection of a specific
+   call within the tunnel. Its purpose is to inform the peer of the
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 53]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   disconnection and the reason why the disconnection occurred. 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
+      Assigned Session ID
+
+   The following AVPs MAY be present in the CDN:
+
+      Q.931 Cause Code
+
+6.13 WAN-Error-Notify (WEN)
+
+   The WAN-Error-Notify message is an L2TP control message sent by the
+   LAC to the LNS to indicate WAN error conditions (conditions that
+   occur on the interface supporting PPP). 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
+      Call Errors
+
+6.14 Set-Link-Info (SLI)
+
+   The Set-Link-Info message is an L2TP control message sent by the LNS
+   to the LAC to set PPP-negotiated options.  These options can change
+   at any time during the life of the call, thus the LAC MUST be able to
+   update its internal call information and behavior on an active PPP
+   session.
+
+   The following AVPs MUST be present in the SLI:
+
+      Message Type
+      ACCM
+
+7.0 Control Connection State Machines
+
+   The control messages defined in section 6 are exchanged by way of
+   state tables defined in this section. Tables are defined for incoming
+   call placement, outgoing call placement, as well as for initiation of
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 54]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   the tunnel itself.  The state tables do not encode timeout and
+   retransmission behavior, as this is handled in the underlying
+   semantics defined in Section 5.8.
+
+7.1 Control Connection Protocol Operation
+
+   This section describes the operation of various L2TP control
+   connection functions and the Control Connection messages which are
+   used to support them.
+
+   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 a message which contains a
+   Message Type that is marked mandatory (see Section 4.4.1) and is
+   unknown to the implementation, or a control message that is received
+   in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ).
+
+   Examples of a malformed control message include one that has an
+   invalid value in its header, contains an AVP that is formatted
+   incorrectly or whose value is out of range, or a message that is
+   missing a required AVP. A control message with a malformed header
+   should be discarded. A control message with an invalid AVP should
+   look to the M-bit for that AVP to determine whether the error is
+   recoverable or not.
+
+   A malformed yet recoverable non-mandatory (M-bit is not set) AVP
+   within a control message should be treated in a similar manner as an
+   unrecognized non-mandatory AVP. Thus, if a malformed AVP is received
+   with the M-bit set, the session or tunnel should be terminated with a
+   proper Result or Error Code sent.  If the M-bit is not set, the AVP
+   should be ignored (with the exception of logging a local error
+   message) and the message accepted.
+
+   This MUST NOT be considered a license to send malformed AVPs, but
+   simply 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. That said,
+   one example of a recoverable, malformed AVP might be if the Rx
+   Connect Speed AVP, attribute 38, is received with a length of 8
+   rather than 10 and the BPS given in 2 octets rather than 4. Since the
+   Rx Connect Speed is non-mandatory, this condition should not be
+   considered catastrophic. As such, the control message should be
+   accepted as if the AVP had not been received (with the exception of a
+   local error message being logged).
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 55]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   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 tunnel destruction, the reliable delivery mechanism must be
+   allowed to run (see Section 5.8) before destroying the tunnel. This
+   permits the tunnel management messages to be reliably delivered to
+   the peer.
+
+   Appendix B.1 contains an example of lock-step tunnel establishment.
+
+7.2 Control Connection States
+
+   The L2TP control connection protocol is not distinguishable between
+   the LNS and LAC, but is distinguishable between the originator and
+   receiver. The originating peer is the one which first initiates
+   establishment of the tunnel (in a tie breaker situation, this is the
+   winner of the tie). Since either LAC or LNS can be the originator, a
+   collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a
+   description of this and its resolution.
+
+7.2.1 Control Connection Establishment
+
+   State           Event             Action               New State
+   -----           -----             ------               ---------
+   idle            Local             Send SCCRQ           wait-ctl-reply
+                   Open 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     Clean up             idle
+
+   wait-ctl-reply  Receive SCCRP,    Send SCCCN,          established
+                   acceptable        Send tunnel-open
+                                     event to waiting
+                                     sessions
+
+   wait-ctl-reply  Receive SCCRP,    Send StopCCN,        idle
+                   not acceptable    Clean up
+
+   wait-ctl-reply  Receive SCCRQ,    Clean up,            idle
+                   lose tie-breaker  Re-queue SCCRQ
+                                     for idle state
+
+
+
+Townsley, et al.            Standards Track                    [Page 56]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   wait-ctl-reply  Receive SCCCN     Send StopCCN         idle
+                                     Clean up
+
+   wait-ctl-conn   Receive SCCCN,    Send tunnel-open     established
+                   acceptable        event to waiting
+                                     sessions
+
+   wait-ctl-conn   Receive SCCCN,    Send StopCCN,        idle
+                   not acceptable    Clean up
+
+   wait-ctl-conn   Receive SCCRP,    Send StopCCN,        idle
+                   SCCRQ             Clean up
+
+   established     Local             Send tunnel-open     established
+                   Open request      event to waiting
+                   (new call)        sessions
+
+   established     Admin             Send StopCCN         idle
+                   Tunnel Close      Clean up
+
+   established     Receive SCCRQ,    Send StopCCN         idle
+                   SCCRP, SCCCN      Clean up
+
+   idle            Receive StopCCN   Clean up             idle
+   wait-ctl-reply,
+   wait-ctl-conn,
+   established
+
+   The states associated with the LNS or LAC for control connection
+   establishment are:
+
+   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.8.
+
+      When an SCCRP is received, it is examined for a compatible
+      version. If the version of the reply is lower than the version
+      sent in the request, the older (lower) version should be used
+      provided it is supported.  If the version in the reply is earlier
+      and supported, the originator moves to the established state.  If
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 57]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      the version is earlier and not supported, a StopCCN MUST be sent
+      to the peer and the originator cleans up and terminates the
+      tunnel.
+
+   wait-ctl-conn
+      This is where an SCCCN is awaited; upon receipt, the challenge
+      response is checked. The tunnel either is established, or is torn
+      down if an authorization failure is detected.
+
+   established
+      An established connection may be terminated by either a local
+      condition or the receipt of a Stop-Control-Connection-
+      Notification. In the event of a local termination, the originator
+      MUST send a Stop-Control-Connection-Notification and clean up the
+      tunnel.
+
+      If the originator receives a Stop-Control-Connection-Notification
+      it MUST also clean up the tunnel.
+
+7.3 Timing considerations
+
+   Due to the real-time nature of telephone signaling, both the LNS and
+   LAC should be implemented with multi-threaded architectures such that
+   messages related to multiple calls are not serialized and blocked.
+   The call and connection state figures do not specify exceptions
+   caused by timers.  These are addressed in Section 5.8.
+
+7.4 Incoming calls
+
+   An Incoming-Call-Request message is generated by the LAC when an
+   incoming call is detected (for example, an associated telephone line
+   rings). The LAC selects a Session ID and serial number and indicates
+   the call bearer type. Modems should always indicate analog call type.
+   ISDN calls should indicate digital when unrestricted digital service
+   or rate adaption is used and analog if digital modems are involved.
+   Calling Number, Called Number, and Subaddress may be included in the
+   message if they are available from the telephone network.
+
+   Once the LAC sends the Incoming-Call-Request, it waits for a response
+   from the LNS but it does not necessarily answer the call from the
+   telephone network yet.  The LNS may choose not to accept the call if:
+
+      -  No resources are available to handle more sessions
+      -  The dialed, dialing, or subaddress fields do not correspond to
+         an authorized user
+      -  The bearer service is not authorized or supported
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 58]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   If the LNS chooses to accept the call, it responds with an Incoming-
+   Call-Reply.  When the LAC receives the Incoming-Call-Reply, it
+   attempts to connect the call.  A final call connected message from
+   the LAC to the LNS indicates that the call states for both the LAC
+   and the LNS should enter the established state.  If the call
+   terminated before the LNS could accept it, a Call-Disconnect-Notify
+   is sent by the LAC to indicate this condition.
+
+   When the dialed-in client hangs up, the call is cleared normally and
+   the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to
+   clear a call, it sends a Call-Disconnect-Notify message and cleans up
+   its session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 59]
+
+RFC 2661                          L2TP                       August 1999
+
+
+7.4.1 LAC Incoming Call States
+
+   State           Event              Action            New State
+   -----           -----              ------            ---------
+   idle            Bearer Ring or     Initiate local    wait-tunnel
+                   Ready to indicate  tunnel open
+                   incoming conn.
+
+   idle            Receive ICCN,      Clean up          idle
+                   ICRP, CDN
+
+   wait-tunnel     Bearer line drop   Clean up          idle
+                   or local close
+                   request
+
+   wait-tunnel     tunnel-open        Send ICRQ         wait-reply
+
+   wait-reply      Receive ICRP,      Send ICCN         established
+                   acceptable
+
+   wait-reply      Receive ICRP,      Send CDN,         idle
+                   Not acceptable     Clean up
+
+   wait-reply      Receive ICRQ       Send CDN          idle
+                                      Clean up
+
+   wait-reply      Receive CDN        Clean up          idle
+                   ICCN
+
+   wait-reply      Local              Send CDN,         idle
+                   close request or   Clean up
+                   Bearer line drop
+
+   established     Receive CDN        Clean up          idle
+
+   established     Receive ICRQ,      Send CDN,         idle
+                   ICRP, ICCN         Clean up
+
+   established     Bearer line        Send CDN,         idle
+                   drop or local      Clean up
+                   close request
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 60]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   The states associated with the LAC for incoming calls are:
+
+   idle
+      The LAC detects an incoming call on one of its interfaces.
+      Typically this means an analog line is ringing or an ISDN TE has
+      detected an incoming Q.931 SETUP message. The LAC initiates its
+      tunnel establishment state machine, and moves to a state waiting
+      for confirmation of the existence of a tunnel.
+
+   wait-tunnel
+      In this state the session is waiting for either the control
+      connection to be opened or for verification that the tunnel is
+      already open. Once an indication that the tunnel has/was opened,
+      session control messages may be exchanged.  The first of these is
+      the Incoming-Call-Request.
+
+   wait-reply
+      The LAC receives either a CDN message indicating the LNS is not
+      willing to accept the call (general error or don't accept) and
+      moves back into the idle state, or an Incoming-Call-Reply message
+      indicating the call is accepted, the LAC sends an Incoming-Call-
+      Connected message and enters the established state.
+
+   established
+      Data is exchanged over the tunnel.  The call may be cleared
+      following:
+         + An event on the connected interface:  The LAC sends a Call-
+           Disconnect-Notify message
+         + Receipt of a Call-Disconnect-Notify message:  The LAC cleans
+           up, disconnecting the call.
+         + A local reason:  The LAC sends a Call-Disconnect-Notify
+           message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 61]
+
+RFC 2661                          L2TP                       August 1999
+
+
+7.4.2 LNS Incoming Call 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
+
+   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              Send CDN,         idle
+   established     Close request      Clean up
+
+   established     Receive ICRQ,      Send CDN          idle
+                   ICRP, ICCN         Clean up
+
+   The states associated with the LNS for incoming calls are:
+
+   idle
+      An Incoming-Call-Request message is received. If the request is
+      not acceptable, a Call-Disconnect-Notify is sent back to the LAC
+      and the LNS remains in the idle state. If the Incoming-Call-
+      Request message is acceptable, an Incoming-Call-Reply is sent. The
+      session moves to the wait-connect state.
+
+   wait-connect
+      If the session is still connected on the LAC, the LAC sends an
+      Incoming-Call-Connected message to the LNS which then moves into
+      established state.  The LAC may send a Call-Disconnect-Notify to
+      indicate that the incoming caller could not be connected. This
+
+
+
+Townsley, et al.            Standards Track                    [Page 62]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      could happen, for example, if a telephone user accidentally places
+      a standard voice call to an LAC resulting in a handshake failure
+      on the called modem.
+
+   established
+      The session is terminated either by receipt of a Call-Disconnect-
+      Notify message from the LAC or by sending a Call-Disconnect-
+      Notify. Clean up follows on both sides regardless of the
+      initiator.
+
+7.5 Outgoing calls
+
+   Outgoing calls are initiated by an LNS and instruct an LAC to place a
+   call.  There are three messages for outgoing calls:  Outgoing-Call-
+   Request, Outgoing-Call-Reply, and Outgoing-Call-Connected.  The LNS
+   sends an Outgoing-Call-Request specifying the dialed party phone
+   number, subaddress and other parameters. The LAC MUST respond to the
+   Outgoing-Call-Request message with an Outgoing-Call-Reply message
+   once the LAC determines that the proper facilities exist to place the
+   call and the call is administratively authorized.  For example, is
+   this LNS allowed to dial an international call?  Once the outbound
+   call is connected, the LAC sends an Outgoing-Call-Connected message
+   to the LNS indicating the final result of the call attempt:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 63]
+
+RFC 2661                          L2TP                       August 1999
+
+
+7.5.1 LAC Outgoing Call States
+
+   State           Event              Action            New State
+   -----           -----              ------            ---------
+   idle            Receive OCRQ,      Send OCRP,        wait-cs-answer
+                   acceptable         Open bearer
+
+   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  Bearer answer,     Send OCCN         established
+                   framing detected
+
+   wait-cs-answer  Bearer failure     Send CDN,         idle
+                                      Clean up
+
+   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
+
+   established     Bearer line drop,  Send CDN,         idle
+                   Local close        Clean up
+                   request
+
+   The states associated with the LAC for outgoing calls are:
+
+   idle
+      If Outgoing-Call-Request is received in error, respond with a
+      Call-Disconnect-Notify. Otherwise, allocate a physical channel and
+      send an Outgoing-Call-Reply. Place the outbound call and move to
+      the wait-cs-answer state.
+
+   wait-cs-answer
+      If the call is not completed or a timer expires waiting for the
+      call to complete, send a Call-Disconnect-Notify with the
+      appropriate error condition set and go to idle state. If a circuit
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 64]
+
+RFC 2661                          L2TP                       August 1999
+
+
+      switched connection is established and framing is detected, send
+      an Outgoing-Call-Connected indicating success and go to
+      established state.
+
+   established
+      If a Call-Disconnect-Notify is received by the LAC, the telco call
+      MUST be released via appropriate mechanisms and the session
+      cleaned up. If the call is disconnected by the client or the
+      called interface, a Call-Disconnect-Notify message MUST be sent to
+      the LNS. The sender of the Call-Disconnect-Notify message returns
+      to the idle state after sending of the message is complete.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 65]
+
+RFC 2661                          L2TP                       August 1999
+
+
+7.5.2 LNS Outgoing Call States
+
+   State           Event              Action            New State
+   -----           -----              ------            ---------
+   idle            Local              Initiate local    wait-tunnel
+                   open request       tunnel-open
+
+   idle            Receive OCCN,      Clean up          idle
+                   OCRP, CDN
+
+   wait-tunnel     tunnel-open        Send OCRQ         wait-reply
+
+   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
+                   OCRQ               Clean up
+
+   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              Send CDN          idle
+   wait-connect,   Close request      Clean up
+   established
+
+   wait-tunnel     Local              Clean up          idle
+                   Close request
+
+   The states associated with the LNS for outgoing calls are:
+
+   idle, wait-tunnel
+      When an outgoing call is initiated, a tunnel is first created,
+      much as the idle and wait-tunnel states for an LAC incoming call.
+      Once a tunnel is established, an Outgoing-Call-Request message is
+      sent to the LAC and the session moves into the wait-reply state.
+
+
+
+Townsley, et al.            Standards Track                    [Page 66]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   wait-reply
+      If a Call-Disconnect-Notify is received, an error occurred, and
+      the session is cleaned up and returns to idle.  If an Outgoing-
+      Call-Reply is received, the call is in progress and the session
+      moves to the wait-connect state.
+
+   wait-connect
+      If a Call-Disconnect-Notify is received, the call failed; the
+      session is cleaned up and returns to idle.  If an Outgoing-Call-
+      Connected is received, the call has succeeded and the session may
+      now exchange data.
+
+   established
+      If a Call-Disconnect-Notify is received, the call has been
+      terminated for the reason indicated in the Result and Cause Codes;
+      the session moves back to the idle state.  If the LNS chooses to
+      terminate the session, it sends a Call-Disconnect-Notify to the
+      LAC and then cleans up and idles its session.
+
+7.6 Tunnel Disconnection
+
+   The disconnection of a tunnel consists of either peer issuing a
+   Stop-Control-Connection-Notification. The sender of this Notification
+   should wait a finite period of time for the acknowledgment of this
+   message before releasing the control information associated with the
+   tunnel. The recipient of this Notification should send an
+   acknowledgment of the Notification and then release the associated
+   control information.
+
+   When to release a tunnel 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 tunnel open for
+   a period of time or perhaps indefinitely after the last session for
+   that tunnel is cleared. Others may choose to disconnect the tunnel
+   immediately after the last user connection on the tunnel disconnects.
+
+8.0 L2TP Over Specific Media
+
+   L2TP is self-describing, operating at a level above the media over
+   which it is carried. However, some details of its connection to media
+   are required to permit interoperable implementations. The following
+   sections describe details needed to permit interoperability over
+   specific media.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 67]
+
+RFC 2661                          L2TP                       August 1999
+
+
+8.1 L2TP over UDP/IP
+
+   L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP
+   packet, including payload and L2TP header, is sent within a UDP
+   datagram. The initiator of an L2TP tunnel 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. Once the source and destination ports and
+   addresses are established, they MUST remain static for the life of
+   the tunnel.
+
+   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 tunnel, i.e., 1701) may make it more difficult for
+   L2TP to traverse some NAT devices. Implementors should consider the
+   potential implication of this before before choosing an arbitrary
+   source port.
+
+   IP fragmentation may occur as the L2TP packet travels over the IP
+   substrate. L2TP makes no special efforts to optimize this. A LAC
+   implementation MAY cause its LCP to negotiate for a specific MRU,
+   which could optimize for LAC environments in which the MTU's of the
+   path over which the L2TP packets are likely to travel have a
+   consistent value.
+
+   The default for any L2TP implementation is that UDP checksums MUST be
+   enabled for both control and data messages. An L2TP implementation
+   MAY provide an option to disable UDP checksums for data messages. It
+   is recommended that UDP checksums always be enabled on control
+   packets.
+
+   Port 1701 is used for both L2F [RFC2341] and L2TP packets. The
+   Version field in each header may be used to discriminate between the
+   two packet types (L2F uses a value of 1, and the L2TP version
+   described in this document uses a value of 2). An L2TP implementation
+   running on a system which does not support L2F MUST silently discard
+   all L2F packets.
+
+   To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has
+   the characteristic of being able to reorder or silently drop packets.
+   The former may break non-IP protocols being carried by PPP,
+   especially LAN-centric ones such as bridging.  The latter may break
+   protocols which assume per-packet indication of error, such as TCP
+   header compression.  Sequencing may be handled by using L2TP data
+   message sequence numbers if any protocol being transported by the PPP
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 68]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   tunnel cannot tolerate reordering. The sequence dependency
+   characteristics of individual protocols are outside the scope of this
+   document.
+
+   Allowing packets to be dropped silently is perhaps more problematic
+   with some protocols. If PPP reliable delivery [RFC1663] is enabled,
+   no upper PPP protocol will encounter lost packets. If L2TP sequence
+   numbers are enabled, L2TP can detect the packet loss. In the case of
+   an LNS, the PPP and L2TP stacks are both present within the LNS, and
+   packet loss signaling may occur precisely as if a packet was received
+   with a CRC error. Where the LAC and PPP stack are co-resident, this
+   technique also applies. Where the LAC and PPP client are physically
+   distinct, the analogous signaling MAY be accomplished by sending a
+   packet with a CRC error to the PPP client. Note that this would
+   greatly increase the complexity of debugging client line problems,
+   since the client statistics could not distinguish between true media
+   errors and LAC-initiated ones. Further, this technique is not
+   possible on all hardware.
+
+   If VJ compression is used, and neither PPP reliable delivery nor
+   sequence numbers are enabled, each lost packet results in a 1 in
+   2**16 chance of a TCP segment being forwarded with incorrect contents
+   [RFC1144]. Where the combination of the packet loss rate with this
+   statistical exposure is unacceptable, TCP header compression SHOULD
+   NOT be used.
+
+   In general, it is wise to remember that the L2TP/UDP/IP transport is
+   an unreliable transport. As with any PPP media that is subject to
+   loss, care should be taken when using protocols that are particularly
+   loss-sensitive. Such protocols include compression and encryption
+   protocols that employ history.
+
+8.2 IP
+
+   When operating in IP environments, L2TP MUST offer the UDP
+   encapsulation described in 8.1 as its default configuration for IP
+   operation. Other configurations (perhaps corresponding to a
+   compressed header format) MAY be defined and made available as a
+   configurable option.
+
+9.0 Security Considerations
+
+   L2TP encounters several security issues in its operation.  The
+   general approach of L2TP to these issues is documented here.
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 69]
+
+RFC 2661                          L2TP                       August 1999
+
+
+9.1 Tunnel Endpoint Security
+
+   The tunnel endpoints may optionally perform an authentication
+   procedure of one another during tunnel establishment.  This
+   authentication has the same security attributes as CHAP, and has
+   reasonable protection against replay and snooping during the tunnel
+   establishment process. This mechanism is not designed to provide any
+   authentication beyond tunnel establishment; it is fairly simple for a
+   malicious user who can snoop the tunnel stream to inject packets once
+   an authenticated tunnel establishment has been completed
+   successfully.
+
+   For authentication to occur, the LAC and LNS MUST share a single
+   secret.  Each side uses this same secret when acting as authenticatee
+   as well as authenticator. Since a single secret is used, the tunnel
+   authentication AVPs include differentiating values in the CHAP ID
+   fields for each message digest calculation to guard against replay
+   attacks.
+
+   The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3)
+   SHOULD be selected in an unpredictable manner rather than
+   sequentially or otherwise.  Doing so will help deter hijacking of a
+   session by a malicious user who does not have access to packet traces
+   between the LAC and LNS.
+
+9.2 Packet Level Security
+
+   Securing L2TP requires that the underlying transport make available
+   encryption, integrity and authentication services for all L2TP
+   traffic.  This secure transport operates on the entire L2TP packet
+   and is functionally independent of PPP and the protocol being carried
+   by PPP. As such, L2TP is only concerned with confidentiality,
+   authenticity, and integrity of the L2TP packets between its tunnel
+
+   endpoints (the LAC and LNS), not unlike link-layer encryption being
+   concerned only about protecting the confidentiality of traffic
+   between its physical endpoints.
+
+9.3 End to End Security
+
+   Protecting the L2TP packet stream via a secure transport does, in
+   turn, also protect the data within the tunneled PPP packets while
+   transported from the LAC to the LNS. Such protection should not be
+   considered a substitution for end-to-end security between
+   communicating hosts or applications.
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 70]
+
+RFC 2661                          L2TP                       August 1999
+
+
+9.4 L2TP and IPsec
+
+   When running over IP, IPsec provides packet-level security via ESP
+   and/or AH. All L2TP control and data packets for a particular tunnel
+   appear as homogeneous UDP/IP data packets to the IPsec system.
+
+   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 is logically performed at the PPP layer or network layer
+   above L2TP.  These network layer access control features may be
+   handled at the LNS via vendor-specific authorization features based
+   upon the authenticated PPP user, 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.
+
+9.5 Proxy PPP Authentication
+
+   L2TP defines AVPs that MAY be exchanged during session establishment
+   to provide forwarding of PPP authentication information obtained at
+   the LAC to the LNS for validation (see Section 4.4.5). This implies a
+   direct trust relationship of the LAC on behalf of the LNS.  If the
+   LNS chooses to implement proxy authentication, it MUST be able to be
+   configured off, requiring a new round a PPP authentication initiated
+   by the LNS (which may or may not include a new round of LCP
+   negotiation).
+
+10.0 IANA Considerations
+
+   This document defines a number of "magic" numbers to be maintained by
+   the IANA.  This section explains the criteria to be used by the IANA
+   to assign additional numbers in each of these lists. The following
+   subsections describe the assignment policy for the namespaces defined
+   elsewhere in this document.
+
+10.1 AVP Attributes
+
+   As defined in Section 4.1, AVPs contain vendor ID, Attribute and
+   Value fields. For vendor ID value of 0, IANA will maintain a registry
+
+
+
+Townsley, et al.            Standards Track                    [Page 71]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   of assigned Attributes and in some case also values. Attributes 0-39
+   are assigned as defined in Section 4.4. The remaining values are
+   available for assignment through IETF Consensus [RFC 2434].
+
+10.2 Message Type AVP Values
+
+   As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0)
+   have an associated value maintained by IANA. Values 0-16 are defined
+   in Section 3.2, the remaining values are available for assignment via
+   IETF Consensus [RFC 2434]
+
+10.3 Result Code AVP Values
+
+   As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1)
+   contain three fields.  Two of these fields (the Result Code and Error
+   Code fields) have associated values maintained by IANA.
+
+10.3.1 Result Code Field Values
+
+   The Result Code AVP may be included in CDN and StopCCN messages. The
+   allowable values for the Result Code field of the AVP differ
+   depending upon the value of the Message Type AVP.  For the StopCCN
+   message, values 0-7 are defined in Section 4.4.2; for the StopCCN
+   message, values 0-11 are defined in the same section.  The remaining
+   values of the Result Code field for both messages are available for
+   assignment via IETF Consensus [RFC 2434].
+
+10.3.2 Error Code Field Values
+
+   Values 0-7 are defined in Section 4.4.2.  Values 8-32767 are
+   available for assignment via IETF Consensus [RFC 2434]. The remaining
+   values of the Error Code field are available for assignment via First
+   Come First Served [RFC 2434].
+
+10.4 Framing Capabilities & Bearer Capabilities
+
+   The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in
+   Section 4.4.3) both contain 32-bit bitmasks. Additional bits should
+   only be defined via a Standards Action [RFC 2434].
+
+10.5 Proxy Authen Type AVP Values
+
+   The Proxy Authen Type AVP (Attribute Type 29) has an associated value
+   maintained by IANA. Values 0-5 are defined in Section 4.4.5, the
+   remaining values are available for assignment via First Come First
+   Served [RFC 2434].
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 72]
+
+RFC 2661                          L2TP                       August 1999
+
+
+10.6 AVP Header Bits
+
+   There are four remaining reserved bits in the AVP header. Additional
+   bits should only be assigned via a Standards Action [RFC 2434].
+
+11.0 References
+
+   [DSS1]    ITU-T Recommendation, "Digital subscriber Signaling System
+             No. 1 (DSS 1) - ISDN user-network interface layer 3
+             specification for basic call control", Rec. Q.931(I.451),
+             May 1998
+
+   [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
+
+   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
+             Serial Links", RFC 1144, February 1990.
+
+   [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
+             RFC 1661, July 1994.
+
+   [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
+             July 1994.
+
+   [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
+
+   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+             1700, October 1994.  See also:
+             http://www.iana.org/numbers.html
+   [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
+             Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
+             August 1996.
+
+   [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
+             Protocol (CHAP)", RFC 1994, August 1996.
+
+   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
+             and E. Lear, "Address Allocation for Private Internets",
+             BCP 5, RFC 1918, February 1996.
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 73]
+
+RFC 2661                          L2TP                       August 1999
+
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+             Authentication Dial In User Service (RADIUS)", RFC 2138,
+             April 1997.
+
+   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+             Languages", BCP 18, RFC 2277, January 1998.
+
+   [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
+             Forwarding (Protocol) L2F", RFC 2341, May 1998.
+
+   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+             Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+   [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
+             and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
+             RFC 2637, July 1999.
+
+   [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
+             Protocols", Addison-Wesley Publishing Company, Inc., March
+             1996, ISBN 0-201-63346-9
+
+12.0 Acknowledgments
+
+   The basic concept for L2TP and many of its protocol constructs were
+   adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A.
+   Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein,
+   J. Taarud, W. Little, and G. Zorn.
+
+   Dory Leifer made valuable refinements to the protocol definition of
+   L2TP and contributed to the editing of this document.
+
+   Steve Cobb and Evan Caves redesigned the state machine tables.
+
+   Barney Wolff provided a great deal of design input on the endpoint
+   authentication mechanism.
+
+   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 this document.
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 74]
+
+RFC 2661                          L2TP                       August 1999
+
+
+13.0 Authors' Addresses
+
+   Gurdeep Singh Pall
+   Microsoft Corporation
+   Redmond, WA
+
+   EMail: gurdeep@microsoft.com
+
+
+   Bill Palter
+   RedBack Networks, Inc
+   1389 Moffett Park Drive
+   Sunnyvale, CA 94089
+
+   EMail: palter@zev.net
+
+
+   Allan Rubens
+   Ascend Communications
+   1701 Harbor Bay Parkway
+   Alameda, CA 94502
+
+   EMail: acr@del.com
+
+
+   W. Mark Townsley
+   cisco Systems
+   7025 Kit Creek Road
+   PO Box 14987
+   Research Triangle Park, NC 27709
+
+   EMail: townsley@cisco.com
+
+
+   Andrew J. Valencia
+   cisco Systems
+   170 West Tasman Drive
+   San Jose CA 95134-1706
+
+   EMail: vandys@cisco.com
+
+
+   Glen Zorn
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: gwz@acm.org
+
+
+
+Townsley, et al.            Standards Track                    [Page 75]
+
+RFC 2661                          L2TP                       August 1999
+
+
+Appendix A: Control Channel 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].
+
+   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 acknowledgement (either explicit or
+   piggybacked). When the acknowledgement 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 ZLB 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.
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 76]
+
+RFC 2661                          L2TP                       August 1999
+
+
+Appendix B: Control Message Examples
+
+B.1: Lock-step tunnel establishment
+
+   In this example, an LAC establishes a tunnel, with the exchange
+   involving each side alternating in sending messages.  This example
+   shows the final acknowledgment explicitly sent within a ZLB ACK
+   message. An alternative would be to piggyback the acknowledgement
+   within a message sent as a reply to the ICRQ or OCRQ that will likely
+   follow from the side that initiated the tunnel.
+
+          LAC or LNS               LNS or LAC
+          ----------               ----------
+
+          SCCRQ     ->
+          Nr: 0, Ns: 0
+                                   <-     SCCRP
+                                   Nr: 1, Ns: 0
+          SCCCN     ->
+          Nr: 1, Ns: 1
+                                   <-       ZLB
+                                   Nr: 2, Ns: 1
+
+B.2: Lost packet with retransmission
+
+   An existing tunnel has a new session requested by the LAC.  The ICRP
+   is lost and must be retransmitted by the LNS.  Note that loss of the
+   ICRP has two impacts: not only does it keep the upper level state
+   machine from progressing, but it also keeps the LAC from seeing a
+   timely lower level acknowledgment of its ICRQ.
+
+            LAC                               LNS
+            ---                               ---
+
+        ICRQ      ->
+        Nr: 1, Ns: 2
+
+                         (packet lost)   <-      ICRP
+                                         Nr: 3, Ns: 1
+
+      (pause; LAC's timer started first, so fires first)
+
+       ICRQ      ->
+       Nr: 1, Ns: 2
+
+       (Realizing that it has already seen this packet,
+       the LNS discards the packet and sends a ZLB)
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 77]
+
+RFC 2661                          L2TP                       August 1999
+
+
+                                         <-       ZLB
+                                         Nr: 3, Ns: 2
+
+                       (LNS's retransmit timer fires)
+
+                                         <-      ICRP
+                                         Nr: 3, Ns: 1
+       ICCN      ->
+       Nr: 2, Ns: 3
+
+                                         <-       ZLB
+                                         Nr: 4, Ns: 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 78]
+
+RFC 2661                          L2TP                       August 1999
+
+
+Appendix C: Intellectual Property Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 Secretariat."
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 79]
+
+RFC 2661                          L2TP                       August 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Townsley, et al.            Standards Track                    [Page 80]
+
diff --git a/rfc/rfc3931.txt b/rfc/rfc3931.txt
new file mode 100644
index 0000000..e428722
--- /dev/null
+++ b/rfc/rfc3931.txt
@@ -0,0 +1,5267 @@
+
+
+
+
+
+
+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]
+