前言

介绍PPP拨号的相关内容。

简介

PPP（Point-to-Point Protocol）协议是一种点到点链路层协议，主要用于在全双工的同异步链路上进行点到点的数据传输。

目的

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

对物理层而言，PPP既支持同步链路又支持异步链路，而X.25、FR（Frame Relay）等数据链路层协议仅支持同步链路，SLIP仅支持异步链路。
PPP协议具有良好的扩展性，例如，当需要在以太网链路上承载PPP协议时，PPP可以扩展为PPPoE。
提供LCP（Link Control Protocol）协议，用于各种链路层参数的协商。
提供各种NCP（Network Control Protocol）协议（如IPCP、IPXCP），用于各网络层参数的协商，更好地支持了网络层协议。
提供认证协议CHAP（Challenge-Handshake Authentication Protocol）、PAP（Password Authentication Protocol），更好的保证了网络的安全性。
无重传机制，网络开销小，速度快。

原理

报文格式

基本构架

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

PPP主要由三类协议族组成：

链路控制协议族（Link Control Protocol），主要用来建立、拆除和监控PPP数据链路。
网络层控制协议族（Network Control Protocol），主要用来协商在该数据链路上所传输的数据包的格式与类型。
扩展协议族CHAP（Challenge-Handshake Authentication Protocol）和PAP（Password Authentication Protocol），主要用于网络安全方面的验证。

PPP帧格式

Flag：标志位，用于表示帧的开始和结束，该字节为0x7E。
Address：地址位，Address域可以唯一标识对端。但PPP协议是被运用在点对点的链路上，不需要地址位，所以该地址位恒为0xFF。
Control：Control位用来标识帧的顺序和重传行为，但由于该功能在PPP协议中没有普遍实现，因此PPP帧中，Control值固定为0x03。
Protocol：用来区分PPP数据帧中信息域所承载的数据包类型。

协议代码	协议类型
0021	Internet Protocol(网络层)
002b	Novell IPX(网络层)
002d	Van Jacobson Compressed TCP/IP(网络层)
002f	Van Jacobson Uncompressed TCP/IP(网络层)
8021	Internet Protocol Control Protocol(网络控制协议NCP)
802b	Novell IPX Control Protocol(网络控制协议NCP)
8031	Bridging NC(网络控制协议NCP)
C021	Link Control Protocol(链路控制协议LCP)
C023	Password Authentication Protocol(链路控制协议LCP)
C223	Challenge Handshake Authentication Protocol(链路控制协议LCP)

Information域最大长度是1500字节，其中包括填充域的内容。Information域的最大长度称为最大接收单元MRU（Maximum Receive Unit）。MRU的缺省值为1500字节，在实际应用当中可根据实际需要进行MRU的协商。
FCS域的功能主要对PPP数据帧传输的正确性进行检测。在数据帧中引入了一些传输的保证机制，会引入更多的开销，这样可能会增加应用层交互的延迟。

LCP 帧格式

在链路建立阶段，PPP协议通过LCP报文进行链路的建立和协商。此时LCP报文作为PPP的净载荷被封装在PPP数据帧的Information域中，PPP数据帧的协议域的值固定填充0xC021。
在链路建立阶段的整个过程中信息域的内容是变化的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分。

Code域的长度为一个字节，主要是用来标识LCP数据报文的类型。在链路建立阶段，接收方接收到LCP数据报文。当其Code域的值无效时，就会向对端发送一个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

Identifier域为1个字节，用来匹配请求和响应，当Identifier域值为非法时，该报文将被丢弃。
通常一个配置请求报文的ID是从0x01开始逐步加1的。当对端接收到该配置请求报文后，无论使用何种报文回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致。
Length域的值就是该LCP报文的总字节数据。它是Code域、Identifier域、Length域和Data域四个域长度的总和。Length域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值。
Data域所包含的是协商报文的内容，这个内容包含以下字段。
- Type为协商选项类型。
- Length为协商选项长度，它是指Data域的总长度，也就是包含Type、Length和Data。
- Data为协商选项的详细信息。

类型值	参数选项	类型值	参数选择
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

LCP报文配置参数

LCP报文主要分为：
    1. 链路配置报文，主要用来建立和配置一条链路；
    2. 链路终止报文，主要用来终止一条链路；
    3. 链路维护报文，主要用来维护和调试链路。
链路配置报文主要用来建立和配置一条链路，包括：Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。

链路配置报文

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

