PPPoE协议

迷南。 2022-07-26 00:27 391阅读 0赞

**PPP over Ethernet（PPPoE）协议**，是在以太网络中转播PPP帧信息的技术，尤其适用于ADSL等方式。可以使以太网的主机通过一个简单的桥接设备连到一个远端的接入集中器上。通过pppoe协议，远端接入设备能够实现对每个接入用户的控制和计费。**PPPoE协议的作用是：实现有效的用户管理，进行网络接入计费等**

## PPPoE帧 ##

PPPoE帧的内容作为以太帧的负载存在， 当一个以太帧为PPPoE帧时，其Len/Type字段应该为0x8863（表示PPPoE的发现阶段）或者0x8864（表示PPPoE的会话阶段）。

![这里写图片描述][20160405172137269]  
\+ **Ver：** 版本号， 4bit， PPPoE规范的本版本为0x01  
\+ **Type：** 类型， 4bit， PPPoE规范的本版本应设置为0x01  
\+ **Code：**代码字段、8bit， 根据两阶段中各种数据包的不同功能而值不同。

<table> 
 <thead> 
  <tr> 
   <th>Code</th> 
   <th>Description</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0x00</td> 
   <td>表示PPP会话阶段</td> 
  </tr> 
  <tr> 
   <td>0x09</td> 
   <td>PADI 报文</td> 
  </tr> 
  <tr> 
   <td>0x07</td> 
   <td>PADO报文</td> 
  </tr> 
  <tr> 
   <td>0x19</td> 
   <td>PADR报文</td> 
  </tr> 
  <tr> 
   <td>0x65</td> 
   <td>PADS报文</td> 
  </tr> 
 </tbody> 
</table>

\+ **Session-ID:**会话ID， 8bit， 是一个网络字节序的无符号值， 其值会在Discovery数据包中定义。 对一个给定的PPP会话来说，该值是一个固定值。 Session-ID 与 以太网Src\_addr 和 Dst\_addr一起实际定义了一个PPP会话。 Session-ID不允许使用0xFFFF（该值保留作将来使用）。  
\+ **Length：** PPPoE负载长度，不包括以太网头部和PPPoE头部。  
\+ **Payload：** PPPoE帧的净负载，在不同的阶段PPPoE的Payload字段的格式有很大区别。在PPPOE的发现阶段时，该域内会填充一些Tag（标记）；而在PPPOE的会话阶段，该域则携带的是PPP的报文。

下图是一个PPPoE的PADO报文

# PPPoE链接 建立过程 #

**PPPoE链路的建立** 和**PPP会话阶段**  
**发现阶段：**

Created with Raphaël 2.1.0ClientClientServerServerPADIPADOPADRPADS

**会话阶段：**

Created with Raphaël 2.1.0ClientClientServerServerLCPPAP/CHAP认证NCP链路建立

**断开连接：**

Created with Raphaël 2.1.0ClientClientServerServerPADT(Terminate)

## (一）发现阶段： ##

当主机开始PPPoE进程时，它必须先识别接入端的以太网MAC地址，建立PPPoE的Session\_ID。这就是Discovery阶段的目的。  
PPPoE发现阶段的主要目的是确定一对一的关系，包括以下两部分

*  互相识别对方的Mac地址 （包括查找NAS服务器）
 *  建立PPPoE的Session\_ID

Discovery阶段由四个步骤组成。完成之后通信双方都知道了PPPoE Session\_ID以及对方以太网地址，它们共同确定了唯一的PPPoE会话。

Created with Raphaël 2.1.0ClientClientServerServerPADI（PPPoE Active Discovery Initial） Dst:广播 Src：ClientPADO（PPPoE Active Discovery Offer） Dst:Client Src：ServerPADR（PPPoE Active Discovery Request） Dst:Server Src：ClientPADS（PPPoE Active Discovery Session-confirmation） Dst:Client Src：Server

### 1. PADI 报文 ###

主机在本以太网内“广播“一个PADI（PPPoE Active Discovery Initial）报文，在此报文中包含主机想要得到的服务类型信息。  
在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为空，就不进行此项检测，直接按照原来的程序执行。

### 2. PADO报文 ###

以太网内的所有服务器收到这个PADI报文后，将其中请求的服务与自己能提供的服务进行比较，可以提供此服务的服务器发回PADO（PPPoE Active Discovery Offer）报文。  
PADO报文的CODE字段值为0×07，SESSION-ID字段值仍为0×0000。  
![这里写图片描述][20160405172202660]

### 3. PADR报文 ###

主机可能收到多个服务器的PADO报文，主机将依据PADO的内容，从多个服务器中选择一个，并向它发回一个会话请求报文PADR（PPPoE Active Discovery Request）。  
由于用户主机在收到PADO报文后，就获知了访问集中器的MAC地址，因此PADR的报文以单播的形式存在。  
PADR报文的CODE字段为0x19，SESSION\_ID字段值仍为0×0000。  
![这里写图片描述][20160405172218457]

### 4. PADS报文 ###

服务器产生唯一的会话标识，标识和主机的这段PPPoE会话。并把此会话标识通过会话确认报文PADS（PPPoE Active Discovery Session-confirmation）发回给主机，若没有错误，双方进入PPP Session阶段。  
PADS报文，CODE字段值为0×65，SESSION-ID字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。  
接入服务器发送确认数据包后，它就可以进入到PPP会话阶段。当主机接收到该确认数据包后，它就可以进入PPP会话阶段。

![这里写图片描述][20160405172249379]

## （二）PPP会话阶段 ##

PPP会话的建立，需要两端的设备都发送LCP数据包来配置和测试数据通信链路。  
用户主机与接入集中器根据在发现阶段所协商的PPP会话连接参数进行PPP会话。一旦PPPoE会话开始，PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。PPPoE会话的SESSION-ID一定不能改变，并且必须是发现阶段分配的值。

### PPP工作流程 ###

**a） LCP协商阶段：**创建链路完成链路的启动、测试、任选参数的协商和最终链路的断开  
**b）认证阶段：** LCP向对端发送协商请求， 双方确定链路的配置参数后，LCP向认证层发送Up事件。常用的认证协议有PAP（口令验证协议）和CHAP（挑战握手验证协议）。  
**c） NCP协商阶段（IPCP协议）：**调用链路层创建阶段选定的网络控制层协议。主要包括动态分配IP地址功能等。常用的NCP协议有IPCP协议。  
**d）会话维持阶段：**进行PPPoE心跳保活  
**e）PPP正常终结：** NCP分别终结，然后LCP终结，最后物理层终结

### 1. LCP协商阶段 ###

LCP的Client和Server进行报文的交互，协商一些通信参数，LCP协商阶段完成最大传输单元（MTU），是否进行认证和采用何种认证方式（Authentication Type）的协商。  
　　LCP协议数据报文可以分为以下几种：  
\+ **链路配置报文：**用来建立和配置一条链路，主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject报文  
\+ **链路维护报文：**用来管理和调试链路，主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request报文  
\+ **链路终止报文：**用来终止一条链路，主要包括Terminate-Request和Terminate-Reply报文

**LCP协商过程**

Created with Raphaël 2.1.0ClientClientServerServerConfig-RequestConfig-AckConfig-RequestConfig-Ack

LCP 两端通过发送LCP Config-Request和Config-Ack交互协商选项。 LCP一方通过发送LCP Config-Request来向另一方请求自己需要的LCP协商选项。如果Config-Request报文的接收方支持并接受这些选项则回复LCP Config-Ack报文。如果Config-Request部分（或者全部）不支持所有的LCP选项则回复其他报文。  
**（1）Config-ACK：**若完全支持对端的LCP选项，则回应Config-ACK报文，报文中必须完全协带对端Request报文中的选项。  
**（2）Config-NAK：**若支持对端的协商选项，但不认可该项协商的内容，则回应Config-NAK报文，在Config-NAK的选项中填上自己期望的内容，如:对端MRU值为1500，而自己期望MRU值为1492，则在Config-NAK报文中埴上自己的期望值1492。  
**（3）Config-Reject：**若不能支持对端的协商选项，则回应Config-Reject报文，报文中带上不能支持的选项，如Windows拨号器会协商CBCP（被叫回呼），而ME60不支持CBCP功能，则回将此选项拒绝掉。

**—-Config-request报文———**  
![这里写图片描述][20160405172000628]  
**—-Config-Ack报文———**  
![这里写图片描述][20160405172009347]

### 2. 认证阶段 ###

PPP认证，常用认证协议有**PAP（口令验证协议）和CHAP（挑战握手验证协议）**  
　　会话双方通过LCP协商好的认证方法进行认证，如果认证通过了，才可以进行下面的网络层的协商。认证过程在链路协商结束后就进行。  
\+ **PAP验证：** 两次握手，明文传输口令，安全性低  
\+ **CHAP验证：** 三次握手， 密文传输口令。  
PAP验证过程

Created with Raphaël 2.1.0ClientClientServerServerRadiusRadiusAuth-ReqAuth-ReqAuth-AckAuth-ACK

CHAP验证过程：

Created with Raphaël 2.1.0ClientClientServerServerRadiusRadiusWaitChallenge（CHAP）ResponseResponseSuccessSuccess

### 3. 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协商协议的基本流程如下：

Created with Raphaël 2.1.0ClientClientServerServerConfiguration-RequestConfiguration-ACKConfiguration-RequestConfiguration-ACK

用户和接入设备对IP服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。  
　　通LCP类似，当Request中的一些选项不被接收方接受时， 接收方不会回复Configuration-ACK报文，而是回复其他如Configuration-NACK报文。

NCP Configuration-Request报文  
![这里写图片描述][20160405172018612]

NCP Configuration-NAK报文

![这里写图片描述][20160405172025425]

### 4. 会话维持（Session Keep-alive） ###

设备主动发送Echo Request进行PPPoE心跳保活，若3次未得到服务器的响应，则设备主动释放地址。发LCP Echo Request 的时候，魔术字字段要和之前通信的Configure\_Request使用的魔术字字段保持一致。  
有些设备或终端不支持主动发送 Echo-Request 报文, 只能支持回应Echo-Reply报文。

### 5. 会话结束（Session Termination） ###

PPPoE 还有一个PADT（PPPOE Active Discovery Terminate）分组，它可以在会话建立后的任何时候发送，来终止PPPoE会话，也就是会话释放。它可以由主机或者接入集中器发送，目的地址填充为对端的以太网的MAC地址。  
当对方接收到一个 PADT（PPPOE Active Discovery Terminate）分组，就不再允许使用这个会话来发送PPP业务。PADT分组不需要任何标签，其CODE字段值为0xa7（PADT Code），SESSION-ID字段值为需要终止的PPP会话的会话标识号码。在发送或接收PADT后，即使正常的PPP终止分组也不必发送。PPP对端应该使用PPP协议自身来终止PPPoE会话，但是当PPP不能使用时，可以使用PADT。

[20160405172137269]: /images/20220724/08f5e9dfd8994e818ce9ac7a8c69659e.png
[20160405172202660]: /images/20220724/4df72d6d97bc462d8e7828c5fe7c7ce5.png
[20160405172218457]: /images/20220724/dbf5ffacb3314c498e8c8bf381bc7152.png
[20160405172249379]: /images/20220724/ea3c9749328248638cea2b07136ca4b2.png
[20160405172000628]: /images/20220724/f141d3a475f94b52ad85b55e47b4639e.png
[20160405172009347]: /images/20220724/2b6d1643c28e4d9a97e7dea7b448815b.png
[20160405172018612]: /images/20220724/45f728c9a5b54bf0972de1843ed09f54.png
[20160405172025425]: /images/20220724/c308c4a9f3ec4af9b78e3ceaf4b832f7.png