广域网技术-PPP协议

---

前言

以下内容主要参考华为培训IE课件、HedEx。未来几章节重点是广域网PPP、MP、PPPoE等技术。

---

PPP协议

PPP（Point-to-Point Protocol）协议，是一种在点到点链路上承载网络层数据包的数据链路层协议，主要用来支持全双工的同/异步链路上进行点到点之间的数据传输。

（一）使用PPP协议的目的

PPP协议是在串行线IP协议SLIP（Serial Line IP）的基础上发展起来的。由于SLIP协议只支持异步传输方式、无协商过程（尤其不能协商如双方IP地址等网络层属性）、只能承载IP一种网络层报文等缺陷，在发展过程中逐步被PPP协议所替代。

（二）PPP协议的优点

PPP协议有如下优点：

1）对物理层而言，既支持同步链路又支持异步链路，而如X.25、FR等数据链路层协议只对同步链路提供支持，SLIP只支持异步链路。
2）有一个易扩充的协议框架，便于支持新协议。
3）支持各种链路层参数的协商（LCP）。
4）能承载多种网络层报文，提供各种NCP协议（如IPCP、IPXCP等），用于各网络层属性的协商，更好地支持了网络层协议。
5）提供验证协议CHAP、PAP，更好地保证了网络的安全性。
6）无重传机制，网络开销小，速度快。

（三）PPP架构和报文格式

1、基本架构

PPP协议处于TCP/IP的数据链路层，主要用在支持全双工的同异步链路上，进行点到点之间的数据传输。


PPP的协议族包括：
LCP，链路控制协议，主要用来协商链路参数，建立、拆除和监控PPP链路。
NCP，网络层控制协议，主要用来协商在数据链路上所传输的数据包的格式与类型。
PPP扩展协议，主要用于提供对PPP功能的进一步支持，如PAP、CHAP等。

2、报文格式

（1）PPP报文的格式如上图所示，各字段含义如下：

①Flag字段
Flag字段标识一个物理帧的起始和结束，该字节为0x7E。
②Address字段
Address字段可以唯一标识对端。但因为PPP协议是被运用在点到点的链路上，因此，使用PPP协议互连的两个通信设备无须知道对方的数据链路层地址。按规定将该字节填充为全1的广播地址。
③Control字段
该字段默认值为0x03，表明为无序号帧，PPP默认没有采用序列号和确认来实现可靠传输。Address字段和Control字段一起标识此报文为PPP报文，即PPP报文头为FF03。
④Protocol字段
Protocol字段可用来区分PPP数据帧中Information字段所承载的数据报类型。该字段的内容必须依据ISO3309的地址扩展机制所给出的规定。如果当发送端发送的PPP数据帧的Protocol字段不符合其规定，接收端则会认为此数据帧是不可识别的，接收端向发送端发送一个Protocol-Reject报文。
常见的协议代码有：0021—IP，002b—Novell IPX，8021—IPCP，802b—Novell IPXCP，c021—LCP，c023—PAP，c223—CHAP等。
⑤Information字段
Information字段，最大长度是1500字节，其中包括填充字段的内容。Information字段的最大长度称为最大接收单元MRU。MRU的缺省值为1500字节，在实际应用中可根据实际需要进行MRU的协商。（联想：以太网接口的MTU默认也为1500B）
⑥FCS字段
FCS字段的功能主要对PPP数据帧传输的正确性进行检测。

（2）在链路建立阶段，PPP协议通过LCP报文进行链路的建立和参数协商过程。此时，LCP报文作为PPP数据帧的载荷数据被封装在Information字段中，PPP数据帧的Protocol字段值为C021。LCP报文的格式如上图所示，各字段含义如下：

①code字段
代码字段，长度1个字节，主要用来标识LCP数据报文的类型。
在链路建立阶段，接收方接收到LCP数据报文。当其code字段的值无效时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。
常见code值对应的报文类型如下图所示：

code值	报文类型
0x01	Configure-Request
0x02	Configure-Ack
0x03	Configure-Nak
0x04	Configure-Reject
0x05	Terminate-Request
0x06	Terminate-Ack
0x07	Code-Reject
0x08	Protocol-Reject
0x09	Echo-Request
0x0A	Echo-Reply
0x0B	Discard-Request
0x0C	Reserved

②Identifier字段
标识字段，长度1个字节，用来匹配请求和响应，当标识域值非法时，该报文被丢弃。
通常一个配置请求报文的ID是从0x01开始逐步加1的。当对端接收到该配置请求报文后，无论使用何种报文回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致。
③Length字段
长度字段，该LCP报文的总字节数。它是code字段、Identitifier字段、Length字段和Data字段的长度的总和。
④Data字段
Data字段，包含的是协商报文的内容，由多个TLD组成。其中，type为协商选项类型，Length为协商选项长度，一个TLD组的总长度，Data为协商选项的具体内容。
常见Type中的协商类型值如下表所示：

协商类型值	协商报文类型
0x01	Maximum-Receive-Unit
0x02	Async-Control-Character-Map
0x03	Authentication-Protocol
0x04	Quality-Protocol
0x05	Magic-Number
0x06	RESERVED
0x07	Protocol-Field-Compression
0x08	Address-and-Control-Field-Compression

3、PPP基本原理

PPP的建链过程

核心是：LCP协商、认证协商和NCP协商
PPP链路的建立是通过一系列的协商完成的。其中，LCP除了用于建立、拆除和监控PPP数据链路，还主要进行链路层参数的协商，如工作方式、MRU、验证协议、magic-number等；NCP主要用于协商在该数据链路上所传输的数据包的格式与类型，如IP地址等。

下图是PPP协议整个链路建立过程需经历的阶段的状态转移图。需要特别说明的是，此处列出的是PPP的工作阶段，并非PPP的协议状态。由于PPP是由一组协议组成的，因此PPP本身没有协议状态。只有特定的的协议如LCP和NCP等才有协议状态和状态转换（协议状态机）。

（1）PPP链路建立过程的简单描述如下：
①PPP协议运行总是以Dead阶段开始和结束。通常处在这个状态的时间很短，仅仅是检测到硬件设备后（即硬件连接状态为UP）就进入Establish阶段。
②在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式（SP/MP）、MRU、magic number、验证方式等。LCP协商成功后进入Opened状态，表示底层链路已经建立。
③如果配置了验证，将进入Authentication阶段，开始CHAP或PAP验证。如果没有配置验证，则直接进入Network阶段。（LCP协商认证方式，Auth协商认证数据）
④对于Authenticate阶段，如果验证失败，进入Terminate阶段，拆除链路，LCP状态状态转为Closed。如果验证成功，进入Network阶段，此时LCP状态仍为Opened，而NCP状态从Initial转到Starting。
⑤在Network阶段，PPP链路进行NCP协商，NCP协商根据网络层协议的不同分为IPCP、MPLSCP等协商。IPCP协商主要包括双方的IP地址。通过NCP协商来选择和配置一个网络层协议。只有相应的网络层协议协商成功后（相应协议的NCP协商状态为Opened），该网络层协议才可以通过这条PPP链路发送报文。例如，IPCP协商通过后，这条PPP链路才可以承载IP报文。
⑥NCP协商成功后，PPP链路将一直保持通信。PPP运行过程中，可以随时中断连接，物理链路断开、认证失败、超时定时器时间到、管理员通过配置关闭连接等动作都可能导致链路进入Terminate阶段。
⑦进入Terminate阶段后且资源释放完毕，即进入Dead阶段。

（2）在点对点链路的配置、维护和终止过程中，PPP需经历以下几个阶段：
①Dead阶段（链路不可用阶段）
有时也称为物理层不可用阶段。当通信双方的两端检测到物理线路激活（通常是检测到链路上有载波信号）时，就会从Dead阶段跃迁至Establish阶段。
②Establish阶段（链路建立阶段）
在链路建立阶段，LCP的状态机会发生2次变化。
当链路处于Dead阶段时，LCP的状态机处于Initial或Starting。当检测到链路可用时，物理层会向链路层发一个Up事件。链路层收到该事件后，会将LCP的状态机从当前状态改变为Request-Sent（请求发送状态），根据此时的状态机LCP会进行相应的动作，也就是开始发送Configure-Request报文来配置数据链路。
无论哪一端接收到了Configure-Ack报文时，LCP的状态机又要发生改变，从当前状态改变为Opened状态。进入Opened状态后收到Configure-Ack报文的一方则完成了当前阶段，应该向下一阶段跃迁。
③Authenticate阶段（验证阶段）
PPP链路缺省情况下，不进行验证。如果要求验证，在Establish阶段必须指定验证协议。PPP验证有2种用途，一是用于主机和路由器之间，通过PPP网络服务器交换电路或拨号接入连接的链路，另一个是用于专用线路。
PPP验证提供了2种验证方式，PAP和CHAP。验证方式的选择是依据在Establish阶段双方进行协商的结果。然而，链路质量的检测也会在这个阶段同时发生，但协议规定不会让链路质量的检测无限制的延迟验证过程。
在这个阶段，仅支持链路控制协议LCP、验证协议和质量检测数据报文，其它的数据报文都会被丢弃。如果在这个阶段再次收到了Configure-Request报文，则又会返回到Establish阶段。
④Network阶段（网络层协议阶段）
一旦PPP完成了前面几个阶段，每种网络层协议（IP、IPX和AppleTalk）会通过各自相应的网络控制协议进行配置，例如：通过IPCP进行IP协议的配置。每个NCP协议可在任何时间打开和关闭，当一个NCP的状态机变成Opened状态时，则PPP就可以开始在链路上承载网络层的数据包报文了。
⑤Terminate阶段（网络终止阶段）
PPP能在任何时候终止链路。当载波丢失、认证失败、链路质量检测失败或管理员人为关闭链路等情况均会导致链路终止。

