pppoe原理協(xié)議詳解

1、PPPoE ( Point to Point Protocol over Ethernet，基于以太網(wǎng)的點對點協(xié)議)的工作流程包含發(fā)現(xiàn)(Discovery)和會話(Session)兩個階段，發(fā)現(xiàn)階段是 無狀態(tài)的，目的是獲得 PPPoE 終 端(在局端的ADSL 設(shè)備上)的以太網(wǎng) MAC 地址，并建立一個惟一的 PPPoESESSIOND。發(fā)現(xiàn)階段結(jié)束后，就進(jìn)入標(biāo)準(zhǔn)的PPP 會話階段1.發(fā)現(xiàn)階段(PPPoED PPPoE Discovery)1.1 PADI( PPPoE Active DiscoveryInitiation)主機(jī)廣播發(fā)起分組，分組的目的地址為以太網(wǎng)的廣播地址Oxfffffff，

2、CODE(代碼)字段值為 0X 09 ( PADI Code), SESSION-ID (會話 ID )字段值為 0 x0000。PADI 分組必須至 少包含一個服務(wù)名稱類型的 標(biāo)簽(Service Name Tag，字段值為 0 x0101)，向接入集中器 提出所要求提供的服務(wù)。1.2 PADO( PPPoE Active Discovery Offer )接入集中器收到在服務(wù)范圍內(nèi)的 PADI 分組，發(fā)送 PPPoE 有效發(fā)現(xiàn)提供包分組，以響應(yīng)請求。其中 COD 寄段值為 0X 07 ( PADO Code , SESSION-ID 字段值仍為 0 x0000。PADO 分組必須 包含一個

3、接入集中器名稱類型的標(biāo)簽(Access Concentrator NameTag,字段值為 0 x0102 ),以及一個或多個服務(wù)名稱類型標(biāo)簽，表明可向主機(jī)提供的服務(wù)種類。PADO 和 PADI 的Host- Uniq Tag 值相同。1.3 PADR ( PPPoE Active Discovery Request )主機(jī)在可能收到的多個 PADC 分組中選擇一個 合適的 PADC 分組，然后向所選擇的接入集中器 發(fā)送PPPoE 有效發(fā)現(xiàn) 請求分組。 其中 CODE段為 0 x19 ( PADR Code , SESSION D 字段值 仍為 0 x0000。PADF 分組必須包含一個服務(wù)名

4、稱類型標(biāo)簽，確定向接入集線器(或交換機(jī)) 請求的服務(wù)種類。當(dāng)主機(jī)在指定的時間內(nèi)沒有接收到PADO 它應(yīng)該重新發(fā)送它的 PADI 分組，并且加倍等待時間，這個過程會被重復(fù)期望的次數(shù)。1.4 PADS( PPPoE Active DiscoverySession -confirmation)接入集中器收到 PADR 分組后準(zhǔn)備開始 PPP 會話，它發(fā)送一個 PPPoE 有效發(fā)現(xiàn)會話確認(rèn) PADS 分組。其中 CODE段值為 0X 65 ( PADSCode), SESSION-ID 字段值為接入集中器所產(chǎn)生的 一個惟一的PPPoE 會話標(biāo)識號碼。PADS 分組也必須包含一個接入集中器名稱類型的標(biāo)簽

5、以 確認(rèn)向主機(jī)提供的服務(wù)。當(dāng)主機(jī)收到PADS 分組確認(rèn)后，雙方就進(jìn)入 PPP 會話階段。PADS和 PADR 的 Host-Uniq Tag 值相同。圖 1 PPPoE 旳協(xié)商流程2會話階段（PPPoES PPPoE SessionPPP 會話的建立，需要兩端的設(shè)備都發(fā)送LCP 數(shù)據(jù)包來配置和測試數(shù)據(jù)通信鏈路。用戶主機(jī)與接入集中器根據(jù)在發(fā)現(xiàn)階段所協(xié)商的PPP 會話連接參數(shù)進(jìn)行 PPP 會話。-旦 PPPoE 會話開始，PPP 數(shù)據(jù)就可以以任何其他的 PPP 封裝形式發(fā)送。所有的以太網(wǎng)幀都是 單播的。PPPoE 會話的 SESSIOND 一定不能改變，并且必須是發(fā)現(xiàn)階段分配的值。2.1 LCP

6、協(xié)商階段(LCP Link Control Protocol)LCP 的 Request 主機(jī)和 AC 都要給對方發(fā)送，LCP 協(xié)商階段完成最大傳輸單元（MTU），是否進(jìn)行認(rèn)證和采用何種認(rèn)證方式（Authentication Type ）的協(xié)商。（1）LCP 協(xié)議數(shù)據(jù)報文分類鏈路配置報文：用來建立和配置一條鏈路，主要包括 Configure-Request、Configure-Ack、Configure-Nak 和 Configure-Reject 報文鏈路維 護(hù)報文：用來管理和調(diào)試鏈路， 主要包 括 Code-Reject、Protocol -Reject Echo-Request Echo

7、-Reply 禾口 Discard-Request 報文鏈路終止報文：用來終止一條鏈路，主要包括Terminate-Request 和 Terminate-Reply 報文（2）LCP 協(xié)商過程LCP 協(xié)商的過程如下：協(xié)商雙方互相發(fā)送一個 LCP Config-Request 報文，確認(rèn)收到的UserME601.PADI2PADO3PADR4FADSConfig-Request 報文中的協(xié)商選項，根據(jù)這些選項的支持與接受情況，做出適當(dāng)?shù)幕貞?yīng)。若 兩端都回應(yīng)了 Config-ACK 則標(biāo)志 LCP 鏈路建立成功，否則會繼續(xù)發(fā)送Request 報文，直到對端回應(yīng)了 ACK 報文為止。圖 2 LCP

