[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 rfc2516                                              
PPP Working Group                  Louis Mamakos, Kurt Lidl, Jeff Evarts
INTERNET-DRAFT                                  UUNET Technologies, Inc.
Category: Informational                         David Carrel, Dan Simone
Title: draft-carrel-info-pppoe-00.txt             RedBack Networks, Inc.
Date: August 1998                                           Ross Wheeler
                                                        RouterWare, Inc.


                       PPP Over Ethernet "PPPOE"
                    <draft-carrel-info-pppoe-00.txt>


                          Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "working draft" or "work in
   progress."

   To learn the current status of any Internet Draft, please check the
   1id-abstracts.txt listing contained in the Internet Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Australia), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   The distribution of this memo is unlimited.  It is filed as <draft-
   carrel-info-pppoe-00.txt>, and expires 10 February, 1999.  Please
   send comments to the authors.


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 the use of Ethernet framing for PPP
   encapsulated packets.








Evarts, Carrel                                                  [Page1]

INTERNET DRAFT                                               August 1998


Applicability

   PPP requires a point-to-point relationship between its peers and is
   not designed for the multi-point relationships which are available in
   Ethernet and other multi-access environments.  This document
   therefore defines a means for conveying PPP facilities, including the
   Link Control Protocol, Network-layer Control Protocols,
   authentication, compression and more, over Ethernet.

   The protocol described in this document can be used by multiple hosts
   on a shared, Ethernet to open PPP sessions to multiple destinations
   via one or more bridging modems.


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






Evarts, Carrel                                                  [Page2]

INTERNET DRAFT                                               August 1998


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.

   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            |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Evarts, Carrel                                                  [Page3]

INTERNET DRAFT                                               August 1998


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

   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



Evarts, Carrel                                                  [Page4]

INTERNET DRAFT                                               August 1998


   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.

   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's value is an unsigned number
   in network byte order, indicating the length in octets of the
   TAG_VALUE.

   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 contains exactly one tag of type Service-Name,
   indicating the service the Host is requesting, and any number of
   other tag types.

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.

   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



Evarts, Carrel                                                  [Page5]

INTERNET DRAFT                                               August 1998


   services that the Access Concentrator offers.  If the Access
   Concentrator can not serve the PADI, then 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 contains exactly one tag of 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 PADR packet contains exactly one tag of 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 single tag of type
   Service-Name-Error, and the SESSION_ID MUST be set to 0x0000.


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.




Evarts, Carrel                                                  [Page6]

INTERNET DRAFT                                               August 1998


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.

   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.


8. Other Considerations

   When a host does not receive a PADO packet within a specified amount
   of time, the client 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.


9. Security Considerations

   Denial of Service (DOS) attacks can be used against an Access
   Concentrator that employs this protocol.  A Cookie tag is currently
   being investigated      to understand if it can alleviate the threat.
   An Access Concentrator can also employ means outside this protocol to
   prevent against DOS attacks.

   Many Access Concentrators will not wish to offer information
   regarding what services they offer to an unauthenticated entity.  In



Evarts, Carrel                                                  [Page7]

INTERNET DRAFT                                               August 1998


   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.

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

11. References

   [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
   07/21/1994

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


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 ASCII 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 ascii rendition of the MAC address of the box.



Evarts, Carrel                                                  [Page8]

INTERNET DRAFT                                               August 1998


   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 ascii string which explains why the request
      was denied.


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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



















Evarts, Carrel                                                  [Page9]

INTERNET DRAFT                                               August 1998


   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      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




















Evarts, Carrel                                          [Page10]

INTERNET DRAFT                                               August 1998


   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 <louie@uu.net>
   Kurt Lidl <lidl@uu.net>
   Jeff Evarts <jde@uu.net>
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA  22031-4648
   United States of America

   David Carrel <carrel@RedBack.net>
   Dan Simone <dan@RedBack.net>
   RedBack Networks, Inc.
   1389 Moffett Park Drive
   Sunnyvale, CA  94089-1134
   United States of America

   Ross Wheeler <ross@routerware.com>
   RouterWare, Inc.
   3961 MacArthur Blvd., Suite 212
   Newport Beach, CA  92660
   United States of America








Evarts, Carrel                                          [Page11]