4、LCP协商过程

（1）LCP的报文类型

LCP的报文类型，通过LCP报文中的code字段的值来区分。常用的LCP报文有Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject、Terminate-Request、Terminate-Ack、Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply等。

需要注意的是Configure-Ack、Configure-Nak和Configure-Reject的区别。
Configure-Ack，表示对端发送的Configure-Request中的参数能被本地识且协商成功，
Configure-Nak，表示对端发送的Configure-Request中的参数能被本地识别但协商失败，
Configure-Reject，表示对端发送的Configure-Request中的参数不能被本地识别（自然还到不了协商步骤）。
再具体点说，到底何时发回Configure-Ack、Configure-Nak和Configure-Reject，看type字段的取值是否合法以及参数协商成功否，type取值合法且参数协商成功则发回Configure-Ack，type取值合法但参数协商失败则发回Configure-Nak，type取值不合法则发回Configure-Reject。

（2）LCP协商的参数

LCP链路建立需要协商多种参数，主要有工作方式、MRU、认证协议和magic-number。
MRU，最大接收单元，表示PPP数据帧中Information字段的总长度。协商规则：使用两端较小值。默认是1500。
认证协议，协商规则：被认证方必须支持认证方使用的认证协议，默认是不认证的。
Magic-number，魔术字，是一个随机产生的数字，用于检测链路环路。
如果收到的LCP报文中的魔术字和本地产生的魔术字相同，则认为链路有环路。
协商规则：一端支持另一端不支持，表示链路无环路，协商成功；两端都支持则使用检测机制检测环路。默认是启用的。

注意：如果两台路由器已经成功建立了LCP链接（均未配置认证），后来更改一方的认证方式为PAP，那么两台路由器之间的LCP连接是否会断开？
答：当双方成功建立LCP链接后，每隔一段时间进行一次简易协商（Echo-Request/Echo-Reply），只协商magic number字段（实验观察发现），不再协商认证方式。所以LCP链接成功建立后，即使更改了一方的认证方式为PAP，LCP连接仍然是成功的。但此时若重启路由器等等，LCP连接需要重新协商，此次协商会协商所有参数，所以这种情况下LCP协商失败，LCP连接建立失败。

（3）魔术字及其防环的详细介绍

1）LCP使用魔术字（Magic-Number）检测链路环路和其它异常情况。魔术字为随机产生的一个数字，随机机制需要保证两端产生相同魔术字的可能性几乎为0。
2）收到一个Configure-Request报文之后，其包含的魔术字需要和本地产生的魔术字做比较，如果不同，表示链路无环路，则使用Confugure-Ack报文确认（其他参数也协商成功），表示魔术字协商成功。在后续发送的报文中，如果报文含有魔术字字段，则该字段设置为协商成功的魔术字，LCP不再产生新的魔术字。
3）如果收到的Configure-Request报文和自身产生的魔术字相同，则发送一个Configure-Nak报文，携带一个新的魔术字。然后，不管新收到的Configure-Nak报文中是否携带相同的魔术字，LCP都发送一个新的Configure-Request报文，携带一个新的魔术字。如果链路有环路，则这个过程会不停的持续下去，如果链路没有环路，则报文交互会很快恢复正常。

（4）LCP协商过程中的典型情况

①LCP协议—参数协商成功

如果R2能识别Configure-Request报文中的所有链路层参数，并且认为每个参数的取值都是可以接受的，则向R1回应一个Configure-Ack报文。


