File: rfc2341.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1627 lines) | stat: -rw-r--r-- 66,592 bytes parent folder | download | duplicates (5)
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






Network Working Group                                         A. Valencia
Request for Comments: 2341                                  M. Littlewood
Category: Historic                                               T. Kolar
                                                            Cisco Systems
                                                                 May 1998


              Cisco Layer Two Forwarding (Protocol) "L2F"

Status of Memo

   This memo describes a historic protocol 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 (1998).  All Rights Reserved.

Abstract

   Virtual dial-up allows many separate and autonomous protocol domains
   to share common access infrastructure including modems, Access
   Servers, and ISDN routers.  Previous RFCs have specified protocols
   for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via
   PPP [2].  This document describes the Layer Two Forwarding protocol
   (L2F) which permits the tunneling of the link layer (i.e., HDLC,
   async HDLC, or SLIP frames) of higher level protocols.  Using such
   tunnels, it is possible to divorce the location of the initial dial-
   up server from the location at which the dial-up protocol connection
   is terminated and access to the network provided.

Table of Contents

   1.0 Introduction                                                3
   1.1 Conventions                                                 3
   2.0 Problem Space Overview                                      3
   2.1 Initial Assumptions                                         3
   2.2 Topology                                                    4
   2.3 Virtual dial-up Service - a walk-though                     5
   3.0 Service Model Issues                                        7
   3.1 Security                                                    7
   3.2 Address allocation                                          8
   3.3 Authentication                                              8
   3.4 Accounting                                                  8
   4.0 Protocol Definition                                         9
   4.1 Encapsulation within L2F                                   10
   4.1.1 Encapsulation of PPP within L2F                          10



Valencia, et. al.               Historic                        [Page 1]

RFC 2341                       Cisco L2F                        May 1998


   4.1.2 Encapsulation of SLIP within L2F                         10
   4.2 L2F Packet Format                                          10
   4.2.1 Overall Packet Format                                    10
   4.2.2 Packet Header                                            11
   4.2.3 Version field                                            11
   4.2.4 Protocol field                                           11
   4.2.5 Sequence Number                                          12
   4.2.6 Packet Multiplex ID                                      12
   4.2.7 Client ID                                                13
   4.2.8 Length                                                   13
   4.2.9 Packet Checksum                                          13
   4.2.10 Payload Offset                                          14
   4.2.11 Packet Key                                              14
   4.2.12 Packet priority                                         14
   4.3 L2F Tunnel Establishment                                   14
   4.3.1 Normal Tunnel Negotiation Sequence                       15
   4.3.2 Normal Client Negotiation Sequence                       17
   4.4 L2F management message types                               18
   4.4.1 L2F message type: Invalid                                18
   4.4.2 L2F_CONF                                                 19
   4.4.3 L2F_OPEN, tunnel establishment                           20
   4.4.4 L2F_OPEN, client establishment                           20
   4.4.5 L2F_CLOSE                                                22
   4.4.6 L2F_ECHO                                                 22
   4.4.7 L2F_ECHO_RESP                                            23
   4.5 L2F Message Delivery                                       23
   4.5.1 Sequenced Delivery                                       23
   4.5.2 Flow Control                                             23
   4.5.3 Tunnel State Table                                       24
   4.5.4 Client State Table                                       25
   5.0 Protocol Considerations                                    26
   5.1 PPP Features                                               26
   5.2 Termination                                                26
   5.3 Extended Authentication                                    26
   5.4 MNP4 and Apple Remote Access Protocol                      27
   5.5 Operation over IP/UDP                                      27
   6.0 Acknowledgments                                            27
   7.0 References                                                 27
   8.0 Security Considerations                                    28
   9.0 Authors' Addresses                                         28
   10.0 Full Copyright Statement                                  29










Valencia, et. al.               Historic                        [Page 2]

RFC 2341                       Cisco L2F                        May 1998


1.0 Introduction

   The traditional dial-up network service on the Internet is for
   registered IP addresses only.  A new class of virtual dial-up
   application which allows multiple protocols and unregistered IP
   addresses is also desired on the Internet. Examples of this class of
   network application are support for privately addressed IP, IPX, and
   AppleTalk dial-up via SLIP/PPP across existing Internet
   infrastructure.

   The support of these multiprotocol virtual dial-up applications is of
   significant benefit to end users and Internet Service providers as it
   allows the sharing of very large investments in access and core
   infrastructure and allows local calls to be used.  It also allows
   existing investments in non-IP protocol applications to be supported
   in a secure manner while still leveraging the access infrastructure
   of the Internet.

   It is the purpose of this RFC to identify the issues encountered in
   integrating multiprotocol dial-up services into an existing Internet
   Service Provider's Point of Presence (hereafter referred to as ISP
   and POP, respectively), and to describe the L2F protocol which
   permits the leveraging of existing access protocols.

1.1. Conventions

   The following language conventions are used in the items of
   specification in this document:

      o   MUST, SHALL, or MANDATORY -- This item is an absolute
          requirement of the specification.

      o   SHOULD or RECOMMEND -- This item should generally be followed
          for all but exceptional circumstances.

      o   MAY or OPTIONAL -- This item is truly optional and may be
          followed or ignored according to the needs of the implementor.

2.0 Problem Space Overview

   In this section we describe in high level terms the scope of the
   problem that will be explored in more detail in later sections.

2.1 Initial Assumptions

   We begin by assuming that Internet access is provided by an ISP and
   that the ISP wishes to offer services other than traditional
   registered IP address based services to dial-up users of the network.



Valencia, et. al.               Historic                        [Page 3]

RFC 2341                       Cisco L2F                        May 1998


   We also assume that the user of such a service wants all of the
   security facilities that are available to him in a dedicated dial-up
   configuration.  In particular, the end user requires:

   +  End System transparency: Neither the remote end system nor his
      home site hosts should require any special software to use this
      service in a secure manner.

   +  Authentication as provided via dial-up PPP CHAP or PAP, or through
      other dialogs as needed for protocols without authentication
      (e.g., SLIP).  This will include TACACS+ and RADIUS solutions as
      well as support for smart cards and one-time passwords.  The
      authentication should be manageable by the user independently of
      the ISP.

   +  Addressing should be as manageable as dedicated dial-up solutions.
      The address should be assigned by the home site and not the ISP.

   +  Authorization should be managed by the home site as it would in a
      direct dial-up solution.

   +  Accounting should be performed both by the ISP (for billing
      purposes) and by the user (for charge-back and auditing).

