PPP原理

PPP协议有三个组成部分：
（1）PPP协议的封装方式。PPP既支持异步链路（无奇偶校验的8比特数据），也支持面向比特的同步链路。
（2）一个用来建立、配置和测试数据链路的链路控制协议LCP（Link Control Protocol）。通信的双方可协商一些选项。在[RFC 1661]中定义了11种类型的LCP分组。
（3）一套网络控制协议NCP（Network Control Protocol），支持不同的网络层协议，如IP、OSI的网络层、DECnet、AppleTalk等。
------------------------
PPP帧格式
PPP帧格式和HDLC帧格式相似，如图所示。二者主要区别：PPP是面向字符的，而HDLC是面向位的。

与HDLC不同的是多了2个字节的协议字段。协议字段不同，后面的信息字段类型就不同。如：
0x0021——信息字段是IP数据报
0xC021——信息字段是链路控制数据LCP
0x8021——信息字段是网络控制数据NCP
0xC023——信息字段是安全性认证PAP
0xC025——信息字段是LQR
0xC223——信息字段是安全性认证CHAP
-------------------------
PPP链路工作过程

当线路处于静止状态时，并不存在物理层的连接。当检测到调制解调器的载波信号，并建立物理层连接后，线路就进入建立状态，这时LCP开始协商一些选项。协商结束后就进入鉴别状态。若通信的双方鉴别身份成功，则进入网络状态。NCP配置网络蹭，分配IP地址，然后就进入可进行数据通信的打开状态。数据传输结束后就转到终止状态。载波停止后则回到静止状态。
---------------------------
PP协议主要包括三部分：LCP（Link Control Protocol）链路控制协议、NCP（Network Control Protocol）和PPP的扩展协议（如Multilink Protocol）
---------------------------
LCP协议
为了能适应复杂多变的网络环境，PPP协议提供了一种链路控制协议来配置和测试数据通信链路，它能用来协商PPP协议的一些配置参数选项；处理不同大小的数据帧；检测链路环路、一些链路的错误；终止一条链路。

根据RFC的规定，到目前为止LCP共包括以下几种类型的数据报文：
代码 报文类型   代码 报文类型
0x01 Config-Request   0x07 Code-Reject
0x02 Config-Ack   0x08 Protocol-Reject
0x03 Config-Nak 0x09 Echo-Request
0x04 Config-Reject    0x0A Echo-Reply
0x05 Terminate-Request 0x0B Discard-Request
0x06 Terminate-Ack 0x0C Reserved

我们依据各报文的的功能又将其具体细化为以下三类：
链路配置报文，主要用来建立和配置一条链路的。
链路终止报文，主要用来终止一条链路的。
链路维护报文，主要用来维护和调试链路的。

链路配置报文主要包括Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。当接收方收到Config-Request报文时，会在剩下的三种类型的报文中选择一种来响应对方的请求报文
1)当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内.
2)当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-Nak报文，该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。当接收端收到Config-Nak报文后，会重新发送Config-Request报文，而这个Config-Request报文与上一次所发送的Config-Request报文区别在于那些被对端不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中
3)当接收Config-Request报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项,当对端接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。

链路终止报文分为Terminate-Request和Terminate-Reply两种报文

除上述两种报文类型以外，剩余的所有报文类型均归属链路维护报文。
1)Code-Reject报文:当接收端发现LCP报文的代码域是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的内容附加上。
2)Protocol-Reject报文:当接收端发现所接收到的数据帧的协议域是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了。
3)Echo-Request报文和Echo-Reply报文:主要用来检测双向链路上自环的问题，除此之外还可附带做一些链路质量的测试和其它功能。
----------------------------
NCP协议
PPP的网络控制协议根据不同的网络层协议可提供一族网络控制协议，常用的有提供给TCP/IP网络使用的IPCP网络控制协议和提供给SPX/IPX网络使用的IPXCP网络控制协议等，但最为常用的是IPCP协议，当点对点的两端进行NCP参数配置协商时，主要是用来通信双方的网络层地址。

IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商的。IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。我们依据两端设备的配置选项可将IPCP的协商过程分为"静态"和"动态"。何为静态，何为动态，这是一个相对的概念，也是自已总结出来的，可能不太准确，只作为参考使用.

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

