PPP详解Word下载.docx

PPP详解Word下载.docx

《PPP详解Word下载.docx》由会员分享，可在线阅读，更多相关《PPP详解Word下载.docx（26页珍藏版）》请在冰豆网上搜索。

为了能适应复杂多变的网络环境，PPP协议提供了一种链路控制协议来配置和测试数据通信链路，它能用来协商PPP协议的一些配置参数选项；

处理不同大小的数据帧；

检测链路环路、一些链路的错误；

终止一条链路。

网络控制协议（NCP）根据不同的网络层协议可提供一族网络控制协议，常用的有提供给TCP/IP网络使用的IPCP网络控制协议和提供给SPX/IPX网络使用的IPXCP网络控制协议等，但最为常用的是IPCP协议。

当点对点的两端进行NCP参数配置协商时，主要是用来获得通信双方的网络层地址。

PPP协议格式

上图中PPP的flag字段恒为0x7f，地址（adress）字段恒为0xff，控制（control）字段恒为0x03.协议（protocol）字段表示PPP报文中封装的payload（data字段）的类型，如果为0x0021，则表示PPP封装的IP报文，0x002B表示IPX报文，0x0029表示AppleTalk报文，这几种都属于PPP的数据报文；

如果为0xC021则表示PPP的LCP报文（用来协商连接），如果为0x8021则表示PPP的NCP报文（用来协商封装的三层协议），这些属于PPP的控制报文。

0xc023表示PAP协议认证报文，0xc223表示CHAP协议认证报文。

紧接在起始标志字节后的一个字节是地址域，该字节为0xFF。

我们熟知网络是分层的，且对等层之间进行相互通信，而下层为上层提供服务。

当对等层进行通信时首先需获知对方的地址，而对不同的网络，在数据链路层则表现为需要知道对方的MAC地址、X.21地址、ATM地址等；

在网络层则表现为需要知道对方的IP地址、IPX地址等；

而在传输层则需要知道对方的协议端口号。

例如如果两个以太网上的主机希望能够通信的话，首先发送端需获知对端的MAC地址。

但由于PPP协议是被运用在点对点的链路上的特殊性，它不像广播或多点访问的网络那样，需要标识通信的对方。

因为点对点的链路就可以唯一标识对方，因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址，所以该字节已无任何意义，按照协议的规定将该字节填充为全1的广播地址。

PPP协议状态机

PPP协议状态机如下图所示：

1、在上图的链接建立阶段，PPP使用LCP报文来协商连接（一种发送配置请求，然后接收响应的简单“握手”过程，不做过多介绍，感兴趣可以去细读RFC1661），该阶段主要是发送一些配置报文来配置数据链路，这些配置的参数不包括网络层协议所需的参数。

协商中双方获得当前点对点连接的状态配置等，之后的“鉴别”阶段使用哪种鉴别方式也在这个协商中确定下来。

2、鉴别阶段是可选的，如果链接协商阶段并没有设置鉴别方式，则将忽略本阶段直接进入“网络”阶段。

鉴别阶段使用链接协商阶段确定下来的鉴别方式来为连接授权，以起到保证点对点连接安全，防止非法终端接入点对点链路的功能。

链路质量的检测也会在这个阶段同时发生，但协议规定不会让链路质量的检测无限制的延迟验证过程。

常用的鉴别认证方式有CHAP和PAP方式。

CHAP方式的原理是：

由一端定期发起挑战“challenge”，收到“challenge”的一端将收到的“challenge”报文中的密钥使用之前双发协商好的一种算法加密后再把结果发回发起端，这种算法应该是结果唯一（不同输入必得到不同输出）且不可逆（由输出无法得到输入）的，发起端也使用该算法计算后验证结果是否正确来为对端授权认证。

一个常用的方案实例是：

发起端发送随机长度及内容的字符串加上自己的用户名作为“密钥”发送出来，接受到“challenge”的一方将收到的字符串和与对方用户名相对应的本端用户的密码使用MD5算法计算后发回，然后发起端将收到的计算结果和本端MD5计算该随机字符串加自己密码的结果相对照，如果双发一致，则认证成功。

PAP方式简单很多，原理：

直接由被验证方将自己的用户名和密码明文方式发送给对端，由对端对用户名和密码验证来决定是否认证成功。

所以，比较而言，CHAP是一种相对更安全一些的验证方式。