2.2 Topology

   Shown below is a generic Internet with Public switched Telephone
   Network (PSTN) access (i.e., async PPP via modems) and Integrated
   Services Digital Network (ISDN) access (i.e., synchronous PPP
   access).  Remote users (either async PPP or SLIP, or ISDN) will
   access the Home LAN as if they were dialed into the Home Gateway,
   although their physical dial-up is via the ISP Network Access Server.



















Valencia, et. al.               Historic                        [Page 4]

RFC 2341                       Cisco L2F                        May 1998


           ...----[L]----+---[L]-----...
                         |
                         |
                        [H]
                         |
                 ________|________________________
                 |                                |
         ________|__                        ______|________
         |         |                        |             |
         |  PSTN  [R]                      [R]  ISDN      |
         |  Cloud  |                        |   Cloud    [N]__[U]
         |         |             Internet   |             |
         |         |                       [R]            |
         [N]______[R]                       |_____________|
          |      |                                |
          |      |                                |
         [U]     |________________________________|


      [H] = Home Gateway
      [L] = Home LAN(s)
      [R] = Router
      [U] = Remote User
      [N] = ISP Network Access Server ("NAS")

2.3 Providing Virtual dial-up Services - a walk-through

   To motivate the following discussion, this section walks through an
   example of what might happen when a Virtual dial-up client initiates
   access.

   The Remote User initiates a PPP connection to an ISP via either the
   PSTN or ISDN.  The Network Access Server (NAS) accepts the connection
   and the PPP link is established.

   The ISP undertakes a partial authentication of the end system/user
   via CHAP or PAP.  Only the username field is interpreted to determine
   whether the user requires a Virtual dial-up service.  It is
   expected-- but not required--that usernames will be structured (e.g.
   littlewo@cisco.com).  Alternatively, the ISP may maintain a database
   mapping users to services.  In the case of Virtual dial-up, the
   mapping will name a specific endpoint, the Home Gateway.

   If a virtual dial-up service is not required, standard access to the
   Internet may be provided.






Valencia, et. al.               Historic                        [Page 5]

RFC 2341                       Cisco L2F                        May 1998


   If no tunnel connection currently exists to the desired Home Gateway,
   one is initiated.  L2F is designed to be largely insulated from the
   details of the media over which the tunnel is established; L2F
   requires only that the tunnel media provide packet oriented point-
   to-point connectivity.  Obvious examples of such media are UDP, Frame
   Relay PVC's, or X.25 VC's.  Details for L2F operation over UDP are
   provided in section 5.5.  The specification for L2F packet formats is
   provided in section 4.2, and the message types and semantics starting
   in section 4.4.

   Once the tunnel exists, an unused Multiplex ID (hereafter, "MID") is
   allocated, and a connect indication is sent to notify the Home
   Gateway of this new dial-up session.  The Home Gateway either accepts
   the connection, or rejects.  Rejection may include a reason
   indication, which may be displayed to the dial-up user, after which
   the call should be disconnected.

   The initial setup notification may include the authentication
   information required to allow the Home Gateway to authenticate the
   user and decide to accept or decline the connection.  In the case of
   CHAP, the set-up packet includes the challenge, username and raw
   response.  For PAP or text dialog (i.e., for SLIP users), it includes
   username and clear text password.  The Home Gateway may choose to use
   this information to complete its authentication, avoiding an
   additional cycle of authentication.

   For PPP, the initial setup notification may also include a copy of
   the the LCP CONFACKs sent in each direction which completed LCP
   negotiation.  The Home Gateway may use this information to initialize
   its own PPP state (thus avoiding an additional LCP negotiation), or
   it may choose to initiate a new LCP CONFREQ exchange.

   If the Home Gateway accepts the connection, it creates a "virtual
   interface" for SLIP or PPP in a manner analogous to what it would use
   for a direct-dialed connection.  With this "virtual interface" in
   place, link layer frames may now pass over this tunnel in both
   directions.  Frames from the remote user are received at the POP,
   stripped of any link framing or transparency bytes, encapsulated in
   L2F, and forwarded over the appropriate tunnel.

   The Home Gateway accepts these frames, strips L2F, and processes them
   as normal incoming frames for the appropriate interface and protocol.
   The "virtual interface" behaves very much like a hardware interface,
   with the exception that the hardware in this case is physically
   located at the ISP POP.  The other direction behaves analogously,
   with the Home Gateway encapsulating the packet in L2F, and the POP
   stripping L2F before transmitting it out the physical interface to
   the remote user.



Valencia, et. al.               Historic                        [Page 6]

RFC 2341                       Cisco L2F                        May 1998


   At this point, the connectivity is a point-to-point PPP or SLIP
   connection whose endpoints are the remote user's networking
   application on one end and the termination of this connectivity into
   the Home Gateway's SLIP or PPP support on the other.  Because the
   remote user has become simply another dial-up client of the Home
   Gateway access server, client connectivity can now be managed using
   traditional mechanisms with respect to further authorization,
   protocol access, and filtering.

   Accounting can be performed at both the NAS as well as the Home
   Gateway.  This document illustrates some Accounting techniques which
   are possible using L2F, but the policies surrounding such Accounting
   are outside the scope of this specification.

   Because L2F connect notifications for PPP clients contain sufficient
   information for a Home Gateway to authenticate and initialize its LCP
   state machine, it is not required that the remote user be queried a
   second time for CHAP authentication, nor that the client undergo
   multiple rounds of LCP negotiation and convergence.  These techniques
   are intended to optimize connection setup, and are not intended to
   deprecate any functions required by the PPP specification.

3.0 Service Model Issues

   There are several significant differences between the standard
   Internet access service and the Virtual dial-up service with respect
   to authentication, address allocation, authorization and accounting.
   The details of the differences between these services and the
   problems presented by these differences are described below.  The
   mechanisms used for Virtual Dial-up service are intended to coexist
   with more traditional mechanisms; it is intended that an ISP's POP
   can simultaneously service ISP clients as well as Virtual dial-up
   clients.

3.1 Security

   For the Virtual dial-up service, the ISP pursues authentication only
   to the extent required to discover the user's apparent identity (and
   by implication, their desired Home Gateway).  As soon as this is
   determined, a connection to the Home Gateway is initiated with the
   authentication information gathered by the ISP.  The Home Gateway
   completes the authentication by either accepting the connection, or
   rejecting it.

   The Home Gateway must also protect against attempts by third parties
   to establish tunnels to the Home Gateway.  Tunnel establishment
   involves an ISP-to-Home Gateway authentication phase to protect
   against such attacks.



