File: rfc2661.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (4483 lines) | stat: -rw-r--r-- 168,150 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
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]