ctrl: implemented PPPoE server

1 files changed, 955 insertions, 0 deletions

diff --git a/rfc/rfc2516.txt b/rfc/rfc2516.txt
new file mode 100644
index 0000000..5397c86
--- /dev/null
+++ b/rfc/rfc2516.txt
@@ -0,0 +1,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]
+