Valencia, et. al.               Historic                        [Page 7]

RFC 2341                       Cisco L2F                        May 1998


3.2 Address Allocation

   For an Internet service, the user accepts that the IP address may be
   allocated dynamically from a pool of Service provider addresses.
   This model often means that the remote user has little or no access
   to their home network's resources, due to firewalls and other
   security policies applied by the home network to accesses from
   external IP addresses.

   For the Virtual dial-up service, the Home Gateway can exist behind
   the home firewall, allocating addresses which are internal (and, in
   fact, can be RFC1597 addresses, or non-IP addresses).  Because L2F
   tunnels exclusively at the frame layer, the actual policies of such
   address management are irrelevant to correct Virtual dial-up service;
   for all purposes of PPP or SLIP protocol handling, the dial-in user
   appears to have connected at the Home Gateway.

3.3 Authentication

   The authentication of the user occurs in three phases; the first at
   the ISP, and the second and optional third at the Home gateway.

   The ISP uses the username to determine that a Virtual dial-up service
   is required and initiate the tunnel connection to the appropriate
   Home Gateway.  Once a tunnel is established, a new MID is allocated
   and a session initiated by forwarding the gathered authentication
   information.

   The Home Gateway undertakes the second phase by deciding whether or
   not to accept the connection.  The connection indication may include
   CHAP, PAP, or textual authentication information.  Based on this
   information, the Home Gateway may accept the connection, or may
   reject it (for instance, it was a PAP request and the
   username/password are found to be incorrect).

   Once the connection is accepted, the Home Gateway is free to pursue a
   third phase of authentication at the PPP or SLIP layer.  These
   activities are outside the scope of this specification, but might
   include an additional cycle of LCP authentication, proprietary PPP
   extensions, or textual challenges carried via a TCP/IP telnet
   session.

3.4 Accounting

   It is a requirement that both the Access gateway and the Home Gateway
   can provide accounting data and hence both may count packets, octets
   and connection start and stop times.




Valencia, et. al.               Historic                        [Page 8]

RFC 2341                       Cisco L2F                        May 1998


   Since Virtual dial-up is an access service, accounting of connection
   attempts (in particular, failed connection attempts) is of
   significant interest.  The Home Gateway can reject new connections
   based on the authentication information gathered by the ISP, with
   corresponding logging.  For cases where the Home Gateway accepts the
   connection and then continues with further authentication, the Home
   Gateway might subsequently disconnect the client.  For such
   scenarios, the disconnection indication back to the ISP may also
   include a reason.

   Because the Home Gateway can decline a connection based on the
   authentication information collected by the ISP, accounting can
   easily draw a distinction between a series of failed connection
   attempts and a series of brief successful connections.  Lacking this
   facility, the Home Gateway must always accept connection requests,
   and would need to exchange a number of PPP packets with the remote
   system.

4.0 Protocol Definition

   The protocol definition for Virtual dial-up services requires two
   areas of standardization:

   +  Encapsulation of PPP packets within L2F.  The ISP NAS and the
      Home gateway require a common understanding of the encapsulation
      protocol so that SLIP/PPP packets can be successfully transmitted
      and received across the Internet.

   +  Connection management of L2F and MIDs.  The tunnel must be
      initiated and terminated, as must MIDs within the tunnel.
      Termination includes diagnostic codes to assist in the diagnosis
      of problems and to support accounting.

   While providing these services, the protocol must address the
   following required attributes:

   +  Low overhead.  The protocol must impose a minimal additional
      overhead.  This requires a compact encapsulation, and a structure
      for omitting some portions of the encapsulation where their
      function is not required.

   +  Efficiency.  The protocol must be efficient to encapsulate and
      deencapsulate.

   +  Protocol independence.  The protocol must make very few
      assumptions about the substrate over which L2F packets are
      carried.




Valencia, et. al.               Historic                        [Page 9]

RFC 2341                       Cisco L2F                        May 1998


   +  Simple deployment.  The protocol must not rely on additional
      telecommunication support (for instance, unique called numbers,
      or caller ID) to operate.

4.1 Encapsulation within L2F

4.1.1 Encapsulation of PPP within L2F

   The PPP packets may be encapsulated within L2F.  The packet
   encapsulated is the packet as it would be transmitted over a physical
   link.  The following are NOT present in the packet:

   + Flags
   + Transparency data (ACCM for async, bit stuffing for sync)
   + CRC

   The following ARE still present:

   + Address and control flags (unless negotiated away by LCP)
   + Protocol value

4.1.2 Encapsulation of SLIP within L2F

   SLIP is encapsulated within L2F in much the same way as PPP.  The
   transparency characters are removed before encapsulating within L2F,
   as is the framing.

4.2 L2F Packet Format

4.2.1 Overall Packet Format

   The entire encapsulated packet has the form:


                 ---------------------------------
                 |                               |
                 |         L2F Header            |
                 |                               |
                 ---------------------------------
                 |                               |
                 |  Payload packet (SLIP/PPP)    |
                 |                               |
                 ---------------------------------
                 |                               |
                 |    L2F Checksum (optional)    |
                 |                               |
                 ---------------------------------




Valencia, et. al.               Historic                       [Page 10]

RFC 2341                       Cisco L2F                        May 1998


4.2.2 Packet Format

   An L2F packet has the form:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|K|P|S|0|0|0|0|0|0|0|0|C| Ver |    Protocol   |Sequence (opt)|\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|          Multiplex ID         |           Client ID           | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F
|             Length            |       Offset (opt)            | |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                         Key (opt)                             | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+                                 (payload)                     |
+                             .....                             |
+                             .....                             |
+                             .....                             |
+                                 (payload)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   L2F Checksum (optional)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.3 Version field

   The Ver ("Version") field represents the major version of the L2F
   software creating the packet.  It MUST contain the value 001.

   If Ver holds a value other than 1, or any bits are non-zero after bit
   S but before bit C, this corresponds to a packet containing
   extensions not understood by the receiving end.  The packet is
   handled as an invalid packet as defined in 4.4.1.

4.2.4 Protocol field

   The Protocol specifies the protocol carried within the L2F packet.
   Legal values (represented here in hexadecimal) are:

      Value           Type                   Description
      0x00            L2F_ILLEGAL            Illegal
      0x01            L2F_PROTO              L2F management packets
      0x02            L2F_PPP                PPP tunneled inside L2F
      0x03            L2F_SLIP               SLIP tunneled inside L2F

   If a packet is received with a Protocol of L2F_ILLEGAL or any other
   unrecognized value, it MUST be treated as an illegal packet as
   defined in 4.4.1.



