PPPoE用户上线交互过程

1、PPPoE用户上线交互过程PPPoE用户上线要经过 PPPoE协商、LCP协商、PAP/CHAP认证、NCP协商几个阶段PPPoE协商PPPoE协商是 ME设备为用户分配 PPPoE接入用的 Session ID ，该Session ID 在每ME设备上唯一，用来唯一标识一条用户与ME设备之间的PPPoE虚拟链路。PPPoE的协商流程见下图。图1 PPPoE的协商流程UserME601 PADI纣皿04.PADS1. 用户广播一个 PADI包，在此包中包含用户想要得到的服务类型信息。2. 以太网内的所有接入集中器（如上图中的ME设备）在收到这个初始化包后，将其中请求的服务与自己能提供的服务进行

2、比较，其中可以为此用户提供此服务的接入集中 器发回PADO包。3. 用户可能会收到多个集中器返回的PADO包。用户根据一定的条件从返回PADO包的接入集中器中选定符合条件的接入集中器，并向它返回一个会话请求包PADR非广播），在PADF包中封装所需的服务信息。4. 被选定的接入集中器在收到PADR包后开始进入 PPP会话阶段。它会产生一个会话标识以唯一的标识它和主机的这段PPPoE会话。并把这个特定的会话标识包含在会话确认包PADS中发回给用户，如果没有错误发生就进入到PPP会话阶段，而主机在收到会话确认包后如果没有错误发生也进入到PPP会话阶段。LCP协商LCP协商的过程如下：协商双方互相发

3、送一个LCP Co nfig-Request报文，确认收到的Con fig-Request报文中的协商选项，根据这些选项的支持与接受情况，做岀适当的回应。若两端都回应了 Config-ACK，则标志LCP链路建立成功，否则会继续发送Request报文，直到对端回应了 ACK报文为止。I 4说明： Config-ACK :若完全支持对端的LCP选项，则回应 Config-ACK报文，报文中必须完全协带对端Request报文中的选项。 Config-NAK :若支持对端的协商选项，但不认可该项协商的内容，则回应Config-NAK报文，在Config-NAK的选项中填上自己期望的内容，如：对端MR

4、U直为1500，而自己期望MRU值为1492，则在Config-NAK报文中埴上自己的期望值1492。 Con fig-Reject:若不能支持对端的协商选项，则回应Co nfig-Reject报文，报文中带上不能支持的选项，如Windows拨号器会协商 CBCP(被叫回呼)，而ME60不支持CBCP功能，则回将此选项拒绝掉。图2 LCP协商的基本过程ClientServerCPCon1ig-reCon1ig*ackCofrfig-reqConfig-tick1. 当用户与 ME设备互相发送 LCP Config-Request报文并且互相回应 LCP Config-Ack报文时，标志着 LC

5、P协商己经成功了。接下来ME设备会周期性的向用户发送LCPEcho-Request报文，探测用户是否在线。2. LCP协议通过互相发送 Echo-Request报文，然后接收对端回应的Echo-reply 报文,来探测LCP链接是否正常，以维持LCP连接。LU说明：* Echo-Request报文，只能支持回应 Echo-Reply报文, Echo是PPPoE用户的探测报文。 Echo探测次数为3次，每20秒为一个周期，BRAS设备从用户上线的一个周期后开始探测，探测3次都未收到用户的 Reply报文，即20 * (3 + 1) = 80秒后，会将用户 CUT下线。认证阶段 PAP认证PAP为

6、两次握手协议，它通过用户名及口令来对用户进行验证。PAP验证过程如下：当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表(或 Radius服务器)查看是否有此用户，口令是否正确。如正确则会给对端发送 Authenticate-ACK报文，通告对端已被允许进入下一阶段协商；否则发送NAK报文，通告对端验证失败。此时，并不会直接将链路关闭。只有当验证不过次数达到一定值(缺省为 10)时，才会关闭链路。PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有可能对网络安全造成极大的威胁。因此，它适用于对网络安全要求相对较低的环境。用户发送

7、认证端发验证请求报文、并且接收到ME设备回应认的证成功报文后，表示PAP认证己经成功。否则 ME设备会回应认证失败报文，通知用户认证不成功。图3 PAP认证流程ClientServerRadiusPITAuth-req认诳阶段Aulh-ackAuth-ackP CHAP认证CHAP为三次握手协议。只在网络上传输用户名，并不传输用户口令，因此它的安全性要比PAP高。CHAP的验证过程为：首先由验证方向被验证方发送一些随机产生的报文，并同时将本端的主机名附带上一起发送给被验证方。被验证方接到对端对本端的验证请求(Challenge)时，便根据此报文中验证方的主机名和本端的用户表查找用户口令字，如找

8、到用户表中与验证方主机名相同的用户，便利用报文ID、此用户的密钥用 Md5算法生成应答(Response )，随后将应答和自己的主机名送回。验证方接到此应答后，用报文ID、本方保留的口令字(密钥)和随机报文用Md5算法得岀结果，与被验证方应答比较，根据比较结果返回相应的结果(ACK or NAK )接受认证端发送 Challe nge申请认证端发验证请求报文 接受认证端回应认证接受报文经过以上三次报文交互后，CHAP认证完成，报文流程见下图图4 CHAP认证流程ClientServerRadiusppp认加段Challenge(CHAP)Auth-reqAuth-reqAuth-ackAjih

9、-ackNCP阶段NCP有很多种，女口 IPCP、BCP、IPV6CP,最为常用的是IPCP协议。NCP的主要功能是协商 PPP报 文的网络层参数，如 IP地址，DNS Server IP 地址，WINS Server IP 地址等。PPPoE用户主要 通过IPCP来获取访问网络的IP地址或IP地址段。NCP流程与LCP流程类似，用户与 ME设备之间互相发送 NCPConfig-Request 报文并且互相回应NCP Co nfig-Ack 报文后，标志 NCP己协商完，用户上线成功，可以正常访问网络了。 IPCPIPCP的协商过程是基于 PPP状态机进行协商的。经过双方协商，通过配置请求、配

10、置确认、配置否认等包文交换配置信息，最终由initial （ 或closed）状态变为Opened状态。IPCP状态变为Opened的条件必须是发送方和接收方都发送和接收过确认包文。IPCP协商过程中，协商包文可包含多个选项，即参数。各个选项的拒绝或否认都不能影响IPCP的UP, IPCP可以无选项协商，无选项协商也同样能够UP。选项有IP Address、网关、掩码等，其中IP Address是最重要的一个选项，有些厂家的实现必须这个选项 得到确认，大多数厂家的实现允许这个选项为空。NCP的基本协商流程见下图:图5 NCP的基本协商流程ClientServerNCPParmeter-reqParmeter-ackPgrmetr-rq协輛段Parmeter*acKPPPoE接入流程PPPoE-CHAP为例，PPP用户接入流程如下:图6 PPP用户接入流程IJIE60AAA ServerUser1.PADI1.PADI2.PADO2.PADO协圈3 PADR3 PADR4 PADS4 PADSPPR协商- lP协阳CHAF认证）（3- lP协阳CHAF认证）6