PPP协议详解

１．简介 

   PPP是为了在点对点物理链路(例如RS232串口链路、电话ISDN线路等)上传输OSI模型中的网络层报文而设计的，它改进了之前的一个点对点协议–SLIP协议–只能同时运行一个网络协议、无容错控制、无授权等许多缺陷，PPP是现在最流行的点对点链路控制协议。这种连接提供了同时的双向的全双工操作，并且假定数据包是按顺序投递的。ＰＰＰ连接提供了一种广泛的解决办法，方便地将多种多样不同的值作为最大接收单元的值。

填充域
在传输中，信息域可能会由附加任意数目的字节填充至最大接收单元长度。这由每个协议负责将信息域和填充域区分开来。

PPP协议概览

       标准的HDLC封装只支持高层的IP协议，不支持其他高层协议。思科对标准帧协议进行了改进，增加了协议域字段，来支持多种网络层协议。

        思科改进的HDLC可用于在思科的设备之间进行点到点连接。当连接非思科的设备时，PPP是比较可行的，因为所有厂家实现的PPP都是相同的。

         PPP协议和大多数硬件兼容，且PPP协议能够承载多种三层协议的数据。

          PPP是一种数据链路层协议，遵循HDLC（高级数据链路控制协议）族的一般报文格式。PPP是为了在点对点物理链路(例如RS232串口链路、电话ISDN线路等)上传输OSI模型中的网络层报文而设计的，它改进了之前的一个点对点协议–SLIP协议–只能同时运行一个网络协议、无容错控制、无授权等许多缺陷，PPP是现在最流行的点对点链路控制协议。

PPP协议主要包括三部分：LCP（Link Control Protocol）链路控制协议、NCP（Network Control Protocol）网络控制协议和PPP的扩展协议（如Multilink Protocol）。
PPP协议默认是不进行认证配置参数选项的协商，它只作为一个可选的参数，当点对点线路的两端需要进行认证时才需配置。

LCP是PPP协议的一个子集。为了能适应复杂多变的网络环境，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是Link Control Protocol(链路控制协议)的简称，它是PPP协议的一个子集。为了能适应复杂多变的网络环境，PPP协议提供了一种链路控制协议来配置和测试数据通信链路，它能用来协商PPP协议的一些配置参数选项；处理不同大小的数据帧；检测链路环路、一些链路的错误；终止一条链路。

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

● 验证----验证过程要求主叫方输入身份信息，让被叫方验证是否建立这个呼叫。
● 压缩-----减少帧中的数据量从而提高效率。
● 差错检测-----用Quality选项来检测链路质量，进行差错检测 。
● 多连接----多链路捆绑，在一条链路负载达到一定数值的情况下，启用第二条链路。多条链路间可实现负载均衡。
●PPP回拨----允许路由器作为回叫服务器。客户端发起初始的呼叫并请求回叫。初始呼叫被终止，回叫服务器根据配置回叫客户端。这种机制增强了安全性。

LCP协议格式

LCP位于物理层之上，负责设备之间链路的创建、维护和终止。LCP数据报文被封装在PPP信息字段中，该PPP协议字段表示类型为十六进制0xc021 (链路控制协议)。

LCP的协议结构：

8bit	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字节长。

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

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

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

2、代码域字段。LCP共包括十几种报文，而IPCP只包括7种报文，但它的报文类型只是LCP数据报文的一个子集（只有LCP代码域从1到7这七种报文：Config-Request，Config-Ack，Config-Nak，Config-Reject，Terminate-Request，Terminate-Ack和Code-Reject），而且实际的数据报文交换过程中链路终止报文一般而言是不在网络协议阶段使用的。

IPCP协议类型域的值如下所示：

0x01 IP-Addresses   IP地址选项配置

0x02 IP-Compression-Protocol 

0x03 IP-Address   IP地址配置

IP-Addresses  0x01 ，IP地址选项配置。使用本IP地址选项配置是不好的，这在实现中已经证明了。IP地址配置(0x03)可以替换这个域， 应该使用IP地址配置0x03。如果接收到的配置请求中包括IP地址或IP地址选项，此选项不应该在配置请求中包括这个选项。只有因为IP地址选项而收到配置拒绝时，或接收到的配置未确认中包括IP地址选项作为附加选项时，才发送这一选项。 

