【正文】 Report鏈路品質(zhì)報告 c223 挑戰(zhàn) 認證握手協(xié)議 新的協(xié)議的開發(fā)者必須從 the Inter Assigned Numbers Authority (IANA), 。 64 信息字段 ? 信息字段是 0或更多的字節(jié)。對于在協(xié)議字段里指定的協(xié)議，信息字段包含數(shù)據(jù)報。信息字段的最大長度，包含填料但不包含協(xié)議字段，術(shù)語叫做 最大接收單元（ MRU），默認值是 1500字節(jié)。若經(jīng)過協(xié)商同意，也可以使用其它的值作為 MRU。 65 PPP的工作過程可通過 PPP狀態(tài)圖來描述： 建 立 鑒 別通 信終 止網(wǎng) 絡靜 止協(xié) 商 選 項鑒 別 成 功N C P 配 置通 信 結(jié) 束失 敗載 波 停 止失 敗檢 測 到 載 波66 （ 1） Dead: 連接靜止階段（物理層未準備好） ? 一個連接的開始和結(jié)束都要經(jīng)歷此階段。當一個外部事件（例如檢測到載波或網(wǎng)絡管理人員配置）指示物理層已準備好并可以使用時，ＰＰＰ將進入建立連接階段。 在此階段，ＬＣＰ協(xié)議自動機（后面將提到）處在初始或正在開始狀態(tài)。當進入到建立連接階段后會引發(fā)ＵＰ事件通知ＬＣＰ協(xié)議自動機。 67 （ 2） 建立連接階段 ? LCP負責創(chuàng)建鏈路。在這個階段，將對基本的通訊方式進行選擇。鏈路兩端設備通過 LCP向?qū)Ψ桨l(fā)送配置信息報文（ Configure Packets）。一旦一個配置成功信息包（ ConfigureAck packet）被發(fā)送且被接收，就完成了交換，進入了 LCP開啟狀態(tài)。 所有的配置選項都被假定為缺省值，除非在配置交互的過程中改變。 68 （ 3）認證階段 (鑒別階段 ) ? 在某些連接時，在允許網(wǎng)絡層協(xié)議數(shù)據(jù)包交換之前希望對對等實體進行認證。 缺省時，認證不是必要的。如果應用時希望對等實體使用某些認證協(xié)議進行認證，這種要求必須在建立連接階段提出。 ? 認證階段應該緊接在建立連接階段后。然而，可能有連接質(zhì)量的決定并行出現(xiàn)。應用時絕對不允許連接質(zhì)量決定數(shù)據(jù)包的交換使認證有不確定的延遲。認證階段后的網(wǎng)絡層協(xié)議階段必須等到認證結(jié) 69 （ 4） 網(wǎng)絡層協(xié)議階段 ? 一旦ＰＰＰ完成了上述階段，每一個網(wǎng)絡層協(xié)議必須單獨的由相應的網(wǎng)絡控制協(xié)議（ＮＣＰ）配置。 每一個網(wǎng)絡控制協(xié)議可以隨時打開或關(guān)閉。 ? 認證階段完成之后， PPP將調(diào)用在鏈路創(chuàng)建階段（階段 1）選定的各種網(wǎng)絡控制協(xié)議（ NCP） ,例如ＩＰ、ＩＰＸ。選定的 NCP解決 PPP鏈路之上的高層協(xié)議問題，例如，在該階段 IP控制協(xié)議（ IPCP）可以向撥入用戶分配動態(tài)地址。 70 （ 5） 終止連接階段 ? PＰＰ連接可以隨時終止。原因可能是載波丟失、認證失敗、連接質(zhì)量失敗、超時計數(shù)器溢出，或者網(wǎng)絡管理員關(guān)閉連接。 ＬＣＰ通過交換連接終止包來終止連接。當連接正在被終止的時候，ＰＰＰ會通知網(wǎng)絡層以便它采取相應的動作。 71 認證方式 （ 1）口令驗證協(xié)議（ PAP） ? PAP是一種簡單的明文驗證方式。NAS（網(wǎng)絡接入服務器， Network Access Server）要求用戶提供用戶名和口令， PAP以明文方式返回用戶信息。很明顯，這種驗證方式的安全性較差，第三方可以很容易的獲取被傳送的用戶名和口令，并利用這些信息與 NAS建立連接獲取 NAS提供的所有資源。所以，一旦用戶密碼被第三方竊取， PAP無法提供避免受到第三方攻擊的保障措施。 72 （ 2）挑戰(zhàn) 握手驗證協(xié)議（ CHAP） ? NAS向遠程用戶發(fā)送一個挑戰(zhàn)口令（ challenge），其中包括會話 ID和一個任意生成的挑戰(zhàn)字串（ arbitrary challenge string）。遠程客戶必須使用 MD5單向哈希算法 （ oneway hashing algorithm）返回用戶名和加密的挑戰(zhàn)口令，會話 ID以及用戶口令，其中用戶名以非哈希方式發(fā)送。 73 PPP的優(yōu)點 ? PPP協(xié)議是目前廣域網(wǎng)上應用最廣泛的協(xié)議之一，它的優(yōu)點在于簡單、具備用戶驗證能力、可以解決 IP分配等。 74 ? 當 PPP用在同步傳輸鏈路時，協(xié)議規(guī)定 采用硬件來完成比特填充 (和 HDLC的做法一樣 )。但當 PPP用在異步傳輸時，它就使用一種 特殊的字符填充法 (當 0x7d出現(xiàn)在 PPP數(shù)據(jù)幀中時，那么緊接著的字符的第 6個比特要取其補碼 ,詳見下頁 ) ? PPP不提供 可靠傳輸?shù)姆?。 75 1) 當遇到字符 0x7e時，需連續(xù)傳送兩個字符：0x7d和 0x5e 2) 當遇到轉(zhuǎn)義字符 0x7d時，需連續(xù)傳送兩個字符： 0x7d和 0x5d 默認情況下，如果字符的值小于 0x20，一般都要進行轉(zhuǎn)義。例如，遇到字符 0x01時需連續(xù)傳送 0x7d和 0x21兩個字符（這時，第 6個比特取補碼后變?yōu)?1，而前面兩種情況均把它變?yōu)?0）。 這樣做的原因是防止它們出現(xiàn)在雙方主機的串行接口驅(qū)動程序或調(diào)制解調(diào)器中，因為有時它們會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協(xié)議來指定是否需要對這 32個字符中的某一些值進行轉(zhuǎn)義。默認情況下是對所有的 32個字符都進行轉(zhuǎn)義 。 特殊的字符填充法 76 PPP協(xié)議之所以不使用序號和確認機制是出于以下的幾點考慮： \（ 1） 若使用可靠的數(shù)據(jù)鏈路層協(xié)議 (如HDLC)， 開銷就要增大 。 （ 2） 在因特網(wǎng)環(huán)境下 ， PPP的信息字段放入的數(shù)據(jù)是 IP數(shù)據(jù)報 。 數(shù)據(jù)鏈路層的可靠傳輸并不能夠保證網(wǎng)絡層的傳輸也是可靠的 。 （ 3） PPP協(xié)議在幀格式中有幀檢驗序列FCS字段 。 77 PPP協(xié)議的實現(xiàn) ? 在同步傳輸鏈路時， 采用硬件 實現(xiàn) ? 在異步傳輸時 ,采用軟件實現(xiàn) ? 在系統(tǒng)中設置 78 PPP協(xié)議的應用 ? 家庭撥號上網(wǎng)就是通過 PPP在用戶端和運營商的接入服務器之間建立通信鏈路。 ? PPP與其他的協(xié)議共同派生出了符合寬帶接入要求的新的協(xié)議，如 PPPoE（ PPP over Ether）， PPPoA（ PPP over ATM）。 ? 網(wǎng)絡互連 79 習題 P59 習題二 1 2