PPPoE(PPP overEthernet)是在乙太網上建立PPP連線，由於乙太網技術十分成熟且使用廣泛，而PPP協議在傳統的撥號上網應用中顯示出良好的可擴充套件性和優質的管理控制機制，二者結合而成的PPPoE協議得到了寬頻接入運營商的認可並廣為採用。PPPoE不僅有乙太網的快速簡便的特點，同時還有PPP的強大功能，任何能被PPP封裝的協議都可以通過PPPoE傳輸。

PPPoE的資料報文是被封裝在乙太網幀的資料域內的。

乙太網幀頭包括：

1. 目的MAC地址(該階段為ffffffffffff的廣播地址)

2. 源MAC地址（客戶端MAC地址）

3. 乙太網協議型別(該階段為0x8863,表示為發現階段)。

PPPoE資料報文的格式：

1.PPPoE資料報文最開始的4位為版本域（Version），協議中給出了明確的規定，這個域填充的內容為0x01.

2. 版本域後是4位的型別域（Type），根據協議規定，這個域填充的內容也是0x01.

3. 程式碼域（Code）佔用一個位元組，對於PPPoE的不同階段這個域內容也不一樣。

4. 會話ID（Session ID）佔用兩個位元組，當訪問集中器（AccessConcentrator）還沒有分配唯一的會話ID給使用者主機的話，改域的內容必須填充為0x0000；一旦主機獲取了會話ID後，那麼在後續的所有報文裡面必須填充那個唯一的會話ID。

5.PPPoE的Payload長度（Length）佔兩個位元組。PPPoE的Payload可以由多個TLV組成，每個包括Tag_Type，Tag_Length，Tag_Vlaue。

PPPoE建立過程可以分為Discovery階段和PPP會話階段。Discovery階段是一個無狀態的階段，該階段主要是選擇接入伺服器，確定所要建立的PPP會話識別符號SessionID，同時獲得對方點到點的連線資訊；PPP會話階段執行標準的PPP過程

一、發現階段（Discovery）

PPPoE的發現階段一共分為4步，分別是：PADI(PPPoE Active DiscoveryInitiation)，PADO(PPPoE Active Discovery Offer)，PADR(PPPoE ActiveDiscovery Request)，PADS(PPPoE Active DiscoverySession-confirmation)。當完成這四步之後，使用者主機（PC）和訪問集中器（AC）雙方就能獲知對方唯一的MAC地址和唯一的會話ID。MAC地址和會話ID共同定義了唯一的PPPoE會話。PPPoE Discovery的乙太網型別域為0x8863。

1.PADI：PPPoE發現階段的第一步。使用者主機以廣播的方式傳送PADI數報包，請求建立鏈路。Code域置為0x09，會話ID域必須置為0x0000。

2.PADO：PPPoE發現階段的第二步。訪問集中器（AC）以單播的方式傳送一個PADO資料包對主機的請求做出應答。目的地址為主機的MAC地址，Code域置為0x07，會話ID域必須置為0x0000。PADO資料包必須包含一個型別為AC-Name的Tag（包含了訪問集中器的名字）。

3.PADR：PPPoE發現階段的第三步。因為PADI資料包是廣播的，所以主機可能收到不止一個的PADO報文。主機在收到報文後，會根據AC-Name或者PADO所提供的服務來選擇一個AC，然後主機向選中的AC單播一個PADR資料包。目的地址域為AC的MAC地址，Code域置為0x19，會話ID域必須置為0x0000。PADR報文必須且只能包含一個Tag_Type為Service-Name的Tag，表明主機請求的服務。

4.PADS：PPPoE發現階段最後一步。當AC在收到PADR報文時，就準備開始一個PPP的會話了。它為PPPoE會話建立一個唯一的會話ID並用單播一個PADS資料包來給主機做出響應。目的地址域為主機的MAC地址，Code域置為0x65，會話ID必須設定為所建立好的會話ID。

注意：

1. Host-Uniq 

在PPPoE發現階段的四個步驟中，PPPoE頭的Payload中始終含有這樣一個TLV：

Tag_Type = 0103 (表示為Host-Uniq)

Tag_Length = 8 （8個位元組的長度）

Tag_Value = 0500000008000000

Host-Uniq為主機唯一標識，類似於PPP資料報文中的標識域，主要是用來匹配發送和接收端的。因為對於廣播式的網路中會同時存在很多個PPPoE的資料報文。

2. AC-Cookie

