PPP協(xié)議技術與標準培訓教材

資料編碼產(chǎn)品名稱使用對象用服工程師產(chǎn)品版本編寫部n交換接入產(chǎn)品技術支援管理部資料版本ppp專題擬制:周ー帆日期:2002-01-05審核:日期:審核:日期:批準：日期:華為技術有限公司版權所有侵權必究

修訂記錄日期修訂版本描述作者2002/01/05vl.0周ー帆錄(TOCHeading)第1章概述（標題1） 錯誤!未定義書簽。移動智能網(wǎng)的概念和特點（標題2）錯誤!未定義書簽。.!移動智能網(wǎng)概念（標題3）.錯誤!未定義書簽。.2移動智能網(wǎng)特點（標題3）.錯誤!未定義書簽。移動智能網(wǎng)的體系結構（標題2）錯誤!未定義書簽。業(yè)務交換點（SSP）（標題3）錯誤!未定義書簽。業(yè)務控制點（SCP）（標題3）錯誤!未定義書簽。第2章移動智能網(wǎng)的概念模型（標題1）錯誤!未定義書簽。概述（標題2） 錯誤!未定義書簽。業(yè)務平面（標題2） 錯誤!未定義書簽。2.1業(yè)務及業(yè)務特征（標題3）.錯誤!未定義書簽。第3章本模板新增兩個樣式 錯誤!未定義書簽。1命令行關鍵字commandkeywords.錯誤!未定義書簽。2命令行參數(shù)commandparameter..錯誤!未定義書簽。3樣例如下 錯誤!未定義書簽。第4章TerminalDisplay樣式 錯誤!未定義書簽。關鍵詞:摘要:縮略語清單:參考資料清單:第1章概述PPP協(xié)議的基本概念PPP協(xié)議出現(xiàn)的背景在提及PPP協(xié)議時,不可不提及它的老祖宗SLIP(SerialLineInternetProtocol)協(xié)議。雖然它已被淡忘在歷史的長河中,但畢竟有過輝煌的日子。它曾經(jīng)主載了Internet半邊江山,人們不僅可以通過在計算機上安裝該協(xié)議實現(xiàn)瀏覽Internet的夢想,而且還可以互連許多網(wǎng)絡設備(如路由器與路由器的互連、路由器與主機的互連和主機與主機的互連)。隨著網(wǎng)絡技術的不斷日新月異,特別是計算機技術的發(fā)展,人們開始漸漸認識到使用SLIP協(xié)議已不能滿足日益增長的網(wǎng)絡需求,如何在串行點對點的鏈路上封裝IPX、AppleTalk等網(wǎng)絡層的協(xié)議呢?這就給我們網(wǎng)絡專家提出了新的挑戰(zhàn),也為PPP協(xié)議的出現(xiàn)提供了契機,PPP由于自身的諸多的優(yōu)點已成為目前被廣泛使用的數(shù)據(jù)鏈路層協(xié)議。說明如果對SLIP不感舉趣,可直接跳到L1.2節(jié)1.1.1.1SLIP協(xié)議的基本概念SLIP協(xié)議出現(xiàn)在80年代中期,并被使用在BSDUNIX主機和SUN的工作站上,因為SLIP簡單好用,所以后來被大量使用在線路速率從1200bps到19.2Kbps的專用線路和撥號線路上互連主機和路由器,到目前為止仍有問大部分UNIX主機保留對該協(xié)議的支持。在80年代末90年代初期,被廣泛用于家庭中每臺有RS232串口的計算機和調制解調器連接到Internet。SLIP是ー種在點對點的串行鏈路上封裝!P數(shù)據(jù)報的簡單協(xié)議,它并非是Internet的標準協(xié)議。1.1.1.2SLIP協(xié)議的封裝格式SLIP協(xié)議的封裝格式必需遵循以下幾條原則:?通過在被發(fā)送IP數(shù)據(jù)報的尾部增加特殊的END字符（OxCO）從而形成一個簡單的SLIP的數(shù)據(jù)幀,而后該幀會被傳送到物理層進行發(fā)送。為了防止線路噪聲被當成數(shù)據(jù)報的內容在線路上傳輸,通常發(fā)送端在被傳送數(shù)據(jù)報的開始處也傳ー個END字符。如果線路上的確存在噪聲,則該數(shù)據(jù)報起始位置的END字符將結束這份錯誤的報文,這樣當前正確的數(shù)據(jù)報文就能正確的傳送了,而前ー個含有無意義報文的數(shù)據(jù)幀會在對端的高層被丟棄。?當被傳送的IP數(shù)據(jù)報文中含有END字符時,則需要對該字符進行轉意（就是使用其它字符來表示）,可使用連續(xù)傳輸?shù)膬蓚€字節(jié)來代替它（如Oxdb和Oxdc）。如果當被轉意后的字符也包含在數(shù)據(jù)報中,則也需要對其進行同樣的操作,直至不出現(xiàn)歧義為止。下圖為SLIP數(shù)據(jù)幀的封裝格式:End Endq IP數(shù)據(jù)報文 險1B 1B圖1-1SUP數(shù)據(jù)幀格式SLIP簡單封裝方式的缺陷:從上圖可以看出SLIP幀的封裝格式非常簡單,通信雙方無需在數(shù)據(jù)報發(fā)送前協(xié)商任何配置參數(shù)選項（在PPP協(xié)議中需協(xié)商配置參數(shù)選項），所以雙方IP層通信前必需先獲知對方的IP地址,才能進行網(wǎng)絡層的通信,否則鏈路層發(fā)送的數(shù)據(jù)幀在被送到對方網(wǎng)絡層時將無法進行轉發(fā)。由于數(shù)據(jù)幀中也沒有類似于以太網(wǎng)、HDLC和PPP等數(shù)據(jù)鏈路層協(xié)議中定義的協(xié)議域字段,因此SLIP僅支持一種網(wǎng)絡層協(xié)議（IP協(xié)議）同一時刻在串行鏈路上發(fā)送。SLIP協(xié)議沒有在數(shù)據(jù)幀的尾部加上CRC校驗和,如果由于線路噪聲的干擾影響傳送數(shù)據(jù)包的內容是無法在對端的數(shù)據(jù)鏈路層中發(fā)現(xiàn)的,必須交由上層的應用軟件來處理。正是由于上面的諸多缺點,導致了SLIP很快的被后面要講的PPP協(xié)議所替代。1.1.2PPP協(xié)議簡介PPP提供了一種在點對點的鏈路上封裝多協(xié)議數(shù)據(jù)報（IP、!PX和AppleTalk）的標準方法。它不僅能支持IP地址的動態(tài)分配和管理;同步（面向位的同步數(shù)據(jù)塊的傳送）或異步（起始位+數(shù)據(jù)位+奇偶校驗位+停止位）物理層的傳輸;網(wǎng)絡層協(xié)議的復用;鏈路的配置、質量檢測和糾錯;而且還支持多種配置參數(shù)選項的協(xié)商。PPP協(xié)議主要包括三部分:LCP(LinkControlProtocol)鏈路控制協(xié)議、NCP(NetworkControlProtocol)和PPP的擴展協(xié)議(如MultilinkProtocol,詳見第五章)。隨著網(wǎng)絡技術的不斷發(fā)展,網(wǎng)絡帶寬已不在是瓶頸,所以PPP擴展協(xié)議的應用也就越來越少,因此往往人們在敘述PPP協(xié)議時經(jīng)常會忘記它的存在。而且大部分網(wǎng)絡教材上會將PPP的認證也作為PPP協(xié)議的ー個主要部分,實際上這是ー個錯誤概念的引導。PPP協(xié)議默認是不進行認證配置參數(shù)選項的協(xié)商,它只作為ー個可選的參數(shù),當點對點線路的兩端需要進行認證時オ需配置。當然在實際應用中這個過程是不可忽略的,例如我們使用計算機上網(wǎng)時,需要通過PPP協(xié)議與NAS設備互連,在整個協(xié)議的協(xié)商過程中,我們需要輸入用戶名和密碼。因此當別人說PPP協(xié)議主要包括LCP、認證和NCP協(xié)議三個部分時,你不要認為他的說法有誤,而只是不夠準確罷了。1.2總結PPP協(xié)議由于自身諸多的優(yōu)點取代了SLIP協(xié)議,從而成為目前被廣泛使用的數(shù)據(jù)鏈路層協(xié)議SLIP協(xié)議歸咎其其簡單數(shù)據(jù)包的封裝方式,使其僅能在點對點的鏈路上封裝單一的網(wǎng)絡層協(xié)議（IP協(xié)議）PPP協(xié)議包括LCP協(xié)議、NCP協(xié)議和PPP擴展協(xié)議RFC166I文檔中說明了PPP協(xié)議缺省是不進行PAP和CHAP認證1.3思考1、當SLIP協(xié)議封裝的IP數(shù)據(jù)報文中存在END字符時,發(fā)送該數(shù)據(jù)幀的網(wǎng)絡設備會對該數(shù)據(jù)報文做什么樣的處理?2、SLIP協(xié)議沒有引入CRC校驗機制,那么它是如何保證數(shù)據(jù)發(fā)送的正確性的?3、PPP協(xié)議不僅可以支持同步物理層傳輸,而且還支持異步物理層傳輸,請比較一下兩者的區(qū)別?4、PPP協(xié)議和SLIP協(xié)議的區(qū)別,可從封裝格式,IP地址分配等方面考慮?第2章PPP協(xié)議的三組件PPP協(xié)議的組件首先簡單介紹一下PPP協(xié)議的三組件:PPP協(xié)議的封裝方式、LCP協(xié)議的協(xié)商過程和NCP協(xié)議的協(xié)商過程,然后再結合具體的LCP和NCP數(shù)據(jù)報的封裝格式和兩個階段實際數(shù)據(jù)報文的交換過程,進ー步理解PPP的LCP和NCP協(xié)商階段的具體內容。PPP協(xié)議的封裝我們知道ISO參考模型共分七層,自下而上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層和應用層。通常我們會依據(jù)協(xié)議所完成的功能將它與這七層進行對照,PPP協(xié)議就屬于數(shù)據(jù)鏈路層協(xié)議。我們在提及PPP協(xié)議的報文封裝格式時,不可不先提ー下HDLC協(xié)議。HDLC也是最常用的數(shù)據(jù)鏈路層協(xié)議,它是從SDLC協(xié)議衍進過來的,許多常用的數(shù)據(jù)鏈路層協(xié)議的封裝方式都是基于HDLC的封裝格式的,同樣PPP協(xié)議也不例外,它也采用了HDLC的定界幀格式。下圖為PPP數(shù)據(jù)幀的封裝格式:FlagAddCtrl Flag讀FF03協(xié)議域 信息域，數(shù)據(jù)域Crcミ圖2-2PPP數(shù)據(jù)幀格式以下為對PPP數(shù)據(jù)幀封裝格式的一點說明:每ー個PPP數(shù)據(jù)幀均是以一個標志字節(jié)起始和結束的,該字節(jié)為0x7E。?緊接在起始標志字節(jié)后的ー個字節(jié)是地址域,該字節(jié)為OxFF。我們熟知網(wǎng)絡是分層的,且對等層之間進行相互通信,而下層為上層提供服務。當對等層進行通信時首先需獲知對方的地址,而對不同的網(wǎng)絡,在數(shù)據(jù)鏈路層則表現(xiàn)為需要知道對方的MAC地址、X.121地址、ATM地址等;在網(wǎng)絡層則表現(xiàn)為需要知道對方的IP地址、IPX地址等;而在傳輸層則需要知道對方的協(xié)議端口號。例如如果兩個以太網(wǎng)上的主機希望能夠通信的話,首先發(fā)送端需獲知對端的MAC地址。但由于PPP協(xié)議是被運用在點對點的鏈路上的特殊性,它不像廣播或多點訪問的網(wǎng)絡ー樣,因為點對點的鏈路就可以唯一標示對方,因此使用PPP協(xié)議互連的通信設備的兩端無須知道對方的數(shù)據(jù)鏈路層地址,所以該字節(jié)已無任何意義,按照協(xié)議的規(guī)定將該字節(jié)填充為全1的廣播地址。同地址域ー樣,PPP數(shù)據(jù)幀的控制域也沒有實際意義,按照協(xié)議的規(guī)定通信雙方將該字節(jié)的內容填充為0x03o就PPP協(xié)議本身而言,我們最關心的內容應該是它的協(xié)議域和信息域。協(xié)議域可用來區(qū)分PPP數(shù)據(jù)幀中信息域所承載的數(shù)據(jù)報文的內容。協(xié)議域的內容必須依據(jù)ISO3309的地址擴展機制所給出的規(guī)定。該機制規(guī)定協(xié)議域所填充的內容必須為奇數(shù),也即是要求低字節(jié)的最低位為〃1〃,高字節(jié)的最低位為〃?！āＨ绻敯l(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域字段不符合上述規(guī)定,則接收端會認為此數(shù)據(jù)幀是不可識別的,那么接收端會向發(fā)送端發(fā)送ー個Protocol-Reject報文,在該報文尾部將完整地填充被拒絕的報文。協(xié)議域的具體取值如下表所示:協(xié)議域類型說明ISO標準0x0***-0x3***信息域中承載的是網(wǎng)絡層的數(shù)據(jù)報文0x4***-0x7***信息域中承載的是與NCP無關的低整流量0x8***-Oxb***信息域中承載的是網(wǎng)絡控制協(xié)議(NCP)的數(shù)據(jù)報文

Oxc***-Oxf***信息域中承載的是鏈路控制協(xié)議（LCP）的數(shù)據(jù)報文最典型的幾種取值0xc021信息域中承載的是鏈路控制協(xié)議（LCP）的數(shù)據(jù)報文0xc023信息域中承載的是PAP協(xié)議的認證報文0xc223信息域中承載的是CHAP協(xié)議的認證報文0x8021信息域中承載的是網(wǎng)絡控制協(xié)議（NCP）的數(shù)據(jù)報文0x0021信息域中承載的是IP數(shù)據(jù)報文說明協(xié)議域類型中的?號表示可從(0-F)中任意取值?信息域缺省時最大長度不能超過1500字節(jié),其中包括填充域的內容(在圖2-1中并未表示,因為它屬于信息域的一部分)，1500字節(jié)大小等于PPP協(xié)議中配置參數(shù)選項MRU(MaximumReceiveUnit)的缺省值,在實際應用當中可根據(jù)實際需要進行信息域最大封裝長度選項的協(xié)商。信息域如果不足1500字節(jié)時可被填充,但不是必須的,如果填充則需通信雙方的兩端能辨認出有用與無用的信息方可正常通信。我們通常在通信設備的配置過程中,遇到最多的也是MTU(MaximumTransmitUnit)〇對于ー個設備而言,它網(wǎng)絡的層次均使用MTU和MRU兩個值,一般情況下設備的MRU會比MTU稍大幾個字節(jié),但這需根據(jù)各廠商的設備而定。?CRC校驗域主要是對PPP數(shù)據(jù)幀傳輸?shù)恼_性進行檢測的,當然在數(shù)據(jù)幀中引入了一些傳輸?shù)谋ＷC機制是好的,但可以反過來說,同樣我們會引入更多的開銷,這樣可能會增加應用層交互的延遲,對于這個字節(jié)的使用我們可以參考一下X.25協(xié)議和FR協(xié)議就知道了。LCP協(xié)議為了能適應復雜多變的網(wǎng)絡環(huán)境,PPP協(xié)議提供了ー種鏈路控制協(xié)議來配置和測試數(shù)據(jù)通信鏈路,它能用來協(xié)商PPP協(xié)議的ー些配置參數(shù)選項;處理不同大小的數(shù)據(jù)幀;檢測鏈路環(huán)路、ー些鏈路的錯誤;終止一條鏈路。說明詳細內容請見3.1.2節(jié)LCP協(xié)議NCP協(xié)議PPP的網(wǎng)絡控制協(xié)議根據(jù)不同的網(wǎng)絡層協(xié)議可提供一族網(wǎng)絡控制協(xié)議,常用的有提供給TCP/IP網(wǎng)絡使用的IPCP網(wǎng)絡控制協(xié)議和提供給SPX/IPX網(wǎng)絡使用的IPXCP網(wǎng)絡控制協(xié)議等,但最為常用的是IPCP協(xié)議,當點對點的兩端進行NCP參數(shù)配置協(xié)商時,主要是用來通信雙方的網(wǎng)絡層地址。詳細內容請見3.1.3節(jié)NCP協(xié)議總結?PPP協(xié)議的三組件包括PPP協(xié)議的封裝方式、LCP協(xié)議和NCP協(xié)議?PPP協(xié)議是數(shù)據(jù)鏈路層協(xié)議,它的數(shù)據(jù)幀封裝格式非常類似于HDLC.PPP協(xié)議可通過協(xié)議域來區(qū)分數(shù)據(jù)域中凈載荷的數(shù)據(jù)類型?PPP協(xié)議通過LCP協(xié)議完成數(shù)據(jù)鏈路的配置和測試?PPP協(xié)議通過NCP協(xié)議完成點對點通信設備之間網(wǎng)絡層通信所需參數(shù)的配置2.3思考1、PPP數(shù)據(jù)幀中的地址域被填充為OxFF（廣播地址）,在實際應用當中該域已沒有任何意義,請想ー下為什么使用PPP協(xié)議通信的設備不需要類似于以太網(wǎng)的數(shù)據(jù)鏈路層尋址機制?2、PPP協(xié)議數(shù)據(jù)域缺省的最大值是多少?3、當發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域不被接收方識別時,接收方將如何處理這個數(shù)據(jù)幀?4、IPCP協(xié)議的主要功能?第3章PPP鏈路的建立PPP鏈路的建立過程PPP的狀態(tài)轉移圖數(shù)據(jù)通信設備（在本文中指路由器）的兩端如果希望通過PPP協(xié)議建立點對點的通信,無論哪一端的設備都需發(fā)送しCP數(shù)據(jù)報文來配置鏈路（測試鏈路）。一旦LCP的配置參數(shù)選項協(xié)商完后,通信的雙方就會根據(jù)しCP配置請求報文中所協(xié)商的認證配置參數(shù)選項來決定鏈路兩端設備所采用的認證方式。協(xié)議缺省情況下雙方是不進行認證的,而直接進入到NCP配置參數(shù)選項的協(xié)商,直至所經(jīng)歷的幾個配置過程全部完成后,點對點的雙方就可以開始通過已建立好的鏈路進行網(wǎng)絡層數(shù)據(jù)報文的傳送了,整個鏈路就處于可用狀態(tài)。只有當任何一端收到LCP或NCP的鏈路關閉報文時（一般而言協(xié)議是不要求NCP有關閉鏈路的能力的,因此通過情況下關閉鏈路的數(shù)據(jù)報文是在しCP協(xié)商階段或應用程序會話階段發(fā)出的）;物理層無法檢測到載波或管理人員對該鏈路進行關閉操作,都會將該條鏈路斷開,從而終止PPP會話。以下為PPP協(xié)議整個鏈路過程需經(jīng)歷階段的狀態(tài)轉移圖:鏈路不可用階段 ?鏈路建立階段一?I!犠路終止階段 驗證階段I1?—網(wǎng)絡層協(xié)議階段?—圖3-1PPP的狀態(tài)轉移圖在點對點鏈路的配置、維護和終止過程中,PPP需經(jīng)歷以下幾個階段:?鏈路不可用階段,有時也稱為物理層不可用階段,PPP鏈路都需從這個階段開始和結束。當通信雙方的兩端檢測到物理線路激活（通常時檢測到鏈路上有載波信號）時,就會從當前這個階段躍遷至下ー個階段（即鏈路建立階段）。先簡單提一下鏈路建立階段,在這個階段主要是通過LCP協(xié)議進行鏈路參數(shù)的配置,LCP在此階段的狀態(tài)機也會根據(jù)不同的事件發(fā)生變化。當處于在鏈路不可用階段時,LCP的狀態(tài)機是處于initial（初始化狀態(tài)）或starting（準備啟動狀態(tài)），一旦檢測到物理線路可用,則LCP的狀態(tài)機就要發(fā)生改變。當然鏈路被斷開后也同樣會返回到這個階段,往往在實際過程中這個階段所停留的時間是很短的,僅僅是檢測到對方設備的存在。?鏈路建立階段,也是PPP協(xié)議最關鍵和最復雜的階段。該階段主要是發(fā)送ー些配置報文來配置數(shù)據(jù)鏈路,這些配置的參數(shù)不包括網(wǎng)絡層協(xié)議所需的參數(shù)。當完成數(shù)據(jù)報文的交換后,則會繼續(xù)向下ー個階段躍遷,該下ー個階段既可是驗證階段,也可是網(wǎng)絡層協(xié)議階段,下ー階段的選擇是依據(jù)鏈路兩端的設備配置的（通常是由用戶來配置,但對NAS或BAS設備的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會進行相應的動作,也即是開始發(fā)送Config-Request報文來配置數(shù)據(jù)鏈路,無論哪一端接收到了Config-Ack報文時,LCP的狀態(tài)機又要發(fā)生改變,從當前狀態(tài)改變?yōu)閛pened狀態(tài),進入Opened狀態(tài)后收到Config-Ack報文的一方則完成了當前階段,應該向下ー個階段躍遷。同理可知,另一端也是ー樣的,但須注意的一點是在鏈路配置階段雙方是鏈路配置操作過程是相互獨立的。如果在該階段收到了非しCP數(shù)據(jù)報文,則會的將這些報文丟棄。在實際配置當中在該階段可能會遇到很多情況,在LCP協(xié)議章節(jié)中會詳細介紹可能遇到的情況,但最好結合一些troubleshooting案例能更好的幫助理解。?驗證階段,多數(shù)情況下的鏈路兩端設備是需要經(jīng)過認證后オ進入到網(wǎng)絡層協(xié)議階段,缺省情況下鏈路兩端的設備是不進行認證的。在該階段支持PAP和CHAP兩種認證方式,驗證方式的選擇是依據(jù)在鏈路建立階段雙方進行協(xié)商的結果。然而,鏈路質量的檢測也會在這個階段同時發(fā)生,但協(xié)議規(guī)定不會讓鏈路質量的檢測無限制的延遲驗證過程。在這個階段僅支持鏈路控制協(xié)議、驗證協(xié)議和質量檢測數(shù)據(jù)報文,其它的數(shù)據(jù)報文都會被丟棄。如果在這個階段再次收到了Config-Request報文,則又會返回到鏈路建立階段。?網(wǎng)絡層協(xié)議階段,一旦PPP完成了前面幾個階段,每種網(wǎng)絡層協(xié)議（IP、!PX和AppleTalk）會通過各自相應的網(wǎng)絡控制協(xié)議進行配置,每個NCP協(xié)議可在任何時間打開和關閉。當ー個NCP的狀態(tài)機變成。pened狀態(tài)時,則PPP就可以開始在鏈路上承載網(wǎng)絡層的數(shù)據(jù)包報文了。如果在個階段收到了Config-Request報文,則又會返回到鏈路建立階段。?網(wǎng)絡終止階段,PPP能在任何時候終止鏈路。當載波丟失、授權失敗、鏈路質量檢測失敗和管理員人為關閉鏈路等情況均會導致鏈路終止。鏈路建立階段可能通過交換しCP的鏈路終止報文來關閉鏈路,當鏈路關閉時,鏈路層會通知網(wǎng)絡層做相應的操作,而且也會通過物理層強制關斷鏈路。對于NCP協(xié)議,它是沒有也沒有必要去關閉PPP鏈路的。3.1.2LCP協(xié)議3.1.2.1LCP數(shù)據(jù)報文的封裝方式LCP數(shù)據(jù)報文是在鏈路建立階段被交換的,它作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中,此時PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021,但在鏈路建立階段的整個過程中信息域的內容是在變化的,它包括很多種類型的報文,所以這些報文也要通過相應的字段來區(qū)分。LCP數(shù)據(jù)報文的一般封裝方式如下圖所示:代碼域標識域長度域數(shù)據(jù)域圖3-2LCP報文的封裝格式?代碼域的長度為ー個字節(jié),主要是用來標識LCP數(shù)據(jù)報文的類型的。在鏈路建立階段時,接收方收到LCP數(shù)據(jù)報文的代碼域無法識別時,就會向對端發(fā)送ー個LCP的代碼拒絕報文（Code-Reject報文）。根據(jù)RFC的規(guī)定,到目前為止LCP共包括以下幾種類型的數(shù)據(jù)報文:代碼值報文類型代碼報文類型0x01Config-Request0x07Code-Reject0x02Config-Ack0x08Protocol-Reject0x03Config-Nak0x09Echo-Request0x04Config-RejectOxOAEcho-Reply0x05Terminate-RequestOxOBDiscard-Request0x06Terminate-AckOxOCReserved?標識域也是一個字節(jié),其目的是用來匹配請求和響應報文。一般而言在進入鏈路建立階段時,通信雙方無論哪一端都會連續(xù)發(fā)送幾個配置請求報文（Config-Request報文）,而這兒個請求報文的數(shù)據(jù)域可能是完全ー樣的,而僅僅是它們的標志域不同罷了。通常一個配置請求報文的ID是從0x01開始逐步加1的,當對端接收到該配置請求報文后,無論使用何種報文（回應報文可能是Config-Ack>Config-Nak和Config-Reject

三種報文中的一種）來回應對方,但必須要求回應報文中的ID要與接收報文中的ID一致,當通信設備收到回應后就可以將該回應與發(fā)送時的進行比較來決定下ー步的操作。說明后面教材中的所有例子,均可參考以下色標的含義范例中報文色標含義如下圖所示:ppp數(shù)據(jù)幀的起始像束標志字節(jié)ppp數(shù)據(jù)幀的地址域和控制域ppp數(shù)據(jù)幀的協(xié)議域LCP數(shù)據(jù)報文的類型域LCP數(shù)據(jù)報文的配置參數(shù)選項或報文內容LCP數(shù)據(jù)報文標識域LCP數(shù)據(jù)報文的長度域圖3-3報文色標含義定義例1:假設點對點通信的一端發(fā)送了一個Config-Request報文,報文內容如下:

Config-Request報文,報文內容如下:從報文中可以看出這個配置請求報文包括5個配置參數(shù)選項。當對端正確接收到了該報文后,應該回應ー個Config-Ack從報文中可以看出這個配置請求報文包括5個配置參數(shù)選項。當對端正確接收到了該報文后,應該回應ー個Config-Ack報文,報文內容如下:該報文中唯一修改的內容就是代碼域（02表示是Config-Ack報文）,標識域與原報文中的ー樣。?長度域的內容ニ總字節(jié)數(shù)據(jù)（代碼域+標志域+長度域+數(shù)據(jù)域）。長度域所指示字節(jié)數(shù)之外的字節(jié)將被當作填充字節(jié)而忽略掉,而且該域的內容不能超過MRU的值。?數(shù)據(jù)域的內容依據(jù)不同LCP數(shù)據(jù)報文的內容也是不一樣的。說明數(shù)據(jù)域的詳細內容請見3.1.2.3節(jié)1.2.2LCP數(shù)據(jù)報文的分類在前ー小節(jié)我們可以看到,ー共包括!2種LCP數(shù)據(jù)報文,我們依據(jù)各報文的的功能又將其具體細化為以下三類:?鏈路配置報文,主要用來建立和配置一條鏈路的。?鏈路終止報文,主要用來終止一條鏈路的。?鏈路維護報文,主要用來維護和調試鏈路的。3.1.2.3LCP的鏈路配置報文圖3-4配置報文中配置選項的數(shù)據(jù)格式鏈路配置報文與其它兩類報文有著明顯的區(qū)別,它主要是用來協(xié)商鏈路的配置參數(shù)選項的,因此這種報文的數(shù)據(jù)域還要攜帶許多配置參數(shù)選項的,而另外兩類報文中部分報文的格式會稍有不同（請參見RFC1661),圖3-4表明了數(shù)據(jù)配置選項的報文格式:鏈路配置報文主要包括Config-RequestヽConfig-Ack、Config-Nak和Config-Reject四種報文。當通信雙方需要建立鏈路時,無論哪一方都需要發(fā)送Config-Request報文并攜帶每一端自己所希望協(xié)商的配置參數(shù)選項,下表為一些可選的配置參數(shù)選項:類型值參數(shù)選項類型值參數(shù)選項0x00Reserved0x05Magic-Number0x01Maximum-Recieve-Un0x06CBCP