类型域1字节长；
长度域1字节: 表示当前LCP配置选项的总长度（类型域 + 长度域 + 数据域）。
当通信双方需要建立链路时，无论哪一方都需要发送Config-Request报文并携带每一端自已所希望协商的配置参数选项。
当接收方收到Config-Request报文时，会在剩下的三种类型的报文中选择一种来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件：
- 能不能完全识别配置参数选项的类型域。我们知道一个Config-Request报文中会同时携带多个配置参数选项，而对于一个支持PPP协议的通信设备也不一定会支持上表中所有列出的配置选项，即使支持，也可能在实际应用中关闭掉某些选项功能。（例如：当使用PPP协议通信的一端可能将一些无用的配置选项都关闭了，而仅支持0x01和0x03两个配置参数选项，因此当对方发送的Config-Request报文中含有0x04配置选项时，对于本端而言这个配置参数选项就无法识别，也即是不支持这个配置参数选项的协商）
- 如果能支持完全识别配置参数选项，能不能认可Config-Request报文中配置参数选项数据域中的内容（例如：当一端发送魔术字配置参数选项中的魔术字为全0，而对端认为应该为其它值，这种情况就属于不支持配置参数选项中的内容）。
- 所以依据上面的两个条件，我们就可以明确在回应对方配置请求报文时，采用何种报文回应。
当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文，并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。

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

下面结合LCP报文格式说明报文的具体内容。注意：说明中省略了FCS字段（后面的说明也是如此）。

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

上图05表示LCP配置选项表中的0x05，魔术字。以此类推，蓝色部分都表示LCP配置选项表中类型值。
当对端正确接收到了该报文后，应该发送一个Config-Ack报文，报文内容如下：

当接收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报文，报文内容如下：

当接收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报文才会做链路终止操作。

链路维护报文

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

当接收端发现LCP报文的代码域code是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的全部内容附加上(注：code只有在LCP协议头中才存在)。
当接收端发现所接收到的PPP数据帧的协议域Protocol是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了（注：Protocol只有在PPP协议头中才存在）。
Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。
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报文。这时我们假设可能会有以下两种情况发生：

链路实际不存在环路，而是由于对方A在产生魔术字时与接收端B产生的一致，但实际这种情况出现的概率是很小的。当Config-Nak被对端A接收到后，A应该发送一个Config-Request报文（此报文中的魔术字为接收到的Nak报文中的），当B接收到后，与上次的Config-Request比较，由于接收端B已经在上一次的Nak报文中产生了一个不同的魔术字，此时接收端B收到的Config-Request报文中的魔术字与上次B发出的Config-Request配置请求报文中不一样，所以接收端B可断定链路不存在环路。
链路实际上确实存在环路，一段时间后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的过程。

PPP的六个阶段

链路不可用阶段：初始阶段
链路建立阶段：LCP协商（协商认证方式等）
验证阶段：PAP/CHAP验证
网络层协商阶段：**NCP协商
PPP会话维持阶段：维持PPP会话，定时发送Echo Request报文，并等待Echo Reply报文
网络终止阶段：终止PPP会话，回到链路不可用阶段。

下图是PPP协议整个链路过程需经历阶段的状态转移图：

PPP运行的过程简单描述如下：

通信双方开始建立PPP链路时，先进入到Establish阶段。
在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还是MP（Multilink PPP）、最大接收单元MRU（Maximum Receive Unit）、验证方式和魔术字（magic number）等选项。LCP协商成功后进入Opened状态，表示底层链路已经建立。
如果配置了验证，将进入Authenticate阶段，开始CHAP或PAP验证。如果没有配置验证，则直接进入Network阶段。
在Authenticate阶段，如果验证失败，进入Terminate阶段，拆除链路，LCP状态转为Down。如果验证成功，进入Network阶段，此时LCP状态仍为Opened。
在Network阶段，PPP链路进行NCP协商。通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。只有相应的网络层协议协商成功后，该网络层协议才可以通过这条PPP链路发送报文。
NCP协商包括IPCP（IP Control Protocol）、MPLSCP（MPLS Control Protocol）等协商。IPCP协商内容主要包括双方的IP地址。
NCP协商成功后，PPP链路将一直保持通信。PPP运行过程中，可以随时中断连接，物理链路断开、认证失败、超时定时器时间到、管理员通过配置关闭连接等动作都可能导致链路进入Terminate阶段。
在Terminate阶段，如果所有的资源都被释放，通信双方将回到Dead阶段，直到通信双方重新建立PPP连接，开始新的PPP链路建立。

下面具体介绍PPP协商阶段。

Dead阶段（链路不可用阶段）

