【正文】 立階段協(xié)商配置參數(shù)選項(xiàng)的。IPCP在運(yùn)行的過程當(dāng)中，主要是完成點(diǎn)對(duì)點(diǎn)通信設(shè)備的兩端動(dòng)態(tài)的協(xié)商IP地址。下面來(lái)看一下驗(yàn)證通過時(shí)，驗(yàn)證方給被驗(yàn)證方所發(fā)送的一段報(bào)文內(nèi)容：7E FF 03 C2 23 03 01 00 17 57 65 6C 63 6F 6D 65 20 74 6F20 4D 41 35 32 30 30 41 2E 7E此時(shí)所回應(yīng)的報(bào)文的代碼域?yàn)?3，且報(bào)文的實(shí)際內(nèi)容是，Wel to MA5200A。例11： 如圖42所示，當(dāng)路由器A（被驗(yàn)證方）收到了路由器B 的Challenge報(bào)文后，報(bào)文內(nèi)容如下：7E FF 03 C2 23 01 01 00 1C 10 FF 41 CF 22 AA 8E F1 B9 99 9A 79 A7 56 78 C4 A7 4d 41 35 32 30 30 417E下劃線的前16個(gè)字節(jié)是驗(yàn)證方隨機(jī)產(chǎn)生的一段報(bào)文，后7個(gè)字節(jié)是驗(yàn)證方的主機(jī)名（MA5200A），而且單個(gè)字節(jié)10表示隨機(jī)報(bào)文的長(zhǎng)度。 與PAP認(rèn)證比起來(lái)，CHAP認(rèn)證更具有安全性，從前面認(rèn)證過程的數(shù)據(jù)包交換過程中不難發(fā)現(xiàn)，采用PAP認(rèn)證時(shí)，被驗(yàn)證是采用明文的方式直接將用戶名和密碼發(fā)送給驗(yàn)證方的，而對(duì)于PAP認(rèn)證則不一樣。反之，如果用戶名與密碼不符，則向?qū)Ψ椒祷仳?yàn)證不通過的響應(yīng)報(bào)文。PAP認(rèn)證是兩次握手，在鏈路建立階段，依據(jù)設(shè)備上的配置情況，如果是使用PAP認(rèn)證，則驗(yàn)證方在發(fā)送ConfigRequest報(bào)文時(shí)會(huì)攜帶認(rèn)證配置參數(shù)選項(xiàng)，而對(duì)于被驗(yàn)證方而言則是不需要，它只需要收到該配置請(qǐng)求報(bào)文后根據(jù)自身的情況給對(duì)端返回相應(yīng)的報(bào)文。 我們所知兩個(gè)設(shè)備在使用PAP進(jìn)行認(rèn)證之前，應(yīng)該確認(rèn)那一方是驗(yàn)證方，那一方是被驗(yàn)證方。一般是在PPP設(shè)備互連的設(shè)備上進(jìn)行配置的，或設(shè)備默認(rèn)支持一個(gè)缺省的認(rèn)證方式（PAP是大部分設(shè)備所默認(rèn)的認(rèn)證方式）。當(dāng)然對(duì)于某些設(shè)備還會(huì)采用第二種機(jī)制，就是不產(chǎn)生任何事件去影響當(dāng)前LCP的狀態(tài)機(jī)，而是停留在請(qǐng)求發(fā)送狀態(tài)。這時(shí)接收端比較這個(gè)ConfigNak報(bào)文與上一次發(fā)出去的一樣，因此鏈路存在環(huán)路的可能性又增大了。此時(shí)接收端將發(fā)送一個(gè)ConfigNak報(bào)文，并在該報(bào)文中攜帶一個(gè)重新產(chǎn)生的魔術(shù)字，而且此時(shí)在未接收到任何ConfigRequest或ConfigNak報(bào)文之前，接收端也不會(huì)發(fā)送任何的ConfigRequest報(bào)文。一般來(lái)說魔術(shù)字的選擇會(huì)采用設(shè)備的系列號(hào)、網(wǎng)絡(luò)硬件地址或時(shí)鐘。對(duì)于鏈路終止報(bào)文也同樣需要ID一致，當(dāng)接收到TerminateReply報(bào)文才會(huì)做鏈路終止操作。鏈路終止報(bào)文分為TerminateRequest和TerminateReply兩種報(bào)文。 當(dāng)接收ConfigRequest報(bào)文的一端不能識(shí)別所有的發(fā)送端發(fā)送過來(lái)的配置參數(shù)選項(xiàng)時(shí)，此時(shí)接收端將會(huì)向?qū)Χ嘶匾粋€(gè)ConfigReject報(bào)文，該報(bào)文中的數(shù)據(jù)域只攜帶那些不能識(shí)別的配置參數(shù)選項(xiàng)（當(dāng)配置參數(shù)選項(xiàng)的類型域不識(shí)別時(shí)）。當(dāng)接收ConfigRequest報(bào)文的一端能識(shí)別發(fā)送過來(lái)的所有配置參數(shù)選項(xiàng)且認(rèn)可所有配置參數(shù)選項(xiàng)數(shù)據(jù)域的內(nèi)容時(shí)，接收端將會(huì)給對(duì)端回一個(gè)ConfigAck報(bào)文并將配置請(qǐng)求報(bào)文中的配置參數(shù)選項(xiàng)原封不動(dòng)的放置在ConfigAck報(bào)文的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項(xiàng)的順序）。當(dāng)接收方收到ConfigRequest報(bào)文時(shí)，會(huì)在剩下的三種類型的報(bào)文中選擇一種來(lái)響應(yīng)對(duì)方的請(qǐng)求報(bào)文，到底選擇哪種報(bào)文來(lái)響應(yīng)對(duì)方需依據(jù)以下兩個(gè)條件：不能完全識(shí)別配置參數(shù)選項(xiàng)的類型域，我們知道一個(gè)ConfigRequest報(bào)文中會(huì)同時(shí)攜帶多個(gè)配置參數(shù)選項(xiàng)，而對(duì)于一個(gè)支持PPP協(xié)議的通信設(shè)備也不一定會(huì)支持上表中所有列出的配置選項(xiàng)，即使支持，也可能在實(shí)際應(yīng)用中關(guān)閉掉某些選項(xiàng)功能。數(shù)據(jù)域的內(nèi)容依據(jù)不同LCP數(shù)據(jù)報(bào)文的內(nèi)容也是不一樣的。一般而言在進(jìn)入鏈路建立階段時(shí)，通信雙方無(wú)論哪一端都會(huì)連續(xù)發(fā)送幾個(gè)配置請(qǐng)求報(bào)文（ConfigRequest報(bào)文），而這幾個(gè)請(qǐng)求報(bào)文的數(shù)據(jù)域可能是完全一樣的，而僅僅是它們的標(biāo)識(shí)域不同罷了。在鏈路建立階段的整個(gè)過程中信息域的內(nèi)容是在變化的，它包括很多種類型的報(bào)文，所以這些報(bào)文也要通過相應(yīng)的字段來(lái)區(qū)分，PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021。當(dāng)載波丟失、授權(quán)失敗、鏈路質(zhì)量檢測(cè)失敗和管理員人為關(guān)閉鏈路等情況均會(huì)導(dǎo)致鏈路終止。一旦PPP完成了前面幾個(gè)階段，每種網(wǎng)絡(luò)層協(xié)議（IP、IPX和AppleTalk）會(huì)通過各自相應(yīng)的網(wǎng)絡(luò)控制協(xié)議進(jìn)行配置，每個(gè)NCP協(xié)議可在任何時(shí)間打開和關(guān)閉。然而，鏈路質(zhì)量的檢測(cè)也會(huì)在這個(gè)階段同時(shí)發(fā)生，但協(xié)議規(guī)定不會(huì)讓鏈路質(zhì)量的檢測(cè)無(wú)限制的延遲驗(yàn)證過程。如果在該階段收到了非LCP數(shù)據(jù)報(bào)文，則會(huì)將這些報(bào)文丟棄。該階段主要是發(fā)送一些配置報(bào)文來(lái)配置數(shù)據(jù)鏈路，這些配置的參數(shù)不包括網(wǎng)絡(luò)層協(xié)議所需的參數(shù)。當(dāng)處于在鏈路不可用階段時(shí)，LCP的狀態(tài)機(jī)是處于initial（初始化狀態(tài)）或starting（準(zhǔn)備啟動(dòng)狀態(tài)），一旦檢測(cè)到物理線路可用，則LCP的狀態(tài)機(jī)就要發(fā)生改變。以下是PPP協(xié)議整個(gè)鏈路過程需經(jīng)歷階段的狀態(tài)轉(zhuǎn)移圖說明：在點(diǎn)對(duì)點(diǎn)鏈路的配置、維護(hù)和終止過程中，PPP需經(jīng)歷以下幾個(gè)階段：鏈路不可用階段。 數(shù)據(jù)通信設(shè)備（在本文中指路由器）的兩端如果希望通過PPP協(xié)議建立點(diǎn)對(duì)點(diǎn)的通信，無(wú)論哪一端的設(shè)備都需發(fā)送LCP數(shù)據(jù)報(bào)文來(lái)配置鏈路（測(cè)試鏈路）。CRC校驗(yàn)域主要是對(duì)PPP數(shù)據(jù)幀傳輸?shù)恼_性進(jìn)行檢測(cè)的，當(dāng)然在數(shù)據(jù)幀中引入了一些傳輸?shù)谋ＷC機(jī)制是好的，但可以反過來(lái)說，同樣我們會(huì)引入更多的開銷，這樣可能會(huì)增加應(yīng)用層交互的延遲。信息域如果不足1500字節(jié)時(shí)可被填充，但不是必須的，如果填充則需通信雙方的兩端能辨認(rèn)出有用與無(wú)用的信息方可正常通信。協(xié)議域的內(nèi)容必須依據(jù)ISO 3309的地址擴(kuò)展機(jī)制所給出的規(guī)定。但由于PPP協(xié)議是被運(yùn)用在點(diǎn)對(duì)點(diǎn)的鏈路上的特殊性，它不像廣播或多點(diǎn)訪問的網(wǎng)絡(luò)一樣，因?yàn)辄c(diǎn)對(duì)點(diǎn)的鏈路就可以唯一標(biāo)示對(duì)方，因此使用PPP協(xié)議互連的通信設(shè)備的兩端無(wú)須知道對(duì)方的數(shù)據(jù)鏈路層地址，所以該字節(jié)已無(wú)任何意義，按照協(xié)議的規(guī)定將該字節(jié)填充為全1的廣播地址。緊接在起始標(biāo)志字節(jié)后的一個(gè)字節(jié)是地址域，該字節(jié)為0xFF。隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)帶寬已不再是瓶頸，所以PPP擴(kuò)展協(xié)議的應(yīng)用也就越來(lái)越少，因此往往人們?cè)跀⑹鯬PP協(xié)議時(shí)經(jīng)常會(huì)忘記它的存在。 SLIP不提供糾錯(cuò)機(jī)制，錯(cuò)誤只能依靠上層協(xié)議實(shí)現(xiàn)。如果要傳送的IP包中正好有一個(gè)字符0xc0要傳送，為了避免它被當(dāng)作END字符，要用連續(xù)的兩個(gè)字節(jié)0xdb和0xdc來(lái)代替它。通過在被發(fā)送IP數(shù)據(jù)報(bào)的尾部增加特殊的END字符（0xC0 ）從而形成一個(gè)簡(jiǎn)單的SLIP的數(shù)據(jù)幀，而后該幀會(huì)被傳送到物理層進(jìn)行發(fā)送。第1章 概述SLIP的全稱是Serial Line IP，出現(xiàn)在80年代中期，并被使用在BSD UNIX主機(jī)和SUN的工作站上。課程目標(biāo)完成本課程學(xué)習(xí)，學(xué)員能夠：l 了解SLIP協(xié)議的基本原理。本課程介紹PPP協(xié)議和PPPOE協(xié)議。l 掌握PPPOE協(xié)議的基本原理。SLIP的幀格式由IP包加上END字符組成。END是判斷一個(gè)SLIP幀是否結(jié)束的標(biāo)志。并且，由于幀格式中沒有類型字段，致使如果一條串行線路如果用于SLIP，就不能同時(shí)使用其它協(xié)議。第2章 PPP協(xié)議PPP協(xié)議主要包括三部分：LCP（Link Control Protocol）鏈路控制協(xié)議、NCP（Network Control Protocol）和PPP的擴(kuò)展協(xié)議（如Multilink Protocol）。以下為對(duì)PPP數(shù)據(jù)幀封裝格式的一點(diǎn)說明：每一個(gè)PPP數(shù)據(jù)幀均是以一個(gè)標(biāo)志字節(jié)起始和結(jié)束的，該字節(jié)為0x7E。例如如果兩個(gè)以太網(wǎng)上的主機(jī)希望能夠通信的話，首先發(fā)送端需獲知對(duì)端的MAC地址。協(xié)議域可用來(lái)區(qū)分PPP數(shù)據(jù)幀中信息域所承載的數(shù)據(jù)報(bào)文的內(nèi)容。信息域缺省時(shí)最大長(zhǎng)度不能超過1500字節(jié)，其中包括填充域的內(nèi)容，1500字節(jié)大小等于PPP協(xié)議中配置參數(shù)選項(xiàng)MRU（Maximum Receive Unit）的缺省值，在實(shí)際應(yīng)用當(dāng)中可根據(jù)實(shí)際需要進(jìn)行信息域最大封裝長(zhǎng)度選項(xiàng)的協(xié)商。 當(dāng)在某些特殊應(yīng)用中，可能會(huì)使用到小于1500字節(jié)或大于1500字節(jié)的情況，這時(shí)在ConfigRequest報(bào)文就會(huì)攜帶要協(xié)商的MRU配置參數(shù)選項(xiàng)值。最為常用的是IPCP協(xié)議，當(dāng)點(diǎn)對(duì)點(diǎn)的兩端進(jìn)行NCP參數(shù)配置協(xié)商時(shí)，主要是用來(lái)通信雙方的網(wǎng)絡(luò)層地址。只有當(dāng)任何一端收到LCP或NCP的鏈路關(guān)閉報(bào)文時(shí)（一般而言協(xié)議是不要求NCP有關(guān)閉鏈路的能力的，因此通常情況下關(guān)閉鏈路的數(shù)據(jù)報(bào)文是在LCP協(xié)商階段或應(yīng)用程序會(huì)話階段發(fā)出的）；物理層無(wú)法檢測(cè)到載波或管理人員對(duì)該鏈路進(jìn)行關(guān)閉操作，都會(huì)將該條鏈路斷開，從而終止PPP會(huì)話。先簡(jiǎn)單提一下鏈路建立階段，在這個(gè)階段主要是通過LCP協(xié)議進(jìn)行鏈路參數(shù)的配置，LCP在此階段的狀態(tài)機(jī)也會(huì)根據(jù)不同的事件發(fā)生變化。是PPP協(xié)議最關(guān)鍵和最復(fù)雜的階段。同理可知，另一端也是一樣的，但須注意的一點(diǎn)是在鏈路配置階段雙方是鏈路配置操作過程是相互獨(dú)立的。在該階段支持PAP和CHAP兩種認(rèn)證方式，驗(yàn)證方式的選擇是依據(jù)在鏈路建立階段雙方進(jìn)行協(xié)商的結(jié)果。網(wǎng)絡(luò)層協(xié)議階段。網(wǎng)絡(luò)終止階段，PPP能在任何時(shí)候終止鏈路。 LCP數(shù)據(jù)報(bào)文是在鏈路建立階段被交換的，它作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中。 標(biāo)識(shí)域也是一個(gè)字節(jié)，其目的是用來(lái)匹配請(qǐng)求和響應(yīng)報(bào)文。長(zhǎng)度域所指示字節(jié)數(shù)之外的字節(jié)將被當(dāng)作填充字節(jié)而忽略掉，而且該域的內(nèi)容不能超過MRU的值。當(dāng)通信雙方需要建立鏈路時(shí)，無(wú)論哪一方都需要發(fā)送ConfigRequest報(bào)文并攜帶每一端自已所希望協(xié)商的配置參數(shù)選項(xiàng)。所以依據(jù)上面的兩個(gè)條件，我們就可以明確在回應(yīng)對(duì)方配置請(qǐng)求報(bào)文時(shí)，采用何種報(bào)文回應(yīng)。然而當(dāng)接收端收到ConfigNak報(bào)文后，會(huì)重新發(fā)送ConfigRequest報(bào)文，而這個(gè)ConfigRequest報(bào)文與上一次所發(fā)送的ConfigRequest報(bào)文區(qū)別在于那些被對(duì)端不認(rèn)可的配置參數(shù)選項(xiàng)的內(nèi)容被填寫到剛剛協(xié)商完后再次發(fā)送的ConfigRequest報(bào)文中（ConfigNak報(bào)文發(fā)送回來(lái)的那些配置參數(shù)選項(xiàng)）。對(duì)于PPP的兩個(gè)端點(diǎn)而言，兩者是獨(dú)立完成各自的配置參數(shù)選項(xiàng)的協(xié)商過程的。LCP的鏈路終止報(bào)文的數(shù)據(jù)域與鏈路配置報(bào)文的數(shù)據(jù)域不一樣，鏈路終止報(bào)文中無(wú)需攜帶各配置參數(shù)選項(xiàng)。魔術(shù)字在目前所有的設(shè)備當(dāng)中都是需要進(jìn)行協(xié)商的，它被放在ConfigRequest的配置選項(xiàng)參數(shù)中進(jìn)行發(fā)送，而且需要由自身的通信設(shè)備獨(dú)立產(chǎn)生，協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術(shù)字，從而導(dǎo)致通信出現(xiàn)不必要的麻煩，因此要求由設(shè)備采用一些隨機(jī)方法產(chǎn)生一個(gè)獨(dú)一無(wú)二的魔術(shù)字。但如果一致的話，接收端認(rèn)為鏈路可能存在環(huán)路，但不一定存在環(huán)路，還需進(jìn)一步確認(rèn)。2. 鏈路實(shí)際上確實(shí)存在環(huán)路，一段時(shí)間后ConfigNak報(bào)文會(huì)