Valencia, et. al.               Historic                       [Page 11]

RFC 2341                       Cisco L2F                        May 1998


4.2.5 Sequence Number

   The Sequence number is present if the S bit in the L2F header is set
   to 1.  This bit MUST be 1 for all L2F management packets.  It MAY be
   set to 1 for non-L2F management packets.  If a non-L2F management
   packet is received with the S bit set, all future L2F packets sent
   for that MID MUST have the S bit set (and, by implication, be sent
   using sequence numbers).  For instance, the Home Gateway might choose
   to force sequenced packet delivery if it detects an NCP opening for a
   protocol which can not operate with out-of-sequence packets.

   The Sequence number starts at 0 for the first sequenced L2F packet.
   Each subsequent packet is sent with the next increment of the
   sequence number.  The sequence number is thus a free running counter
   represented modulo 256.  There is distinct Sequence number state
   (i.e., counter) for each distinct MID value.

   For packets with S bit and sequence number, the sequence number is
   used to protect against duplication of packets, as follows:

   The receiving side of the tunnel records the sequence number of each
   valid L2F packet it receives.  If a received packet appears to have a
   value less than or equal to the last received value, the packet MUST
   be silently discarded.  Otherwise, the packet is accepted and the
   sequence number in the packet recorded as the latest value last
   received.

   For purposes of detecting duplication, a received sequence value is
   considered less than or equal to the last received value if its value
   lies in the range of the last value and its 127 successor values.
   For example, if the last received sequence number was 15, then
   packets with sequence numbers 0 through 15, as well as 144 through
   255, would be considered less than or equal to, and would be silently
   discarded.  Otherwise it would be accepted.

4.2.6 Packet Multiplex ID

   The Multiplex ID ("MID") identifies a particular connection within
   the tunnel.  Each new connection is assigned a MID currently unused
   within the tunnel.  It is recommended that the MID cycle through the
   entire 16-bit namespace, to reduce aliasing between previous and
   current sessions.  A MID value which has been previously used within
   a tunnel, has been closed, and will now be used again, must be
   considered as an entirely new MID, and initialised as such.

   The MID with value 0 is special; it is used to communicate the state
   of the tunnel itself, as distinct from any connection within the
   tunnel.  Only L2F_PROTO packets may be sent using an MID of 0; if any



Valencia, et. al.               Historic                       [Page 12]

RFC 2341                       Cisco L2F                        May 1998


   other type is sent on MID 0, the packet is illegal and MUST be
   processed as defined in 4.4.1.

4.2.7 Client ID

   The Client ID ("CLID") is used to assist endpoints in demultiplexing
   tunnels when the underlying point-to-point substrate lacks an
   efficient or dependable technique for doing so directly.  Using the
   CLID, it is possible to demultiplex multiple tunnels whose packets
   arrive over the point-to-point media interleaved, without requiring
   media-specific semantics.

   When transmitting the L2F_CONF message (described below), the peer's
   CLID must be communicated via the Assigned_CLID field.  This MUST be
   a unique non-zero value on the sender's side, which is to be expected
   in the Home Gateway's L2F_CONF response, as well as all future non-
   L2F_CONF packets received.

   The CLID value from the last valid L2F_CONF message received MUST be
   recorded and used as the CLID field value for all subsequent packets
   sent to the peer.

   Packets with an unknown Client ID MUST be silently discarded.

   For the initial packet sent during tunnel establishment, where no
   L2F_CONF has yet been received, the CLID field MUST be set to 0.

   Thus, during L2F_CONF each side is told its CLID value.  All later
   packets sent, tagged with this CLID value, serve as a tag which
   uniquely identifies this peer.

4.2.8 Length

   Length is the size in octets of the entire packet, including header,
   all fields present, and payload.  Length does not reflect the
   addition of the checksum, if one is present.  The packet should be
   silently discarded if the received packet is shorter than the
   indicated length.  Additional bytes present in the packet beyond the
   indicated length MUST be silently ignored.

4.2.9 Packet Checksum

   The Checksum is present if the C bit is present in the header flags.
   It is a 16-bit CRC as used by PPP/HDLC (specifically, FCS-16 [3]).
   Is is applied over the entire packet starting with the first byte of
   L2F flags, through the last byte of payload data.  The checksum is
   then added as two bytes immediately following the last byte of
   payload data.



Valencia, et. al.               Historic                       [Page 13]

RFC 2341                       Cisco L2F                        May 1998


4.2.10 Payload Offset

   The Offset is present if the F bit is set in the header flags.  This
   field specifies the number of bytes past the L2F header at which the
   payload data is expected to start.  If it is 0, or the F bit is not
   set, the first byte following the last byte of L2F header is the
   first byte of payload data.

   It is recommended that data skipped due to the payload offset be
   initialized to 0's.

   For architectures where it is more efficient to have the payload
   start at an aligned 32-bit boundary with respect to the L2F header,
   it is recommended that the F bit be set, and an offset of 0 be used.

4.2.11 Packet Key

   The Key field is present if the K bit is set in the L2F header.  The
   Key is based on the authentication response last given to the peer
   during tunnel creation (the details of tunnel creation are provided
   in the next section).  It serves as a key during the life of a
   session to resist attacks based on spoofing.  If a packet is received
   in which the Key does not match the expected value, the packet MUST
   be silently discarded.  Such handling takes precedence over 4.4.1.

   The Key value is generated by taking the 128-bit authentication
   response from the peer, interpreting it as four adjacent 32-bit words
   in network byte order, XOR'ing these words together, and using the
   resulting 32-bit value as the Key.

4.2.12 Packet priority

   If the P bit in the L2F header is set, this packet is a "priority"
   packet.  When possible for an implementation, a packet received with
   the P bit should be processed in preference to previously received
   unprocessed packets without the P bit.

   The P bit may be set by an implementation based on criteria beyond
   the scope of this specification.  However, it is recommended that PPP
   keepalive traffic, if any, be sent with this bit set.

4.3 L2F Tunnel Establishment

   When the point-to-point link is first initiated between the NAS and
   the Home Gateway, the endpoints communicate on MID 0 prior to
   providing general L2F services to clients.  This communication is
   used to verify the presence of L2F on the remote end, and to permit
   any needed authentication.



Valencia, et. al.               Historic                       [Page 14]

RFC 2341                       Cisco L2F                        May 1998


   The protocol for such negotiation is always 1, indicating L2F
   management.  The message itself is structured as a sequence of single
   octets indicating an option, followed by zero or more further octets
   formatted as needed for the option.

4.3.1 Normal Tunnel Negotiation Sequence

   The establishment sequence is best illustrated by a "typical"
   connection sequence.  Detailed description of each functions follows,
   along with descriptions of the handling of exceptional conditions.

   Each packet is described as a source->destination on one line, a
   description of the L2F packet field contents on the next, and the
   contents of the packet's body on following lines.  The exact encoding
   of octets will be described later.

   Note that this example uses the Key option, but does not use the
   Offset and Checksum options.  The Length field would be present,
   reflecting the actual length of the packets as encoded as an octet
   stream.

      1. NAS->GW:
          Proto=L2F, Seq=0, MID=0, CLID=0, Key=0
          L2F_CONF
              Name: NAS_name
              Challenge: Rnd
              Assigned_CLID: 22

   The NAS decides that a tunnel must be initiated from the NAS to the
   GW.  An L2F packet is sent with the Proto field indicating an L2F
   management message is contained.

   Because the tunnel is being initiated, Key is set to 0.  The sequence
   number starts at 0; the MID is 0 to reflect the establishment of the
   tunnel itself.  Since the NAS has not yet received an L2F_CONF, the
   CLID is set to 0.

   The body of the packet specifies the claimed name of the NAS, and a
   challenge random number which GW will use in authenticating itself as
   a valid tunnel endpoint.  Assigned_CLID is generated to be a value
   not currently assigned out to any other tunnel to any other Home
   Gateway.









Valencia, et. al.               Historic                       [Page 15]

RFC 2341                       Cisco L2F                        May 1998


      2. GW->NAS:
          Proto=L2F, Seq=0, MID=0, CLID=22, Key=0
          L2F_CONF
              Name: GW_name
              Challenge: Rnd2
              Assigned_CLID: 73

   The Home Gateway has processed the previous packet, and sends a
   response.  The protocol continues to be L2F, with a sequence number 0
   (each side maintains its own sequence number for transmissions).  MID
   continues to be 0 to reflect tunnel establishment.  CLID reflects the
   Assigned_CLID field of the L2F_CONF received.  The Key continues to
   be 0 during this phase of tunnel establishment.

   The body contains the Home Gateway's name, its own random number
   challenge, and its own Assigned_CLID for the NAS to place in the CLID
   field of future packets.  The CLID is generated in an analogous
   manner to that of the NAS.  After this, all packets received from the
   NAS must be tagged with a CLID field containing 73, and all packets
   sent to the NAS must be tagged with a CLID field containing 22.

      3. NAS->GW
          Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
          L2F_OPEN
              Response: C(Rnd2)

   The NAS responds with its Key now set to reflect the shared secret.
   The Key is a CHAP-style hash of the random number received; each
   packet hereafter will reflect this calculated value, which serves as
   a key for the life of the tunnel.  Both the Home Gateway and the NAS
   use such Keys for the life of the tunnel.  The Key is a 32-bit
   representation of the MD5 digest resulting from encrypting the shared
   secret; the full MD5 digest is included in the L2F_OPEN response, in
   the "response" field.

      4. GW->NAS
          Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd)
          L2F_OPEN
              Response: C(Rnd)

   The Home Gateway provides closure of the key from the NAS, reflected
   in both the Key field as well as the "response" field.  The tunnel is
   now available for clients to be established.








Valencia, et. al.               Historic                       [Page 16]

RFC 2341                       Cisco L2F                        May 1998


4.3.2 Normal Client Negotiation Sequence

   This section describes the establishment of a Virtual dial-up client
   on a NAS into a Home Gateway.  It assumes a tunnel has been created
   in the way described in 4.3.1.  The client for this example is a PPP
   client configured for CHAP.

   Treatment of Checksum, Length, and Offset are as in 4.3.1.

         1. NAS->GW
             Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2)
             L2F_OPEN
                 Type: CHAP
                 Name: CHAP-name
                 Challenge: Rnd3
                 Response: <Value received, presumably C(Rnd3)>
                 ID: <ID used in challenge>

   The NAS has received a call, tried CHAP with a challenge value of
   Rnd3, and found that the client responded.  The claimed name lead the
   NAS to believe it was a Virtual dial-up client hosted by the Home
   Gateway.  The next free MID is allocated, and the information
   associated with the CHAP challenge/response is included in the
   connect notification.

      2. GW->NAS
          Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
          L2F_OPEN

   The Home Gateway, by sending back the L2F_OPEN, accepts the client.

      3. NAS->GW
          Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
          <Frame follows>

      4. GW->NAS
          Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
          <Frame follows>

   Traffic is now free to flow in either direction as sent by the remote
   client or the home site.  The contents is uninterpreted data, HDLC in
   this case.  Data traffic, since it is not the L2F protocol, does not
   usually use the Seq field, which is set to 0 in non-L2F messages (see
   the S bit in section 4.2.5 for details on an exception to this).







Valencia, et. al.               Historic                       [Page 17]

RFC 2341                       Cisco L2F                        May 1998


4.4 L2F management message types

   When an L2F packet's Proto field specifies L2F management, the body
   of the packet is encoded as zero or more options.  An option is a
   single octet "message type", followed by zero or more sub-options.
   Each sub-option is a single byte sub-option value, and further bytes
   as appropriate for the sub-option.

   Options in L2F are:


   Hex Value       Abbreviation       Description
   --------        ------------       -----------
    0x00            Invalid           Invalid message
    0x01            L2F_CONF          Request configuration
    0x02            L2F_CONF_NAME     Name of peer sending L2F_CONF
    0x03            L2F_CONF_CHAL     Random number peer challenges with
    0x04            L2F_CONF_CLID     Assigned_CLID for peer to use
    0x02            L2F_OPEN          Accept configuration
    0x01            L2F_OPEN_NAME     Name received from client
    0x02            L2F_OPEN_CHAL     Challenge client received
    0x03            L2F_OPEN_RESP     Challenge response from client
    0x04            L2F_ACK_LCP1      LCP CONFACK accepted from client
    0x05            L2F_ACK_LCP2      LCP CONFACK sent to client
    0x06            L2F_OPEN_TYPE     Type of authentication used
    0x07            L2F_OPEN_ID       ID associated with authentication
    0x08            L2F_REQ_LCP0      First LCP CONFREQ from client
    0x03            L2F_CLOSE         Request disconnect
    0x01            L2F_CLOSE_WHY     Reason code for close
    0x02            L2F_CLOSE_STR     ASCII string description
    0x04            L2F_ECHO          Verify presence of peer
    0x05            L2F_ECHO_RESP     Respond to L2F_ECHO

