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配置。