本備忘錄狀態(tài)
ThismemoPRovidesinformationfortheInternetcommunity.Itdoes
notspecifyanInternetstandardofanykind.Distributionofthis
memoisunlimited.
版權(quán)聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
摘要
點(diǎn)到點(diǎn)協(xié)議(PPP，參考文獻(xiàn)[1])提供在點(diǎn)到點(diǎn)連路上傳送多協(xié)議數(shù)據(jù)報(bào)的標(biāo)準(zhǔn)方法。
本文檔描述在以太網(wǎng)上建立PPP會(huì)話以及封裝PPP數(shù)據(jù)報(bào)的方法。

可行性
本說(shuō)明書(shū)試圖提供PPP所定義的工具，如鏈路控制協(xié)議(LinkControlProtocol,LCP),網(wǎng)絡(luò)層控制協(xié)議（Network-layerControlProtocols,NCP）,認(rèn)證以及其它機(jī)制。這些功能要求在通信雙方之間存在點(diǎn)到點(diǎn)的關(guān)系，而不是在以太網(wǎng)和其他多訪問(wèn)環(huán)境中所出現(xiàn)的多點(diǎn)關(guān)系。
本規(guī)范可用于同一個(gè)以太網(wǎng)上的多個(gè)主機(jī)通過(guò)一個(gè)或多個(gè)跨接（橋接）的調(diào)制解調(diào)器向多個(gè)目的主機(jī)開(kāi)放其PPP會(huì)話。主要用于寬帶遠(yuǎn)程訪問(wèn)技術(shù)，即訪問(wèn)服務(wù)的提供者希望通過(guò)提供一個(gè)橋接的拓?fù)浣Y(jié)構(gòu)從而保持PPP會(huì)話摘要。
本文檔描述的PPPoE是RedBackNetworks,RouterWare,UUNET及其它廠商所采用的在以太網(wǎng)上封裝PPP的方法。

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

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

以太網(wǎng)的幀格式如下所示:

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

payload......
CHECKSUM

DESTINATION_ADDR域是一個(gè)以太網(wǎng)單播目的地址或者以太網(wǎng)廣播地址(0xffffffff)。對(duì)于Discovery數(shù)據(jù)包來(lái)說(shuō),該域的值是在Descovery章節(jié)中定義的單播或者多播地址。對(duì)于PPP會(huì)話流量來(lái)說(shuō)，該域必須是Descovery階段已確定的通信對(duì)方的單播地址。
SOURCE_ADDR域必須包含源設(shè)備的以太網(wǎng)MAC地址。
ETHER_TYPE設(shè)置為0x8863(Discovery階段)或者0x8864(PPP會(huì)話階段)。

PPPoE的以太網(wǎng)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域?yàn)?位，PPPoE規(guī)范的本版本必須設(shè)置為0x1。
TYPE域?yàn)?位，PPPoE規(guī)范的本版本必須設(shè)置為0x1。
CODE域?yàn)?位，其定義在后面的Discovery和PPP會(huì)話章節(jié)分別指定。
SESSION_ID域?yàn)?6位，是一個(gè)網(wǎng)絡(luò)字節(jié)序的無(wú)符號(hào)值。其值在后面Discovery數(shù)據(jù)包中定義。對(duì)一個(gè)給定的PPP會(huì)話來(lái)說(shuō)該值是一個(gè)固定值，并且與以太網(wǎng)SOURCE_ADDR和DESTINATION_ADDR一起實(shí)際地定義了一個(gè)PPP會(huì)話。值0xffff為將來(lái)的使用保留，不答應(yīng)使用。
LENGTH域?yàn)?6位。該值（網(wǎng)絡(luò)字節(jié)序）表明了PPPoE的payload長(zhǎng)度。不包括以太網(wǎng)頭部和PPPoE頭部的長(zhǎng)度。

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

Discovery階段所有的以太網(wǎng)幀的ETHER_TYPE域都設(shè)置為0x8863。

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


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域?yàn)?6位值（網(wǎng)絡(luò)字節(jié)序），附錄A列出了各種TAG_TYPE和TAG_VALUE。
TAG_LENGTH域?yàn)?6位，是無(wú)符號(hào)值（網(wǎng)絡(luò)字節(jié)序），表明TAG_VALUE的字節(jié)數(shù)。
假如收到的discovery數(shù)據(jù)包中包含未知的TAG_TYPE,則必須忽略掉該TAG，除非本文檔非凡指出。這樣規(guī)定是為了在增加新的TAG時(shí)保持向后兼容。假如增加強(qiáng)制使用的TAG，則版本號(hào)(version)將會(huì)提高。

附錄B中有一些Discovery數(shù)據(jù)包的例子。

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

附錄B中給出了數(shù)據(jù)包的一個(gè)實(shí)例。
7.LCP方面的考慮
推薦使用MagicNumberLCP配置選項(xiàng)，不推薦使用協(xié)議域壓縮（ProtocolFieldCompression，PFC）選項(xiàng)。不答應(yīng)實(shí)現(xiàn)請(qǐng)求使用下面的任何一個(gè)選項(xiàng)，對(duì)此必須作出拒絕：

FieldCheckSequence(FCS)Alternatives,
Address-and-Control-Field-Compression(ACFC),
Asynchronous-Control-Character-Map(ACCM)
協(xié)商后（PPPoE）的最大接收單元(MRU)不答應(yīng)超過(guò)1492。因?yàn)橐蕴W(wǎng)的最大凈載為1500字節(jié)，而PPPoE頭部為6個(gè)字節(jié)，PPPProtocol-ID為2個(gè)字節(jié)，所以PPP的MTU不答應(yīng)超過(guò)1492。

推薦訪問(wèn)集中器不時(shí)向主機(jī)發(fā)送回聲請(qǐng)求（Echo-Request）數(shù)據(jù)包，以確定會(huì)話的狀態(tài)。否則假如主機(jī)在沒(méi)有發(fā)送結(jié)束請(qǐng)求（Terminate-Request）數(shù)據(jù)包的情況下終止會(huì)話，則訪問(wèn)集中器將無(wú)法得知該會(huì)話已經(jīng)“死去”。
當(dāng)LCP結(jié)束的時(shí)候，主機(jī)和訪問(wèn)集中器必須停止使用該P(yáng)PPoE會(huì)話。假如主機(jī)希望開(kāi)始另一個(gè)PPP會(huì)話，則它必須重新進(jìn)入PPPoEDiscoverey階段。
8.其它方面的考慮
假如主機(jī)在一段指定時(shí)間內(nèi)沒(méi)有收到PADO數(shù)據(jù)包，它應(yīng)該重發(fā)其PADI數(shù)據(jù)包并把等待的間隔加倍。按所期望的次數(shù)重復(fù)這個(gè)動(dòng)作。主機(jī)在等待接收PADS數(shù)據(jù)包時(shí)，應(yīng)該采用類(lèi)似的定時(shí)機(jī)制，只是主機(jī)重新發(fā)送的是PADR數(shù)據(jù)包。在重發(fā)指定次數(shù)后（還沒(méi)有收到PADO），主機(jī)應(yīng)該重新發(fā)送PADI。
本文檔中的ETHER_TYPE（0x8863,0x8864）已經(jīng)被IEEE指定專(zhuān)用于以太網(wǎng)上的PPP（PPPoE），使用這兩個(gè)值和PPPoEVER（版本）域?qū)⑽ㄒ粯?biāo)識(shí)本協(xié)議。

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

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

PADO數(shù)據(jù)包:

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（續(xù)）
Access_Concentrator_mac_addr
Access_Concentrator_mac_addr(續(xù))
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數(shù)據(jù)包:顯示了PPPprotocol的值(0xc021)，但是PPP的凈載數(shù)據(jù)留給讀者。這是一個(gè)從主機(jī)發(fā)給訪問(wèn)集中器的數(shù)據(jù)包。
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
完整的版權(quán)通告
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.