【正文】 從后面的88 63和09也可以確定這一點。這里給出了用該軟件捕獲的PPPOE過程的數(shù)據(jù)包。 例如：PPPOE會話階段的數(shù)據(jù)報文00 10 A4 97 C1 D9 00 B0 D0 BC AB 75 88 64 11 00 01 6B 00 14 C0 21 01 00 00 12 01 04 05 DC 03 04 C0 23 05 06 00 00 4E 3D我們可以看到下劃線部分為PPP的數(shù)據(jù)報文（0xC021表示LCP協(xié)商階段，且為代碼域為0x01表示是ConfigRequest報文）。一旦PPPOE進(jìn)入到會話階段，則PPP的數(shù)據(jù)報文就會被填充在PPPOE的凈載荷中被傳送，這時兩者所發(fā)送的所有以太網(wǎng)包均是單目地址。在收到或發(fā)送PADT后甚至正常的PPP終止報文也不能被發(fā)送。它可以由主機或訪問集中器發(fā)送，目的地址填充為對端的以太網(wǎng)的MAC地址我們來看一下PADT報文幾個域的填充情況，版本域和類型域不變固定填充0x01，代碼域填充0xA7，會話ID是那個需要被終止的進(jìn)程，報文中不需要攜帶任何標(biāo)記。例4：PADS 數(shù)據(jù)報文00 10 A4 97 C1 D9 00 B0 D0 BC AB 75 88 63 11 65 01 6B 00 10 01 03 00 04 01 00 00 00 01 01 00 00 00 00 00 00 其中下劃線部分為訪問集中器給這個PPPOE會話分配的唯一會話ID。當(dāng)然如果訪問集中器不滿足用戶所申請的服務(wù)的話，則會向用戶發(fā)送一個PADS報文，而其中攜帶一個服務(wù)名錯誤的標(biāo)記，而且此時該PADS報文中的會話ID填充0x0000。 例如：PADR 數(shù)據(jù)報文00 B0 D0 BC AB 75 00 10 A4 97 C1 D9 88 63 11 19 00 00 00 0C 01 03 00 04 01 00 00 00 01 01 00 00當(dāng)收到訪問集中器的PADO報文后，用戶主機會發(fā)送PADR報文，該報文所含的標(biāo)記域與PADI報文中的一致，但些時用戶主機已獲知了訪問集中器名。我們來看一下PADR報文幾個域的填充情況，版本域和類型域不變固定填充0x01，代碼域填充0x19，會話ID域填充0x0000。當(dāng)用戶主機收到PADO報文后，會從這些報文中挑選一個訪問集中器作為后續(xù)會話的對象。 例如：PADO 數(shù)據(jù)報文00 10 A4 97 C1 D9 00 B0 D0 BC AB 75 88 63 11 07 00 00 00 1A 01 02 00 06 4D 44 35 35 30 30 01 03 00 04 01 00 00 00 01 01 00 00 00 00 00 00這個報文中包括4個標(biāo)記，在PADI所提供的標(biāo)記的基礎(chǔ)上又增加了兩個標(biāo)記，一個是訪問集中器名，下劃線部分即表示訪問集中器名（MD5500），而且還包含一個標(biāo)記結(jié)束標(biāo)記。PADO報文中必須包含一個訪問集中器名這個標(biāo)記，同時還要包含對PADI報文中服務(wù)名標(biāo)記的確認(rèn)標(biāo)記和對其它標(biāo)記的一些確認(rèn)標(biāo)記。PADO（PPPOE Active Discovery Offer）是PPPOE發(fā)現(xiàn)階段的第二步，也即是由訪問集中器回應(yīng)各用戶主機發(fā)送的PADI報文，此時該報文所對應(yīng)的以太網(wǎng)幀的源地址填充訪問集中器的MAC地址，而目的地址則填充從PADI中所獲取的用戶主機的MAC地址。PADI報文必須含一個由用戶側(cè)請求的正確服務(wù)名標(biāo)記，當(dāng)然還可能攜帶一些其它的標(biāo)記，而一個完整的PADI報文（包括PPPOE頭）不能超過1484個字節(jié)，以便能留下足夠的空間給中繼代理增加一個中繼的會話ID標(biāo)記。我們來看一下PADI報文中幾個域的填充情況，前面已強調(diào)過版本域和類型域固定填充0x01，因為兩個域各占4位，所以合并為1個字節(jié)后應(yīng)為0x11。用戶主機是以廣播的方式發(fā)送這個報文，所以該報文所對應(yīng)的以太網(wǎng)幀的目的地址域應(yīng)填充為全1，而源地址域填充用戶主機的MAC地址。上圖中每一行后面的數(shù)字為該報文的代碼值。標(biāo)記的長度域為2個字節(jié)，它用來指明標(biāo)記數(shù)據(jù)域的長度。0x0202訪問集中器名出錯。0x0110中繼會話ID，對于PPPOE的數(shù)據(jù)報文也同樣可以像DHCP報文一樣被中斷到另外的AC上終結(jié)，這個字段則是用來維護(hù)另一個連接的。0x0104ACCookies，主要被用來防止惡意性DOS功擊。0x0102訪問集中器名，當(dāng)用戶側(cè)接收到了AC的回應(yīng)的PADO報文時，就可獲從所攜帶的標(biāo)記中獲知訪問集中器的名子，而且還可以據(jù)此來選擇相應(yīng)的訪問集中器。標(biāo)記的類型域為2個字節(jié)，下表列出了各種標(biāo)記類型的含義：標(biāo)記類型標(biāo)記說明0x0000表示PPPOE報文數(shù)據(jù)域中一串標(biāo)記的結(jié)束，為了保證版本的兼容性而保留，在有些報文中有應(yīng)用。對于PPPOE協(xié)議而言，沒有像PPP的配置參數(shù)選項那樣定義了很多細(xì)節(jié)，而只是一個初略的定義，因此在實際當(dāng)中實現(xiàn)這個過程會依據(jù)不同廠商的設(shè)備有不同。在PPPOE的發(fā)現(xiàn)階段時，該域內(nèi)會填充一些Tag（標(biāo)記）；而在PPPOE的會話階段，該域則攜帶的是PPP的報文。長度域為2個字節(jié)，用來指示PPPOE數(shù)據(jù)報文中凈載荷的長度。代碼域占用1個字節(jié)，對于PPPOE 的不同階段這個域內(nèi)的內(nèi)容也是不一樣的。PPPOE數(shù)據(jù)報文的數(shù)據(jù)區(qū)最開始的4位為版本域，協(xié)議中給出了明確的規(guī)定，這個域的內(nèi)容填充0x01。到此時已完成了前兩步了，那么剩下的兩步則是協(xié)商一些所提供的服務(wù)選項和獲取PPPOE會話階段所必須的會話ID值。當(dāng)收到初始化報文后，訪問集中器會向該用戶回應(yīng)一個報文。在這個階段一開始，由于接入用戶并不知道訪問集中器的MAC地址，則使用類似于ARP解析的過程的機制來獲取訪問集中器的MAC地址。當(dāng)完成這四步后，用戶主機與訪問集中器雙方就能獲知對方的MAC地址和唯一的會話ID號，從而進(jìn)入到下一個階段（PPPOE的會話階段）。簡單來說我們可能把PPPOE報文分成兩大塊，一大塊是PPPOE的數(shù)據(jù)報頭，另一塊則是PPPOE的凈載荷（數(shù)據(jù)域），對于PPPOE報文數(shù)據(jù)域中的內(nèi)容會隨著會話過程的進(jìn)行而不斷改變。校驗域，主要用來保證鏈路層數(shù)據(jù)幀傳送的正確性。在PPPOE的發(fā)現(xiàn)階段時，以太網(wǎng)的類型域填充0x8863；而在PPPOE的會話階段時，以太網(wǎng)的類型域填充為0x8864。通過這個字段的內(nèi)容，數(shù)據(jù)包的接收方可以識別以太網(wǎng)的數(shù)據(jù)域中承載的是什么協(xié)議的數(shù)據(jù)報文。在前面也提到了，對于PPP這樣的數(shù)據(jù)鏈路層協(xié)議而言，二層地址通信雙方之間已失去了原有的意義。以太網(wǎng)目的地址（目的MAC地址）和以太網(wǎng)源地址（源MAC地址），是我們大家最為熟悉的數(shù)據(jù)鏈路層地址。在介紹PPPOE的發(fā)現(xiàn)階段之前，首先讓我們重溫一下以太網(wǎng)幀的封裝格式，前面也介紹過了，所有的PPPOE的數(shù)據(jù)報文均是被封裝在以太網(wǎng)的數(shù)據(jù)域（凈載荷區(qū)）中傳送的。在這個過程中訪問集中器會為每一個PPPOE會話分配一個唯一的進(jìn)程ID，會話建立起來后就開始了PPPOE的會話階段，在這個階段中已建立好點對點連接的雙方（這種點對點的結(jié)構(gòu)與PPP不一樣，它是一種邏輯上的點對點關(guān)系）就采用PPP協(xié)議來交換數(shù)據(jù)報文，從而完成一系列PPP的過程，最終將在這點對點的邏輯通道上進(jìn)行網(wǎng)絡(luò)層數(shù)據(jù)報的傳送。當(dāng)一個主機希望能夠開始一個PPPOE會話時，它首先會在廣播式的網(wǎng)絡(luò)（也可能還要跨躍多點訪問的網(wǎng)絡(luò)，如ATM等，從而就形成了PPPOEOA的數(shù)據(jù)包）上尋找一個訪問集中器，當(dāng)然可能網(wǎng)絡(luò)上會存在多個訪問集中器時，對于主機而言則會根據(jù)各訪問集中器（AC，Access Concentration）所能提供的服務(wù)或用戶的預(yù)先的一些配置來進(jìn)行相應(yīng)的選擇。這里我們更注重PPPOE發(fā)現(xiàn)階段的介紹，因為PPPOE的會話階段和PPP的會話過程基本上是一樣的，兩者的主要區(qū)別在于只是在PPP的數(shù)據(jù)報文前封裝了PPPOE的報文頭。為了能在廣播式的網(wǎng)絡(luò)上建立、維持各主機與訪問集中器之間點對點的關(guān)系，那么就需要每個主機與訪問集中器之間能建立唯一的點到點的會話。PPPOE協(xié)議提供了在廣播式的網(wǎng)絡(luò)（如以太網(wǎng)）中多臺主機連接到遠(yuǎn)端的訪問集中器（我們對目前能完成上述功能的設(shè)備為寬帶接入服務(wù)器）上的一種標(biāo)準(zhǔn)。IETF的工程師們在秉承窄帶撥號上網(wǎng)的運營思路（使用NAS設(shè)備終結(jié)用戶的PPP數(shù)據(jù)包），制定出了在以太網(wǎng)上傳送PPP數(shù)據(jù)包的協(xié)議（Point To Point Protocol Over Ethernet），這個協(xié)議出臺后，各網(wǎng)絡(luò)設(shè)備制造商也相繼推出自已品牌的寬帶接入服務(wù)器（BAS），它不僅能支持PPPOE協(xié)議數(shù)據(jù)報文的終結(jié)，而且還能支持其它許多協(xié)議。同時又給各大網(wǎng)絡(luò)運營商們帶來了種種困惑，無論使用哪種接入技術(shù)，對于他們而言可盼和可求的是如何有效的管理用戶，如何從網(wǎng)絡(luò)的投資中收取回報，因此對于各種寬帶接入技術(shù)的收費的問題就變得更加敏感。當(dāng)對端正確接收到了該報文后，應(yīng)該回應(yīng)一個ConfigNak報文，報文內(nèi)容如下：7E FF 03 80 21 03 01 00 0A 03 06 C0 A8 00 01 7E當(dāng)接收方收到該報文后，重新發(fā)送一個ConfigRequest報文，報文內(nèi)容如下：7E FF 03 80 21 01 02 00 0A 03 06 C0 A8 00 01 7E接收方再次收到發(fā)送方的一個ConfigRequest報文，此時將回應(yīng)一個ConfigAck報文，報文內(nèi)容如下：7E FF 03 80 21 02 02 00 0A 03 06 C0 A8 00 01 7E請仔細(xì)觀察一下這些報文在交互過程中，PPP數(shù)據(jù)幀凈載荷內(nèi)的數(shù)據(jù)報文的類型域和報文ID。接收方IP地址的配置過程與靜態(tài)時的一樣，只需發(fā)送一個ConfigRequest報文即可，當(dāng)收到發(fā)送方的ConfigAck報文，就表示接收方的IP地址配置完成。由于發(fā)送方?jīng)]有配置IP地址（而是動態(tài)獲取IP地址），所以在IPCP的ConfigRequest報文的IP地址配置參數(shù)配置選項中的IP地址填充全0（），這樣當(dāng)對端收到這個ConfigRequest報文時，當(dāng)接收方收到該配置請求報文后會迅檢測IP地址的內(nèi)容，如果發(fā)送為全0，則認(rèn)為對端的這個IP地址不是我所希望的值，這樣就回應(yīng)一個ConfigNak報文，并將希望分配給對方的IP地址填充到ConfigNak報文內(nèi)。圖我們可以看出發(fā)送方連續(xù)發(fā)送了兩次ConfigRequest報文，才能完成發(fā)送方的協(xié)商過程。當(dāng)對端正確接收到了該報文后，應(yīng)該回應(yīng)一個ConfigAck報文，報文內(nèi)容如下：7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 01 7E同樣的接收方給發(fā)送方也發(fā)送一個ConfigRequest報文內(nèi)容如下，但此時報文中IP地址配置參數(shù)選項的值為本端的IP地址（）：7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E發(fā)送方回應(yīng)一個ConfigAck報文給接收方，報文內(nèi)容如下：7E FF 03 80 21 02 01 00 0A 03