summaryrefslogtreecommitdiff
path: root/rfc/rfc2637.txt
blob: 56e9e0f5097081bc9e282f42d9b87abf413b754d (plain)
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






Network Working Group                                          K. Hamzeh
Request for Comments: 2637                         Ascend Communications
Category: Informational                                          G. Pall
                                                   Microsoft Corporation
                                                             W. Verthein
                                                                    3Com
                                                               J. Taarud
                                                Copper Mountain Networks
                                                               W. Little
                                                          ECI Telematics
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               July 1999


                Point-to-Point Tunneling Protocol (PPTP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   The PPTP protocol was developed by a vendor consortium. The
   documentation of PPTP is provided as information to the Internet
   community. The PPP WG is currently defining a Standards Track
   protocol (L2TP) for tunneling PPP across packet-switched networks.

Abstract

   This document specifies a protocol which allows the Point to Point
   Protocol (PPP) to be tunneled through an IP network.  PPTP does not
   specify any changes to the PPP protocol but rather describes a new
   vehicle for carrying PPP.  A client-server architecture is defined in
   order to decouple functions which exist in current Network Access
   Servers (NAS) and support Virtual Private Networks (VPNs).  The PPTP
   Network Server (PNS) is envisioned to run on a general purpose
   operating system while the client, referred to as a PPTP Access
   Concentrator (PAC) operates on a dial access platform.  PPTP
   specifies a call-control and management protocol which allows the
   server to control access for dial-in circuit switched calls
   originating from a PSTN or ISDN or to initiate outbound circuit-



Hamzeh, et al.               Informational                      [Page 1]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   switched connections.  PPTP uses an enhanced GRE (Generic Routing
   Encapsulation) mechanism to provide a flow- and congestion-controlled
   encapsulated datagram service for carrying PPP packets.

Specification of Requirements

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
   described in [12].

   The words "silently discard", when used in reference to the behavior
   of an implementation upon receipt of an incoming packet, are to be
   interpreted as follows: the implementation discards the datagram
   without further processing, and without indicating an error to the
   sender.  The implementation SHOULD provide the capability of logging
   the error, including the contents of the discarded datagram, and
   SHOULD record the event in a statistics counter.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.1.  Protocol Goals and Assumptions . . . . . . . . . . . . . .   4
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .   6
   1.3.1.  Control Connection Overview  . . . . . . . . . . . . . .   7
   1.3.2.  Tunnel Protocol Overview . . . . . . . . . . . . . . . .   7
   1.4.  Message Format and Protocol Extensibility  . . . . . . . .   8
   2.  Control Connection Protocol Specification  . . . . . . . . .  10
   2.1.  Start-Control-Connection-Request . . . . . . . . . . . . .  10
   2.2.  Start-Control-Connection-Reply . . . . . . . . . . . . . .  12
   2.3.  Stop-Control-Connection-Request  . . . . . . . . . . . . .  15
   2.4.  Stop-Control-Connection-Reply  . . . . . . . . . . . . . .  16
   2.5.  Echo-Request . . . . . . . . . . . . . . . . . . . . . . .  17
   2.6.  Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . .  18
   2.7.  Outgoing-Call-Request  . . . . . . . . . . . . . . . . . .  19
   2.8.  Outgoing-Call-Reply  . . . . . . . . . . . . . . . . . . .  22
   2.9.  Incoming-Call-Request  . . . . . . . . . . . . . . . . . .  25
   2.10.  Incoming-Call-Reply . . . . . . . . . . . . . . . . . . .  28
   2.11.  Incoming-Call-Connected . . . . . . . . . . . . . . . . .  29
   2.12.  Call-Clear-Request  . . . . . . . . . . . . . . . . . . .  31
   2.13.  Call-Disconnect-Notify  . . . . . . . . . . . . . . . . .  32
   2.14.  WAN-Error-Notify  . . . . . . . . . . . . . . . . . . . .  33
   2.15.  Set-Link-Info . . . . . . . . . . . . . . . . . . . . . .  35
   2.16.  General Error Codes . . . . . . . . . . . . . . . . . . .  36
   3.  Control Connection Protocol Operation  . . . . . . . . . . .  36
   3.1.  Control Connection States  . . . . . . . . . . . . . . . .  37
   3.1.1.  Control Connection Originator (may be PAC or PNS)  . . .  37
   3.1.2.  Control connection Receiver (may be PAC or PNS)  . . . .  39



Hamzeh, et al.               Informational                      [Page 2]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   3.1.3.  Start Control Connection Initiation Request Collision  .  40
   3.1.4.  Keep Alives and Timers . . . . . . . . . . . . . . . . .  40
   3.2.  Call States  . . . . . . . . . . . . . . . . . . . . . . .  41
   3.2.1.  Timing considerations  . . . . . . . . . . . . . . . . .  41
   3.2.2.  Call ID Values . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.  Incoming Calls . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.1.  PAC Incoming Call States . . . . . . . . . . . . . . .  42
   3.2.3.2.  PNS Incoming Call States . . . . . . . . . . . . . . .  43
   3.2.4.  Outgoing Calls . . . . . . . . . . . . . . . . . . . . .  44
   3.2.4.1.  PAC Outgoing Call States . . . . . . . . . . . . . . .  45
   3.2.4.2.  PNS Outgoing Call States . . . . . . . . . . . . . . .  46
   4.  Tunnel Protocol Operation  . . . . . . . . . . . . . . . . .  47
   4.1.  Enhanced GRE header  . . . . . . . . . . . . . . . . . . .  47
   4.2.  Sliding Window Protocol  . . . . . . . . . . . . . . . . .  49
   4.2.1.  Initial Window Size  . . . . . . . . . . . . . . . . . .  49
   4.2.2.  Closing the Window . . . . . . . . . . . . . . . . . . .  49
   4.2.3.  Opening the Window . . . . . . . . . . . . . . . . . . .  50
   4.2.4.  Window Overflow  . . . . . . . . . . . . . . . . . . . .  50
   4.2.5.  Multi-packet Acknowledgment  . . . . . . . . . . . . . .  50
   4.3.  Out-of-sequence Packets  . . . . . . . . . . . . . . . . .  50
   4.4.  Acknowledgment Time-Outs . . . . . . . . . . . . . . . . .  51
   4.4.1.  Calculating Adaptive Acknowledgment Time-Out . . . . . .  53
   4.4.2.  Congestion Control: Adjusting for Time-Out . . . . . . .  54
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  54
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  55
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . .  56
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  57

1.  Introduction

   PPTP allows existing Network Access Server (NAS) functions to be
   separated using a client-server architecture. Traditionally, the
   following functions are implemented by a NAS:

      1) Physical native interfacing to PSTN or ISDN and control of
         external modems or terminal adapters.

         A NAS may interface directly to a telco analog or digital
         circuit or attach via an external modem or terminal adapter.
         Control of a circuit-switched connection is accomplished with
         either modem control or DSS1 ISDN call control protocols.

         The NAS, in conjunction with the modem or terminal adapters,
         may perform rate adaption, analog to digital conversion, sync
         to async conversion or a number of other alterations of data
         streams.





Hamzeh, et al.               Informational                      [Page 3]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


      2) Logical termination of a Point-to-Point-Protocol (PPP) Link
         Control Protocol (LCP) session.

      3) Participation in PPP authentication protocols [3,9,10].

      4) Channel aggregation and bundle management for PPP Multilink
         Protocol.

      5) Logical termination of various PPP network control protocols
         (NCP).

      6) Multiprotocol routing and bridging between NAS interfaces.

   PPTP divides these functions between the PAC and PNS. The PAC is
   responsible for functions 1, 2, and possibly 3. The PNS may be
   responsible for function 3 and is responsible for functions 4, 5, and
   6.  The protocol used to carry PPP protocol data units (PDUs) between
   the PAC and PNS, as well as call control and management is addressed
   by PPTP.

   The decoupling of NAS functions offers these benefits:

      Flexible IP address management. Dial-in users may maintain a
      single IP address as they dial into different PACs as long as they
      are served from a common PNS. If an enterprise network uses
      unregistered addresses, a PNS associated with the enterprise
      assigns addresses meaningful to the private network.

      Support of non-IP protocols for dial networks behind IP networks.
      This allows Appletalk and IPX, for example to be tunneled through
      an IP-only provider. The PAC need not be capable of processing
      these protocols.

      A solution to the "multilink hunt-group splitting" problem.
      Multilink PPP, typically used to aggregate ISDN B channels,
      requires that all of the channels composing a multilink bundle be
      grouped at a single NAS.  Since a multilink PPP bundle can be
      handled by a single PNS, the channels comprising the bundle may be
      spread across multiple PACs.

1.1.  Protocol Goals and Assumptions

   The PPTP protocol is implemented only by the PAC and PNS. No other
   systems need to be aware of PPTP. Dial networks may be connected to a
   PAC without being aware of PPTP. Standard PPP client software should
   continue to operate on tunneled PPP links.





Hamzeh, et al.               Informational                      [Page 4]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   PPTP can also be used to tunnel a PPP session over an IP network. In
   this configuration the PPTP tunnel and the PPP session runs between
   the same two machines with the caller acting as a PNS.

   It is envisioned that there will be a many-to-many relationship
   between PACs and PNSs.  A PAC may provide service to many PNSs. For
   example, an Internet service provider may choose to support PPTP for
   a number of private network clients and create VPNs for them. Each
   private network may operate one or more PNSs. A single PNS may
   associate with many PACs to concentrate traffic from a large number
   of geographically diverse sites.

   PPTP uses an extended version of GRE to carry user PPP packets. These
   enhancements allow for low-level congestion and flow control to be
   provided on the tunnels used to carry user data between PAC and PNS.
   This mechanism allows for efficient use of the bandwidth available
   for the tunnels and avoids unnecessary retransmisions and buffer
   overruns.  PPTP does not dictate the particular algorithms to be used
   for this low level control but it does define the parameters that
   must be communicated in order to allow such algorithms to work.
   Suggested algorithms are included in section 4.

1.2.  Terminology

   Analog Channel

      A circuit-switched communication path which is intended to carry
      3.1 Khz audio in each direction.

   Digital Channel

      A circuit-switched communication path which is intended to carry
      digital information in each direction.

   Call

      A connection or attempted connection between two terminal
      endpoints on a PSTN or ISDN -- for example, a telephone call
      between two modems.

   Control Connection

      A control connection is created for each PAC, PNS pair and
      operates over TCP [4]. The control connection governs aspects of
      the tunnel and of sessions assigned to the tunnel.






Hamzeh, et al.               Informational                      [Page 5]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Dial User

      An end-system or router attached to an on-demand PSTN or ISDN
      which is either the initiator or recipient of a call.

   Network Access Server (NAS)

      A device providing temporary, on-demand network access to users.
      This access is point-to-point using PSTN or ISDN lines.

   PPTP Access Concentrator (PAC)

      A device attached to one or more PSTN or ISDN lines capable of PPP
      operation and of handling the PPTP protocol. The PAC need only
      implement TCP/IP to pass traffic to one or more PNSs. It may also
      tunnel non-IP protocols.

   PPTP Network Server (PNS)

      A PNS is envisioned to operate on general-purpose computing/server
      platforms. The PNS handles the server side of the PPTP protocol.
      Since PPTP relies completely on TCP/IP and is independent of the
      interface hardware, the PNS may use any combination of IP
      interface hardware including LAN and WAN devices.

   Session

      PPTP is connection-oriented.  The PNS and PAC maintain state for
      each user that is attached to a PAC.  A session is created when
      end-to-end PPP connection is attempted between a dial user and the
      PNS.  The datagrams related to a session are sent over the tunnel
      between the PAC and PNS.

   Tunnel

      A tunnel is defined by a PNS-PAC pair.  The tunnel protocol is
      defined by a modified version of GRE [1,2].  The tunnel carries
      PPP datagrams between the PAC and the PNS.  Many sessions are
      multiplexed on a single tunnel.  A control connection operating
      over TCP controls the establishment, release, and maintenance of
      sessions and of the tunnel itself.

1.3.  Protocol Overview

   There are two parallel components of PPTP: 1) a Control Connection
   between each PAC-PNS pair operating over TCP and 2) an IP tunnel
   operating between the same PAC-PNS pair which is used to transport
   GRE encapsulated PPP packets for user sessions between the pair.



Hamzeh, et al.               Informational                      [Page 6]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


1.3.1.  Control Connection Overview

   Before PPP tunneling can occur between a PAC and PNS, a control
   connection must be established between them. The control connection
   is a standard TCP session over which PPTP call control and management
   information is passed. The control session is logically associated
   with, but separate from, the sessions being tunneled through a PPTP
   tunnel.  For each PAC-PNS pair both a tunnel and a control connection
   exist. The control connection is responsible for establishment,
   management, and release of sessions carried through the tunnel. It is
   the means by which a PNS is notified of an incoming call at an
   associated PAC, as well as the means by which a PAC is instructed to
   place an outgoing dial call.

   A control connection can be established by either the PNS or the PAC.
   Following the establishment of the required TCP connection, the PNS
   and PAC establish the control connection using the Start-Control-
   Connection-Request and -Reply messages.  These messages are also used
   to exchange information about basic operating capabilities of the PAC
   and PNS.  Once the control connection is established, the PAC or PNS
   may initiate sessions by requesting outbound calls or responding to
   inbound requests. The control connection may communicate changes in
   operating characteristics of an individual user session with a Set-
   Link-Info message.  Individual sessions may be released by either the
   PAC or PNS, also through Control Connection messages.

   The control connection itself is maintained by keep-alive echo
   messages.  This ensures that a connectivity failure between the PNS
   and the PAC can be detected in a timely manner. Other failures can be
   reported via the

   Wan-Error-Notify message, also on the control connection.

   It is intended that the control connection will also carry management
   related messages in the future, such as a message allowing the PNS to
   request the status of a given PAC; these message types have not yet
   been defined.

1.3.2.  Tunnel Protocol Overview

   PPTP requires the establishment of a tunnel for each communicating
   PNS-PAC pair.  This tunnel is used to carry all user session PPP
   packets for sessions involving a given PNS-PAC pair.  A key which is
   present in the GRE header indicates which session a particular PPP
   packet belongs to.






Hamzeh, et al.               Informational                      [Page 7]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   In this manner, PPP packets are multiplexed and demultiplexed over a
   single tunnel between a given PNS-PAC pair.  The value to use in the
   key field is established by the call establishment procedure which
   takes place on the control connection.

   The GRE header also contains acknowledgment and sequencing
   information that is used to perform some level of congestion-control
   and error detection over the tunnel.  Again the control connection is
   used to determine rate and buffering parameters that are used to
   regulate the flow of PPP packets for a particular session over the
   tunnel.  PPTP does not specify the particular algorithms to use for
   congestion-control and flow-control.  Suggested algorithms for the
   determination of adaptive time-outs to recover from dropped data or
   acknowledgments on the tunnel are included in section 4.4 of this
   document.

1.4.  Message Format and Protocol Extensibility

   PPTP defines a set of messages sent as TCP data on the control
   connection between a PNS and a given PAC.  The TCP session for the
   control connection is established by initiating a TCP connection to
   port 1723 [6]. The source port is assigned to any unused port number.

   Each PPTP Control Connection message begins with an 8 octet fixed
   header portion.  This fixed header contains the following: the total
   length of the message, the PPTP Message Type indicator, and a "Magic
   Cookie".

   Two Control Connection message types are indicated by the PPTP
   Message Type field:

         1 - Control Message
         2 - Management Message

   Management messages are currently not defined.

   The Magic Cookie is always sent as the constant 0x1A2B3C4D.  Its
   basic purpose is to allow the receiver to ensure that it is properly
   synchronized with the TCP data stream.  It should not be used as a
   means for resynchronizing the TCP data stream in the event that a
   transmitter issues an improperly formatted message.  Loss of
   synchronization must result in immediate closing of the control
   connection's TCP session.

   For clarity, all Control Connection message templates in the next
   section include the entire PPTP Control Connection message header.
   Numbers preceded by 0x are hexadecimal values.




Hamzeh, et al.               Informational                      [Page 8]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


The currently defined Control Messages, grouped by function, are:

         Control Message                        Message Code

         (Control Connection Management)

         Start-Control-Connection-Request            1
         Start-Control-Connection-Reply              2
         Stop-Control-Connection-Request             3
         Stop-Control-Connection-Reply               4
         Echo-Request                                5
         Echo-Reply                                  6

         (Call Management)

         Outgoing-Call-Request                       7
         Outgoing-Call-Reply                         8
         Incoming-Call-Request                       9
         Incoming-Call-Reply                        10
         Incoming-Call-Connected                    11
         Call-Clear-Request                         12
         Call-Disconnect-Notify                     13

         (Error Reporting)

         WAN-Error-Notify                           14

         (PPP Session Control)

         Set-Link-Info                              15

   The Start-Control-Connection-Request and -Reply messages determine
   which version of the Control Connection protocol will be used.  The
   version number field carried in these messages consists of a version
   number in the high octet and a revision number in the low octet.
   Version handling is described in section 2. The current value of the
   version number field is 0x0100 for version 1, revision 0.

   The use of the GRE-like header for the encapsulation of PPP user
   packets is specified in section 4.1.

   The MTU for the user data packets encapsulated in GRE is 1532 octets,
   not including the IP and GRE headers.








Hamzeh, et al.               Informational                      [Page 9]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


2.  Control Connection Protocol Specification

   Control Connection messages are used to establish and clear user
   sessions.  The first set of Control Connection messages are used to
   maintain the control connection itself.  The control connection is
   initiated by either the PNS or PAC after they establish the
   underlying TCP connection.  The procedure and configuration
   information required to determine which TCP connections are
   established is not covered by this protocol.

   The following Control Connection messages are all sent as user data
   on the established TCP connection between a given PNS-PAC pair.  Note
   that care has been taken to ensure that all word (2 octet) and
   longword (4 octet) values begin on appropriate boundaries.  All data
   is sent in network order (high order octets first).  Any "reserved"
   fields MUST be sent as 0 values to allow for protocol extensibility.

2.1.  Start-Control-Connection-Request

   The Start-Control-Connection-Request is a PPTP control message used
   to establish the control connection between a PNS and a PAC.  Each
   PNS-PAC pair requires a dedicated control connection to be
   established.  A control connection must be established before any
   other PPTP messages can be issued.  The establishment of the control
   connection can be initiated by either the PNS or PAC.  A procedure
   which handles the occurrence of a collision between PNS and PAC
   Start-Control-Connection-Requests is described in section 3.1.3.
























Hamzeh, et al.               Informational                     [Page 10]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Framing Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Bearer Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length                   Total length in octets of this PPTP
                               message, including the entire PPTP
                               header.

      PPTP Message Type        1 for Control Message.

      Magic Cookie             0x1A2B3C4D. This constant value is used
                               as a sanity check on received messages
                               (see section 1.4).

      Control Message Type     1 for Start-Control-Connection-Request.

      Reserved0                This field MUST be 0.

      Protocol Version         The version of the PPTP protocol that the
                               sender wishes to use.

      Reserved1                This field MUST be 0.







