rfc2516.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.