需要注意的是，PPP两端双方向的鉴权方式可以不同，即A端为B端鉴权时使用PAP方式（B发送自己的用户名和密码给请A认证），而同时B端使用CHAP方式为A端鉴权（B向A发起CHAP挑战），是完全可以的。

3、如果鉴别阶段成功，则PPP状态机进入“网络”阶段。

这个阶段主要是使用NCP报文来协商将PPP封装怎样的网络层的问题。

NCP报文及协商流程和LCP极为相似，就不过多介绍了。

4、经过网络阶段后，PPP状态机进入OPEN打开状态，在这个状态下，PPP链路上的三层数据报文即可正常通信了。

5、一旦任何一端收到LCP或NCP的链路关闭报文（一般而言协议是不要求NCP有关闭链路的能力的，因此通常情况下关闭链路的数据报文是在LCP协商阶段或应用程序会话阶段发出的）、授权失败、链路质量检测失败、物理层无法检测到载波、管理人员对该链路进行关闭操作，都会将该条链路终止，从而终止PPP会话。

LCP协议

LCP是LinkControlProtocol（链路控制协议）的简称，它是PPP协议的一个子集。

此外还提供协商封装格式的可选选项，具体包括以下内容：

●验证----验证过程要求主叫方输入身份信息，让被叫方验证是否建立这个呼叫。

●压缩-----减少帧中的数据量从而提高效率。

●差错检测-----用Quality选项来检测链路质量，进行差错检测。

●多连接----多链路捆绑，在一条链路负载达到一定数值的情况下，启用第二条链路。

多条链路间可实现负载均衡。

●PPP回拨----允许路由器作为回叫服务器。

客户端发起初始的呼叫并请求回叫。

初始呼叫被终止，回叫服务器根据配置回叫客户端。

这种机制增强了安全性。

LCP协议格式

LCP位于物理层之上，负责设备之间链路的创建、维护和终止。

LCP数据报文被封装在PPP信息字段中，该PPP协议字段表示类型为十六进制0xc021（链路控制协议）。

LCP的协议结构：

8bit

16bit

变长

code

Indentifier

Length

Data

代码域code：

长度为一个字节，主要用来标识LCP数据报文的类型。

在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。

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

标识域Indentifier：

一个字节，其目的是用来匹配请求和响应报文。

一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文（Config-Request报文），而这几个请求报文的数据域Data可能是完全一样的，而仅仅是它们的标识域不同罢了。

通常一个配置请求报文的ID（标识域 

Indentifier）是从0x01开始逐步加1的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可能是Config-Ack、Config-Nak和Config-Reject三种报文中的一种）来回应对方，要求回应报文中的ID要与接收报文中的ID一致，当通信设备收到回应后就可以将该回应ID与发送时ID的进行比较来决定下一步的操作。

长度域Length：

两个字节长，表示总字节数（代码域+标志域+长度域+数据域）。

长度域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值。

数据域Data：

内容根据不同的LCP数据报文的内容也是不一样的。

LCP报文详解

下面说一下LCP包括的几种报文类型，不同的报文在标识域中所填充的内容也不同。

LCP报文主要分为：

1、链路配置报文，主要用来建立和配置一条链路；

2、链路终止报文，主要用来终止一条链路；

3、链路维护报文，主要用来维护和调试链路。

链路配置报文

链路配置报文主要用来建立和配置一条链路，包括：

Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。

链路配置报文与其它两类报文有着明显的区别，它主要是用来协商链路的配置参数选项的，因此这种报文的数据域还要携带许多配置参数选项的，而另外两类报文中部分报文的格式会稍有不同（请参见RFC1661），下图表明了数据配置选项的报文格式：

类型域1字节长；

长度域1字节，表示当前LCP配置选项的总长度（类型域+长度域+数据域）。

1、当通信双方需要建立链路时，无论哪一方都需要发送Config-Request报文并携带每一端自已所希望协商的配置参数选项。

下表为可选的配置参数选项：

类型值

参数选项

0x00

Reserved

0x05

Magic-Number

0x01

Maximum-Recieve-Unit

0x06

CBCP

0x02

Async-Control-Character-Map

0x07

Protocol-Field-Compress

0x03

Authentication-Protocol

0x08

Address-and-Control-Field-Compress

0x04

Quality-Protocol

0x0D

Multilink-Protocol