IP-Compression-Protocol  0x02，用来提供协商使用指定的压缩协议，默认不使用压缩选项。选项的格式如下： 

IP压缩协议域指明要使用的压缩协议，协议编号与PPP协议域中的协议编号相同。

目前支持的协议有Van Jacobson Compressed TCP/IP[29],编号为002D(16进制)。 

IP-Address 0x03，IP地址配置。IP-Address用来协商本地使用的IP地址。该选项允许请求发送者提供自己的IP地址（静态）或请求对方给自己分配IP地址（动态），在后一种情况下，请求者发送一个全为0的IP地址，对方在一个NAK数据帧中给出请求者的IP地址。

我们依据两端设备的配置选项可将IPCP的协商过程分为：“静态”和“动态”。我们在下面会具体描述这两个过程。

以下就具体介绍一下IPCP控制协议的静态和动态的两个过程，实际上两者的区分是在于互连设备IP地址的获取过程。

静态协商

静态协商，也即是不协商。点对点的通信设备两端在PPP协商之前已配置好了IP地址，所以就无须在网络层协议阶段协商IP地址，而双方唯一要做的就是告诉对方自身的IP地址。

在IPCP控制协议完成整个配置的过程时，最理想的情况将会看到前述的四种报文，而无其它报文再被发送。

如果当配置请求中所携带的网络层配置参数选项类似于LCP配置参数选项协商过程一样，可能会有对方不识别的配置参数选项或不被对方所认可的配置参数选项的内容。

这样在这个阶段的协商过程中可能还会看到其它的一些报文。

在静态协商时，如果IPCP的Config-Request报文中只含有地址配置参数选项时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与LCP阶段的一样，而我们这里只提到了IP地址配置参数选项），无论是发送方还是接收方都同时发送Config-Request报文，其中配置选项中只含有各自的IP地址。

当对端收到该报文后，会发送一个Config-Ack报文，这个目的是告诉对端我已经知道了你的IP地址，对路由器而言会增加一条到对端接口的主机路由。 

刚进入网络层协议阶段时，IPCP的状态机是initial的，但当完成了上述的整个过程后，IPCP的状态机改变为Opened，双方也就可以开始网络层数据网的传送了。

IPCP协议中并未规定点对点两端的IP地址必须在同一网段。当一端接收到Config-Request报文后，它从报文的配置参数选项中可获知对端的IP地址，但并不与本端的IP地址进行比较。我们也知道，一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段，也无条件向对方回应Config-Ack报文。

因此说点对点通信的两端如果是手动设置每一端的IP地址时，无须双方地址在同一网段。

例：

假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方设置IP地址为192.168.0.1，接收方设置IP地址为192.168.0.2，发送方发送Config-Request报文内容如下：

在这个例子中我们能看见明显的改变之处在于PPP协议域字段由原先的0xC021（LCP）改变为0x8021（NCP中的IPCP），下划线的部分表示本端的IP地址(192.168.0.1)。

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

同样的接收方给发送方也发送一个Config-Request报文内容如下，但此时报文中IP地址配置参数选项的值为本端的IP地址（192.168.0.2）：

发送方回应一个Config-Ack报文给接收方，报文内容如下：

动态协商

动态协商是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址。

这个过程实际上可与窄带拨号上网的过程相一致，如果我们想用计算机上网，均会安装一个拨号适配器，而且计算机中的拨号网络适配器是采用动态获取IP地址的方式。

这个例子与上一个例子相似，也就是在IPCP的Config-Request报文中只携带IP地址的配置参数选项。如果是配置参数选项中含有其它配置参数选项，则可能会遇到其它的一些情况（如不识别配置参数选项的代码域或不认可配置参数选项的内容，但对于这些情况的处理方法和LCP配置参数选项的处理方法一致）。

在这种情况下，发送方连续发送了两次Config-Request报文，才能完成发送方的协商过程。而接收方仍然只需要发送一次Config-Request即可完成本端的协商过程。

由于发送方没有配置IP地址（而是动态获取IP地址），所以在IPCP的Config-Request报文的IP地址配置参数配置选项中的IP地址填充全0（也即是0.0.0.0），当接收方收到该配置请求报文后会检测IP地址的内容，如果发送为全0，则认为对端的这个IP地址不是我所希望的值，这样就回应一个Config-Nak报文，并将希望分配给对方的IP地址填充到Config-Nak报文内。这时当接收方收到Config-Nak报文后，就会重新发送一个Config-Request报文，这个报文中的IP地址配置选项为对方在Nak报文中所提供的。

