【正文】 返回到發(fā)送該報文的同一端。第一種機制就是如上面所述的，這個過程不斷地重復，最終可能會給LCP狀態(tài)機發(fā)一個Down事件，這時可能會使LCP的狀態(tài)機又回到初始化階段，又開始新一輪的協(xié)商。在LCP的ConfigRequest報文中不可一次攜帶多種認證配置選項，必須二者擇其一（PAP/CHAP）。PPP支持兩種授權協(xié)議：PAP（Password Authentication Protocol）和CHAP（Challenge Hand Authentication Protocol）。一般在兩端設備使用PAP協(xié)議之前，均會設備上進行一些相應的配置，對于MA5200IP接入設備，它默認就作為驗證方，但可通過使用命令PAP Authentication PAP/CHAP來更改認證方式，而對于被驗證方而言只需設置用戶名和密碼即可。當通信設備的兩端在收到對方返回的ConfigAck報文時，就從各自的鏈路建立階段進入到認證階段，那么作為被驗證方此時需要向驗證方發(fā)送PAP認證的請求報文，該請求報文攜帶了用戶名和密碼，當驗證方收到該認證請求報文后，則會根據(jù)報文中的實際內容查找本地的數(shù)據(jù)庫，如果該數(shù)據(jù)庫中有與用戶名和密碼一致的選項時，則回向對方返回一個認證請求響應，告訴對方認證已通過。當路由器B收到了該報文后，會向路由器A回應一個PAP Authenticate Ack報文，報文內容如下：7E FF 03 80 21 02 01 00 05 00 7E此時所回應的報文中，并未攜帶任何數(shù)據(jù)，如果是認證不通過，則會在返回的報文中指是因何原因無法認證通過，可能是無此用戶名或密碼不匹配。當被驗證方收到驗證方的驗證請求，從中提取出驗證方所發(fā)送過來的主機名，然后根據(jù)該主機名在被驗證方設備的后臺數(shù)據(jù)庫中去查找相同的用戶名的記錄，當查找到后就使用該用戶名所對應的密鑰，然后根據(jù)這個密鑰、報文ID和驗證方發(fā)送的隨機報文用Md5加密算法生成應答，隨后將應答和自己的主機名送回，同樣驗證方收到被驗證方發(fā)送回應后，提取被驗證方的用戶名，然后去查找本地的數(shù)據(jù)庫，當找到與被驗證方一致用戶名后，根據(jù)該用戶名所對應的密鑰、保留報文ID和隨機報文用Md5加密算法生成結果，和剛剛被驗證方所返回的應答進行比較，相同則返回Ack，否則返回Nak。在實際應用當中，我們很多都是使用PC機來進行撥號這個過程，實際中當驗證方發(fā)送挑戰(zhàn)后，PC機只接收而并不去查本地數(shù)據(jù)庫，而直接使用在撥號對話框中所輸入的密碼和報文的ID及報報文的內容進行MD5算法加密（這個在PC機采用PPPOE軟件撥入到MA5200時就是這樣的）。 IPCP控制協(xié)議主要是負責完成IP網(wǎng)絡層協(xié)議通信所需配置參數(shù)的選項協(xié)商的。我們在下面會具體描述這兩個過程。靜態(tài)協(xié)商，也即是不協(xié)商。這樣在這個階段的協(xié)商過程中可能還會看到其它的一些報文。當一端接收到ConfigRequest報文后，它從報文的配置參數(shù)選項中可獲知對端的IP地址，但并不與本端的IP地址進行比較。例8：假設IPCP在網(wǎng)絡層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商IP地址的配置參數(shù)選項地的過程），發(fā)送方發(fā)送給ConfigRequest報文內容如下：7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E在這個例子中我們能看見明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021，下劃線的部分表示本端的IP地址。而接收方仍然只需要發(fā)送一次ConfigRequest即可完成本端的協(xié)商過程。例9： 假設IPCP在網(wǎng)絡層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商IP地址的配置參數(shù)選項地的過程），發(fā)送方?jīng)]有配置IP地址，接收方可給發(fā)送方分配IP地址（），發(fā)送方發(fā)送給接收方的ConfigRequest報文內容如下：7E FF 03 80 21 01 01 00 0A 03 06 00 00 00 00 7E有下劃線的部分表示本端的IP地址。在傳統(tǒng)的以太網(wǎng)模型中，我們是不存在所謂的用戶計費的概念，要么用戶能設置/獲取IP地址上網(wǎng)，要么用戶就無法上網(wǎng)。在這種網(wǎng)絡模型中，我們不難看出所有用戶的主機都需要能獨立的初始化自已的PPP協(xié)議棧，而且通過PPP協(xié)議本身所具有的一些特點，能實現(xiàn)在廣播式網(wǎng)絡上對用戶進行計費和管理。無論是哪一個階段的數(shù)據(jù)報文最終會被封裝成以太網(wǎng)的幀進行傳送。PPPOE的初始化過程是至關重要的，它不僅要在廣播式的網(wǎng)絡上確定一對一的邏輯關系，而且還要為PPPOE的會話階段準備一些必要條件，如訪問集中器唯一分配的會話ID（Session ID）。它包括單播地址、多播地址和廣播地址，而對于PPPOE協(xié)議中要使用到單播地址和廣播地址。對于PPPOE的兩大階段，也正是通過以太網(wǎng)的類型域進行區(qū)分的。PPPOE的數(shù)據(jù)報文是被封裝在以太網(wǎng)幀的數(shù)據(jù)域內的。實際上雙方在互相知道了對方的MAC地址后，就已經(jīng)在廣播式的網(wǎng)絡上確定了一一的對應關系，為了保證這個連接的有效性，同時使PPPOE協(xié)議能更加靈活的運用，因此還加入了會話ID字段，通過這兩個條件就可完成確定雙方點對點的關系。如果網(wǎng)絡上存在很多這樣的訪問集中器且都收到了用戶側發(fā)送的初始化報文時，它們也都會向用戶側會送一個確認報文，如果該用戶收到這個報文后，則會依據(jù)報文中所攜帶的內容或本端的一些配置來選擇一個唯一的訪問集中器進行會話。緊接在版本域后的4位是類型域，協(xié)議中同樣規(guī)定，這個域的內容填充為0x01。數(shù)據(jù)域，有時也稱之為凈載荷域，在PPPOE的不同階段該域內的數(shù)據(jù)內容會有很大的不同。從上圖中可以看出，標記的封裝格式采用的是大家所熟知的TLV結構，也即是（類型+長度+數(shù)據(jù)）。0x0103主機唯一標識，類似于PPP數(shù)據(jù)報文中的標識域，主要是用來匹配發(fā)送和接收端的，因為對于廣播式的網(wǎng)絡中會同時存在很多個PPPOE的數(shù)據(jù)報文。0x0201服務名錯誤，當請求的服務名不被對端所接受時，會在響應的報文中攜帶這個標記。標記的數(shù)據(jù)域中用來放置不同類型標記所對應的相關數(shù)據(jù)。廣播包可能會被多個訪問集中器接收到，后面會講到對于接收到PADI報文的訪問集中器會使用PADO報文來回應用戶主機。例如：PADI 數(shù)據(jù)報文FF FF FF FF FF FF 00 10 A4 97 C1 D9 88 63 11 09 00 00 00 0C 01 03 00 04 01 00 00 00 01 01 00 00這個報文中包括兩個標記：一個是主機的只唯一標識，另一個則是服務名標記，從上面這個報文中可以看出服務名沒有具體實際的內容，說明對于用戶主機可以接受任何由訪問集中器所提供的服務。這個過程有點類似于PPP協(xié)議中鏈路建立過程中的ConfigAck報文，當然如果用戶主機所申請的服務訪問集中器不支持的話，則訪問集中器就不會回應PADO報文。由于用戶主機在收到PADO報文后，就獲知了訪問集中器的MAC地址，因此PADR報文所以應的以太網(wǎng)幀的源地址填充用戶主機的MAC地址，而以太網(wǎng)的目的地址填充為訪問集中器的MAC地址。PADS（PPPOE Active Discovery Sessionconfirmation）是PPPOE發(fā)現(xiàn)階段的第四步，也即是最后一步，此時訪問集中器當收到PADR報文時，就準備進入開始一個PPP的會話了，而此時訪問集中器會為在這個會話分配一個唯一的會話進程ID，并在發(fā)送給主機的PADS報文中攜帶上這個會話ID。PADT（PPPOE Active Discovery Terminate）報文可能在會話進行開始之后的任意時間內被發(fā)送，主要是用來終止一個PPPOE會話的止。例如：PADT 數(shù)據(jù)報文00 B0 D0 BC AB 75 00 10 A4 97 C1 D9 88 63 11 A7 01 6B 00 00 這個報文中不含有任何標記，而且下劃線部分為所需終止的會話進行ID。Netxray是一個抓包軟件，它可以捕獲達到本PC或從本PC發(fā)出去的數(shù)據(jù)包。附錄 縮略詞表AAAAuthentication Authorization Accounting 驗證、授權、計費BNCPBridging Network Control Protocol橋接網(wǎng)絡控制協(xié)議BNPBridging Network Protocol橋接網(wǎng)絡協(xié)議CHAPChallengeHandshake Authentication Protocol驗證請求握手協(xié)議CHAPChallenge Handshake Authentication Protocol挑戰(zhàn)握手驗證協(xié)議CRCCyclic Redundancy Check循環(huán)校驗碼DSAPDestination Service Access Point目的業(yè)務接入點FCSFrame Check Sequence幀檢查序列IPCPInternet Protocol Control ProtocolIP控制協(xié)議IPXInternet Protocol eXchange protocolIP交換協(xié)議IPXCPInternet Protocol eXchange Control ProtocolIP交換控制協(xié)議LCPLink Control Protocol鏈路控制協(xié)議MRUMaximum Receive Unit最大接收單元NASNetwork Access Server網(wǎng)絡接入服務器NCPNetwork Control Protocol網(wǎng)絡控制協(xié)議PADIPPPoE Active Discovery InitiationPPPoE主動發(fā)現(xiàn)初始化包PADOPPPoE Active Discovery OfferPPPoE主動發(fā)現(xiàn)響應包PADRPPPoE Active Discovery RequestPPPoE主動發(fā)現(xiàn)請求包PADSPPPoE Active Discovery SessionconfirmationPPPoE主動發(fā)現(xiàn)會話證實包PADTPPPoE Active Discovery TerminatePPPoE主動發(fā)現(xiàn)終結包PAPPassword Authentication Protocol密碼驗證協(xié)議PAPPassword Authentication Protocol口令驗證協(xié)議PPP PointToPoint Protocol點到點協(xié)議PPPoAPPP over ATM在ATM上傳輸PPP協(xié)議PPPoEPPP over Ethernet在以太上傳輸PPP協(xié)議SSAPSource Service Access Point起源業(yè)務接入點