7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 该数据报文中有下划线的配置参数选项的内容为对端不认可的。 当对端正确接收到了该报文后，发现类型域为0x02的配置参数选项可识别，但该配置参数选项数据域的内容不认可，应发送一个Config-Nak报文且该报文中将携带希望的配置参数选项内容，报文内容如下：
7E FF 03 C0 21 03 01 00 0A 02 06 00 0E 00 00 7E 该报文中返回的值已经被更改，且当发端收到该报文后会重新发送一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 04 00 17 02 06 00 0E 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 仔细观察是不是新的配置请求报文与老的配置请求的报文ID不一样。 ", 当接收Config-Request报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别时）。当对端接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将 不可识别的那些配置参数选项给删除了。
例4：假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 下划线所表示的配置参数选项为对端不可识别的。
当对端正确接收到了该报文后，发现类型域为0x02的配置参数选项不识别，应该回应一个Config-Reject报文，报文内容如下：
7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7E
该报文如果被原发送端接收后，又会重新发送一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 04 00 11 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 这时我们能看到，类型域为02的配置选项在下一次的请求报文中被删除了。所以我们能够看出，链路配置阶段也可能要经过几次协商后才能完成，但这与点对点两端的设备有着密切的联系。对于PPP的两个端点而言，两者是独立完成各自的配置参数选项的协商过程的。具体的配置参数选项待后续的章节中讲解。 3.1.2.4 LCP的链路终止报文
链路终止报文分为Terminate-Request和Terminate-Reply两种报文。LCP报文中提供了一种机
制来关闭一个点对点的连接，想要关断链路的一端会持续发送Terminate-Request报文，直到收到一个Terminate-Reply为止。接收端一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply报文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。 LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项。对于链路终止报文也同样需要ID一致，当接收到Terminate-Reply报文才会做链路终止操作。
3.1.2.5 LCP的链路维护报文
除上述两种报文类型以外，剩余的所有报文类型均归属链路维护报文。 ", 当接收端发现LCP报文的代码域是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的内容附加上。
例5：假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 1F02 7E 有下划线的部分表示这个代码域在标准中未定义，从而无法识别。
当对端正确接收到了该报文后，发现LCP数据报文的代码域为0x0E时，应该发送一个 Code-Reject报文，报文内容如下：
7E FF 03 C0 21 07 01 00 1D 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 1F 02 7E ", 当接收端发现所接收到的数据帧的协议域是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了。Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。
例6：假设点对点通信的一端发送了一个协议域未定义（无法识别）的报文，报文内容如 下：
7E FF 03 77 77 01 01 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02 7E 其中下划线部分为PPP数据帧的协议域，0x7777表示一个未定义的类型（也即对端无法识别）。当对端正确接收到了该报文后，发现该报文的协议域为0x7777，该值未在RFC中未有明确定义，应该发送一个Protocol-Reject报文，报文内容如下：
7E FF 03 C0 21 08 01 00 18 77 77 01 00 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02 7E ", Echo-Request报文和Echo-Reply报文主要用来检测双向链路上自环的问题， 除此之外还可附带做一些链路质量的测试和其它功能。当LCP状态机处于Opened状态时，如果接收到了Echo-Request，就需向对端回送一个Echo-Reply报文。否则在其它LCP状态下，该类型的报文会被丢弃。这种类型数据报文的长度域后不是直接跟数据域，而是要插入4个字节的Magic-Number（魔术字），该魔术字是在LCP的Config-Request的配置参 数选项协商时获得的。
例7：假设点对点通信的一端接收到了一个Echo-Request报文，报文内容如下： 7E FF 03 C0 21 09 01 00 08 02 06 00 0D 7E 有下划线的部分表示魔术字。
当对端正确接收到了该报文后，应该发送一个Echo-Reply报文，报文内容如下： 7E FF 03 C0 21 0A 01 00 08 02 06 00 0D 7E 3.1.3 NCP协议
NCP协议的数据报文是在网络层协议阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。NCP协议主要包括IPCP、IPXCP等，但我们在实际当中最常遇见的也只有IPCP协议了，
如果对IPXCP或其它的一些网络控制协议有兴趣，则可参见RFC1552。 3.1.3.1 IPCP
IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商的。IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。我们依据两端设备的配置选项可将IPCP的协商过程分为”静态”和”动态”。何为静态，何为动态，这是一个相对的概念，也是自已总结出来的，可能不太准确，只作为参考使用。我们在下面会具体描述这两个过程。IPCP的数据的文同LCP的数据报文非常类似，只不过一个是在网络层协议阶段协商 配置参数选项，而LCP协议则是在链路建立阶段协商配置参数选项的。除此之外是两者在所使用报文上的相似之处，我们知道LCP共包括十几种报文，而IPCP也包括多种报文，但它的报文类型只是LCP数据报文的一个子集（只 有LCP代码域从1到7这七种报文），而且实际的数据报文交换过程中也仅涉及以下几种：Config-Request、Config-Ack、Config-Nak和Config-Reject（代码域从1到4，而链路终止报文一般而言是不在网络协议阶段使用的，而且也是不需要的）。以下就具体介绍一下IPCP控制协议的静态和动态的两个过程，
实际上两者的区分是在于互连设备IP地址的获取过程。 ", 静态协商，也即是不协商。点对点的通信设备两端在PPP协商之前已配
置好了IP地址，所以就无须在网络层协议阶段协商IP地址，而双方唯一要做的就是告诉对方自身的IP地址。在IPCP控制协议完成整个配置的过程时，最理想的情况将会看到如图所示的四种报文，而无其它报文再被发送。如果当配置请求中所携带的网络层配置参数选项类似于LCP配置参数选项协商过程一样，可能会有对方不识别的配置参数选项或不被对 方所认可的配置参数选项的内容。这样在这个阶段的协商过程中可能还会看到其它的一些报文。
在静态协商时，如果IPCP的Config-Request报文中只含有地址配置参数选项时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与LCP阶段的一样，而我这里只提到了IP地址配置参数选项），无论是发送方还是接收方都同时发送Config-Request报文，其中配置选项中只含有各自的IP地址。当对端收到该报文后，会发送一个Config-Ack报文， 这个目的是告诉对端我已经知道了你的IP地址，对路由器而言会增加一条到对端接口的主机路由。刚进入网络层协议阶段时，IPCP的状态机是initial的，但当完成了上述的整个过程后，IPCP的状态机改变为Opened，双方也就可以开始网络层数据网的传送了。IPCP协议中并未规定，当一端接收到Config-Request报文后，它从报文的配置参数选项中可获知对端的IP地址，但并不与本端的IP地址进行比较.我们也知道，一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段，就不给对方回应Config-Ack报文，而是无条件的回送
一个回应报文。因此说点对点通信的两端如果是手动设置每一端的IP地址时，无须双方地址在同一网段。
例8：假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参 数选项地的过程），发送方设置IP地址为192.168.0.1，接收方设置IP地址为192.168.0.2， 发送方发送给Config-Request报文内容如下： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E 在这个例子中我们能看见明显的改变之处再于PPP协议域字段由原先的0xC021改变为0x8021，下划线的部分表示本端的IP地址。
当对端正确接收到了该报文后，应该回应一个Config-Ack报文，报文内容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 01 7E 同样的接收方给发送方也发送一个Config-Request报文内容如下，但此时报文中IP地址配置参数选项的值为本端的IP地址（192.168.0.2）： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E 发送方回应一个Config-Ack报文给接收方，报文内容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E ", 动态协商，也即是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址，这个过程实际上可与窄带拨号上网的过程相一致，如果我们想用计算机上网，均会安装一个拨号适配器，而
且计算机中的拨号网络适配器是采用动态获取IP地址的方式。这个例子与一个例子相似，也就是在IPCP的Config-Request报文中只携带IP地址的配置参数选项。如果是配置参数选项中含有其它配置参数选项，则可能会遇到其它的一些情况（如不识别配置参数选项的代码域或不认可配置参数选项的内容，但对于这些情况的处理方法和LCP配置参数选项的处理方法一致）。图3-6中我们可以看出发送方连续发送了两次Config-Request报文，才能完成发送方的协商过程。而接收方仍然只需要发送一次Config-Request即可完成本端的协商过程。 由于发送方没有配置IP地址（而是动态获取IP地址），所以在IPCP的Config-Request报文的IP地址配置参数配置选项中的IP地址填充全0（也即是0.0.0.0），这样当对端收到这个Config-Request报文时，当接收方收到该配置请求报文后会迅检测IP地址的内容，如果发送为全0，则认为对端的这个IP地址不是我所希望的值，这样就回应一个Config-Nak报文，并将希望分配给对方的IP地址填充到Config-Nak报文内。这时当接收方收到Config-Nak报文后，就会重新发送一个Config-Request报文，这个报文中的IP地址配置选项为对方在Nak报文中所提供的。接收方IP 地址的配置过程与静态时的一样， 只需发送一个Config-Request报文即
可，当收到发送方的Config-Ack报文，就表示接收方的IP地址配置完成。 例9： 假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方没有配置IP地址，而接收方配置了IP地址为192.168.0.2，接收方可给发送方分配IP地址（192.168.0.1），发送方发送给接收方的Config-Request报文内 容如下：
7E FF 03 80 21 01 01 00 0A 03 06 00 00 00 00 7E 有下划线的部分表示本端的IP地址。
当对端正确接收到了该报文后，应该回应一个Config-Nak报文，报文内容如下： 7E FF 03 80 21 03 01 00 0A 03 06 C0 A8 00 01 7E 当接收方收到该报文后，重新发送一个Config-Request报文，报文内容如下： 7E FF 03 80 21 01 02 00 0A 03 06 C0 A8 00 01 7E 接收方再次收到发送方的一个Config-Request报文，此时将回应一个Config-Ack报文，报文内容如下：
7E FF 03 80 21 02 02 00 0A 03 06 C0 A8 00 01 7E 请仔细观察一下这些报文在交互过程中，PPP数据帧净载荷内的数据报文的类型域和报文 ID。同样的接收方给发送方也发送一个Config-Request报文，报文内容如下： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E 发送方应回送一个Config-Ack给接收方，报文内容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E 本章节的一些内容可能没有明确写出，只是将IPCP配置参数选项配置过程中最关键的部分做了一些说明，如果想深入了解决IPCP或IPXCP，可参见相关的RFC文档。 3.2 总结 ", PPP协议的状态转移图包括链路不可用阶段、链路建立阶段、认证阶段、 网络层协议阶段和链路终止阶段 ", LCP协议依据报文的功能可分为链路配置报文、链路终止报文和链路维 ", LCP协议的链路配置报文主要是用来协商一些可选的配置参数选项 ", LCP协议的链路终止报文主要是用来终止一条PPP链路 ", LCP协议的链路维护报文主要是用来测试和调试PPP链路 ", NCP协议主要负责网络层配置参数选项的协商，它包括”静态协商”和”动态协商 第四章 LCP的可选配置参数 4.1 LCP的参数配置选项
LCP协议在对链路配置过程中需要进行一些可选配置参数选项的协商，我们在前面讲述的过程中已列举了许多配置参数选项，但我们只挑选其中较为重要的几个参数做相应的扩展说明（魔术字和认证协议选项）。关于一些更具体的细节和未涉及到的配置参数选项，请参数PPP的RFC文档（RFC1661）。
4.1.1 魔术字（Magic-Number）
魔术字是在LCP的Config-Request报文中被协商的，并且可被其它一些其它类型的LCP数据报文所使用，如前面已经说过的Echo-Request、Echo-Reply报文和Quality-Protocol报文等。对于PPP协议本身它是不要求协商魔术字的，如果在双方不协商魔术字的情况下，某些LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全0；反之，则填充为配置参数选项协商后的结果。魔术字在目前所有的设备当中都是需要进行协商的， 它被放在Config-Request的配置选项参数中进行发送，而且需要由自身的通信设备独立产生，协议为了避免双方可能产生同样的魔术字，从而导致通信出现不必要的麻烦，因此要求由设备采用一些随机方法产生一个独一无二的魔术字。一般来说魔术字的选择会采用设备的系列号、网