{企業(yè)通用培訓(xùn)}華為培訓(xùn)協(xié)議和協(xié)議課程BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0HuaweiTechnologies目錄課程說明1課程介紹1課程目標1第1章概述2第2章PPP協(xié)議8第3章PPPOE協(xié)議48附錄縮略詞表74BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0課程說明課程說明課程介紹本教材為寬帶產(chǎn)品工程師培訓(xùn)公共課程。本課程介紹PPP協(xié)議和PPPOE協(xié)議。課程目標完成本課程學(xué)習(xí)，學(xué)員能夠：了解SLIP協(xié)議的基本原理。掌握PPP協(xié)議的基本原理。掌握LCP協(xié)議和NCP協(xié)議數(shù)據(jù)報文的交換過程。掌握PPPOE協(xié)議的基本原理。1BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第1章概述第1章概述2BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第1章概述SLIP的全稱是SerialLineIP80BSDUNIX主機和SUN的工作站上。因為SLIP1200bps到19.2Kbps的專用線路和撥號UNIX80年代末90年代初期，被廣泛用于家庭中每臺有RS232串口的計算機和調(diào)制解調(diào)器連接到Internet。SLIP的幀格式由IP包加上END字符組成。通過在被發(fā)送IP數(shù)據(jù)報的尾部增加特殊的END0xC0SLIP的數(shù)據(jù)幀，常發(fā)送端在被傳送數(shù)據(jù)報的開始處也傳一個END始位置的END個含有無意義報文的數(shù)據(jù)幀會在對端的高層被丟棄。END是判斷一個SLIP幀是否結(jié)束的標志。如果要傳送的IP包中正好有一個字符0xc0要傳送，為了避免它被當作END0xdb和0xdc0xdb，那么就用連續(xù)傳輸兩個字節(jié)0xdb和0xdd來代替它。3BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第1章概述SLIP只支持IPIPX行線路如果用于SLIP，就不能同時使用其它協(xié)議。4BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第1章概述SLIP不提供糾錯機制，錯誤只能依靠上層協(xié)議實現(xiàn)。5BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第1章概述SLIP幀的封裝格式非常簡單，通信雙方無需在數(shù)據(jù)報發(fā)送前協(xié)商任何配置參數(shù)選項（在PPP協(xié)IP層通信前必需先獲知對方的IP缺點，導(dǎo)致了SLIP很快的被后面要講的PPP協(xié)議所替代。6BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第1章概述7BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議第2章PPP協(xié)議8BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議9BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議10BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議PPP協(xié)議主要包括三部分：LCP（LinkControlProtocol）鏈路控制協(xié)議、NCP（NetworkControlProtocolPPP的擴展協(xié)議（如MultilinkProtocol）。隨著網(wǎng)絡(luò)技術(shù)的不PPPPPP協(xié)議時經(jīng)常會忘記它的存在。11BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議我們在提及PPPHDLCHDLC也是最常用的數(shù)據(jù)鏈SDLCHDLC的封裝格式的，同樣PPP協(xié)議也不例外，它也采用了HDLC的定界幀格式。以下為對PPP數(shù)據(jù)幀封裝格式的一點說明：每一個PPP數(shù)據(jù)幀均是以一個標志字節(jié)起始和結(jié)束的，該字節(jié)為0x7E。緊接在起始標志字節(jié)后的一個字節(jié)是地址域，該字節(jié)為0xFF。我們熟知網(wǎng)絡(luò)是分層的，且對等對不同的網(wǎng)絡(luò)，在數(shù)據(jù)鏈路層則表現(xiàn)為需要知道對方的MAC地址、X.121地址、ATM地址等；在網(wǎng)絡(luò)層則表現(xiàn)為需要知道對方的IP地址、IPX地址等；而在傳輸層則需要知道對方的協(xié)議端口MAC于PPPPPP協(xié)議互連的通信設(shè)備的兩端無須知道對方的數(shù)據(jù)鏈路層地址，所以該字節(jié)已無任何意義，按照協(xié)議的規(guī)定將該字節(jié)填充為全1的廣播地址。PPP填充為0x03。就PPPPPP數(shù)

ISO3309的地址擴展機制所給出

的規(guī)定。該機制規(guī)定協(xié)議域所填充的內(nèi)容必須為奇數(shù)，也即是要求低字節(jié)的最低位為“1”，高

字節(jié)的最低位為“0”。如果當發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域字段不符合上述規(guī)定，則接收

Protocol-Reject報文尾部將完整地填充被拒絕的報文。信息域缺省時最大長度不能超過15001500字節(jié)大小等于PPP協(xié)

議中配置參數(shù)選項MRU（MaximumReceiveUnit信息域最大封裝長度選項的協(xié)商。信息域如果不足1500字節(jié)時可被填充，但不是必須的，如果

填充則需通信雙方的兩端能辨認出有用與無用的信息方可正常通信。說明：MRU表示本端接收到的PPP數(shù)據(jù)幀的數(shù)據(jù)域的最大值。通常情況下這個參數(shù)選項使用默認值（1500Config-Request報文中雙方都不會攜帶這個配置參數(shù)選項。當在某些特殊應(yīng)用中，可能會使用到小于1500字節(jié)或大于1500字節(jié)的情況，這時在Config-Request報文就會攜帶要協(xié)商的MRU配置參數(shù)選項值。CRC校驗域主要是對PPP12BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議遲。13BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議為了能適應(yīng)復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，PPP協(xié)議提供了一種鏈路控制協(xié)議來配置和測試數(shù)據(jù)通信鏈路，它能用來協(xié)商PPP的錯誤；終止一條鏈路。PPP的網(wǎng)絡(luò)控制協(xié)議根據(jù)不同的網(wǎng)絡(luò)層協(xié)議可提供一族網(wǎng)絡(luò)控制協(xié)議(NCP)，常用的有提供給TCP/IP網(wǎng)絡(luò)使用的IPCPSPX/IPX網(wǎng)絡(luò)使用的IPXCP網(wǎng)絡(luò)控制協(xié)議等。最為常用的是IPCP協(xié)議，當點對點的兩端進行NCP參數(shù)配置協(xié)商時，主要是用來通信雙方的網(wǎng)絡(luò)層地址。14BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議PPP端的設(shè)備都需發(fā)送LCP數(shù)據(jù)報文來配置鏈路（測試鏈路）。一旦LCP的配置參數(shù)選項協(xié)商完后，通信的雙方就會根據(jù)LCP配置請求報文中所協(xié)商的認證配置參數(shù)選項來決定鏈路兩端設(shè)備所采用的認證方式。協(xié)議缺省情況下雙方是不進行認證的，而直接進入到NCP配置參數(shù)選項的協(xié)商，LCP或NCP的鏈路關(guān)閉報NCP在LCPPPPPPP協(xié)議整個鏈路過程需經(jīng)歷階段的狀態(tài)轉(zhuǎn)移圖說明：在點對點鏈路的配置、維護和終止過程中，PPP需經(jīng)歷以下幾個階段：PPPLCP

LCP不可用階段時，LCP的狀態(tài)機是處于initialstartingLCP階段，往往在實際過程中這個階段所停留的時間是很短的，僅僅是檢測到對方設(shè)備的存在。

PPPNAS或BAS設(shè)備的PPP模塊缺省就需要支持

PAP或CHAP中的一種認證方式）。在此階段LCP的狀態(tài)機會發(fā)生兩次改變，前面我們說了當鏈

路處于不可用階段時，此時LCP的狀態(tài)機處于initial或starting，當檢測到鏈路可用時，則

物理層會向鏈路層發(fā)送一個UP事件，鏈路層收到該事件后，會將LCP的狀態(tài)機從當前狀態(tài)改變?yōu)镽equest-Sent（請求發(fā)送狀態(tài)），根據(jù)此時的狀態(tài)機LCP會進行相應(yīng)的動作，也即是開始發(fā)送Config-RequestConfig-AckLCP的狀態(tài)機又要發(fā)生改變，從當前狀態(tài)改變?yōu)閛pened狀態(tài)，進入Opened狀態(tài)后收到Config-Ack報文的LCP數(shù)據(jù)報文，則會將這些報文丟棄。15BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議鏈路兩端的設(shè)備是不進行認證的。在該階段支持PAP和CHAP兩種認證方式，驗證方式的選擇是協(xié)議和質(zhì)量檢測數(shù)據(jù)報文，其它的數(shù)據(jù)報文都會被丟棄。如果在這個階段再次收到了Config-Request報文，則又會返回到鏈路建立階段。網(wǎng)絡(luò)層協(xié)議階段。一旦PPP完成了前面幾個階段，每種網(wǎng)絡(luò)層協(xié)議（IP、IPX和AppleTalk）會NCPNCP的狀態(tài)機變成Opened狀態(tài)時，則PPP就可以開始在鏈路上承載網(wǎng)絡(luò)層的數(shù)據(jù)包報文了。如果在個階段收到了Config-Request報文，則又會返回到鏈路建立階段。PPPLCP的鏈路終止報文來關(guān)對于NCP協(xié)議，它是沒有也沒有必要去關(guān)閉PPP鏈路的。16BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議LCPPPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中。文也要通過相應(yīng)的字段來區(qū)分，PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021。LCP收到LCPLCPCode-Reject報文）。信雙方無論哪一端都會連續(xù)發(fā)送幾個配置請求報文（Config-Request報文），而這幾個請求報文的數(shù)據(jù)域可能是完全一樣的，而僅僅是它們的標識域不同罷了。通常一個配置請求報文的ID是從0x01開始逐步加1的，當對端接收到該配置請求報文后，無論使用何種報文（回應(yīng)報文可能是Config-Ack、Config-Nak和Config-Reject三種報文中的一種）來回應(yīng)對方，但必須要求回應(yīng)報文中的IDID一致，當通信設(shè)備收到回應(yīng)后就可以將該回應(yīng)與發(fā)送時的進行比較來決定下一步的操作。長度域的內(nèi)容=+標志域+長度域+將被當作填充字節(jié)而忽略掉，而且該域的內(nèi)容不能超過MRU的值。數(shù)據(jù)域的內(nèi)容依據(jù)不同LCP數(shù)據(jù)報文的內(nèi)容也是不一樣的。17BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議18BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議19BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議20BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議這種報文的數(shù)據(jù)域還要攜帶許多配置參數(shù)選項的。鏈路配置報文主要包括Config-RequestConfig-AckConfig-Nak和Config-Reject四種報文。當通信雙方需要建立鏈路時，無論哪一方都需要發(fā)送Config-Request報文并攜帶每一端自已所希望協(xié)商的配置參數(shù)選項。當接收方收到Config-Request報文時，會在剩下的三種類型的報文中選擇一種來響應(yīng)對方的請求報文，到底選擇哪種報文來響應(yīng)對方需依據(jù)以下兩個條件：不能完全識別配置參數(shù)選項的類型域，我們知道一個Config-Request報文中會同時攜帶多個配置參數(shù)選項，而對于一個支持PPP協(xié)議的通信設(shè)備也不一定會支持上表中所有列出的配置選項，PPP協(xié)議通信的一端可能0x01和0x03Config-Request報文中含有0x04即是不支持這個配置參數(shù)選項的協(xié)商）。如果能支持完全識別配置參數(shù)選項，但接收端也可能不認可Config-Request報文中配置參數(shù)選0，而對端認為應(yīng)該為其它值，這種情況就屬于不支持配置參數(shù)選項中的內(nèi)容）。所以依據(jù)上面的兩個條件，我們就可以明確在回應(yīng)對方配置請求報文時，采用何種報文回應(yīng)。21BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議當接收Config-Request報文的一端能識別發(fā)送過來的所有配置參數(shù)選項且認可所有配置參數(shù)選項數(shù)據(jù)域的內(nèi)容時，接收端將會給對端回一個Config-Ack報文并將配置請求報文中的配置參數(shù)選項原封不動的放置在Config-Ack報文的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項Config-Ack22BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議當接收Config-Request報文的一端能識別發(fā)送端所發(fā)送過來的所有配置參數(shù)選項，但對部分配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容不認可時，接收端將會給對端回應(yīng)一個Config-Nak報文，該報文中收到Config-Nak報文后，會重新發(fā)送Config-Request報文，而這個Config-Request報文與上一次所發(fā)送的Config-Request報文區(qū)別在于那些被對端不認可的配置參數(shù)選項的內(nèi)容被填寫到剛剛協(xié)商完后再次發(fā)送的Config-RequestConfig-Nak報文發(fā)送回來的那些配置參數(shù)選項）。23BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議當接收Config-Request報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時，此時接收端將會向?qū)Χ嘶匾粋€Config-RejectConfig-Reject發(fā)送一個Config-Request報文，這個配置請求報文與上一次發(fā)送的區(qū)別在于將不可識別的那些配置參數(shù)選項給刪除了。24BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議25BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議于PPP的兩個端點而言，兩者是獨立完成各自的配置參數(shù)選項的協(xié)商過程的。26BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議鏈路終止報文分為Terminate-Request和Terminate-Reply兩種報文。LCP報文中提供了一種機Terminate-Request到一個Terminate-ReplyTerminate-Request個Terminate-Reply報文，同時等待對端先將鏈路斷開后，再完成本端的所有斷開的操作。LCP參數(shù)選項。對于鏈路終止報文也同樣需要ID一致，當接收到Terminate-Reply報文才會做鏈路終止操作。27BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議魔術(shù)字是在LCP的Config-Request報文中被協(xié)商的，并且可被一些其它類型的LCP數(shù)據(jù)報文所Echo-RequestEcho-Reply報文和Quality-ProtocolPPP協(xié)議本身它是LCP的數(shù)據(jù)報文需要使用魔術(shù)字時，那么只能是將魔術(shù)字的內(nèi)容填充為全0；反之，則填充為配置參數(shù)選項協(xié)商后的結(jié)果。魔術(shù)字在目前所有的設(shè)備當中都是需要進行協(xié)商的，它被放在Config-Request的配置選項參數(shù)中進行發(fā)送，而且需要由自身的通信設(shè)備獨立產(chǎn)生，協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術(shù)字，個廠商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字的方法是一樣的。我們知道魔術(shù)字產(chǎn)生的作用是用來幫助檢測鏈路是否存在環(huán)路，當接收端收到一個Config-RequestConfig-Request存在環(huán)路，但不一定存在環(huán)路，還需進一步確認。此時接收端將發(fā)送一個Config-Nak報文，并在該報文中攜帶一個重新產(chǎn)生的魔術(shù)字，而且此時在未接收到任何Config-Request或Config-NakConfig-Request以下兩種情況發(fā)生：1.鏈路實際不存在環(huán)路，而是由于對方在產(chǎn)生魔術(shù)字時與接收端產(chǎn)生的一

致，但實際這種情況出現(xiàn)的概率是很小的。當Config-Nak被對端接收到后，應(yīng)該發(fā)送一個

Config-Request報文（此報文中的魔術(shù)字為Nak報文中的），當對端接收到后，與上次比較，

由于接收端已經(jīng)在Nak報文中產(chǎn)生了一個不同的魔術(shù)字，此時接收端收到的Config-Request報

文中的魔術(shù)字與上次配置請求報文中不一樣，所以接收端可斷定鏈路不存在環(huán)路。2.鏈路實際上確實存在環(huán)路，一段時間后Config-Nak報文會返回到發(fā)送該

報文的同一端。這時接收端比較這個Config-Nak報文與上一次發(fā)出去的一樣，因此鏈路存在環(huán)

路的可能性又增大了。我們知道當一端收到了一個Config-Nak報文時，又會發(fā)送一個Config-RequestConfig-Nak在這條鏈路上就會不斷的出現(xiàn)Config-Request、Config-Nak報文，因此這樣周而復(fù)始下去，接收端就會認為PPP在環(huán)路。但在實際應(yīng)用中根據(jù)不同設(shè)備實現(xiàn)PPPLCP狀態(tài)機發(fā)一個Down事件，

這時可能會使LCP28BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議LCP時認為鏈路有環(huán)路的一端設(shè)備需要不斷的向鏈路上發(fā)送Echo-Request報文來檢測鏈路環(huán)路是否Echo-ReplyPPP的過程。29BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議PPPLCP的Config-RequestPAP/CHAP）。

一般是在PPPPAP是大部

式，則回應(yīng)一個Config-AckConfig-Nak報文，并附帶上自希望雙方采用的

認證方式。當對方接收到Config-Ack報文后就可以開始進行認證了，而如果收到得是

Config-NakConfig-Nak回應(yīng)一個新的Config-Request（并攜帶上Config-Nak回應(yīng)一個Config-Reject報文，那么雙方就無法通過認證，從而不可能建立起PPP鏈路。

PPP支持兩種授權(quán)協(xié)議：PAP（PasswordAuthenticationProtocol）和CHAP

（ChallengeHandAuthenticationProtocol）。我們所知兩個設(shè)備在使用PAP際上對于使用PPP協(xié)議互連的兩端來說，既可作為認證方，也可作為被認證方。但通常情況下，

PAPPAP配置，對于MA5200IP接入設(shè)備，它默認就作為驗證方，但可通過使用命令

PAPAuthenticationPAP/CHAPPAPPAP方在發(fā)送Config-Request報文時會攜帶認證配置參數(shù)選項，而對于被驗證方而言則是不需要，

采用的是PAPPPP鏈路建立的過程中

使用的認證方式為PAP的話，那么驗證方在其Config-Request報文中必須含有認證配置參數(shù)選

項，且該認證配置參數(shù)選項的數(shù)據(jù)域為0xC023。當通信設(shè)備的兩端在收到對方返回的Config-Ack報文時，就從各自的鏈路建立階段進入到認證

PAP次的認證失敗后，則會從當前狀態(tài)返回鏈路不可用狀態(tài)。例如：當路由器A（被驗證方）收到了路由器B的Config-Ack報文后，因為是使用PAP認證，

所以作為被驗證方的路由器A應(yīng)主動向驗證方（路由器B）發(fā)送認證請求報文30BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議（PAPAuthenticate），用戶名和密碼均為163，報文的內(nèi)容如下：7EFF03C000C03313633033136337E下劃線的前四個字節(jié)是用戶名，后四個字節(jié)是密碼。當路由器BA回應(yīng)一個PAPAuthenticateAck7EFFE因無法認證通過，可能是無此用戶名或密碼不匹配。31BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議與PAP認證比起來，CHAP認證更具有安全性，從前面認證過程的數(shù)據(jù)包交換過程中不難發(fā)現(xiàn)，采用PAPPAP認證則不一樣。CHAP為三次握手協(xié)議，它只在網(wǎng)絡(luò)上傳送用戶名而不傳送口令，因此安全性比PAP高。在驗證PAP文ID和驗證方發(fā)送的隨機報文用Md5加密算法生成應(yīng)答，隨后將應(yīng)答和自己的主機名送回，同與被驗證方一致用戶名后，根據(jù)該用戶名所對應(yīng)的密鑰、保留報文ID和隨機報文用Md5加密算法生成結(jié)果，和剛剛被驗證方所返回的應(yīng)答進行比較，相同則返回Ack，否則返回Nak。例114-2所示，當路由器AB的Challenge報文后，報文內(nèi)容如下：7EFF03C001C10FF41CF22AA8EF1B9999A79A75678C4A74d4135323030417E下劃線的前16個字節(jié)是驗證方隨機產(chǎn)生的一段報文，后7個字節(jié)是驗證方的主機名（MA5200A），而且單個字節(jié)10表示隨機報文的長度。而此時路由器A會根據(jù)用戶名所對應(yīng)的密鑰使用報文的ID和該報文的內(nèi)容生成一個回應(yīng)報文，報文內(nèi)容如下：7EFF03C001F10188622FFCE81D068FF808500A7E3853570706B6973734068

75617E01改為02文的長度有變化，主要后而一個下劃線的內(nèi)容是被驗證方的主機名（），而且此時回應(yīng)的16個

字節(jié)的報文已經(jīng)是經(jīng)過MD5算法加密過的。MD5來的16個字節(jié)的加密值一樣的話，則就會發(fā)送一個報文通知被驗證方，你的認證已經(jīng)通過，我們可以進入到下一個階段了。在實際應(yīng)用當中，我們很多都是使用PC機來進行撥號這個過程，實際中當驗證方發(fā)送挑戰(zhàn)后，PC機只接收而并不去查本地數(shù)據(jù)庫，而直接使用在撥號對話框中所輸入的密碼和報文的ID及報報文的內(nèi)容進行MD5PC機采用PPPOE軟件撥入到MA5200時就是這樣的）。下面來看一下驗證通過時，驗證方給被驗證方所發(fā)送的一段報文內(nèi)容：32BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議7EFF03C57656C636F6D6520746F204D4135323030412E7E此時所回應(yīng)的報文的代碼域為03，且報文的實際內(nèi)容是，WeltoMA5200A。33BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議NCPNCP協(xié)議主要包括IPCPIPXCPIPCPIPXCP或其它的一些網(wǎng)絡(luò)控制協(xié)議有興趣，則可參見RFC1552。34BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議IPCP控制協(xié)議主要是負責(zé)完成IP網(wǎng)絡(luò)層協(xié)議通信所需配置參數(shù)的選項協(xié)商的。IPCP在運行的過程當中，主要是完成點對點通信設(shè)備的兩端動態(tài)的協(xié)商IP地址。我們依據(jù)兩端設(shè)備的配置選項可將IPCP的協(xié)商過程分為"靜態(tài)"和"動態(tài)"。何為靜態(tài)，何為動態(tài)，這是一個相對的概念，可能不太準確，只作為參考使用。我們在下面會具體描述這兩個過程。IPCP的數(shù)據(jù)的文同LCP的數(shù)據(jù)報文非常類似，只不過NCP是在網(wǎng)絡(luò)層協(xié)議階段協(xié)商配置參數(shù)選項，而LCP處，我們知道LCP共包括十幾種報文，而IPCP也包括多種報文，但它的報文類型只是LCP數(shù)據(jù)LCP代碼域從1到7涉及以下幾種：Config-Request、Config-Ack、Config-Nak和Config-Reject（代碼域從1到4，而鏈路終止報文一般而言是不在網(wǎng)絡(luò)協(xié)議階段使用的，而且也是不需要的）。以下就具體介紹一下IPCPIP地址的獲取過程。靜態(tài)協(xié)商，也即是不協(xié)商。點對點的通信設(shè)備兩端在PPP協(xié)商之前已配置好了IP地址，所以就

無須在網(wǎng)絡(luò)層協(xié)議階段協(xié)商IP地址，而雙方唯一要做的就是告訴對方自身的IP地址。在IPCP

LCP配置參數(shù)選項協(xié)商過程一樣，

的協(xié)商過程中可能還會看到其它的一些報文。IPCP的Config-Request會附帶其它配置參數(shù)選項，這些配置參數(shù)選項的協(xié)商與LCP階段的一樣，而我這里只提到了IP

地址配置參數(shù)選項），無論是發(fā)送方還是接收方都同時發(fā)送Config-Request報文，其中配置選

項中只含有各自的IPConfig-Ack訴對端我已經(jīng)知道了你的IP地址，對路由器而言會增加一條到對端接口的主機路由。剛進入網(wǎng)

絡(luò)層協(xié)議階段時，IPCP的狀態(tài)機是initial的，但當完成了上述的整個過程后，IPCP的狀態(tài)機

改變?yōu)镺pened，雙方也就可以開始網(wǎng)絡(luò)層數(shù)據(jù)網(wǎng)的傳送了。當一端接收到Config-RequestIP不與本端的IP地址進行比較。我們也知道，一般而言點對點的兩端應(yīng)該是在一個網(wǎng)段。但如果IPCPConfig-Ack條件的回送。因此說點對點通信的兩端如果是手動設(shè)置每一端的IP地址時，無須雙方地址在同一網(wǎng)段。例8IPCP在網(wǎng)絡(luò)層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商IP地址的配置參數(shù)選

項地的過程），發(fā)送方設(shè)置IP地址為192.168.0.1，接收方設(shè)置IP地址為192.168.0.2，發(fā)送35BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議方發(fā)送給Config-Request報文內(nèi)容如下：7EFF00A0306C0A800017E在這個例子中我們能看見明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021，下劃線的部分表示本端的IP地址。當對端正確接收到了該報文后，應(yīng)該回應(yīng)一個Config-Ack報文，報文內(nèi)容如下：7EFF00A0306C0A800017E同樣的接收方給發(fā)送方也發(fā)送一個Config-RequestIP地址配置參數(shù)選項的值為本端的IP地址（192.168.0.2）：7EFF00A0306C0A800027E發(fā)送方回應(yīng)一個Config-Ack報文給接收方，報文內(nèi)容如下：7EFF00A0306C0A800027E36BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議IPIP端分配IP地址，這個過程實際上可與窄帶撥號上網(wǎng)的過程相一致，如果我們想用計算機上網(wǎng)，均會安裝一個撥號適配器，而且計算機中的撥號網(wǎng)絡(luò)適配器是采用動態(tài)獲取IP地址的方式，也就是在IPCP的Config-Request報文中只攜帶IP地址的配置參數(shù)選項。方法和LCP配置參數(shù)選項的處理方法一致）。圖我們可以看出發(fā)送方連續(xù)發(fā)送了兩次Config-Request報文，才能完成發(fā)送方的協(xié)商過程。而接收方仍然只需要發(fā)送一次Config-Request即可完成本端的協(xié)商過程。由于發(fā)送方?jīng)]有配置IPIPIPCP的Config-Request報文的IP地址配置參數(shù)配置選項中的IP地址填充全0（也即是0.0.0.0），這樣當對端收到這個Config-RequestIP全0IPConfig-Nak望分配給對方的IP地址填充到Config-Nak報文內(nèi)。這時當接收方收到Config-Nak報文后，就會重新發(fā)送一個Config-RequestIP地址配置選項為對方在Nak報文中所提供的。接收方IPConfig-Request送方的Config-Ack報文，就表示接收方的IP地址配置完成。例9IPCP在網(wǎng)絡(luò)層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商IP地址的配置參數(shù)選

IP地址，而接收方配置了IP地址為192.168.0.2，接收方可給

發(fā)送方分配IP地址（192.168.0.1），發(fā)送方發(fā)送給接收方的Config-Request報文內(nèi)容如下：

