The RFC is refreshingly small, and is largely concerned with how a device (client) discovers and connects to an access controller on the network. Once you have a connection to an access controller, the rest is PPP, which has its own protocols to negotiate IP addresses and carry packets.
PPP itself dates back to the good old days of dialup modems, but is still used today for broadband lines and even high speed fibre to the cabinet and fibre to the premises lines.
The key thing PPPoE does is separate the modem (which converts signals on the line itself) from the router (which decides what to do with IP packets). There are a couple of good reasons to do this. (a) It makes for a good demarcation point for a telco allowing generic termination equipment (the modem) to be part of the service whilst providing choice of actual router, and (b) modem/router manufacturers are notoriously bad at making routers that are any good at routing (note lack of IPv6 support as a good example) and you usually want to have a decent router/firewall from someone that can make routers (like the FireBrick, of course :-) ).
As you probably saw, I wrote the FireBrick PPPoE client on Friday morning, and was well pleased with myself having tested on a Vigor V120 PPPoE/A modem on a BT line. I then spent most of this morning trying to get it working with BT lines using a Zyxel in bridge mode. It is working now with zyxel in bridge mode to BT and Be as well as to the Vigor. Next to test is FTTC and FTTP BT lines.
Whilst the RFC for PPPoE is not bad, there are a few issues:-
- PPPoE limits the MTU to 1492 as 8 bytes are used for PPPoE and PPP headers. Fortunately there is a later RFC allowing negotiation of baby jumbo frames (dumbo frames?) to handle full 1500 byte MTU. Unfortunately I have yet to find a router that supports it even though their Ethernet chip-sets can probably do the larger frame. Fortunately BT FTTC and FTTP does support it, apparently.
- PPPoE has a range of extensible tagged parameters, but they missed a trick by failing to define a few simple ones such as telephone number for dialup or VPI/VCI/encap mode for DSL. Having these would mean modems need no configuration at all and so not need DHCP, IP and web interfaces - having all parameters using the PPPoE tags would be perfect and should have been encouraged in the original PPPoE spec. Other obvious status parameters, like tx speed and rx speed and so on, in the response from them modem would have been a simple addition. These could have been defined as optional tagged values in the original spec and saved everyone a lot of time.
- PPPoE allows for a relay device. This makes perfect sense for a DSL router to relay PPPoE either to PPPoA as raw PPP, or to a remote PPPoE device on the wire whilst appearing as only one device on the local network. This is how it should be done. Sadly it seems almost all routers that do PPPoE work in a bridge mode - bridging the LAN to the far end of the DSL line. This causes serious problems. For a start you have no way to direct traffic to a specific line via a specific router/bridge, if you have more than one, as you only see the far end bridged Ethernet MAC addresses. You also have no way to tell this has happened. You also have to run a separate LAN segment even if you only have one router/bridge as the broadcast traffic on your LAN is bridged and can trip MAC address limits on the DSL service. In short, each PPPoE router/bridge has to be on its own LAN segment which is a pain, and a shame as the spec allowed them to act as relays!
- Finally, bugs... It seems our favourite telco do not follow the RFC. There is an "end" tag, id 0x0000, which you can put at the end of the list of tags. It is not required but remains for backwards compatibility. So I dutifully included it, and all was well. Vigor happy. Be happy. Could not get working with our favourite telco. Turns out if you include this completely valid tag then our favourite telco just totally ignore your PADI packets. WTF! RTFRFC guys!
There is much more code still to do though...