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地址: