在以太網上傳輸PPP的方法（PPPoE）

本備忘錄狀態
ThismemoprovidesinformationfortheInternetcommunity.Itdoes
notspecifyanInternetstandardofanykind.Distributionofthis
memoisunlimited.
版權聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
摘要
點到點協議(PPP，參考文獻[1])提供在點到點連路上傳送多協議數據報的標準方法。
本文檔描述在以太網上建立PPP會話以及封裝PPP數據報的方法。

可行性
本說明書試圖提供PPP所定義的工具，如鏈路控制協議(LinkControlProtocol,LCP),網絡層控制協議（Network-layerControlProtocols,NCP）,認證以及其它機制。這些功能要求在通信雙方之間存在點到點的關系，而不是在以太網和其他多訪問環境中所出現的多點關系。
本規范可用于同一個以太網上的多個主機通過一個或多個跨接（橋接）的調制解調器向多個目的主機開放其PPP會話。主要用于寬帶遠程訪問技術，即訪問服務的提供者希望通過提供一個橋接的拓撲結構從而保持PPP會話摘要。
本文檔描述的PPPoE是RedBackNetworks,RouterWare,UUNET及其它廠商所采用的在以太網上封裝PPP的方法。

目錄
1.簡介 3
2.約定 3
3.協議總述 3
4.凈載數據 4
5.DISCOVERY階段 5
5.1PPPoEActiveDiscoveryInitiation數據包(PADI) 5
5.2ThePPPoEActiveDiscoveryOffer數據包(PADO) 5
5.3ThePPPoEActiveDiscoveryRequest數據包(PADR) 6
5.4ThePPPoEActiveDiscoverySession-confirmation數據包(PADS) 6
5.5THEPPPOEACTIVEDISCOVERYTERMINATE數據包(PADT) 6
6.PPP會話階段 6
7.LCP方面的考慮 7
8.其它方面的考慮 7
9.安全方面的考慮 7
10.致謝 8
11.參考文獻 8
附錄A 8
附錄B 9
作者地址 10
完整的版權通告 11

1.簡介
現代訪問技術有幾個互相沖突的設計目標。人們想通過相同的以顧客為前提的訪問設備（接入設備）來連接到遠程站點上的多個主機，同時提供與撥號上網（使用PPP）類似的訪問控制和支付功能。在很多訪問技術（接入技術）中，把多個主機連接到以顧客為前提的訪問設備（接入設備）的最經濟的方法就是通過以太網。另外，還想盡量保持設備的低成本同時要求不改變或很少改變其配置。
以太網上的PPP(PPPoE)提供通過簡單橋接訪問設備（接入設備）把一個網絡的多個主機連接到遠程訪問集中器的功能。使用該模型，每一個主機使用自己的PPP協議棧，呈現給用戶的還是熟悉的用戶接口，訪問控制、支付以及服務類型（typeofservice）都能基于每一個用戶，而不是基于站點。
為了提供以太網上的點到點連接，每一個PPP會話必須知道遠程通信對方的以太網地址，并建立一個唯一的會話標識符。PPPoE包含一個（以太網地址）發現協議來提供這個功能。
2.約定
本文當中出現的關鍵詞必須（MUST）,不允許（MUSTNOT）,必需（REQUIRED）,應該（SHALL）,不應（SHALLNOT）,應該（SHOULD）,不應該（SHOULDNOT）,推薦（RECOMMENDED）,可以（可能，MAY）,以及可選（OPTIONAL）,按參考文獻[2]解釋。中譯版本將對這些關鍵詞加粗并加上紅色突出顯示。
3.協議總述
PPPoE分為兩個階段，即Discovery（地址發現）階段和PPP會話階段。當某個主機希望發起一個PPPoE會話時，它必須首先執行Discovery來確定對方的以太網MAC地址并建立起一個PPPoE會話標識符SESSION_ID。雖然PPP定義的是端到端的對等關系，Discovery卻是天生的一種客戶端-服務器關系。在Discovery的過程中,主機(作為客戶端)發現某個訪問集中器（AccessConcentrator，作為服務器），根據網絡的拓撲結構，可能主機能夠跟不止一個的訪問集中器通信。Discovery階段允許主機發現所有的訪問集中器并從中選擇一個。當Discovery階段成功完成之后，主機和訪問集中器兩者都具備了用于在以太網上建立點到點連接所需的所有信息。
Discovery階段保持無狀態（stateless）直到建立起一個PPP會話。一旦PPP會話建立，主機和訪問集中器兩者都必須為一個PPP虛擬接口分配資源。
4.凈載數據
這里定義了下面所示的數據包格式。payload的內容將在Discovery和PPP的章節中描述。

以太網的幀格式如下所示:

0
1
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
DESTINATION_ADDR
（6個字節）
SOURCE_ADDR
（6個字節）
ETHER_TYPE(2個字節)

payload......
CHECKSUM

DESTINATION_ADDR域是一個以太網單播目的地址或者以太網廣播地址(0xffffffff)。對于Discovery數據包來說,該域的值是在Descovery章節中定義的單播或者多播地址。對于PPP會話流量來說，該域必須是Descovery階段已確定的通信對方的單播地址。
SOURCE_ADDR域必須包含源設備的以太網MAC地址。
ETHER_TYPE設置為0x8863(Discovery階段)或者0x8864(PPP會話階段)。

PPPoE的以太網payload如下所示:

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
VER
TYPE
CODE
SESSION_ID
LENGTH
payload......

VER域為4位，PPPoE規范的本版本必須設置為0x1。
TYPE域為4位，PPPoE規范的本版本必須設置為0x1。
CODE域為8位，其定義在后面的Discovery和PPP會話章節分別指定。
SESSION_ID域為16位，是一個網絡字節序的無符號值。其值在后面Discovery數據包中定義。對一個給定的PPP會話來說該值是一個固定值，并且與以太網SOURCE_ADDR和DESTINATION_ADDR一起實際地定義了一個PPP會話。值0xffff為將來的使用保留，不允許使用。
LENGTH域為16位。該值（網絡字節序）表明了PPPoE的payload長度。不包括以太網頭部和PPPoE頭部的長度。

5.Discovery階段
Discovery階段由4個步驟組成。完成之后通信雙方都知道了PPPoESESSION_ID以及對方以太網地址，它們共同定義了唯一的PPPoE會話。這些步驟包括：主機廣播一個（會話）發起數據包（以請求建立鏈路），一個或多個訪問集中器發送提供（服務）數據包，主機發送單播會話請求數據包以及選中的訪問集中器發送確認數據包。當主機接收到該確認數據包后，它就可以進入PPP會話階段。訪問集中器發送確認數據包后，它就可以進入到PPP會話階段。

Discovery階段所有的以太網幀的ETHER_TYPE域都設置為0x8863。

PPPoE的payload部分包含0個或多個TAG。一個TAG是一個TLV(type-length-value)結構，定義如下：


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
41
2
3
4
5
6
7
8
9
0
1
TAG_TYPE
TAG_LENGTH
TAG_VALUE......

TAG_TYPE域為16位值（網絡字節序），附錄A列出了各種TAG_TYPE和TAG_VALUE。
TAG_LENGTH域為16位，是無符號值（網絡字節序），表明TAG_VALUE的字節數。
如果收到的discovery數據包中包含未知的TAG_TYPE,則必須忽略掉該TAG，除非本文檔特別指出。這樣規定是為了在增加新的TAG時保持向后兼容。如果增加強制使用的TAG，則版本號(version)將會提高。

附錄B中有一些Discovery數據包的例子。

5.1PPPoEActiveDiscoveryInitiation數據包(PADI)
主機發送DESTINATION_ADDR為廣播地址的PADI數據包，CODE域設置為0x09,SESSION_ID域必須設置為0x0000。
PADI數據包必須包含且僅包含一個TAG_TYPE為Service-Name的TAG，以表明主機請求的服務，以及任意數目的其它類型的TAG。整個PADI數據包（包括PPPoE頭部）不允許超過1484個字節，以留足空間讓中繼代理（向數據包中）增加類型為Relay-Session-Id的TAG。
5.2ThePPPoEActiveDiscoveryOffer數據包(PADO)
如果訪問集中器能夠為收到的PADI請求提供服務，它將通過發送一個PADO數據包來做出應答。DESTINATION_ADDR為發送PADI的主機的單播地址，CODE域為0x07,SESSION_ID域必須設置為0x0000。
PADO數據包必須包含一個類型為AC-Name的TAG（包含了訪問集中器的名字），與PADI中相同的Service-Name，以及任意數目的類型為Service-Name的TAG表明訪問集中器提供的其它服務。如果訪問集中器不能為PADI提供服務，則不允許用PADO作響應。
5.3ThePPPoEActiveDiscoveryRequest數據包(PADR)
由于PADI是廣播的,主機可能收到不止一個PADO,它將審查接收到的所有PADO并從中選擇一個?？梢愿鶕渲械腁C-Name或PADO所提供的服務來作出選擇。然后主機向選中的訪問集中器發送一個PADR數據包。其中，DESTINATION_ADDR域設置為發送PADO的訪問集中器的單播地址，CODE域設置為0x19，SESSION_ID必須設置為0x0000。
PADR必須包含且僅包含一個TAG_TYPE為Service-Name的TAG，表明主機請求的服務，以及任意數目其他類型的TAG。
5.4ThePPPoEActiveDiscoverySession-confirmation數據包(PADS)
當訪問集中器收到一個PADR數據包，它就準備開始一個PPP會話。它為PPPoE會話創建一個唯一的SESSION_ID并用一個PADS數據包來給主機作出響應。DESTINATION_ADDR域為發送PADR數據包的主機的單播以太網地址，CODE域設置為0x65,SESSION_ID必須設置為所創建好的PPPoE會話標識符。
PADS數據包包含且僅包含一個TAG_TYPE為Service-Name的TAG，表明訪問集中器已經接受的該PPPoE會話的服務類型，以及任意數目的其他類型的TAG。
如果訪問集中器不喜歡PADR中的Service-Name,那么它必須用一個帶有類型為Service-Name-Error的TAG(以及任意數目的其它TAG類型)的PADS來作出應答。這種情況下，SESSION_ID必須設置為0x0000。
5.5ThePPPoEActiveDiscoveryTerminate數據包(PADT)
這種數據包可以在會話建立以后的任意時刻發送，表明PPPoE會話已經終止。它可以由主機或訪問集中器發送，DESTINATION_ADDR域為單播以太網地址，CODE域設置為0xa7,SESSION_ID必須表明終止的會話，這種數據包不需要任何TAG。
當收到PADT以后，就不允許再使用該會話發送PPP流量了。在發送或接收到PADT后，即使是常規的PPP結束數據包也不允許發送。PPP通信雙方應該使用PPP協議自身來結束PPPoE會話，但在無法使用PPP時可以使用PADT。
6.PPP會話階段
一旦PPPoE會話開始，PPP數據就像其它PPP封裝一樣發送。所有的以太網數據包都是單播的。ETHER_TYPE域設置為0x8864。PPPoE的CODE必須設置為0x00。PPPoE會話的SESSION_ID不允許發生改變，必須是Discovery階段所指定的值。PPPoE的payload包含一個PPP幀，幀始于PPPProtocol-ID。

附錄B中給出了數據包的一個實例。
7.LCP方面的考慮
推薦使用MagicNumberLCP配置選項，不推薦使用協議域壓縮（ProtocolFieldCompression，PFC）選項。不允許實現請求使用下面的任何一個選項，對此必須作出拒絕：

FieldCheckSequence(FCS)Alternatives,
Address-and-Control-Field-Compression(ACFC),
Asynchronous-Control-Character-Map(ACCM)
協商后（PPPoE）的最大接收單元(MRU)不允許超過1492。因為以太網的最大凈載為1500字節，而PPPoE頭部為6個字節，PPPProtocol-ID為2個字節，所以PPP的MTU不允許超過1492。

推薦訪問集中器不時向主機發送回聲請求（Echo-Request）數據包，以確定會話的狀態。否則如果主機在沒有發送結束請求（Terminate-Request）數據包的情況下終止會話，則訪問集中器將無法得知該會話已經“死去”。
當LCP結束的時候，主機和訪問集中器必須停止使用該PPPoE會話。如果主機希望開始另一個PPP會話，則它必須重新進入PPPoEDiscoverey階段。
8.其它方面的考慮
如果主機在一段指定時間內沒有收到PADO數據包，它應該重發其PADI數據包并把等待的間隔加倍。按所期望的次數重復這個動作。主機在等待接收PADS數據包時，應該采用類似的定時機制，只是主機重新發送的是PADR數據包。在重發指定次數后（還沒有收到PADO），主機應該重新發送PADI。
本文檔中的ETHER_TYPE（0x8863,0x8864）已經被IEEE指定專用于以太網上的PPP（PPPoE），使用這兩個值和PPPoEVER（版本）域將唯一標識本協議。

