PPPOE协议
PPPoE（Point-to-Point Protocol over Ethernet）协议，又称作以太网上的PPP协议，应用在链路层。它通过在以太网上提供点到点的连接，建立PPP会话，封装PPP报文为PPPoE报文。PPPoE技术可以将用户连接到远程接入设备上，并提供良好访问控制功能，提供了一种经济的用户接入技术，并实现了对用户的控制。 PPPoE利用以太网络，提供远程的多个用户主机接入功能，并且能够提供数据传输的计费数据，解决用户上网收费等实际应用问题，因而被广泛应用于接入运营商网络。
PPPoE解决了哪些问题？
PPP协议是一种点对点协议，点对点的含义即为一个节点只能访问另一个指定的节点。PPP协议处于OSI（Open Systems Interconnection）参考模型的第二层，即TCP/IP数据链路层，主要用于全双工的异步链路上进行点到点的数据传输。PPP协议的一个重要功能便是提供了身份验证功能。但是PPP协议虽然提供了通信双方身份验证的功能，其协议中没有提供地址信息，而以太网是一个广播类型的多路访问网络，因而PPP协议是无法直接应用在以太网链路上的。
以太网技术虽然具有简单易用，成本低等特点，但是以太网广播网络的属性，使得其通信双方无法相互验证对方的身份，因而通信是不安全的。
PPPoE结合了PPP协议通信双方身份验证的功能，在PPP组网结构的基础上，将PPP报文封装成PPPoE报文，从而实现以太网上的点对点通信，使得以太网中的客户端能够连接到远端的宽带接入设备上。
PPPoE的特点
PPPoE具有以下特点：
功能上：
-
PPPoE由于集成了PPP协议，实现了传统以太网不能提供的身份验证、加密以及压缩等功能。
-
PPPoE通过唯一的Session ID可以很好的保障用户的安全性。
应用上：
-
PPPoE拨号上网作为一种最常见的方式让终端设备能够连接ISP从而实现宽带接入。
-
PPPoE可用于缆线调制解调器（Cable Modem）和数字用户线路（DSL）等以太网线，通过以太网协议向用户提供接入服务的协议体系。
-
实现有效的用户管理，进行网络接入计费等
总而言之，PPPoE技术将以太网技术的经济性与PPP协议的可管理控制性结合在一起，提供接入互联网的功能。对于运营商来说，它能够最大限度地利用电信接入网现有的体系结构，利用现有的拨号网络资源，运营和管理的模式也不需要很大的改变；对于用户来说，使用感与原来的拨号上网没有太大区别，较容易接受。
PPPOE协议是一种C/S的协议，即客户端和服务端协议，但是PPPOE协议却可以实现在ADSL中实现点到点的数据链路层协议，其原因便是他集成封装了PPP协议，在它建立连接后的回话阶段，流程和PPP协议是几乎一样的一样，接下来我们将介绍它是如何工作的
PPPoE如何工作？
我们将从PPPoE的报文结构以及PPPoE的工作阶段来介绍他的工作原理：
PPPoE报文
在了解PPPoE建立连接的阶段之前，我们先来了解下PPPoE协议的报文结构，PPPoE报文的格式就是在以太网帧中携带PPP报文，报文封装结构如下图所示。
PPPoE协议报文结构图
表1-1 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建立连接的阶段之前，我们先了解下PPPoE组网结构中的各种角色。
PPPoE协议采用Client/Server模式，如PPPoE接入组网图所示，基本的PPPoE组网中的角色有PPPoE Client，PPPoE Server，以及RADIUS设备（代理服务器）。
PPPoE接入组网图
PPPoE用户上线需要经过两个阶段，发现阶段和PPP会话阶段。发现阶段主要是选择PPPoE服务器，并确定索要建立的会话标识符Session ID。PPP会话阶段即执行标准的PPP过程，包括LCP协商、PAP/CHAP认证、NCP协商等阶段。
PPPoE工作原理实现过程
具体的PPPoE发现阶段和PPP会话阶段的时序如下图所示。
PPPoE发现阶段和PPP会话阶段时序图
接下来我们仔细讲一下PPPOE的工作阶段：
发现阶段
发现阶段是指设备为用户分配接入的Session ID，用来标识一条用户与设备之间的PPPoE虚拟链路。
Discovery阶段由四个步骤组成。完成之后通信双方都知道了PPPoE Session_ID以及对方以太网地址，它们共同确定了唯一的PPPoE会话。
-
PPPoE Client广播一个PADI（PPPoE Active Discovery Initiation，PPPoE激活发现起始）报文，在此报文中包含用户想要得到的服务类型信息。
在PPPoE的初始阶段，接入主机并不知道访问集中器（NAS）的MAC地址，这时就采用类似于ARP的方式广播PADI报文。以太网上的访问集中器如果配置了PPPoE的业务，就会实时监测网络上的PPPoE报文。 PADI报文的目的地址为以太网的广播地址0×ffffffffffff，CODE（代码）字段值为0×09，SESSION-ID（会话ID）字段值为0×0000。 如果在PPPoE的服务器端配置service-name，client将发送Discovery阶段的PADI报文给服务器端请求建立连接。 如果该PADI报文中包含有不为空的service-name时，服务器端将用配置的service-name和该报文中的service-name进行完全匹配性检测。如果两者完全相同，服务器端提供后续服务，否则，服务器端不提供服务。 以上是两者的service-name都不为空时的情况。但如果两者中有一个service-name为空，就不进行此项检测，直接按照原来的程序执行。
-
以太网内的所有PPPoE Server在收到这个初始化报文后，将其中请求的服务与自己能提供的服务进行比较，其中可以为PPPoE Client提供此服务的PPPoE Server会回应PADO（PPPoE Active Discovery Offer，PPPoE激活发现服务）报文。
PADO报文的CODE字段值为0×07，SESSION-ID字段值仍为0×0000。
-
PPPoE Client可能会收到多个PPPoE Server回应的PADO报文。PPPoE Client会根据一定的条件从返回PADO报文的PPPoE Server中选定符合条件的PPPoE Server，并向它返回一个会话请求报文PADR（非广播）（PPPoE Active Discovery Request，PPPoE激活发现请求），在PADR报文中封装所需的服务信息。
PADR报文的CODE字段为0x19，SESSION_ID字段值仍为0×0000。
-
被选定的PPPoE Server在收到PADR报文后，PPPoE Server会产生一个唯一的会话标识以标识它和PPPoE Client的这段PPPoE会话。并把这个特定的会话标识包含在会话确认报文PADS（PPPoE Active Discovery Session-confirmation，PPPoE激活发现会话确认）中回应给PPPoE Client，如果没有错误发生就进入到PPP会话阶段，而PPPoE Client在收到会话确认报文后如果没有错误发生也进入到PPP会话阶段。
PADS报文，CODE字段值为0×65，SESSION-ID字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。
PPP会话阶段
PPP会话阶段包括LCP协商、PAP/CHAP认证、NCP协商等阶段。
LCP协商
进入PPP会话阶段之后，首先进行LCP协商，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连接。
表1-2 回应报文类型列表
| 回应报文类型 | 含义 |
|---|---|
| Configure-ACK | 若完全支持对端的LCP选项，则回应Configure-ACK报文，报文中必须完全协带对端Request报文中的选项。 |
| Configure-NAK | 若支持对端的协商选项，但不认可该项协商的内容，则回应Configure-NAK报文，在Configure-NAK的选项中填上本端期望的内容，如：对端MRU值为1500，而本端期望MRU值为1492，则在Configure-NAK报文中填上1492。 |
| Configure-Reject | 若不能支持对端的协商选项，则回应Configure-Reject报文，报文中带上不能支持的选项 |
PAP/CHAP认证
LCP协商完成后，会进入认证阶段，该分为PAP认证（口令验证协议）和CHAP认证（挑战握手验证协议）两种认证方式。
-
PAP认证
两次握手，明文传输口令，安全性低：
PAP为两次握手协议，是通过用户名和密码来对用户进行认证，并且是以明文的方式传递用户名和密码。PPPoE Server（或者RADIUS服务器）根据本端的用户表查看用户名和密码是否正确。适用于网络安全要求相对较低的环境。
-
CHAP认证
三次握手， 密文传输口令。
CHAP认证为三次握手协议，也是由PPPoE Server（或者RADIUS服务器）根据本端的用户表查看用户名和密码是否正确。但是CHAP认证方式只在网络上传输用户名，不传输用户密码，安全性比PAP要高。
NCP协商
NCP有很多种，如IPCP、BCP、IPv6CP，最为常用的是IPCP（Internet Protocol Control Protocol）协议。NCP的主要功能是协商PPP报文的网络层参数，如IP地址，DNS Server IP地址，WINS Server IP地址等。PPPoE用户主要通过IPCP来获取访问网络的IP地址或IP地址段。 NCP流程与LCP流程类似，用户与ME设备之间互相发送NCP Config-Request报文并且互相回应NCP Config-Ack报文后，标志NCP己协商完，用户上线成功，可以正常访问网络了。 NCP协商协议的基本流程如下：
用户和接入设备对IP服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。 同LCP类似，当Request中的一些选项不被接收方接受时， 接收方不会回复Configuration-ACK报文，而是回复其他如Configuration-NACK报文。
NCP Configuration-Request报文
NCP Configuration-NAK报文
会话维持（Session Keep-alive）
设备主动发送Echo Request进行PPPoE心跳保活，若3次未得到服务器的响应，则设备主动释放地址。发LCP Echo Request 的时候，魔术字字段要和之前通信的Configure_Request使用的魔术字字段保持一致。 有些设备或终端不支持主动发送 Echo-Request 报文, 只能支持回应Echo-Reply报文。
会话结束（Session Termination）
PPPoE 还有一个PADT（PPPOE Active Discovery Terminate）分组，它可以在会话建立后的任何时候发送，来终止PPPoE会话，也就是会话释放。它可以由主机或者接入集中器发送，目的地址填充为对端的以太网的MAC地址。
文章来源：https://www.toymoban.com/news/detail-417165.html
当对方接收到一个 PADT（PPPOE Active Discovery Terminate）分组，就不再允许使用这个会话来发送PPP业务。PADT分组不需要任何标签，其CODE字段值为0xa7（PADT Code），SESSION-ID字段值为需要终止的PPP会话的会话标识号码。在发送或接收PADT后，即使正常的PPP终止分组也不必发送。PPP对端应该使用PPP协议自身来终止PPPoE会话，但是当PPP不能使用时，可以使用PADT。文章来源地址https://www.toymoban.com/news/detail-417165.html
到了这里，关于PPPOE协议的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![[Linux系统]部署PPPoE+radius服务器](https://imgs.yssmx.com/Uploads/2024/04/847129-1.png)
