PPPoE客户端连接协商过程

1 协商过程

整个协商过程分为两个阶段：发现阶段和会话阶段

1.1 发现阶段

1.2 会话阶段

2 报文分析

实验组网

整个协商过程的报文

2.1 发现阶段

2.1.1 报文1-PADI

回忆一下PPPoE发现阶段报文格式

根据报文格式，具体的解析过程如下

发现阶段以太头的帧类型是0x8863,代码0x09表示PADI，其中目的MAC是广播地址，此时的会话ID是0，长度为16表示净载荷总长16字节，0x0101的标记类型表示服务名，此时值为0（因此wireshark并没有显示），0x0103表示主机产生，后面0x08表示值长度是8字节，注意，响应报文不可以改变该值。

2.1.2 报文2-PADO

PADO是二层单播报文，从MAC地址可以看出，此时的帧类型依然是0x8863,Code值变为0x07，即PADO，并且包含了4个Tag，均采用TLV表示，其中响应报文不会对AC-Cookie改写。

2.1.3 报文3-PADR

可以发现相比PADO，该报文的MAC地址发生了调换，Code变为0x19，即PADR，Host-Uniq和AC-Cookie均没有发生变化。

2.1.4 报文4-PADS

该报文相比之前，最重要的变化就是Session ID产生了一个唯一值。

至此，发现阶段完毕，接下来进入会话阶段，开始PPP协商。

2.2 会话阶段

会话阶段基本上是PPP协商阶段，主要分为三个步骤：LCP协商-->认证-->NCP协商

2.2.1 LCP协商

PPPoE在LCP协商阶段报文格式如下：

接下来分析LCP协商过程，LCP协商过程中的报文主要分为三类，如下所示:

1、链路配置报文

用来创建和配置一条链路

Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject

2、链路终止报文

用来终止一条链路

Terminate-Request、Terminate-Reply

3、链路维护报文

用来管理和调试链路

Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply、Discard-Request

需要指出的是PPP协商是双向的，也就是说双方都会发出Configure-Request请求，并且有可能协商多次才能成功，最理想的就是一对Configure-Request&Configure-Ack就协商成功，下面是几种常见的协商过程。

（1）一次交互

（2）两次交互，Nak情况

（3）两次交互，Reject情况

（4）多次交互

接下来通过报文具体分析整个协商过程。

（1）报文5--Configure-Request报文，PC-->Server

注意以太头中的帧类型变为了0x8864，PPPoE头中的Code变为0，在会话阶段Code将一直置0，并且Session ID一旦产生不会发生变化，直至会话断开。0xC021表示LCP协议，Identifier是标志域，其目的是用来匹配请求和响应报文。一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发出几个配置请求报文，而这几个请求报文的数据域可能完全一样，而仅仅是它们的标志域不同罢了。接下来是协商选项options，此处协商了链路的MTU，魔术字以及Callback。

（2）报文6--Configure-Request报文，Server-->PC

注意这个Configure-Request报文的Identifier是1，后面的options协商的内容是认证协议和魔术字。

（3）报文7--Configure-Ack报文，PC-->Server

此时LCP的Code变为2，即Configure-Ack报文，并且Identifier是1，表明该Ack报文是对报文6的响应，后面的选项和报文6一致。

到此，Server-->PC方向的LCP协商完毕。

（4）报文8--Configure-Request报文，PC-->Server

由于报文5发出后没有得到响应，PC再次向Sever发送Configure-Request报文，注意Identifier的值是1。

（5）报文9--Configure-Reject，Server-->PC

PPP报文中的Code是4，表示收到的Request请求中有不支持的Option，Configure-Reject报文将不支持的option内容发回给发送者，此处即不支持Callback，因此将此作为报文的option发给发送者。

（6）报文10--Configure-Request，PC-->Server

PC收到Server的Reject报文后，将对方不支持的选项去掉，重新发送Configure-Request报文，注意此时PPP报文中的Identifier变为2，说明这是重新发送的Request。

 （7）报文11--Configure-Ack，Server-->PC

这次Server同意Pc发出的协商请求，向PC发出Ack报文。

至此，PC-->Server的LCP协商完毕，整个LCP协商过程完毕。

（8）报文12--Echo-Request报文，Server-->PC

这个是一个维护报文，在LCP协商完毕后，用来检测链路联通状态，如果链路OK，PC会发给Server一个Echo-Reply报文。

Echo数据豹纹呢的长度域不是直接跟数据域，没有配置参数选项，而是直接插入4个字节的Magic-Number（魔术字），该魔术字是在LCP的Config-Request的配置参数选项协商时获得的。

（9）LCP协商过程总结

PC-->Server

Server-->PC

2.2.2. 认证

    一般有两种认证方式：PAP（两次握手）和CHAP（三次握手），根据前面的协商，这里选择了CHAP协议（见报文6）。

（1）报文13--Challenge，Server-->PC

从验证方向被验证方发送一段随机的报文，并加上自己的主机名，我们通常称这个过程为挑战。

（2）报文14--Identification,PC--Server

（3）报文15--Identification，PC-->Server

报文14和报文15是两个LCP报文，在PPP数据的Code域是12，这两个是与验证无关的报文。

（4）报文16--Code-Reject，Server-->PC

PPP数据中Code的值是Code Reject，说明上面收到的报文14中的Code域（12）此处不识别，将Code-Reject报文发给发出者，报文中LCP数据域即报文14中从Code域开始到PPP封装的内容。这里需要注意的是Identifier的值是2，是在在报文7的Identifier的值上加1得到的，虽然是对报文14的回应，但是与报文14中的Idenitfier没有关系。

（5）报文17--Code-Reject，Server-->PC

这个与报文16相同，不再赘述。

（6）报文18--Echo-Relay，PC-->Server

该报文是对报文12的响应，Identifier与报文12相同，ppp数据中的Code变为Echo Reply。

（7）报文19--Response，PC-->Server

ppp封装中的Identifier域报文13中的值相同，将随机值和主机名作为Chap的Data发给Server。

（8）报文20--Success，Server-->PC

发给被验证方的响应，此处表示验证成功。

至此，认证阶段完毕。

（9）认证过程总结

2.2.3 NCP协商（此处以IPCP为例）

     NCP的协商和LCP一样，也是双向协商的，即协商双方都需要发送Configure-Request报文，并接受到对端回应的Configure-Ack报文才行。

     IPCP协商报文格式

    

    IPCP协商分为两种情况：静态协商和动态协商，其过程分别如下：

    静态协商：

     动态协商：

     

    本文涉及的是IPCP协商为动态协商

（1）报文21--Configure-Request，Server-->PC

    以太头部的type依然是0x8864，ppp封装中的protocol是0x8021，Identifier是1，在options域中的协商参数是IP address。

（2）报文22--Configure-Request，PC-->Server

在ppp封装中Identifier是5，options里面的个个配置项均为空。

（3）报文23--Configure-Ack，PC-->Server

    在该Ack报文中，ppp封装里面只有Code与报文21不同，其他的完全一致。

（4）报文24--Configure-Reject，Server-->PC

    ppp报文中Configure-Reject表示收到的报文22中存在Server不认识的配置选项，该Reject报文将不识别的配置选项作为options发给报文22的发送者，注意此处Identifier为5，并不与报文22相同。

（5）报文25--Configure-Request，PC-->Server

    这次的Configure-Request报文将Server不认识的配置参数去掉，并且将Identifier变为6。

（6）报文26--Configure-Nak，Server-->PC

    Configure-Nak报文表示不认可发送端的配置选项值，并给出自己认可的值，报文ppp封装中Code字段变为3，在options中填充了自己认可的配置选项值。

（7）报文27--Configure-Request，PC-->Server

    PC根据收到的Configure-Nak报文中的options值，重新填充构造的Reuqest报文中options域，再次发送Configure-Request报文，Identifier再一次加1.

（8）报文28--Configure-Ack，Server-->PC

     Server终于向PC发送Ack报文，该报文在PPP部分除了Code和报文27不一样外，其他的完全一致。

至此，NCP协商完毕，PPPoE拨号成功。

（9）NCP协商过程总结

PC-->Server

Server-->PC

（完毕）