接收方IP地址的配置过程与静态时的一样，只需发送一个Config-Request报文即可，当收到发送方的Config-Ack报文，就表示接收方的IP地址配置完成。

例：

假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方没有配置IP地址，而接收方配置了IP地址为192.168.0.2，接收方可给发送方分配IP地址（192.168.0.1），发送方发送给接收方的Config-Request报文内容如下：

 

有下划线的部分表示本端的IP地址。当接收方端正确接收到了该报文后，应该回应一个Config-Nak报文，报文内容如下：

 

当发送方正确收到该报文后，重新发送一个Config-Request报文，报文内容如下：

接收方再次收到发送方的一个Config-Request报文，此时将回应一个Config-Ack报文，报文内容如下：

同样的接收方给发送方也发送一个Config-Request报文，报文内容如下：

发送方回应一个Config-Ack报文给接收方，报文内容如下：

ＰＰＰ连接操作

３．１概述 
为了在点到点连接中建立通信，ＰＰＰ连接的每一端都必须首先发送ＬＣＰ数据 
包来配置和测试数据连接。在连接建立后，对等实体还有可能需要认证。 
然后，ＰＰＰ必须发送ＮＣＰ数据包来选择一种或多种网络层协议来配置。一旦 
被选中的网络层协议被配置好后，该网络层的数据报就可以在链路上传送了。 
链路将保持可配置的状态直到有ＬＣＰ数据包和ＮＣＰ数据包终止连接，或者由 
其他外部事件发生时（例如非活动时钟计时已满或网络管理人员的干涉）。

３．２状态图 
在配置维持和终止点到点连接的过程中，ＰＰＰ连接经历了几个不同的阶段，这 
些阶段由以下简化的状态图说明：

 

 

+------+ +-----------+ +--------------+ 
| | 连接 | | 已打开 | | 成功/无 
| 死亡 |------->| 建立 |---------->| 认证 |--+ 
| | | | | | | 
+------+ +-----------+ +--------------+ | 
^ | | | 
| 失败 | 失败 | | 
+<--------------+ +----------+ | 
| | | 
| +-----------+ | +---------+ | 
| 断开 | | | 正在关闭 | | | 
+------------| 终止 |<---+<----------| 网络 |<-+ 
| | | | 
+-----------+ +---------+

３．３连接死亡阶段（物理层未准备好） 
一个连接的开始和结束都要经历此阶段。当一个外部事件（例如检测到载波或网 
络管理人员配置）指示物理层已准备好并可以使用时，ＰＰＰ将进入建立连接阶段。 
在此阶段，ＬＣＰ协议自动机（后面将提到）处在初始或正在开始状态。当进入 
到建立连接阶段后会引发ＵＰ事件通知ＬＣＰ协议自动机。

应用注意事项： 
典型的，一个连接将在调制解调器连接断开后自动返回到此阶段。在使用电话线 
的连接情况下，这个阶段将相当的短，短到很少有足够的时间能用仪器检测到它的存在。

３．４建立连接阶段 
链路控制协议（ＬＣＰ）通过交换配置数据包建立连接。当ＬＣＰ协议自动机进 
入已打开状态，并且发送和接收过配置确认数据包时，为建立连接的交换过程才完成。 
所有的配置选项都被假定为缺省值，除非在配置交互的过程中改变。关于ＬＣＰ 
配置选项的进一步讨论参见后面的章节。 
有一点是非常重要的，就是那些只有与特定网络层协议无关的选项才能被ＬＣＰ 
配置。配置单独的网络层协议是在网络层协议阶段由相应的网络控制协议来配置。 
在此阶段接收到的任何非ＬＣＰ数据包将被静默丢弃。 
接收到ＬＣＰ配置请求数据包将引起ＰＰＰ连接从网络层协议阶段或认证阶段返 
回到建立连接阶段。

３．５认证阶段 
在某些连接时，在允许网络层协议数据包交换之前希望对对等实体进行认证。 
缺省时，认证不是必要的。如果应用时希望对等实体使用某些认证协议进行认证 
，这种要求必须在建立连接阶段提出。

