PPP協議詳解

１．簡介
         點到點協議是為在兩個對等實體間傳輸資料包建立簡單串連而設計的。這種串連提供了同
時的雙向的全雙工系統操作，並且假定資料包是按順序投遞的。ＰＰＰ串連提供了一種廣泛的
解決辦法，方便地將多種多樣不忘的值作為最大接收單元的值。

填充域
在傳輸中，資訊域可能會由附加任意數目的位元組填充至最大接收單元長度。這由
每個協議負責將資訊域和填充域區分開來。

３．ＰＰＰ串連操作

３．１概述
為了在點到點串連中建立通訊，ＰＰＰ串連的每一端都必須首先發送ＬＣＰ資料
包來配置和測試資料連線。在串連建立後，對等實體還有可能需要認證。
然後，ＰＰＰ必鬚髮送ＮＣＰ資料包來選擇一種或多種網路層協議來配置。一旦
被選中的網路層協議被配置好後，該網路層的資料報就可以在鏈路上傳送了。
鏈路將保持可配置的狀態直到有ＬＣＰ資料包和ＮＣＰ資料包終止串連，或者由
其他外來事件發生時（例如非活動時鐘計時已滿或網路管理員的幹涉）。

３．２狀態圖
在配置維持和終止點到點串連的過程中，ＰＰＰ串連經曆了幾個不同的階段，這
些階段由以下簡化的狀態圖說明：

 

 

+------+ +-----------+ +--------------+
| | 串連 | | 已開啟 | | 成功/無
| 死亡 |------->| 建立 |---------->| 認證 |--+
| | | | | | |
+------+ +-----------+ +--------------+ |
^ | | |
| 失敗 | 失敗 | |
+<--------------+ +----------+ |
| | |
| +-----------+ | +---------+ |
| 斷開 | | | 正在關閉 | | |
+------------| 終止 |<---+<----------| 網路 |<-+
| | | |
+-----------+ +---------+

３．３串連死亡階段（物理層未準備好）
一個串連的開始和結束都要經曆此階段。當一個外來事件（例如檢測到載波或網
絡管理員配置）指示物理層已準備好並可以使用時，ＰＰＰ將進入建立串連階段。
在此階段，ＬＣＰ協議自動機（後面將提到）處在初始或正在開始狀態。當進入
到建立串連階段後會引發ＵＰ事件通知ＬＣＰ協議自動機。

應用注意事項：
典型的，一個串連將在數據機串連斷開後自動返回到此階段。在使用電話線
的串連情況下，這個階段將相當的短，短到很少有足夠的時間能用儀器檢測到它的存在。

３．４建立串連階段
鏈路控制協議（ＬＣＰ）通過交換佈建封包建立串連。當ＬＣＰ協議自動機進
入已開啟狀態，並且發送和接收過配置確認資料包時，為建立串連的交換過程才完成。
所有的配置選項都被假定為預設值，除非在配置互動的過程中改變。關於ＬＣＰ
配置選項的進一步討論參見後面的章節。
有一點是非常重要的，就是那些只有與特定網路層協議無關的選項才能被ＬＣＰ
配置。配置單獨的網路層協議是在網路層協議階段由相應的網路控制協議來配置。
在此階段接收到的任何非ＬＣＰ資料包將被靜默丟棄。
接收到ＬＣＰ配置請求資料包將引起ＰＰＰ串連從網路層協議階段或認證階段返
回到建立串連階段。

３．５認證階段
在某些串連時，在允許網路層協議資料包交換之前希望對對等實體進行認證。
預設時，認證不是必要的。如果應用時希望對等實體使用某些認證協議進行認證
，這種要求必須在建立串連階段提出。

認證階段應該緊接在建立串連階段後。然而，可能有串連品質的決定並行出現。
應用時絕對不允許串連品質決定資料包的交換使認證有不確定的延遲。
認證階段後的網路層協議階段必須等到認證結束後才能開始。如果認證失敗，將轉而進入
終止串連階段。
僅僅是串連控制協議、認證協議、串連品質監測的資料包才被允許在此階段中出現。所有
其它在此階段中接收到的資料包都將被靜默丟棄。

應用注意事項：
應用時不能簡單的因為逾時或缺少回應就認為認證失敗。應該允許重傳，僅當試
圖認證的次數超過一定的限制時才進入終止串連階段。
如果對方拒絕認證，己方有權進入終止串連階段。

３．６網路層協議階段
一旦ＰＰＰ完成了上述階段，每一個網路層協議（例如ＩＰ、ＩＰＸ、
ＡｐｐｌｅＴａｌｋ）必須單獨的由相應的網路控制協議（ＮＣＰ）配置。
每一個網路控制協議可以隨時開啟或關閉。

應用注意事項：
因為可能一開始就會使用需要花費大量時間的串連品質決定，所以當等待對方進
行網路控制協議配置時應該避免使用固定的逾時限制。
當一個網路控制協議自動機達到已開啟的狀態時，ＰＰＰ串連上就可以傳送相應
的網路層協議資料包。當接收到的任何所支援的網路層協議資料包時，只要相應的網路控
制協議狀態自動機未進入已開啟狀態，都將作靜默丟棄處理。

應用注意事項：
只要ＬＣＰ協議狀態自動機處於已開啟的狀態，任何接收到的不支援的協議資料
包都將返回協議拒絕包（後面將提到）。所支援的協議資料包都將靜默丟棄。
在此階段，串連上流通的包括ＬＣＰ資料包、ＮＣＰ資料包和網路層協議資料包。

３．７終止串連階段
PＰＰ串連可以隨時終止。原因可能是載波丟失、認證失敗、串連品質失敗、超
時計數器溢出，或者網路系統管理員關閉串連。
ＬＣＰ通過交換串連終止包來終止串連。當串連正在被終止的時候，ＰＰＰ會通
知網路層以便它採取相應的動作。

在交換過終止請求包後，將通知物理層斷開以便使串連真正終止，尤其是在認證失敗的時
侯。發送串連終止請求包的一方應該等待接收到串連終止確認包之後或逾時計數器計滿之
後再斷開。收到串連終止確認包的一方應該等待對方首先斷開，並且決不能斷開直到至少
有一個逾時計時器在發送了終止串連確認包之後溢出。然後ＰＰＰ應該進入串連死亡階段
。
在此階段所有接收到的非ＬＣＰ資料包都將被靜默丟棄。

應用注意事項：
關閉時使用ＬＣＰ就已足夠。並不需要每一個ＮＣＰ都發送終止串連資料包。相
反的，一個ＮＣＰ協議自動機關閉並不能關閉整個ＰＰＰ串連，即使這個ＮＣＰ協議自動
機是當前唯一處於已開啟狀態。

４． 選項協商自動機
有限狀態自動機由事件、動作、狀態遷移定義。事件包括接收外部命令，諸如開啟、關閉
、逾時計時器溢出和接收到對方發送過來的資料包。動作包括開啟逾時計數器和向對方發
送資料包。
有些類型的資料包，諸如配置否定包和配置拒絕包，或者編號拒絕包和協議拒絕包，或者
回應請求包、回應回答包和丟棄請求包在自動機的描述中都是不可區分的。正如後面將要
提到的，雖然這些不同類型的資料包會引起相同的狀態遷移，但它們確實起到了不同的作
用。

事件 動作
Up = 低層已串連 tlu = 該層已串連
Down = 低層已斷開 tld = 該層已斷開
Open = 開啟串連 tls = 該層已開始串連
Close= 關閉串連 tlf = 該層已關閉串連

TO+ = 逾時計時器溢出且逾時計數器值大於零 irc = 初始化逾時計數器
TO- = 逾時計時器溢出且逾時計數器值小於零 zrc = 逾時計數器清零

RCR+ = 收到正確的配置請求包 scr = 發送配置請求包
RCR- = 收到不正確的配置請求包
RCA = 收到配置確認包 sca = 發送配置確認包
RCN = 收到配置否定包/拒絕包 scn = 發送配置否定包/拒絕包

RTR = 收到終止請求包 str = 發送終止請求包
RTA = 收到終止確認包 sta = 發送終止確認包

RUC = 收到未知編碼包 scj = 發送編碼拒絕包
RXJ+ = 收到編碼拒絕包 (允許的)
或受到協議拒絕包
RXJ- = 收到編碼拒絕包 (糟糕的)
或受到協議拒絕包
RXR = 收到回應請求包 ser = 發送回應回答包
或者收到回應回答包
或者收到丟棄請求包
４．１狀態跳躍表
以下就是完整的狀態跳躍表。狀態水平列出來的。低層仍然沒有準備好。逾時計
時器也沒有運行在此狀態下。
當低層變得可用時，就發送配置請求包。

Ｃｌｏｓｅｄ狀態
在此狀態下，串連有效，但是沒有出現Ｏｐｅｎ事件。逾時計時器也沒有運行在
此狀態下。
此時接收到配置請求包後，將發送終止請求包。接收到終止確認包將被靜默丟棄
以免產生迴圈。

Ｓｔｏｐｐｅｄ狀態
此狀態是在Ｃｌｏｓｅｄ狀態發生了Ｏｐｅｎ事件後遷移而來的。當自動機在進
行了ｔｌｆ動作後或發送了終止請求包後在等待Ｄｏｗｎ事件時就進入此狀態。逾時計時
器也沒有運行在此狀態下。
此時接收到配置請求包後，將做出合適的回答。接收到其他類型的包時，就發送
終止確認包。接收到終止確認包將被靜默丟棄以免產生迴圈。

基本原理：
Ｓｔｏｐｐｅｄ狀態是串連終止階段、串連配置失敗和其它自動機的錯誤模式的
交匯之處。
還存在著Ｄｏｗｎ事件（由ｔｌｆ動作引發）和ＲＣＲ事件的競爭的情況。當Ｒ
或拒絕其它使用者的請求。自從串連被確認為可用時，就可以由一個Ｄｏｗｎ事件和一個緊
接著的Ｏｐｅｎ事件來通知ＬＣＰ來類比實現。應該特別注意的是Ｃｌｏｓｅ事件不能由
其它的原因引發。
此時將觸發一個Ｄｏｗｎ事件，隨即緊接著一個Ｕｐ事件。這樣做將使得串連有
次序的開始重新協商，自動機由Ｃｌｏｓｉｎｇ狀態轉移到Ｓｔｏｐｐｉｎｇ狀態，並且
ｔｌｆ動作將中斷連線。自動機將在Ｓｔｏｐｐｅｄ狀態或Ｓｔａｒｔｉｎｇ狀態中等待
下一次串連。

Ｔｉｍｅｏｕｔ（ＴＯ＋，ＴＯ－）事件
Ｔｉｍｅｏｕｔ事件指示逾時計時器溢出。當發送出配置請求包和終止請求包後
逾時計時器開始計時。
ＴＯ＋事件指示著逾時計數器的值仍然大於零。其中逾時計數器每減一，就表明
配置請求包或終止請求包就重傳一次。
ＴＯ－事件指示著逾時計數器的值小於零，再沒有任何資料包需要重傳了。

Ｒｅｃｅｉｖｅ－Ｃｏｎｆｉｇｕｒｅ－Ｒｅｑｕｅｓｔ（ＲＣＲ＋，ＲＣＲ－）事件
ＲＣＲ事件出現表明接收到了從對方發送來的配置請求包。配置請求包的到來表
明對方希望開啟串連並且指定串連選項。配置請求包將在後面有更詳細的描述。
ＲＣＲ＋事件表明對方的配置請求是可以接受的，並且將傳送配置確認包。
ＲＣＲ－事件表明對方的配置請求是不能接受，並且將傳送相應的配置否定包或
配置拒絕包。

應用注意事項：
這些事件可以在自動機已處於Ｏｐｅｎｅｄ狀態的時候發生。這時必須立即準備
好重新協商選項。

Ｒｅｃｅｉｖｅ－Ｃｏｎｆｉｇｕｒｅ－Ａｃｋ（ＲＣＡ）事件
ＲＣＡ事件出現表明收到了對方κ褂茫眨鶚錄魑卮稹? 這個動作的結果高度依賴於應用的需要。