it0x0Async-0x07Protocol-F2Controield-Compr1-Charessacter-Map0x0Authen0x08Address-an3ticatid-Control-on-ProField-Comptocolress0x0QualitOxODMultilink-4y-ProtProtocolocol這個表格內的內容并非完全,可能還有一新定議的配置選項未列在其中,如有興趣可參照相關的文檔說明。當接收方收到Config-Request報文時,會在剩下的三種類型的報文中選擇ー種來響應對方的請求報文,到底選擇哪種報文來響應對方需依據(jù)以下兩個條件:?不能完全識別配置參數(shù)選項的類型域,我們知道ー個Config-Request報文中會同時攜帶多個配置參數(shù)選項,而對于ー個支持PPP協(xié)議的通信設備也不一定會支持上表中所有列出的配置選項,即使支持,也可能在實際應用中關閉掉某些選項功能。（例如:當使用PPP協(xié)議通信的一端可能將一些無用的配置選項都關閉了,而僅支持0x01和0x03兩個配置參數(shù)選項,因此當對方發(fā)送的Config-Request報文中含有0x04配置選項時,對于本端而言這個配置參數(shù)選項就無法識別,也即是不支持這個配置參數(shù)選項的協(xié)商）。?如果能支持完全識別配置參數(shù)選項,但接收端也可能不認可Config-Request報文中配置參數(shù)選項數(shù)據(jù)域中的內容（例如:當一端發(fā)送魔術字配置參數(shù)選項中的魔術字為全〇,而對端認為應該為其它值,這種情況就屬于不支持配置參數(shù)選項中的內容）。所以依據(jù)上面的兩個條件,我們就可以明確在回應對方配置請求報文時,采用何種報文回應。?當接收Config-Request報文的一端能識別發(fā)送過來的所有配置參數(shù)選項且認可所有配置參數(shù)選項數(shù)據(jù)域的內容時,接收端將會給對端回ー個Config-Ack報文并將配置請求報文中的配置參數(shù)選項原封不動的放置在Config-Ack報文的數(shù)據(jù)域內（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項的順序）。當配置請求報文的發(fā)送端收到Config-Ack報后,則會從當前階段進入到下ー個階段。例2：假設點對點通信的一端發(fā)送了一個Config-Request報文,報文內容如下:當對端正確接收到了該報文后,應該發(fā)送ー個Config-Ack報文,報文內容如下:FF03唯一改變的內容就是代碼域（02表示是Config-Ack報文）,此例與例1完全ー樣,但兩都說明的問題有則重點。?當接收Config-Request報文的一端能識別發(fā)送端所發(fā)送過來的所有配置參數(shù)選項,但對部分配置參數(shù)選項數(shù)據(jù)域中的內容不認可時,接收端將會給對端回應ー個Config-Nak報文,該報文中

只攜帶不認可的配置參數(shù)選項,而這些配置參數(shù)選項的數(shù)據(jù)內容為本端希望的值。然而當接收端收到Config-Nak報文后,會重新發(fā)送Config-Request報文,而這個Config-Request報文與上一次所發(fā)送的Config-Request報文區(qū)別在于那些被對端不認可的配置參數(shù)選項的內容被填寫到剛剛協(xié)商完后再次發(fā)送的Config-Request報文中（Config-Nak報文發(fā)送回來的那些配置參數(shù)選項）。例3：假設點對點通信的一端發(fā)送了一個Config-Request報文,報文內容如下:該數(shù)據(jù)報文中有下劃線的配置參數(shù)選項的內容為對端不認可的。當對端正確接收到了該報文后,發(fā)現(xiàn)類型域為該數(shù)據(jù)報文中有下劃線的配置參數(shù)選項的內容為對端不認可的。當對端正確接收到了該報文后,發(fā)現(xiàn)類型域為0x02的配置參數(shù)選項可識別,但該配置參數(shù)選項數(shù)據(jù)域的內容不認可,應發(fā)送ー個Config-Nak報文且該報文中將攜帶希望的配置參數(shù)選項內容,報文內容如下:HFF03HFF03該報文中返回的值已經(jīng)被更改,且當發(fā)端收到該報文后會重新發(fā)送ー個Config-Request報文,報文內容如下:7EFF03仔細觀察是不是新的配置請求報文與老的配置請求的報文ID不一樣。?當接收Config-Request報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時,此時接收端將會向對端回ー個Config-Reject報文,該報文中的數(shù)據(jù)域只攜帶那些不能識別的配置參數(shù)選項（當配置參數(shù)選項的類型域不識別時）。該報文中返回的值已經(jīng)被更改,且當發(fā)端收到該報文后會重新發(fā)送ー個Config-Request報文,報文內容如下:7EFF03仔細觀察是不是新的配置請求報文與老的配置請求的報文ID不一樣。?當接收Config-Request報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時,此時接收端將會向對端回ー個Config-Reject報文,該報文中的數(shù)據(jù)域只攜帶那些不能識別的配置參數(shù)選項（當配置參數(shù)選項的類型域不識別時）。當對端接收到Config-Reject報文后,同樣會再次發(fā)送ー個Config-Request報文,這個配置請求報文與上一次發(fā)送的區(qū)別在于將不可識別的那些配置參數(shù)選項給刪除了。例4：假設點對點通信的一端發(fā)送了一個Config-Request報文,報文內容如下:FF03UI力下劃線所表示的配置參數(shù)選項為對端不可識別的。當對端正確接收到了該報文后,發(fā)現(xiàn)類型域為0x02的配置參數(shù)選項不識別,應該回應ー個Config-Reject報文,報文內容如下:該報文如果被原發(fā)送端接收后,又會重新發(fā)送ー個Config-Request報文,報文內容如下:FF03FF03這時我們能看到,類型域為02的配置選項在下ー次的請求報文中被刪除了。所以我們能夠看出,鏈路配置階段也可能要經(jīng)過幾次協(xié)商后才能完成,但這與點對點兩端的設備有著密切的聯(lián)系。對于PPP的兩個端點而言,兩者是獨立完成各自的配置參數(shù)選項的協(xié)商過程的。具體的配置參數(shù)選項待后續(xù)的章節(jié)中講解。3.1.2.4LCP的鏈路終止報文鏈路終止報文分為Terminate-Request和Terminate-Reply兩種報文。LCP報文中提供了一種機制來關閉一個點對點的連接,想要關斷鏈路的一端會持續(xù)發(fā)送Terminate-Request報文,直到收到ー個Terminate-Reply為止。接收端一旦收到了一Terminate-Request報文后,必須回應ー個Terminate-Reply報文,同時等待對端先將鏈路斷開后,再完成本端的所有斷開的操作。LCP的鏈路終止報文的數(shù)據(jù)域與鏈路配置報文的數(shù)據(jù)域不一樣,鏈路終止報文中無需攜帶各配置參數(shù)選項。對于鏈路終止報文也同樣需要ID一致,當接收到Terminate-Reply報文才會做鏈路終止操作。3.1.2.5LCP的鏈路維護報文除上述兩種報文類型以外,剩余的所有報文類型均歸屬鏈路維護報文。當接收端發(fā)現(xiàn)LCP報文的代碼域是ー個不合法的值時,將會向發(fā)送端回應ー個Code-Reject報文,在回應報文中會將所拒絕報文的內容附加上。例5：假設點對點通信的一端發(fā)送了一個Config-Request報文,報文內容如下:

有下劃線的部分表示這個代碼域在標準中未定義,從而無法識別。當對端正確接收到了該報文后,發(fā)現(xiàn)LCP數(shù)據(jù)報文的代碼域為OxOE時,應該發(fā)送ー個Code-Reject報文,報文內容如下:?當接收端發(fā)現(xiàn)所接收到的數(shù)據(jù)幀的協(xié)議域是ー個不合法的值時,將會向發(fā)送端回應ー個Protocol-Reject報文,發(fā)送端收到該拒絕報文后將停止發(fā)送該種協(xié)議類型的數(shù)據(jù)報文了。Protocol-Reject報文只能在LCP的狀態(tài)機處于Opened狀態(tài)時オ可被處理,而在其它狀態(tài)接收到該報文將被丟棄。在Protocol-Reject報文的數(shù)據(jù)域內將攜帶所拒絕報文的協(xié)議類型和報文內容。例6：假設點對點通信的一端發(fā)送了一個協(xié)議域未定義（無法識別）的報文,報文內容如下:FF03FF03其中下劃線部分為PPP數(shù)據(jù)幀的協(xié)議域,0x7777表示ー個未定義的類型（也即對端無法識別）。當對端正確接收到了該報文后,發(fā)現(xiàn)該報文的協(xié)議域為0x7777,該值未在RFC中未有明確定義,應該發(fā)送ー個Protocol-Reject報文,報文內容如下:?Echo-Request報文和Echo-Reply報文主要用來檢測雙向鏈路上自環(huán)的問題,除此之外還可附帶做ー些鏈路質量的測試和其它功能。當しCP狀態(tài)機處于Opened狀態(tài)時,如果接收到了Echo-Request,就需向對端回送ー個Echo-Reply報文。否則在其它LCP狀態(tài)下,該類型的報文會被丟棄。這種類型數(shù)據(jù)報文的長度域后不是直接跟數(shù)據(jù)域,而是要插入4個字節(jié)的Magic-Number（魔術字）,該魔術字是在LCP的Config-Request的配置參數(shù)選項協(xié)商時獲得的〇例7:假設點對點通信的一端接收到了一個Echo-Request報文，報文內容如下:FF03有下劃線的部分表示魔術字。當對端正確接收到了該報文后,應該發(fā)送ー個Echo-Reply報文,報文內容如下:3.1.3NCP協(xié)議NCP協(xié)議的數(shù)據(jù)報文是在網(wǎng)絡層協(xié)議階段被交換的,在這個階段所需的ー些配置參數(shù)選項協(xié)商完后,就可以進行網(wǎng)絡層的通信,也即是在點對點的鏈路上可以開始傳送網(wǎng)絡層的數(shù)據(jù)報文了。NCP協(xié)議主要包括IPCP、IPXCP等,但我們在實際當中最常遇見的也只有IPCP協(xié)議了,如果對IPXCP或其它的一些網(wǎng)絡控制協(xié)議有興趣,則可參見RFC1552。1.3.1IPCPIPCP控制協(xié)議主要是負責完成IP網(wǎng)絡層協(xié)議通信所需配置參數(shù)的選項協(xié)商的。IPCP在運行的過程當中,主要是完成點對點通信設備的兩端動態(tài)的協(xié)商IP地址。我們依據(jù)兩端設備的配置選項可將!PCP的協(xié)商過程分為〃靜態(tài)〃和〃動態(tài)〃。何為靜態(tài),何為動態(tài),這是ー個相對的概念,也是自己總結出來的,可能不太準確,只作為參考使用。我們在下面會具體描述這兩個過程。!PCP的數(shù)據(jù)的文同LCP的數(shù)據(jù)報文非常類似,只不過ー個是在網(wǎng)絡層協(xié)議階段協(xié)商配置參數(shù)選項,而LCP協(xié)議則是在鏈路建立階段協(xié)商配置參數(shù)選項的。除此之外是兩者在所使用報文上的相似之處,我們知道LCP共包括十幾種報文,而IPCP也包括多種報文,但它的報文類型只是LCP數(shù)據(jù)報文的ー個子集（只有しCP代碼域從1到7這七種報文）,而且實際的數(shù)據(jù)報文交換過程中也僅涉及以下兒種:Config-Request>Config-Ack>Config-Nak和Config-Reject（代碼域從1到4,而鏈路終止報文一般而言是不在網(wǎng)絡協(xié)議階段使用的,而且也是不需要的）。以下就具體介紹一下IPCP控制協(xié)議的靜態(tài)和動態(tài)的兩個過程,實際上兩者的區(qū)分是在于互連設備IP地址的獲取過程。?靜態(tài)協(xié)商,也即是不協(xié)商。點對點的通信設備兩端在PPP協(xié)商之前已配置好了IP地址,所以就無須在網(wǎng)絡層協(xié)議階段協(xié)商IP地址,而雙方唯ー要做的就是告訴對方自身的IP地址。在IPCP控制協(xié)議完成整個配置的過程時,最理想的情況將會看到如圖所示的四種報文,而無其它報文再被發(fā)送。如果當配置請求中所攜帶的網(wǎng)絡層配置參數(shù)選項類似于しCP配置參數(shù)選項協(xié)商過程一樣,可能會有對方不識別的配置參數(shù)選項或不被對方所認可的配置參數(shù)選項的內容。這樣在這個階段的協(xié)商過程中可能還會看到其它的ー些報文。在靜態(tài)協(xié)商時,如果IPCP的Config-Request報文中只含有地址配置參數(shù)選項時（實際中可能還會附帶其它配置參數(shù)選項,這些配置參數(shù)選項的協(xié)商與LCP階段的ー樣,而我這里只提到了IP地址配置參數(shù)選項）,無論是發(fā)送方還是接收方都同時發(fā)送Config-Request報文,其中配置選項中只含有各自的!P地址。當對端收到該報文后,會發(fā)送ー個Config-Ack報文,這個目的是告訴對端我已經(jīng)知道了你的IP地址,對路由器而言會增加一條到對端接口的主機路由。剛進入網(wǎng)絡層協(xié)議階段時,IPCP的狀態(tài)機是initial的,但當完成了上述的整個過程后,IPCP的狀態(tài)機改變?yōu)镺pened,雙方也就可以開始網(wǎng)絡層數(shù)據(jù)網(wǎng)的傳送了。IPCP協(xié)議中并未規(guī)定,當一端接收到Config-Request報文后,它從報文的配置參數(shù)選項中可獲知對端的IP地址,但并不與本端的IP地址進行比較.我們也知道,一般而言點對點的兩端應該是在ー個網(wǎng)段。但如果雙方的地址不在ー個網(wǎng)段,就不給對方回應Config-Ack報文,而是無條件的回送一個回應報文因此說點對點通信的兩端如果是手動設置每ー端的IP地址時,無須雙方地址在同一網(wǎng)段。例8：假設!PCP在網(wǎng)絡層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商!P地址的配置參數(shù)選項地的過程）,發(fā)送方設置!P地址為192.168.0.1,接

收方設置IP地址為192.168.0.2,發(fā)送方發(fā)送給Config-Request報文內容如下:FF03在這個例子中我們能看見明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021,下劃線的部分表示本端的IP地址。當對端正確接收到了該報文后,應該回應ー個Config-Ack報文,報文內容如下:同樣的接收方給發(fā)送方也發(fā)送ー個同樣的接收方給發(fā)送方也發(fā)送ー個Config-Request報文內容如下,但此時報文中IP地址配置參數(shù)選項的值為本端的IP地址(192.168.0.2)：.FF03.FF03發(fā)送方回應ーConfig-Ack報文給接收方,報文內容如下:

?動態(tài)協(xié)商,也即是一端配置為動態(tài)獲取IP地址,另一端通過手動方式配置IP地址,且允許給對端分配IP地址,這個過程實際上可與窄帶撥號上網(wǎng)的過程相一致,如果我們想用計算機上網(wǎng),均會安裝ー個撥號適配器,而?且計算機中的撥號網(wǎng)絡適配器是采用動態(tài)獲取IP地址的方式。這個例子與一個例子相似,也就是在IPCP的Config-Request報文中只攜帶!P地址的配置參數(shù)選項。如果是配置參數(shù)選項中含有其它配置參數(shù)選項,則可能會遇到其它的ー些情況（如不識SenderReceiver圖3-6SenderReceiver圖3-6動態(tài)協(xié)商別配置參數(shù)選項的代碼域或不認可配置參數(shù)選項的內容,但對于這些情況的處理方法和LCP配置參數(shù)選項的處理方法一致）。圖3-6中我們可以看出發(fā)送方連續(xù)發(fā)送了兩次Config-Request報文,才能完成發(fā)送方的協(xié)商過程。而接收方仍然只需要發(fā)送一次Config-Request即可完成本端的協(xié)商過程。由于發(fā)送方?jīng)]有配置IP地址（而是動態(tài)獲取IP地址）,所以在IPCP的Config-Request報文的IP地址配置參數(shù)配置選項中的IP地址填充全。（也即是。.〇?〇.〇）,這樣當對端收到這個Config-Request報文時,當接收方收到該配置請求報文后會迅檢測!P地址的內容,如果發(fā)送為全0,則認為對端的這個IP地址不是我所希望的值,這樣就回應ー個Config-Nak報文,并將希望分配給對方的IP地址填充到Config-Nak報文內。這時當接收方收到Config-Nak報文后,就會重新發(fā)送ー個Config-Request報文,這個報文中的IP地址配置選項為對方在Nak報文中所提供的。Sender圖Sender圖3-6動態(tài)協(xié)商接收方!P地址的配置過程與靜態(tài)時的ー樣,只需發(fā)送ー個Config-Request報文即可,當收到發(fā)送方的Config-Ack報文,就表示接收方的IP地址配置完成。例9：假設!PCP在網(wǎng)絡層協(xié)議階段開始協(xié)商配置參數(shù)選項(這里只舉協(xié)商!P地址的配置參數(shù)選項地的過程),發(fā)送方?jīng)]有配置IP地址,而接收方配置了!P地址為192.168.0.2,接收方可給發(fā)送方分配IP地址(192.168.0.1),發(fā)送方發(fā)送給接收方的Config-Request報文內容如下:有下劃線的部分表示本端的ip地址。當對端正確接收到了該報文后,應該回應ー個Config-Nak報文,報文內容如下:.師03當接收方收到該報文后,重新發(fā)送ー個Config-Request報文,報文內容如下:IffIff03接收方再次收到發(fā)送方的ー個Config-Request報文,此時將回應ー個Config-Ack報文,報文內容如下:7E7EFF03請仔細觀察一下這些報文在交互過程中,PPP數(shù)據(jù)幀凈載荷內的數(shù)據(jù)報文的類型域和報文IDo同樣的接收方給發(fā)送方也發(fā)送ー個Config-Request報文,報文內容如下:發(fā)送方應回送一個Config-Ack給接收方,報文內容如下:FF03FF03本章節(jié)的ー些內容可能沒有明確寫出,只是將IPCP配置參數(shù)選項配置過程中最關鍵的部分做了一些說明,如果想深入了解決IPCP或IPXCP,可參見相關的RFC文檔。3.2總結PPP協(xié)議的狀態(tài)轉移圖包括鏈路不可用階段、鏈路建立階段、認證階段、網(wǎng)絡層協(xié)議階段和鏈路終止階段LCP協(xié)議依據(jù)報文的功能可分為鏈路配置報文、鏈路終止報文和鏈路維護報文LCP協(xié)議的鏈路配置報文主要是用來協(xié)商ー些可選的配置參數(shù)選項LCP協(xié)議的鏈路終止報文主要是用來終止一條PPP鏈路LCP協(xié)議的鏈路維護報文主要是用來測試和調試PPP鏈路NCP協(xié)議主要負責網(wǎng)絡層配置參數(shù)選項的協(xié)商,它包括〃靜態(tài)協(xié)商〃和〃動態(tài)協(xié)商〃3.3思考1、當發(fā)送端在鏈路建立階段開始時,發(fā)送ー個Config-Request報文,那么當接收端接收到該數(shù)據(jù)報文后,什么情況下回應Config-Ack報文,什么情況下回應Config-Nak報文,而什么情況下又回應Config-Reject報文?2、按功能分,Echo-Request報文和Echo-Reply報文屬于LCP協(xié)議哪種類型報文,在這種報文中需要攜帶鏈路配置報文中協(xié)商何種配置參數(shù)選項?3、IPCP協(xié)議在進行網(wǎng)絡層配置參數(shù)選項協(xié)商時可能會遇到哪兩種協(xié)商,當只協(xié)商!P地址選項時,請對比ー下這兩種配置參數(shù)選項的區(qū)別?當需要進行多種參數(shù)配置參數(shù)選項時（請回憶一下LCP配置參數(shù)選項協(xié)商的情況）,可能會出現(xiàn)哪幾種情況 ?第4章LCP的可選配置參數(shù)LCP的參數(shù)配置選項LCP協(xié)議在對鏈路配置過程中需要進行一些可選配置參數(shù)選項的協(xié)商,我們在前面講述的過程中已列舉了許多配置參數(shù)選項,但我們只挑選其中較為重要的幾個參數(shù)做相應的擴展說明（魔術字和認證協(xié)議選項）。關于ー些更具體的細節(jié)和未涉及到的配置參數(shù)選項,請參數(shù)PPP的RFC文檔（RFC1661）。魔術字（Magic-Number）魔術字是在LCP的Config-Request報文中被協(xié)商的,并且可被其它ー些其它類型的LCP數(shù)據(jù)報文所使用,如前面已經(jīng)說過的Echo-RequestヽEcho-Reply報文和Quality-Protoco!報文等。對于PPP協(xié)議本身它是不要求協(xié)商魔術字的,如果在雙方不協(xié)商魔術字的情況下,某些LCP的數(shù)據(jù)報文需要使用魔術字時,那么只能是將魔術字的內容填充為全0:反之,則填充為配置參數(shù)選項協(xié)商后的結果。魔術字在目前所有的設備當中都是需要進行協(xié)商的,它被放在Config-Request的配置選項參數(shù)中進行發(fā)送,而且需要由自身的通信設備獨立產(chǎn)生,協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術字,從而導致通信出現(xiàn)不必要的麻煩,因此要求由設備采用ー些隨機方法產(chǎn)生一個獨一無二的魔術字。一般來說魔術字的選擇會采用設備的系列號、網(wǎng)絡硬件地址或時鐘。雙方產(chǎn)生相同魔術字的可能性不能說是沒有的,但應盡量避免,通常這種情況是發(fā)產(chǎn)在相同廠商的設備進行互連時,因為一個廠商所生產(chǎn)的設備產(chǎn)生魔術字的方法是ー樣的。我們知道魔術字產(chǎn)生的作用是用來幫助檢測鏈路是否存在環(huán)路,當接收端收到ー個Config-Request報文時,會將此報文與上一次所接收到的Config-Request進行比較,如果兩個報文中所含的魔術字不一致的話,表明鏈路不存在環(huán)路。但如果一致的話,接收端認為鏈路可能存在環(huán)路,但不ー定存在環(huán)路,還需進ー步確認。此時接收端將發(fā)送ー個Config-Nak報文,并在該報文中攜帶ー個重新產(chǎn)生的魔術字,而且此時在未接收到任何Config-Request或Config-Nak報文之前,接收端也不會發(fā)送任何的Config-Request報文。這時我們假設可能會有以下兩種情況發(fā)生:?鏈路實際不存在環(huán)路,而是由于對方在產(chǎn)生魔術字時與接收端產(chǎn)生的一致,但實際這種情況出現(xiàn)的概率是很小的。當Config-Nak被對端接收到后,應該發(fā)送ー個Config-Request報文（此報文中的魔術字為Nak報文中的）,當對端接收到后,與上次比較,由于接收端已經(jīng)在Nak報文中產(chǎn)生了一個不同的魔術字,此時接收端收到的Config-Request報文中的魔術字與上次配置請求報文中不一樣,所以接收端可斷定鏈路不存在環(huán)路。?鏈路實際上確實存在環(huán)路,一段時間后Config-Nak報文會返回到發(fā)送該報文的同一端。這時接收端比較這個Config-Nak報文與上一次發(fā)出去的ー樣,因此鏈路存在環(huán)路的可能性又增大了。我們知道當一端收到了一Config-Nak報文時,又會發(fā)送ーVConfig-Request報文（該報文中的魔術字與Config-Nak中的一致）,這樣又回到了最初的狀態(tài),在這條鏈路上就會不斷的出現(xiàn)Config-Request>Config-Nak報文,因此這樣周而復始下去,接收端就會認為PPP鏈路存在環(huán)路的可能性在不斷增加,當達到ー定數(shù)量級時,就可認為此鏈路存在環(huán)路。但在實際應用中根據(jù)不同設備實現(xiàn)PPP協(xié)議的方法,我們在鏈路環(huán)路檢測時可采用兩種方法。第ー種機制就是如上面所述的,這個過程不斷地重復,最終可能會給LCP狀態(tài)機發(fā)ー個Down事件,這時可能會使しCP的狀態(tài)機又回到初始化階段,又開始新一輪的協(xié)商。當然對于某些設備還會采用第二種機制,就是不產(chǎn)生任何事件去影響當前LCP的狀態(tài)機,而是停留在請求發(fā)送狀態(tài)。但這時認為鏈路有環(huán)路的一端設備需要不斷的向鏈路上發(fā)送Echo-Request報文來檢測鏈路環(huán)路是否被解除,當接收端收到Echo-Reply報文時,就認為鏈路環(huán)路被解除,從而就可能進行后續(xù)的PPP的過程。認證協(xié)議PPP協(xié)議也提供了可選的認證配置參數(shù)選項,缺省情況下點對點通信的兩端是不進行認證的。在eCP的Config-Request報文中不可一次攜帶多種認證配置選項,必須二者擇其ー(PAP/CHAP),選擇最希望的那ー種,一般是在PPP設備互連的設備上進行配置的,但一般設備會默認支持ー個缺省的認證方式(PAP是大部分設備所默認的認證方式)。當對端收到該配置請求報文后,如果支持配置參數(shù)選項中的認證方式,則回應ー個Config-Ack報文;否則回應ー個Config-Nak報文,并附帶上自希望雙方采用的認證方式。當對方接收到Config-Ack報文后就可以開始進行認證了,而如果收到得是Config-Nak報文,則根據(jù)自身是否支持Config-Nak報文中的認證方式來回應對方,如果支持則回應ー個新的Config-Request(并攜帶上Config-Nak報文中所希望使用的認證協(xié)議),否則將回應ー個Config-Reject報文,那么雙方就無法通過認證,從而不可能建立起PPP鏈路。PPP支持兩種授權協(xié)議:PAP(PasswordAuthenticationProtocol)和CHAP(ChallengeHandAuthenticationProtocol)〇4.1.2.1PAP認證我們所知兩個設備在使用PAP進行認證之前,應該確認那一方是驗證方,那一方是被驗證方。實際上對于使用PPP協(xié)議互連的兩端來說,既可作為認證方,也可作為被認證方。但通常情況下,PAP只使用一個方向上的認證。一般在兩端設備使用PAP協(xié)議之前,均會設備上進行一些相應的配置,對于寬帶工程師而言MA5200可謂是大家最熟悉的產(chǎn)品了,它默認就作為驗證方,但可通過使用命令PAPAuthenticationPAP/CHAP來更改認證方式,而對于被驗證方而言只需設置用戶名和密碼即可。PAP認證是兩次握手,在鏈路建立階段,依據(jù)設備上的配置情況,如果是使用PAP認證,則驗證方在發(fā)送Config-Request報文時會攜帶認證配置參數(shù)選項,而對于被驗證方而言則是不需要,它只需要收到該配置請求報文后根據(jù)自身的情況給對端返回相應的報文。如果點對點的兩端設備采用的是PAP雙向認證時,也即是它同時也作為驗證方,則此時需要在配置請求報文中攜帶認證配置參數(shù)選項。因此,我們可以總結一下,如果對于點對點的兩個設備在PPP鏈路建立的過程中使用的認證方式為PAP的話,那么驗證方在其Config-Request報文中必須含有認證配置參數(shù)選項,且該認證配置參數(shù)選項的數(shù)據(jù)域為0xC023,下圖為PAP認證的過程:用戶名ノ密碼被瞼證方 >驗證方RouterA ppp封裝 RouterB< 圖4-1PAPiA證過程當通信設備的兩端在收到對方返回的Config-Ack報文時,就從各自的鏈路建立階段進入到認證階段,那么作為被驗證方此時需要向驗證方發(fā)送PAP認證的請求報文,該請求報文攜帶了用戶名和密碼,當驗證方收到該認證請求報文后,則會根據(jù)報文中的實際內容查找本地的數(shù)據(jù)庫,如果該數(shù)據(jù)庫中有與用戶名和密碼一致的選項時,則回向對方返回ー個認證請求響應,告訴對方認證已通過。反之,如果用戶名與密碼不符,則向對方返回驗證不通過的響應報文。如果雙方都配置為驗證方,則需要雙方的兩個單向驗證過程都完成后,方可進入到網(wǎng)絡