认证阶段应该紧接在建立连接阶段后。然而，可能有连接质量的决定并行出现。 
应用时绝对不允许连接质量决定数据包的交换使认证有不确定的延迟。 
认证阶段后的网络层协议阶段必须等到认证结束后才能开始。如果认证失败，将转而进入 
终止连接阶段。 
仅仅是连接控制协议、认证协议、连接质量监测的数据包才被允许在此阶段中出现。所有 
其它在此阶段中接收到的数据包都将被静默丢弃。

应用注意事项： 
应用时不能简单的因为超时或缺少回应就认为认证失败。应该允许重传，仅当试 
图认证的次数超过一定的限制时才进入终止连接阶段。 
如果对方拒绝认证，己方有权进入终止连接阶段。

３．６网络层协议阶段 
一旦ＰＰＰ完成了上述阶段，每一个网络层协议（例如ＩＰ、ＩＰＸ、 
ＡｐｐｌｅＴａｌｋ）必须单独的由相应的网络控制协议（ＮＣＰ）配置。 
每一个网络控制协议可以随时打开或关闭。

应用注意事项： 
因为可能一开始就会使用需要花费大量时间的连接质量决定，所以当等待对方进 
行网络控制协议配置时应该避免使用固定的超时限制。 
当一个网络控制协议自动机达到已打开的状态时，ＰＰＰ连接上就可以传送相应 
的网络层协议数据包。当接收到的任何所支持的网络层协议数据包时，只要相应的网络控 
制协议状态自动机未进入已打开状态，都将作静默丢弃处理。

应用注意事项： 
只要ＬＣＰ协议状态自动机处于已打开的状态，任何接收到的不支持的协议数据 
包都将返回协议拒绝包（后面将提到）。所支持的协议数据包都将静默丢弃。 
在此阶段，连接上流通的包括ＬＣＰ数据包、ＮＣＰ数据包和网络层协议数据包。

３．７终止连接阶段 
PＰＰ连接可以随时终止。原因可能是载波丢失、认证失败、连接质量失败、超 
时计数器溢出，或者网络管理员关闭连接。 
ＬＣＰ通过交换连接终止包来终止连接。当连接正在被终止的时候，ＰＰＰ会通 
知网络层以便它采取相应的动作。

在交换过终止请求包后，将通知物理层断开以便使连接真正终止，尤其是在认证失败的时 
侯。发送连接终止请求包的一方应该等待接收到连接终止确认包之后或超时计数器计满之 
后再断开。收到连接终止确认包的一方应该等待对方首先断开，并且决不能断开直到至少 
有一个超时计时器在发送了终止连接确认包之后溢出。然后ＰＰＰ应该进入连接死亡阶段 
。 
在此阶段所有接收到的非ＬＣＰ数据包都将被静默丢弃。

应用注意事项： 
关闭时使用ＬＣＰ就已足够。并不需要每一个ＮＣＰ都发送终止连接数据包。相 
反的，一个ＮＣＰ协议自动机关闭并不能关闭整个ＰＰＰ连接，即使这个ＮＣＰ协议自动 
机是当前唯一处于已打开状态。

４． 选项协商自动机 
有限状态自动机由事件、动作、状态迁移定义。事件包括接收外部命令，诸如打开、关闭 
、超时计时器溢出和接收到对方发送过来的数据包。动作包括打开超时计数器和向对方发 
送数据包。 
有些类型的数据包，诸如配置否定包和配置拒绝包，或者编号拒绝包和协议拒绝包，或者 
回应请求包、回应回答包和丢弃请求包在自动机的描述中都是不可区分的。正如后面将要 
提到的，虽然这些不同类型的数据包会引起相同的状态迁移，但它们确实起到了不同的作 
用。

事件 动作 
Up = 低层已连接 tlu = 该层已连接 
Down = 低层已断开 tld = 该层已断开 
Open = 打开连接 tls = 该层已开始连接 
Close= 关闭连接 tlf = 该层已关闭连接

TO+ = 超时计时器溢出且超时计数器值大于零 irc = 初始化超时计数器 
TO- = 超时计时器溢出且超时计数器值小于零 zrc = 超时计数器清零

