Network Working Group

Request for Comments: 2516

A Method for Transmitting PPP Over Ethernet (PPPoE)

Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (1999).

All Rights Reserved.

AbstractThe Point-to-Point Protocol (PPP) [1] provides a standard method fortransporting multi-protocol datagrams over point-to-point links.This document describes how to build PPP sessions and encapsulate PPPpackets over Ethernet.ApplicabilityThis specification is intended to provide the facilities which aredefined for PPP, such as the Link Control Protocol, Network-layerControl Protocols, authentication, and more. These capabilitiesrequire a point-to-point relationship between the peers, and are notdesigned for the multi-point relationships which are available inEthernet 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 ormore bridging modems. It is intended to be used with broadbandremote access technologies that provide a bridged Ethernet topology,when access providers wish to maintain the session abstractionassociated 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. IntroductionModern access technologies are faced with several conflicting goals.It is desirable to connect multiple hosts at a remote site throughthe same customer premise access device. It is also a goal toprovide access control and billing functionality in a manner similarto dial-up services using PPP. In many access technologies, the mostcost effective method to attach multiple hosts to the customerpremise access device, is via Ethernet. In addition, it is desirableto keep the cost of this device as low as possible while requiringlittle or no configuration.PPP over Ethernet (PPPoE) provides the ability to connect a networkof hosts over a simple bridging access device to a remote AccessConcentrator. With this model, each host utilizes its own PPP stackand the user is presented with a familiar user interface. Accesscontrol, 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 PPPsession must learn the Ethernet address of the remote peer, as wellas establish a unique session identifier. PPPoE includes a discoveryprotocol that provides this.2. ConventionsThe keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in thisdocument, are to be interpreted as described in [2].3. Protocol OverviewPPPoE has two distinct stages. There is a Discovery stage and a PPPSession stage. When a Host wishes to initiate a PPPoE session, itmust first perform Discovery to identify the Ethernet MAC address ofthe peer and establish a PPPoE SESSION_ID. While PPP defines apeer-to-peer relationship, Discovery is inherently a client-serverrelationship. In the Discovery process, a Host (the client)discovers an Access Concentrator (the server). Based on the networktopology, there may be more than one Access Concentrator that theHost can communicate with. The Discovery stage allows the Host todiscover all Access Concentrators and then select one. WhenDiscovery completes successfully, both the Host and the selectedAccess Concentrator have the information they will use to build theirpoint-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 andthe Access Concentrator MUST allocate the resources for a PPP virtualinterface.4. PayloadsThe following packet formats are defined here. The payload contentswill be defined in the Discovery and PPP sections.An Ethernet frame is as follows:10 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 Ethernetdestination address, or the Ethernet broadcast address (0xffffffff).For Discovery packets, the value is either a unicast or broadcastaddress as defined in the Discovery section. For PPP sessiontraffic, this field MUST contain the peers unicast address asdetermined from the Discovery stage.The SOURCE_ADDR field MUST contains the Ethernet MAC address of thesource 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:

1230 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 ofthe PPPoE specification.The TYPE field is four bits and MUST be set to 0x1 for this versionof the PPPoE specification.The CODE field is eight bits and is defined below for the Discoveryand PPP Session stages.The SESSION_ID field is sixteen bits. It is an unsigned value innetwork byte order. Its value is defined below for Discoverypackets. The value is fixed for a given PPP session and, in fact,defines a PPP session along with the Ethernet SOURCE_ADDR andDESTINATION_ADDR. A value of 0xffff is reserved for future use andMUST NOT be usedThe LENGTH field is sixteen bits. The value, in network byte order,indicates the length of the PPPoE payload. It does not include thelength of the Ethernet or PPPoE headers.5. Discovery StageThere are four steps to the Discovery stage. When it completes, bothpeers know the PPPoE SESSION_ID and the peers Ethernet address,which together define the PPPoE session uniquely. The steps consistof the Host broadcasting an Initiation packet, one or more AccessConcentrators sending Offer packets, the Host sending a unicastSession Request packet and the selected Access Concentrator sending aConfirmation packet. When the Host receives the Confirmation packet,it may proceed to the PPP Session Stage. When the AccessConcentrator sends the Confirmation packet, it may proceed to the PPPSession Stage.All Discovery Ethernet frames have the ETHER_TYPE field set to thevalue 0x8863.

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, theTAG 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 beincremented.Some example Discovery packets are shown in Appendix B.5.1 The PPPoE Active Discovery Initiation (PADI) packetThe Host sends the PADI packet with the DESTINATION_ADDR set to thebroadcast address. The CODE field is set to 0x09 and the SESSION_IDMUST be set to 0x0000.The PADI packet MUST contain exactly one TAG of TAG_TYPE ServiceName, indicating the service the Host is requesting, and any numberof other TAG types. An entire PADI packet (including the PPPoEheader) MUST NOT exceed 1484 octets so as to leave sufficient roomfor a relay agent to add a Relay-Session-Id TAG.5.2 The PPPoE Active Discovery Offer (PADO) packetWhen the Access Concentrator receives a PADI that it can serve, itreplies by sending a PADO packet. The DESTINATION_ADDR is theunicast address of the Host that sent the PADI. The CODE field isset 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 AccessConcentrators name, a Service-Name TAG identical to the one in thePADI, and any number of other Service-Name TAGs indicating otherservices that the Access Concentrator offers. If the AccessConcentrator can not serve the PADI it MUST NOT respond with a PADO.5.3 The PPPoE Active Discovery Request (PADR) packetSince the PADI was broadcast, the Host may receive more than onePADO. The Host looks through the PADO packets it receives andchooses one. The choice can be based on the AC-Name or the Servicesoffered. The Host then sends one PADR packet to the AccessConcentrator that it has chosen. The DESTINATION_ADDR field is setto the unicast Ethernet address of the Access Concentrator that sentthe PADO. The CODE field is set to 0x19 and the SESSION_ID MUST beset to 0x0000.The PADR packet MUST contain exactly one TAG of TAG_TYPE ServiceName, indicating the service the Host is requesting, and any numberof other TAG types.5.4 The PPPoE Active Discovery Session-confirmation (PADS) packetWhen the Access Concentrator receives a PADR packet, it prepares tobegin a PPP session. It generates a unique SESSION_ID for the PPPoEsession and replies to the Host with a PADS packet. TheDESTINATION_ADDR field is the unicast Ethernet address of the Hostthat sent the PADR. The CODE field is set to 0x65 and the SESSION_IDMUST 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 acceptedthe PPPoE session, and any number of other TAG types.If the Access Concentrator does not like the Service-Name in thePADR, then it MUST reply with a PADS containing a TAG of TAG_TYPEService-Name-Error (and any number of other TAG types). In this casethe SESSION_ID MUST be set to 0x0000.5.5 The PPPoE Active Discovery Terminate (PADT) packetThis packet may be sent anytime after a session is established toindicate that a PPPoE session has been terminated. It may be sent byeither the Host or the Access Concentrator. The DESTINATION_ADDRfield is a unicast Ethernet address, the CODE field is set to 0xa7and the SESSION_ID MUST be set to indicate which session is to beterminated. 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 besent after sending or receiving a PADT. A PPP peer SHOULD use thePPP protocol itself to bring down a PPPoE session, but the PADT MAYbe used when PPP can not be used.6. PPP Session StageOnce the PPPoE session begins, PPP data is sent as in any other PPPencapsulation. All Ethernet packets are unicast. The ETHER_TYPEfield is set to 0x8864. The PPPoE CODE MUST be set to 0x00. TheSESSION_ID MUST NOT change for that PPPoE session and MUST be thevalue assigned in the Discovery stage. The PPPoE payload contains aPPP frame. The frame begins with the PPP Protocol-ID.An example packet is shown in Appendix B.7. LCP ConsiderationsThe Magic Number LCP configuration option is RECOMMENDED, and theProtocol Field Compression (PFC) option is NOT RECOMMENDED. Animplementation MUST NOT request any of the following options, andMUST 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 alarger size than 1492. Since Ethernet has a maximum payload size of1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is2 octets, the PPP MTU MUST NOT be greater than 1492.It is RECOMMENDED that the Access Concentrator ocassionally sendEcho-Request packets to the Host to determine the state of thesession. Otherwise, if the Host terminates a session without sendinga Terminate-Request packet, the Access Concentrator will not be ableto determine that the session has gone away.When LCP terminates, the Host and Access concentrator MUST stop usingthat 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 ConsiderationsWhen a host does not receive a PADO packet within a specified amountof time, it SHOULD resend its PADI packet and double the waitingperiod. This is repeated as many times as desired. If the Host iswaiting to receive a PADS packet, a similar timeout mechanism SHOULDbe used, with the Host re-sending the PADR. After a specified numberof retries, the Host SHOULD then resend a PADI packet.The ETHER_TYPEs used in this document (0x8863 and 0x8864) have beenassigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use ofthese values and the PPPoE VER (version) field uniquely identify thisprotocol.UTF-8 [5] is used throughout this document instead of ASCII. UTF-8supports the entire ASCII character set while allowing forinternational character sets as well. See [5] for more details.9. Security ConsiderationsTo help protect against Denial of Service (DOS) attacks, the AccessConcentrator can employ the AC-Cookie TAG. The Access ConcentratorSHOULD be able to uniquely regenerate the TAG_VALUE based on the PADRSOURCE_ADDR. Using this, the Access Concentrator can ensure that thePADI SOURCE_ADDR is indeed reachable and can then limit concurrentsessions for that address. What algorithm to use is not defined andleft as an implementation detail. An example is HMAC [3] over theHost MAC address using a key known only to the Access > Concentrator.While the AC-Cookie is useful against some DOS attacks, it can notprotect against all DOS attacks and an Access Concentrator MAY employother means to protect resources.While the AC-Cookie is useful against some DOS attacks, it can notprotect against all DOS attacks and an Access Concentrator MAY employother means to protect resources.Many Access Concentrators will not wish to offer informationregarding what services they offer to an unauthenticated entity. Inthat case the Access Concentrator should employ one of two policies.It SHOULD never refuse a request based on the Service-Name TAG, andalways return the TAG_VALUE that was sent to it. Or it SHOULD onlyaccept requests with a Service-Name TAG with a zero TAG_LENGTH(indicating any service). The former solution is RECOMMENDED.10. AcknowledgmentsThis document is based on concepts discussed in several forums,including the ADSL forum.