8、 協(xié)商的基本過程說明:（1） Config-ACK 若完全支持對端的 LCP 選項，則回應(yīng) Config-ACK 報文，報文中必須完 全攜帶對端 Request 報文中的選項。（2） Config-NAK：若支持對端的協(xié)商選項，但不認(rèn)可該項協(xié)商的內(nèi)容， 則回應(yīng) Config-NAK報文，在 Config-NAK 的選項中填上自己期望的內(nèi)容，如：對端 MRU 值為 1500,而自己期望MRU 值為 1492，則在 Config-NAK 報文中埴上自己的期望值1492。（3） Config-Reject:若不能支持對端的協(xié)商選項，則回應(yīng)Config-Reject 報文，報文中帶上不能支持的選項，如

9、Windows 撥號器會協(xié)商 CBCP（被叫回呼），而 ME60 不支持 CBCP 功能，則回將此選項拒絕掉。2.2 認(rèn)證階段（PPP Authentication : PAP/CHAP會話雙方通過 LCP 協(xié)商好的認(rèn)證方法進(jìn)行認(rèn)證，如果認(rèn)證通過了，才可以進(jìn)行下面的網(wǎng) 絡(luò)層的協(xié)商。認(rèn)證過程在鏈路協(xié)商結(jié)束后就進(jìn)行。I PAP （ Password Authentication Protocol ，口令認(rèn)證協(xié)議）認(rèn)證PAP 為兩次握手協(xié)議，它通過用戶名及口令來對用戶進(jìn)行驗證。PAP 驗證過程如下：當(dāng)兩端鏈路可相互傳輸數(shù)據(jù)時，被驗證方發(fā)送本端的用戶名及口令到驗證方，驗證方根據(jù)本端的用戶表（或Radi

10、us 服務(wù)器）查看是否有此用戶，口令是否正確。如正確則會給對端發(fā)送 Authenticate-ACK 報文，通告對端已被允許進(jìn)入下一階段協(xié)商；否則發(fā)送NAK 報文，通告對端驗證失敗。此時，并不會直接將鏈路關(guān)閉。只有當(dāng)驗證不過次數(shù)達(dá)到一定值（缺省為 10）時，才會關(guān)閉鏈路。PAP 的特點是在網(wǎng)絡(luò)上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有 可能對網(wǎng)絡(luò)安全造成極大的威脅。因此，它適用于對網(wǎng)絡(luò)安全要求相對較低的環(huán)境。ClientServerI.CPConfig-req - -Config-reqpw-ConflQ*ll k- AClientServerRadiusS3 PAP認(rèn)證流翟n