Ｔｈｉｓ－Ｌａｙｅｒ－Ｆｉｎｉｓｈｅｄ（ｔｌｆ）動作
ｔｌｆ動作表明低層的協議自動機進入了Ｉｎｔｉａｌ狀態，Ｃｌｏｓｅｄ狀態
，或Ｓｔｏｐｐｅｄ狀態，並且低層已不再為串連所用。當低層終止時應使用Ｄｏｗｎ事
件作為回答。
典型的，此動作可能會被ＬＣＰ用來提前進入串連死亡階段，或者被ＮＣＰ用來
通知ＬＣＰ當沒有任何ＮＣＰ被開啟時串連可能會終止。
這個動作的結果高度依賴於應用的需要。

Ｉｎｉｔｉａｌｉｚｅ－Ｒｅｓｔａｒｔ－Ｃｏｕｎｔ（ｉｒｃ）動作
ｉｒｃ動作初始化逾時計數器為一合適的值（Ｍａｘ－Ｔｅｒｍｉｎａｔｅ或
Ｍａｘ－Ｃｏｎｆｉｇｕｒｅ）。每傳送一次資料包，計數器就減一，並且包括第一次。

應用注意事項：
除了設定逾時計數器之外，還必須為逾時計時器設定逾時事件的時間長度。

Ｚｅｒｏ－Ｒｅｓｔａｒｔ－Ｃｏｕｎｔ（ｚｒｃ）動作
ｚｒｃ動作將逾時計數器清零。

應用注意事項：
此動作使有限自動狀態機器能夠在進入最終所期望的狀態之前停止，允許由對方處
理網路流量。除了設定逾時計數器之外，還必須為逾時計時器設定逾時事件的時間長度。

Ｓｅｎｄ－Ｃｏｎｆｉｇｕｒｅ－Ｒｅｑｕｅｓｔ（ｓｃｒ）動作
ｓｃｒ動作將發送配置請求包。這表明期望用指定的配置選項開啟串連。當配置
選項包被發送時，逾時計時器開始計時以防止它被丟失。每當發送一個配置請求包時，超
時計數器就減一。

Ｓｅｎｄ－Ｃｏｎｆｉｇｕｒｅ－Ａｃｋ（ｓｃａ）動作
ｓｃａ動作發送配置確認包。它表明確認了接收到的配置請求包中所有的配置選
項。

Ｓｅｎｄ－Ｃｏｎｆｉｇｕｒｅ－Ｎａｋ（ｓｃｎ）動作
ｓｃｎ動作發送配置否定包或配置拒絕包。它表明否定了接收到的配置請求包中
某些的配置選項。
配置否定包被用於拒絕某一個配置選項值，並且還建議了一個新的可以接受的配
置選項值。而配置拒絕包被用於拒絕所有的配置選項，典型的是因為這些選項不能被識別
或被運用。關於如何使用配置否定包和配置拒絕包將在後面敘述鏈路控制協議資料包格式
的章節中詳細說明。

Ｓｅｎｄ－Ｔｅｒｍｉｎａｔｅ－Ｒｅｑｕｅｓｔ（ｓｔｒ）動作
ｓｔｒ動作發送終止請求包。它表明期望關閉串連。當終止請求包被發送時，超
時計時器開始計時以防止它被丟失。每當發送一個配置請求包時，逾時計數器就減一。

Ｓｅｎｄ－Ｔｅｒｍｉｎａｔｅ－Ａｃｋ（ｓｔａ）動作
ｓｔａ動作發送終止確認包。它表明確認了接收到的終止請求包或者對雙方的協
議自動機起到同步的作用。

Ｓｅｎｄ－Ｃｏｄｅ－Ｒｅｊｅｃｔ（ｓｃｊ）動作
ｓｃｊ動作發送編碼拒絕包。它表明接收到有不能識別編碼的資料包。

Ｓｅｎｄ－Ｅｃｈｏ－Ｒｅｐｌｙ（ｓｅｒ）動作
ｓｅｒ動作發送回應回答包。它表明確認接收到了回應請求包。

４．６避免迴圈

