pppoe原理协议详解样本.doc

pppoe原理协议详解样本 e pppoe原理协议详解本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 E PPPoE（Point toPoint Protocolover Ether，基于以太网的点对点协议）的工作流程包含发现（Discovery）和会话（Session）两个阶段，发现阶段是无状态的，目的是获得PPPoE终端（在局端的L ADSL设备上）的以太网MAC地址，并建立一个惟一的PPPoE SESSION-ID。 发现阶段结束后，就进入标准的P PPP会话阶段（PPPoED:PPPoE Discovery）PADI（PPPoE Active Discovery Initiation）主机广播发起分组，分组的目的地址为以太网的广播地址0xffffffffffff，CODE（代码）字段值为009（PADI Code），SESSION-ID（会话ID）字段值为0x0000。 I PADI分组必须至少包含一个服务名称类型的标签（Service Name Tag，字段值为0x0101），向接入集中器提出所要求提供的服务。 PADO（PPPoE ActiveDiscovery Offer）接入集中器收到在服务范围内的的I PADI分组，发送送E PPPoE有效发现提供包分组，以响应请求。 其本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 中CODE字段值为7007（PADO Code，），SESSION-ID字段值仍为0x0000。 O PADO分组必须包含一个接入集中器名称类型的标签（Aess ConcentratorNameTag，字段值为0x0102），以及一个或多个服务名称类型标签，表明可向主机提供的服务种类。 O PADO和和I PADI的的Host-Uniq gTag值相同。 PADR（PPPoE ActiveDiscovery Request）主机在可能收到的多个O PADO分组中选择一个合适的O PADO分组，然后向所选择的接入集中器发送送E PPPoE有效发现请求分组。 其中E CODE字段为0x19（PADR Code），D SESSION_ID字段值仍为0x0000。 R PADR分组必须包含一个服务名称类型标签，确定向接入集线器（或交换机）请求的服务种类。 当主机在指定的时间内没有接收到PADO，它应该重新发送它的I PADI分组，并且加倍等待时间，这个过程会被重复期望的次数。 PADS（PPPoE ActiveDiscovery Session-confirmation）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 接入集中器收到PADR分组后准备开始PPP会话，它发送一个PPPoE有效发现会话确认PADS分组。 其中E CODE字段值为065（PADS Code），SESSION-D ID字段值为接入集中器所产生的一个惟一的E PPPoE会话标识号码。 S PADS分组也必须包含一个接入集中器名称类型的标签以确认向主机提供的服务。 当主机收到PADS分组确认后，双方就进入P PPP会话阶段。 S PADS和和R PADR的Host-g UniqTag值相同。 （PPPoES:PPPoE Session）P PPP会话的建立，需要两端的设备都发送P LCP数据包来配置和测试数据通信链路。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 用户主机与接入集中器根据在发现阶段所协商的P PPP行会话连接参数进行P PPP会话。 一旦E PPPoE会话开始，P PPP数据就能够以任何其它的PPP封装形式发送。 所有的以太网帧都是单播的。 E PPPoE会话的SESSION-D ID一定不能改变，并且必须是发现阶段分配的值。 LCP（协商阶段（LCP:Link Control Protocol）P LCP的t Request主机和C AC都要给对方发送，P LCP协商阶段完成最大传输单元（MTU），是否进行认证和采用何种认证方式（Authentication Type）的协商。 （11）P LCP协议数据报文分类链路配置报文:用来建立和配置一条链路，主要包括Configure-Request、Configure-Ack、Configure-k Nak和和Configure-t Reject报文链路维护报文:用来管理和调试链路，主要本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 包括Code-t Reject、Protocol-t Reject、Echo-Request、Echo-y Reply和和Discard-Request报文链路终止报文:用来终止一条链路，主要包括Terminate-Request和Terminate-Reply报文 （22）P LCP协商过程P LCP协商的过程如下:协商双方互相发送一个个LCP Config-t Request报文，确认收到的Config-t Request报文中的协商选项，根据这些选项的支持与接受情况，做出适当的回应。 若两端都回应了Config-ACK，则标志P LCP链路建立成功，否则会继续发送t Request报文，直到对端回应了K ACK报文为止。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 说明: （11）Config-ACK:若完全支持对端的P LCP选项，则回应Config-K ACK报文，报文中必须完全携带对端t Request报文中的选项。 （22）Config-NAK:若支持对端的协商选项，应但不认可该项协商的内容，则回应Config-NAK报文，在Config-K NAK的选项中填上自己期望的内容，如:对端U MRU值为1500，而自己期望MRU值为1492，则在Config-K NAK报文中埴上自己的期望值1492。 （33）Config-Reject:若不能支持对端的协商选项，则回应Config-Ret ject报文，报文中带本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 如上不能支持的选项，如s Windows拨号器会协商CBCP（被叫回呼），而0ME60不支持P CBCP功能，则回将此选项拒绝掉。 认证阶段（PPP Authentication:PAP/CHAP）过会话双方通过P LCP协商好的认证方法进行认证，如果认证通过了，才能够进行下面的网络层的协商。 认证过程在链路协商结束后就进行。 P PAP（Password Authentication Protocol，口令认证协议）认证P PAP为两次握手协议，它通过用户名及口令来对用户进行验证。 P PAP验证过程如下:当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表（或s Radius服务器）查看是否有此用户，口令是否正确。 如正确则会给对端发送Authenticate-K ACK报文，通告对端已被允许进入下一阶段协商；否则发送K NAK报文，通告对端本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 验证失败。 此时，并不会直接将链路关闭。 只有为当验证不过次数达到一定值（缺省为10）时，才会关闭链路。 PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有可能对网络安全造成极大的威胁。 因此，它适用于对网络安全要求相对较低的环境。 CHAP（Challenge HandshakeAuthenticationProtocol，质询握手认证协议）认证P CHAP为三次握手协议。 只在网络上传输用户名，并不传输用户口令，因此它的安全性要比P PAP高。 P CHAP的验证过程为:本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 首先由验证方（Server）向被验证方（Client）发送一些随机产生的报文，并同时将本端的主机名附带上一起发送给被验证方。 被验证方接到对端对本端的验证请求（Challenge）时，便根据此报文中验证方的主机名和本端的用户表查找用户口令字，如找到用户表中与验证方文主机名相同的用户，便利用报文ID、此用户的密钥用5Md5算法生成应答（Response），随后将应答和自己的主机名送回。 验证方接到此应答文后，用报文ID、本方保留的口令字（密钥）和随机报文用5Md5算法得出结果，与被验证方应答比较，根据比较结果返回相应的结果（ACK orNAK） （11）接受认证端发送Challenge （22）申请认证端发验证请求报文 （33）接受认证端回应认证接受报文经过以上三次报文交互后，P CHAP。 认证完成。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 P NCP协商阶段（NCP:Network ControlProtocol）P NCP有很多种，如IPCP、BCP、IPv6CP，最为常用的是IPCP（Inter ProtocolControlProtocol）协议。 P NCP的主要功能是协商P PPP报如文的网络层参数，如P IP地址，DNS Server IP地址，P WINSServerIP地址等。 E PPPoE用户主要通过P IPCP来获取访问网络的P IP地址或P IP地址段。 P NCP流程与P LCP流程类似，用户与E ME设备之间互相发送NCP Config-t Request报文并且互相回应NCP Config-k Ack报文后，标志P NCP己协商完，用户上线成功，能够正常访问网络了。 P IPCP的协商过程是基于P PPP状态机进行协商的。 经过双方协商，通过配置请求、配置确认、本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 配置否认等包文交换配置信息，最终由initial(或或closed)状态变为d Opened。 状态。 P IPCP状态变为为d Opened的条件必须是发送方和接收方都发送和接收过确认包文。 P IPCP协商过程中，协商包文可包含多个选项，即参数。 各个选项的拒绝或否认都不能影响P IPCP的的UP，P IPCP能够无选项协商，无选项协商也同样能够UP。 选项有IP Address、网关、掩码等，其中s IPAddress是最重要的一个选项，有些厂家的实现必须这个选项得到确认，大多数厂家的实现允许这个选项为空。 P NCP的基本协商流程见下图:用户和接入设备对P IP服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 如P:IP业务阶段使用的P IP压缩协议等。 双方的协议是通过报文中包含的n Option项进行协，商的，每一个n Option。 都是一个需要协商的问题。 复最后双方都需要对方答复Configure_Ack的同意报文。 会话维持（Session Keep-alive）设备主动发送t EchoRequest进行E PPPoE心跳保活，若33次未得到服务器的响应，则设备主动释放地址。 发LCP EchoRequest的时候，魔的术字字段要和之前通信的Configure_Request使用的魔术字字段保持一致。 有些设备或终端不支持主动发送Echo-Request报文,只能支持回应Echo o-Reply报文。 会话结束（Session Termination）PPPoE个还有一个T PADT（PPPOE ActiveDiscovery Terminate）分组，它能够在会话建立后的任何时候发送，来终止E PPPoE会话，也就本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 是会话释放。 它能够由主机或者接入集中器发送，目的地址填充为对端的以太网的C MAC。 地址。 当对方接收到一个PADT（PPPOE ActiveDiscovery Terminate）分组，就不再允许使用这个会话来发送P PPP业务。 T PADT分组不需要任何标签，其E CODE字段值为0xa7（PADT Code），SESSION-D ID字段值为需要终止的P PPP会话的会话标识号码。 在发送或接收T PADT后，即使正常的的P PPP终止分组也不必发送。 P PPP对端应该使用P PPP协议自身来终止E PPPoE会话，但是当P PPP不能使用时，能够使用PADT。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 （pppd:Point-to-Point ProtocolDaemon）Linux内核include/uapi/linux/中定义了PADI_CODE,PADO_CODE,PADR_C ODE,PADS_CODE,PADT_CODE和struct pppoe_tag/pppoe_hdr；PPP/PPPoE实现代码在/drivers/ppp/目录下，中实现了pppoe_connect、pppoe_xmit、pppoe_recvmsg等接口。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 pppd是一个后台服务进程(daemon)，是一个用户空间的进程，所以把策略性的内容从内核的的P PPP协议处理模块移到pppd中是很自然的事了。 pppd实现了所有鉴权、压缩/解压和加密/解密等扩展功能的控制协议。 d pppd只是一个普通的用户进程，它如何扩展PPP协议呢?这就是pppd与内核中的PPP协议处理模块之间约定了，它们之间采用了最传统的内核空间与用户空间之间通信方式:设备文件。 设备文件名是/dev/ppp过。 通过d read系统调用，d pppd能够读取P PPP协议处理模块的数据包，当然，P PPP协议处理模块只会把应该由d pppd处理的数据包发给pppd。 通过e write系统调用，d pppd能够把要发送的数据包传递给P PPP协议处理模块。 通过l ioctrl系统调用，d pppd能够设置P PPP协议的参数，能够建立/关闭连接P PPP帧格式:本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 E PPPoE在的报文就是在P PPP的报文前面再加上E PPPOE头和以太网的报头，使得E PPPoE能够通过简单桥接设备连入远端接入设备E PPPOE字段如下:本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 其中:TAG_TYPES:（用于eDiscoveryStage中的协商参数）本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 0x0000End-Of-List0x0101Service-Name0x0102AC-Name0x0103Host-Uniq0x0104AC-Cookie0x0105Vendor-Specific0x0110Relay-Sess ion-Id0x0201Service-Name-Error0x0202AC-System-Error0x0203Generic-Error本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 P PPP协议的P LCP数据报文下面我们来对PPP协议的LCP数据报文内容进行一下分析和讲解。 首先我们需要从数据帧内容过度一下今天的内容。 对于PPP，协议的基础内容，PPP数据帧以及PPP模式我们都做了介绍。 那么这里我们再来讲解一下下P PPP协议的P LCP数据报文的内容。 通过前面的文章，我们知道，P LCP数据报文是在链路建立阶段被交换的，它作为P PPP的净载荷被封装在PPP数据帧的信息域中。 在链路建立阶段的整个过程中信息域的内容是在变化的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分。 P PPP数据帧的协议域固定填充0xC021。 代码域1+标识域1+长度域+数据本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 域代码域的长度为一个字节，主要是用来标识P LCP数据报文的类型的。 在链路建立阶段时，接收方收到P LCP数据报文的代码域无法识别时，就个会向对端发送一个P LCP的代码拒绝报文（Code-t Reject报文）。 标识域也是一个字节，其目的是用来匹配请求和响应报文。 一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文（Config-t Request报文），而这几个请求报文的数据域可能是完全一样的，而仅仅是它们的标识域不同罢了。 通常一个配置请求报文的D ID是从10x01开始逐步加11的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可能是Config-k Ack、Config-Nak和Config-Reject三种报文中的一种）来回应对方，但必须要求回应报文中的的ID（标识域）要与接收报文中的D ID一致，当通信设备收到回应后就能够将该回应与发送时的进行比较来决定下一步的操作。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 长度域的内容=总字节数据（代码域+标志域+长度域+数据域）。 长度域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过U MRU的值。 的数据域的内容根据不同的P LCP数据报文的内容也是不一样的。 下面说一下P LCP包括的几种报文类型，不同的报文在标识域中所填充的内容也不同。 P LCP报文主要分为 11、链路配置报文； 22、链路终止报文； 33、链路维护报文。 括链路配置报文主要包括C Config-Request、Config-Ack、Config-k Nak和和Config-t Reject四种报文。 当通信双方需要建立链路时，无论哪一方都需要发送Config-t Request报文并携带每一端自已所希望协商的配置参数选项。 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 当接收方收到Config-t Request报文时，会在剩下的三种类型的报文中选择一种来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件:不能完全识别配置参数选项的类型域，我们知道一个Config-t Request报文中会同时携带多个配置参数选项，而对于一个支持P PPP协议的通信设备也不一定会支持上表中所有列出的配置选项，即使支持，也可能在实际应用中关闭掉某些选项功能。 （例如:当使用P PPP协议通信的一端可能将一些无用的配置选项都关闭了，而仅支持10x01和和30x03两个配置参数选项，因此当对方发送的Config-Request报文中含有0x04配置选项时，对于本端而言这个配置参数选项就无法识别，也即是不支持这个配置参数选项的协商）。 如果能支持完全识别配置参数选项，但接收端也可能不认可Config-t Request报文中配置参数选项数据域中的内容（例如:当一端发送魔术字配置参数选项中的魔术字为全00，而对端认为应该为其它值，这种情况就属于不支持配置参数选本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 项中的内容）。 所以依据上面的两个条件，我们就能够明确在回应对方配置请求报文时，采用何种报文回应。 当接收Config-t Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个个Config-k Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-k Ack报文的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。 当配置请求报文的发送端收到Conf ig-k Ack报后，则会从当前阶段进入到下一个阶段。 当接收Config-t Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-k Nak报文，（注意，是能够识别，只是对部分参数内容不认可，所以不是Config-t Reject报文）该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 内容为本端希望的值。 然而当接收端收到Config-Nak报文后，会重新发送Config-t Request报文，而这个Config-Re quest报文与上一次所发送的Config-t Request报文区别在于那些被对端不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-t Request报文中（Config-k Nak报文发送回来的那些配置参数选项）。 当接收Config-t Request报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-t Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别时）。 当对端接收到Config-t Reject报文后，同样会再次发送一个Config-t Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。 为链路终止报文分为Terminate-t Request和Terminate-y Reply两种报文。 P LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 路的一端会持续发送Terminate-t Request报文，直到收到一个Terminate-y Reply为止。 接收端一旦收到了一个Terminate-t Request报文后，必须回应一个Terminate-y Reply报文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。 LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配要置参数选项。 对于链路终止报文也同样需要ID一致，当接收到Terminate-y Reply报文才会做链路终止操作。 最后说一下魔术字的含义，这是在链路建立过程中比较重要的一个参数，这个参数是在Config-t Request里面被协商的，主要的作用是防止环路，如果在双方不协商魔术字的情况下，某些P LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全00；反之，则填充为配置参数选项协商后的结果。 魔术字在当前所有的设备当中都是需要进行本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 协商的，它被放在Config-t Request的配置选项参数中进行发送，而且需要由自身的通信设备独立产生，协议为了避免双方可能产生同样的魔术字，从而导致通信出现不必要的麻烦，因此要求由设备采用一些随机方法产生一个独一无二的魔术字。 一般来说魔术字的选择会采用设备的系列号、网络硬件地址或时钟。 双方产生相同魔术字的可能性不能说是没有的，但应尽量避免，通常这种情况是发产在相同厂商的设备进行互连时，因为一个厂商所生产的设备产生魔术字的方法是一样的。 我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端收到一个Config-t Request报文时，会将此报文与上一次所接收到的Config-t Request进行比较，如果两个报文中所含的魔术字不一致的话，表明链路不存在环路。 但如果一致的话，接收端认为链路可能存在环路，但不一定存在环路，还需进一步确认。 此时接收端将发送一个Config-k Nak报文，并在该报文中携带一个重新产生的魔术字，而且何此时在未接收到任何Config-t Request或本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 Config-k Nak报文之前，接收端也不会发送任何的的Config-Requet st报文。 这时我们假设可能会有以下两种情况发生:，而是由于对方在产生魔术字时与接收端产生的一致，但实际这种情况出现的概率是很小的。 当当Config-k Nak被对端接收到后，应该发送一个Config-t Request报文（此报文中的魔术字为Nak报文中的），当对端接收到后，与上次比较，由在于接收端已经在k Nak报文中产生了一个不同的魔术字，此时接收端收到的Config-t Request报文中的魔术字与上次配置请求报文中不一样，所以接收端可断定链路不存在环路。 ，一段时间后Config-k Nak报文会返回到发送该报文的同一端。 这时接收端比较这个Config-k Nak报文与上一次发出去的一样，因此链路存在环路的可能性又增大了。 我们知道当一端收到了一个Config-k Nak报文时，又会发送一个个Config-t Request报文（该报文中的魔术字与Config-k Nak中的一致），这样又回到了最初的状态，在这条链路上就会不断的出现本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 Config-Request、Config-k Nak报文，因此这样周而复始下去，接收端就会认为P PPP链路存在环路的可能性在不断增加，当达到一定数量级时，就可认为此链路存在环路。 （注意，不是第一次受到相同的魔术字就判断有环路的）现但在实际应用中根据不同设备实现P PPP协议的方法，我们在链路环路检测时可采用两种方法。 第一种机制就是如上面所述的，这个过程不断地重复，最终可能会给P LCP状态机发一个Down事件，