PPPoE（Point to Point Protocol over Ethernet，基于以太网的点对点协议）的工作流程包含发现（Discovery）和会话（Session）两个阶段，发现阶段是无状态的，目的是获得PPPoE 终端（在局端的ADSL设备上）的以太网MAC 地址，并建立一个惟一的PPPoE SESSION-ID。发现阶段结束后，就进入标准的PPP会话阶段
1.发现阶段（PPPoED：PPPoE Discovery）
1.1 PADI（PPPoE Active Discovery Initiation）
主机广播发起分组，分组的目的地址为以太网的广播地址 0xffffffffffff，CODE（代码）字段值为0×09（PADI Code），SESSION-ID（会话ID）字段值为0x0000。PADI分组必须至少包含一个服务名称类型的标签（Service Name Tag，字段值为0x0101），向接入集中器提出所要求提供的服务。
1.2 PADO（PPPoE Active Discovery Offer）
接入集中器收到在服务范围内的PADI分组，发送PPPoE有效发现提供包分组，以响应请求。其中CODE字段值为0×07（PADO Code），SESSION-ID字段值仍为0x0000。PADO分组必须包含一个接入集中器名称类型的标签（Access Concentrator Name Tag，字段值为0x0102），以及一个或多个服务名称类型标签，表明可向主机提供的服务种类。PADO和PADI的
Host-Uniq Tag值相同。
1.3 PADR（PPPoE Active Discovery Request）
主机在可能收到的多个PADO分组中选择一个合适的PADO分组，然后向所选择的接入集中器发送PPPoE有效发现请求分组。其中CODE字段为0x19（PADR Code），SESSION_ID字段值仍为0x0000。PADR分组必须包含一个服务名称类型标签，确定向接入集线器（或交换机）请求的服务种类。当主机在指定的时间内没有接收到PADO，它应该重新发送它的PADI分组，并且加倍等待时间，这个过程会被重复期望的次数。
1.4 PADS（PPPoE Active Discovery Session-confirmation）
接入集中器收到PADR分组后准备开始PPP会话，它发送一个PPPoE有效发现会话确认PADS 分组。其中CODE字段值为0×65（PADS Code），SESSION-ID字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。PADS分组也必须包含一个接入集中器名称类型的标签以确认向主机提供的服务。当主机收到PADS 分组确认后，双方就进入PPP会话阶段。PADS 和PADR的Host-Uniq Tag值相同。
2.会话阶段（PPPoES：PPPoE Session）
PPP会话的建立，需要两端的设备都发送LCP数据包来配置和测试数据通信链路。
用户主机与接入集中器根据在发现阶段所协商的PPP会话连接参数进行PPP会话。一旦PPPoE会话开始，PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。PPPoE会话的SESSION-ID一定不能改变，并且必须是发现阶段分配的值。
2.1 LCP协商阶段（LCP：Link Control Protocol）
LCP的Request主机和AC都要给对方发送，LCP协商阶段完成最大传输单元（MTU），是否进行认证和采用何种认证方式（Authentication Type）的协商。
（1）LCP协议数据报文分类
链路配置报文：用来建立和配置一条链路，主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject报文
链路维护报文：用来管理和调试链路，主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request报文
链路终止报文：用来终止一条链路，主要包括Terminate-Request和Terminate-Reply报文
（2）LCP协商过程
LCP协商的过程如下：协商双方互相发送一个LCP Config-Request报文，确认收到的Config-Request报文中的协商选项，根据这些选项的支持与接受情况，做出适当的回应。若两端都回应了Config-ACK，则标志LCP链路建立成功，否则会继续发送Request报文，直到对端回应了ACK报文为止。
说明：
（1）Config-ACK：若完全支持对端的LCP选项，则回应Config-ACK报文，报文中必须完全携带对端Request报文中的选项。
（2）Config-NAK：若支持对端的协商选项，但不认可该项协商的内容，则回应Config-NAK 报文，在Config-NAK的选项中填上自己期望的内容，如:对端MRU值为1500，而自己期望MRU值为1492，则在Config-NAK报文中埴上自己的期望值1492。
（3）Config-Reject：若不能支持对端的协商选项，则回应Config-Reject报文，报文中带上不能支持的选项，如Windows拨号器会协商CBCP（被叫回呼），而ME60不支持CBCP功能，则回将此选项拒绝掉。
2.2 认证阶段（PPP Authentication：PAP/CHAP）
会话双方通过LCP协商好的认证方法进行认证，如果认证通过了，才可以进行下面的网络层的协商。认证过程在链路协商结束后就进行。
ⅠPAP（Password Authentication Protocol，口令认证协议）认证
PAP为两次握手协议，它通过用户名及口令来对用户进行验证。PAP验证过程如下：当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表（或Radius服务器）查看是否有此用户，口令是否正确。如正确则会给对端发送Authenticate-ACK报文，通告对端已被允许进入下一阶段协商；否则发送NAK报文，通告对端验证失败。此时，并不会直接将链路关闭。只有当验证不过次数达到一定值（缺省为10）时，才会关闭链路。
PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有可能对网络安全造成极大的威胁。因此，它适用于对网络安全要求相对较低的环境。
ⅡCHAP（Challenge Handshake Authentication Protocol，质询握手认证协议）认证
CHAP为三次握手协议。只在网络上传输用户名，并不传输用户口令，因此它的安全性要比PAP高。CHAP的验证过程为：
首先由验证方（Server）向被验证方（Client）发送一些随机产生的报文，并同时将本端的主机名附带上一起发送给被验证方。被验证方接到对端对本端的验证请求（Challenge）时，便根据此报文中验证方的主机名和本端的用户表查找用户口令字，如找到用户表中与验证方主机名相同的用户，便利用报文ID、此用户的密钥用Md5算法生成应答（Response），随后将应答和自己的主机名送回。验证方接到此应答后，用报文ID、本方保留的口令字（密钥）和随机报文用Md5算法得出结果，与被验证方应答比较，根据比较结果返回相应的结果（ACK