協議有效避免了在協商配置選項時的迴圈。然而，協議並不能保證這種迴圈不再出現。
在協商任何選項時，雙方有可能採取了相互矛盾決不相容的配置策略。但是雙方也有可能
採取了可以相容的配置策略，但這時可能需要花費很多時間。應用者要將此記在心中並應
應用迴圈監測機制和更高層次的逾時機制。

４．７計數器和計時器

逾時計時器
自動機並沒有運用特殊的計時器。逾時計時器被用來監測配置請求包和終止請求
包的傳送。當計時器計滿後將引發一個Ｔｉｍｅｏｕｔ事件，並重新發送相應的配置請求
包或終止請求包。逾時計時器必須被配置，而且預設值應該為三秒鐘。

應用注意事項：
逾時計時器的設定應該基於串連的速度。預設值是為低速串連（２４００－
９６００ｂｐｓ）、高速交換串連（典型的如電話線）設計的。更高速的串連，或低交換
速度串連應該相應的增加重傳的次數。

取代固定的逾時值，逾時計時器應該最初設為一個小的值然後再增加達到最終配置值。每
一個小於最終值的成功的值都應該是前一個值的兩倍。初始值應該足夠處理一個資料包，
它通常設定為兩倍於以連線速度在傳送間做一往返的時間還要加上一百毫秒，以允許對方
在做作回應之前能夠處理資料包。

最大終止次數
它是為終止請求包計數的逾時計數器所要求的一個值。它表明了在假定對方不能
做出回答之前且未接收到終止確認包時發送終止請求包最大的發送次數。最大終止次數必
須被配置，而且預設值應該為重傳兩次。

最大配置次數
相似的量被推薦給了配置請求包。它表明在假定對方不能做出回答之前且未接收
到配置確認包、配置否定包或配置拒絕包時發送配置請求包最大的發送次數。最大配置次
數必須被配置，而且預設值應該為重傳十次。

最大失敗次數

相似的量被推薦給了配置否定包。它表明了在假定未達成一致發送配置確認包之前配置否
定包最大的發送次數。任何由對方配置否定包中所建議的而後又被加入到配置拒絕包中的
選項和本地所期望的選項在協商過程中都不再追加進去。最大配置次數必須被配置，而且
預設值應該為五次。

5． 鏈路控制協議資料包格式
有三種類型的鏈路控制協議資料包：
1． 串連佈建封包用於建立和配置串連。（配置請求包，配置確認包，配置否定包
和配置拒絕包）。
2． 串連終止資料包用於終止串連（終止請求包和終止確認包）。
3． 串連維護資料包用於管理和調試串連（編碼拒絕包，協議拒絕包，回應請求包，
回應回答包和丟棄請求包）。
為了簡化起見，資料連結控制協議資料包格式中並沒有版本號碼域。對於不能識別的協議和
編碼都能以簡單的可識別的鏈路控制協議資料包格式予以回應，因此對其它的版本提供了
一種確定性但效率低的的運行機制。
不管什麼配置選項被確定為使能，所有的串連配置包，串連終止包，編碼拒絕包（編碼號
１－７）都假定沒有配置選項被協商。實際上，每一個配置選項都被指定了一個預設值。
這樣做使得諸如鏈路控制協議的資料包總是能夠識別，即使當串連已結束但仍被錯誤的認
為串連是開啟的時候。

鏈路控制協議資料包被封裝在ＰＰＰ框架格式的資料域中，且ＰＰＰ幀的協議域的值是０ｘ
ｃ０２１。
鏈路控制協議資料包格式總結如下。按照從左至右的順序被傳送。

 

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 編碼 | 標識 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 資料 ．．．
+-+-+-+-+

編碼域
編碼域佔一個八位位元組。它標識這是何種類型的鏈路控制協議資料包。當接收到
編碼域不可識別的資料包時，就發送編碼拒絕資料包。
最新的編碼域的值由最近公布的"Ａｓｓｉｇｎｅｄ　Ｎｕｍｂｅｒｓ"ＲＦＣ文
檔說明。與本文檔相關的有以下的值：
1 配置請求(Configure-Request)
2 配置確認(Configure-Ack)
3 配置否定(Configure-Nak)
4 配置拒絕(Configure-Reject)
5 終止請求(Terminate-Request)
6 終止確認(Terminate-Ack)
7 編碼拒絕(Code-Reject)
8 協議拒絕(Protocol-Reject)
9 回應請求(Echo-Request)
10 回應回答(Echo-Reply)
11 丟棄請求(Discard-Request)

