home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2516.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  32.7 KB  |  956 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        L. Mamakos
  8. Request for Comments: 2516                                      K. Lidl
  9. Category: Informational                                       J. Evarts
  10.                                                UUNET Technologies, Inc.
  11.                                                               D. Carrel
  12.                                                               D. Simone
  13.                                                  RedBack Networks, Inc.
  14.                                                              R. Wheeler
  15.                                                        RouterWare, Inc.
  16.                                                           February 1999
  17.  
  18.  
  19.           A Method for Transmitting PPP Over Ethernet (PPPoE)
  20.  
  21. Status of this Memo
  22.  
  23.    This memo provides information for the Internet community.  It does
  24.    not specify an Internet standard of any kind.  Distribution of this
  25.    memo is unlimited.
  26.  
  27. Copyright Notice
  28.  
  29.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  30.  
  31. Abstract
  32.  
  33.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  34.    transporting multi-protocol datagrams over point-to-point links.
  35.  
  36.    This document describes how to build PPP sessions and encapsulate PPP
  37.    packets over Ethernet.
  38.  
  39. Applicability
  40.  
  41.    This specification is intended to provide the facilities which are
  42.    defined for PPP, such as the Link Control Protocol, Network-layer
  43.    Control Protocols, authentication, and more.  These capabilities
  44.    require a point-to-point relationship between the peers, and are not
  45.    designed for the multi-point relationships which are available in
  46.    Ethernet and other multi-access environments.
  47.  
  48.    This specification can be used by multiple hosts on a shared,
  49.    Ethernet to open PPP sessions to multiple destinations via one or
  50.    more bridging modems.  It is intended to be used with broadband
  51.    remote access technologies that provide a bridged Ethernet topology,
  52.    when access providers wish to maintain the session abstraction
  53.    associated with PPP.
  54.  
  55.  
  56.  
  57.  
  58. Mamakos, et. al.             Informational                      [Page 1]
  59.  
  60. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  61.  
  62.  
  63.    This document describes the PPP Over Ethernet encapsulation that is
  64.    being deployed by RedBack Networks, RouterWare, UUNET and others.
  65.  
  66. 1. Introduction
  67.  
  68.    Modern access technologies are faced with several conflicting goals.
  69.    It is desirable to connect multiple hosts at a remote site through
  70.    the same customer premise access device.  It is also a goal to
  71.    provide access control and billing functionality in a manner similar
  72.    to dial-up services using PPP.  In many access technologies, the most
  73.    cost effective method to attach multiple hosts to the customer
  74.    premise access device, is via Ethernet.  In addition, it is desirable
  75.    to keep the cost of this device as low as possible while requiring
  76.    little or no configuration.
  77.  
  78.    PPP over Ethernet (PPPoE) provides the ability to connect a network
  79.    of hosts over a simple bridging access device to a remote Access
  80.    Concentrator.  With this model, each host utilizes it's own PPP stack
  81.    and the user is presented with a familiar user interface.  Access
  82.    control, billing and type of service can be done on a per-user,
  83.    rather than a per-site, basis.
  84.  
  85.    To provide a point-to-point connection over Ethernet, each PPP
  86.    session must learn the Ethernet address of the remote peer, as well
  87.    as establish a unique session identifier.  PPPoE includes a discovery
  88.    protocol that provides this.
  89.  
  90. 2. Conventions
  91.  
  92.    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  93.    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
  94.    document, are to be interpreted as described in [2].
  95.  
  96. 3. Protocol Overview
  97.  
  98.    PPPoE has two distinct stages.  There is a Discovery stage and a PPP
  99.    Session stage.  When a Host wishes to initiate a PPPoE session, it
  100.    must first perform Discovery to identify the Ethernet MAC address of
  101.    the peer and establish a PPPoE SESSION_ID.  While PPP defines a
  102.    peer-to-peer relationship, Discovery is inherently a client-server
  103.    relationship.  In the Discovery process, a Host (the client)
  104.    discovers an Access Concentrator (the server).  Based on the network
  105.    topology, there may be more than one Access Concentrator that the
  106.    Host can communicate with.  The Discovery stage allows the Host to
  107.    discover all Access Concentrators and then select one.  When
  108.    Discovery completes successfully, both the Host and the selected
  109.    Access Concentrator have the information they will use to build their
  110.    point-to-point connection over Ethernet.
  111.  
  112.  
  113.  
  114. Mamakos, et. al.             Informational                      [Page 2]
  115.  
  116. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  117.  
  118.  
  119.    The Discovery stage remains stateless until a PPP session is
  120.    established.  Once a PPP session is established, both the Host and
  121.    the Access Concentrator MUST allocate the resources for a PPP virtual
  122.    interface.
  123.  
  124. 4. Payloads
  125.  
  126.    The following packet formats are defined here.  The payload contents
  127.    will be defined in the Discovery and PPP sections.
  128.  
  129.    An Ethernet frame is as follows:
  130.  
  131.                                        1
  132.                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  133.                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  134.                   |       DESTINATION_ADDR        |
  135.                   |          (6 octets)           |
  136.                   |                               |
  137.                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  138.                   |         SOURCE_ADDR           |
  139.                   |          (6 octets)           |
  140.                   |                               |
  141.                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.                   |    ETHER_TYPE  (2 octets)     |
  143.                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.                   ~                               ~
  145.                   ~           payload             ~
  146.                   ~                               ~
  147.                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  148.                   |           CHECKSUM            |
  149.                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  150.  
  151.    The DESTINATION_ADDR field contains either a unicast Ethernet
  152.    destination address, or the Ethernet broadcast address (0xffffffff).
  153.    For Discovery packets, the value is either a unicast or broadcast
  154.    address as defined in the Discovery section.  For PPP session
  155.    traffic, this field MUST contain the peer's unicast address as
  156.    determined from the Discovery stage.
  157.  
  158.    The SOURCE_ADDR field MUST contains the Ethernet MAC address of the
  159.    source device.
  160.  
  161.    The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864
  162.    (PPP Session Stage).
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Mamakos, et. al.             Informational                      [Page 3]
  171.  
  172. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  173.  
  174.  
  175.    The Ethernet payload for PPPoE is as follows:
  176.  
  177.                         1                   2                   3
  178.     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
  179.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.    |  VER  | TYPE  |      CODE     |          SESSION_ID           |
  181.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.    |            LENGTH             |           payload             ~
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.  
  185.    The VER field is four bits and MUST be set to 0x1 for this version of
  186.    the PPPoE specification.
  187.  
  188.    The TYPE field is four bits and MUST be set to 0x1 for this version
  189.    of the PPPoE specification.
  190.  
  191.    The CODE field is eight bits and is defined below for the Discovery
  192.    and PPP Session stages.
  193.  
  194.    The SESSION_ID field is sixteen bits.  It is an unsigned value in
  195.    network byte order.  It's value is defined below for Discovery
  196.    packets.  The value is fixed for a given PPP session and, in fact,
  197.    defines a PPP session along with the Ethernet SOURCE_ADDR and
  198.    DESTINATION_ADDR.  A value of 0xffff is reserved for future use and
  199.    MUST NOT be used
  200.  
  201.    The LENGTH field is sixteen bits.  The value, in network byte order,
  202.    indicates the length of the PPPoE payload.  It does not include the
  203.    length of the Ethernet or PPPoE headers.
  204.  
  205. 5. Discovery Stage
  206.  
  207.    There are four steps to the Discovery stage.  When it completes, both
  208.    peers know the PPPoE SESSION_ID and the peer's Ethernet address,
  209.    which together define the PPPoE session uniquely.  The steps consist
  210.    of the Host broadcasting an Initiation packet, one or more Access
  211.    Concentrators sending Offer packets, the Host sending a unicast
  212.    Session Request packet and the selected Access Concentrator sending a
  213.    Confirmation packet.  When the Host receives the Confirmation packet,
  214.    it may proceed to the PPP Session Stage.  When the Access
  215.    Concentrator sends the Confirmation packet, it may proceed to the PPP
  216.    Session Stage.
  217.  
  218.    All Discovery Ethernet frames have the ETHER_TYPE field set to the
  219.    value 0x8863.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Mamakos, et. al.             Informational                      [Page 4]
  227.  
  228. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  229.  
  230.  
  231.    The PPPoE payload contains zero or more TAGs.  A TAG is a TLV (type-
  232.    length-value) construct and is defined as follows:
  233.  
  234.                         1                   2                   3
  235.     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
  236.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  237.    |          TAG_TYPE             |        TAG_LENGTH             |
  238.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.    |          TAG_VALUE ...                                        ~
  240.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.  
  242.    TAG_TYPE is a sixteen bit field in network byte order.  Appendix A
  243.    contains a list of all TAG_TYPEs and their TAG_VALUEs.
  244.  
  245.    TAG_LENGTH is a sixteen bit field.  It is an unsigned number in
  246.    network byte order, indicating the length in octets of the TAG_VALUE.
  247.  
  248.    If a discovery packet is received with a TAG of unknown TAG_TYPE, the
  249.    TAG MUST be ignored unless otherwise specified in this document.
  250.    This provides for backwards compatibility if/when new TAGs are added.
  251.    If new mandatory TAGs are added, the version number will be
  252.    incremented.
  253.  
  254.    Some example Discovery packets are shown in Appendix B.
  255.  
  256. 5.1 The PPPoE Active Discovery Initiation (PADI) packet
  257.  
  258.    The Host sends the PADI packet with the DESTINATION_ADDR set to the
  259.    broadcast address.  The CODE field is set to 0x09 and the SESSION_ID
  260.    MUST be set to 0x0000.
  261.  
  262.    The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-
  263.    Name, indicating the service the Host is requesting, and any number
  264.    of other TAG types.  An entire PADI packet (including the PPPoE
  265.    header) MUST NOT exceed 1484 octets so as to leave sufficient room
  266.    for a relay agent to add a Relay-Session-Id TAG.
  267.  
  268. 5.2 The PPPoE Active Discovery Offer (PADO) packet
  269.  
  270.    When the Access Concentrator receives a PADI that it can serve, it
  271.    replies by sending a PADO packet.  The DESTINATION_ADDR is the
  272.    unicast address of the Host that sent the PADI.  The CODE field is
  273.    set to 0x07 and the SESSION_ID MUST be set to 0x0000.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Mamakos, et. al.             Informational                      [Page 5]
  283.  
  284. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  285.  
  286.  
  287.    The PADO packet MUST contain one AC-Name TAG containing the Access
  288.    Concentrator's name, a Service-Name TAG identical to the one in the
  289.    PADI, and any number of other Service-Name TAGs indicating other
  290.    services that the Access Concentrator offers.  If the Access
  291.    Concentrator can not serve the PADI it MUST NOT respond with a PADO.
  292.  
  293. 5.3 The PPPoE Active Discovery Request (PADR) packet
  294.  
  295.    Since the PADI was broadcast, the Host may receive more than one
  296.    PADO.  The Host looks through the PADO packets it receives and
  297.    chooses one.  The choice can be based on the AC-Name or the Services
  298.    offered.  The Host then sends one PADR packet to the Access
  299.    Concentrator that it has chosen.  The DESTINATION_ADDR field is set
  300.    to the unicast Ethernet address of the Access Concentrator that sent
  301.    the PADO.  The CODE field is set to 0x19 and the SESSION_ID MUST be
  302.    set to 0x0000.
  303.  
  304.    The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-
  305.    Name, indicating the service the Host is requesting, and any number
  306.    of other TAG types.
  307.  
  308. 5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet
  309.  
  310.    When the Access Concentrator receives a PADR packet, it prepares to
  311.    begin a PPP session.  It generates a unique SESSION_ID for the PPPoE
  312.    session and replies to the Host with a PADS packet.  The
  313.    DESTINATION_ADDR field is the unicast Ethernet address of the Host
  314.    that sent the PADR.  The CODE field is set to 0x65 and the SESSION_ID
  315.    MUST be set to the unique value generated for this PPPoE session.
  316.  
  317.    The PADS packet contains exactly one TAG of TAG_TYPE Service-Name,
  318.    indicating the service under which Access Concentrator has accepted
  319.    the PPPoE session, and any number of other TAG types.
  320.  
  321.    If the Access Concentrator does not like the Service-Name in the
  322.    PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE
  323.    Service-Name-Error (and any number of other TAG types).  In this case
  324.    the SESSION_ID MUST be set to 0x0000.
  325.  
  326. 5.5 The PPPoE Active Discovery Terminate (PADT) packet
  327.  
  328.    This packet may be sent anytime after a session is established to
  329.    indicate that a PPPoE session has been terminated.  It may be sent by
  330.    either the Host or the Access Concentrator.  The DESTINATION_ADDR
  331.    field is a unicast Ethernet address, the CODE field is set to 0xa7
  332.    and the SESSION_ID MUST be set to indicate which session is to be
  333.    terminated.  No TAGs are required.
  334.  
  335.  
  336.  
  337.  
  338. Mamakos, et. al.             Informational                      [Page 6]
  339.  
  340. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  341.  
  342.  
  343.    When a PADT is received, no further PPP traffic is allowed to be sent
  344.    using that session.  Even normal PPP termination packets MUST NOT be
  345.    sent after sending or receiving a PADT.  A PPP peer SHOULD use the
  346.    PPP protocol itself to bring down a PPPoE session, but the PADT MAY
  347.    be used when PPP can not be used.
  348.  
  349. 6. PPP Session Stage
  350.  
  351.    Once the PPPoE session begins, PPP data is sent as in any other PPP
  352.    encapsulation.  All Ethernet packets are unicast.  The ETHER_TYPE
  353.    field is set to 0x8864.  The PPPoE CODE MUST be set to 0x00.  The
  354.    SESSION_ID MUST NOT change for that PPPoE session and MUST be the
  355.    value assigned in the Discovery stage.  The PPPoE payload contains a
  356.    PPP frame.  The frame begins with the PPP Protocol-ID.
  357.  
  358.    An example packet is shown in Appendix B.
  359.  
  360. 7. LCP Considerations
  361.  
  362.    The Magic Number LCP configuration option is RECOMMENDED, and the
  363.    Protocol Field Compression (PFC) option is NOT RECOMMENDED.  An
  364.    implementation MUST NOT request any of the following options, and
  365.    MUST reject a request for such an option:
  366.  
  367.       Field Check Sequence (FCS) Alternatives,
  368.  
  369.       Address-and-Control-Field-Compression (ACFC),
  370.  
  371.       Asynchronous-Control-Character-Map (ACCM)
  372.  
  373.    The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
  374.    larger size than 1492.  Since Ethernet has a maximum payload size of
  375.    1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
  376.    2 octets, the PPP MTU MUST NOT be greater than 1492.
  377.  
  378.    It is RECOMMENDED that the Access Concentrator ocassionally send
  379.    Echo-Request packets to the Host to determine the state of the
  380.    session.  Otherwise, if the Host terminates a session without sending
  381.    a Terminate-Request packet, the Access Concentrator will not be able
  382.    to determine that the session has gone away.
  383.  
  384.    When LCP terminates, the Host and Access concentrator MUST stop using
  385.    that PPPoE session.  If the Host wishes to start another PPP session,
  386.    it MUST return to the PPPoE Discovery stage.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Mamakos, et. al.             Informational                      [Page 7]
  395.  
  396. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  397.  
  398.  
  399. 8. Other Considerations
  400.  
  401.    When a host does not receive a PADO packet within a specified amount
  402.    of time, it SHOULD resend it's PADI packet and double the waiting
  403.    period. This is repeated as many times as desired.  If the Host is
  404.    waiting to receive a PADS packet, a similar timeout mechanism SHOULD
  405.    be used, with the Host re-sending the PADR.  After a specified number
  406.    of retries, the Host SHOULD then resend a PADI packet.
  407.  
  408.    The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been
  409.    assigned by the IEEE for use by PPP Over Ethernet (PPPoE).  Use of
  410.    these values and the PPPoE VER (version) field uniquely identify this
  411.    protocol.
  412.  
  413.    UTF-8 [5] is used throughout this document instead of ASCII.  UTF-8
  414.    supports the entire ASCII character set while allowing for
  415.    international character sets as well.  See [5] for more details.
  416.  
  417. 9. Security Considerations
  418.  
  419.    To help protect against Denial of Service (DOS) attacks, the Access
  420.    Concentrator can employ the AC-Cookie TAG.  The Access Concentrator
  421.    SHOULD be able to uniquely regenerate the TAG_VALUE based on the PADR
  422.    SOURCE_ADDR.  Using this, the Access Concentrator can ensure that the
  423.    PADI SOURCE_ADDR is indeed reachable and can then limit concurrent
  424.    sessions for that address.  What algorithm to use is not defined and
  425.    left as an implementation detail.  An example is HMAC [3] over the
  426.    Host MAC address using a key known only to the Access > Concentrator.
  427.    While the AC-Cookie is useful against some DOS attacks, it can not
  428.    protect against all DOS attacks and an Access Concentrator MAY employ
  429.    other means to protect resources.
  430.  
  431.    While the AC-Cookie is useful against some DOS attacks, it can not
  432.    protect against all DOS attacks and an Access Concentrator MAY employ
  433.    other means to protect resources.
  434.  
  435.    Many Access Concentrators will not wish to offer information
  436.    regarding what services they offer to an unauthenticated entity.  In
  437.    that case the Access Concentrator should employ one of two policies.
  438.    It SHOULD never refuse a request based on the Service-Name TAG, and
  439.    always return the TAG_VALUE that was sent to it.  Or it SHOULD only
  440.    accept requests with a Service-Name TAG with a zero TAG_LENGTH
  441.    (indicating any service).  The former solution is RECOMMENDED.
  442.  
  443. 10. Acknowledgments
  444.  
  445.    This document is based on concepts discussed in several forums,
  446.    including the ADSL forum.
  447.  
  448.  
  449.  
  450. Mamakos, et. al.             Informational                      [Page 8]
  451.  
  452. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  453.  
  454.  
  455.    Copious amounts of text have been stolen from RFC 1661, RFC 1662 and
  456.    RFC 2364.
  457.  
  458. 11. References
  459.  
  460.    [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
  461.        RFC 1661, July 1994
  462.  
  463.    [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  464.        Levels", BCP 14, RFC 2119, March 1997.
  465.  
  466.    [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
  467.        for Message Authentication", RFC 2104, February 1998.
  468.  
  469.    [4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  470.        October 1994.  See also: http://www.iana.org/numbers.html
  471.  
  472.    [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
  473.        2279, January 1998.
  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. Mamakos, et. al.             Informational                      [Page 9]
  507.  
  508. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  509.  
  510.  
  511. Appendix A
  512.  
  513.    TAG_TYPES and TAG_VALUES
  514.  
  515.    0x0000 End-Of-List
  516.  
  517.       This TAG indicates that there are no further TAGs in the list. The
  518.       TAG_LENGTH of this TAG MUST always be zero.  Use of this TAG is
  519.       not required, but remains for backwards compatibility.
  520.  
  521.    0x0101 Service-Name
  522.  
  523.       This TAG indicates that a service name follows.  The TAG_VALUE is
  524.       an UTF-8 string that is NOT NULL terminated. When the TAG_LENGTH
  525.       is zero this TAG is used to indicate that any service is
  526.       acceptable.  Examples of the use of the Service-Name TAG are to
  527.       indicate an ISP name or a class or quality of service.
  528.  
  529.    0x0102 AC-Name
  530.  
  531.       This TAG indicates that a string follows which uniquely identifies
  532.       this particular Access Concentrator unit from all others. It may
  533.       be a combination of trademark, model, and serial id information,
  534.       or simply an UTF-8 rendition of the MAC address of the box.  It is
  535.       not NULL terminated.
  536.  
  537.    0x0103 Host-Uniq
  538.  
  539.       This TAG is used by a Host to uniquely associate an Access
  540.       Concentrator response (PADO or PADS) to a particular Host request
  541.       (PADI or PADR).  The TAG_VALUE is binary data of any value and
  542.       length that the Host chooses.  It is not interpreted by the Access
  543.       Concentrator.  The Host MAY include a Host-Uniq TAG in a PADI or
  544.       PADR.  If the Access Concentrator receives this TAG, it MUST
  545.       include the TAG unmodified in the associated PADO or PADS
  546.       response.
  547.  
  548.    0x0104 AC-Cookie
  549.  
  550.       This TAG is used by the Access Concentrator to aid in protecting
  551.       against denial of service attacks (see the Security Considerations
  552.       section for an explanation of how this works).  The Access
  553.       Concentrator MAY include this TAG in a PADO packet.  If a Host
  554.       receives this TAG, it MUST return the TAG unmodified in the
  555.       following PADR.  The TAG_VALUE is binary data of any value and
  556.       length and is not interpreted by the Host.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Mamakos, et. al.             Informational                     [Page 10]
  563.  
  564. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  565.  
  566.  
  567.    0x0105 Vendor-Specific
  568.  
  569.       This TAG is used to pass vendor proprietary information.  The
  570.       first four octets of the TAG_VALUE contain the vendor id and the
  571.       remainder is unspecified.  The high-order octet of the vendor id
  572.       is 0 and the low-order 3 octets are the SMI Network Management
  573.       Private Enterprise Code of the Vendor in network byte order, as
  574.       defined in the Assigned Numbers RFC [4].
  575.  
  576.       Use of this TAG is NOT RECOMMENDED.  To ensure inter-operability,
  577.       an implementation MAY silently ignore a Vendor-Specific TAG.
  578.  
  579.    0x0110 Relay-Session-Id
  580.  
  581.       This TAG MAY be added to any discovery packet by an intermediate
  582.       agent that is relaying traffic.  The TAG_VALUE is opaque to both
  583.       the Host and the Access Concentrator.  If either the Host or
  584.       Access Concentrator receives this TAG they MUST include it
  585.       unmodified in any discovery packet they send as a response.  All
  586.       PADI packets MUST guarantee sufficient room for the addition of a
  587.       Relay-Session-Id TAG with a TAG_VALUE length of 12 octets.
  588.  
  589.       A Relay-Session-Id TAG MUST NOT be added if the discovery packet
  590.       already contains one.  In that case the intermediate agent SHOULD
  591.       use the existing Relay-Session-Id TAG.  If it can not use the
  592.       existing TAG or there is insufficient room to add a Relay-
  593.       Session-Id TAG, then it SHOULD return a Generic-Error TAG to the
  594.       sender.
  595.  
  596.    0x0201 Service-Name-Error
  597.  
  598.       This TAG (typically with a zero-length data section) indicates
  599.       that for one reason or another, the requested Service-Name request
  600.       could not be honored.
  601.  
  602.       If there is data, and the first octet of the data is nonzero, then
  603.       it MUST be a printable UTF-8 string which explains why the request
  604.       was denied.  This string MAY NOT be NULL terminated.
  605.  
  606.    0x0202 AC-System-Error
  607.  
  608.       This TAG indicates that the Access Concentrator experienced some
  609.       error in performing the Host request.  (For example insufficient
  610.       resources to create a virtual circuit.)  It MAY be included in
  611.       PADS packets.
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Mamakos, et. al.             Informational                     [Page 11]
  619.  
  620. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  621.  
  622.  
  623.       If there is data, and the first octet of the data is nonzero, then
  624.       it MUST be a printable UTF-8 string which explains the nature of
  625.       the error.  This string MAY NOT be NULL terminated.
  626.  
  627.    0x0203 Generic-Error
  628.  
  629.       This TAG indicates an error.  It can be added to PADO, PADR or
  630.       PADS packets when an unrecoverable error occurs and no other error
  631.       TAG is appropriate.  If there is data then it MUST be an UTF-8
  632.       string which explains the nature of the error.  This string MUST
  633.       NOT be NULL terminated.
  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. Mamakos, et. al.             Informational                     [Page 12]
  675.  
  676. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  677.  
  678.  
  679. Appendix B
  680.  
  681.    The following are some example packets:
  682.  
  683.    A PADI packet:
  684.  
  685.                            1                   2                   3
  686.        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
  687.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  688.       |                         0xffffffff                            |
  689.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  690.       |           0xffff              |        Host_mac_addr          |
  691.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  692.       |                    Host_mac_addr (cont)                       |
  693.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  694.       |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0x09  |
  695.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  696.       |     SESSION_ID = 0x0000       |      LENGTH = 0x0004          |
  697.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  698.       |      TAG_TYPE = 0x0101        |    TAG_LENGTH = 0x0000        |
  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. Mamakos, et. al.             Informational                     [Page 13]
  731.  
  732. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  733.  
  734.  
  735.    A PADO packet:
  736.  
  737.                            1                   2                   3
  738.        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
  739.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  740.       |                         Host_mac_addr                         |
  741.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  742.       |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
  743.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  744.       |             Access_Concentrator_mac_addr (cont)               |
  745.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  746.       |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0x07  |
  747.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  748.       |     SESSION_ID = 0x0000       |      LENGTH = 0x0020          |
  749.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  750.       |      TAG_TYPE = 0x0101        |    TAG_LENGTH = 0x0000        |
  751.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  752.       |      TAG_TYPE = 0x0102        |    TAG_LENGTH = 0x0018        |
  753.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  754.       |     0x47      |     0x6f      |     0x20      |     0x52      |
  755.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  756.       |     0x65      |     0x64      |     0x42      |     0x61      |
  757.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  758.       |     0x63      |     0x6b      |     0x20      |     0x2d      |
  759.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  760.       |     0x20      |     0x65      |     0x73      |     0x68      |
  761.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  762.       |     0x73      |     0x68      |     0x65      |     0x73      |
  763.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  764.       |     0x68      |     0x6f      |     0x6f      |     0x74      |
  765.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Mamakos, et. al.             Informational                     [Page 14]
  787.  
  788. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  789.  
  790.  
  791.    A PPP LCP packet:  The PPP protocol value is shown (0xc021) but the
  792.    PPP payload is left to the reader.  This is a packet from the Host to
  793.    the Access Concentrator.
  794.  
  795.                            1                   2                   3
  796.        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
  797.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  798.       |                  Access_Concentrator_mac_addr                 |
  799.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  800.       |Access_Concentrator_mac_addr(c)|        Host_mac_addr          |
  801.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  802.       |                     Host_mac_addr (cont)                      |
  803.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  804.       |    ETHER_TYPE = 0x8864        | v = 1 | t = 1 |  CODE = 0x00  |
  805.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  806.       |     SESSION_ID = 0x1234       |      LENGTH = 0x????          |
  807.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  808.       |    PPP PROTOCOL = 0xc021      |        PPP payload            ~
  809.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  810.  
  811. Authors'  Addresses
  812.  
  813.    Louis Mamakos
  814.    UUNET Technologies, Inc.
  815.    3060 Williams Drive
  816.    Fairfax, VA  22031-4648
  817.    United States of America
  818.  
  819.    EMail: louie@uu.net
  820.  
  821.  
  822.    Kurt Lidl
  823.    UUNET Technologies, Inc.
  824.    3060 Williams Drive
  825.    Fairfax, VA  22031-4648
  826.    United States of America
  827.  
  828.    EMail: lidl@uu.net
  829.  
  830.  
  831.    Jeff Evarts
  832.    UUNET Technologies, Inc.
  833.    3060 Williams Drive
  834.    Fairfax, VA  22031-4648
  835.    United States of America
  836.  
  837.    EMail: jde@uu.net
  838.  
  839.  
  840.  
  841.  
  842. Mamakos, et. al.             Informational                     [Page 15]
  843.  
  844. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  845.  
  846.  
  847.    David Carrel
  848.    RedBack Networks, Inc.
  849.    1389 Moffett Park Drive
  850.    Sunnyvale, CA  94089-1134
  851.    United States of America
  852.  
  853.    EMail: carrel@RedBack.net
  854.  
  855.  
  856.    Dan Simone
  857.    RedBack Networks, Inc.
  858.    1389 Moffett Park Drive
  859.    Sunnyvale, CA  94089-1134
  860.    United States of America
  861.  
  862.    EMail:dan@RedBack.net
  863.  
  864.  
  865.    Ross Wheeler
  866.    RouterWare, Inc.
  867.    3961 MacArthur Blvd., Suite 212
  868.    Newport Beach, CA  92660
  869.    United States of America
  870.  
  871.    EMail: ross@routerware.com
  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. Mamakos, et. al.             Informational                     [Page 16]
  899.  
  900. RFC 2516             Transmitting PPP Over Ethernet        February 1999
  901.  
  902.  
  903. Full Copyright Statement
  904.  
  905.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  906.  
  907.    This document and translations of it may be copied and furnished to
  908.    others, and derivative works that comment on or otherwise explain it
  909.    or assist in its implementation may be prepared, copied, published
  910.    and distributed, in whole or in part, without restriction of any
  911.    kind, provided that the above copyright notice and this paragraph are
  912.    included on all such copies and derivative works.  However, this
  913.    document itself may not be modified in any way, such as by removing
  914.    the copyright notice or references to the Internet Society or other
  915.    Internet organizations, except as needed for the purpose of
  916.    developing Internet standards in which case the procedures for
  917.    copyrights defined in the Internet Standards process must be
  918.    followed, or as required to translate it into languages other than
  919.    English.
  920.  
  921.    The limited permissions granted above are perpetual and will not be
  922.    revoked by the Internet Society or its successors or assigns.
  923.  
  924.    This document and the information contained herein is provided on an
  925.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  926.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  927.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  928.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  929.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  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. Mamakos, et. al.             Informational                     [Page 17]
  955.  
  956.