11、 CHAP （Challenge Handshake Authentication Protocol ，質(zhì)詢握手認(rèn)證協(xié)議）認(rèn)證CHAP 為三次握手協(xié)議。只在網(wǎng)絡(luò)上傳輸用戶名，并不傳輸用戶口令，因此它的安全性 要比 PAP高。CHAP 的驗證過程為：首先由驗證方（Server）向被驗證方（Client）發(fā)送一些隨機(jī)產(chǎn)生的報文，并同時將本端 的主機(jī)名附帶上一起發(fā)送給被驗證方。被驗證方接到對端對本端的驗證請求（Challe nge）時，便根據(jù)此報文中驗證方的主機(jī)名和本端的用戶表查找用戶口令字，如找到用戶表中與驗證方主機(jī)名相同的用戶，便利用報文ID、此用戶的密鑰用 Md5 算法生成應(yīng)答（Respons

12、e）,隨后將應(yīng)答和自己的主機(jī)名送回。驗證方接到此應(yīng)答后，用報文 ID、本方保留的口令字 （密鑰）和隨機(jī)報文用 Md5 算法得出結(jié)果，與被驗證方應(yīng)答比較，根據(jù)比較結(jié)果返回相應(yīng)的結(jié)果（ACKor NAK）（1）接受認(rèn)證端發(fā)送 Challe nge（2）申請認(rèn)證端發(fā)驗證請求報文（3）接受認(rèn)證端回應(yīng)認(rèn)證接受報文經(jīng)過以上三次報文交互后，CHAP 認(rèn)證完成。圉4 CHAPU證潮旱2.3 NCP 協(xié)商階段(NCP: Network Control Protocol )NCP 有很多種，女口 IPCR BCP IPv6CP,最為常用的是 IPCR In ternet Protocol Co ntrol Pro

13、tocol )PPPJAAuth-reqE- AMAuth-reqIk.AutivackAuth-ackClientServerRadiusPPPluEPMChaltenge(CHAP)Auth-reqAuth-reqAuth-ackAuth-ack協(xié)議。NCP 的主要功能是協(xié)商 PPP 報文的網(wǎng)絡(luò)層參數(shù)，如 IP 地址，DNS Server IP 地址，WINS Server IP地址等。PPPoE 用戶主要通過 IPCP 來獲取訪問網(wǎng)絡(luò)的 IP 地址或 IP 地址段。NCP 流程與 LCP 流程類似，用戶與 ME 設(shè)備之間互相發(fā)送 NCP Config-Request 報文并且 互相回應(yīng)N

14、CP Config-Ack 報文后，標(biāo)志 NCP 己協(xié)商完，用戶上線成功，可以正常訪問網(wǎng)絡(luò)了。IPCP 的協(xié)商過程是基于 PPP 狀態(tài)機(jī)進(jìn)行協(xié)商的。經(jīng)過雙方協(xié)商，通過配置請求、配置確認(rèn)、配置否認(rèn)等包文交換配置信息，最終由initial (或 closed)狀態(tài)變?yōu)?Opened 狀態(tài)。IPCP狀態(tài)變?yōu)?Opened 的條件必須是發(fā)送方和接收方都發(fā)送和接收過確認(rèn)包文。IPCP 協(xié)商過程中，協(xié)商包文可包含多個選項，即參數(shù)。各個選項的拒絕或否認(rèn)都不能 影響 IPCP 的UP, IPCP 可以無選項協(xié)商，無選項協(xié)商也同樣能夠UP。選項有 IP Address、網(wǎng)關(guān)、掩碼等，其中 IP Address