2、当接收方收到Config-Request报文时，会在剩下的三种类型的报文中选择一种来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件：

A、能不能完全识别配置参数选项的类型域。

我们知道一个Config-Request报文中会同时携带多个配置参数选项，而对于一个支持PPP协议的通信设备也不一定会支持上表中所有列出的配置选项，即使支持，也可能在实际应用中关闭掉某些选项功能。

（例如：

当使用PPP协议通信的一端可能将一些无用的配置选项都关闭了，而仅支持0x01和0x03两个配置参数选项，因此当对方发送的Config-Request报文中含有0x04配置选项时，对于本端而言这个配置参数选项就无法识别，也即是不支持这个配置参数选项的协商）。

B、如果能支持完全识别配置参数选项，能不能认可Config-Request报文中配置参数选项数据域中的内容（例如：

当一端发送魔术字配置参数选项中的魔术字为全0，而对端认为应该为其它值，这种情况就属于不支持配置参数选项中的内容）。

所以依据上面的两个条件，我们就可以明确在回应对方配置请求报文时，采用何种报文回应：

A、当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文，并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。

当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。

假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：

下面结合LCP报文格式说明报文的具体内容。

注意：

说明中省略了FCS字段（后面的说明也是如此）。

上图02表示LCP配置选项0x02，字符转义。

上图05表示LCP配置选项表中的0x05，魔术字。

以此类推，蓝色部分都表示LCP配置选项表中类型值。

当对端正确接收到了该报文后，应该发送一个Config-Ack报文，报文内容如下：

B、当接收Config-Request报文的一端B能识别发送端A所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端B将会给对端A回应一个Config-Nak报文（注意，是能够识别，只是对部分参数内容不认可，所以不是Config-Reject报文）。

该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。

然后，当A收到Config-Nak报文后，会重新发送Config-Request报文，而这个Config-Request报文与上一次所发送的Config-Request报文区别在于：

那些被对端B不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中（Config-Nak报文发送回来的那些配置参数选项）。

假设还是刚才的Config-Request报文：

该数据报文中有下划线的配置参数选项的内容为对端不认可的。

当对端B正确接收到了该报文后，发现类型域为0x02的配置参数选项可识别，但该配置参数选项数据域的内容不认可，应发送一个Config-Nak报文且该报文中将携带希望的配置参数选项内容，报文内容如下：

当发端A收到该报文后会重新发送一个Config-Request报文，报文内容如下：

C、当接收Config-Request报文的一端B不能识别所有的发送端A发送过来的配置参数选项时，此时接收端B将会向对端A回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项。

当对端A接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。

对于PPP的两个端点而言，两者是独立完成各自的配置参数选项的协商过程的。

链路终止报文

链路终止报文主要用来终止一条链路，分为Terminate-Request和Terminate-Reply两种报文。

LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端A会持续发送Terminate-Request报文，直到收到一个Terminate-Reply为止。

接收端B一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply报文，同时等待对端A先将链路断开后，再完成本端的所有断开的操作。

LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项。

对于链路终止报文也同样需要ID一致，当接收到Terminate-Reply报文才会做链路终止操作。

链路维护报文

除上述两种报文类型以外，剩余的所有报文类型均归属链路维护报文。

（1）当接收端发现LCP报文的代码域code是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的全部内容附加上（注：

code只有在LCP协议头中才存在）。

（2）当接收端发现所接收到的PPP数据帧的协议域Protocol是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了（注：

Protocol只有在PPP协议头中才存在）。

Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。

在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。

（3）Echo-Request报文和Echo-Reply报文主要用来检测双向链路上自环的问题，除此之外还可附带做一些链路质量的测试和其它功能。

当LCP状态机处于Opened状态时，如果接收到了Echo-Request，就需向对端回送一个Echo-Reply报文。

否则在其它LCP状态下，该类型的报文会被丢弃。

这种类型数据报文的长度域后不是直接跟数据域，而是要插入4个字节的Magic-Number（魔术字），该魔术字是在LCP的Config-Request的配置参数选项协商时获得的。

魔术字

最后说一下魔术字的含义，这是在链路建立过程中比较重要的一个参数，这个参数是在Config-Request里面被协商的，主要的作用是防止环路，如果在双方不协商魔术字的情况下，某些LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全0；

反之，则填充为配置参数选项协商后的结果。