Hamzeh, et al.               Informational                     [Page 11]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Framing Capabilities     A set of bits indicating the type of framing
                            that the sender of this message can provide.
                            The currently defined bit settings are:

                               1 - Asynchronous Framing supported

                               2 - Synchronous Framing supported

   Bearer Capabilities      A set of bits indicating the bearer
                            capabilities that the sender of this message
                            can provide.  The currently defined bit
                            settings are:

                               1 - Analog access supported

                               2 - Digital access supported

   Maximum Channels         The total number of individual PPP sessions
                            this PAC can support.  In Start-Control-
                            Connection-Requests issued by the PNS, this
                            value SHOULD be set to 0.  It MUST be
                            ignored by the PAC.

   Firmware Revision        This field contains the firmware revision
                            number of the issuing PAC, when issued by
                            the PAC, or the version of the PNS PPTP
                            driver if issued by the PNS.

   Host Name                A 64 octet field containing the DNS name of
                            the issuing PAC or PNS.  If less than 64
                            octets in length, the remainder of this
                            field SHOULD be filled with octets of value
                            0.

   Vendor Name              A 64 octet field containing a vendor
                            specific string describing the type of PAC
                            being used, or the type of PNS software
                            being used if this request is issued by the
                            PNS.  If less than 64 octets in length, the
                            remainder of this field SHOULD be filled
                            with octets of value 0.

2.2.  Start-Control-Connection-Reply

   The Start-Control-Connection-Reply is a PPTP control message sent in
   reply to a received Start-Control-Connection-Request message.  This
   message contains a result code indicating the result of the control
   connection establishment attempt.



Hamzeh, et al.               Informational                     [Page 12]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Framing Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Bearer Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     2 for Start-Control-Connection-Reply.

   Reserved0                This field MUST be 0.

   Protocol Version         The version of the PPTP protocol that the
                            sender wishes to use.

   Result Code              Indicates the result of the command channel
                            establishment attempt.  Current valid Result
                            Code values are:

                                  1 - Successful channel establishment

                                  2 - General error -- Error Code
                                      indicates the problem



Hamzeh, et al.               Informational                     [Page 13]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


                                  3 - Command channel already exists;

                                  4 - Requester is not authorized to
                                      establish a command channel

                                  5 - The protocol version of the
                                      requester is not supported

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.2.

   Framing Capabilities     A set of bits indicating the type of framing
                            that the sender of this message can provide.
                            The currently defined bit settings are:

                                  1 - Asynchronous Framing supported

                                  2 - Synchronous Framing supported.

   Bearer Capabilities      A set of bits indicating the bearer
                            capabilities that the sender of this message
                            can provide.  The currently defined bit
                            settings are:

                                  1 - Analog access supported

                                  2 - Digital access supported

   Maximum Channels         The total number of individual PPP sessions
                            this PAC can support.  In a Start-Control-
                            Connection-Reply issued by the PNS, this
                            value SHOULD be set to 0 and it must be
                            ignored by the PAC. The PNS MUST NOT use
                            this value to try to track the remaining
                            number of PPP sessions that the PAC will
                            allow.

   Firmware Revision        This field contains the firmware revision
                            number of the issuing PAC, or the version of
                            the PNS PPTP driver if issued by the PNS.








Hamzeh, et al.               Informational                     [Page 14]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Host Name                A 64 octet field containing the DNS name of
                            the issuing PAC or PNS.  If less than 64
                            octets in length, the remainder of this
                            field SHOULD be filled with octets of value
                            0.

   Vendor Name              A 64 octet field containing a vendor
                            specific string describing the type of PAC
                            being used, or the type of PNS software
                            being used if this request is issued by the
                            PNS.  If less than 64 octets in length, the
                            remainder of this field SHOULD be filled
                            with octets of value 0.

2.3.  Stop-Control-Connection-Request

   The Stop-Control-Connection-Request is a PPTP control message sent by
   one peer of a PAC-PNS control connection to inform the other peer
   that the control connection should be closed.  In addition to closing
   the control connection, all active user calls are implicitly cleared.
   The reason for issuing this request is indicated in the Reason field.

       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            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reason     |   Reserved1   |           Reserved2           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     3 for Stop-Control-Connection-Request.

   Reserved0                This field MUST be 0.

   Reason                   Indicates the reason for the control
                            connection being closed. Current valid
                            Reason values are:



Hamzeh, et al.               Informational                     [Page 15]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


                                  1 (None) - General request to clear
                                    control connection

                                  2 (Stop-Protocol) - Can't support
                                    peer's version of the protocol

                                  3 (Stop-Local-Shutdown) - Requester is
                                    being shut down

      Reserved1, Reserved2     These fields MUST be 0.

2.4.  Stop-Control-Connection-Reply

   The Stop-Control-Connection-Reply is a PPTP control message sent by
   one peer of a PAC-PNS control connection upon receipt of a Stop-
   Control-Connection-Request from the other peer.

       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             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     4 for Stop-Control-Connection-Reply.

   Reserved0                This field MUST be 0.

   Result Code              Indicates the result of the attempt to close
                            the control connection. Current valid Result
                            Code values are:








Hamzeh, et al.               Informational                     [Page 16]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


                                  1 (OK) - Control connection closed

                                  2 (General Error) - Control connection
                                    not closed for reason indicated in
                                    Error Code

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.2.

   Reserved1                This field MUST be 0.

2.5.  Echo-Request

   The Echo-Request is a PPTP control message sent by either peer of a
   PAC-PNS control connection. This control message is used as a "keep-
   alive" for the control connection.  The receiving peer issues an
   Echo-Reply to each Echo-Request received. As specified in section
   3.1.4, if the sender does not receive an Echo-Reply in response to an
   Echo-Request, it will eventually clear the control connection.

       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             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     5 for Echo-Request.

   Reserved0                This field MUST be 0.






Hamzeh, et al.               Informational                     [Page 17]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Identifier               A value set by the sender of the Echo-
                            Request that is used to match the reply with
                            the corresponding request.

2.6.  Echo-Reply

   The Echo-Reply is a PPTP control message sent by either peer of a
   PAC-PNS control connection in response to the receipt of an Echo-
   Request.

       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     6 for Echo-Reply.

   Reserved0                This field MUST be 0.

   Identifier               The contents of the identify field from the
                            received Echo-Request is copied to this
                            field.

   Result Code              Indicates the result of the receipt of the
                            Echo-Request. Current valid Result Code
                            values are:

                                  1 (OK) - The Echo-Reply is valid

                                  2 (General Error) - Echo-Request not
                                    accepted for the reason indicated in
                                    Error Code



Hamzeh, et al.               Informational                     [Page 18]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

   Reserved1                This field MUST be 0.

2.7.  Outgoing-Call-Request

   The Outgoing-Call-Request is a PPTP control message sent by the PNS
   to the PAC to indicate that an outbound call from the PAC is to be
   established.  This request provides the PAC with information required
   to make the call. It also provides information to the PAC that is
   used to regulate the transmission of data to the PNS for this session
   once it is established.


































Hamzeh, et al.               Informational                     [Page 19]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Minimum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Maximum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Bearer Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Phone Number Length      |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Phone Number (64 octets)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     7 for Outgoing-Call-Request.

   Reserved0                This field MUST be 0.









Hamzeh, et al.               Informational                     [Page 20]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Call ID                  A unique identifier, unique to a particular
                            PAC-PNS pair assigned by the PNS to this
                            session.  It is used to multiplex and
                            demultiplex data sent over the tunnel
                            between the PNS and PAC involved in this
                            session.

   Call Serial Number       An identifier assigned by the PNS to this
                            session for the purpose of identifying this
                            particular session in logged session
                            information.  Unlike the Call ID, both the
                            PNS and PAC associate the same Call Serial
                            Number with a given session. The combination
                            of IP address and call serial number SHOULD
                            be unique.

   Minimum BPS              The lowest acceptable line speed (in
                            bits/second) for this session.

   Maximum BPS              The highest acceptable line speed (in
                            bits/second) for this session.

   Bearer Type              A value indicating the bearer capability
                            required for this outgoing call.  The
                            currently defined values are:

                                  1 - Call to be placed on an analog
                                      channel

                                  2 - Call to be placed on a digital
                                      channel

                                  3 - Call can be placed on any type of
                                      channel

   Framing Type             A value indicating the type of PPP framing
                            to be used for this outgoing call.

                                  1 - Call to use Asynchronous framing

                                  2 - Call to use Synchronous framing

                                  3 - Call can use either type of
                                      framing

   Packet Recv. Window Size The number of received data packets the PNS
                            will buffer for this session.




Hamzeh, et al.               Informational                     [Page 21]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Packet Processing Delay  A measure of the packet processing delay
                            that might be imposed on data sent to the
                            PNS from the PAC.  This value is specified
                            in units of 1/10 seconds.  For the PNS this
                            number should be very small.  See section
                            4.4 for a description of how this value is
                            determined and used.

   Phone Number Length      The actual number of valid digits in the
                            Phone Number field.

   Reserved1                This field MUST be 0.

   Phone Number             The number to be dialed to establish the
                            outgoing session.  For ISDN and analog calls
                            this field is an ASCII string.  If the Phone
                            Number is less than 64 octets in length, the
                            remainder of this field is filled with
                            octets of value 0.

   Subaddress               A 64 octet field used to specify additional
                            dialing information.  If the subaddress is
                            less than 64 octets long, the remainder of
                            this field is filled with octets of value 0.