標識域
標識域編碼佔一個八位位元組，它協助請求和回答進行匹配。當收到的資料包中的標
識域是無效的，它將被靜默丟棄並且不影響自動機的狀態。

長度域
標識域編碼佔兩個八位位元組，它標識了鏈路控制協議資料包的長度，包括編碼域
，標識域，資料域等。此長度不能超過串連的最大接收長度。
超過長度域的八位位元組被視為填充位元組並在接收時忽略。當接收到長度域無效的
資料包時，它將被靜默丟棄並且不影響自動機的狀態。

資料域
資料域有零個或多個八位位元組，正如長度域中所指示的長度。資料域中的格式由
編碼域中的值決定。

５．１配置請求
描述
當希望開啟一個串連時，必須傳送配置請求包。選項域中由期望改變串連預設值
的配置選項填充。配置選項不必包含使用預設值的配置選項。
當接收到了配置請求包時，必須傳送合適的資料包作為回應。
配置請求包的格式總結如下。按照從左至右的順序被傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 編碼 | 標識 | 長度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 選項 ．．．
+-+-+-+-+

編碼
1代表配置請求。

標識
當選項域中的內容改變或當接收到對前一次請求的無效回答時，標識域應做改變
。重傳時，標識域則不應改變。

選項
選項域長度可變，包含有零個或多個希望協商的配置選項的列表。全部的配置選
項將同時協商。選項域的格式將在後面的章節詳細討論。

５．２配置確認
描述
如果對方發送來的配置請求包中的配置選項都是可識別並且可接受，就可以發送
配置確認包。其中已被確認的選項的順序和選項自身都不能以任何方式修改。
接收到的配置確認包中的標識域必須同上一次發送的配置請求包中的標識域匹配
。此外，在配置確認包中選項必須同上一次發送的配置請求包中的選項完全一致。
配置請求包的格式總結如下。按照從左至右的順序被傳送。

0 1 2 用於通知對方己方可以接收更大
的資料包，或者要求對方發送更小的資料包。
它的預設值是１５００位元組。如果要求更小的資料包，當串連失去同步時應用仍
將按１５００位元組接收資訊域。

應用注意事項：

此選項說明了應用的能力。對方並沒有要求使用最大的能力。舉例來說，當ＭＲＵ為
２０４８位元組，而對方沒有被要求發送２０４８位元組大小的資料包。此時對方不需要使用
配置否定包表明它僅僅發送比２０４８位元組小的資料包，因為應用始終要求支援至少
１５００位元組的資料包。
最大接收單元配置選項格式小結如下。按照從左至右的順序被傳送。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 類型 | 　長度 | 　　 最大接收單元 　　 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

類型
1

長度
4

最大接收單元
最大接收單元域有兩個八位位元組，它指定了資訊域和填充域所能接受的最大位元組
數。它不包括幀協議域，迴圈校正碼和任何因透明傳輸而需要的位或位元組。

６．２認證協議
描述
在進行某些串連時可能希望在交換網路層資料包之前要求對方來認證自己。
這個配置選項提供了協商用指定的認證協議進行認證的方法。預設情況下，認證
是不需要的。
應用時不能在配置請求包中包含多個認證協議配置選項。相反的，應該首先配置
最期望使用的認證協議。如果被配置否定包所否定，應該在下一次配置請求中配置其次最
期望使用使用的認證協議。
應用發送配置請求包表明它希望對方對自己進行認證。如果對方發送來配置確認
包，表示它同意使用指定的協議進行erkins, D., "Requirements for an Internet
Standard Point-to-Point Protocol", RFC 1547, Carnegie Mellon University,
December 1993.

[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1340, USC/Information Sciences Institute, July 1992.

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/alec626/archive/2004/11/10/175268.aspx