4.4.1 L2F message type: Invalid

   If a message is received with this value, or any value higher than
   the last recognized option value, or if an illegal packet as defined
   by other parts of this specification is received, the packet is
   considered invalid.  The packet MUST be discarded, and an L2F_CLOSE
   of the entire tunnel MUST be requested.  Upon receipt of an
   L2F_CLOSE, the tunnel itself may be closed.  All other received
   message MUST be discarded.  An implementation MAY close the tunnel
   after an interval of time appropriate to the characteristics of the
   tunnel.







Valencia, et. al.               Historic                       [Page 18]

RFC 2341                       Cisco L2F                        May 1998


   Note that packets with an invalid Key are discarded, but disconnect
   is not initiated.  This prevents denial-of-service attacks.  Invalid
   option types within a message MUST be treated as if the entire
   message type was invalid.

4.4.2 L2F_CONF

   The L2F message type is used to establish the tunnel between the NAS
   and the Home Gateway.  MID is always set to 0.  The body of such a
   message starts with the octet 0x01 (L2F_CONF), followed by all three
   of the sub-options below.

   The L2F_CONF_NAME sub-option MUST be present.  It is encoded as the
   octet value 0x02, followed by an octet specifying a non-zero length,
   followed by the indicated number of bytes, which are interpreted as
   the sender's ASCII name.

   The L2F_CONF_CHAL sub-option MUST be present.  It is encoded as the
   octet value 0x03, followed by a non-zero octet, followed by a number
   of bytes specified by this non-zero octet.

   The challenge value should be generated using whatever techniques
   provide the highest quality of random numbers available to a given
   implementation.

   The L2F_CONF_CLID sub-option MUST be present.  It is encoded as the
   octet 0x04, followed by four bytes of Assigned_CLID value.  The
   Assigned_CLID value is generated as a non-zero 16-bit integer value
   unique across all tunnels which exist on the sending system.  The
   least significant two octets of Assigned_CLID are set to this value,
   and the most significant two octets MUST be set to 0.

   The CLID field is sent as 0 in the initial L2F_CONF packet from NAS
   to Home Gateway, and otherwise MUST be sent containing the value
   specified in the Assigned_CLID field of the last L2F_CONF message
   received.

   Key MUST be set to 0 in all L2F_CONF packets, and no key field is
   included in the packet.

   When sent from a NAS to a Home Gateway, the L2F_CONF is the initial
   packet in the conversation.

   When sent from the Home Gateway to the NAS, an L2F_CONF indicates the
   Home Gateway's recognition of the tunnel creation request.  The Home
   Gateway MUST provide its name and its own challenge in the message
   body.




Valencia, et. al.               Historic                       [Page 19]

RFC 2341                       Cisco L2F                        May 1998


   In all packets following the L2F_CONF, the Key MUST be set to the
   CHAP-style hash of the received challenge bytes.  The CHAP-style hash
   is done over the concatenation of the low 8 bits of the assigned
   CLID, the secret, and the challenge value.  Generation of the 32-bit
   key value is discussed in section 4.2.11.

4.4.3 L2F_OPEN, tunnel establishment

   The L2F_OPEN message is used to provide tunnel setup closure (for a
   MID of 0) or to establish a client connection within a tunnel
   previously established by L2F_CONF and L2F_OPEN messages (MID not
   equal to 0).  This section describes tunnel establishment; section
   4.4.4 following describes clients established within the tunnel.

   An L2F_OPEN for tunnel establishment MUST contain only the sub-option
   0x03, L2F_OPEN_RESP.  This option MUST be followed by the octet 0x10,
   specifying the size of the 128-bit MD5 digest resulting from
   encrypting the challenge value in the L2F_CONF, along with the low
   byte of the Assigned_CLID.  After this byte MUST be the sixteen bytes
   of the generated MD5 digest.

   If during tunnel establishment an L2F_OPEN is received with an
   incorrect L2F_OPEN_RESP, the packet MUST be silently discarded.  It
   is recommended that such an event generate a log event as well.

4.4.4 L2F_OPEN, client establishment

   An L2F_OPEN (with non-zero MID) sent from the NAS to the Home Gateway
   indicates the presence of a new dial-in client.  When sent back from
   the Home Gateway to the NAS, it indicates acceptance of the client.
   This message starts with the octet 0x02.  When sent from the NAS, it
   may contain further sub-options.  When sent from the Home Gateway, it
   may not contain any sub-options.  All further discussion of sub-
   options in this section apply only to the NAS to Home Gateway
   direction.

   The L2F_OPEN_TYPE sub-option MUST be present.  It is encoded as the
   octet 0x06, followed by a single byte describing the type of
   authentication the NAS exchanged with the client in detecting the
   client's claimed identification.  Implicit in the authentication type
   is the encapsulation to be carried over the life of the session.  The
   authentication types are:

      0x01 Textual username/password exchange for SLIP
      0x02 PPP CHAP
      0x03 PPP PAP
      0x04 PPP no authentication
      0x05 SLIP no authentication



Valencia, et. al.               Historic                       [Page 20]

RFC 2341                       Cisco L2F                        May 1998


   The L2F_OPEN_NAME sub-option is encoded as the octet 0x01, followed
   by an octet specifying the length of the name, followed by the
   indicated number of bytes of the name.  This field MUST be present
   for any authentication type except 0x04 (None).  It MUST contain the
   name specified in the client's authentication response.

   The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed
   by an octet specifying the length of the challenge sent, followed by
   the challenge itself.  This field is only present for CHAP, and MUST
   contain the challenge value sent to the client by the NAS.

   The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed
   by an octet specifying the length of the response received, followed
   by the client's response to the challenge.  For CHAP, this field
   contains the response value received by the NAS.  For PAP or textual
   authentication, it contains the clear text password received from the
   client by the NAS.  This field is absent for authentication 0x04
   "None".

   The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the
   octets 0x04 and 0x05 respectively, followed in either case by two
   octets in network byte order specifying the length of the LCP CONFACK
   last received from or sent to the client.  Following these octets is
   an exact copy of the CONFACK packet.  L2F_ACK_LCP1 specifies a copy
   of the closing CONFACK received from the client, and L2F_ACK_LCP2
   specifies a copy of the closing CONFACK sent to the client by the
   NAS.

   The L2F_REQ_LCP0 sub-option is encoded as the octet 0x08, followed by
   two octets in network byte order specifying the length of the LCP
   CONFREQ initially received from the client.  This may be used by the
   Home Gateway to detect capabilities of the client which were
   negotiated away while starting LCP with the NAS.  Detection of such
   options may be used by the Home Gateway to decide to renegotiate LCP.

   The L2F_OPEN_ID sub-option is encoded as the octet 0x06, followed by
   a single octet.  This sub-option is only present for CHAP; the single
   octet contains the CHAP Identifier value sent to the client during
   the CHAP challenge.

   The Home Gateway may choose to ignore any sub-option of the L2F_OPEN,
   and accept the connection anyway.  The Home Gateway would then have
   to undertake its own LCP negotiations and authentication.  To
   maximize the transparency of the L2F tunnel, it is recommended that
   extra negotiations and authentication be avoided if possible.