②LCP协议—参数协商时能识别但不能接受

如果R2能识别Configure-Request报文中的所有链路层参数，但认为部分或全部参数的取值不能接受，则发回一个Configure-Nak报文。在这个Configure-Nak报文中，只包含不能接受的那部分参数，并将取值修改为R2可以接受的值。R1接收到后，修改参数，重新发送Configure-Request报文。


③LCP协议—参数协商时不能识别

如果R2不能识别Configure-Request报文中携带的部分或全部链路层参数，则R2回应一个Configure-Reject报文。在此Configure-Reject报文中，只包含不被识别的部分参数。


④LCP协议—检测链路状态（简易协商）

LCP建立连接之后，系统会使用Echo-Request报文和Echo-Reply报文检测链路状态，收到一个Echo-Request报文后应当回应一个Echo-Reply报文，表示链路状态正常（两个报文中只包含MagicNumber参数）。


⑤LCP协议—连接关闭

5、PPP认证过程

（1）PAP认证（Password Authentication Protocol）

①PAP验证报文
在PPP报文的帧格式中，我们了解到，当PPP报文的protocol字段取值为0xC023时，其载荷数据为PAP报文，即PAP报文封装在protocol字段为0xC023的PPP数据链路层帧的information字段中。PAP数据报的帧格式如下图所示：

其中，code字段代表了PAP报文类型，主要有Authenticate-Request报文、Authenticate-Ack报文和Authenticate-Nak报文。

Authenticate-Request报文

Authenticate-Ack报文/Authenticate-Nak报文

②PAP验证过程
PAP验证是明文验证，即口令为明文。另外，PAP验证为2次握手验证协议，被验证方主动发起第一次握手，发出Authenticate-Request报文，验证方回应第二次握手，发出Authenticate-Ack或Authenticate-Nak。
验证过程仅在链路初始建立阶段进行。当链路建立阶段结束后，用户名和密码将由被验证方重复地在链路上发送给验证方，直到验证通过或者中止连接。具体过程如下：

被验证方把本地用户名和口令发送到验证方；验证方根据本地用户表（AAA下配置）查看是否正确，然后做出不同反应。

③PAP配置

验证方：

ppp authentication-mode pap
//接口下，配置PPP认证方式为PAP

aaa
local-user huawei password cipher 123
local-user huawei service-type ppp
//AAA下，配置用户名密码和服务类型（查资料了解AAA详细配置）

被验证方：

ppp pap local-user huawei password cipher 123
//接口下，配置本地被对端以PAP方式验证时，本地发送的PAP用户名和密码

（2）CHAP认证（Challenge-Handshake Authentication Protocol）

①CHAP验证报文
在PPP报文的帧格式中，我们了解到，当PPP报文的protocol字段取值为0xC223时，其载荷数据为CHAP报文，即CHAP报文封装在protocol字段为0xC223的PPP数据链路层帧的information字段中。CHAP数据报的帧格式如下图所示：

其中，code字段代表了CHAP数据报的类型，主要有Challenge报文、Response报文、Success报文和Failure报文。


Challenge报文和Response报文

Success报文和Failure报文


②CHAP验证过程
CHAP验证是密文验证，验证过程中在网络上传输Identifier、用户名、随机数和MD5值，不传输密码，因此安全性要比PAP高。另外，CHAP验证为3次握手验证协议，首先，验证方主动发起第一次握手，发出Challenge报文，然后，被验证方回应第二次握手，发出Response报文，最后，验证方回应第三次握手，发出Success/Failure报文。

CHAP验证有2种方式，单向验证和双向验证。单向验证是指一端作为验证方，另一端作为被验证方；双向验证是单向验证的简单叠加，即两端都是既作为验证方又作为被验证方。在实际应用中一般只采用单向验证。具体过程如下图所示：

③CHAP4种常见情况
CHAP单向验证过程分2种情况：验证方接口配置了用户名和验证方接口没有配置用户名。（可将被认证方接口是否配置密码考虑在内，细分为4种情况，其中第4种情况“认证方接口没有配置用户名，被认证方接口没有配置密码”必然失败）

