PPPoE协议RFC+2516.docx

上传人:b****4 文档编号:11914824 上传时间:2023-04-16 格式:DOCX 页数:20 大小:24.72KB
下载 相关 举报
PPPoE协议RFC+2516.docx_第1页
第1页 / 共20页
PPPoE协议RFC+2516.docx_第2页
第2页 / 共20页
PPPoE协议RFC+2516.docx_第3页
第3页 / 共20页
PPPoE协议RFC+2516.docx_第4页
第4页 / 共20页
PPPoE协议RFC+2516.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

PPPoE协议RFC+2516.docx

《PPPoE协议RFC+2516.docx》由会员分享,可在线阅读,更多相关《PPPoE协议RFC+2516.docx(20页珍藏版)》请在冰豆网上搜索。

PPPoE协议RFC+2516.docx

PPPoE协议RFC+2516

NetworkWorkingGroupL.Mamakos

RequestforComments:

2516K.Lidl

Category:

InformationalJ.Evarts

UUNETTechnologies,Inc.

D.Carrel

D.Simone

RedBackNetworks,Inc.

R.Wheeler

RouterWare,Inc.

February1999

 

AMethodforTransmittingPPPOverEthernet(PPPoE)

本备忘录的状态

本备忘录为因特网社区提供信息。

它不指定任务类型的因特网标准。

允许任意分发本备忘录。

版权通告

Copyright(C)TheInternetSociety(1999).保留所有权利。

摘要

点对点协议(PPP)[1]提供了在点对点连接上传输多种协议报文的标准方法。

适用性

本规格说明书意图提供用于定义PPP的资源,例如链路控制协议(LinkControlProtocol)、网络层控制协议(Network-layerControlProtocol)、认证(authentication),等等。

这些能力需要端与端之间的点对点关系,而不是用于已在以太网及其他多点访问环境中使用的多点关系。

本规格说明书可以用于多个主机,这些主机在共享的、用于开放的PPP会话的以太网,并且通过一个或者更多的桥接调制解调器而抵达多个目标地址。

它试图用于提供桥接以太网拓扑的宽带远程访问技术,并且当访问提供者希望维持与PPP相关的、抽象的会话时。

本文档描述了在以太网上包装的PPP,它已经被RedBack网络、RouterWare、UUNET及其他机构使用。

 

1、介绍

Modem接入技术面临一些相互矛盾的目标,既要通过同一个用户前置接入设备连接远程的多个用户主机,又要提供类似拨号一样的接入控制,计费等功能。

在许多接入技术中,对于用户而言,访问多主机最有效的方式所依赖的接入设备,是通过以太网。

另外,值得注意的是,在尽可能少的配置下,要尽可能低地保持设备的成本。

在以太网上的PPP(PPPoE)提供了通过简单的桥接访问设备到远程访问集中器来连接主机网络的能力。

在这个模型下,每个主机利用它自己的PPP栈,给用户类似的用户界面。

基本而言,访问控制、计费以及服务类型可以逐用户的完成,而不是逐站点完成。

为了在以太网上提供点对点连接,每个PPP会话必须学习远端的以太网地址,同时建立一个唯一的会话标识符。

PPPoE包的的发现协议提供了这个功能。

2、约定

以下关键字:

必须,必须不,需要的,应该,应该不,推荐,可能,可选的,当它们出现在这个文档中时,将如[2]中描述的那样解释。

3、协议概述

PPPoE有两个截然不同的阶段,即发现阶段(Discoverystage)及PPP会话阶段(PPPSessionstage)。

当一个主机希望初始化一个PPPoE会话,它必须首先执行发现阶段去标识对方的以太MAC地址并且建立一个PPPoE会话标识符(SESSION_ID)。

当PPP定义了一个端对端关系时,发现阶段也同时建立了一个客户端-服务器关系。

在发现过程中,一个主机(客户端)发现了一个访问集中器(服务器)。

基于这个网络拓扑,该主机可能有不止一个可以通信的访问集中器。

发现阶段允许该主机发现所有的访问集中器,然后选择使用其中一个。

当发现阶段成功结束时,该主机与被选择的访问集中器都拥有将用于建立它们之间在以太网上的点对点连接的信息。

发现阶段将保持无状态,直到PPP会话被建立起来。

一当PPP会话被建立起来,主机和访问集中器必须为PPP虚拟接口分配资源。

4、有效载荷(payload)

定义以下包格式。

其中有效载荷的内容将在发现阶段及PPP节定义。

一个以太帧如下所示:

1

0123456789012345

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|目标地址|

|(6octets)|

