summaryrefslogtreecommitdiff
path: root/rfc/rfc2516.txt
blob: 5397c863dc395cd2c84785028c1049c9aff1499a (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






Network Working Group                                        L. Mamakos
Request for Comments: 2516                                      K. Lidl
Category: Informational                                       J. Evarts
                                               UUNET Technologies, Inc.
                                                              D. Carrel
                                                              D. Simone
                                                 RedBack Networks, Inc.
                                                             R. Wheeler
                                                       RouterWare, Inc.
                                                          February 1999


          A Method for Transmitting PPP Over Ethernet (PPPoE)

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.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   This document describes how to build PPP sessions and encapsulate PPP
   packets over Ethernet.

Applicability

   This specification is intended to provide the facilities which are
   defined for PPP, such as the Link Control Protocol, Network-layer
   Control Protocols, authentication, and more.  These capabilities
   require a point-to-point relationship between the peers, and are not
   designed for the multi-point relationships which are available in
   Ethernet and other multi-access environments.

   This specification can be used by multiple hosts on a shared,
   Ethernet to open PPP sessions to multiple destinations via one or
   more bridging modems.  It is intended to be used with broadband
   remote access technologies that provide a bridged Ethernet topology,
   when access providers wish to maintain the session abstraction
   associated with PPP.




Mamakos, et. al.             Informational                      [Page 1]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   This document describes the PPP Over Ethernet encapsulation that is
   being deployed by RedBack Networks, RouterWare, UUNET and others.

1. Introduction

   Modern access technologies are faced with several conflicting goals.
   It is desirable to connect multiple hosts at a remote site through
   the same customer premise access device.  It is also a goal to
   provide access control and billing functionality in a manner similar
   to dial-up services using PPP.  In many access technologies, the most
   cost effective method to attach multiple hosts to the customer
   premise access device, is via Ethernet.  In addition, it is desirable
   to keep the cost of this device as low as possible while requiring
   little or no configuration.

   PPP over Ethernet (PPPoE) provides the ability to connect a network
   of hosts over a simple bridging access device to a remote Access
   Concentrator.  With this model, each host utilizes it's own PPP stack
   and the user is presented with a familiar user interface.  Access
   control, billing and type of service can be done on a per-user,
   rather than a per-site, basis.

   To provide a point-to-point connection over Ethernet, each PPP
   session must learn the Ethernet address of the remote peer, as well
   as establish a unique session identifier.  PPPoE includes a discovery
   protocol that provides this.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [2].

3. Protocol Overview

   PPPoE has two distinct stages.  There is a Discovery stage and a PPP
   Session stage.  When a Host wishes to initiate a PPPoE session, it
   must first perform Discovery to identify the Ethernet MAC address of
   the peer and establish a PPPoE SESSION_ID.  While PPP defines a
   peer-to-peer relationship, Discovery is inherently a client-server
   relationship.  In the Discovery process, a Host (the client)
   discovers an Access Concentrator (the server).  Based on the network
   topology, there may be more than one Access Concentrator that the
   Host can communicate with.  The Discovery stage allows the Host to
   discover all Access Concentrators and then select one.  When
   Discovery completes successfully, both the Host and the selected
   Access Concentrator have the information they will use to build their
   point-to-point connection over Ethernet.



Mamakos, et. al.             Informational                      [Page 2]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   The Discovery stage remains stateless until a PPP session is
   established.  Once a PPP session is established, both the Host and
   the Access Concentrator MUST allocate the resources for a PPP virtual
   interface.

4. Payloads

   The following packet formats are defined here.  The payload contents
   will be defined in the Discovery and PPP sections.

   An Ethernet frame is as follows:

                                       1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |       DESTINATION_ADDR        |
                  |          (6 octets)           |
                  |                               |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |         SOURCE_ADDR           |
                  |          (6 octets)           |
                  |                               |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |    ETHER_TYPE  (2 octets)     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ~                               ~
                  ~           payload             ~
                  ~                               ~
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |           CHECKSUM            |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The DESTINATION_ADDR field contains either a unicast Ethernet
   destination address, or the Ethernet broadcast address (0xffffffff).
   For Discovery packets, the value is either a unicast or broadcast
   address as defined in the Discovery section.  For PPP session
   traffic, this field MUST contain the peer's unicast address as
   determined from the Discovery stage.

   The SOURCE_ADDR field MUST contains the Ethernet MAC address of the
   source device.

   The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864
   (PPP Session Stage).







Mamakos, et. al.             Informational                      [Page 3]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   The Ethernet payload for PPPoE is as follows:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  VER  | TYPE  |      CODE     |          SESSION_ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LENGTH             |           payload             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The VER field is four bits and MUST be set to 0x1 for this version of
   the PPPoE specification.

   The TYPE field is four bits and MUST be set to 0x1 for this version
   of the PPPoE specification.

   The CODE field is eight bits and is defined below for the Discovery
   and PPP Session stages.

   The SESSION_ID field is sixteen bits.  It is an unsigned value in
   network byte order.  It's value is defined below for Discovery
   packets.  The value is fixed for a given PPP session and, in fact,
   defines a PPP session along with the Ethernet SOURCE_ADDR and
   DESTINATION_ADDR.  A value of 0xffff is reserved for future use and
   MUST NOT be used

   The LENGTH field is sixteen bits.  The value, in network byte order,
   indicates the length of the PPPoE payload.  It does not include the
   length of the Ethernet or PPPoE headers.

5. Discovery Stage

   There are four steps to the Discovery stage.  When it completes, both
   peers know the PPPoE SESSION_ID and the peer's Ethernet address,
   which together define the PPPoE session uniquely.  The steps consist
   of the Host broadcasting an Initiation packet, one or more Access
   Concentrators sending Offer packets, the Host sending a unicast
   Session Request packet and the selected Access Concentrator sending a
   Confirmation packet.  When the Host receives the Confirmation packet,
   it may proceed to the PPP Session Stage.  When the Access
   Concentrator sends the Confirmation packet, it may proceed to the PPP
   Session Stage.

   All Discovery Ethernet frames have the ETHER_TYPE field set to the
   value 0x8863.






Mamakos, et. al.             Informational                      [Page 4]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   The PPPoE payload contains zero or more TAGs.  A TAG is a TLV (type-
   length-value) construct and is defined as follows:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TAG_TYPE             |        TAG_LENGTH             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TAG_VALUE ...                                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TAG_TYPE is a sixteen bit field in network byte order.  Appendix A
   contains a list of all TAG_TYPEs and their TAG_VALUEs.

   TAG_LENGTH is a sixteen bit field.  It is an unsigned number in
   network byte order, indicating the length in octets of the TAG_VALUE.

   If a discovery packet is received with a TAG of unknown TAG_TYPE, the
   TAG MUST be ignored unless otherwise specified in this document.
   This provides for backwards compatibility if/when new TAGs are added.
   If new mandatory TAGs are added, the version number will be
   incremented.

   Some example Discovery packets are shown in Appendix B.

5.1 The PPPoE Active Discovery Initiation (PADI) packet

   The Host sends the PADI packet with the DESTINATION_ADDR set to the
   broadcast address.  The CODE field is set to 0x09 and the SESSION_ID
   MUST be set to 0x0000.

   The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-
   Name, indicating the service the Host is requesting, and any number
   of other TAG types.  An entire PADI packet (including the PPPoE
   header) MUST NOT exceed 1484 octets so as to leave sufficient room
   for a relay agent to add a Relay-Session-Id TAG.

5.2 The PPPoE Active Discovery Offer (PADO) packet

   When the Access Concentrator receives a PADI that it can serve, it
   replies by sending a PADO packet.  The DESTINATION_ADDR is the
   unicast address of the Host that sent the PADI.  The CODE field is
   set to 0x07 and the SESSION_ID MUST be set to 0x0000.








Mamakos, et. al.             Informational                      [Page 5]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   The PADO packet MUST contain one AC-Name TAG containing the Access
   Concentrator's name, a Service-Name TAG identical to the one in the
   PADI, and any number of other Service-Name TAGs indicating other
   services that the Access Concentrator offers.  If the Access
   Concentrator can not serve the PADI it MUST NOT respond with a PADO.

5.3 The PPPoE Active Discovery Request (PADR) packet

   Since the PADI was broadcast, the Host may receive more than one
   PADO.  The Host looks through the PADO packets it receives and
   chooses one.  The choice can be based on the AC-Name or the Services
   offered.  The Host then sends one PADR packet to the Access
   Concentrator that it has chosen.  The DESTINATION_ADDR field is set
   to the unicast Ethernet address of the Access Concentrator that sent
   the PADO.  The CODE field is set to 0x19 and the SESSION_ID MUST be
   set to 0x0000.

   The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-
   Name, indicating the service the Host is requesting, and any number
   of other TAG types.

5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet

   When the Access Concentrator receives a PADR packet, it prepares to
   begin a PPP session.  It generates a unique SESSION_ID for the PPPoE
   session and replies to the Host with a PADS packet.  The
   DESTINATION_ADDR field is the unicast Ethernet address of the Host
   that sent the PADR.  The CODE field is set to 0x65 and the SESSION_ID
   MUST be set to the unique value generated for this PPPoE session.

   The PADS packet contains exactly one TAG of TAG_TYPE Service-Name,
   indicating the service under which Access Concentrator has accepted
   the PPPoE session, and any number of other TAG types.

   If the Access Concentrator does not like the Service-Name in the
   PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE
   Service-Name-Error (and any number of other TAG types).  In this case
   the SESSION_ID MUST be set to 0x0000.

5.5 The PPPoE Active Discovery Terminate (PADT) packet

   This packet may be sent anytime after a session is established to
   indicate that a PPPoE session has been terminated.  It may be sent by
   either the Host or the Access Concentrator.  The DESTINATION_ADDR
   field is a unicast Ethernet address, the CODE field is set to 0xa7
   and the SESSION_ID MUST be set to indicate which session is to be
   terminated.  No TAGs are required.




Mamakos, et. al.             Informational                      [Page 6]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   When a PADT is received, no further PPP traffic is allowed to be sent
   using that session.  Even normal PPP termination packets MUST NOT be
   sent after sending or receiving a PADT.  A PPP peer SHOULD use the
   PPP protocol itself to bring down a PPPoE session, but the PADT MAY
   be used when PPP can not be used.

6. PPP Session Stage

   Once the PPPoE session begins, PPP data is sent as in any other PPP
   encapsulation.  All Ethernet packets are unicast.  The ETHER_TYPE
   field is set to 0x8864.  The PPPoE CODE MUST be set to 0x00.  The
   SESSION_ID MUST NOT change for that PPPoE session and MUST be the
   value assigned in the Discovery stage.  The PPPoE payload contains a
   PPP frame.  The frame begins with the PPP Protocol-ID.

   An example packet is shown in Appendix B.

7. LCP Considerations

   The Magic Number LCP configuration option is RECOMMENDED, and the
   Protocol Field Compression (PFC) option is NOT RECOMMENDED.  An
   implementation MUST NOT request any of the following options, and
   MUST reject a request for such an option:

      Field Check Sequence (FCS) Alternatives,

      Address-and-Control-Field-Compression (ACFC),

      Asynchronous-Control-Character-Map (ACCM)

   The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
   larger size than 1492.  Since Ethernet has a maximum payload size of
   1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
   2 octets, the PPP MTU MUST NOT be greater than 1492.

   It is RECOMMENDED that the Access Concentrator ocassionally send
   Echo-Request packets to the Host to determine the state of the
   session.  Otherwise, if the Host terminates a session without sending
   a Terminate-Request packet, the Access Concentrator will not be able
   to determine that the session has gone away.

   When LCP terminates, the Host and Access concentrator MUST stop using
   that PPPoE session.  If the Host wishes to start another PPP session,
   it MUST return to the PPPoE Discovery stage.







Mamakos, et. al.             Informational                      [Page 7]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


8. Other Considerations

   When a host does not receive a PADO packet within a specified amount
   of time, it SHOULD resend it's PADI packet and double the waiting
   period. This is repeated as many times as desired.  If the Host is
   waiting to receive a PADS packet, a similar timeout mechanism SHOULD
   be used, with the Host re-sending the PADR.  After a specified number
   of retries, the Host SHOULD then resend a PADI packet.

   The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been
   assigned by the IEEE for use by PPP Over Ethernet (PPPoE).  Use of
   these values and the PPPoE VER (version) field uniquely identify this
   protocol.

   UTF-8 [5] is used throughout this document instead of ASCII.  UTF-8
   supports the entire ASCII character set while allowing for
   international character sets as well.  See [5] for more details.

9. Security Considerations

   To help protect against Denial of Service (DOS) attacks, the Access
   Concentrator can employ the AC-Cookie TAG.  The Access Concentrator
   SHOULD be able to uniquely regenerate the TAG_VALUE based on the PADR
   SOURCE_ADDR.  Using this, the Access Concentrator can ensure that the
   PADI SOURCE_ADDR is indeed reachable and can then limit concurrent
   sessions for that address.  What algorithm to use is not defined and
   left as an implementation detail.  An example is HMAC [3] over the
   Host MAC address using a key known only to the Access > Concentrator.
   While the AC-Cookie is useful against some DOS attacks, it can not
   protect against all DOS attacks and an Access Concentrator MAY employ
   other means to protect resources.

   While the AC-Cookie is useful against some DOS attacks, it can not
   protect against all DOS attacks and an Access Concentrator MAY employ
   other means to protect resources.

   Many Access Concentrators will not wish to offer information
   regarding what services they offer to an unauthenticated entity.  In
   that case the Access Concentrator should employ one of two policies.
   It SHOULD never refuse a request based on the Service-Name TAG, and
   always return the TAG_VALUE that was sent to it.  Or it SHOULD only
   accept requests with a Service-Name TAG with a zero TAG_LENGTH
   (indicating any service).  The former solution is RECOMMENDED.

10. Acknowledgments

   This document is based on concepts discussed in several forums,
   including the ADSL forum.



Mamakos, et. al.             Informational                      [Page 8]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   Copious amounts of text have been stolen from RFC 1661, RFC 1662 and
   RFC 2364.

11. References

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

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

   [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
       for Message Authentication", RFC 2104, February 1998.

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

   [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
       2279, January 1998.
































Mamakos, et. al.             Informational                      [Page 9]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


Appendix A

   TAG_TYPES and TAG_VALUES

   0x0000 End-Of-List

      This TAG indicates that there are no further TAGs in the list. The
      TAG_LENGTH of this TAG MUST always be zero.  Use of this TAG is
      not required, but remains for backwards compatibility.

   0x0101 Service-Name

      This TAG indicates that a service name follows.  The TAG_VALUE is
      an UTF-8 string that is NOT NULL terminated. When the TAG_LENGTH
      is zero this TAG is used to indicate that any service is
      acceptable.  Examples of the use of the Service-Name TAG are to
      indicate an ISP name or a class or quality of service.

   0x0102 AC-Name

      This TAG indicates that a string follows which uniquely identifies
      this particular Access Concentrator unit from all others. It may
      be a combination of trademark, model, and serial id information,
      or simply an UTF-8 rendition of the MAC address of the box.  It is
      not NULL terminated.

   0x0103 Host-Uniq

      This TAG is used by a Host to uniquely associate an Access
      Concentrator response (PADO or PADS) to a particular Host request
      (PADI or PADR).  The TAG_VALUE is binary data of any value and
      length that the Host chooses.  It is not interpreted by the Access
      Concentrator.  The Host MAY include a Host-Uniq TAG in a PADI or
      PADR.  If the Access Concentrator receives this TAG, it MUST
      include the TAG unmodified in the associated PADO or PADS
      response.

   0x0104 AC-Cookie

      This TAG is used by the Access Concentrator to aid in protecting
      against denial of service attacks (see the Security Considerations
      section for an explanation of how this works).  The Access
      Concentrator MAY include this TAG in a PADO packet.  If a Host
      receives this TAG, it MUST return the TAG unmodified in the
      following PADR.  The TAG_VALUE is binary data of any value and
      length and is not interpreted by the Host.





Mamakos, et. al.             Informational                     [Page 10]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   0x0105 Vendor-Specific

      This TAG is used to pass vendor proprietary information.  The
      first four octets of the TAG_VALUE contain the vendor id and the
      remainder is unspecified.  The high-order octet of the vendor id
      is 0 and the low-order 3 octets are the SMI Network Management
      Private Enterprise Code of the Vendor in network byte order, as
      defined in the Assigned Numbers RFC [4].

      Use of this TAG is NOT RECOMMENDED.  To ensure inter-operability,
      an implementation MAY silently ignore a Vendor-Specific TAG.

   0x0110 Relay-Session-Id

      This TAG MAY be added to any discovery packet by an intermediate
      agent that is relaying traffic.  The TAG_VALUE is opaque to both
      the Host and the Access Concentrator.  If either the Host or
      Access Concentrator receives this TAG they MUST include it
      unmodified in any discovery packet they send as a response.  All
      PADI packets MUST guarantee sufficient room for the addition of a
      Relay-Session-Id TAG with a TAG_VALUE length of 12 octets.

      A Relay-Session-Id TAG MUST NOT be added if the discovery packet
      already contains one.  In that case the intermediate agent SHOULD
      use the existing Relay-Session-Id TAG.  If it can not use the
      existing TAG or there is insufficient room to add a Relay-
      Session-Id TAG, then it SHOULD return a Generic-Error TAG to the
      sender.

   0x0201 Service-Name-Error

      This TAG (typically with a zero-length data section) indicates
      that for one reason or another, the requested Service-Name request
      could not be honored.

      If there is data, and the first octet of the data is nonzero, then
      it MUST be a printable UTF-8 string which explains why the request
      was denied.  This string MAY NOT be NULL terminated.

   0x0202 AC-System-Error

      This TAG indicates that the Access Concentrator experienced some
      error in performing the Host request.  (For example insufficient
      resources to create a virtual circuit.)  It MAY be included in
      PADS packets.






Mamakos, et. al.             Informational                     [Page 11]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


      If there is data, and the first octet of the data is nonzero, then
      it MUST be a printable UTF-8 string which explains the nature of
      the error.  This string MAY NOT be NULL terminated.

   0x0203 Generic-Error

      This TAG indicates an error.  It can be added to PADO, PADR or
      PADS packets when an unrecoverable error occurs and no other error
      TAG is appropriate.  If there is data then it MUST be an UTF-8
      string which explains the nature of the error.  This string MUST
      NOT be NULL terminated.








































Mamakos, et. al.             Informational                     [Page 12]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


Appendix B

   The following are some example packets:

   A PADI packet:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         0xffffffff                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           0xffff              |        Host_mac_addr          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Host_mac_addr (cont)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0x09  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     SESSION_ID = 0x0000       |      LENGTH = 0x0004          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      TAG_TYPE = 0x0101        |    TAG_LENGTH = 0x0000        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






























Mamakos, et. al.             Informational                     [Page 13]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   A PADO packet:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Host_mac_addr                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Access_Concentrator_mac_addr (cont)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0x07  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     SESSION_ID = 0x0000       |      LENGTH = 0x0020          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      TAG_TYPE = 0x0101        |    TAG_LENGTH = 0x0000        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      TAG_TYPE = 0x0102        |    TAG_LENGTH = 0x0018        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x47      |     0x6f      |     0x20      |     0x52      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x65      |     0x64      |     0x42      |     0x61      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x63      |     0x6b      |     0x20      |     0x2d      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x20      |     0x65      |     0x73      |     0x68      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x73      |     0x68      |     0x65      |     0x73      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x68      |     0x6f      |     0x6f      |     0x74      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




















Mamakos, et. al.             Informational                     [Page 14]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   A PPP LCP packet:  The PPP protocol value is shown (0xc021) but the
   PPP payload is left to the reader.  This is a packet from the Host to
   the Access Concentrator.

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Access_Concentrator_mac_addr                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Access_Concentrator_mac_addr(c)|        Host_mac_addr          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Host_mac_addr (cont)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ETHER_TYPE = 0x8864        | v = 1 | t = 1 |  CODE = 0x00  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     SESSION_ID = 0x1234       |      LENGTH = 0x????          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    PPP PROTOCOL = 0xc021      |        PPP payload            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authors'  Addresses

   Louis Mamakos
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA  22031-4648
   United States of America

   EMail: louie@uu.net


   Kurt Lidl
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA  22031-4648
   United States of America

   EMail: lidl@uu.net


   Jeff Evarts
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA  22031-4648
   United States of America

   EMail: jde@uu.net




Mamakos, et. al.             Informational                     [Page 15]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


   David Carrel
   RedBack Networks, Inc.
   1389 Moffett Park Drive
   Sunnyvale, CA  94089-1134
   United States of America

   EMail: carrel@RedBack.net


   Dan Simone
   RedBack Networks, Inc.
   1389 Moffett Park Drive
   Sunnyvale, CA  94089-1134
   United States of America

   EMail:dan@RedBack.net


   Ross Wheeler
   RouterWare, Inc.
   3961 MacArthur Blvd., Suite 212
   Newport Beach, CA  92660
   United States of America

   EMail: ross@routerware.com


























Mamakos, et. al.             Informational                     [Page 16]

RFC 2516             Transmitting PPP Over Ethernet        February 1999


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Mamakos, et. al.             Informational                     [Page 17]