7EFF00A07E有下劃線的部分表示本端的IP地址。當對端正確接收到了該報文后，應(yīng)該回應(yīng)一個Config-Nak報文，報文內(nèi)容如下：7EFF00A0306C0A800017E當接收方收到該報文后，重新發(fā)送一個Config-Request報文，報文內(nèi)容如下：7EFF00A0306C0A800017E接收方再次收到發(fā)送方的一個Config-Request報文，此時將回應(yīng)一個Config-Ack報文，報文內(nèi)容如下：7EFF00A0306C0A800017E請仔細觀察一下這些報文在交互過程中，PPP數(shù)據(jù)幀凈載荷內(nèi)的數(shù)據(jù)報文的類型域和報文ID。同樣的接收方給發(fā)送方也發(fā)送一個Config-Request報文，報文內(nèi)容如下：37BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議7EFF00A0306C0A800027E發(fā)送方應(yīng)回送一個Config-Ack給接收方，報文內(nèi)容如下：7EFF00A0306C0A800027E38BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議39BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議40BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第2章PPP協(xié)議41BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議第3章PPPOE協(xié)議42BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議隨著寬帶網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，以xDSL、CableModem和以太網(wǎng)為主的幾種主流寬帶接入技術(shù)的應(yīng)用已開展的如火如荼。同時又給各大網(wǎng)絡(luò)運營商們帶來了種種困惑，無論使用哪種接入技術(shù)，戶計費的概念，要么用戶能設(shè)置/獲取IP地址上網(wǎng)，要么用戶就無法上網(wǎng)。IETF的工程師們在NAS設(shè)備終結(jié)用戶的PPP送PPPPointToPointProtocolOverEthernetBASPPPOE協(xié)議數(shù)據(jù)報文的終結(jié)，而且還能支持其它許多協(xié)議。如華為公司的MA5200IP接入設(shè)備和ISN8850智能多業(yè)務(wù)交換機。PPPOE所有用戶的主機都需要能獨立的初始化自已的PPPPPP協(xié)議本身所具有的一些的會話。43BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PPPOE協(xié)議共包括兩個階段，即PPPOE的發(fā)現(xiàn)階段（PPPOEDiscoveryStage）和PPPOE的會話階段（PPPOESessionStage）。這里我們更注重PPPOE發(fā)現(xiàn)階段的介紹，因為PPPOE的會話階段和PPPPPP的數(shù)據(jù)報文前封裝了PPPOE的夠開始一個PPPOEATMPPPOEOA集中器時，對于主機而言則會根據(jù)各訪問集中器（AC，AccessConcentration）所能提供的服務(wù)訪問集中器建立一個PPPOEPPPOE會話分配一個唯一的進程ID，會話建立起來后就開始了PPPOE的會話階段，在這個階段中已建立好點對點連PPPPPP協(xié)議來PPP的傳送。44BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議45BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PPPOE要為PPPOEID（SessionID介紹PPPOE的PPPOE大多數(shù)人來說是并不陌生，而且目前大多數(shù)的網(wǎng)絡(luò)中都在使用以太網(wǎng)2.0版，因此EthernetII考相關(guān)局域網(wǎng)技術(shù)方面的書籍。以太網(wǎng)目的地址（目的MAC地址）和以太網(wǎng)源地址（源MAC地PPPOEPPP這樣的數(shù)據(jù)鏈路層協(xié)議它在1997年以前還一直由施樂公司維護，但后來就交由IEEE802小組維護了。通過這個字段的PPPOE的PPPOE充0x8863；而在PPPOE的會話階段時，以太網(wǎng)的類型域填充為0x8864。數(shù)據(jù)域（凈載荷）主要PPPOE協(xié)議中所有的PPPOE數(shù)據(jù)報文就是被封裝在這個域中被傳送。校驗域，主要用來保證鏈路層數(shù)據(jù)幀傳送的正確性。46BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PPPOEPPPOE報文分成兩大PPPOEPPPOEPPPOE報文數(shù)據(jù)域中的內(nèi)容會隨著會話過程的進行而不斷改變。PPPOEPPPOE成這四步后，用戶主機與訪問集中器雙方就能獲知對方的MAC地址和唯一的會話ID號，從而進PPPOEMACPPPOE協(xié)議能更加靈活的運用，因此還加入了會話ID字段，通過這兩個條件就可完成確定雙方點對點的關(guān)系。在MACARP解析的過程的機制來獲取訪問集中器的MAC集中器如果配置了PPPOE載的是PPPOEPPPOE會話階段所必須的會話ID值。在這個階段，所有數(shù)據(jù)報文是被承載在以太網(wǎng)的數(shù)據(jù)域中的，而且以太網(wǎng)數(shù)據(jù)幀的協(xié)議域始終為0x8863。47BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PPPOE數(shù)據(jù)報文的數(shù)據(jù)區(qū)最開始的40x01。緊接在版本域后的4位是類型域，協(xié)議中同樣規(guī)定，這個域的內(nèi)容填充為0x01。代碼域占用1個字節(jié)，對于PPPOE的不同階段這個域內(nèi)的內(nèi)容也是不一樣的。會話ID點用2個字節(jié)，當訪問集中器還未分配唯一的會話ID0x0000旦主機獲取了會話IDID為2個字節(jié)，用來指示PPPOE數(shù)據(jù)報文中凈載荷的長度。數(shù)據(jù)域，有時也稱之為凈載荷域，在PPPOEPPPOE些Tag（標記）；而在PPPOE的會話階段，該域則攜帶的是PPP的報文。48BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議對于發(fā)現(xiàn)階段的PPPOE數(shù)據(jù)報文而言，它的凈載荷可能包含零個或多個Tag些標記的意義非常類似于PPP配置參數(shù)選項，它同樣也是要經(jīng)過協(xié)商的。對于PPPOE協(xié)議而言，沒有像PPP這個過程會依據(jù)不同廠商的設(shè)備有不同。從上圖中可以看出，標記的封裝格式采用的是大家所熟知的TLV結(jié)構(gòu)，也即是（類型+長度+數(shù)據(jù)）。標記的類型域為2個字節(jié)，下表列出了各種標記類型的含義：標記類型標記說明0x0000表示PPPOE報文數(shù)據(jù)域中一串標記的結(jié)束，為了保證版本的兼容性而保留，在有些報文中有應(yīng)用。0x0101服務(wù)名，主要用來表明網(wǎng)絡(luò)側(cè)所能提供給用戶的一些服務(wù)。0x0102AC的回應(yīng)的PADO報文時，就可獲從所攜帶的標記中獲知訪問集中器的名子，而且還可以據(jù)此來選擇相應(yīng)的訪問集中器。0x0103主機唯一標識，類似于PPP數(shù)據(jù)報文中的標識域，主要是用來匹配發(fā)送和接收端的，因為對于廣播式的網(wǎng)絡(luò)中會同時存在很多個PPPOE的數(shù)據(jù)報文。0x0104AC-Cookies，主要被用來防止惡意性DOS功擊。0x0105銷售商的標識符。0x0110中繼會話IDPPPOE的數(shù)據(jù)報文也同樣可以像DHCP報文一樣被中斷到另外的AC個連接的。0x0201服務(wù)名錯誤，當請求的服務(wù)名不被對端所接受時，會在響應(yīng)的報文中攜帶這個標記。0x0202訪問集中器名出錯。0x0203一般性錯誤。標記的長度域為2個字節(jié)，它用來指明標記數(shù)據(jù)域的長度。標記的數(shù)據(jù)域中用來放置不同類型標記所對應(yīng)的相關(guān)數(shù)據(jù)。49BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議上圖中每一行后面的數(shù)字為該報文的代碼值。50BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PADI（PPPOEActiveDiscoveryInitiationPPPOE址域應(yīng)填充為全1MAC到，后面會講到對于接收到PADI報文的訪問集中器會使用PADO報文來回應(yīng)用戶主機。我們來看一下PADI0x01為兩個域各占4位，所以合并為1個字節(jié)后應(yīng)為0x11。PADI報文的代碼域填充0x09，會話ID填充0x0000。PADI報文必須含一個由用戶側(cè)請求的正確服務(wù)名標記，當然還可能攜帶一些其它PADIPPPOE1484間給中繼代理增加一個中繼的會話ID標記。例如：PADI數(shù)據(jù)報文FFFFFFFFFFFF0010A497C1DC服務(wù)。51BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PADO（PPPOEActiveDiscoveryOffer）是PPPOE發(fā)現(xiàn)階段的第二步，也即是由訪問集中器回應(yīng)各用戶主機發(fā)送的PADIMAC地址，而目的地址則填充從PADI中所獲取的用戶主機的MAC地址。我們來看一下PADO報文幾個域的填充情況，版本域和類型域不變固定填充0x01，代碼域填充0x07ID填充0x0000PADOPADI報文中服務(wù)名標記的確認標記和對其它標記的一些確認標記。這個過程有點類似于PPP協(xié)議中鏈路建立過程中的Config-Ack報文，當然如果用戶主機所申請的服務(wù)訪問集中器不支持的話，則訪問集中器就不會回應(yīng)PADO報文。例如：PADO數(shù)據(jù)報文0010A497C1D900B0D0BCABA64D44353530這個報文中包括4個標記，在PADI所提供的標記的基礎(chǔ)上又增加了兩個標記，一個是訪問集中器名，下劃線部分即表示訪問集中器名（MD5500），而且還包含一個標記結(jié)束標記。52BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PADR（PPPOEActiveDiscoveryRequest）是PPPOE發(fā)現(xiàn)階段的第三步，也即是由用戶主機向訪問服務(wù)器發(fā)送單播的請求報文。當用戶主機收到PADO報文后，會從這些報文中挑選一個訪問集中器作為后續(xù)會話的對象。由于用戶主機在收到PADO報文后，就獲知了訪問集中器的MAC地址，因此PADR報文所以應(yīng)的以太網(wǎng)幀的源地址填充用戶主機的MAC地址，而以太網(wǎng)的目的地址填充為訪問集中器的MAC地址。我們來看一下PADR報文幾個域的填充情況，版本域和類型域不變固定填充0x01，代碼域填充0x19，會話ID域填充0x0000。此時PADR報文必須準確地包含一個服務(wù)名的標記，指示用戶主機申請的服務(wù)和其它的標記類型。例如：PADR數(shù)據(jù)報文00B0D0BCAB750010A497C1DC當收到訪問集中器的PADO報文后，用戶主機會發(fā)送PADR報文，該報文所含的標記域與PADI報文中的一致，但些時用戶主機已獲知了訪問集中器名。53BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PADS（PPPOEActiveDiscoverySession-confirmationPPPOE一步，此時訪問集中器當收到PADR報文時，就準備進入開始一個PPP的會話了，而此時訪問集中器會為在這個會話分配一個唯一的會話進程IDPADS報文中攜帶上這個會話IDPADS其中攜帶一個服務(wù)名錯誤的標記，而且此時該PADS報文中的會話ID填充0x0000。我們來看一下PADS報文幾個域的填充情況，版本域和類型域不變固定填充0x01，代碼域填充0x65，會話ID必須設(shè)為給這個PPPOE進程所分配的唯一值。例4：PADS數(shù)據(jù)報文0010A497C1D900B0D0BCAB16B其中下劃線部分為訪問集中器給這個PPPOE會話分配的唯一會話ID。54BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議PADT（PPPOEActiveDiscoveryTerminate）報文可能在會話進行開始之后的任意時間內(nèi)被發(fā)送，主要是用來終止一個PPPOE以太網(wǎng)的MAC地址我們來看一下PADT報文幾個域的填充情況，版本域和類型域不變固定填充0x01，代碼域填充0xA7IDPADT允許再使用當前這個進程發(fā)送PPP數(shù)據(jù)流量。在收到或發(fā)送PADT后甚至正常的PPP終止報文也不能被發(fā)送。例如：PADT數(shù)據(jù)報文00B0D0BCAB750010A497C1DA7016B0000這個報文中不含有任何標記，而且下劃線部分為所需終止的會話進行ID。55BA000003PPP協(xié)議和PPP0E協(xié)議ISSUE1.0第3章PPPOE協(xié)議一旦PPPOEPPP的數(shù)據(jù)報文就會被填充在PPPOE者所發(fā)送的所有以太網(wǎng)包均是單目地址。PPPOE會話階段以太網(wǎng)幀的協(xié)議域填充為0x8864域填充0x00，整個