魔术字在目前所有的设备当中都是需要进行协商的，它被放在Config-Request的配置选项参数中进行发送，而且需要由自身的通信设备独立产生，协议为了避免双方可能产生同样的魔术字，从而导致通信出现不必要的麻烦，因此要求由设备采用一些随机方法产生一个独一无二的魔术字。

一般来说魔术字的选择会采用设备的系列号、网络硬件地址或时钟。

双方产生相同魔术字的可能性不能说是没有的，但应尽量避免，通常这种情况是发产在相同厂商的设备进行互连时，因为一个厂商所生产的设备产生魔术字的方法是一样的。

我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端B收到一个Config-Request报文时，会将此报文与上一次所接收到（应该是上一次发送出）的Config-Request进行比较，如果两个报文中所含的魔术字不一致的话，表明链路不存在环路。

但如果一致的话，接收端B认为链路可能存在环路，但不一定存在环路，还需进一步确认。

此时接收端B将发送一个Config-Nak报文，并在该报文中携带一个重新产生的魔术字，而且此时在未接收到任何Config-Request或Config-Nak报文之前，接收端B也不会发送任何的Config-Request报文。

这时我们假设可能会有以下两种情况发生：

1.链路实际不存在环路，而是由于对方A在产生魔术字时与接收端B产生的一致，但实际这种情况出现的概率是很小的。

当Config-Nak被对端A接收到后，A应该发送一个Config-Request报文（此报文中的魔术字为接收到的Nak报文中的），当B接收到后，与上次的Config-Request比较，由于接收端B已经在上一次的Nak报文中产生了一个不同的魔术字，此时接收端B收到的Config-Request报文中的魔术字与上次B发出的Config-Request配置请求报文中不一样，所以接收端B可断定链路不存在环路。

2.链路实际上确实存在环路，一段时间后Config-Nak报文会返回到发送该报文的同一端B。

这时接收端B比较这个Config-Nak报文与上一次发出去的Config-Nak报文一样，因此链路存在环路的可能性又增大了。

我们知道当一端收到了一个Config-Nak报文时，又会发送一个Config-Request报文（该报文中的魔术字与Config-Nak中的一致），这样又回到了最初的状态，在这条链路上就会不断的出现Config-Request、Config-Nak报文，因此这样周而复始下去，接收端就会认为PPP链路存在环路的可能性在不断增加，当达到一定数量级时，就可认为此链路存在环路。

（注意，不是第一次受到相同的魔术字就判断有环路的）

但在实际应用中根据不同设备实现PPP协议的方法，我们在链路环路检测时可采用两种方法。

第一种机制就是如上面所述的，这个过程不断地重复，最终可能会给LCP状态机发一个Down事件，这时可能会使LCP的状态机又回到初始化阶段，又开始新一轮的协商。

当然对于某些设备还会采用第二种机制，就是不产生任何事件去影响当前LCP的状态机，而是停留在请求发送状态。

但这时认为链路有环路的一端设备需要不断的向链路上发送Echo-Request报文来检测链路环路是否被解除，当接收端收到Echo-Reply报文时，就认为链路环路被解除，从而就可能进行后续的PPP的过程。

好了，基本上通过3篇PPP闲谈，我们可以比较彻底的了解PPP协议的工作机制和特点，其实，会者不难，协议都是人制订的，只有简单易用的协议才会最终保留下来，就像TCP/IP打败OSI一样。

所以，只要静下心来，没有什么高深的。

可能这3篇文章里面有部分个人理解错误的地方，希望大家可以多提意见，大家共同进步。

NCP协议

NCP协议的数据报文是在网络阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。

NCP协议主要包括IPCP、IPXCP等，但我们在实际当中最常遇见的也只有IPCP协议了，如果对IPXCP或其它的一些网络控制协议有兴趣，则可参见RFC1552。

下面我们主要介绍IPCP。

IPCP控制协议

IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商，负责建立，使能和中止IP模块。

IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。

IPCP包在PPP没有达到网络层协议阶段以前不能进行交换，如果有IPCP包在到达此阶段前到达会被抛弃。

IPCP协议格式

代码域1字节长，标识域1字节长，长度域2字节长。

IPCP的数据的报文同LCP的数据报文非常类似，不同之处有两点：

1、IPCP是在网络层协议阶段协商配置参数选项，code字段为0x8021，而LCP协议则是在