PPPoE报文交互详解

1. PPPoE的验证过程

PPPoE的验证过程，包括2个阶段，Discovery阶段和PPP Session阶段。

2.Discovery阶段，包含4个步骤：

Step 1 ：PADI（PPPoE Active Discovery Initiation）

PPPoE客户端发送主动发现初始化包（PPPoE Active Discovery Initiation，PADI）以太头中的目的地址是以太广播地址 FF:FF:FF:FF:FF:FF，PPPOE 头中的 CODE 为 0x09，SESSION_ID 值必须为 0，负载部分必须只包含一个 Service-Name 类型的 TAG 表示请求的服务类型，另外可以包含其他 TAG，整个 PPPOE 包不能超过 1484 字节；

Step 2: PADO（PPPoE Active Discovery Offer）

服务器端 PPPoE 进程在网络接口侦听到 PADI 包后，发送主动发现提议包(PPPoEActive Discovery Offer, PADO)，用来回应客户机的 PADI 包，以太头中的目的地址是客户机的mac 地址，PPPOE 头中的 CODE 为 0x07， SESSION_ID 值必须为 0，负载部分必须包含一个 AC-Name 类型的 TAG，用来指示本 AC 的名称，一个在 PADI 包中指定的Service- Name 的 TAG，另外可以包含其他 Service-Name 的 TAG。如果 AC 不对该客户机提供服务，AC 就不回应 PADO 包。

Step 3: PADR（PPPoE Active Discovery Request）

PPPoE 客户端收到 PADO 包后，在 PADO 包中选择一个（可能有多个 PPPoE 服务器，通常选取最快的一个）发送主动发现请求包（PPPoEActive Discovery Request，PADR），以太头中的目的地址是所选取的 PADO 包的源以太头地址（即 PPPoE 服务器的 MAC 地址），PPPOE 头中的 CODE 为 0x19，SESSION_ID 值必须为 0，负载部分必须只包含一个 Service-Name 类型的 TAG 表示请求的服务类型，另外可以包含其他 TAG。

Step 4: PADS（PPPoE Active Discovery Seession-Confirmation）

MAC 地址匹配的 PPPoE 服务器收到 PADR 包后，发送主动发现会话确认包(PPPoE Active Discovery Session-confirmation, PADS)，将产生一个 SEESSION_ID 值用来标志本次 PPP 会话，以 PADR 包方式发送给客户机。以太头中的目的地址是客户机的 MAC 地址，PPPOE 头中 的 CODE 为 0x65，SESSION_ID 值必须为所生成的那个SESSION_ID，负载部分必须只包含一个 Service-Name 类型的 TAG， 表示该服务类型被 PPPoE 服务器接受，另外可以包含其他 TAG。如果 PPPoE 服务器不接受 PADR 中的

Server-Name，PADS 中则包含一个 Service-Name -Error 类型的 TAG,这时 SESSION_ID 设置为 0。

3. PPP Session 阶段:

当客户端与服务器端远成发现阶段之后，即进入会话阶段，在 PPP 会话阶段，PPP 包被封装在 PPPoE 以太帧中，以太包目的地址都是单一的，以太协议为 0x8864， PPPoE 头的CODE必须为0，SESSION_ID必须一直为发现阶段协商出的SEESION_ID值， PPPoE 的负载是整个 PPP 包，PPP 包前是两字节的 PPP 协议 ID 值。

Step 1: LCP（Link Control Protocol）协商

主要协商了MRU（Maximum Receive Unit），并提出了认证使用的Magic Number。

图3-1 client发送到server的Configuration Request

图3-2 server发送到client的Configuration Request

图3-3 client发送到server的Configuration Ack

图3-4 server发送到client的Configuration Ack

Step 2: 认证阶段

认证阶段务器端将验证客户端的合法性。最常见的两种就是PAP和CHAP；

PAP（Password Authentication Protocol）验证为两次握手验证，密码为明文；

PAP验证的过程如下：

(1)被验证方发送用户名和密码到验证方；

(2)验证方根据本端用户表查看是否有此用户以及密码是否正确，然后返回不同的响应。

CHAP（Challenge-Handshake Authentication Protocol）验证为三次握手验证，密码为密文（密钥）；

注意：PAP不是一种安全的验证协议。当验证时，口令以明文方式在链路上发送，并且由于完成PPP链路建立后，被验证方会不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以不能防止攻击。

CHAP验证过程如下：

(1)Challenge：验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文，并同时将本端的用户名附带上一起发送给被验证方；

(2)Response：若被验证方接到验证方的验证请求后，检查本端接口上是否配置了缺省的CHAP密码，如果配置了则被验证方利用报文ID、该缺省密码和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名发回验证方；若被验证方检查发现本端接口上没有配置缺省的CHAP密码，则被验证方根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码，如果在用户表找到了与验证方用户名相同的用户，便利用报文ID、此用户的密钥（密码）和MD5算法对该随机报文进行加密，将生成的密文和被验证方自己的用户名发回验证方；

(3)result:验证方用自己保存的被验证方密码和MD5算法对原随机报文加密，比较二者的密文，根据比较结果返回不同的响应。

图3-5 server发送到client的Challenge

图3-5 client发送到server的Response

图3-6 server发送到client的Success

Step 3: IPCP（IP Control Protocol）阶段

图3-7 server发送到client的Configuration Request

图3-8 client发送到server的Configuration Request

图3-9 server发送到client的Configuration Nak

图3-10 client发送到server的Configuration Ack

图3-11 client发送到server的Configuration Request

图3-12 server发送到client的Configuration Ack