无论使用PAP还是CHAP，只要通过对端的验证，PPP协商就进入到第三阶段了——网络控制协商(NCP)阶段。本阶段NCP负责建立并配置IP、IPX、AppleTalk等网络层协议，以及建立并中断多种第三层协议会话。
如果大家对前面讲到的通信两端LCP协商的流程和四种链路配置报文结构有所了解的话，那么对于PPP协议的另一个子层——NCP子层的协商也就很容易理解了。NCP是PPP协议的另一个子层，该子层的主要作用就是在通信两端协商网络层的参数，比如IP地址、DNS等参数。因为PPP协议支持多协议栈(IP协议栈、IPX协议栈、AppleTalk协议栈)，所以在各个协议栈中PPP的NCP的名称都不一样，比如在IP协议栈中NCP称为IPCP，在IPX协议栈中，NCP称为IPXCP，而在AppleTalk协议栈中NCP称为APCP。假设这里PPP协议工作在TCP/IP协议栈。接下来我们看看PPP协议在第三阶段是如何使用IPCP协商网络层的参数的。
双方在IPCP协商阶段与LCP协商一样通常也会使用到前面提到的四种链路配置报文，只不过这四种报文此时是需要被IPCP封装：
IPCP Config-Request （配置请求）
IPCP Config-Ack （配置确认）
IPCP Config-NAK （配置非确认）
IPCP Config-Reject （配置拒绝）
那IPCP协商主要是协商网络层的哪些参数呢？我们先看 IPCP Config-Request（IPCP配置请求报文）结构：
Code ：ConfigurationRequest (0x01)
Identifier ：0x05
Length ：34
Options ：(30 bytes)
IP address ：0.0.0.0
Primary DNS server IPaddress ：0.0.0.0
Primary WINS serverIP address ：0.0.0.0
Secondary DNS serverIP address ：0.0.0.0
Secondary WINS serverIP address ：0.0.0.0
该报文中的字段含义请参考前面LCP报文字段的解释。从Configuration Request报文中可以看出，发送方需要和对方协商的参数是IP地址、Primary DNS server IP address(主DNS服务器IP地址)、Primary WINS server IP address（主WINS服务器IP地址）、Secondary DNS server IP address(辅助DNS服务器IP地址)、Secondary WINS server IP address(辅助WINS服务器IP地址)。
------------------------------------------------------------------------------------------
IPCP Config-Reject （IPCP配置拒绝报文）结构：
Code ：ConfigurationReject(0x04)
Identifier ：0x05
Length ：16
Options ：(12 bytes)
Primary WINS serverIP address ：0.0.0.0
Secondary WINS serverIP address ：0.0.0.0
从这个接收方回复的IPCP Config-Reject（配置拒绝）报文中可以看出，接收方对于发送方需要协商的两项参数(Primary WINS server IP address：0.0.0.0和Secondary WINS server IP address：0.0.0.0)是不认可的。我们继续看接下来的协商。
-------------------------------------------------------------------------------------------
IPCP Config-NAK （IPCP配置非确认报文）结构：
Code ：ConfigurationNak (0x03)
Identifier ：0x06
Length ：22
Options ：(18 bytes)
IP address ：113.232.89.224
Primary DNS server IPaddress ：202.96.64.68
Secondary DNS serverIP address ：202.96.69.38
该报文也是接收方回复的报文，从报文中我们看到接收方对于发送方协商的IP address、Primary DNS server IP address和Secondary DNS server IP address这三项参数没有异议，但对这三个参数中的具体内容并不认同，所以将这三个参数中的具体内容进行更改（由“0.0.0.0”改为具体的IP地址）。以上协商完成后，发送方应最后发送一个IPCP Config-Ack（配置确认）报文进行确认以上协商的选项参数。
IPCP Config-Ack （IPCP配置确认报文）结构如下：
Code ：ConfigurationAck (0x02)
Identifier ：0x07
Length ：22
Options ：(18 bytes)
IP address ：113.232.89.224
Primary DNS server IPaddress ：202.96.64.68
Secondary DNS serverIP address ：202.96.69.38
该报文的“Code”字段表明这是一个确认报文，PPP连接的发起者得到的IP地址是：113.232.89.224，得到的主DNS服务器的IP是：202.96.64.68，辅助DNS服务器的IP是：202.96.69.38。至此 IPCP协商完成。发送方IPCP进程的结束标志着PPP连接的完成，同时PPP也为承载网络层的IP数据包做好了链路层的准备工作。
一条PPP链路搭建好了之后，对该链路的维护工作也是必不可少的。本篇文章的开头部分我就介绍了，从链路的建立、维护到终止LCP协商基本上要使用到三类报文：
链路配置报文
链路维护报文
链路终止报文
现在我简单介绍一下LCP协商使用的第二类报文——“链路维护报文”。顾名思义，该报文是用于LCP协商成功后链路两端连接的维护工作的。链路的两端成功进行LCP协商之后，双方会周期性地向对方发送这种“链路维护报文”。该报文是 请求——响应 这种模式的。报文的名称和结构如下：
LCP Echo Request (LCP 回馈请求，目的就是询问对端是否一切正常)报文结构：
Code ：EchoRequest (0x09)
Identifier ：0x01
Length ：12
Magic number ：0x0111a51f
Message (4 bytes)
-------------------------------------------------------------------------------------------
LCP Echo Replay(LCP 回馈应答)报文结构：
Code ：EchoReply (0x0a)
Identifier ：0x01
Length ：12
Magic number ：0x00158d83
Message (4 bytes)
从这两个报文可以看出双方是依靠各自生成的“Magic number (魔术字)”来进行交互的，而且在双方周期性发送的这两个报文中，各自的魔术字（魔术字的作用简单说就是可以防止LCP链路出现环路）是不改变的。
最后再来说说PPP运行的第四阶段——PPP链路终止阶段。PPP链路终止阶段使用的是“链路终止报文”。该报文在PPP链路被拆除时使用。当通信双方中的某一方完成了数据传输后想断开PPP连接时，会通过LCP协议向对端发送链路终止报文——Terminal Request报文。
该报文结构如下：
Code ：TerminalRequest (0x05)
Identifier ：0x02
Length ：4
同样，接收方收到Terminal Request报文后会回应一个链路终止确认报文，该确认报文结构如下：
Code ：TerminalAck (0x06)
Identifier ：0x02
Length ：4
我们注意到这两个报文中都已没有了“Options(选项)”字段，只有“报文名称”、“Identifier(标识)”和“Length(报文长度)”三个字段了。可以看出与LCP链路的建立相比，链路的终止过程要简单得多了。关于PPP协议在设备中的配置，大家可参考另一篇文档——PPP配置。
如果大家对前面讲到的通信两端LCP协商的流程和四种链路配置报文结构有所了解的话，那么对于PPP协议的另一个子层——NCP子层的协商也就很容易理解了。NCP是PPP协议的另一个子层，该子层的主要作用就是在通信两端协商网络层的参数，比如IP地址、DNS等参数。因为PPP协议支持多协议栈(IP协议栈、IPX协议栈、AppleTalk协议栈)，所以在各个协议栈中PPP的NCP的名称都不一样，比如在IP协议栈中NCP称为IPCP，在IPX协议栈中，NCP称为IPXCP，而在AppleTalk协议栈中NCP称为APCP。假设这里PPP协议工作在TCP/IP协议栈。接下来我们看看PPP协议在第三阶段是如何使用IPCP协商网络层的参数的。
双方在IPCP协商阶段与LCP协商一样通常也会使用到前面提到的四种链路配置报文，只不过这四种报文此时是需要被IPCP封装：
IPCP Config-Request （配置请求）
IPCP Config-Ack （配置确认）
IPCP Config-NAK （配置非确认）
IPCP Config-Reject （配置拒绝）
那IPCP协商主要是协商网络层的哪些参数呢？我们先看 IPCP Config-Request（IPCP配置请求报文）结构：
Code ：ConfigurationRequest (0x01)
Identifier ：0x05
Length ：34
Options ：(30 bytes)
IP address ：0.0.0.0
Primary DNS server IPaddress ：0.0.0.0
Primary WINS serverIP address ：0.0.0.0
Secondary DNS serverIP address ：0.0.0.0
Secondary WINS serverIP address ：0.0.0.0
该报文中的字段含义请参考前面LCP报文字段的解释。从Configuration Request报文中可以看出，发送方需要和对方协商的参数是IP地址、Primary DNS server IP address(主DNS服务器IP地址)、Primary WINS server IP address（主WINS服务器IP地址）、Secondary DNS server IP address(辅助DNS服务器IP地址)、Secondary WINS server IP address(辅助WINS服务器IP地址)。
------------------------------------------------------------------------------------------
IPCP Config-Reject （IPCP配置拒绝报文）结构：
Code ：ConfigurationReject(0x04)
Identifier ：0x05
Length ：16
Options ：(12 bytes)
Primary WINS serverIP address ：0.0.0.0
Secondary WINS serverIP address ：0.0.0.0
从这个接收方回复的IPCP Config-Reject（配置拒绝）报文中可以看出，接收方对于发送方需要协商的两项参数(Primary WINS server IP address：0.0.0.0和Secondary WINS server IP address：0.0.0.0)是不认可的。我们继续看接下来的协商。
-------------------------------------------------------------------------------------------
IPCP Config-NAK （IPCP配置非确认报文）结构：
Code ：ConfigurationNak (0x03)
Identifier ：0x06
Length ：22
Options ：(18 bytes)
IP address ：113.232.89.224
Primary DNS server IPaddress ：202.96.64.68
Secondary DNS serverIP address ：202.96.69.38
该报文也是接收方回复的报文，从报文中我们看到接收方对于发送方协商的IP address、Primary DNS server IP address和Secondary DNS server IP address这三项参数没有异议，但对这三个参数中的具体内容并不认同，所以将这三个参数中的具体内容进行更改（由“0.0.0.0”改为具体的IP地址）。以上协商完成后，发送方应最后发送一个IPCP Config-Ack（配置确认）报文进行确认以上协商的选项参数。
IPCP Config-Ack （IPCP配置确认报文）结构如下：
Code ：ConfigurationAck (0x02)
Identifier ：0x07
Length ：22
Options ：(18 bytes)
IP address ：113.232.89.224
Primary DNS server IPaddress ：202.96.64.68
Secondary DNS serverIP address ：202.96.69.38
该报文的“Code”字段表明这是一个确认报文，PPP连接的发起者得到的IP地址是：113.232.89.224，得到的主DNS服务器的IP是：202.96.64.68，辅助DNS服务器的IP是：202.96.69.38。至此 IPCP协商完成。发送方IPCP进程的结束标志着PPP连接的完成，同时PPP也为承载网络层的IP数据包做好了链路层的准备工作。
一条PPP链路搭建好了之后，对该链路的维护工作也是必不可少的。本篇文章的开头部分我就介绍了，从链路的建立、维护到终止LCP协商基本上要使用到三类报文：
链路配置报文
链路维护报文
链路终止报文
现在我简单介绍一下LCP协商使用的第二类报文——“链路维护报文”。顾名思义，该报文是用于LCP协商成功后链路两端连接的维护工作的。链路的两端成功进行LCP协商之后，双方会周期性地向对方发送这种“链路维护报文”。该报文是 请求——响应 这种模式的。报文的名称和结构如下：
LCP Echo Request (LCP 回馈请求，目的就是询问对端是否一切正常)报文结构：
Code ：EchoRequest (0x09)
Identifier ：0x01
Length ：12
Magic number ：0x0111a51f
Message (4 bytes)
-------------------------------------------------------------------------------------------
LCP Echo Replay(LCP 回馈应答)报文结构：
Code ：EchoReply (0x0a)
Identifier ：0x01
Length ：12
Magic number ：0x00158d83
Message (4 bytes)
从这两个报文可以看出双方是依靠各自生成的“Magic number (魔术字)”来进行交互的，而且在双方周期性发送的这两个报文中，各自的魔术字（魔术字的作用简单说就是可以防止LCP链路出现环路）是不改变的。
最后再来说说PPP运行的第四阶段——PPP链路终止阶段。PPP链路终止阶段使用的是“链路终止报文”。该报文在PPP链路被拆除时使用。当通信双方中的某一方完成了数据传输后想断开PPP连接时，会通过LCP协议向对端发送链路终止报文——Terminal Request报文。
该报文结构如下：
Code ：TerminalRequest (0x05)
Identifier ：0x02
Length ：4
同样，接收方收到Terminal Request报文后会回应一个链路终止确认报文，该确认报文结构如下：
Code ：TerminalAck (0x06)
Identifier ：0x02
Length ：4
我们注意到这两个报文中都已没有了“Options(选项)”字段，只有“报文名称”、“Identifier(标识)”和“Length(报文长度)”三个字段了。可以看出与LCP链路的建立相比，链路的终止过程要简单得多了。关于PPP协议在设备中的配置，大家可参考另一篇文档——PPP配置。