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 or NAK ）
（1）接受认证端发送Challenge
（2）申请认证端发验证请求报文
（3）接受认证端回应认证接受报文
经过以上三次报文交互后， CHAP 认证完成。
2.3 NCP 协商阶段（NCP ： Network Control Protocol ）
NCP 有很多种，如IPCP 、BCP 、IPv6CP ，最为常用的是IPCP （ Internet Protocol Control
Protocol ）协议。NCP 的主要功能是协商PPP 报文的网络层参数，如IP 地址， DNS Server
IP 地址， WINS Server IP 地址等。PPPoE 用户主要通过IPCP 来获取访问网络的IP 地址
或IP 地址段。
NCP 流程与LCP 流程类似，用户与ME 设备之间互相发送NCP Config-Request 报文并且
互相回应NCP Config-Ack 报文后，标志NCP 己协商完，用户上线成功，可以正常访问网
络了。
IPCP 的协商过程是基于PPP 状态机进行协商的。经过双方协商，通过配置请求、配置确
认、配置否认等包文交换配置信息， 最终由initial ( 或closed) 状态变为Opened 状态。IPCP
状态变为Opened 的条件必须是发送方和接收方都发送和接收过确认包文。
IPCP 协商过程中，协商包文可包含多个选项，即参数。各个选项的拒绝或否认都不能影响
IPCP 的UP，IPCP 可以无选项协商，无选项协商也同样能够UP 。选项有IP Address 、网
关、掩码等，其中IP Address 是最重要的一个选项，有些厂家的实现必须这个选项得到确
认，大多数厂家的实现允许这个选项为空。
NCP 的基本协商流程见下图：
用户和接入设备对IP 服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。
如： IP 业务阶段使用的IP 压缩协议等。双方的协议是通过报文中包含的Option 项进行协
商的，每一个Option 都是一个需要协商的问题。
最后双方都需要对方答复Configure_Ack 的同意报文。
2.4 会话维持（ Session Keep-alive ）
设备主动发送Echo Request 进行PPPoE 心跳保活，若3 次未得到服务器的响应，则设备
主动释放地址。发LCP Echo Request 的时候，魔术字字段要和之前通信的
Configure_Request 使用的魔术字字段保持一致。
有些设备或终端不支持主动发送Echo-Request 报文, 只能支持回应Echo-Reply 报文。
2.5 会话结束（ Session Termination ）
PPPoE 还有一个PADT （ PPPOE Active Discovery Terminate ）分组，它可以在会话建立
后的任何时候发送，来终止PPPoE 会话，也就是会话释放。它可以由主机或者接入集中器
发送，目的地址填充为对端的以太网的MAC 地址。
当对方接收到一个PADT （ PPPOE Active Discovery Terminate ）分组，就不再允许使用
这个会话来发送PPP 业务。PADT 分组不需要任何标签， 其CODE 字段值为0xa7 （ PADT
Code ），SESSION-ID 字段值为需要终止的PPP 会话的会话标识号码。在发送或接收PADT
后，即使正常的PPP 终止分组也不必发送。PPP 对端应该使用PPP 协议自身来终止PPPoE
会话，但是当PPP 不能使用时，可以使用PADT 。
3.PPPoE 接入流程示例
PPP 状态变迁如图6 所示：
以PPPoE-CHAP 为例， PPP 用户接入流程如图7 所示：
4.Linux 中的PPPoE 拨号守护进程（pppd ：Point-to-Point Protocol Daemon ）
pppd 是一个后台服务进程(daemon) ，是一个用户空间的进程，所以把策略性的内容从内核
的PPP 协议处理模块移到pppd 中是很自然的事了。pppd 实现了所有鉴权、压缩/解压和加
密/解密等扩展功能的控制协议。
pppd 只是一个普通的用户进程，它如何扩展PPP 协议呢？这就是pppd 与内核中的PPP
协议处理模块之间约定了， 它们之间采用了最传统的内核空间与用户空间之间通信方式： 设
备文件。
设备文件名是/dev/ppp 。通过read 系统调用，pppd 可以读取PPP 协议处理模块的数据包，
当然， PPP 协议处理模块只会把应该由pppd 处理的数据包发给pppd 。通过write 系统调
用， pppd 可以把要发送的数据包传递给PPP 协议处理模块。通过ioctrl 系统调用， pppd
可以设置PPP 协议的参数，可以建立/关闭连接。