本文檔始終使用UTF-8（參考文獻[5]）而不是ASCII。UTF-8支持所有ASCII字符集同時允許國際字符集。參見參考文獻[5]。
9.安全方面的考慮
為了防止拒絕服務攻擊（DenialofService，簡稱DOS）,訪問集中器可以使用類型為AC-Cookie的TAG。訪問集中器應該能夠根據PADR的SOURCE_ADDR來重新產生具有唯一性的TAG_VALUE。使用這種方法，訪問集中器可以確保PADI的SOURCE_ADDR確實是可到達的，并對該地址的并行會話數進行限制。使用什么樣的算法并沒有指定，留給實現細節自己選擇。對主機MAC地址使用HMAC(參考文獻[3])就是一個例子，（在進行HMAC密碼散列時）使用的是僅有訪問集中器知道的密碼。雖然AC-Cookie對防止某些DOS有用，但它不能防止所有的DOS攻擊，訪問集中器可以使用其它的方法來保護。
很多訪問集中器不希望提供信息表明為未認證實體提供什么服務。在這種情況下，訪問集中器應該使用下面兩種策略之一：它應該根據請求中的Service-Name標簽不拒絕該請求，并返回收到的TAG_VALUE；或者應該僅接受帶有TAG_LENGTH為0（表明任意服務）的Service-Name標簽的請求。推薦使用前一種方案。
10.致謝
本文檔建立在幾個論壇所討論概念的基礎上，包括ADSL論壇。還從RFC1661,RFC1662以及RFC2364中借用了很多內容。
11.參考文獻
[1]Simpson,W.,Editor,“點到點協議（PPP）”,STD51,RFC1661,July1994
[2]Bradner,S.,“RFC中表明條件級別的關鍵詞”,BCP14,RFC2119,March1997.
[3]Krawczyk,H.,Bellare,M.andR.Canetti,“HMAC:消息認證的密鑰散列”,RFC2104,February1998.
[4]Reynolds,J.andJ.Postel,“指定值”,STD2,RFC1700,October1994.參見:http://www.iana.org/numbers.html
[5]Yergeau,F.,“UTF-8,ISO10646的一種轉換”,RFC2279,January1998.
附錄A
TAG_TYPE和TAG_VALUE
0x0000End-Of-List
該TAG表明表中沒有其它TAG了。該TAG的TAG_LENGTH必須總是0。不要求使用該標簽，存在是為了向后兼容。
0x0101Service-Name
該TAG表明后面緊跟的是服務的名稱。TAG_VALUE是不以NULL結束的UTF-8字符串。當TAG_LENGTH為0時，該TAG用于表明接受任何服務。使用Service-Name標簽的例子是表明ISP(Internet服務提供商)或者一類服務或者服務的質量。
0x0102AC-Name
該TAG表明后面緊跟的字符串唯一地表示了某個特定的訪問集中器。它可以是商標、型號以及序列號等信息的集合，或者該訪問集中器MAC地址的一個簡單的UTF-8表示。它不以NULL來結束。
0x0103Host-Uniq
該TAG由主機用于把訪問集中器的響應（PADO或者PADS）與主機的某個唯一特定的請求聯系起來。TAG_VALUE是主機選擇的長度和值為任意的二進制數據。它不能由訪問集中器解釋。主機可以在PADI或者PADR中包含一個Host-Uniq標簽。如果訪問集中器收到了該標簽，它必須在對應的PADO或者PADS中不加改變的包含該標簽。
0x0104AC-Cookie
該TAG由訪問集中器用于防止拒絕服務攻擊（見“安全方面的考慮”）。訪問集中器可以在PADO數據包中包含該TAG。如果主機收到了該標簽，它必須在接下來的PADR中不加改變的包含該標簽。TAG_VALUEI是長度和值任意的二進制數據，不能由主機解釋。
0x0105Vendor-Specific
該TAG用來傳送廠商自定義的信息。TAG_VALUE的頭4個字節包含了廠商的識別碼，其余字節尚未定義。廠商識別碼的高字節為0，低3個字節為網絡字節序的廠商的SMI網絡管理專用企業碼，如“定義值RFC”（參考文獻[4]）中定義的那樣。
不推薦使用該TAG。為了確?；ゲ僮餍?，實現可以悄悄的忽略Vendor-SpecificTAG。
0x0110Relay-Session-Id
該TAG可由中繼流量的中間代理加入到Discovery數據包中。TAG_VALUE對主機和訪問集中器都是晦澀難懂的（paque）。如果主機或訪問集中器收到該TAG，則它們必須在所有的Discovery數據包中包含該TAG以作為響應。所有的PADI數據包必須保證足夠空間來加入TAG_VALUE長度為12字節的Relay-Session-Id標簽。
如果Discovery數據包中已經包含一個Relay-Session-Id標簽，則不允許再加入該標簽。這種情況下，中間代理應該使用該現有的Relay-Session-Id標簽。如果它不能使用現有的標簽，或者沒有足夠空間來增加一個Relay-Session-Id標簽,那么它應該向發送者返回一個Generic-Error標簽。
0x0201Service-Name-Error
該TAG(典型的有一個長度為零的數據部分)表明了由于某種原因，沒有理睬所請求的Service-Name。如果有數據部分,并且數據部分的頭一個字節非0，那么它必須是一個可打印的UTF-8字符串，解釋請求被拒絕的原因。該字符串可以不以NULL結束。
0x0202AC-System-Error
該TAG表明了訪問集中器在處理主機請求時出現了某個錯誤。(例如沒有足夠資源來創建一個虛擬電路。PADS數據包中可以包含該標簽。
如果有數據，并且數據的第一個字節不為0，那么（數據）必須是一個可打印的UTF-8字符串，該字符串解釋了錯誤的性質。該字符串可以不以NULL結束。
0x0203Generic-Error
該TAG表明發生了一個錯誤。當發生一個不可恢復的錯誤并且沒有其它合適的TAG時，它可被加到PADO,PADR或PADS數據包中。如果出現數據部分，那么數據必須是一個UTF-8字符串，解釋錯誤的性質。該字符串不允許以NULL結束。
附錄B
下面是數據包的幾個例子：
PADI數據包:

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
0xffffffff
0xffff
Host_mac_addr
Host_mac_addr(續)
ETHER_TYPE=0x8863
v=1
t=1
CODE=0x09
SESSION_ID=0x0000
LENGTH=0x0004
TAG_TYPE=0x0101
TAG_LENGTH=0x0000

PADO數據包:

0
1
2
3
1
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
Host_mac_addr
Host_mac_addr（續）
Access_Concentrator_mac_addr
Access_Concentrator_mac_addr(續)
ETHER_TYPE=0x8863
v=1
t=1
CODE=0x07
SESSION_ID=0x0000
LENGTH=0x0020
TAG_TYPE=0x0101
TAG_LENGTH=0x0000
0x47
0x6f
0x20
0x52
0x65
0x64
0x42
0x61
0x63
0x6b
0x20
0x2d
0x20
0x65
0x73
0x68
0x73
0x68
0x65
0x73
0x68
0x6f
0x6f
0x74


PPPLCP數據包:顯示了PPPprotocol的值(0xc021)，但是PPP的凈載數據留給讀者。這是一個從主機發給訪問集中器的數據包。
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
Access_Concentrator_mac_addr
Access_Concentrator_mac_addr(c)
Host_mac_addr
Host_mac_addr(cont)
ETHER_TYPE=0x8864
v=1
t=1
CODE=0x00
SESSION_ID=0x1234
LENGTH=0x????
PPPPROTOCOL=0xc021
PPPpayload......

作者地址
LouisMamakos
UUNETTechnologies,Inc.
3060WilliamsDrive
Fairfax,VA22031-4648
UnitedStatesofAmerica
EMail:louie@uu.net

KurtLidl
UUNETTechnologies,Inc.
3060WilliamsDrive
Fairfax,VA22031-4648
UnitedStatesofAmerica
EMail:lidl@uu.net

JeffEvarts
UUNETTechnologies,Inc.
3060WilliamsDrive
Fairfax,VA22031-4648
UnitedStatesofAmerica
EMail:jde@uu.net

DavidCarrel
RedBackNetworks,Inc.
1389MoffettParkDrive
Sunnyvale,CA94089-1134
UnitedStatesofAmerica
EMail:carrel@RedBack.net

DanSimone
RedBackNetworks,Inc.
1389MoffettParkDrive
Sunnyvale,CA94089-1134
UnitedStatesofAmerica
EMail:dan@RedBack.net

RossWheeler
RouterWare,Inc.
3961MacArthurBlvd.,Suite212
NewportBeach,CA92660
UnitedStatesofAmerica
EMail:ross@routerware.com
完整的版權通告
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.