||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|源地址|

|(6octets)|

||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|以太包类型(2octets)|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~~

~有效载荷~

~~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|校验码|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

目标地址(DESTINATION_ADDR)域或者是单播的以太网目标地址,或者是以太网广播地址(0xffffffff)。

对于发现帧而言,这个值或者是单播地址,或者是广播地址,就如在发现一节中所描述的一样。

对于PPP会话通信,这个域必须包含对方的单播地址,该地址由发现阶段决定。

源地址(SOURCE_ADDR)域必须包含源设备的以太MAC地址。

以太包类型(ETHER_TYPE)被设备为0x8863(发现阶段)或者0x8864(PPP会话阶段)。

PPPoE的以太有效载荷如下所示:

123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|VER|TYPE|CODE|SESSION_ID|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|LENGTH|payload~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VER域占用4位,对于本版本的PPPoE规格说明书,必须设置为0x1。

TYPE域占用4位,对于本版本的PPPoE规格说明书,必须设置为0x1。

CODE域占用8位,对于发现阶段和PPP会话阶段,它的定义稍后再做描述。

SESSION_ID域占用16位。

这是一个网络字节顺序的无符号数值。

它的值在发现包中给出。

对于给定的PPP会话,这个值是固定的,并且,事实上,它与以太网源地址和目标地址一起定义了一个PPP会话。

0xffff是保留值,可能在将来会被使用,但现在必须不能使用。

LENGTH域占用16位。

这个网络字节顺序的值,指出PPPoE有效载荷的长度。

它不包括以太包及PPPoE包头。

5、发现阶段

在发现阶段有4个步骤。

当它完成时,两端都将知道PPPoE的会话ID及对方的以太网址,而且它们一起唯一标识了PPPoE会话。

这些步骤包括:

主机广播一个初始(Initiation)包,一个或者多个访问集中器发送提议(Offer)包,主机发送一个单播会话请求(SessionRequest)包,被选择的访问集中器发送一个确认(Confirmation)包。

当主机接收到这个确认包时,它就可以进入到PPP会话阶段了。

当访问集中器发送了确认包以后,它就可以进入到PPP会话阶段了。

所有的发现阶段的以太帧,都要将ETHER_TYPE域的值设置为0x8863。

PPPoE有效载荷可以包含一个或者多个标签(TAG)。

一个标签是一个TLV(type-length-value,类型-长度-值)的结构,它的定义如下所示:

 

123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|TAG_TYPE|TAG_LENGTH|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|TAG_VALUE...~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TAG_TYPE域占用16位,使用网络字节顺序。

附录A包含了所有的标签类型(TAG_TYPE)及它们的标签值(TAG_VALUE)。

TAG_LENGTH域占用16位,它是网络字节顺序的无符号数值,指出标签值的所使用的字节(8位)数。

如果发现包接收到一个未知类型的标签,该标签必须被忽略,除非在本文件中另外指定。

这样可以在新增加了标签时提供向后兼容。

如果增加了新的强制性的标签,则版本号也将随之增加。

附录B中给出了一个发现包的例子。

5.1、PPPoE活动发现初始(PADI)包

主机发送PADI(PPPoEActiveDiscoveryInitiation)包,此时目标地址被设置为广播地址。

CODE域设置为0x09,同时,SESSION_ID必须被设置为0x0000。

PADI包必须包含正确的、类型为服务名称(Service-Name)的标签,用于指出主机正在请求的服务。

也可以包含任意数量的其他标签类型。

整个PADI包(包括PPPoE包头),必须不超过1484字节(8位),以便有足够的空间用于中继代理增加中继会话ID(Relay-Session-Id)标签。

5.2、PPPoE活动发现提议(PADO)包

当访问集中器接收到它可以提供服务的PADI包,它通过发送一个PADO(PPPoEActiveDiscoveryOffer)包来响应。

目标地址是发送PADI的主机的单播地址。

CODE域被设置为0x07,同时,SESSION_ID必须被设置为0x0000。

PADO包必须包含一个AC名称(AC-Name)标签,其中有访问集中器的名称;同时,必须包含一个服务名称(Service-Name)标签来标识PADI中的服务名称,同时可以包含任意数量的其他服务名称(Service-Name)标签来指出该访问集中器提供的其他服务。

如果该访问集中器不能为这个PADI包提供服务,则它必须不能用PADO做出应答。

5.3、PPPoE活动发现请求(PADR)包

因为PADI是广播包,所以主机可能接收到多个PADO。

主机需要审核这些PADO包,并且从中选择一个。

这个选择可以基于所提供的AC名称(AC-Name)或者服务。