Mamakos, et. al.

Informational

[Page 9]

RFC 2516

Transmitting PPP Over Ethernet

February 1999

Appendix ATAG_TYPES and TAG_VALUES0x0000 End-Of-ListThis TAG indicates that there are no further TAGs in the list. TheTAG_LENGTH of this TAG MUST always be zero. Use of this TAG isnot required, but remains for backwards compatibility.0x0101 Service-NameThis TAG indicates that a service name follows. The TAG_VALUE isan UTF-8 string that is NOT NULL terminated. When the TAG_LENGTHis zero this TAG is used to indicate that any service isacceptable. Examples of the use of the Service-Name TAG are toindicate an ISP name or a class or quality of service.0x0102 AC-NameThis TAG indicates that a string follows which uniquely identifiesthis particular Access Concentrator unit from all others. It maybe a combination of trademark, model, and serial id information,or simply an UTF-8 rendition of the MAC address of the box. It isnot NULL terminated.0x0103 Host-UniqThis TAG is used by a Host to uniquely associate an AccessConcentrator response (PADO or PADS) to a particular Host request(PADI or PADR). The TAG_VALUE is binary data of any value andlength that the Host chooses. It is not interpreted by the AccessConcentrator. The Host MAY include a Host-Uniq TAG in a PADI orPADR. If the Access Concentrator receives this TAG, it MUSTinclude the TAG unmodified in the associated PADO or PADSresponse.0x0104 AC-CookieThis TAG is used by the Access Concentrator to aid in protectingagainst denial of service attacks (see the Security Considerationssection for an explanation of how this works). The AccessConcentrator MAY include this TAG in a PADO packet. If a Hostreceives this TAG, it MUST return the TAG unmodified in thefollowing PADR. The TAG_VALUE is binary data of any value andlength and is not interpreted by the Host.

Mamakos, et. al.

Informational

[Page 10]

RFC 2516

Transmitting PPP Over Ethernet

February 1999

0x0105 Vendor-SpecificThis TAG is used to pass vendor proprietary information. Thefirst four octets of the TAG_VALUE contain the vendor id and theremainder is unspecified. The high-order octet of the vendor idis 0 and the low-order 3 octets are the SMI Network ManagementPrivate Enterprise Code of the Vendor in network byte order, asdefined 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-IdThis TAG MAY be added to any discovery packet by an intermediateagent that is relaying traffic. The TAG_VALUE is opaque to boththe Host and the Access Concentrator. If either the Host orAccess Concentrator receives this TAG they MUST include itunmodified in any discovery packet they send as a response. AllPADI packets MUST guarantee sufficient room for the addition of aRelay-Session-Id TAG with a TAG_VALUE length of 12 octets.A Relay-Session-Id TAG MUST NOT be added if the discovery packetalready contains one. In that case the intermediate agent SHOULDuse the existing Relay-Session-Id TAG. If it can not use theexisting TAG or there is insufficient room to add a RelaySession-Id TAG, then it SHOULD return a Generic-Error TAG to thesender.0x0201 Service-Name-ErrorThis TAG (typically with a zero-length data section) indicatesthat for one reason or another, the requested Service-Name requestcould not be honored.If there is data, and the first octet of the data is nonzero, thenit MUST be a printable UTF-8 string which explains why the requestwas denied. This string MAY NOT be NULL terminated.0x0202 AC-System-ErrorThis TAG indicates that the Access Concentrator experienced someerror in performing the Host request. (For example insufficientresources to create a virtual circuit.) It MAY be included inPADS 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, thenit MUST be a printable UTF-8 string which explains the nature ofthe error. This string MAY NOT be NULL terminated.0x0203 Generic-ErrorThis TAG indicates an error. It can be added to PADO, PADR orPADS packets when an unrecoverable error occurs and no other errorTAG is appropriate. If there is data then it MUST be an UTF-8string which explains the nature of the error. This string MUSTNOT be NULL terminated.

Mamakos, et. al.

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 itor assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph areincluded on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.