Dead阶段也称为物理层不可用阶段。PPP链路都需从这个阶段开始和结束。
当通信双方的两端检测到物理线路激活（通常是检测到链路上有载波信号）时，就会从Dead阶段跃迁至Establish阶段，即链路建立阶段。
链路被断开后也同样会返回到链路不可用阶段。

Establish阶段（链路建立阶段）

在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还是MP（Multilink PPP）、最大接收单元MRU、验证方式和魔术字（magic number）等选项。当完成配置报文的交换后，则会继续向下一个阶段跃迁。
在链路建立阶段，LCP的状态机会发生如下改变。

当链路处于不可用阶段时，此时LCP的状态机处于初始化Initial状态或准备启动Starting状态。当检测到链路可用时，则物理层会向链路层发送一个Up事件。链路层收到该事件后，会将LCP的状态机从当前状态改变为Request-Sent（请求发送）状态，根据此时的状态机LCP会进行相应的动作，也就是开始发送Configure-Request报文来配置数据链路。
如果本端设备先收到Configure-Ack报文，则LCP的状态机从Request-Sent状态改变为Ack-Received状态，本端向对端发送Configure-Ack报文以后，LCP的状态机从Ack-Received状态改变为Opened状态。
如果本端设备先向对端发送Configure-Ack报文，则LCP的状态机从Request-Sent状态改变为Ack-Sent状态，本端收到对端发送的Configure-Ack报文以后，LCP的状态机从Ack-Sent状态改变为Opened状态。
LCP状态机变为Open状态以后就完成当前阶段的协商，并向下一个阶段跃迁。

下一个阶段既可能是验证阶段，也可能是网络层协商阶段。下一阶段的选择是依据链路两端的设备配置的，通常由用户来配置。

Authenticate阶段（验证阶段）

缺省情况下，PPP链路不进行验证。如果要求验证，在链路建立阶段必须指定验证协议。
PPP验证主要是用于主机和设备之间，通过PPP网络服务器交换电路或拨号接入连接的链路，偶尔也用于专用线路。
PPP提供密码验证协议PAP（Password Authentication Protocol）和质询握手验证协议CHAP（Challenge-Handshake Authentication Protocol）两种验证方式。
单向验证是指一端作为验证方，另一端作为被验证方。双向验证是单向验证的简单叠加，即两端都是既作为验证方又作为被验证方。在实际应用中一般只采用单向验证。

PAP验证过程

PAP验证协议为两次握手验证，口令为明文。

被验证方把本地用户名和口令发送到验证方。
验证方根据本地用户表查看是否有被验证方的用户名
- 若有，则查看口令是否正确，若口令正确，则认证通过；若口令不正确，则认证失败。
- 若没有，则认证失败。

CHAP验证过程

CHAP验证协议为三次握手验证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性要比PAP高。

CHAP认证过程比较复杂，三次握手机制。
使用密文格式发送CHAP认证信息。
由认证方发起CHAP认证，有效避免暴力破解。
在链路建立成功后具有再次认证检测机制。
目前在企业网的远程接入环境中用的比较常见。

CHAP认证过程

CHAP认证第一步：主认证方发送挑战信息【01(此报文为认证请求）、id(此认证的序列号）、随机数据、主认证方认证用户名】，被认证方接收到挑战信息，根据接收到主认证方的认证用户名到自己本地的数据库中查找对应的密码（如果没有设密码就用默认的密码），查到密码再结合主认证方发来的id和随机数据根据MD5算法算出一个Hash值。

CHAP认证第二步：被认证方回复认证请求，认证请求里面包括【02（此报文为CHAP认证响应报文）、id(与认证请求中的id相同）、Hash值、被认证方的认证用户名】，主认证方处理挑战的响应信息，根据被认证方发来的认证用户名，主认证方在本地数据库中查找被认证方对应的密码（口令）（即必须要求主认证方和被认证方使用的密码必须相同）结合id找到先前保存的随机数据和id根据MD5算法算出一个Hash值（即根据口令、CHAP id 和随机数三个量计算Hash值），与从被认证方得到的Hash值做比较，如果一致，则认证通过，如果不一致，则认证不通过。

CHAP认证第三步：认证方告知被认证方认证是否通过。

CHAP与PAP验证过程对比

PAP认证中，口令以明文方式在链路上发送，完成PPP链路建立后，被验证方会不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以安全性不高。当实际应用过程中，对安全性要求不高时，可以采用PAP认证建立PPP连接。
CHAP认证中，验证协议为三次握手验证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性比PAP认证高。当实际应用过程中，对安全性要求较高时，可以采用CHAP认证建立PPP连接。

Network阶段（网络层协商阶段）

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报文，报文内容如下：