RCR+ = 收到正确的配置请求包 scr = 发送配置请求包 
RCR- = 收到不正确的配置请求包 
RCA = 收到配置确认包 sca = 发送配置确认包 
RCN = 收到配置否定包/拒绝包 scn = 发送配置否定包/拒绝包

RTR = 收到终止请求包 str = 发送终止请求包 
RTA = 收到终止确认包 sta = 发送终止确认包

RUC = 收到未知编码包 scj = 发送编码拒绝包 
RXJ+ = 收到编码拒绝包 (允许的) 
或受到协议拒绝包 
RXJ- = 收到编码拒绝包 (糟糕的) 
或受到协议拒绝包 
RXR = 收到回应请求包 ser = 发送回应回答包 
或者收到回应回答包 
或者收到丢弃请求包 
４．１状态转移表 
以下就是完整的状态转移表。状态水平列出来的。低层仍然没有准备好。超时计 
时器也没有运行在此状态下。 
当低层变得可用时，就发送配置请求包。

Ｃｌｏｓｅｄ状态 
在此状态下，连接有效，但是没有出现Ｏｐｅｎ事件。超时计时器也没有运行在 
此状态下。 
此时接收到配置请求包后，将发送终止请求包。接收到终止确认包将被静默丢弃 
以免产生循环。

Ｓｔｏｐｐｅｄ状态 
此状态是在Ｃｌｏｓｅｄ状态发生了Ｏｐｅｎ事件后迁移而来的。当自动机在进 
行了ｔｌｆ动作后或发送了终止请求包后在等待Ｄｏｗｎ事件时就进入此状态。超时计时 
器也没有运行在此状态下。 
此时接收到配置请求包后，将做出合适的回答。接收到其他类型的包时，就发送 
终止确认包。接收到终止确认包将被静默丢弃以免产生循环。

基本原理： 
Ｓｔｏｐｐｅｄ状态是连接终止阶段、连接配置失败和其它自动机的错误模式的 
交汇之处。 
还存在着Ｄｏｗｎ事件（由ｔｌｆ动作引发）和ＲＣＲ事件的竞争的情况。当Ｒ 
或拒绝其它用户的请求。自从连接被确认为可用时，就可以由一个Ｄｏｗｎ事件和一个紧 
接着的Ｏｐｅｎ事件来通知ＬＣＰ来模拟实现。应该特别注意的是Ｃｌｏｓｅ事件不能由 
其它的原因引发。 
此时将触发一个Ｄｏｗｎ事件，随即紧接着一个Ｕｐ事件。这样做将使得连接有 
次序的开始重新协商，自动机由Ｃｌｏｓｉｎｇ状态转移到Ｓｔｏｐｐｉｎｇ状态，并且 
ｔｌｆ动作将断开连接。自动机将在Ｓｔｏｐｐｅｄ状态或Ｓｔａｒｔｉｎｇ状态中等待 
下一次连接。

Ｔｉｍｅｏｕｔ（ＴＯ＋，ＴＯ－）事件 
Ｔｉｍｅｏｕｔ事件指示超时计时器溢出。当发送出配置请求包和终止请求包后 
超时计时器开始计时。 
ＴＯ＋事件指示着超时计数器的值仍然大于零。其中超时计数器每减一，就表明 
配置请求包或终止请求包就重传一次。 
ＴＯ－事件指示着超时计数器的值小于零，再没有任何数据包需要重传了。

Ｒｅｃｅｉｖｅ－Ｃｏｎｆｉｇｕｒｅ－Ｒｅｑｕｅｓｔ（ＲＣＲ＋，ＲＣＲ－）事件 
ＲＣＲ事件出现表明接收到了从对方发送来的配置请求包。配置请求包的到来表 
明对方希望打开连接并且指定连接选项。配置请求包将在后面有更详细的描述。 
ＲＣＲ＋事件表明对方的配置请求是可以接受的，并且将传送配置确认包。 
ＲＣＲ－事件表明对方的配置请求是不能接受，并且将传送相应的配置否定包或 
配置拒绝包。

应用注意事项： 
这些事件可以在自动机已处于Ｏｐｅｎｅｄ状态的时候发生。这时必须立即准备 
好重新协商选项。

Ｒｅｃｅｉｖｅ－Ｃｏｎｆｉｇｕｒｅ－Ａｃｋ（ＲＣＡ）事件 
ＲＣＡ事件出现表明收到了对方κ褂茫眨鹗录魑卮稹? 这个动作的结果高度依赖于应用的需要。