層協(xié)議階段,否則在一定次的認證失敗后,則會從當前狀態(tài)返回鏈路不可用狀態(tài)。例1。:如圖4-1所示,當路由器A（被驗證方）收到了路由器B的Config-Ack報文后,因為是使用PAP認證,所以作為被驗證方的路由器A應主動向驗證方（路由器B）發(fā)送認證請求報文（PAPAuthenticate）,用戶名和密碼均為!63?報文的內容如下:FF03FF03下劃線的前四個字節(jié)是用戶名,后四個字節(jié)是密碼。當路由器B收到了該報文后,會向路由器A回應一個PAPAuthenticateAck報文,報文內容如下:小?№?11此時所回應的報文中,并未攜帶任何數(shù)據(jù),如果是認證不通過,則會在返回的報文中指是因何原因無法認證通過,可能是無此用戶名或密碼不匹配。4.1.2.2CHAP認證與PAP認證比起來,CHAP認證更具有安全性,從前面認證過程的數(shù)據(jù)包交換過程中不然發(fā)現(xiàn),采用PAP認證時,被驗證是采用明文的方式直接將用戶名和密碼發(fā)送給驗證方的,而對于PAP認證則不ー樣。CHAP為三次握手協(xié)議,它只在網(wǎng)絡上傳送用戶名而不傳送口令,因此安全性比PAP高。在驗證ー開始,不像PAPー樣是由被驗證方發(fā)送認證請求報文了,而是由驗證方向被驗證方發(fā)送一段隨機的報文,并加上自己的主機名,我們通稱這個過程叫做挑戰(zhàn)。當被驗證方收到驗證方的驗證請求,從中提取出驗證方所發(fā)送過來的主機名,然后根據(jù)該主機名在被驗證方設備的后臺數(shù)據(jù)庫中去查找相同的用戶名的記錄,當查找到后就使用該用戶名所對應的密鑰,然后根據(jù)這個密鑰、報文ID和驗證方發(fā)送的隨機報文用Md5加密算法生成應答,隨后將應答和自己的主機名送回,同樣驗證方收到被驗證方發(fā)送回應后,提取被驗證方的用戶名,然后去查找本地的數(shù)據(jù)庫,當找到與被驗證方一致用戶名后,根據(jù)該用戶名所對應的密鑰、保留報文!D和隨機報文用Md5加密算法生成結果,和剛剛被驗證方所返回的應答進行比較,相同則返回Ack,否則返回Nak,下圖為CHAP的認證過程:例11:如圖4-2所示,當路由器A（被驗證方）收到了路由器B的Challenge報文后,報文內容如下:下劃線的前16個字節(jié)是驗證方隨機產(chǎn)生的一段報文,后7個字節(jié)是驗證方的主機名（MA5200A）,而且單個字節(jié)10表示隨機報文的長度。而此時路由器A會根據(jù)用戶名所對應的密鑰使用報文的ID和該報文的內容生成一個回應報文,報文內容如下:被瞼證方 主機名，應答 驗證方RouterA ppp封裝 RouterB接收，拒絕圖4-2CHAP認證過程我們將這個回應報文與驗證方發(fā)送的挑戰(zhàn)報文進行比較,報文的代碼域已由原01改為02,總報文的長度有變化,主要后而一個下劃線的內容是被驗證方的主機名(ppkiss@hua),而且此時回應的16個字節(jié)的報文已經(jīng)是經(jīng)過MD5算法加密過的。當驗證方收到了這個回應報文后,會根據(jù)報文中被驗證方的主機名(ppkiss@hua)在本地的數(shù)據(jù)庫中去查找密鑰,然后再對原發(fā)先發(fā)送的那段挑戰(zhàn)報文進行MD5的算法加密,如果所得的結果與對方剛發(fā)過來的16個字節(jié)的加密值ー樣的話,則就會發(fā)送ー個報文通知被驗證方,你的認證已經(jīng)通過,我們可以進入到下ー個階段了。在實際應用當中,我們很多都是使用PC機來進行撥號這個過程,實際中當驗證方發(fā)送挑戰(zhàn)后,PC機只接收而并不去查本地數(shù)據(jù)庫,而直接使用在撥號對話框中所輸入的密碼和報文的ID及報報文的內容進行MD5算法加密（這個在PC機采用PPPOE軟件撥入到MA5200時就是這樣的）。下面來看一下驗證通過時,驗證方給被驗證方所發(fā)送的一段報文內容:此時所回應的報文的代碼域為03,且報文的實際內容是,WelcomtoMA5200Ao4.1.3MRU（MaxiumReceiveUnit）這個配置參數(shù)選項主要是Config-Request報文的發(fā)送端告訴接收端,本端接收到的PPP數(shù)據(jù)幀的數(shù)據(jù)域的最大值。通常情況下這個參數(shù)選項使用默認值（1500字節(jié)）,因此在Config-Request報文中雙方都不會攜帶這個配置參數(shù)選項。當在某些特殊應用中,可能會使用到小于1500字節(jié)或大于1500字節(jié)的情況,這時在Config-Request報文就會攜帶要協(xié)商的MRU配置參數(shù)選項值。4.2總結魔術字可以在鏈路配置階段被協(xié)商,數(shù)據(jù)報文可借助魔術字來檢PP?鏈路是否存在環(huán)路PAP（密碼認證協(xié)議）認證是二次握手,它是直接在網(wǎng)絡上傳送明文的用戶名和密碼,因此這種協(xié)議安全性不高CHAP（挑戰(zhàn)性握手認證協(xié)議）認證是三次握手,它只在網(wǎng)絡上傳送驗證方和被驗證方的主機名,而并不傳送密碼,因此相比之處CHAP比PAP更安全PPP協(xié)議缺省的MRU是!500,而對于通信的雙方可根據(jù)實際需要對MRU進行協(xié)商4.3思考1、PPP協(xié)議可通過幾種方式來檢測PPP鏈路是否存在環(huán)路?2、請比較PAP認證和CHAP認證?第5章PPP擴展協(xié)議PPP擴展協(xié)議概述MP出現(xiàn)的背景我們知道ISDN可以在兩個系統(tǒng)之間提供2B+D和30B+D多通道捆綁能務,從而為用戶能夠提供更多可用的帶寬。諸如上述的許多鏈路捆綁功能需要軟件和硬件的協(xié)同工作,而且更多的基于硬件來實現(xiàn)的。然而我們是否考慮過僅僅通過軟件的實現(xiàn)來完成鏈路捆綁的功能,同時還考慮到很多實際鏈路的情況,對于軟件在實現(xiàn)過程中還要能對不同速率的鏈路進行捆綁。我們可以通過在發(fā)送數(shù)據(jù)之前增加ー定數(shù)據(jù)的字節(jié)頭,其中含有為重組數(shù)據(jù)而所需的ー些字段。隨著PPP的廣泛應用,MP作為PPP功能擴展協(xié)議應運而生。它可為用戶提供更大的帶寬,實現(xiàn)數(shù)據(jù)的快速轉發(fā)。同時,還可實現(xiàn)對鏈路資源進行動態(tài)分配,有效的利用寶貴的資源。但隨著網(wǎng)絡技術的發(fā)展,網(wǎng)絡的帶寬已不再是瓶頸,所以對于使用PPP擴展協(xié)議已沒有實際意義,只在本章中簡單做一下介紹,如果想進ー步了解該協(xié)議,可參考相應的RFC1717或提供的參考書目。MP(MultilinkProtocol)協(xié)議MP的協(xié)商較為特殊。MP配置參數(shù)選項的協(xié)商是在LCP協(xié)商過程中完成的,協(xié)商MP配置參數(shù)選項的目的完成以下幾個過程:?表明系統(tǒng)是否支持將多個物理鏈路捆綁成一個邏輯鏈路?系統(tǒng)在多鏈路上接收到了對端發(fā)送的數(shù)據(jù)單元后,能夠通過附加在這些數(shù)據(jù)之前的重組字段對這些分段的數(shù)據(jù)單元進行重組.邏輯鏈路為了能夠提高傳輸?shù)男?可以不使用單ーPPP物理鏈路上的最大接收單元,可以重新協(xié)商新的邏輯鏈路上使用的最大接收單元進行數(shù)據(jù)報文的發(fā)送和接收。MP協(xié)議可以用來靈活的調整點對點系統(tǒng)之間的多條獨立物理鏈路,它可為整個系統(tǒng)提供一個虛擬鏈路,虛擬鏈路的帶寬是N個鏈路的捆綁之和(N21)〇而對于被捆綁的鏈路并未做出特殊要求,可以將同步鏈路和異步鏈路進行捆綁,同樣也可將低速鏈路和高速鏈路進行捆綁。使用該協(xié)商可將多個PPP的鏈路捆綁成一條使用,而決定不同通道是否需進行多鏈路捆綁有兩個條件:只有兩個鏈路的Discriminator和驗證方式、用戶完全相符時,才能對兩個鏈路進行捆綁。這就意味著只有當驗證完成后,才能真正完成MP的協(xié)商過程。MP不會導致鏈路的拆除。如果配置了MP,兩個鏈路不符合MP條件,則會建立一條新的MP通道,這同時也表明允許MP為單鏈路。MP的捆綁是完全依照用戶進行的,只有相同用戶才能進行捆綁。如一端配置了MP,另ー端不支持或未配MP,則建立起來的鏈路為非MP鏈路?？偨Y?MP協(xié)議屬于PPP協(xié)議的擴展協(xié)議?MP協(xié)議可依據(jù)終端指示符和驗證方式對不同的物理鏈路進行捆綁5.3思考如下圖所示,設備1與設備2通過兩條物理鏈路互連（使用鏈路1和鏈路2）,而設備1與設備3也通過兩條物理鏈路互連（使用鏈路3和鏈路4）,我們知道設備鏈路的捆綁是依據(jù)終端指示符和驗證方式的組合進行的,試想一下使用這兩項的4種組合設備1在進行鏈路捆綁中會出現(xiàn)哪些情況。第6章PPP的狀態(tài)機6.1PPP擴展協(xié)議概述由于PPP的狀態(tài)機,對于我們實際使用當中沒有太大的意義,如果想進ー步深入了解PPP協(xié)議的話,請參見PPP的RFC文檔。資料編碼產(chǎn)品名稱使用對象用服工程師產(chǎn)品版本編寫部門交換接入產(chǎn)品技術支援管理部資料版本

