完整word版pppoe原理协议详解
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
PPPoE(Point to Point Protocol over Ethernet,基于以太网的点对点协议)的工作流程包含发现(Discovery)和会话(Session)两个阶段,发现阶段是无状态的,目的是获得PPPoE 终端(在局端的ADSL设备上)的以太网MAC 地址,并建立一个惟一的PPPoE SESSION-ID。发现阶段结束后,就进入标准的PPP会话阶段
1.发现阶段(PPPoED:PPPoE Discovery)
) Initiation PADI(PPPoE Active Discovery1.1
主机广播发起分组,分组的目的地址为以太网的广播地址 0xffffffffffff,CODE(代码)字段值为0×09(PADI Code),SESSION-ID(会话ID)字段值为0x0000。PADI分组必须至少包含一个服务名称类型的标签(Service Name Tag,字段值为0x0101),向接入集中器提出所要求提供的服务。) Offer(PPPoE Active Discovery1.2 PADO接入集中器收到在服务范围内的PADI 分组,发送PPPoE有效发现提供包分组,以响应请求。其中CODE字段值为0×07(PADO Code),SESSION-ID字段值仍为0x0000。PADO分组必须包含一个接入集中器名称类型的标签(Access Concentrator Name Tag,字段值为0x0102),以及一个或多个服务名称类型标签,表明可向主机提供的服务种类。PADO和PADI的值相同。Host-Uniq Tag
) Request PADR(PPPoE Active Discovery1.3主机在可能收到的多个PADO分组中选择一个合适的PADO分组,然后向所选择的接入集中器发送PPPoE有效发现请求分组。其中CODE字段为0x19(PADR Code),SESSION_ID字段值仍为0x0000。PADR分组必须包含一个服务名称类型标签,确定向接入集线器(或交换机)请求的服务种类。当主机在指定的时间内没有接收到PADO,它应该重新发送它的PADI分组,时间,这个过程会被重复期望的次数。并且加倍等待)-confirmation(PPPoE Active Discovery Session1.4 PADS接入集中器收到PADR分组后准备开始PPP会话,它发送一个PPPoE有效发现会话确认PADS分组。其中CODE字段值为0×65(PADS Code),SESSION-ID字段值为接入集中器所产生的一个惟一的PPPoE 会话标识号码。PADS分组也必须包含一个接入集中器名称类型的标签以确认向主机提供的服务。当主机收到PADS 分组确认后,双方就进入PPP会话阶段。PADS值相同。的和PADRHost-Uniq Tag
)PPPoES:PPPoE Session会话阶段(2.
数据包来配置和测试数据通信链路。PPP会话的建立,需要两端的设备都发送LCP
会话。一PPP用户主机与接入集中器根据在发现阶段所协商的PPP会话连接参数进行
所有的以太网帧都是封装形式发送。PPP数据就可以以任何其他的PPP旦PPPoE会话开始,一定不能改变,并且必须是发现阶段分配的值。-ID单播的。PPPoE会话的SESSION
):Link Control Protocol 2.1 LCP协商阶段(LCP
,MTU)AC主机和都要给对方发送,LCP协商阶段完成最大传输单元(LCP的Request Authentication Type)的协商。是否进行认证和采用何种认证方式(
LCP协议数据报文分类(1)
、Ack、Configure-Request 链路配置报文:用来建立和配置一条链路,主要包括Configure-
报文Configure-RejectConfigure-Nak和、RejectProtocol-括Code-Reject、链路维护报文:用来管理和调试链路,主要包Request报文Reply和Discard-Echo-Request、Echo-报Reply和Terminate-链路终止报文:用来终止一条链路,主要包括Terminate-Request
文
LCP协商过程(2)
报文,确认收到的-ConfigRequestLCP 协商的过程如下:协商双方互相发送一个LCP
报文中的协商选项,根据这些选项的支持与接受情况,做出适当的回应。若Request-Config报文,直到Request链路建立成功,否则会继续发送LCP,则标志ACK-Config两端都回应了.
对端回应了ACK报文为止。
说明:
报文,报文中必须完ACKConfig-ACK:若完全支持对端的LCP选项,则回应1 ()Config-报文中的选项。全携带对端RequestNAK-则回应ConfigNAK:若支持对端的协商选项,但不认可该项协商的内容,(2)Config-,而自己期望值为1500的选项中填上自己期望的内容,如:对端MRU报文,在Config-NAK 1492。-NAK报文中埴上自己的期望值,则在MRU值为1492Config 报文,报文中带Reject:若不能支持对端的协商选项,则回应Config--(3)ConfigReject
功CBCP,而ME60不支持上不能支持的选项,如Windows拨号器会协商CBCP(被叫回呼)能,则回将此选项拒绝掉。
):PAP/CHAP 2.2 认证阶段(PPP Authentication
才可以进行下面的网协商好的认证方法进行认证,如果认证通过了,会话双方通过LCP
络层的协商。认证过程在链路协商结束后就进行。
,口令认证协议)认证PAP(Password Authentication ProtocolⅠ
:PAP验证过程如下PAP为两次握手协议,它通过用户名及口令来对用户进行验证。验证方根当两端链路可相互传输数据时,被验证方发送本端的用户名及口令到验证方,
服务器)查看是否有此用户,口令是否正确。如正确则会给对Radius据本端的用户表(或报文,NAKACK报文,通告对端已被允许进入下一阶段协商;否则发送Authenticate端发送-此时,并不会直接将链路关闭。只有当验证不过次数达到一定值(缺省通告对端验证失败。)时,才会关闭链路。为10的特点是在网络上以明文的方式传递用户名及口令,如在传输过程中被截获,便有PAP
可能对网络安全造成极大的威胁。因此,它适用于对网络安全要求相对较低的环
境。.
Challenge Handshake Authentication Protocol(,质询握手认证协议)认证ⅡCHAP
为三次握手协议。只在网络上传输用户名,并不传输用户口令,因此它的安全性CHAP
CHAP的验证过程为:要比PAP高。)发送一些随机产生的报文,并同时将本端)向被验证方(Client 首先由验证方(Server
时,Challenge)的主机名附带上一起发送给被验证方。被验证方接到对端对本端的验证请求(如找到用户表中与验证方便根据此报文中验证方的主机名和本端的用户表查找用户口令字,,随后)Md5算法生成应答(Response主机名相同的用户,便利用报文ID、此用户的密钥用(密钥)本方保留的口令字用报文ID、将应答和自己的主机名送回。验证方接到此应答后,ACK (与被验证方应答比较,根据比较结果返回相应的结果和随机报文用Md5算法得出结果,)or NAK
)接受认证端发送Challenge1 (
2)申请认证端发验证请求报文(
)接受认证端回应认证接受报文( 3
认证完成。经过以上三次报文交互后,CHAP