Valencia, et. al.               Historic                       [Page 21]

RFC 2341                       Cisco L2F                        May 1998


4.4.5 L2F_CLOSE

   This message is encoded as the byte 0x03.  An L2F_CLOSE may be sent
   by either side of the tunnel at any time.  When sent with MID of 0,
   it indicates the desire to terminate the entire tunnel and all
   clients within the tunnel.  When sent from the Home Gateway in
   response to an L2F_OPEN, it indicates that the Home Gateway has
   declined the connection.  When sent with a non-zero MID, it indicates
   the termination of that client within the tunnel.

   The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed
   four bytes in network byte order specifying a bit mask of reasons for
   the disconnection.  The bits are encoded as:

      0x00000001 Authentication failed
      0x00000002 Out of resources
      0x00000004 Administrative intervention
      0x00000008 User quota exceeded
      0x00000010 Protocol error
      0x00000020 Unknown user
      0x00000040 Incorrect password
      0x00000080 PPP configuration incompatible
      0x00000100 Wrong multilink PPP destination

   Bits in the mask 0xFF000000 are reserved for per-vendor
   interpretation.

   An implementation can choose to not provide status bits even if it
   detects a condition described by one of these bits.  For instance, an
   implementation may choose to not use 0x00000020 due to security
   considerations, as it can be used to probe user name space.

   The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by
   a two-byte length in network byte order, followed by the indicated
   number of bytes, which are interpreted as descriptive ASCII text
   associated with the disconnection.  This string may be ignored, but
   could be recorded in a log to provide detailed or auxiliary
   information associated with the L2F_CLOSE.

4.4.6 L2F_ECHO

   Transmission of L2F_ECHO messages is optional.  If an implementation
   transmits L2F_ECHO messages, it MUST not transmit more than one such
   request each second.  The payload size MUST be 64 bytes or less in
   length.  It is recommended that at least 5 L2F_ECHO messages be sent
   without response before an implementation assumes that its peer has
   terminated.




Valencia, et. al.               Historic                       [Page 22]

RFC 2341                       Cisco L2F                        May 1998


   The L2F_ECHO message is encoded as the single byte 0x04.  It may be
   sent by either side once the tunnel is established.  MID MUST be 0.
   An L2F_ECHO_RESP (documented below) MUST be sent back in response.

4.4.7 L2F_ECHO_RESP

   All implementations MUST respond to L2F_ECHO, using L2F_ECHO_RESP.
   The received packet MUST be sent back verbatim, except that the CLID,
   sequence number, and checksum (if any) MUST be updated, and the
   L2F_ECHO message type changed to an L2F_ECHO_RESP.  Payload data
   following the 0x04 octet, if any, MUST be preserved in the response.

   When an L2F_ECHO_RESP is received, the payload data may be used to
   associate this response with a previously sent L2F_ECHO, or the
   packet may be silently discarded.

4.5 L2F Message Delivery

   L2F is designed to operate over point-to-point unreliable links.  It
   is not designed to provide flow control of the data traffic, nor does
   it provide reliable delivery of this traffic; each protocol tunnel
   carried via L2F is expected to manage flow control and retry itself.
   Thus, it is only L2F control messages which must be retransmitted;
   this process is described in this section.

4.5.1 Sequenced delivery

   All L2F control messages (i.e., those L2F packets with a protocol
   type of 0x01) are transmitted with a sequence number.  The sequence
   number is a per-L2F tunnel free running counter which is incremented
   (modulo 256) after each packet is transmitted.  It is used to permit
   the receiving end to detect duplicated or out-of-order packets, and
   to discard such packets.  Section 4.2.5 describes the process in
   detail.

4.5.2 Flow control

   L2F control messages are expected to be exchanged lock-step.  Thus,
   per-client activities can not occur until tunnel setup is complete.
   Neither can one client be serviced until the L2F message exchange is
   complete for a previous client.  Thus, it is expected that rarely--if
   ever--should a flow control action be required.  If the input queue
   of L2F control messages reaches an objectionable level for an
   implementation, the implementation may silently discard all messages
   in the queue to stabilize the situation.






Valencia, et. al.               Historic                       [Page 23]

RFC 2341                       Cisco L2F                        May 1998


4.5.3 Tunnel State table

   The following enumerates the handling of L2F messages for tunnel
   creation in state table format.  Events name an L2F_ message type
   (the L2F_ portion of the named message is omitted to permit a more
   compact table).  A start ("*") matches any event not otherwise
   matched for the named state.

   A NAS starts at initial state Start0, sending a packet before waiting
   for its first event.  A Home Gateway starts at Start1, waiting for an
   initial packet to start service.

   If an event is not matched for a given state, the packet associated
   with that event is silently discarded.

   Tunnel establishment (MID == 0), NAS side.


      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0                  Send CONF               Start1
      Start1  CONF            Send OPEN               Start2
      Start1  timeout 1-3     Send CONF               Start1
      Start1  timeout 4       Clean up tunnel         (done)
      Start2  OPEN            (initiate 1st client)   Open1
      Start2  timeout 1-3     Send OPEN               Start2
      Start2  timeout 4       Clean up tunnel         (done)
      Open1   OPEN            Send OPEN               Open1
      Open1   CLOSE           Send CLOSE              Close1
      Open1   no MIDs open    Send CLOSE              Close2
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up tunnel         (done)
      Close2  CLOSE           Clean up tunnel         (done)
      Close2  timeout 1-3     Send CLOSE              Close2
      Close2  timeout 4       Clean up tunnel         (done)

   Tunnel establishment (MID == 0), Home Gateway side.

      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0  CONF            Send CONF               Start1
      Start1  CONF            Send CONF               Start1
      Start1  OPEN            Send OPEN               Open1
      Start1  timeout 4       Clean up tunnel         (done)
      Open1   OPEN            Send OPEN               Open1
      Open1   OPEN (MID > 0)  (1st client, below)     Open2
      Open1   CLOSE           Send CLOSE              Close1
      Open1   timeout 4       Clean up tunnel         (done)