Ｔｈｉｓ－Ｌａｙｅｒ－Ｆｉｎｉｓｈｅｄ（ｔｌｆ）动作 
ｔｌｆ动作表明低层的协议自动机进入了Ｉｎｔｉａｌ状态，Ｃｌｏｓｅｄ状态 
，或Ｓｔｏｐｐｅｄ状态，并且低层已不再为连接所用。当低层终止时应使用Ｄｏｗｎ事 
件作为回答。 
典型的，此动作可能会被ＬＣＰ用来提前进入连接死亡阶段，或者被ＮＣＰ用来 
通知ＬＣＰ当没有任何ＮＣＰ被打开时连接可能会终止。 
这个动作的结果高度依赖于应用的需要。

Ｉｎｉｔｉａｌｉｚｅ－Ｒｅｓｔａｒｔ－Ｃｏｕｎｔ（ｉｒｃ）动作 
ｉｒｃ动作初始化超时计数器为一合适的值（Ｍａｘ－Ｔｅｒｍｉｎａｔｅ或 
Ｍａｘ－Ｃｏｎｆｉｇｕｒｅ）。每传送一次数据包，计数器就减一，并且包括第一次。

应用注意事项： 
除了设置超时计数器之外，还必须为超时计时器设置超时事件的时间长度。

Ｚｅｒｏ－Ｒｅｓｔａｒｔ－Ｃｏｕｎｔ（ｚｒｃ）动作 
ｚｒｃ动作将超时计数器清零。

应用注意事项： 
此动作使有限自动状态机能够在进入最终所期望的状态之前停止，允许由对方处 
理网络流量。除了设置超时计数器之外，还必须为超时计时器设置超时事件的时间长度。

Ｓｅｎｄ－Ｃｏｎｆｉｇｕｒｅ－Ｒｅｑｕｅｓｔ（ｓｃｒ）动作 
ｓｃｒ动作将发送配置请求包。这表明期望用指定的配置选项打开连接。当配置 
选项包被发送时，超时计时器开始计时以防止它被丢失。每当发送一个配置请求包时，超 
时计数器就减一。

Ｓｅｎｄ－Ｃｏｎｆｉｇｕｒｅ－Ａｃｋ（ｓｃａ）动作 
ｓｃａ动作发送配置确认包。它表明确认了接收到的配置请求包中所有的配置选 
项。

Ｓｅｎｄ－Ｃｏｎｆｉｇｕｒｅ－Ｎａｋ（ｓｃｎ）动作 
ｓｃｎ动作发送配置否定包或配置拒绝包。它表明否定了接收到的配置请求包中 
某些的配置选项。 
配置否定包被用于拒绝某一个配置选项值，并且还建议了一个新的可以接受的配 
置选项值。而配置拒绝包被用于拒绝所有的配置选项，典型的是因为这些选项不能被识别 
或被运用。关于如何使用配置否定包和配置拒绝包将在后面叙述链路控制协议数据包格式 
的章节中详细说明。

Ｓｅｎｄ－Ｔｅｒｍｉｎａｔｅ－Ｒｅｑｕｅｓｔ（ｓｔｒ）动作 
ｓｔｒ动作发送终止请求包。它表明期望关闭连接。当终止请求包被发送时，超 
时计时器开始计时以防止它被丢失。每当发送一个配置请求包时，超时计数器就减一。

Ｓｅｎｄ－Ｔｅｒｍｉｎａｔｅ－Ａｃｋ（ｓｔａ）动作 
ｓｔａ动作发送终止确认包。它表明确认了接收到的终止请求包或者对双方的协 
议自动机起到同步的作用。

Ｓｅｎｄ－Ｃｏｄｅ－Ｒｅｊｅｃｔ（ｓｃｊ）动作 
ｓｃｊ动作发送编码拒绝包。它表明接收到有不能识别编码的数据包。

Ｓｅｎｄ－Ｅｃｈｏ－Ｒｅｐｌｙ（ｓｅｒ）动作 
ｓｅｒ动作发送回应回答包。它表明确认接收到了回应请求包。

４．６避免循环