2.8.  Outgoing-Call-Reply

   The Outgoing-Call-Reply is a PPTP control message sent by the PAC to
   the PNS in response to a received Outgoing-Call-Request message.  The
   reply indicates the result of the outgoing call attempt.  It also
   provides information to the PNS about particular parameters used for
   the call.  It provides information to allow the PNS to regulate the
   transmission of data to the PAC for this session.


















Hamzeh, et al.               Informational                     [Page 22]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |          Cause Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     8 for Outgoing-Call-Reply.

   Reserved0                This field MUST be 0.

   Call ID                  A unique identifier for the tunnel, assigned
                            by the PAC to this session.  It is used to
                            multiplex and demultiplex data sent over the
                            tunnel between the PNS and PAC involved in
                            this session.

   Peer's Call ID           This field is set to the value received in
                            the Call ID field of the corresponding
                            Outgoing-Call-Request message.  It is used
                            by the PNS to match the Outgoing-Call-Reply
                            with the Outgoing-Call-Request it issued. It
                            also is used as the value sent in the GRE
                            header for mux/demuxing.







Hamzeh, et al.               Informational                     [Page 23]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Result Code              This value indicates the result of the
                            Outgoing-Call-Request attempt.  Currently
                            valid values are:

                                  1 (Connected) - Call established with
                                    no errors

                                  2 (General Error) - Outgoing Call not
                                    established for the reason indicated
                                    in Error Code

                                  3 (No Carrier) - Outgoing Call failed
                                    due to no carrier detected

                                  4 (Busy) - Outgoing Call failed due to
                                    detection of a busy signal

                                  5 (No Dial Tone) - Outgoing Call
                                    failed due to lack of a dial tone

                                  6 (Time-out) - Outgoing Call was not
                                    established within time allotted by
                                    PAC

                                  7 (Do Not Accept) - Outgoing Call
                                    administratively prohibited

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

   Cause Code               This field gives additional failure
                            information.  Its value can vary depending
                            upon the type of call attempted.  For ISDN
                            call attempts it is the Q.931 cause code.

   Connect Speed            The actual connection speed used, in
                            bits/second.

   Packet Recv. Window Size The number of received data packets the PAC
                            will buffer for this session.







Hamzeh, et al.               Informational                     [Page 24]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Packet Processing Delay  A measure of the packet processing delay
                            that might be imposed on data sent to the
                            PAC from the PNS.  This value is specified
                            in units of 1/10 seconds.  For the PAC, this
                            number is related to the size of the buffer
                            used to hold packets to be sent to the
                            client and to the speed of the link to the
                            client.  This value should be set to the
                            maximum delay that can normally occur
                            between the time a packet arrives at the PAC
                            and is delivered to the client.  See section
                            4.4 for an example of how this value is
                            determined and used.

   Physical Channel ID      This field is set by the PAC in a vendor-
                            specific manner to the physical channel
                            number used to place this call.  It is used
                            for logging purposes only.

2.9.  Incoming-Call-Request

   The Incoming-Call-Request is a PPTP control message sent by the PAC
   to the PNS to indicate that an inbound call is to be established from
   the PAC.  This request provides the PNS with parameter information
   for the incoming call.

   This message is the first in the "three-way handshake" used by PPTP
   for establishing incoming calls.  The PAC may defer answering the
   call until it has received an Incoming-Call-Reply from the PNS
   indicating that the call should be established. This mechanism allows
   the PNS to obtain sufficient information about the call before it is
   answered to determine whether the call should be answered or not.



















