pppoe原理協(xié)議詳解

1、PPPoE ( Point to Point Protocol over Ethernet，基于以太網(wǎng)的點(diǎn)對(duì)點(diǎn)協(xié)議)的工作流程包含發(fā)現(xiàn)(Discovery)和會(huì)話(Session)兩個(gè)階段，發(fā)現(xiàn)階段是 無狀態(tài)的，目的是獲得 PPPoE 終 端(在局端的ADSL 設(shè)備上)的以太網(wǎng) MAC 地址，并建立一個(gè)惟一的 PPPoESESSIOND。發(fā)現(xiàn)階段結(jié)束后，就進(jìn)入標(biāo)準(zhǔn)的PPP 會(huì)話階段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 (會(huì)話 ID )字段值為 0 x0000。PADI 分組必須至 少包含一個(gè)服務(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)請(qǐng)求。其中 COD 寄段值為 0X 07 ( PADO Code , SESSION-ID 字段值仍為 0 x0000。PADO 分組必須 包含一個(gè)

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

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

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

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

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

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

9、Windows 撥號(hào)器會(huì)協(xié)商 CBCP（被叫回呼），而 ME60 不支持 CBCP 功能，則回將此選項(xiàng)拒絕掉。2.2 認(rèn)證階段（PPP Authentication : PAP/CHAP會(huì)話雙方通過 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é)議，它通過用戶名及口令來對(duì)用戶進(jìn)行驗(yàn)證。PAP 驗(yàn)證過程如下：當(dāng)兩端鏈路可相互傳輸數(shù)據(jù)時(shí)，被驗(yàn)證方發(fā)送本端的用戶名及口令到驗(yàn)證方，驗(yàn)證方根據(jù)本端的用戶表（或Radi

10、us 服務(wù)器）查看是否有此用戶，口令是否正確。如正確則會(huì)給對(duì)端發(fā)送 Authenticate-ACK 報(bào)文，通告對(duì)端已被允許進(jìn)入下一階段協(xié)商；否則發(fā)送NAK 報(bào)文，通告對(duì)端驗(yàn)證失敗。此時(shí)，并不會(huì)直接將鏈路關(guān)閉。只有當(dāng)驗(yàn)證不過次數(shù)達(dá)到一定值（缺省為 10）時(shí)，才會(huì)關(guān)閉鏈路。PAP 的特點(diǎn)是在網(wǎng)絡(luò)上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有 可能對(duì)網(wǎng)絡(luò)安全造成極大的威脅。因此，它適用于對(duì)網(wǎng)絡(luò)安全要求相對(duì)較低的環(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 的驗(yàn)證過程為：首先由驗(yàn)證方（Server）向被驗(yàn)證方（Client）發(fā)送一些隨機(jī)產(chǎn)生的報(bào)文，并同時(shí)將本端 的主機(jī)名附帶上一起發(fā)送給被驗(yàn)證方。被驗(yàn)證方接到對(duì)端對(duì)本端的驗(yàn)證請(qǐng)求（Challe nge）時(shí)，便根據(jù)此報(bào)文中驗(yàn)證方的主機(jī)名和本端的用戶表查找用戶口令字，如找到用戶表中與驗(yàn)證方主機(jī)名相同的用戶，便利用報(bào)文ID、此用戶的密鑰用 Md5 算法生成應(yīng)答（Respons

12、e）,隨后將應(yīng)答和自己的主機(jī)名送回。驗(yàn)證方接到此應(yīng)答后，用報(bào)文 ID、本方保留的口令字 （密鑰）和隨機(jī)報(bào)文用 Md5 算法得出結(jié)果，與被驗(yàn)證方應(yīng)答比較，根據(jù)比較結(jié)果返回相應(yīng)的結(jié)果（ACKor NAK）（1）接受認(rèn)證端發(fā)送 Challe nge（2）申請(qǐng)認(rèn)證端發(fā)驗(yàn)證請(qǐng)求報(bào)文（3）接受認(rèn)證端回應(yīng)認(rèn)證接受報(bào)文經(jīng)過以上三次報(bào)文交互后，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 報(bào)文的網(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 報(bào)文并且 互相回應(yīng)N

14、CP Config-Ack 報(bào)文后，標(biāo)志 NCP 己協(xié)商完，用戶上線成功，可以正常訪問網(wǎng)絡(luò)了。IPCP 的協(xié)商過程是基于 PPP 狀態(tài)機(jī)進(jìn)行協(xié)商的。經(jīng)過雙方協(xié)商，通過配置請(qǐng)求、配置確認(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é)商包文可包含多個(gè)選項(xiàng)，即參數(shù)。各個(gè)選項(xiàng)的拒絕或否認(rèn)都不能 影響 IPCP 的UP, IPCP 可以無選項(xiàng)協(xié)商，無選項(xiàng)協(xié)商也同樣能夠UP。選項(xiàng)有 IP Address、網(wǎng)關(guān)、掩碼等，其中 IP Address

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

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

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

18、PADT。4.Linux 中的 PPPoE 撥號(hào)守護(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 實(shí)現(xiàn)代碼在 /drivers/net/ppp/ 目錄下，pppoe.c 中實(shí)現(xiàn) 了pppoe_connect、pppoe_xmit、pppoe_recvmsg 等接口。pppd 是一個(gè)后臺(tái)服務(wù)進(jìn)

19、程(daemon),是一個(gè)用戶空間的進(jìn)程，所以把策略性的內(nèi)容從 內(nèi)核的 PPP 協(xié)議處理模塊移到 pppd 中是很自然的事了。pppd 實(shí)現(xiàn)了所有鑒權(quán)、壓縮/解壓和加密/解密等擴(kuò)展功能的控制協(xié)議。pppd 只是一個(gè)普通的用戶進(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é)議處理模塊只會(huì)把應(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看對(duì)總共多了咅個(gè)宇苔,其中首尾寺節(jié)都是幀的超始和結(jié)束掾志檢,示地址,C表示控制。協(xié)議的兩個(gè)寧段,表示后面信息部分的城協(xié)儀是什么.包括:0 x0021_息宇段是1卩數(shù)據(jù)報(bào)0XC021-信息宇段星遊路揑閱觀居LCF0 x8021息字豳網(wǎng)蚯制軸NCPOXCO23言息寧段是安全性認(rèn)證FAF0XC02

21、5音息字段是LQR0XC223忌字段是安全性認(rèn)證匚HAPPPPoE 的報(bào)文就是在 PPP 的報(bào)文前面再加上 PPPOE 頭和 以太網(wǎng)的報(bào)頭，使得 PPPoE 可 以通過簡(jiǎn)單橋接設(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ù)報(bào)文下面我們來對(duì) PPP 協(xié)議的 LCP 數(shù)據(jù)報(bào)文內(nèi)容進(jìn)行一下分析和講解。首先我們需要從數(shù)據(jù) 幀內(nèi)容過度一下今天的內(nèi)容。對(duì)于 PPP 協(xié)議的基礎(chǔ)內(nèi)容，PPP 數(shù)據(jù)幀以及 PPP 模式我們都做了介紹。那么這里我們?cè)?來講解一下 PPP 協(xié)議的 LCP 數(shù)據(jù)報(bào)文的內(nèi)容。通過前面的文章，我們知道，LCP 數(shù)據(jù)報(bào)文是在鏈路建立階段被交換的，它作為PPP 的凈載荷被封裝在 PPP 數(shù)據(jù)幀的信息域中。在鏈路建立階段的整個(gè)過程中信息域

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

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

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

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

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

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

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

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

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

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

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

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

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

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