Figure 1  PPP over Ethernet (PPPoE)

Figure 2 Steps in the PPPoE Discovery stage

The host sends the PADI packet with the Ethernet 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_TYP Service-Name, indicating the service the host is requesting; it may contain 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.

When the Access Concentrator receives a PADI that it can serve, it replies by sending a PADO packet. The Ethernet 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. The PADO packet must contain one AC-Name tag containing the Acces Concentrator’s name, a Service-Name tag identical to the one in the PADI; it may also contain any number of other Service-Name tags indicating other services that the Access Concentrator offers. If the Access Concentrator cannot serve the PADI it must not respond with a PADO.

Because 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; it may also contain any number of other tag types.

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; it may also contain 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.

The PPPoE session is established after the BSN sends the PADS and the host receives the Confirmation packet. The PPP session stage is then entered, and PPP data is then sent as in any other PPP encapsulation in any other network architecture. All Ethernet packets are unicast. The ETHER_TYPE field is set to the PPPoE identifier 0x8864 for all PPP session packets [and all IP packets contained in the PPP headers following successful LCP negotiation]. 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.

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:

• Frame 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 1,492. Since Ethernet has a maximum payload size of 1,500 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 occasionally 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.

The PPPoE Active Discovery Terminate (PADT) packet may be sent any time 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. 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 cannot be used.

The very first thing to note is that you must make sure that there is an end-to-end pure bridged network between the PPPoE client and the BSN. It could be a 1483 bridged or Ethernet access connection. Remember, the Discovery stage of PPPoE consists of the PPPoE client sending a broadcast (mac destination = all F’s) PADI packet to find its BSN. If within the network there is a router in between, it will probably stop your connection, because most routers block broadcasts from exiting their domain.