PADO和PADR資料包裡面都含有Tag_Type為AC-Cookie的Tag，16Bytes。Ac-Cookie是為了防止拒絕服務攻擊（DenialofService，簡稱DOS）。訪問集中器（AC）能夠根據PADR的源地址來重新產生唯一的Tag_Value。使用這種方法，AC可以確保PADI的源地址是可達的，並對該地址的並行會話數進行限制。

二、會話階段（PPP)

PPP會話的建立，需要兩端的裝置都發送LCP（Link ControlProtocol）資料包來配置和測試資料通訊鏈路。

LCP報文可以分為三類：鏈路配置報文（LCP Configure Request，LCP ConfigureReject，LCP Configure Ack和LCP Configure Nak）、鏈路終止報文和鏈路維護報文。

Ⅰ 協商階段

LCP的Request主機和AC都要給對方傳送，LCP協商階段完成最大傳輸單元，是否進行認證和採用何種認證方式的協商。

LCP協商階段的資料幀由三部分組成：乙太網頭，PPPoE頭和PPP頭。PPPoESession的乙太網型別域為0x8864。

PPP資訊包括： Code＝01（表示Configure Request,請求同意Option中的內容）

                    02（表示ConfigureAck，完全同意）

                    03（表示ConfigureNak，同意部分Option中的內容，還需要再協商）

                   04（表示Configure Reject，完全不同意）

                   06（Terminate Ack，正常下網）

1.當Config-Request報文的一端能識別傳送過來的所有配置引數選項且認可所有配置引數選項資料域的內容時，接收端將會給對端回一個Config-Ack報文並將配置請求報文中的配置引數選項原封不動的放置在Config-Ack報文的資料域內。

2.當接收Config-Request報文的一端能識別傳送端所傳送過來的所有配置引數選項，但對部分配置引數選項資料域中的內容不認可時，接收端將會給對端迴應一個Config-Nak報文，該報文只攜帶不認可的配置引數選項，而這些配置引數選項的資料內容為本端希望的值。

當接收端接收到Config-Nak報文後，會重新新發送Config-Request報文。這次的報文和上一次報文的區別在於那些被對端不認可的配置引數選項的內容被替換成Config-Nak報文裡面相應的內容。

3.當接收Config-Request報文的一端不能識別所有傳送端傳送過來的配置引數選項時，此時接收端將會向對端回一個Config-Reject報文，該報文中的資料域只攜帶那些不能識別的配置引數選項。當對端接收到Config-Reject報文後，會再次傳送Config-Request報文，只是將不被識別的那些配置引數選項給刪除了。
Ⅱ 認證階段

會話雙方通過LCP協商好的認證方法進行認證，如果認證通過了，才可以進行下面的網路層的協商。認證過程在鏈路協商結束後就進

行。但此時可能鏈路質量的協商還在進行。所以會延緩認證過程。

認證階段包括：Challenge Packet Identifier ,Response Packet Identifier.Success Packet Identifier和Failure Packet Identifier

認證報文包括：乙太網頭，PPPOE頭，PPP頭和CHAP頭（採用的是Chap認證）。

乙太網頭和PPPOE頭跟LCP中的相似。PPP頭中，Protocol＝0xc223（Challenge HandshakeAuthentication）

認證通過要經過三個步驟：首先AC傳送Challenge Packet Identifier，然後客戶端傳送 ResponsePacket Identifier，最後AC傳送Success Packet Identifier。

認證失敗要經過三個步驟：首先AC傳送Challenge Packet Identifier，然後客戶端傳送兩次 ResponsePacket Identifier，最後AC傳送 Failure Packet Identifier。

Ⅲ IPCP協商階段

使用者和接入裝置對IP服務階段的一些要求進行多次協商，以決定雙方都能夠接收的約定。如：IP業務階段使用的IP壓縮協議等。雙方的協議是通過報文中包含的Option項進行協商的，每一個Option都是一個需要協商的問題。最後雙方都需要對方答覆Configure_Ack的同意報文。

IPCP階段的報文：乙太網頭，PPPoE頭，PPP。乙太網頭和PPPOE頭跟LCP階段相同。

PPP中存放的是多個Option。Option格式與LCP的TLV相同。

Configure_Request：要求協商的Option

Configure_Nak：表示對收到的Option都可識別，但是一些不能夠接收。

Configure_Ack：表示對收到的都能夠接收。

Configure_Reject：收到的Option不能夠接收。

達成一致後，進入資料包的真正傳輸階段，即IP階段。使用者和AC之間通訊都開始使用對方的IP地址而不是MAC地址。

檢視原文:http://blog.sina.com.cn/s/blog_4db83b6f01000apf.html