PPP協議簡介 ---------------------------- PPP: Point-to-Point Protocol，鏈路層協議。使用者實現點對點的通訊。 PPP協議中提供了一整套方案來解決鏈路建立、維護、拆除、上層協議協商、認證等問題。具體包含這樣幾個部分：鏈路控制協議LCP（Link Control Protocol）；網路控制協議NCP（Network Control Protocol）；認證協議，最常用的包括口令驗證協議PAP（Password Authentication Protocol）和挑戰握手驗證協議CHAP（Challenge-Handshake Authentication Protocol）。 幀格式與HDLC相似，不同的是PPP是面向字元，HDLC是面向位的。PPP幀格式如下：
看到總共多了8個位元組，其中首尾位元組都是幀的起始和結束標誌位，A表示地址，C表示控制。 協議的兩個欄位，表示後面資訊部分的資料協議是什麼，包括： 0x0021——資訊欄位是IP資料報
0xC021——資訊欄位是鏈路控制資料LCP
0x8021——資訊欄位是網路控制資料NCP
0xC023——資訊欄位是安全性認證PAP
0xC025——資訊欄位是LQR
0xC223——資訊欄位是安全性認證CHAP PPP協議的工作過程 --------------------------------- PPP通訊是兩個端點之間的通訊，每一端必須首先發送LCP packets資料來設定和測試資料鏈路，當鏈路建立後，peer才可以被認證，認證完成後，再通過傳送NCP packets來選定網路層協議，這些後續的通訊就可以在網路層進行了。 具體的過程如下： 1. 鏈路靜止狀態：鏈路一定開始並結束於這個階段。當一個外部事件（例如載波偵聽或網路管理員設定）指出物理層已經準備就緒時，PPP將進入鏈路建立階段。在這個階段，LCP自動機器將處於初始狀態，向鏈路建立階段的轉換將給LCP自動機器一個UP事件訊號。 2. 鏈路建立狀態：LCP用於交換配置資訊包（Configure packets），建立連線。一旦一個配置成功資訊包（Configure-Ackpacket）被髮送且被接收，就完成了交換，進入了LCP開啟狀態。所有的配置選項都假定使用預設值，除非被配置交換所改變。有一點要注意：只有不依賴於特別的網路層協議的配置選項才被LCP配置。在網路層協議階段，個別的網路層協議的配置由個別的網路控制協議（NCP）來處理。在這個階段接收的任何非LCPpackets必須被silentlydiscarded（靜靜的丟棄）。收到LCPConfigure-Request（LCP配置要求）能使鏈路從網路層協議階段或者認證階段返回到鏈路建立階段。 3. 認證階段：在一些鏈路上，在允許網路層協議packets交換之前，鏈路的一端可能需要peer去認證它。認證是不需要強制執行的。如果一次執行希望peer根據某一特定的認證協議來認證，那麼它必須在鏈路建立階段要求使用那個認證協議。應該儘可能在鏈路建立後立即進行認證。鏈路質量檢查可以同時發生。在認證完成之前，禁止從認證階段前進到網路層協議階段。如果認證失敗，認證者應該躍遷到鏈路終止階段。 在這一階段裡，只有鏈路控制協議、認證協議，和鏈路質量監視協議的packets是被允許的。在該階段裡接收到的其他的packets必須被靜靜的丟棄。 4. 網路層協議階段：一旦PPP完成了前面的階段，每一個網路層協議（例如IP，IPX，或AppleTalk）必須被適當的網路控制協議（NCP）分別設定。比如，NCP可以給新接入的PC機分配一個臨時的IP地址，這樣PC機就成為Internet上一個主機了。每個NCP可以隨時被開啟和關閉。當一個NCP處於Opened狀態時，PPP將攜帶相應的網路層協議packets。當相應的NCP不處於Opened狀態時，任何接收到的被支援的網路層協議packets都將被靜靜的丟棄。 5. 鏈路終止階段：PPP可以在任意時間終止鏈路。引起鏈路終止的原因很多：載波丟失、認證失敗、鏈路質量失敗、空閒週期定時器期滿、或者管理員關閉鏈路。LCP用交換Terminate（終止）packets的方法終止鏈路。當鏈路正被關閉時，PPP通知網路層協議，以便他們可以採取正確的行動。交換Terminate（終止）packets之後，執行應該通知物理層斷開，以便強制鏈路終止，尤其當認證失敗時。Terminate-Request（終止-要求）的傳送者，在收到Terminate-Ack（終止-允許）後，或者在重啟計數器期滿後，應該斷開連線。收到Terminate-Request的一方，應該等待peer去切斷，在發出Terminate-Request後，至少也要經過一個Restarttime（重啟時間），才允許斷開。PPP應該前進到鏈路死亡階段。在該階段收到的任何非LCPpackets，必須被靜靜的丟棄。
PPPoE協議及其工作過程 ----------------------------------------- PPPoE: PPP over Ethernet，是經常被用在DSL連結上的變種協議(RFC 2516)，另外PPPoA 有時也被使用(PPP over ATM)。 PPPoE一般用在DSL接入網路，如下圖所示： PPPoE的報文就是在PPP的報文前面再加上乙太網的報頭，使得PPPoE可以通過簡單橋接裝置連入遠端接入裝置。但這裡我們發現PPPoE報文中的PPP內容與原始的PPP並不相同。 也可參考整個PPPoE的報文（包括Ethernet Frame）： 詳細的說，就是下面的內容：
解釋一下上面PPPoE報文中的關鍵欄位的意義。 ETHER_TYPE： 

0x8863	Discovery Stage
0x8864	PPP Session Stage

CODE： 

0x00	PPP Session Stage
0x09	PPPOE Active Discovery Initiation (PADI) packet
0x07	PPPOE Active Discovery Offer (PADO) packet
0x19	PPPOE Active Discovery Request (PADR) packet
0x65	PPPOE Active Discovery Session-confirmation (PADS) packet
0xa7	PPPOE Active Discovery Terminate (PADT) packet

TAG_TYPES：（用於Discovery Stage中的協商引數）
0x0000 End-Of-List
0x0101 Service-Name
0x0102 AC-Name
0x0103 Host-Uniq
0x0104 AC-Cookie
0x0105 Vendor-Specific
0x0110 Relay-Session-Id
0x0201 Service-Name-Error
0x0202 AC-System-Error
0x0203 Generic-Error PPPoE的工作過程分成兩個階段，即發現階段(Discorvery)和PPP會話階段。 發現階段(Discovery Stage)的具體過程如下： 1. 使用者主機用廣播的方式發出PADI (PPPOE Active Discovery Initiatio) 包，準備去獲得所有可連線的接入裝置（獲得其MAC地址）； 2. 接入裝置收到PADI包後，返回PADO (PPPOE Active Discovery Offer) 作為迴應； 3. 使用者主機從收到的多個PADO包中，根據其名稱型別名或者服務名，選擇一個合適的接入裝置，然後傳送PADR (PPPOE Active Discovery Request) 包，另外如果一個使用者主機在發出PADI後在規定時間內沒有收到PADO，則會重發PADI； 4. 接入裝置收到PADR包後，返回PAS (PPPOE Active Discovery Session-confirmation) 包，其中包含了一個唯一session ID，雙方進入PPP會話階段。 PPP會話階段，即在session建立後的通訊階段。 另外，無論是使用者主機還是接入裝置可隨時發起PADT包，中止通訊。 使用PPPoE進行通訊的整個過程如下圖所示：