PPPoE

PPPoE

什么是PPPoE

PPPoE(Point-to-Point Protocol over Ethernet)， 应用于以太网上的PPP协议，应用在链路层，通过在以太网上提供点到点的连接，建立PPP会话卷，封装PPP报文为PPPoE报文，PPPoE技术可以将用户连接到远程接入设备上，并提供良好的访问控制功能，提供了一种经济的用户接入技术，并实现了对用户的控制。

PPP协议虽然提供了通信双方的身份验证功能，但是其协议中没有提供地址信息，而以太网是一个广播类型的多路访问网络，所以PPP协议无法直接应用在以太网链路上的。

PPPoE利用以太网络，提供远程的多个用户主机接入功能，并且能够提供数据传输的计费数据，解决用户上网收费等实际应用问题，因而被广泛应用于接入运营商网络。

PPPoE具有以下特点：

• PPPoE由于集成了PPP协议，实现了传统以太网不能提供的身份验证，加密以及压缩等功能。
• PPPoE通过唯一的Session ID可以很好的保障用户的安全性。
• PPPoE拨号上网作为一种最常见的方式让终端设备能够连接ISP从而实现带宽接入。
• PPPoE可用于缆线调制解调器(Cable Modem) 和数字用户线路(DSL)等以太网线，通过以太网协议向用户提供接入服务的协议体系。

PPPoE报文

报文字段	说明
Ver	4bits, PPPoE的版本号，值为0x1
Type	4bits, PPPoE的类型，值为0x1
Code	8bits, PPPoE报文类型。Code域为0x00，表示会话数据。Code域为0x09，表示PADI报文；Code域为0x07，表示PADO或PADT报文；Code域为0x19，表示PADR报文；Code域为0x65，表示PADS报文。
Session_ID	16bits，对于一个给定的PPP会话，该值是一个固定值，并且与以太网Source_address和Destination_address一起实际的定义了一个PPP会话。值0xffff为将来的使用保留，不允许使用。
Length	16bits，定义PPPoE的Payload域长度。不包括以太网头部和PPPoE头部的长度。

PPPoE建立连接

PPPoE 用户上线需要经历两个阶段，发现阶段和PPP会话阶段，发现阶段主要是选择PPPoE服务器，并确定索要建立会话标识符Session ID， 会话阶段即执行标准的PPP的过程，包括LCP协商，PAP/CHAP 认证，NCP协商等阶段。

具体的PPPoE的时序图如下所示：

1.发现阶段：

发现阶段是指设备为用户分配接入的Session ID，用来标识一条用户与设备之间的PPPoE虚拟链路。

• PPPoE Client广播一个PADI（PPPoE Active Discovery Initiation，PPPoE激活发现起始）报文，在此报文中包含用户想要得到的服务类型信息。
• 以太网内的所有PPPoE Server在收到这个初始化报文后，将其中请求的服务与自己能提供的服务进行比较，其中可以为PPPoE Client提供此服务的PPPoE Server会回应PADO（PPPoE Active Discovery Offer，PPPoE激活发现服务）报文。
• PPPoE Client可能会收到多个PPPoE Server回应的PADO报文。PPPoE Client会根据一定的条件从返回PADO报文的PPPoE Server中选定符合条件的PPPoE Server，并向它返回一个会话请求报文PADR（非广播）（PPPoE Active Discovery Request，PPPoE激活发现请求），在PADR报文中封装所需的服务信息。
• 被选定的PPPoE Server在收到PADR报文后，PPPoE Server会产生一个唯一的会话标识以标识它和PPPoE Client的这段PPPoE会话。并把这个特定的会话标识包含在会话确认报文PADS（PPPoE Active Discovery Session-confirmation，PPPoE激活发现会话确认）中回应给PPPoE Client，如果没有错误发生就进入到PPP会话阶段，而PPPoE Client在收到会话确认报文后如果没有错误发生也进入到PPP会话阶段。

PPP会话阶段

PPP会话阶段包括LCP协商、PAP/CHAP认证、NCP协商等阶段。

2.LCP协商

进入PPP会话阶段后，首先进行LCP协商：

• PPPoE Client与PPPoE Server互相发送LCP Configure-Request报文。

• 双方收到Configure-Request报文后，根据报文中协商选项支持情况做出适当的回应（请参见下表）。若两端都回应了Configure-ACK，则标志LCP链路建立成功，否则会继续发送Request报文：

  如果在设定的LCP协商间隔与协商次数内，对端回应了Configure-ACK，则LCP链路建立成功。

  如果在超过了设定的LCP协商次数后，对端尚未回应Configure-ACK，则终止LCP协商。

• LCP链路建立成功后，PPPoE Server会周期性地向PPPoE Client发送LCP Echo-Request报文，然后接收PPPoE Client回应的Echo-Reply报文，来探测LCP链路是否正常，以维持LCP连接。

回应报文类型列表：

回应报文类型	说明
Configure-ACK	若完全支持对端的LCP选项，则回应Configure-ACK报文，报文中必须完全协带对端Request报文中的选项。
Configure-NAK	若支持对端的协商选项，但不认可该项协商的内容，则回应Configure-NAK报文，在Configure-NAK的选项中填上本端期望的内容，如：对端MRU值为1500，而本端期望MRU值为1492，则在Configure-NAK报文中填上1492。
Configure-Reject	若不能支持对端的协商选项，则回应Configure-Reject报文，报文中带上不能支持的选项

3.PAP/CHAP认证

LCP协商完成后，会进入认证阶段，认证分为PAP和CHAP认证两种认证方式。

PAP为两次握手协议，是通过用户名和密码来对用户进行认证，并且是以明文的方式传递用户名和密码。PPPoE Server（或者RADIUS服务器）根据本端的用户表查看用户名和密码是否正确。适用于网络安全要求相对较低的环境。

CHAP认证为三次握手协议，也是由PPPoE Server（或者RADIUS服务器）根据本端的用户表查看用户名和密码是否正确。但是CHAP认证方式只在网络上传输用户名，不传输用户密码，安全性比PAP要高。

4.NCP协商

NCP协商的主要功能是协商PPP报文的网络层参数，如IPCP、IPv6CP等。PPPoE Client主要通过IPCP协议来获取访问网络的IP地址或IP地址段。

NCP协商的流程与LCP流程类似。NCP协商成功之后，PPPoE Client可以正常访问网络。

NCP协商成功之后，即为PPPoE Client上线，此时PPPoE Server（通常为BRAS设备），会给RADIUS服务器发送计费请求报文，通过RADIUS服务器对PPPoE Client进行计费。

通过IPCP协议获取到IP地址：