PPP協議運行原理(三)

無論使用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配置。