1 / 34
文档名称:

pppoe原理协议详解.docx

格式:docx   大小:3,918KB   页数:34页
下载后只包含 1 个 DOCX 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

pppoe原理协议详解.docx

上传人:才艺人生 2024/5/10 文件大小:3.83 MB

下载得到文件列表

pppoe原理协议详解.docx

相关文档

文档介绍

文档介绍:该【pppoe原理协议详解 】是由【才艺人生】上传分享,文档一共【34】页,该文档可以免费在线阅读,需要了解更多关于【pppoe原理协议详解 】的内容,可以使用淘豆网的站内搜索功能,选择自己适合的文档,以下文字是截取该文章内的部分文字,如需要获得完整电子版,请下载此文档到您的设备,方便您编辑和打印。pppoe原理协议详解PPPoE(,基于以太网的点对点协议)的工作流程包含发现(Discovery)和会话(Session)两个阶段,发现阶段是无状态的,目的是获得PPPoE终端(在局端的ADSL设备上)的以太网MAC地址,并建立一个惟一的PPPoESESSION-ID。发现阶段结束后,(PPPoED:PPPoEDiscovery)(PPPoEActiveDiscoveryInitiation)主机广播发起分组,分组的目的地址为以太网的广播地址0xffffffffffff,CODE(代码)字段值为0×09(PADICode),SESSION-ID(会话ID)字段值为0x0000。PADI分组必须至少包含一个服务名称类型的标签(ServiceNameTag,字段值为0x0101),向接入集中器提出所要求提供的服务。(PPPoEActiveDiscoveryOffer)接入集中器收到在服务范围内的PADI分组,发送PPPoE有效发现提供包分组,以响应请求。其接入集中器收到PADR分组后准备开始PPP会话,它发送一个PPPoE有效发现会话确认PADS分组。其中CODE字段值为0×65(PADSCode),SESSION-ID字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。PADS分组也必须包含一个接入集中器名称类型的标签以确认向主机提供的服务。当主机收到PADS分组确认后,双方就进入PPP会话阶段。PADS和PADR的Host-UniqTag值相同。(PPPoES:PPPoESession)PPP会话的建立,需要两端的设备都发送LCP数据包来配置和测试数据通信链路。用户主机与接入集中器根据在发现阶段所协商的PPP会话连接参数进行PPP会话。一旦PPPoE会话开始,PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。PPPoE会话的SESSION-ID一定不能改变,并且必须是发现阶段分配的值。(LCP:LinkControlProtocol)LCP的Request主机和AC都要给对方发送,LCP协商阶段完成最大传输单元(MTU),是否进行认证和采用何种认证方式(AuthenticationType)的协商。(1)LCP协议数据报文分类链路配置报文:用来建立和配置一条链路,主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject报文链路维护报文:用来管理和调试链路,主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request报文链路终止报文:用来终止一条链路,主要包括Terminate-Request和Terminate-Reply报文(2)LCP协商过程LCP协商的过程如下:协商双方互相发送一个LCPConfig-Request报文,确认收到的Config-Request报文中的协商选项,根据这些选项的支持与接受情况,做出适当的回应。若两端都回应了Config-ACK,则标志LCP链路建立成功,否则会继续发送Request报文,直到对端回应了ACK报文为止。说明:(1)Config-ACK:若完全支持对端的LCP选项,则回应Config-ACK报文,报文中必须完全携带对端Request报文中的选项。(2)Config-NAK:若支持对端的协商选项,但不认可该项协商的内容,则回应Config-NAK报文,在Config-NAK的选项中填上自己期望的内容,如:对端MRU值为1500,而自己期望MRU值为1492,则在Config-NAK报文中埴上自己的期望值1492。(3)Config-Reject:若不能支持对端的协商选项,则回应Config-Reject报文,报文中带上不能支持的选项,如Windows拨号器会协商CBCP(被叫回呼),而ME60不支持CBCP功能,则回将此选项拒绝掉。(PPPAuthentication:PAP/CHAP)会话双方通过LCP协商好的认证方法进行认证,如果认证通过了,才可以进行下面的网络层的协商。认证过程在链路协商结束后就进行。ⅠPAP(PasswordAuthenticationProtocol,口令认证协议)认证PAP为两次握手协议,它通过用户名及口令来对用户进行验证。PAP验证过程如下:当两端链路可相互传输数据时,被验证方发送本端的用户名及口令到验证方,验证方根据本端的用户表(或Radius服务器)查看是否有此用户,口令是否正确。如正确则会给对端发送Authenticate-ACK报文,通告对端已被允许进入下一阶段协商;否则发送NAK报文,通告对端验证失败。此时,并不会直接将链路关闭。只有当验证不过次数达到一定值(缺省为10)时,才会关闭链路。PAP的特点是在网络上以明文的方式传递用户名及口令,如在传输过程中被截获,便有可能对网络安全造成极大的威胁。因此,它适用于对网络安全要求相对较低的环境。ⅡCHAP(ChallengeHandshakeAuthenticationProtocol,质询握手认证协议)认证CHAP为三次握手协议。只在网络上传输用户名,并不传输用户口令,因此它的安全性要比PAP高。CHAP的验证过程为: