PPP协议

痛定思痛。 2022-07-26 00:26 276阅读 0赞

# PPP协议概述 #

PPP（Point-to-Point Protocol点到点协议）是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。这种链路提供全双工操作，并按照顺序传递数据包。  
**PPP协议支持以下功能：**

*  IP地址的动态分配和管理
 *  同步或异步的物理层通信
 *  链路的配置、质量检测和纠错
 *  多种配置参数选项的协商

PPP是目前使用最广泛的数据链路层协议，不管是低速的拨号猫连接还是高速的光纤链路，都适用PPP协议。因特网用户通常都要连接到某个ISP 才能接入到因特网。 PPP协议就是用户计算机和ISP进行通信时所使用的数据链路层协议。 ISP使用PPP协议为计算机分配一些网络参数（如IP地址、域名等）。

PPP协议是一个协议集，主要包含下面三部分

1.  LCP（ Link Control Protocol）链路控制协议
2.  NCP（ Network Control Protocol）
3.  PPP的扩展协议（如Multilink Protocol，

后面我们会提到PPP链路建立过程中涉及到了 **认证**， 但认证阶段使用到的CHAP/PAP等协议本身不属于PPP协议的范畴。（其实默认情况下“认证阶段”是缺省的，即PPP链路默认是不进行认证的）

### PPP协议的六个阶段 ###

**1. 链路不可用阶段：** 初始阶段  
**2. 链路建立阶段：** LCP协商，（协商认证方式等）  
**3. 验证阶段：** PAP/CHAP验证  
\*\*4. 网络层协议阶段：\*\*NCP协商  
**5. PPP会话维持阶段：** 维持PPP会话， 定时发送Echo Request报文，并等待Echo Reply报文  
**6. 网络终止阶段：** 终止PPP会话，回到链路不可用阶段。

## （一）PPP 帧 ##

PPP帧从HDLC（High-level link Control）。  
![这里写图片描述][20160405171237406]

*  **Flag：**标志位、用于标识帧的开始和结束
 *  **Addr：**地址位，用于标识Station地址。PPP帧发源自HDLC帧，保留了此字段。对于PPP帧来说，由于是点对点协议，不需要地址位。PPP帧的地址位恒为0xFF。（PPP协议被运用在点对点链路上，不需要知道对端的链路地址，因为点对点链路，如PPPoE帧头中，已经确定了对端的地址）。
 *  **Control：**在DHLC帧中，Control位用来标识帧的顺序和重传行为，但由于该功能在PPP协议中并没有普遍实现，因此PPP帧中，Control值固定为）0x03.
 *  **Protocol：**协议字段，标识所携带报文的类型。如0x0021时，表示PPP帧的信息字段是IP数据报文。不同的Protocol标识Data字段的不同含义。  
    ISO标准下 的协议域类型：

<table> 
 <thead> 
  <tr> 
   <th>Protocol</th> 
   <th>对应的Data域的含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0x0***-0x3***</td> 
   <td>网络层的数据报文</td> 
  </tr> 
  <tr> 
   <td>0x4***-0x7***</td> 
   <td>与NCP无关的第整流量</td> 
  </tr> 
  <tr> 
   <td>0x8***-0xb***</td> 
   <td>网络控制协议（NCP）的数据报文</td> 
  </tr> 
  <tr> 
   <td>0xc***-0xf***</td> 
   <td>链路控制协议(LCP)的数据报文</td> 
  </tr> 
 </tbody> 
</table>

常用的几种Protocol取值：

<table> 
 <thead> 
  <tr> 
   <th>Protocol</th> 
   <th>信息字段</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0x0021</td> 
   <td>IP数据报</td> 
  </tr> 
  <tr> 
   <td>0x8021</td> 
   <td>网络控制数据NCP</td> 
  </tr> 
  <tr> 
   <td>0xC021</td> 
   <td>链路控制数据LCP</td> 
  </tr> 
  <tr> 
   <td>0xC023</td> 
   <td>安全性认证PAP</td> 
  </tr> 
  <tr> 
   <td>0xC223</td> 
   <td>安全性认证CHAP</td> 
  </tr> 
 </tbody> 
</table>

\+ **Data：** 信息字段，即PPP帧的负载(如LCP帧、NCP帧）.信息域缺省时最大长度不能超过1500字节，其中包括填充域的内容  
\+ **Pad:** 填充字段  
\+ **FCS：**循环冗余码。 覆盖了两个Flag（不包括）之间的字段。

*  注：  
    　　由于Addr和Control字段在PPP帧中是固定值，在传输过程中经常使用Address and Control Field Compression (ACFC)选项省略掉这两个字段。  
    ![这里写图片描述][20160405171256063]

## PPP工作流程 ##

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

# 一、 LCP 协商 #

**LCP（Link Control Protocol）**用来创建链路完成链路的启动、测试、任选参数的协商和最终链路的断开  
　　LCP的操作只关注连接的两端，而不在乎Mac层协议（如以太网协议、WIFI），也就是不需要考虑具体的传输媒介是什么。

## LCP帧 ##

LCP帧以PPP帧为基础。格式如下：  
![这里写图片描述][20160405171305563]

LCP帧有自己特有的四个字段：Code、Ident、Length、LCP Data。  
另外，（PPP帧的）字段Protocol的值应为0xC021，标识该PPP帧为LCP帧。  
\+ **Code：** 表示LCP数据报文（Request或Reply）类型。 值如下：

<table> 
 <thead> 
  <tr> 
   <th>Code</th> 
   <th>Description</th> 
   <th></th> 
   <th>Code</th> 
   <th>Description</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0x01</td> 
   <td>configure-request</td> 
   <td></td> 
   <td>0x08</td> 
   <td>Protocol-REJECT</td> 
  </tr> 
  <tr> 
   <td>0x02</td> 
   <td>configure-ACK</td> 
   <td></td> 
   <td>0x09</td> 
   <td>echo-request</td> 
  </tr> 
  <tr> 
   <td>0x03</td> 
   <td>configure-NACK</td> 
   <td></td> 
   <td>0x0A</td> 
   <td>echo-reply</td> 
  </tr> 
  <tr> 
   <td>0x04</td> 
   <td>configure-REJECT</td> 
   <td></td> 
   <td>0x0B</td> 
   <td>discard-request</td> 
  </tr> 
  <tr> 
   <td>0x05</td> 
   <td>teminate-request</td> 
   <td></td> 
   <td>0x0C</td> 
   <td>identification</td> 
  </tr> 
  <tr> 
   <td>0x06</td> 
   <td>terminate-ACK</td> 
   <td></td> 
   <td>0x0D</td> 
   <td>Time-Remaining</td> 
  </tr> 
  <tr> 
   <td>0x07</td> 
   <td>code-REJECT</td> 
   <td></td> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

\+ **Ident：**标识域。LCP报文的序列号，用于匹配Request和Reply报文。 由Request帧的发送者生成，在之后的序列帧中递增。对于应答报文（如ACK，NACK，REJECT应答报文， Ident帧的值是从Request报文中copy过来的。（由此，Request方可以通过Ident字段识别Rely的对应关系）。  
\+ **Length:** LCP报文的长度，以字节为单位。 Code+Ident+Length+LCP Data  
\+ **LCP Data：** LCP数据报文。

***不同类型的LCP帧的作用：***

<table> 
 <thead> 
  <tr> 
   <th>帧 类型</th> 
   <th>用途</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>configure 帧</td> 
   <td>对链路两端进行最基本的配置</td> 
  </tr> 
  <tr> 
   <td>Terminate帧</td> 
   <td>链路通信完成时，对链路连接进行清理操作</td> 
  </tr> 
  <tr> 
   <td>echo 帧</td> 
   <td>用来确认一些操作， 一个活动的链路随时会发送echo帧</td> 
  </tr> 
  <tr> 
   <td>discard-request 帧</td> 
   <td>用于测量链路的性能</td> 
  </tr> 
  <tr> 
   <td>identification 帧 Time-Remaining帧</td> 
   <td>用于一些管理操作</td> 
  </tr> 
 </tbody> 
</table>

总的来说，LCP帧根据用途可以分为三大类， **链路配置报文，链路终止报文，链路维护报文：**

(1). **链路配置报文：**  
　　包含Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。  
　　当通信双方需要建立链路时，双方都需要发送Config-Request报文并携带自已所希望协商的配置参数选项。当接收方收到Config-Request报文时，会根据是否识别、认可Configure-Request报文中的配置参数来在剩下的三种配置报文中选择一种应答。 如果识别且认可全部参数，则应答Configure-ACK报文（携带全部配置参数）； 如果识别，但只认可部分配置参数，则应答configure-NACK报文（携带不认可的配置参数）； 如果不能识别所有的配置，则应答configure-Reject报文（携带全部报文）。  
LCP的配置选项（配置报文的数据域），是一些TLV（Type、Length、Value）组。

(2). **链路终止报文：**  
　　包含Terminate-Request和Terminate-Reply两种报文。  
　　LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端会持续发送Terminate-Request报文，直到收到一个 Terminate-Reply为止。接收端一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply报 文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。  
(3). **链路维护报文：**  
　　链路维护报文中比较杂。比如，我们需要定时进行PPP保活（确认当前PPP链路是否仍在活跃状态），则PPP链路双方分别发送Echo Request报文，如果对方回复了Echo Reply报文，则表示PPP链路仍在活跃状态。

**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报文———**  
![这里写图片描述][20160405171319579]  
**—-Config-Ack报文———**  
![这里写图片描述][20160405171327875]

# 二. 认证阶段 #

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

# 三. 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报文

![这里写图片描述][20160405171339313]  
NCP Configuration-NAK报文  
![这里写图片描述][20160405171346594]

# 四. 会话维持（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地址。  
当对方接收到一个 PADT（PPPOE Active Discovery Terminate）分组，就不再允许使用这个会话来发送PPP业务。PADT分组不需要任何标签，其CODE字段值为0xa7（PADT Code），SESSION-ID字段值为需要终止的PPP会话的会话标识号码。在发送或接收PADT后，即使正常的PPP终止分组也不必发送。PPP对端应该使用PPP协议自身来终止PPPoE会话，但是当PPP不能使用时，可以使用PADT。

[20160405171237406]: /images/20220724/bc27ee6a9f7643ba8caebfd69d297832.png
[20160405171256063]: /images/20220724/cfc6007de183495d910a5bac93dfe41e.png
[20160405171305563]: /images/20220724/2ccd5947f11b4b99a67ed1ce741bb258.png
[20160405171319579]: /images/20220724/f26afa5b27ad4471984dc7ee7c00499c.png
[20160405171327875]: /images/20220724/44c3bc16d32744a2af06fe041cb496b0.png
[20160405171339313]: /images/20220724/14c9cb4fcf5c4a54979e56fde173d713.png
[20160405171346594]: /images/20220724/f03cdbab33ef438e8929eb4fb3106142.png