PPPOE协议工作流程
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 协议的参数，可以建立/关闭连接。