Hamzeh, et al.               Informational                     [Page 25]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Call Bearer Type                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Dialed Number Length      |     Dialing Number Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Dialed Number (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Dialing Number (64 octets)                   +
      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     9 for Incoming-Call-Request.

   Reserved0                This field MUST be 0.

   Call ID                  A unique identifier for this tunnel,
                            assigned by the PAC to this session.  It is
                            used to multiplex and demultiplex data sent
                            over the tunnel between the PNS and PAC
                            involved in this session.





Hamzeh, et al.               Informational                     [Page 26]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Call Serial Number       An identifier assigned by the PAC to this
                            session for the purpose of identifying this
                            particular session in logged session
                            information.  Unlike the Call ID, both the
                            PNS and PAC associate the same Call Serial
                            Number to a given session. The combination
                            of IP address and call serial number should
                            be unique.

   Bearer Type              A value indicating the bearer capability
                            used for this incoming call.  Currently
                            defined values are:

                                  1 - Call is on an analog channel

                                  2 - Call is on a digital channel

   Physical Channel ID      This field is set by the PAC in a vendor-
                            specific manner to the number of the
                            physical channel this call arrived on.

   Dialed Number Length     The actual number of valid digits in the
                            Dialed Number field.

   Dialing Number Length    The actual number of valid digits in the
                            Dialing Number field.

   Dialed Number            The number that was dialed by the caller.
                            For ISDN and analog calls this field is an
                            ASCII string.  If the Dialed Number is less
                            than 64 octets in length, the remainder of
                            this field is filled with octets of value 0.

   Dialing Number           The number from which the call was placed.
                            For ISDN and analog calls this field is an
                            ASCII string.  If the Dialing Number is less
                            than 64 octets in length, the remainder of
                            this field is filled with octets of value 0.

   Subaddress               A 64 octet field used to specify additional
                            dialing information.  If the subaddress is
                            less than 64 octets long, the remainder of
                            this field is filled with octets of value 0.








Hamzeh, et al.               Informational                     [Page 27]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


2.10.  Incoming-Call-Reply

   The Incoming-Call-Reply is a PPTP control message sent by the PNS to
   the PAC in response to a received Incoming-Call-Request message.  The
   reply indicates the result of the incoming call attempt.  It also
   provides information to allow the PAC to regulate the transmission of
   data to the PNS for this session.

   This message is the second in the three-way handshake used by PPTP
   for establishing incoming calls.  It indicates to the PAC whether the
   call should be answered or not.

       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             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |   Packet Recv. Window Size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Packet Transmit Delay     |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     10 for Incoming-Call-Reply.

   Reserved0                This field MUST be 0.

   Call ID                  A unique identifier for this tunnel assigned
                            by the PNS to this session.  It is used to
                            multiplex and demultiplex data sent over the
                            tunnel between the PNS and PAC involved in
                            this session.

   Peer's Call ID           This field is set to the value received in
                            the Call ID field of the corresponding
                            Incoming-Call-Request message. It is used by



Hamzeh, et al.               Informational                     [Page 28]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


                            the PAC to match the Incoming-Call-Reply
                            with the Incoming-Call-Request it issued.
                            This value is included in the GRE header of
                            transmitted data packets for this session.

   Result Code              This value indicates the result of the
                            Incoming-Call-Request attempt.  Current
                            valid Result Code values are:

                                  1 (Connect) - The PAC should answer
                                    the incoming call

                                  2 (General Error) - The Incoming Call
                                    should not be established due to the
                                    reason indicated in Error Code

                                  3 (Do Not Accept) - The PAC should not
                                    accept the incoming call.  It should
                                    hang up or issue a busy indication

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

   Packet Recv. Window Size The number of received data packets the PAC
                            will buffer for this session.

   Packet Transmit Delay    A measure of the packet processing delay
                            that might be imposed on data sent to the
                            PAC from the PNS.  This value is specified
                            in units of 1/10 seconds.

   Reserved1                This field MUST be 0.

2.11.  Incoming-Call-Connected

   The Incoming-Call-Connected message is a PPTP control message sent by
   the PAC to the PNS in response to a received Incoming-Call-Reply.  It
   provides information to the PNS about particular parameters used for
   the call.  It also provides information to allow the PNS to regulate
   the transmission of data to the PAC for this session.

   This message is the third in the three-way handshake used by PPTP for
   establishing incoming calls.  It provides a mechanism for providing
   the PNS with additional information about the call that cannot, in



Hamzeh, et al.               Informational                     [Page 29]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   general, be obtained at the time the Incoming-Call-Request is issued
   by the PAC.

       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Peer's Call ID          |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |     Packet Transmit Delay     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     11 for Incoming-Call-Connected.

   Reserved0                This field MUST be 0.

   Peer's Call ID           This field is set to the value received in
                            the Call ID field of the corresponding
                            Incoming-Call-Reply message.  It is used by
                            the PNS to match the Incoming-Call-Connected
                            with the Incoming-Call-Reply it issued.

   Connect Speed            The actual connection speed used, in
                            bits/second.

   Packet Recv. Window Size The number of received data packets the PAC
                            will buffer for this session.

   Packet Transmit Delay    A measure of the packet processing delay
                            that might be imposed on data sent to the
                            PAC from the PNS.  This value is specified
                            in units of 1/10 seconds.



Hamzeh, et al.               Informational                     [Page 30]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Framing Type             A value indicating the type of PPP framing
                            being used by this incoming call.

                                  1 - Call uses asynchronous framing

                                  2 - Call uses synchronous framing

2.12.  Call-Clear-Request

   The Call-Clear-Request is a PPTP control message sent by the PNS to
   the PAC indicating that a particular call is to be disconnected.  The
   call being cleared can be either an incoming or outgoing call, in any
   state.  The PAC responds to this message with a Call-Disconnect-
   Notify message.

       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     12 for Call-Clear-Request.

   Reserved0                This field MUST be 0.

   Call ID                  The Call ID assigned by the PNS to this
                            call.  This value is used instead of the
                            Peer's Call ID because the latter may not be
                            known to the PNS if the call must be aborted
                            during call establishment.

   Reserved1                This field MUST be 0.






Hamzeh, et al.               Informational                     [Page 31]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


2.13.  Call-Disconnect-Notify

   The Call-Disconnect-Notify message is a PPTP control message sent by
   the PAC to the PNS.  It is issued whenever a call is disconnected,
   due to the receipt by the PAC of a Call-Clear-Request or for any
   other reason.  Its purpose is to inform the PNS of both the
   disconnection and the reason for it.

       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Cause Code           |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +              Call Statistics (128 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     13 for Call-Disconnect-Notify.

   Reserved0                This field MUST be 0.

   Call ID                  The value of the Call ID assigned by the PAC
                            to this call.  This value is used instead of
                            the Peer's Call ID because the latter may
                            not be known to the PNS if the call must be
                            aborted during call establishment.









Hamzeh, et al.               Informational                     [Page 32]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Result Code              This value indicates the reason for the
                            disconnect. Current valid Result Code values
                            are:

                                  1 (Lost Carrier) - Call disconnected
                                    due to loss of carrier

                                  2 (General Error) - Call disconnected
                                    for the reason indicated in Error
                                    Code

                                  3 (Admin Shutdown) - Call disconnected
                                    for administrative reasons

                                  4 (Request) - Call disconnected due to
                                    received Call-Clear-Request

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case the
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

   Cause Code               This field gives additional disconnect
                            information.  Its value varies depending on
                            the type of call being disconnected.  For
                            ISDN calls it is the Q.931 cause code.

   Call Statistics          This field is an ASCII string containing
                            vendor-specific call statistics that can be
                            logged for diagnostic purposes.  If the
                            length of the string is less than 128, the
                            remainder of the field is filled with octets
                            of value 0.

2.14.  WAN-Error-Notify

   The WAN-Error-Notify message is a PPTP control message sent by the
   PAC to the PNS 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.







Hamzeh, et al.               Informational                     [Page 33]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Peer's Call ID         |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          CRC Errors                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Framing Errors                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Hardware Overruns                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Buffer Overruns                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Time-out Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Alignment Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     14 for WAN-Error-Notify.

   Reserved0                This field MUST be 0.

   Peer's Call ID           Th Call ID assigned by the PNS to this call.

   CRC Errors               Number of PPP frames received with CRC
                            errors since session was established.

   Framing Errors           Number of improperly framed PPP packets
                            received.

   Hardware Overruns        Number of receive buffer over-runs since
                            session was established.

   Buffer Overruns          Number of buffer over-runs detected since
                            session was established.



Hamzeh, et al.               Informational                     [Page 34]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Time-out Errors          Number of time-outs since call was
                            established.

   Alignment Errors         Number of alignment errors since call was
                            established.

2.15.  Set-Link-Info

   The Set-Link-Info message is a PPTP control message sent by the PNS
   to the PAC to set PPP-negotiated options.  Because these options can
   change at any time during the life of the call, the PAC must be able
   to update its internal call information dynamically and perform PPP
   negotiation on an active PPP session.

       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             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Peer's Call ID         |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Send ACCM                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receive ACCM                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     15 for Set-Link-Info.

   Reserved0                This field MUST be 0.

   Peer's Call ID           The value of the Call ID assigned by the PAC
                            to this call.

   Reserved1                This field MUST be 0.






Hamzeh, et al.               Informational                     [Page 35]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Send ACCM                The send ACCM value the client should use to
                            process outgoing PPP packets.  The default
                            value used by the client until this message
                            is received is 0XFFFFFFFF.  See [7].

   Receive ACCM             The receive ACCM value the client should use
                            to process incoming PPP packets. The default
                            value used by the client until this message
                            is received is 0XFFFFFFFF.  See [7].

2.16.  General Error Codes

   General error codes pertain to types of errors which are not specific
   to any particular PPTP request, but rather to protocol or message
   format errors.  If a PPTP reply indicates in its Result Code that a
   general error occurred, the General Error value should be examined to
   determined what the error was.  The currently defined General Error
   codes and their meanings are:

      0 (None)          - No general error

      1 (Not-Connected) - No control connection exists yet for this
                          PAC-PNS pair

      2 (Bad-Format)    - Length is wrong or Magic Cookie value is
                          incorrect

      3 (Bad-Value)     - One of the field values was out of range or
                          reserved field was non-zero

      4 (No-Resource)   - Insufficient resources to handle this command
                          now

      5 (Bad-Call ID)    - The Call ID is invalid in this context

      6 (PAC-Error)     - A generic vendor-specific error occurred in
                          the PAC

3.  Control Connection Protocol Operation

   This section describes the operation of various PPTP control
   connection functions and the Control Connection messages which are
   used to support them.  The protocol operation of the control
   connection is simplified because TCP is used to provide a reliable
   transport mechanism.  Ordering and retransmission of messages is not
   a concern at this level.  The TCP connection itself, however, can
   close at any time and an appropriate error recovery mechanism must be
   provided to handle this case.



Hamzeh, et al.               Informational                     [Page 36]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Some error recovery procedures are common to all states of the
   control connection.  If an expected reply does not arrive within 60
   seconds, the control connection is closed, unless otherwise
   specified.  Appropriate logging should be implemented for easy
   determination of the problems and the reasons for closing the control
   connection.

   Receipt of an invalid or malformed Control Connection message should
   be logged appropriately, and the control connection should be closed
   and restarted to ensure recovery into a known state.

3.1.  Control Connection States

   The control connection relies on a standard TCP connection for its
   service.  The PPTP control connection protocol is not distinguishable
   between the PNS and PAC, but is distinguishable between the
   originator and receiver. The originating peer is the one which first
   attempts the TCP open. Since either PAC or PNS may originate a
   connection, it is possible for a TCP collision to occur.  See section
   3.1.3 for a description of this situation.

3.1.1.  Control Connection Originator (may be PAC or PNS)

                TCP Open Indication
                /Send Start Control
                  Connection Request       +-----------------+
     +------------------------------------>|  wait_ctl_reply |
     |                                     +-----------------+
     |     Collision/See (4.1.3) Close TCP   V  V  V   Receive Start Ctl
     |       +-------------------------------+  |  |   Connection Reply
     |       |                                  |  |   Version OK
     ^       V                                  |  V
+-----------------+          Receive Start Ctl  | +-----------------+
|      idle       |          Connection Reply   | |   established   |
+-----------------+          Version Not OK     | +-----------------+
     ^                                          |  V   Local Terminate
     |         Receive Stop Control             |  |   /Send Stop
     |         Connection Request               |  |    Control Request
     |         /Send Stop Control Reply         V  V
     |          Close TCP                  +-----------------+
     +-------------------------------------| wait_stop_reply |
                                           +-----------------+









Hamzeh, et al.               Informational                     [Page 37]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   idle
      The control connection originator attempts to open a TCP
      connection to the peer during idle state. When the TCP connection
      is open, the originator transmits a send Start-Control-
      Connection-Request and then enters the wait_ctl_reply state.

   wait_ctl_reply
      The originator checks to see if another TCP connection has been
      requested from the same peer, and if so, handles the collision
      situation described in section 3.1.3.

      When a Start-Control-Connection-Reply 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 the version is earlier and not supported, a
      Stop-Control-Connection-Request SHOULD be sent to the peer and the
      originator moves into the wait_stop_reply state.

   established
      An established connection may be terminated by either a local
      condition or the receipt of a Stop-Control-Connection-Request. In
      the event of a local termination, the originator MUST send a
      Stop-Control-Connection-Request and enter the wait_stop_reply
      state.

      If the originator receives a Stop-Control-Connection-Request it
      SHOULD send a Stop-Control-Connection-Reply and close the TCP
      connection making sure that the final TCP information has been
      "pushed" properly.

   wait_stop_reply
      If a Stop-Control-Connection-Reply is received, the TCP connection
      SHOULD be closed and the control connection becomes idle.
















Hamzeh, et al.               Informational                     [Page 38]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


3.1.2.  Control connection Receiver (may be PAC or PNS)

Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
  +--------+
  |        |         Receive Control Connection Request Version OK
  |        |         /Send Start Control Connection Reply
  |        |   +----------------------------------------+
  ^        V   ^                                        V
+-----------------+             Receive Start Ctl    +-----------------+
|      Idle       |             Connection Request   |   Established   |
+-----------------+             /Send Stop Reply     +-----------------+
        ^      ^                 Close TCP           V  V Local Terminate
        |      +-------------------------------------+  | /Send Stop
        |                                               |  Control Conn.
        |                                               V  Request
        |                                     +-----------------+
        +-------------------------------------| Wait-Stop-Reply |
                 Receive Stop Control         +-----------------+
                 Connection Reply
                 /Close TCP

   idle
      The control connection receiver waits for a TCP open attempt on
      port 1723. When notified of an open TCP connection, it should
      prepare to receive PPTP messages.  When a Start-Control-
      Connection-Request is received its version field should be
      examined. If the version is earlier than the receiver's version
      and the earlier version can be supported by the receiver, the
      receiver SHOULD send a Start-Control-Connection-Reply. If the
      version is earlier than the receiver's version and the version
      cannot be supported, the receiver SHOULD send a Start-Connection-
      Reply message, close the TCP connection and remain in the idle
      state.  If the receiver's version is the same as earlier than the
      peer's, the receiver SHOULD send a Start-Control-Connection-Reply
      with the receiver's version and enter the established state.

   established
      An established connection may be terminated by either a local
      condition or the reception of a Stop-Control-Connection-Request.
      In the event of a local termination, the originator MUST send a
      Stop-Control-Connection-Request and enter the wait_stop_reply
      state.







Hamzeh, et al.               Informational                     [Page 39]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


      If the originator receives a Stop-Control-Connection-Request it
      SHOULD send a Stop-Control-Connection-Reply and close the TCP
      connection, making sure that the final TCP information has been
      "pushed" properly.

   wait_stop_reply
      If a Stop-Control-Connection-Reply is received, the TCP connection
      SHOULD be closed and the control connection becomes idle.

3.1.3.  Start Control Connection Initiation Request Collision

   A PAC and PNS must have only one control connection between them. It
   is possible, however, for a PNS and a PAC to simultaneously attempt
   to establish a control connection to each other. When a Start-
   Control-Connection-Request is received on one TCP connection and
   another Start-Control-Connection-Request has already been sent on
   another TCP connection to the same peer, a collision has occurred.

   The "winner" of the initiation race is the peer with the higher IP
   address (compared as 32 bit unsigned values, network number more
   significant). For example, if the peers 192.33.45.17 and 192.33.45.89
   collide, the latter will be declared the winner.  The loser will
   immediately close the TCP connection it initiated, without sending
   any further PPTP control messages on it and will respond to the
   winner's request with a Start-Control-Connection-Reply message. The
   winner will wait for the Start-Control-Connection-Reply on the
   connection it initiated and also wait for a TCP termination
   indication on the connection the loser opened.  The winner MUST NOT
   send any messages on the connection the loser initiated.

3.1.4.  Keep Alives and Timers

   A control connection SHOULD be closed by closing the underlying TCP
   connection under the following circumstances:

   1. If a control connection is not in the established state (i.e.,
      Start-Control-Connection-Request and Start-Control-Connection-
      Reply have not been exchanged), a control connection SHOULD be
      closed after 60 seconds by a peer waiting for a Start-Control-
      Connection-Request or Start-Control-Connection-Reply message.

   2. If a peer's control connection is in the established state and has
      not received a control message for 60 seconds, it SHOULD send a
      Echo-Request message. If an Echo-Reply is not received 60 seconds
      after the Echo-Request message transmission, the control
      connection SHOULD be closed.





Hamzeh, et al.               Informational                     [Page 40]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


3.2.  Call States

3.2.1.  Timing considerations

   Because of the real-time nature of telephone signaling, both the PNS
   and PAC should be implemented with multi-threaded architectures such
   that messages related to multiple calls are not serialized and
   blocked. The transit delay between the PAC and PNS should not exceed
   one second. The call and connection state figures do not specify
   exceptions caused by timers. The implicit assumption is that since
   the TCP-based control connection is being verified with keep-alives,
   there is less need to maintain strict timers for call control
   messages.

   Establishing outbound international calls, including the modem
   training and negotiation sequences, may take in excess of 1 minute so
   the use of short timers is discouraged.

   If a state transition does not occur within 1 minute (except for
   connections in the idle or established states), the integrity of the
   protocol processing between the peers is suspect and the ENTIRE
   CONTROL CONNECTION should be closed and restarted. All Call IDs are
   logically released whenever a control connection is started. This
   presumably also helps in preventing toll calls from being "lost" and
   never cleared.

3.2.2.  Call ID Values

   Each peer assigns a Call ID value to each user session it requests or
   accepts. This Call ID value MUST be unique for the tunnel between the
   PNS and PAC to which it belongs. Tunnels to other peers can use the
   same Call ID number so the receiver of a packet on a tunnel needs to
   associate a user session with a particular tunnel and Call ID.  It is
   suggested that the number of potential Call ID values for each tunnel
   be at least twice as large as the maximum number of calls expected on
   a given tunnel.

   A session is defined by the triple (PAC, PNS, Call ID).

3.2.3.  Incoming Calls

   An Incoming-Call-Request message is generated by the PAC when an
   associated telephone line rings. The PAC selects a Call 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





Hamzeh, et al.               Informational                     [Page 41]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   digital modems are involved. Dialing number, dialed number, and
   subaddress may be included in the message if they are available from
   the telephone network.

   Once the PAC sends the Incoming-Call-Request, it waits for a response
   from the PNS but does not answer the call from the telephone network.
   The PNS may choose not to accept the call if:

      -  No resources are available to handle more sessions

      -  The dialed, dialing, or subaddress fields are not indicative of
         an authorized user

      -  The bearer service is not authorized or supported

   If the PNS chooses to accept the call, it responds with an Incoming-
   Call-Reply which also indicates window sizes (see section 4.2). When
   the PAC receives the Outgoing-Call-Reply, it attempts to connect the
   call, assuming the calling party has not hung up. A final call
   connected message from the PAC to the PNS indicates that the call
   states for both the PAC and the PNS should enter the established
   state.

   When the dialed-in client hangs up, the call is cleared normally and
   the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to
   clear a call, it sends a Call-Clear-Request message and then waits
   for a Call-Disconnect-Notify.

3.2.3.1.  PAC Incoming Call States

    Ring/Send Incoming Call Request          +-----------------+
  +----------------------------------------->|    wait_reply   |
  |                                          +-----------------+
  |           Receive Incoming Call Reply    V  V  V
  |           Not Accepting                  |  |  |   Receive Incoming
  |         +--------------------------------+  |  |   Call Reply Accept-
  |         |    +------------------------------+  |   ing/Answer call;
  |         |    |     Abort/Send Call             |   Send Call
  ^         V    V     Disconnect Notify           V   Connected
+-----------------+                              +-----------------+
|      idle       |<-----------------------------|   established   |
+-----------------+  Receive Clear Call Request  +-----------------+
                     or telco call dropped
                     or local disconnect
                     /Send Call Disconnect Notify






Hamzeh, et al.               Informational                     [Page 42]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


The states associated with the PAC for incoming calls are:

   idle
      The PAC detects an incoming call on one of its telco interfaces.
      Typically this means an analog line is ringing or an ISDN TE has
      detected an incoming Q.931 SETUP message. The PAC sends an
      Incoming-Call-Request message and moves to the wait_reply state.

   wait_reply
      The PAC receives an Incoming-Call-Reply message indicating non-
      willingness to accept the call (general error or don't accept) and
      moves back into the idle state. If the reply message indicates
      that the call is accepted, the PAC 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 telco connection. The PAC sends a
         Call-Disconnect-Notify message

         Receipt of a Call-Clear-Request.  The PAC sends a
         Call-Disconnect-Notify message

         A local reason. The PAC sends a Call-Disconnect-Notify message.

3.2.3.2.  PNS Incoming Call States

  Receive Incoming Call Request
  /Send Incoming Call Reply                  +-----------------+
   Not Accepting if Error                    |   Wait-Connect  |
  +-----+                                    +-----------------+
  |     |     Receive Incoming Call Req.     ^  V  V
  |     |     /Send Incoming Call Reply OK   |  |  |   Receive Incoming
  |     |   +--------------------------------+  |  |   Call Connect
  ^     V   ^    V------------------------------+  V
+-----------------+  Receive Call Disconnect     +-----------------+
|      Idle       |  Notify                   +- |   Established   |
+-----------------+                           |  +-----------------+
        ^        ^                            |   V   Local Terminate
        |        +----------------------------+   |   /Send Call Clear
        |            Receive Call Disconnect      |    Request
        |            Notify                       V
        |                                      +-----------------+
        +--------------------------------------| Wait-Disconnect |
                     Receive Call Disconnect   +-----------------+
                     Notify



Hamzeh, et al.               Informational                     [Page 43]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


The states associated with the PNS for incoming calls are:

   idle
      An Incoming-Call-Request message is received. If the request is
      not acceptable, an Incoming-Call-Reply is sent back to the PAC and
      the PNS remains in the idle state.  If the Incoming-Call-Request
      message is acceptable, an Incoming-Call-Reply is sent indicating
      accept in the result code. The session moves to the wait_connect
      state.

   wait_connect
      If the session is connected on the PAC, the PAC sends an incoming
      call connect message to the PNS which then moves into established
      state. The PAC may send a Call-Disconnect-Notify to indicate that
      the incoming caller could not be connected.  This could happen,
      for example, if a telephone user accidently places a standard
      voice call to a PAC 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 PAC or by sending a Call-Clear-Request.
      Once a Call-Clear-Request has been sent, the session enters the
      wait_disconnect state.

   wait_disconnect
      Once a Call-Disconnect-Notify is received the session moves back
      to the idle state.

3.2.4.  Outgoing Calls

   Outgoing messages are initiated by a PNS and instruct a PAC to place
   a call on a telco interface. There are only two messages for outgoing
   calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends
   an Outgoing-Call-Request specifying the dialed party phone number and
   subaddress as well as speed and window parameters. The PAC MUST
   respond to the Outgoing-Call-Request message with an Outgoing-Call-
   Reply message once the PAC determines that:

      The call has been successfully connected

      A call failure has occurred for reasons such as: no interfaces are
      available for dial-out, the called party is busy or does not
      answer, or no dial tone is detected on the interface chosen for
      dialing






Hamzeh, et al.               Informational                     [Page 44]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


3.2.4.1.  PAC Outgoing Call States

Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
  |--------+
  |        |         Receive Outgoing Call Request No Error
  |        |         /Off Hook; Dial
  |        |   +-----------------------------------------
  ^        V   ^                                        V
+-----------------+           Incomplete Call        +-----------------+
|      idle       |           /Send Outgoing Call    |   wait_cs_ans   |
+-----------------+            Reply with Error      +-----------------+
        ^      ^           or Recv. Call Clear Req.  V  V Telco Answer
        |      |              /Send Disconnect Notify|  | /Send Outgoing
        |      +-------------------------------------+  |  Call Reply.
        |                                               V
        |                                     +-----------------+
        +-------------------------------------|   established   |
                 Receive Call Clear Request   +-----------------+
                 or local terminate
                 or telco disconnect
                 /Hangup call and send
                 Call Disconnect Notify

   The states associated with the PAC for outgoing calls are:

   idle
      Received Outgoing-Call-Request. If this is received in error,
      respond with an Outgoing-Call-Reply with error condition set.
      Otherwise, allocate physical channel to dial on. Place the
      outbound call, wait for a connection, and move to the wait_cs_ans
      state.

   wait_cs_ans
      If the call is incomplete, send an Outgoing-Call-Reply with a
      non-zero Error Code. If a timer expires on an outbound call, send
      back an Outgoing-Call-Reply with a non-zero Error Code. If a
      circuit switched connection is established, send an Outgoing-
      Call-Reply indicating success.

   established
      If a Call-Clear-Request is received, the telco call SHOULD be
      released via appropriate mechanisms and a Call-Disconnect-Notify
      message SHOULD BE sent to the PNS. If the call is disconnected by
      the client or by the telco interface, a Call-Disconnect-Notify
      message SHOULD be sent to the PNS.





Hamzeh, et al.               Informational                     [Page 45]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


3.2.4.2.  PNS Outgoing Call States

                Open Indication                              Abort/Send
                /Send Outgoing Call                          Call Clear
                 Request                  +-----------------+Request
        +-------------------------------->|    Wait-Reply   |----------+
        |                                 +-----------------+          |
        |     Receive Outgoing Call Reply   V     V   Receive Outgoing |
        |     with Error                    |     |   Call Reply       |
        |   +-------------------------------+     |   No Error         |
        ^   V                                     V                    |
+-----------------+                              +-----------------+   |
|      Idle       |<-----------------------------|   Established   |   |
+-----------------+    Receive Call Disconnect   +-----------------+   |
        ^              Notify                     V   Local Terminate  |
        |                                         |   /Send Call Clear |
        |                                         |    Request         |
        |     Receive Call Disconnect             V                    |
        |     Notify                      +-----------------+          |
        +---------------------------------| Wait-Disconnect |<---------+
                                          +-----------------+

The states associated with the PNS for outgoing calls are:

   idle
      An Outgoing-Call-Request message is sent to the PAC and the
      session moves into the wait_reply state.

   wait_reply
      An Outgoing-Call-Reply is received which indicates an error. The
      session returns to idle state. No telco call is active. If the
      Outgoing-Call-Reply does not indicate an error, the telco call is
      connected and the session moves to the established state.

   established
      If a Call-Disconnect-Notify is received, the telco call has been
      terminated for the reason indicated in the Result and Cause Codes.
      The session moves back to the idle state. If the PNS chooses to
      terminate the session, it sends a Call-Clear-Request to the PAC
      and then enters the wait_disconnect state.

   wait_disconnect
      A session disconnection is waiting to be confirmed by the PAC.
      Once the PNS receives the Call-Disconnect-Notify message, the
      session enters idle state.






Hamzeh, et al.               Informational                     [Page 46]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


4.  Tunnel Protocol Operation

   The user data carried by the PPTP protocol are PPP data packets.  PPP
   packets are carried between the PAC and PNS, encapsulated in GRE
   packets which in turn are carried over IP.  The encapsulated PPP
   packets are essentially PPP data packets less any media specific
   framing elements.  No HDLC flags, bit insertion, control characters,
   or control character escapes are included. No CRCs are sent through
   the tunnel. The IP packets transmitted over the tunnels between a PAC
   and PNS has the following general structure:

      +--------------------------------+
      |          Media Header          |
      +--------------------------------+
      |           IP Header            |
      +--------------------------------+
      |           GRE Header           |
      +--------------------------------+
      |           PPP Packet           |
      +--------------------------------+

4.1.  Enhanced GRE header

   The GRE header used in PPTP is enhanced slightly from that specified
   in the current GRE protocol specification [1,2].  The main difference
   involves the definition of a new Acknowledgment Number field, used to
   determine if a particular GRE packet or set of packets has arrived at
   the remote end of the tunnel.  This Acknowledgment capability is not
   used in conjunction with any retransmission of user data packets.  It
   is used instead to determine the rate at which user data packets are
   to be transmitted over the tunnel for a given user session.  The
   format of the enhanced GRE header is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Key (HW) Payload Length    |       Key (LW) Call ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Sequence Number (Optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Acknowledgment Number (Optional)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Hamzeh, et al.               Informational                     [Page 47]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   C
      (Bit 0) Checksum Present.  Set to zero (0).

   R
      (Bit 1) Routing Present.  Set to zero (0).

   K
      (Bit 2) Key Present.  Set to one (1).
   S
      (Bit 3) Sequence Number Present.  Set to one (1) if a payload
      (data) packet is present.  Set to zero (0) if payload is not
      present (GRE packet is an Acknowledgment only).

   s
      (Bit 4) Strict source route present.  Set to zero (0).

   Recur
      (Bits 5-7) Recursion control.  Set to zero (0).

   A
      (Bit 8) Acknowledgment sequence number present.  Set to one (1) if
      packet contains Acknowledgment Number to be used for acknowledging
      previously transmitted data.

   Flags
      (Bits 9-12) Must be set to zero (0).

   Ver
      (Bits 13-15) Must contain 1 (enhanced GRE).

   Protocol Type
      Set to hex 880B [8].

   Key
      Use of the Key field is up to the implementation.  PPTP uses it as
      follows:
         Payload Length
            (High 2 octets of Key) Size of the payload, not including
            the GRE header

         Call ID
            (Low 2 octets) Contains the Peer's Call ID for the session
            to which this packet belongs.

         Sequence Number
            Contains the sequence number of the payload.  Present if S
            bit (Bit 3) is one (1).




Hamzeh, et al.               Informational                     [Page 48]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


         Acknowledgment Number
            Contains the sequence number of the highest numbered GRE
            packet received by the sending peer for this user session.
            Present if A bit (Bit 8) is one (1).

         The payload section contains a PPP data packet without any
         media specific framing elements.

         The sequence numbers involved are per packet sequence numbers.
         The sequence number for each user session is set to zero at
         session startup.  Each packet sent for a given user session
         which contains a payload (and has the S bit (Bit 3) set to one)
         is assigned the next consecutive sequence number for that
         session.

         This protocol allows acknowledgments to be carried with the
         data and makes the overall protocol more efficient, which in
         turn requires less buffering of packets.

4.2.  Sliding Window Protocol

   The sliding window protocol used on the PPTP data path is used for
   flow control by each side of the data exchange.  The enhanced GRE
   protocol allows packet acknowledgments to be piggybacked on data
   packets.  Acknowledgments can also be sent separately from data
   packets.  Again, the main purpose of the sliding window protocol is
   for flow control--retransmissions are not performed by the tunnel
   peers.

4.2.1.  Initial Window Size

   Although each side has indicated the maximum size of its receive
   window, it is recommended that a conservative approach be taken when
   beginning to transmit data.  The initial window size on the
   transmitter is set to half the maximum size the receiver requested,
   with a minimum size of one packet.  The transmitter stops sending
   packets when the number of packets awaiting acknowledgment is equal
   to the current window size.  As the receiver successfully digests
   each window, the window size on the transmitter is bumped up by one
   packet until the maximum is reached.  This method prevents a system
   from flooding an already congested network because no history has
   been established.

4.2.2.  Closing the Window

   When a time-out does occur on a packet, the sender adjusts the size
   of the transmit window down to one half its value when it failed.
   Fractions are rounded up, and the minimum window size is one.



Hamzeh, et al.               Informational                     [Page 49]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


4.2.3.  Opening the Window

   With every successful transmission of a window's worth of packets
   without a time-out, the transmit window size is increased by one
   packet until it reaches the maximum window size that was sent by the
   other side when the call was connected.  As stated earlier, no
   retransmission is done on a time-out. After a time-out, the
   transmission resumes with the window starting at one half the size of
   the transmit window when the time-out occurred and adjusting upward
   by one each time the transmit window is filled with packets that are
   all acknowledged without time-outs.

4.2.4.  Window Overflow

   When a receiver's window overflows with too many incoming packets,
   excess packets are thrown away.  This situation should not arise if
   the sliding window procedures are being properly followed by the
   transmitter and receiver. It is assumed that, on the transmit side,
   packets are buffered for transmission and are no longer accepted from
   the packet source when the transmit buffer fills.

4.2.5.  Multi-packet Acknowledgment

   One feature of the PPTP sliding window protocol is that it allows the
   acknowledgment of multiple packets with a single acknowledgment. All
   outstanding packets with a sequence number lower or equal to the
   acknowledgment number are considered acknowledged. Time-out
   calculations are performed using the time the packet corresponding to
   the highest sequence number being acknowledged was transmitted.

   Adaptive time-out calculations are only performed when an
   Acknowledgment is received.  When multi-packet acknowledgments are
   used, the overhead of the adaptive time-out algorithm is reduced. The
   PAC is not required to transmit multi-packet acknowledgments; it can
   instead acknowledge each packet individually as it is delivered to
   the PPP client.

4.3.  Out-of-sequence Packets

   Occasionally packets lose their sequencing across a complicated
   internetwork.  Say, for example that a PNS sends packets 0 to 5 to a
   PAC.  Because of rerouting in the internetwork, packet 4 arrives at
   the PAC before packet 3. The PAC acknowledges packet 4, and may
   assume packet 3 is lost. This acknowledgment grants window credit
   beyond packet 4.






Hamzeh, et al.               Informational                     [Page 50]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   When the PAC does receive packet 3, it MUST not attempt to transmit
   it to the corresponding PPP client.  To do so could cause problems,
   as proper PPP protocol operation is premised upon receiving packets
   in sequence.  PPP does properly deal with the loss of packets, but
   not with reordering so out of sequence packets between the PNS and
   PAC MUST be silently discarded, or they may be reordered by the
   receiver.  When packet 5 comes in, it is acknowledged by the PAC
   since it has a higher sequence number than 4, which was the last
   highest packet acknowledged by the PAC.  Packets with duplicate
   sequence numbers should never occur since the PAC and PNS never
   retransmit GRE packets.  A robust implementation will silently
   discard duplicate GRE packets, should it receive any.

4.4.  Acknowledgment Time-Outs

   PPTP uses sliding windows and time-outs to provide both user session
   flow-control across the internetwork and to perform efficient data
   buffering to keep the PAC-PNS data channels full without causing
   receive buffer overflow.  PPTP requires that a time-out be used to
   recover from dropped data or acknowledgment packets.  The exact
   implementation of the time-out is vendor-specific.  It is suggested
   that an adaptive time-out be implemented with backoff for congestion
   control.  The time-out mechanism proposed here has the following
   properties:

      Independent time-outs for each session. A device (PAC or PNS) will
      have to maintain and calculate time-outs for every active session.

      An administrator-adjustable maximum time-out, MaxTimeOut, unique
      to each device.

      An adaptive time-out mechanism that compensates for changing
      throughput.  To reduce packet processing overhead, vendors may
      choose not to recompute the adaptive time-out for every received
      acknowledgment.  The result of this overhead reduction is that the
      time-out will not respond as quickly to rapid network changes.

      Timer backoff on time-out to reduce congestion. The backed-off
      timer value is limited by the configurable maximum time-out value.
      Timer backoff is done every time an acknowledgment time-out
      occurs.

   In general, this mechanism has the desirable behavior of quickly
   backing off upon a time-out and of slowly decreasing the time-out
   value as packets are delivered without time-outs.






Hamzeh, et al.               Informational                     [Page 51]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Some definitions:

      Packet Processing Delay (PPD) is the amount of time required for
      each side to process the maximum amount of data buffered in their
      receive packet sliding window. The PPD is the value exchanged
      between the PAC and PNS when a call is established. For the PNS,
      this number should be small.  For a PAC making modem connections,
      this number could be significant.

      Sample is the actual amount of time incurred receiving an
      acknowledgment for a packet. The Sample is measured, not
      calculated.

      Round-Trip Time (RTT) is the estimated round-trip time for an
      Acknowledgment to be received for a given transmitted packet. When
      the network link is a local network, this delay will be minimal
      (if not zero). When the network link is the Internet, this delay
      could be substantial and vary widely. RTT is adaptive: it will
      adjust to include the PPD and whatever shifting network delays
      contribute to the time between a packet being transmitted and
      receiving its acknowledgment.

      Adaptive Time-Out (ATO) is the time that must elapse before an
      acknowledgment is considered lost.  After a time-out, the sliding
      window is partially closed and the ATO is backed off.

   The Packet Processing Delay (PPD) parameter is a 16-bit word
   exchanged during the Call Control phase that represents tenths of a
   second (64 means 6.4 seconds). The protocol only specifies that the
   parameter is exchanged, it does not specify how it is calculated. The
   way values for PPD are calculated is implementation-dependent and
   need not be variable (static time-outs are allowed). The PPD must be
   exchanged in the call connect sequences, even if it remains constant
   in an implementation. One possible way to calculate the PPD is:

   PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
   PPD = PPD' + PACFudge

   Header is the total size of the IP and GRE headers, which is 36. The
   MTU is the overall MTU for the internetwork link between the PAC and
   PNS.  WindowSize represents the number of packets in the sliding
   window, and is implementation-dependent. The latency of the
   internetwork could be used to pick a window size sufficient to keep
   the current session's pipe full. The constant 8 converts octets to
   bits (assuming ConnectRate is in bits per second).  If ConnectRate is
   in bytes per second, omit the 8.  PACFudge is not required but can be
   used to take overall processing overhead of the PAC into account.




Hamzeh, et al.               Informational                     [Page 52]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   The value of PPD is used to seed the adaptive algorithm with the
   initial RTT[n-1] value.

4.4.1.  Calculating Adaptive Acknowledgment Time-Out

   We still must decide how much time to allow for acknowledgments to
   return. If the time-out is set too high, we may wait an unnecessarily
   long time for dropped packets. If the time-out is too short, we may
   time out just before the acknowledgment arrives. The acknowledgment
   time-out should also be reasonable and responsive to changing network
   conditions.

   The suggested adaptive algorithm detailed below is based on the TCP
   1989 implementation and is explained in [11].  'n' means this
   iteration of the calculation, and 'n-1' refers to values from the
   last calculation.

      DIFF[n] = SAMPLE[n] - RTT[n-1]
      DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
      RTT[n] = RTT[n-1] + (alpha * DIFF[n])
      ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
               (chi * DEV[n]), MaxTimeOut))

      DIFF represents the error between the last estimated round-trip
      time and the measured time. DIFF is calculated on each iteration.

      DEV is the estimated mean deviation. This approximates the
      standard deviation.  DEV is calculated on each iteration and
      stored for use in the next iteration. Initially, it is set to 0.

      RTT is the estimated round-trip time of an average packet. RTT is
      ycalculated on each iteration and stored for use in the next
      iteration.  Initially, it is set to PPD.

      ATO is the adaptive time-out for the next transmitted packet. ATO
      is calculated on each iteration.  Its value is limited, by the MIN
      function, to be a maximum of the configured MaxTimeOut value.

      Alpha is the gain for the average and is typically 1/8 (0.125).

      Beta is the gain for the deviation and is typically 1/4 (0.250).

      Chi is the gain for the time-out and is typically set to 4.








Hamzeh, et al.               Informational                     [Page 53]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   To eliminate division operations for fractional gain elements, the
   entire set of equations can be scaled. With the suggested gain
   constants, they should be scaled by 8 to eliminate all division.  To
   simplify calculations, all gain values are kept to powers of two so
   that shift operations can be used in place of multiplication or
   division.

4.4.2.  Congestion Control: Adjusting for Time-Out

   This section describes how the calculation of ATO is modified in the
   case where a time-out does occur.  When a time-out occurs, the time-
   out value should be adjusted rapidly upward.  Although the GRE
   packets are not retransmitted when a time-out occurs, the time-out
   should be adjusted up toward a maximum limit.  To compensate for
   shifting internetwork time delays, a strategy must be employed to
   increase the time-out when it expires (notice that in addition to
   increasing the time-out, we are also shrinking the size of the window
   as described in the next section).  For an interval in which a time-
   out occurs, the new
   ATO is calculated as:

      RTT[n] = delta * RTT[n-1]
      DEV[n] = DEV[n-1]
      ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
               (chi * DEV[n]), MaxTimeOut))

   In this calculation of ATO, only the two values that both contribute
   to ATO and are stored for the next iteration are calculated.  RTT is
   scaled by delta, and DEV is unmodified.  DIFF is not carried forward
   and is not used in this scenario.  A value of 2 for Delta, the time-
   out gain factor for RTT, is suggested.

