PPPoE过程
最近兩天一直在公司研究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）占用兩個字節，當訪問集中器（Access Concentrator）還沒有分配唯一的會話ID給用戶主機的話，改域的內容必須填充為0x0000；一旦主機獲取了會話ID后，那么在后續的所有報文里面必須填充那個唯一的會話ID。
5. PPPoE的Payload長度（Length）占兩個字節。PPPoE的Payload可以由多個TLV組成，每個包括Tag_Type，Tag_Length，Tag_Vlaue。
?
一、發現階段
PPPoE的發現階段一共分為4步，分別是：PADI(PPPoE Active Discovery Initiation)，PADO(PPPoE Active Discovery Offer)，PADR(PPPoE Active Discovery Request)，PADS(PPPoE Active Discovery Session-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是為了防止拒絕服務攻擊（Denial of Service，簡稱DOS）。訪問集中器（AC）能夠根據PADR的源地址來重新產生唯一的Tag_Value。使用這種方法，AC可以確保PADI的源地址是可達的，并對該地址的并行會話數進行限制。
?
二、會話階段
PPP會話的建立，需要兩端的設備都發送LCP（Link Control Protocol）數據包來配置和測試數據通信鏈路。
LCP報文可以分為三類：鏈路配置報文（LCP Configure Request，LCP Configure Reject，LCP Configure Ack和LCP Configure Nak）、鏈路終止報文和鏈路維護報文。
Ⅰ 協商階段
LCP的Request主機和AC都要給對方發送，LCP協商階段完成最大傳輸單元，是否進行認證和采用何種認證方式的協商。
LCP協商階段的數據幀由三部分組成：以太網頭，PPPoE頭和PPP頭。PPPoE Session的以太網類型域為0x8864。
PPP信息包括：Code＝01（表示Configure Request,請求同意Option中的內容）
02（表示Configure Ack，完全同意）
????????????????????03（表示Configure Nak，同意部分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 Handshake Authentication）
認證通過要經過三個步驟：首先AC發送Challenge Packet Identifier，然后客戶端發送Response Packet Identifier，最后AC發送Success Packet Identifier。
認證失敗要經過三個步驟：首先AC發送Challenge Packet Identifier，然后客戶端發送兩次Response Packet 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
?
總結
- 上一篇： CAD文件解析（DWG to SVG）
- 下一篇： Mac安装binutils工具