然后,主机发送PADR(PPPoEActiveDiscoveryRequest)包给被选中的访问集中器。

目标地址被设置为这个发送PADO的访问集中器的单播以太网地址。

CODE域被设置为0x19,同时,SESSION_ID必须被设置为0x0000。

PADR包必须包含一个正确的服务名称(Service-Name)标签,该标签指出主机所请求的服务。

同时可以包含任意数量的其他标签。

5.4、PPPoE活动发现会话确认(PADS)包

当访问集中器接收到PADR包时,它开始准备开始一个PPP会话。

它为PPPoE会话创建一个唯一的会话ID(SESSION_ID),并用PADS(PPPoEActiveDiscoverySession-confirmation)包回复给主机。

目标地址域设置为发送PADR的主机的单播以太网地址。

CODE域设置为0x65,同时,SESSION_ID必须设置为刚为本次PPPoE会话创建的唯一值。

PADS包包含一个正确的服务名称(Service-Name)标签,该标签指出这个接收了PPPoE会话的访问集中器的服务。

同时可以包含任意数量的其他标签。

如果访问集中器不喜欢PADR中的服务名称,则它必须在回复的PADS中包含服务名称错误(Service-Name-Error)标签(以及任意数量的其他标签)。

这时,SESSION_ID必须被设置为0x0000。

5.5、PPPoE活动发现终止(PADT)包

这个包可以在会话建立之后的任意时刻发送,用于指出这个PPPoE会话已经被终止。

主机或者访问集中器都可以发送这个包。

目标地址被设置为单播以太网地址,CODE域被设置为0xa7,SESSION_IDMUST必须设置为将被终止的会话的ID。

这个包不需要任何标签。

 

当接收到一个PADT(PPPoEActiveDiscoveryTerminate)时,任何使用该会话的PPP通信都是不允许的。

在发送或者接收到一个PADT后,即使正常的PPP终止包也必须不再被发送。

PPP端应该使用PPP协议本身来关闭一个PPPoE会话,但PADT可以用于PPP不能使用的情况。

6、PPP会话阶段

一当PPPoE会话开始以后,PPP数据就象任何其他PPP封闭一样被发送。

所有的以太包都是单播的。

ETHER_TYPE域被设置为0x8864。

PPPoE的CODE必须被设置为0x00。

对于这个PPPoE会话,SESSION_ID必须不能被改变,并且必须是发现阶段指定的值。

PPPoE有效载荷包含一个PPP帧。

该帧以PPP协议ID开头。

附录B中给出了一个包的例子。

7、LCP考虑

魔数LCP规则说明选项是被推荐的,而协议域压缩(PFC,ProtocolFieldCompression)选项则是不推荐的。

它的实现必须不请求以下任意的选项,并且,必须拒绝这些选项:

FieldCheckSequence(FCS)Alternatives,

Address-and-Control-Field-Compression(ACFC),

Asynchronous-Control-Character-Map(ACCM)

最大接收单元(MRU,Maximum-Receive-Unit)选项必须不超过1492。

因为以太网有1500字节(8位)的最大有效载荷限制,而PPPoE头有6字节(8位)并且PPP协议ID包含2字节(8位),所以,PPP的MTU必须不超过1492。

推荐访问集中器不定期的发送回音请求(Echo-Request)包给主机,以此决定这个会话的状态。

否则,如果主机不发送终止请求(Terminate-Request)包即终止一个会话,访问集中器将不能判断这个会话是否已经过时。

当LCP终止时,主机和访问集中器必须停止使用这个PPPoE会话。

如果主机希望开始另一个PPP会话,它必须返回到PPPoE发现阶段。

8、其他考虑

当主机在指定超时范畴内没有接收到PADO包,这应该重新发送它的PADI包,并且让等待时间加倍。

它可以重复所需要的任意多次。

如果主机正在等待接收一个PADS包,应该使用类似的超时机制,并且主机重发那个PADR。

当重试指定次数以后,主机应该重新发送PADI包。

本文档中使用的ETHER_TYPE(0x8863和0x8864)已经被IEEE指定用于在以太网上的PPP(PPPoE)。

同时使用这些值以及PPPoEVER(版本)域将唯一标识该协议。

本文档通篇使用UTF-8[5],而不是ASCII。

UTF-8支持整个ASCII字符集,同时也支持国际字符集。

更多细节请参见[5]。

9、安全考虑

为了帮助避免遭受拒绝服务(DOS)攻击,访问集中器可以使用AC-Cookie标签。

访问集中器应该能够唯一的根据PADR源地址重新生成这个标签值。