15、是最重要的一個選項，有些廠家的實現(xiàn)必須這個選項得到確認(rèn)， 大多數(shù)廠家的實現(xiàn)允許這個選項為空。NCP 的基本協(xié)商流程見下圖：Server圖 5 NCP 的基本 t 辦商流程用戶和接入設(shè)備對IP服務(wù)階段的一些要求進(jìn)行多次協(xié)商，以決定雙方都能夠接收的約女如： IP 業(yè)務(wù)階段使用的 IP 壓縮協(xié)議等。雙方的協(xié)議是通過報文中包含的Option 項進(jìn)行協(xié)商的，每一個 Option 都是一個需要協(xié)商的問題。最后雙方都需要對方答復(fù)Configure_Ack 的同意報文。2.4 會話維持(Session Keep-alive)設(shè)備主動發(fā)送 Echo Request 進(jìn)行 PPPoE 心跳?；?，若 3 次未得到服

16、務(wù)器的響應(yīng)，貝 U 設(shè)備 主動釋放地址。發(fā) LCP Echo Request 的時候，魔術(shù)字字段要和之前通信的 Configure_Request 使用的魔術(shù)字字段保持一致。有些設(shè)備或終端不支持主動發(fā)送Echo-Request 報文，只能支持回應(yīng) Echo-Reply 報文。2.5 會話結(jié)束(Sessi on Term in ati on )PPPoE 還有一個 PADT( PPPOE Active Discovery Terminate)分組，它可以在會話建立后的任何時候發(fā)送，來終止 PPPoE 會話，也就是會話釋放。它可以由主機(jī)或者接入集中器發(fā)送，ClientNCP協(xié)商階段Parmeter

17、-reqPar meter-ackParmeler-req-Parmeter-ack-目的地址填充為對端的以太網(wǎng)的MAC 地址。當(dāng)對方接收到一個 PADT ( PPPOE Active Discovery Terminate)分組，就不再允許使用這 個會話來發(fā)送 PPP 業(yè)務(wù)。PADT 分組不需要任何標(biāo)簽，其 CODE 字段值為 0 xa7( PADT Code，SESSIOND 字段值為需要終止的 PPP 會話的會話標(biāo)識號碼。在發(fā)送或接收PADT 后，即使正常的 PPP 終止分組也不必發(fā)送。PPP 對端應(yīng)該使用 PPP 協(xié)議自身來終止 PPPoE 會話，但是當(dāng) PPP 不能使用時，可以使用

18、PADT。4.Linux 中的 PPPoE 撥號守護(hù)進(jìn)程(pppd : Point-to-Point Protocol Daemon)Linux 內(nèi) 核in clude/uapi/li nu x/if_pppox.h中 定 義 了PADI_CODE,PADO_CODE,PADR_CODE,PADS_CODE,PADT_CODE和structpppoe_tag/pppoe_hdr ； PPP/PPPoE 實現(xiàn)代碼在 /drivers/net/ppp/ 目錄下，pppoe.c 中實現(xiàn) 了pppoe_connect、pppoe_xmit、pppoe_recvmsg 等接口。pppd 是一個后臺服務(wù)進(jìn)

19、程(daemon),是一個用戶空間的進(jìn)程，所以把策略性的內(nèi)容從 內(nèi)核的 PPP 協(xié)議處理模塊移到 pppd 中是很自然的事了。pppd 實現(xiàn)了所有鑒權(quán)、壓縮/解壓和加密/解密等擴(kuò)展功能的控制協(xié)議。pppd 只是一個普通的用戶進(jìn)程， 它如何擴(kuò)展 PPP 協(xié)議呢？這就是 pppd 與內(nèi)核中的 PPP 協(xié)議處理模塊之間約定了， 它們之間采用了最傳統(tǒng)的內(nèi)核空間與用戶空間之間通信方式：設(shè)備文件。設(shè)備文件名是/dev/ppp。通過 read 系統(tǒng)調(diào)用，pppd 可以讀取 PPP 協(xié)議處理模塊的數(shù) 據(jù)包，當(dāng)然，PPP 協(xié)議處理模塊只會把應(yīng)該由pppd 處理的數(shù)據(jù)包發(fā)給 pppd。通過 write 系統(tǒng)調(diào)用，

20、pppd 可以把要發(fā)送的數(shù)據(jù)包傳遞給PPP 協(xié)議處理模塊。通過 ioctrl 系統(tǒng)調(diào)用，pppd可以設(shè)置 PPP 協(xié)議的參數(shù)，可以建立/關(guān)閉連接PPP 幀格式：禎恪武與HDLL相似,不同的是PFP是面向字符rHDLC是向問位蝕FTF幀格式如T：7E EF 031FACFCS F手節(jié)I 1 I ZT152 I看對總共多了咅個宇苔,其中首尾寺節(jié)都是幀的超始和結(jié)束掾志檢,示地址,C表示控制。協(xié)議的兩個寧段,表示后面信息部分的城協(xié)儀是什么.包括:0 x0021_息宇段是1卩數(shù)據(jù)報0XC021-信息宇段星遊路揑閱觀居LCF0 x8021息字豳網(wǎng)蚯制軸NCPOXCO23言息寧段是安全性認(rèn)證FAF0XC02

21、5音息字段是LQR0XC223忌字段是安全性認(rèn)證匚HAPPPPoE 的報文就是在 PPP 的報文前面再加上 PPPOE 頭和 以太網(wǎng)的報頭，使得 PPPoE 可 以通過簡單橋接設(shè)備連入遠(yuǎn)端接入設(shè)備PPPOE 字段如下：詳細(xì)的說就是下面的內(nèi)容:其中:FTHFRTYPE :右30）越 3PPP Seition SU裝z轄昨cwOOPPP SflSiioHOxO9fv PHf Aft1- r hffiwry InitiaTifln PAD1I pa-rkr0 x07PPPOE Active Disccwry Crffer (PADOJ packet0 x15PPPOE Active Discover

22、y RequBt (PADR) packetftlthPPPOL ActjVte1DihLOiy SeMUFi-tuiilirmjtiufi iPADSj燉!：PPPOL Atlivc GiiiMvuy T#rniirule (PADT| pjckAlTAG_TYPES (用于 Discovery Stage 中的協(xié)商參數(shù)) 0 x0000 En d-Of-List 0 x0101 Service-Name0 x0102 AC-Name0 x0103 Host-U niq0 x0104 AC-Cookie0 x0105 Vendor-Specific0 x0110 Relay-Session-

23、Id00 x0201 Service-Name-Error0 x0202 AC-System-Error0 x0203 Generic -ErrorPPP 協(xié)議的 LCP 數(shù)據(jù)報文下面我們來對 PPP 協(xié)議的 LCP 數(shù)據(jù)報文內(nèi)容進(jìn)行一下分析和講解。首先我們需要從數(shù)據(jù) 幀內(nèi)容過度一下今天的內(nèi)容。對于 PPP 協(xié)議的基礎(chǔ)內(nèi)容，PPP 數(shù)據(jù)幀以及 PPP 模式我們都做了介紹。那么這里我們再 來講解一下 PPP 協(xié)議的 LCP 數(shù)據(jù)報文的內(nèi)容。通過前面的文章，我們知道，LCP 數(shù)據(jù)報文是在鏈路建立階段被交換的，它作為PPP 的凈載荷被封裝在 PPP 數(shù)據(jù)幀的信息域中。在鏈路建立階段的整個過程中信息域

24、的內(nèi)容是在變化的， 它包括很多種類型的報文， 所以這些報文 也要通過相應(yīng)的字段來區(qū)分。PPP 數(shù)據(jù)幀的協(xié)議域固定填充0 xC021。代碼域 1 + 標(biāo)識域 1 + 長度域 + 數(shù)據(jù)域代碼域的長度為一個字節(jié)， 主要是用來標(biāo)識 LCP 數(shù)據(jù)報文的類型的。在鏈路建立階段時， 接收方收到 LCP 數(shù)據(jù)報文的代碼域無法識別時，就會向?qū)Χ税l(fā)送一個LCP 的代碼拒絕報文（Code-Reject 報文）。標(biāo)識域也是一個字節(jié)， 其目的是用來匹配請求和響應(yīng)報文。 一般而言在進(jìn)入鏈路建立階 段時，通信雙方無論哪一端都會連續(xù)發(fā)送幾個配置請求報文 （Config-Request 報文），而這幾 個請求報文的數(shù)據(jù)域可能是

25、完全一樣的， 而僅僅是它們的標(biāo)識域不同罷了。 通常一個配置請 求報文的 ID 是從0 x01 開始逐步加 1 的，當(dāng)對端接收到該配置請求報文后，無論使用何種報文（回應(yīng)報文可能是 Config-Ack、Config-Nak 和 Config-Reject 三種報文中的一種）來回應(yīng)對 方，但必須要求回應(yīng)報文中的ID （標(biāo)識域）要與接收報文中的ID 一致，當(dāng)通信設(shè)備收到回應(yīng)后就可以將該回應(yīng)與發(fā)送時的進(jìn)行比較來決定下一步的操作。長度域的內(nèi)容 = 總字節(jié)數(shù)據(jù)（代碼域 +標(biāo)志域 +長度域 +數(shù)據(jù)域）。長度域所指示字節(jié)數(shù) 之外的字節(jié)將被當(dāng)作填充字節(jié)而忽略掉，而且該域的內(nèi)容不能超過MRU 的值。數(shù)據(jù)域的內(nèi)容根

26、據(jù)不同的LCP 數(shù)據(jù)報文的內(nèi)容也是不一樣的。下面說一下 LCP 包括的幾種報文類型，不同的報文在標(biāo)識域中所填充的內(nèi)容也不同。LCP 報文主要分為 1、鏈路配置報文；2、鏈路終止報文；3、鏈路維護(hù)報文。鏈路配置報文主要包括 Config-Request、 Config-Ack、 Config-Nak 和 Config-Reject 四種報 文。當(dāng)通信雙方需要建立鏈路時， 無論哪一方都需要發(fā)送 Config-Request 報文并攜帶每一端 自已所希望協(xié)商的配置參數(shù)選項。當(dāng)接收方收到 Config-Request 報文時， 會在剩下的三種類型的報文中選擇一種來響應(yīng)對 方的請求報文，到底選擇哪種報文

27、來響應(yīng)對方需依據(jù)以下兩個條件：不能完全識別配置參數(shù)選項的類型域， 我們知道一個 Config-Request 報文中會同時攜帶多個配置參數(shù)選項，而對于一個支持 PPP 協(xié)議的通信設(shè)備也不一定會支持上表中所有列出的 配置選項，即使支持，也可能在實際應(yīng)用中關(guān)閉掉某些選項功能。（例如：當(dāng)使用 PPP 協(xié)議通信的一端可能將一些無用的配置選項都關(guān)閉了，而僅支持 0 x01 和 0 x03 兩個配置參數(shù)選項，因此當(dāng)對方發(fā)送的 Config-Request 報文中含有 0 x04 配置選項時，對于本端而言這個配置參 數(shù)選項就無法識別，也即是不支持這個配置參數(shù)選項的協(xié)商） 。如果能支持完全識別配置參數(shù)選項，

28、但接收端也可能不認(rèn)可 Config-Request 報文中配置 參數(shù)選項數(shù)據(jù)域中的內(nèi)容（例如：當(dāng)一端發(fā)送魔術(shù)字配置參數(shù)選項中的魔術(shù)字為全0，而對端認(rèn)為應(yīng)該為其它值，這種情況就屬于不支持配置參數(shù)選項中的內(nèi)容） 。所以依據(jù)上面的兩個條件， 我們就可以明確在回應(yīng)對方配置請求報文時， 采用何種報文 回應(yīng)。當(dāng)接收 Config-Request 報文的一端能識別發(fā)送過來的所有配置參數(shù)選項且認(rèn)可所有配置 參數(shù)選項數(shù)據(jù)域的內(nèi)容時， 接收端將會給對端回一個 Config-Ack 報文并將配置請求報文中的 配置參數(shù)選項原封不動的放置在 Config-Ack 報文的數(shù)據(jù)域內(nèi) （根據(jù)協(xié)議的規(guī)定是不可改變配 置參數(shù)選項

29、的順序） 。當(dāng)配置請求報文的發(fā)送端收到 Config-Ack 報后，則會從當(dāng)前階段進(jìn)入 到下一個階段。當(dāng)接收 Config-Request 報文的一端能識別發(fā)送端所發(fā)送過來的所有配置參數(shù)選項，但對部分配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容不認(rèn)可時，接收端將會給對端回應(yīng)一個Config-Nak 報文，（注意，是能夠識別，只是對部分參數(shù)內(nèi)容不認(rèn)可，所以不是 Config-Reject 報文）該報文中 只攜帶不認(rèn)可的配置參數(shù)選項， 而這些配置參數(shù)選項的數(shù)據(jù)內(nèi)容為本端希望的值。 然而當(dāng)接 收端收到Config-Nak 報文后，會重新發(fā)送 Config-Request 報文，而這個 Config-Request 報

30、文 與上一次所發(fā)送的 Con fig-Request 報文區(qū)別在于那些被對端不認(rèn)可的配置參數(shù)選項的內(nèi)容被 填寫到剛剛協(xié)商完后再次發(fā)送的Config-Request 報文中（Config-Nak 報文發(fā)送回來的那些配置參數(shù)選項）。當(dāng)接收 Config-Request 報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時， 此時接收端將會向?qū)Χ嘶匾粋€ Config-Reject 報文，該報文中的數(shù)據(jù)域只攜帶那些不能識別的 配置參數(shù)選項（當(dāng)配置參數(shù)選項的類型域不識別時）。當(dāng)對端接收到 Config-Reject 報文后，同樣會再次發(fā)送一個Config-Request 報文，這個配置請求報文與上一次

31、發(fā)送的區(qū)別在于將不可識別的那些配置參數(shù)選項給刪除了。鏈路終止報文分為 Terminate-Request 和 Terminate-Reply 兩種報文。LCP 報文中提供了一 種機(jī)制來關(guān)閉一個點對點的連接，想要關(guān)斷鏈路的一端會持續(xù)發(fā)送Termi nate-Request 報文，直到收到一個 Terminate-Reply 為止。接收端一旦收到了一個Terminate-Request 報文后，必須回應(yīng)一個 Terminate- Reply 報文，同時等待對端先將鏈路斷開后，再完成本端的所有斷開 的操作。LCP 的鏈路終止報文的數(shù)據(jù)域與鏈路配置報文的數(shù)據(jù)域不一樣，鏈路終止報文中無需攜帶各配置參數(shù)選

32、項。對于鏈路終止報文也同樣需要ID 一致，當(dāng)接收到 Termi nate-Reply 報文才會做鏈路終止操作。最后說一下魔術(shù)字的含義， 這是在鏈路建立過程中比較重要的一個參數(shù)， 這個參數(shù)是在Config-Request 里面被協(xié)商的， 主要的作用是防止環(huán)路， 如果在雙方不協(xié)商魔術(shù)字的情況下， 某些 LCP的數(shù)據(jù)報文需要使用魔術(shù)字時，那么只能是將魔術(shù)字的內(nèi)容填充為全0;反之，則填充為配置參數(shù)選項協(xié)商后的結(jié)果。魔術(shù)字在目前所有的設(shè)備當(dāng)中都是需要進(jìn)行協(xié)商的， 它被放在 Config-Request 的配置選 項參數(shù)中進(jìn)行發(fā)送， 而且需要由自身的通信設(shè)備獨(dú)立產(chǎn)生， 協(xié)議為了避免雙方可能產(chǎn)生同樣 的魔術(shù)