i.验证方接口配置了用户名（再区分被验证方接口是否配置了密码）
验证方主动发出Challenge报文，该报文中包含Identitier、随机数和用户名。
被验证方接收到Challenge报文后，先检查被验证方接口上是否配置了password：
如果配置了则被验证方使用接口密码计算MD5，即MD5（随机数、Identifier、接口密码），将生成的MD5值和接口用户名发回给验证方（Response报文）；
如果接口未配置password，则根据Challenge报文中的用户名在本端的AAA用户数据库中查找对应的密码计算MD5，即MD5（随机数、Identifier、AAA对应密码），将生成的密文和接口用户名发回给验证方（Response报文）。

验证方根据Response报文中用户名（即被验证方接口用户名）查询本端AAA数据库中对应的密码，同样用MD5（随机数、Identifier、AAA对应密码）加密，比较二者的密文，根据比较结果返回不同的响应。

ii.验证方接口没有配置用户名（这种情况，被验证方接口必须配置密码）
验证方主动发出Challenge报文，该报文中包含Identitifier、随机数，不含用户名。
被验证方接收到Challenge报文后，使用接口密码计算MD5，即MD5（随机数、ID、接口密码），将生成的MD5值和接口用户名发回验证方（Response报文）。
验证方根据Response报文的用户名（即被验证方的用户名）查询数据库中的对应密码，进行MD5（随机数、Identifier、AAAUI应密码）加密，比较二者的密文，根据比较结果返回不同的响应。

④CHAP的配置

验证方：

ppp authentication-mode chap
//接口下，配置PPP认证方式为CHAP

aaa
local-user huawei password cipher 123
local-user huawei service-type ppp
//AAA下，配置用户名、密码和服务类型（查资料了解AAA详细配置）

被验证方：

ppp chap user huawei
ppp chap password cipher 123
//接口下，配置本地被对端以CHAP方式验证时，本地发送的CHAP用户名和密码

6、NCP协商过程

NCP协议，主要用来协商在该数据链路上所传输的数据包的格式与类型。能承载多种网络层报文，提供各种NCP协议（如IPCP、IPXCP等），用于各网络层属性的协商，更好地支持了网络层协议。

（1）NCP报文

NCP报文的类型主要有Configure-Request、Configure-Ack、Configure-Nak等。

（2）NCP协商参数

根据承载的网络层报文的不同，NCP分为IPCP、IPXCP、MPLSCP等等。
其中，IPCP，用于协商控制IP参数（主要是检查对端IP是否可用、是否冲突），使PPP可用于传输IP数据包。

（3）NCP协商过程

①IPCP静态协商IP地址（双向：都是静态）

如上图所示，两端配置的IP地址分别是12.1.1.1/24和12.1.1.2/24（两端IP地址即使不在同一网段也会通过IPCP协商）。两端静态配置IP地址的时候会进行如下协商（主要是检测IP地址是否可用、是否冲突）：
R1和R2都要发送Configure-Request报文，在此报文中包含本地配置的IP地址；
R1和R2接收到对端的Configure-Request报文之后，检查其中的IP地址，如果IP地址是一个合法的单播地址，而且和本地配置的IP地址没有冲突，则认为对端可以使用该地址，回应一个Configure-Ack报文。

②IPCP动态协商IP地址（双向：一方动态、一方静态，看具体配置）

如上图所示，R1配置为请求对端分配IP地址，R2配置静态IP地址12.1.1.2/24，并且启用R2给对端分配IP地址的能力，给R1分配IP地址12.1.1.1。
两端动态协商IP地址过程如下：
R1向R2发送一个Configure-Request报文，此报文中含有IP地址0.0.0.0，一个含有0.0.0.0的IP地址的Configure-Request报文表示向对端请求IP地址；
R2收到该报文后，认为其中包含的地址（0.0.0.0）不合法，于是使用Configure-Nak回应一个新的IP地址12.1.1.1；
R1收到此Configure-Nak报文后，更新本地IP地址，并重新发送一个Configure-Request报文，包含新的IP地址12.1.1.1；
R2收到Configure-Request报文后，认为其中包含的IP地址为合法地址，回应一个Configure-Ack报文；
同时，R2也要向R1发送Configure-Request报文请求使用地址12.1.1.2，R1认为此地址合法，回应Configure-Ack报文。

（4）IPCP动态协商IP地址配置

ip pool HuaWei
network 12.1.1.0 mask 24
//用户视图下，定义一个地址池

remote address pool HuaWei
//接口下，被请求方启用远端地址池

ip address ppp-negotiate
//请求方启用IPCP动态协商IP地址，启用后即会向对端请求IP地址

---

总结

本章重点为PPP的定义、建链过程及LCP协商、PPP认证与NCP协商过程。