通过它,访问集中器可以确保PADI源地址确实可以到达,并且可以限制来自于这个地址的并发的会话数。

不要求具体使用哪一种算法,并且该算法被当作具体的实现细节。

一个例子是在主机MAC地址基础上使用只有访问集中器知道的密钥的HMAC[3]算法。

虽然AC-Cookie对于避免某些DOS攻击很有效,但它不能避免所有的DOS攻击,所以,访问集中器应该使用其他的手段来保护资源。

许多访问集中器可能不希望向未经论证的实体提供它们所能支持的服务的信息。

这种情况下,这个访问集中器应该采用以下两种策略之一。

它应当永远都不拒绝基于服务名称标签的请求,并且这个标签值总是返回它所接收的值。

或者,它应当只接收TAG_LENGTH等于0的服务名称标签的请求(表示任意服务)。

推荐使用前一种解决方式。

10、感谢

本文档基于若干个论坛中讨论的概念,其中包括ADSL论坛。

大量文本直接来自于RFC1661,RFC1662以及RFC2364。

11、参考资料

[1]Simpson,W.,Editor,"ThePoint-to-PointProtocol(PPP)",STD51,

RFC1661,July1994

[2]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement

Levels",BCP14,RFC2119,March1997.

[3]Krawczyk,H.,Bellare,M.andR.Canetti,"HMAC:

Keyed-Hashing

forMessageAuthentication",RFC2104,February1998.

[4]Reynolds,J.andJ.Postel,"AssignedNumbers",STD2,RFC1700,

October1994.Seealso:

http:

//www.iana.org/numbers.html

[5]Yergeau,F.,"UTF-8,atransformationformatofISO10646",RFC

2279,January1998.

 

AppendixA

TAG_TYPESandTAG_VALUES

0x0000End-Of-List

这个标签指出,在列表中不再有其他的标签。

这个标签的TAG_LENGTH必须总是等于0。

不要求必须使用这个标签,保留这个标签是为了保持向后兼容。

0x0101Service-Name

ThisTAGindicatesthataservicenamefollows.TheTAG_VALUEis

anUTF-8stringthatisNOTNULLterminated.WhentheTAG_LENGTH

iszerothisTAGisusedtoindicatethatanyserviceis

acceptable.ExamplesoftheuseoftheService-NameTAGareto

indicateanISPnameoraclassorqualityofservice.

0x0102AC-Name

ThisTAGindicatesthatastringfollowswhichuniquelyidentifies

thisparticularAccessConcentratorunitfromallothers.Itmay

beacombinationoftrademark,model,andserialidinformation,

orsimplyanUTF-8renditionoftheMACaddressofthebox.Itis

notNULLterminated.

0x0103Host-Uniq

ThisTAGisusedbyaHosttouniquelyassociateanAccess

Concentratorresponse(PADOorPADS)toaparticularHostrequest

(PADIorPADR).TheTAG_VALUEisbinarydataofanyvalueand

lengththattheHostchooses.ItisnotinterpretedbytheAccess

Concentrator.TheHostMAYincludeaHost-UniqTAGinaPADIor

PADR.IftheAccessConcentratorreceivesthisTAG,itMUST

includetheTAGunmodifiedintheassociatedPADOorPADS

response.

0x0104AC-Cookie

ThisTAGisusedbytheAccessConcentratortoaidinprotecting

againstdenialofserviceattacks(seetheSecurityConsiderations

sectionforanexplanationofhowthisworks).TheAccess

ConcentratorMAYincludethisTAGinaPADOpacket.IfaHost

receivesthisTAG,itMUSTreturntheTAGunmodifiedinthe

followingPADR.TheTAG_VALUEisbinarydataofanyvalueand

lengthandisnotinterpretedbytheHost.

 

0x0105Vendor-Specific

ThisTAGisusedtopassvendorproprietaryinformation.The

firstfouroctetsoftheTAG_VALUEcontainthevendoridandthe

remainderisunspecified.Thehigh-orderoctetofthevendorid

is0andthelow-order3octetsaretheSMINetworkManagement

PrivateEnterpriseCodeoftheVendorinnetworkbyteorder,as

definedintheAssignedNumbersRFC[4].

UseofthisTAGisNOTRECOMMENDED.Toensureinter-operability,

animplementationMAYsilentlyignoreaVendor-SpecificTAG.

0x0110Relay-Session-Id

ThisTAGMAYbeaddedtoanydiscoverypacketbyanintermediate

agentthatisrelayingtraffic.TheTAG_VALUEisopaquetoboth

theHostandthe

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1