5.  Security Considerations

   The security of user data passed over the tunneled PPP connection is
   addressed by PPP, as is authentication of the PPP peers.

   Because the PPTP control channel messages are neither authenticated
   nor integrity protected, it might be possible for an attacker to
   hijack the underlying TCP connection.  It is also possible to
   manufacture false control channel messages and alter genuine messages
   in transit without detection.

   The GRE packets forming the tunnel itself are not cryptographically
   protected.  Because the PPP negotiations are carried out over the
   tunnel, it may be possible for an attacker to eavesdrop on and modify
   those negotiations.




Hamzeh, et al.               Informational                     [Page 54]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   Unless the PPP payload data is cryptographically protected, it can be
   captured and read or modified.

6.  Authors' Addresses

   Kory Hamzeh
   Ascend Communications
   1275 Harbor Bay Parkway
   Alameda, CA 94502

   EMail: kory@ascend.com


   Gurdeep Singh Pall
   Microsoft Corporation
   Redmond, WA

   EMail: gurdeep@microsoft.com


   William Verthein
   U.S. Robotics/3Com


   Jeff Taarud
   Copper Mountain Networks


   W. Andrew Little
   ECI Telematics


   Glen Zorn
   Microsoft Corporation
   Redmond, WA

   EMail: glennz@microsoft.com














Hamzeh, et al.               Informational                     [Page 55]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


7.  References

   [1]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
        Encapsulation (GRE)", RFC 1701, October 1994.

   [2]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
        Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.

   [3]  Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC
        1334, October 1992.

   [4]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [5]  Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.

   [6]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.  See also: http://www.iana.org/numbers.html

   [7]  Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, July 1994.

   [8]  Ethertype for PPP, Reserved with Xerox Corporation.

   [9]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
        (CHAP)", RFC 1994, August 1996.

   [10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-
        Wesley, 1994.

   [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.
















Hamzeh, et al.               Informational                     [Page 56]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


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



















Hamzeh, et al.               Informational                     [Page 57]