PPP0E專題擬制周ー帆日期：2002-01-05審核:日期:審核:日期:批準：日期：華為技術有限公司

版權所有侵權必究修訂記錄日期修訂版本描述作者2002/01/05vl.0周ー帆

目錄(TOCHeading)TOC\o"1-5"\h\z第1章概述 571.1PPP0E協(xié)議的基本概念 571.1.1 PPP0E協(xié)議出現(xiàn)的背景 571.1.2 PPP0E協(xié)議簡介 582總結 601.3思考 60第2章PPP0E的發(fā)現(xiàn)階段 611PPP0E的初始化過程 612.1.1以太網(wǎng)的幀格式 612.1.2PPP0E的數(shù)據(jù)報文格式 632.1.3PPP0E發(fā)現(xiàn)階段的數(shù)據(jù)報文 652.1.3.1 PPP0E數(shù)據(jù)報文中Tag(標記)的格式672.1.3.2PADI(PPPOEActiveDiscoveryInitiation)報文 692.1.3.3PADO(PPPOEActiveDiscoveryOffer)報文712.1.3.4PADR(PPPOE ActiveDiscoveryRequest)報文 72TOC\o"1-5"\h\z2.1.3.5PADS(PPPOEActiveDiscoverySession-confirmation)報文 731.3.6PADT(PPPOE ActiveDiscoveryTerminate)報742總結 753思考 76第3章PPPOE的會話階段 771PPPOE的會話過程 772總結 783思考 78第1章概述PPP0E協(xié)議的基本概念PPP0E協(xié)議出現(xiàn)的背景隨著寬帶網(wǎng)絡技術的不斷發(fā)展,以xDSL、Cab1eModem和以太網(wǎng)為主的幾種主流寬帶接入技術的應用已開展的如火如荼。同時又給各大網(wǎng)絡運營商們帶來了種種困惑,無論使用哪種接入技術,對于他們而言可盼和可求的是如何有效的管理用戶,如何從網(wǎng)絡的投資中收取回報,因此對于各種寬帶接入技術的收費的問題就變得更加敏感。在傳統(tǒng)的以太網(wǎng)模型中,我們是不存在所謂的用戶計費的概念,要么用戶能設置/獲取IP地址上網(wǎng),要么用戶就無法上網(wǎng)。IETF的工程師們在秉承窄帶撥號上網(wǎng)的運營思路(使用NAS設備終結用戶的PPP數(shù)據(jù)包),制定出了在以太網(wǎng)上傳送PPP數(shù)據(jù)包的協(xié)議(PointToPointProtocolOverEthernet),這個協(xié)議出臺后,各網(wǎng)絡設備制造商也相繼推出自已品牌的寬帶接入服務器（BAS）,它不僅能支持PPP0E協(xié)議數(shù)據(jù)報文的終結,而且還能支持其它許多協(xié)議。如華為公司的MA5200（小BAS）和ISN8850（大BAS）〇PPPOE協(xié)議簡介PPPOE協(xié)議提供了在廣播式的網(wǎng)絡（如以太網(wǎng)）中多臺主機連接到遠端的訪問集中器（我們對目前能完成上述功能的設備為寬帶接入服務器）上的ー種標準。在這種網(wǎng)絡模型中,我們不難看出所有用戶的主機都需要能獨立的初始化自已的PPP協(xié)議棧,而且通過PPP協(xié)議本身所具有的一些特點,能實現(xiàn)在廣播式網(wǎng)絡上對用戶進行計費和管理。為了能在廣播式的網(wǎng)絡上建立、維持各主機與訪問集中器之間點對點的關系,那么就需要每個主機與訪問集中器之間能建立唯一的點到點的會話。PPPOE協(xié)議共包括兩個階段,即PPPOE的發(fā)現(xiàn)階段（PPPOEDiscoveryStage）和PPPOE的會話階段（PPPOESessionStage）〇在這篇培訓教材中更注重是PPPOE發(fā)現(xiàn)階段的介紹,因為對于PPPOE的會話階段,可以看成和PPP的會話過程是ー樣的（可直接參照PPP協(xié)議培訓教材）,而兩者的主要區(qū)別在于只是在PPP的數(shù)據(jù)報文前封裝了PPP0E的報文頭。無論是哪ー個階段的數(shù)據(jù)報文最終會被封裝成以太網(wǎng)的幀進行傳送。當一個主機希望能夠開始ー個PPP0E會話時,它首先會在廣播式的網(wǎng)絡（協(xié)議中是這樣說的,但在實際應用中,可能還要跨躍多點訪問的網(wǎng)絡,如ATM等,從而就形成了PPP0E0A的數(shù)據(jù)包）上尋找ー個訪問集中器,當然可能網(wǎng)絡上會存在多個訪問集中器時,對于主機而言則會根據(jù)各訪問集中器（AC,AccessConcentration）所能提供的服務或用戶的預先的ー些配置來進行相應的選擇。當主機選擇完了所需要的訪問集中器后,就開始和訪問集中器建立一個PPP0E會話進程。在這個過程中訪問集中器會為每ー個PPPOE會話分配ー個唯一的進程ID,會話建立起來后就開始了PPPOE的會話階段,在這個階段中已建立好點對點連接的雙方（這種點對點的結構與PPP不一樣,它是一種邏輯上的點對點關系）就采用PPP協(xié)議來交換數(shù)據(jù)報文,從而完成一系列PPP的過程,最終將在這點對點的邏輯通道上進行網(wǎng)絡層數(shù)據(jù)報的傳送?？偨Y?PPP0E協(xié)議包括PPP0E的發(fā)現(xiàn)階段和PPP0E的會話階段?大多數(shù)的BAS（寬帶接入服務器）都支持PPP0E協(xié)議1.3思考1、PPP0E的客戶端是依據(jù)什么條件來選項訪問集中器的?第2章PPPOE的發(fā)現(xiàn)階段PPPOE的初始化過程PPPOE的初始化過程是至關重要的,它不僅要在廣播式的網(wǎng)絡上確定一對一的邏輯關系,而且還要為PPPOE的會話階段準備ー些必要條件,如訪問集中器唯一分配的會話!D(SessionID)〇在介紹PPPOE的發(fā)現(xiàn)階段之前,首先讓我們重溫一下以太網(wǎng)幀的封裝格式,前面也介紹過了,所有的PPPOE的數(shù)據(jù)報文均是被封裝在以太網(wǎng)的數(shù)據(jù)域(凈載荷區(qū))中傳送的。以太網(wǎng)的幀格式以太網(wǎng)的幀格式對于大多數(shù)人來說是并不陌生,而且目前大多數(shù)的網(wǎng)絡中都在使用以太網(wǎng)2.。版,因此EthernetH就被作為ー種事實上的工業(yè)標準而廣泛使用,如果對以太網(wǎng)不太熟悉或想深入了解的讀者,可參考相關局域網(wǎng)技術方面的書籍。下圖為以太網(wǎng)的幀格式:以太網(wǎng)目的地址（目的MAC地址）和以太網(wǎng)源地址（源MAC地址）,是我們大家最為熟悉的數(shù)據(jù)鏈路層地址。它包括單播地址、多播地址和廣播地址,而對于PPPOE協(xié)議中要使用到單播地址和廣播地址。在PPP的培訓教材中也提到了,對于PPP這樣的數(shù)據(jù)鏈路層協(xié)議而言,二層地址通信雙方之間已失去了原有的意義。以太網(wǎng)的類型域也是我們最關心的一個字段,它在199?年以前還一直由施樂公司維護,但后來就交由IEEE802小組維護了。通過這個字段的內容,數(shù)據(jù)包的接收方可以識別以太網(wǎng)的數(shù)據(jù)域中承載的是什么協(xié)議的數(shù)據(jù)報文。對于PPPOE的兩大階段,也正是通過以太網(wǎng)的類型域進行區(qū)分的。在PPPOE的發(fā)現(xiàn)階段時,以太網(wǎng)的類型域填充0x8863;而在PPPOE的會話階段時,以太網(wǎng)的類型域填充為0x8864。數(shù)據(jù)域（凈載荷）主要是用來承載類型域中所指示的數(shù)據(jù)報文,在PPPOE協(xié)議中所有的PPPOE數(shù)據(jù)報文就是被封裝在這個域中被傳送。校驗域,主要用來保證鏈路層數(shù)據(jù)幀傳送的正確性。PPPOE的數(shù)據(jù)報文格式描述完了以太網(wǎng)的幀格式后,我們簡要介紹一下PPPOE的數(shù)據(jù)報文格式。PPPOE的數(shù)據(jù)報文是被封裝在以太網(wǎng)幀的數(shù)據(jù)域內的。簡單來說我們可能把PPPOE報文分成兩大塊,（雖然這樣比較籠統(tǒng),但還是比較好助于理解）,一大塊是PPPOE的數(shù)據(jù)報頭,另ー塊則是PPPOE的凈載荷（數(shù)據(jù)域）,對于PPPOE報文數(shù)據(jù)域中的內容會隨著會話過程的進行而不斷改變。下圖為PPPOE的報文的格式:01234567890123456789012345678901版本類型代碼 金話ID長度域 浄我荷圖2-2PPPOE數(shù)據(jù)報文的格式?PPPOE數(shù)據(jù)報文最開始的4位為版本域,協(xié)議中

給出了明確的