协议有效的避免了在协商配置选项时的循环。然而，协议并不能保证这种循环不再出现。 
在协商任何选项时，双方有可能采取了相互矛盾决不相容的配置策略。但是双方也有可能 
采取了可以相容的配置策略，但这时可能需要花费很多时间。应用者要将此记在心中并应 
应用循环监测机制和更高层次的超时机制。

４．７计数器和计时器

超时计时器 
自动机并没有运用特殊的计时器。超时计时器被用来监测配置请求包和终止请求 
包的传送。当计时器计满后将引发一个Ｔｉｍｅｏｕｔ事件，并重新发送相应的配置请求 
包或终止请求包。超时计时器必须被配置，而且缺省值应该为三秒钟。

应用注意事项： 
超时计时器的设置应该基于连接的速度。缺省值是为低速连接（２４００－ 
９６００ｂｐｓ）、高速交换连接（典型的如电话线）设计的。更高速的连接，或低交换 
速度连接应该相应的增加重传的次数。

取代固定的超时值，超时计时器应该最初设为一个小的值然后再增加达到最终配置值。每 
一个小于最终值的成功的值都应该是前一个值的两倍。初始值应该足够处理一个数据包， 
它通常设置为两倍于以连接速度在传送间做一往返的时间还要加上一百毫秒，以允许对方 
在做作回应之前能够处理数据包。

最大终止次数 
它是为终止请求包计数的超时计数器所要求的一个值。它表明了在假定对方不能 
做出回答之前且未接收到终止确认包时发送终止请求包最大的发送次数。最大终止次数必 
须被配置，而且缺省值应该为重传两次。

最大配置次数 
相似的量被推荐给了配置请求包。它表明在假定对方不能做出回答之前且未接收 
到配置确认包、配置否定包或配置拒绝包时发送配置请求包最大的发送次数。最大配置次 
数必须被配置，而且缺省值应该为重传十次。

最大失败次数

相似的量被推荐给了配置否定包。它表明了在假定未达成一致发送配置确认包之前配置否 
定包最大的发送次数。任何由对方配置否定包中所建议的而后又被加入到配置拒绝包中的 
选项和本地所期望的选项在协商过程中都不再追加进去。最大配置次数必须被配置，而且 
缺省值应该为五次。

5． 链路控制协议数据包格式 
有三种类型的链路控制协议数据包： 
1． 连接配置数据包用于建立和配置连接。（配置请求包，配置确认包，配置否定包 
和配置拒绝包）。 
2． 连接终止数据包用于终止连接（终止请求包和终止确认包）。 
3． 连接维护数据包用于管理和调试连接（编码拒绝包，协议拒绝包，回应请求包， 
回应回答包和丢弃请求包）。 
为了简化起见，数据链路控制协议数据包格式中并没有版本号域。对于不能识别的协议和 
编码都能以简单的可识别的链路控制协议数据包格式予以回应，因此对其它的版本提供了 
一种确定性但效率低的的运行机制。 
不管什么配置选项被确定为使能，所有的连接配置包，连接终止包，编码拒绝包（编码号 
１－７）都假定没有配置选项被协商。实际上，每一个配置选项都被指定了一个缺省值。 
这样做使得诸如链路控制协议的数据包总是能够识别，即使当连接已结束但仍被错误的认 
为连接是打开的时候。

链路控制协议数据包被封装在ＰＰＰ帧格式的数据域中，且ＰＰＰ帧的协议域的值是０ｘ 
ｃ０２１。 
链路控制协议数据包格式总结如下。按照从左至右的顺序被传送。

 

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 编码 | 标识 | 长度 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 数据 ．．． 
+-+-+-+-+

编码域 
编码域占一个八位字节。它标识这是何种类型的链路控制协议数据包。当接收到 
编码域不可识别的数据包时，就发送编码拒绝数据包。 
最新的编码域的值由最近公布的"Ａｓｓｉｇｎｅｄ　Ｎｕｍｂｅｒｓ"ＲＦＣ文 
档说明。与本文档相关的有以下的值： 
1 配置请求(Configure-Request) 
2 配置确认(Configure-Ack) 
3 配置否定(Configure-Nak) 
4 配置拒绝(Configure-Reject) 
5 终止请求(Terminate-Request) 
6 终止确认(Terminate-Ack) 
7 编码拒绝(Code-Reject) 
8 协议拒绝(Protocol-Reject) 
9 回应请求(Echo-Request) 
10 回应回答(Echo-Reply) 
11 丢弃请求(Discard-Request)