33、字， 從而導(dǎo)致通信出現(xiàn)不必要的麻煩， 因此要求由設(shè)備采用一些隨機(jī)方法產(chǎn)生一個獨(dú) 一無二的魔術(shù)字。 一般來說魔術(shù)字的選擇會采用設(shè)備的系列號、 網(wǎng)絡(luò)硬件地址或時鐘。 雙方 產(chǎn)生相同魔術(shù)字的可能性不能說是沒有的，但應(yīng)盡量避免， 通常這種情況是發(fā)產(chǎn)在相同廠商 的設(shè)備進(jìn)行互連時，因為一個廠商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字的方法是一樣的。我們知道魔術(shù)字產(chǎn)生的作用是用來幫助檢測鏈路是否存在環(huán)路， 當(dāng)接收端收到一個 Config-Request 報文時，會將此報文與上一次所接收到的 Config-Request 進(jìn)行比較，如果兩 個報文中所含的魔術(shù)字不一致的話， 表明鏈路不存在環(huán)路。 但如果一致的話， 接收端認(rèn)為鏈

34、路可能存在環(huán)路，但不一定存在環(huán)路，還需進(jìn)一步確認(rèn)。此時接收端將發(fā)送一個Config-Nak報文，并在該報文中攜帶一個重新產(chǎn)生的魔術(shù)字，而且此時在未接收到任何Config-Request或 Config-Nak 報文之前，接收端也不會發(fā)送任何的 Config-Request 報文。這時我們假設(shè)可能 會有以下兩種情況發(fā)生：1. 鏈路實際不存在環(huán)路，而是由于對方在產(chǎn)生魔術(shù)字時與接收端產(chǎn)生的一致，但實際這 種情況出現(xiàn)的概率是很小的。當(dāng) Config-Nak 被對端接收到后，應(yīng)該發(fā)送一個 Config-Request 報文（此報文中的魔術(shù)字為 Nak 報文中的），當(dāng)對端接收到后，與上次比較，由于接收端已

