PPP over Ethernet (PPPoE) Interface
Table of Contents >> Optional Protocols
Contents
PPPoE Description
Treck PPPoE is a Treck TCP/IP option that enables a user to connect to an ISP provider that requires the use of PPP over Ethernet (or PPPoE), identified as PPPoE client. The PPPoE server (Access Concentrator) functionality is implemented for testing the PPPoE client only; it is not as a product.
General Description of PPPoE
PPPoE allows ISPs to use their existing authentication, authorization, accounting (AAA) system (i.e. Radius, etc.), previously deployed on their dial up service, on a broadband connection. PPP is for dial up service, most broadband connections are on Ethernet, hence PPP over Ethernet. The ISPs can use PPP for billing and to grant access per user (not site).It allows them to resell the same line multiple times for rated services, metered services, etc. PPPoE allows multiple hosts to connect to an access concentrator over a simple bridging access device. The hosts run the PPPoE client, and the Access concentrator runs the PPPoE server. Each connecting host has to have its own PPP stack. Each host has a point-to-point connection over Ethernet.
Figure 1: Typical PPP over Ethernet Topology
To provide a point-to-point connection over Ethernet, each PPPoE session must learn the Ethernet address of the remote peer, as well as establish a unique session identifier. PPPoE includes a discovery protocol that allows the PPPoE client to discover the remote Ethernet address, and the unique session ID. PPPoE has two distinct stages, a discovery stage and a PPP session stage. In the discovery stage, a host (the client) discovers an Access Concentrator (the server). When a host client initiates a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID. There may be more than one Access Concentrator. The discovery process allows the client to discover all Access Concentrators, and then select one. When Discovery completes successfully, both the host and the Access Concentrator have the information necessary to build their PPP connection over Ethernet, and thus enter the PPP session stage. The discovery stage remains stateless until a PPP session is established. Once a PPP session is established, both the host and the concentrator must allocate the resources for a PPP virtual interface.
PPPoE Discovery phase
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 host broadcasts an initiation packet (PADI)
- One or more Access Concentrators send an offer packet (PADO)
- The host sends a unicast session request packet (PADR) to the chosen Access Concentrator
- The Access Concentrator sends a confirmation packet (PADS) to the host, and moves to the PPP session stage.
Upon receiving the PADS, the host moves to the PPP session stage. PPPoE packets are sent in an Ethernet frame as explained in the Ethernet payload section below.
 Note:
|
Packet examples can be found in RFC 2516. |
PPPoE PPP session phase
Once the PPPoE PPP session begins, PPP data is sent on the connection in an Ethernet frame. The Ethernet payload is a PPPoE packet as explained in the Ethernet payload section below. The PPPoE payload contains a PPP frame which starts with the PPP protocol ID.
PPPoE termination
A PADT (PPPoE termination) packet can be sent at any time after a PPP session is established to indicate that a PPPoE session has been terminated. It may be sent by either the host or Access Concentrator. When a PADT is sent no further traffic is allowed. 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 cannot be used.
Ethernet payload
PPPoE Discovery phase and PPPoE PPP session phase packets travel as payload in an Ethernet frame. The Ethernet payload for PPPoE always start with a version field, type field code field, session ID and length as shown below.
Figure 2: Ethernet frame with payload
Figure 3: Ethernet field values
Figure 4: Ethernet payload for PPPoE
Figure 5: PPPoE field values
PPPoE payload in discovery phase
The PPPoE payload contains zero or more tags. A tag is a TLV (type-length-value) construct and is defined as follows:
.gif)
Figure 6: One Tag(in PPPoE payload in discovery phase)
RFC 2516 Appendix A contains a list of TAG_TYPE and associated TAG_VALUE
Figure 7: PPPoE payload in discovery phase
PPP LCP options
| PPP LCP options | in PPPoE packets |
| Magic Number LCP configuration option | Recommended |
| Protocol Field Compression option | Not Recommended |
| Field Check Sequence (FCS) Alternatives options | MUST NOT REQUEST, and MUST REJECT |
| Address-and-Control-Field-Compression (ACFC) | MUST NOT REQUEST, and MUST REJECT |
| Maximum-Receive-Unit (MRU) option | MUST NOT be NEGOTIATED to a larger size than 1492 (to leave room for PPPoE header (6bytes), and the PPP protocol ID (2 bytes) |
PPP LCP termination
- It is recommended that the Access Concentrator occasionally send LCP Echo-Request packets to the host to determine the state of the PPP session, so that the Access Concentrator can determine whether the host has terminated without sending an LCP terminate request packet
- When LCP terminated, 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 phase.
Host PADI, and Host PADR packet retransmission
- PADI timeout. The host should use a timeout mechanism to re-send the PADI, if it does not receive a response from the Access Concentrator. It should double the waiting period. This is repeated as many times as desired.
- PADR timeout. Similarly the host should use a timeout mechanism to re-send the PADR, if it does not receive a response from the Access Concentrator. After a specified number of retries, the host should resend a PADI packet, if it does not receive a response to the PADR packet.
Security Considerations
- To help against DOS (Denial of Service) attacks, the Access Concentrator can employ the AC-Cookie Tag.
- Many Access Concentrators will not wish to offer information regarding what services they offer to an unauthenticated entity. This can be enforced in one of 2 ways:
- It should never refuse a request based on the Service-Name Tag, and always return the TAG_VALUE that was sent to it. (Recommended)
- Or it should only accept requests with Service-Name Tag with a zero TAG_LENGTH (indicating any service).
Treck PPPoE Client
Compile time PPPoE Client configuration
Enabling PPPoE Client
To enable the PPPoE Client code, you must define TM_USE_PPPOE_CLIENT in <trsystem.h>.
PPPoE Client default option values
The user can overwrite the default values for the following PPPoE client options, by either re-defining the macro(s) in <trsystem.h> to a different value, or by calling tfPppoeSetOption() as described in the following section.
| PPPoE macro | Meaning | Default Value |
| TM_PPPOE_PADI_RETRIES_MAX | Client default PADI maximum number of retries | 4 |
| TM_PPPOE_INITIAL_RETRY_WAIT | Client default PADI or PADR initial waiting period before the first retry in milliseconds | 1,000ms |
| TM_PPPOE_PADR_RETRIES_MAX | Client default PADR maximum number of retries | 4 |
| TM_PPPOE_DISC_RETRIES_MAX | Client default maximum number of times we will retry the discovery phase because the server did not respond to our PADR packets | 1 |
Run time configuration tfPppoeSetOption
tfPppoeSetOption() is a new User API provided to allow the user to change default values for the PPPoE connection at run time.
Creation of a new PPPoE Client link layer tfUseClientPppoe()
tfUseClientPppoe() is the public API to allow the user to use a PPPoE link layer as a client. The parameter is identical to the tfUseAsyncPpp() parameter, i.e. a link layer notify function pointer, data type ttUserLnkNotifyFuncPtr. Like tfUseAsyncPpp(), tfUseClientPppoe() returns a link layer handle to the user.
PPPoE and PPP User notifications
PPPoE will notify the user of PPPoE transitions, and PPP transitions. A new flag has been added so that the user is notified at the end of the discovery phase, when the PPP session phase has been reached.
TM_LL_PPPOE_DISC_COMPLETE
Treck PPPoE Server
Compile time PPPoE server configuration
Enabling PPPoE Server
To enable the PPPoE Server code, you must define TM_USE_PPPOE_SERVER in <trsystem.h>.
PPPoE Server default option values
The user can overwrite the default values for the following PPPoE client options, by either re-defining the macro(s) in <trsystem.h> to a different value, or by calling tfPppoeSetOption() as described in the following section.
| PPPoE macro | Meaning | Default Value |
| TM_PPPOE_DISC_SRVR_TIMEOUT | Server default timeout in milliseconds during discovery waiting for next expected packet from the client | 10,000 ms |
Run time PPPoE Server Configuration tfPppoeSetOption()
A new User API is provided tfPppoeSetOption() to allow the user to change default values for the PPPoE connection at run time.
Creation of a new PPPoE server link layer tfUseServerPppoe()
tfUseServerPppoe() is provided to allow the user to use a PPPoE link layer as a server. Parameter is identical to the tfUseAsyncServerPpp() parameter, i.e. a link layer notify function pointer, data type ttUserLnkNotifyFuncPtr. Like tfUseAsyncServerPpp(), tfUseServerPppoe() returns a link layer handle to the user.
PPPoE and PPP User notifications
PPPoE will notify the user of PPPoE transitions, and PPP transitions. A new flag has been added so that the user is notified at the end of the discovery phase, when the PPP session phase has been reached.
TM_LL_PPPOE_DISC_COMPLETE