标识域 
标识域编码占一个八位字节，它帮助请求和回答进行匹配。当收到的数据包中的标 
识域是无效的，它将被静默丢弃并且不影响自动机的状态。

长度域 
标识域编码占两个八位字节，它标识了链路控制协议数据包的长度，包括编码域 
，标识域，数据域等。此长度不能超过连接的最大接收长度。 
超过长度域的八位字节被视为填充字节并在接收时忽略。当接收到长度域无效的 
数据包时，它将被静默丢弃并且不影响自动机的状态。

数据域 
数据域有零个或多个八位字节，正如长度域中所指示的长度。数据域中的格式由 
编码域中的值决定。

５．１配置请求 
描述 
当希望打开一个连接时，必须传送配置请求包。选项域中由期望改变连接缺省值 
的配置选项填充。配置选项不必包含使用缺省值的配置选项。 
当接收到了配置请求包时，必须传送合适的数据包作为回应。 
配置请求包的格式总结如下。按照从左至右的顺序被传送。

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 编码 | 标识 | 长度 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 选项 ．．． 
+-+-+-+-+

编码 
1代表配置请求。

标识 
当选项域中的内容改变或当接收到对前一次请求的无效回答时，标识域应做改变 
。重传时，标识域则不应改变。

选项 
选项域长度可变，包含有零个或多个希望协商的配置选项的列表。全部的配置选 
项将同时协商。选项域的格式将在后面的章节详细讨论。

５．２配置确认 
描述 
如果对方发送来的配置请求包中的配置选项都是可识别并且可接受，就可以发送 
配置确认包。其中已被确认的选项的顺序和选项自身都不能以任何方式修改。 
接收到的配置确认包中的标识域必须同上一次发送的配置请求包中的标识域匹配 
。此外，在配置确认包中选项必须同上一次发送的配置请求包中的选项完全一致。 
配置请求包的格式总结如下。按照从左至右的顺序被传送。

0 1 2 用于通知对方己方可以接收更大 
的数据包，或者要求对方发送更小的数据包。 
它的缺省值是１５００字节。如果要求更小的数据包，当连接失去同步时应用仍 
将按１５００字节接收信息域。

应用注意事项：

此选项说明了应用的能力。对方并没有要求使用最大的能力。举例来说，当ＭＲＵ为 
２０４８字节，而对方没有被要求发送２０４８字节大小的数据包。此时对方不需要使用 
配置否定包表明它仅仅发送比２０４８字节小的数据包，因为应用始终要求支持至少 
１５００字节的数据包。 
最大接收单元配置选项格式小结如下。按照从左至右的顺序被传送。

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 类型 | 　长度 | 　　 最大接收单元 　　 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

类型 
1

长度 
4

最大接收单元 
最大接收单元域有两个八位字节，它指定了信息域和填充域所能接受的最大字节 
数。它不包括帧协议域，循环校验码和任何因透明传输而需要的位或字节。

６．２认证协议 
描述 
在进行某些连接时可能希望在交换网络层数据包之前要求对方来认证自己。 
这个配置选项提供了协商用指定的认证协议进行认证的方法。缺省情况下，认证 
是不需要的。 
应用时不能在配置请求包中包含多个认证协议配置选项。相反的，应该首先配置 
最期望使用的认证协议。如果被配置否定包所否定，应该在下一次配置请求中配置其次最 
期望使用使用的认证协议。 
应用发送配置请求包表明它希望对方对自己进行认证。如果对方发送来配置确认 
包，表示它同意使用指定的协议进行erkins, D., "Requirements for an Internet 
Standard Point-to-Point Protocol", RFC 1547, Carnegie Mellon University, 
December 1993.

[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 

1340, USC/Information Sciences Institute, July 1992.

http://www.360doc.com/content/13/1008/18/7256015_319886347.shtml

http://baike.baidu.com/link?url=PNOBkULHY4S39TwbuBlOc-XA15vwoQVxlpnSrfddtvJ-u_a1nmJsVXM9ML4g0Ync3i1wQQyX98-63DKeCJw7_LMTVln9s0M5YMbssEnXARa

http://network.51cto.com/art/201009/224056.htm

http://neucert.neu.edu.cn/archives/70

http://www.freedocuments.info/8603583662/