Valencia, et. al.               Historic                       [Page 24]

RFC 2341                       Cisco L2F                        May 1998


      Open2   OPEN (MID > 0)  (below)                 Open2
      Open2   CLOSE           Send CLOSE              Close1
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up tunnel         (done)

4.5.4 Client State table

   This table is similar to the previous one, but enumerates the states
   for a client connection within a tunnel in the opened state from
   4.5.3.  As this sequence addresses clients, MID will be non-zero.

   Client establishment (MID != 0), NAS side.

      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0                  Send OPEN               Start1
      Start1  OPEN            (enable forwarding)     Open1
      Start1  CLOSE           Clean up MID            (MID done)
      Start1  timeout 1-3     Send OPEN               Start1
      Start1  timeout 4       Clean up MID            (MID done)
      Start1  client done     Send CLOSE              Close2
      Open1   OPEN            (no change)             Open1
      Open1   CLOSE           Send CLOSE              Close1
      Open1   client done     Send CLOSE              Close2
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up MID            (MID done)
      Close2  CLOSE           Clean up MID            (MID done)
      Close2  timeout 1-3     Send CLOSE              Close2
      Close2  timeout 4       Clean up MID            (MID done)

   Client establishment (MID != 0), Home Gateway side.

      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0  OPEN            Send OPEN               Open1
      Start0  OPEN (fail)     Send CLOSE              Close3
      Open1   OPEN            Send OPEN               Open1
      Open1   CLOSE           Send CLOSE              Close1
      Open1   client done     Send CLOSE              Close2
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up MID            (MID done)
      Close2  CLOSE           Clean up MID            (MID done)
      Close2  timeout 1-3     Send CLOSE              Close2
      Close2  timeout 4       Clean up MID            (MID done)
      Close3  OPEN            Send CLOSE              Close3
      Close3  timeout 4       Clean up MID            (MID done)





Valencia, et. al.               Historic                       [Page 25]

RFC 2341                       Cisco L2F                        May 1998


5. Protocol Considerations

   Several aspects of operation over L2F, while outside the realm of the
   protocol description itself, serve to clarify the operation of L2F.

5.1 PPP Features

   Because L2F in operation carries uninterpreted frames, it permits
   operation of features without explicit knowledge of these features.
   For instance, if a PPP session is carried, L2F is simply transporting
   HDLC frames.  The two PPP endpoints can negotiate higher-level
   features, such as reliable link, compression, multi-link, or
   encryption.  These features then operate between the two PPP
   endpoints (the dial-in client on one end, and the Home Gateway on the
   other), with L2F continuing to simply ship HDLC frames back and
   forth.

   For similar reasons, PPP echo requests, NCP configuration
   negotiation, and even termination requests, are all simply tunneled
   HDLC frames.

5.2 Termination

   As L2F simply tunnels link-layer frames, it does not detect frames
   like PPP TERMREQ.  L2F termination in these scenarios is driven from
   a protocol endpoint; for instance, if a Home Gateway receives a
   TERMREQ, its action will be to "hang up" the PPP session.  It is the
   responsibility of the L2F implementation at the Home Gateway to
   convert a "hang up" into an L2F_CLOSE action, which will shut down
   client's session in the tunnel cleanly.  L2F_CLOSE_WHY and
   L2F_CLOSE_STR may be included to describe the reason for the
   shutdown.

5.3 Extended Authentication

   L2F is compatible with both PAP and CHAP protocols.  SLIP does not
   provide authentication within the protocol itself, and thus requires
   an ASCII exchange of username and password before SLIP is started.
   L2F is compatible with this mode of operation as well.

   One-time password cards have become very common.  To the extent the
   NAS can capture and forward the one-time password, L2F operation is
   compatible with password cards.  For the most general solution, an
   arbitrary request/response exchange must be supported.  In an L2F
   environment, the protocol must be structured so that the NAS can
   detect the apparent identity of the user and establish a tunnel
   connection to the Home Gateway, where the arbitrary exchange can
   occur.



Valencia, et. al.               Historic                       [Page 26]

RFC 2341                       Cisco L2F                        May 1998


5.4 MNP4 and Apple Remote Access Protocol

   L2F appears compatible with Apple's ARAP protocol.  Its operation
   under L2F has not been described simply because this experimental RFC
   does not have a corresponding implementation of such operation.

5.5 Operation of IP and UDP

   L2F tries to be self-describing, operating at a level above the
   particular media over which it is carried.  However, some details of
   its connection to media are required to permit interoperable
   implementations.  This section describes the issues which have been
   found when operating L2F over IP and UDP.

   L2F uses the well-known UDP port 1701 [4].  The entire L2F packet,
   including payload and L2F header, is sent within a UDP datagram.  The
   source and destination ports are the same (1701), with demultiplexing
   being achieved using CLID values.  It is legal for the source IP
   address of a given CLID to change over the life of a connection, as
   this may correspond to a peer with multiple IP interfaces responding
   to a network topology change.  Responses should reflect the last
   source IP address for that CLID.

   IP fragmentation may occur as the L2F packet travels over the IP
   substrate.  L2F makes no special efforts to optimize this.  A NAS
   implementation MAY cause its LCP to negotiate for a specific MRU,
   which could optimize for NAS environments in which the MTUs of the
   path over which the L2F packets are likely to travel have a
   consistent value.

6.0 Acknowledgments

   L2F uses a packet format inspired by GRE [5].  Thanks to Fred Baker
   for consultation, Dave Carrel for consulting on security aspects, and
   to Paul Traina for philosophical guidance.

7.0 References

   [1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
       Serial Lines: SLIP", RFC 1055, June 1988.

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

   [3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662,
       July 1994.





Valencia, et. al.               Historic                       [Page 27]

RFC 2341                       Cisco L2F                        May 1998


   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       October 1994.

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

8.0 Security Considerations

   Security issues are discussed in Section 3.1.

9.0 Authors' Addresses

   Tim Kolar
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

   EMail: tkolar@cisco.com


   Morgan Littlewood
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

   EMail: littlewo@cisco.com


   Andy Valencia
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

   EMail: valencia@cisco.com

















Valencia, et. al.               Historic                       [Page 28]

RFC 2341                       Cisco L2F                        May 1998


9.0  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Valencia, et. al.               Historic                       [Page 29]