在静态协商时，如果IPCP的Config-Request报文中只含有地址配置参数选项时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与LCP阶段的一样，而我这里只提到了IP地址配置参数选项），无论是发送方还是接收方都同时发送Config-Request报文，其中配置选项中只含有各自的IP地址。当对端收到该报文后，会发送一个Config-Ack报文，这个目的是告诉对端我已经知道了你的IP地址，对路由器而言会增加一条到对端接口的主机路由。刚进入网络层协议阶段时，IPCP的状态机是initial的，但当完成了上述的整个过程后，IPCP的状态机改变为Opened，双方也就可以开始网络层数据网的传送了。
注释：IPCP协议中并未规定，当一端接收到Config-Request报文后，它从报文的配置参数选项中可获知对端的IP地址，但并不与本端的IP地址进行比较.我们也知道，一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段，就不给对方回应Config-Ack报文，而是无条件的回送一个回应报文

2)动态协商，也即是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址，这个过程实际上可与窄带拨号上网的过程相一致.

IP地址分配过程：由于发送方没有配置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报文中所提供的。
-------------------------------
LCP的参数配置选项： 认证协议
PPP协议也提供了可选的认证配置参数选项，缺省情况下点对点通信的两端是不进行认证的。在LCP的Config-Request报文中不可一次携带多种认证配置选项，必须二者择其一（PAP/CHAP），选择最希望的那一种，一般是在PPP设备互连的设备上进行配置的，但一般设备会默认支持一个缺省的认证方式（PAP是大部分设备所默认的认证方式）。当对端收到该配置请求报文后，如果支持配置参数选项中的认证方式，则回应一个Config-Ack报文；否则回应一个Config-Nak报文，并附带上自希望双方采用的认证方式。当对方接收到Config-Ack报文后就可以开始进行认证了，而如果收到得是Config-Nak报文，则根据自身是否支持Config-Nak报文中的认证方式来回应对方，如果支持则回应一个新的Config-Request（并携带上Config-Nak报文中所希望使用的认证协议），否则将回应一个Config-Reject报文，那么双方就无法通过认证，从而不可能建立起PPP链路。

PAP认证：我们所知两个设备在使用PAP进行认证之前，应该确认那一方是验证方，那一方是被验证方，实际上对于使用PPP协议互连的两端来说，既可作为认证方，也可作为被认证方。但通常情况下，PAP只使用一个方向上的认证。
如果对于点对点的两个设备在PPP链路建立的过程中使用的认证方式为PAP的话，那么验证方在其Config-Request报文中必须含有认证配置参数选项，且该认证配置参数选项的数据域为0xC023，当通信设备的两端在收到对方返回的Config-Ack报文时，就从各自的链路建立阶段进入到认证阶段，那么作为被验证方此时需要向验证方发送PAP认证的请求报文，该请求报文携带了用户名和密码，当验证方收到该认证请求报文后，则会根据报文中的实际内容查找本地的数据库，如果该数据库中有与用户名和密码一致的选项时，则回向对方返回一个认证请求响应，告诉对方认证已通过。反之，如果用户名与密码不符，则向对方返回验证不通过的响应报文。如果双方都配置为验证方，则需要双方的两个单向验证过程都完成后，方可进入到网络层协议阶段，否则在一定次的认证失败后，则会从当前状态返回链路不可用状态。

CHAP为三次握手协议，它只在网络上传送用户名而不传送口令，因此安全性比PAP高。在验证一开始，不像PAP一样是由被验证方发送认证请求报文了，而是由验证方向被验证方发送一段随机的报文，并加上自己的主机名，我们通称这个过程叫做挑战。当被验证方收到验证方的验证请求，从中提取出验证方所发送过来的主机名，然后根据该主机名在被验证方设备的后台数据库中去查找相同的用户名的记录，当查找到后就使用该用户名所对应的密钥，然后根据这个密钥、报文ID和验证方发送的随机报文用Md5加密算法生成应答，随后将应答和自己的主机名送回，同样验证方收到被验证方发送回应后，提取被验证方的用户名，然后去查找本地的数据库，当找到与被验证方一致用户名后，根据该用户名所对应的密钥、保留报文ID和随机报文用Md5加密算法生成结果，和刚刚被验证方所返回的应答进行比较，相同则返回Ack，否则返回Nak，下图为CHAP的认证过程：