35、 經(jīng)在 Nak 報文中產(chǎn)生了一個不同的魔術(shù)字， 此時接收端收到的 Config-Request 報文中的魔術(shù) 字與上次配置請求報文中不一樣，所以接收端可斷定鏈路不存在環(huán)路。2. 鏈路實際上確實存在環(huán)路， 一段時間后 Config-Nak 報文會返回到發(fā)送該報文的同一端。 這時接收端比較這個 Config-Nak 報文與上一次發(fā)出去的一樣， 因此鏈路存在環(huán)路的可能性又 增大了。我們知道當(dāng)一端收到了一個 Config-Nak 報文時，又會發(fā)送一個 Config-Request 報文 （該報文中的魔術(shù)字與Config-Nak 中的一致），這樣又回到了最初的狀態(tài)，在這條鏈路上就 會不斷的出現(xiàn) Conf

36、ig-Request、Config-Nak 報文，因此這樣周而復(fù)始下去，接收端就會認(rèn)為 PPP 鏈路存在環(huán)路的可能性在不斷增加，當(dāng)達(dá)到一定數(shù)量級時，就可認(rèn)為此鏈路存在環(huán)路。 （注意，不是第一次受到相同的魔術(shù)字就判斷有環(huán)路的）但在實際應(yīng)用中根據(jù)不同設(shè)備實現(xiàn)PPP 協(xié)議的方法，我們在鏈路環(huán)路檢測時可采用兩種方法。第一種機(jī)制就是如上面所述的，這個過程不斷地重復(fù)，最終可能會給 LCP 狀態(tài)機(jī)發(fā)一個 Down 事件，這時可能會使 LCP 的狀態(tài)機(jī)又回到初始化階段，又開始新一輪的協(xié)商。當(dāng)然 對于某些設(shè)備還會采用第二種機(jī)制，就是不產(chǎn)生任何事件去影響當(dāng)前LCP 的狀態(tài)機(jī)，而是停留在請求發(fā)送狀態(tài)。 但這時認(rèn)為鏈

37、路有環(huán)路的一端設(shè)備需要不斷的向鏈路上發(fā)送 Echo-Request 報文來檢測鏈路環(huán)路是否被解除，當(dāng)接收端收到 Echo-Reply 報文時， 就認(rèn)為鏈 路環(huán)路被解除，從而就可能進(jìn)行后續(xù)的PPP 的過程。ppp協(xié)商過理囹;首先，ppp 從 DEAD 階段開始，PPPOE 從開始到結(jié)束都是從這個階段開始了，他表示已 經(jīng)準(zhǔn)備好開始了，然后，他會進(jìn)入 establish 段，主機(jī)和服務(wù)器之間通過交換LCP 協(xié)議報文配置具體參數(shù)。在這個階段，如果 LCP 在剛剛的驗證方式驗證過程中說不要用驗證方式進(jìn)行驗證，那么就直接進(jìn)入 network 階段，如果要用驗證，就要進(jìn)入 authentication 階段用 PAP,或