pppoe原理协议详解

1、PPPoE ( Point to Point Protocol over Ethernet ,基于以太网的点对点协议)的工作流程包含发现(Discovery)和会话(Session)两个阶段，发现阶段是 无状态的，目的是获得 PPPoE终 端(在局端的 ADSL设备上)的以太网 MAC地址，并建立一个惟一的PPPoESESSIOND。发现阶段结束后，就进入标准的PPP会话阶段1 .发现阶段(PPPoED PPPoE Discovery )1.1 PADI (PPPoE Active Discovery Initiation )主机广播发起分组，分组的目的地址为以太网的广播地址0xfffffff

2、fffff , CODE(代码)字段值为0X09 (PADI Code) , SESSION-ID (会话ID)字段值为 0x0000。PADI分组必须至 少包含一个服务名称类型的 标签(Service Name Tag ,字段值为0x0101),向接入集中器 提出所要求提供的服务。1.2 PADO(PPPoE Active Discovery Offer )接入集中器收到在服务范围内的 PADI分组，发送PPPoEW效发现提供包分组，以响应请求。 其中COD今段值为0X07 ( PADO Code , SESSION-ID字段值仍为 0x0000。PAD3组必须 包含一个接入集中器名称类型的

3、标签(Access Concentrator NameTag,字段值为0x0102),以及一个或多个服务名称类型标签，表明可向主机提供的服务种类。PADOF口 PADI的Host-Uniq Tag 值相同。1.3 PADR ( PPPoE Active Discovery Request )主机在可能收到的多个PADOHfi中选择一个 合适的PADS组，然后向所选择的接入集中器发送PPPoEW效发现 请求分组。其中 COD序段为0x19 (PADR Code , SESSION叶段值 仍为0x0000。PAD明组必须包含一个服务名称类型标签，确定向接入集线器(或交换机) 请求的服务种类。当主机

4、在指定的时间内没有接收到PADO它应该重新发送它的 PADI分组，并且加倍等待时间，这个过程会被重复期望的次数。1.4 PADS(PPPoE Active Discovery Session -confirmation )接入集中器收到 PADR组后准备开始PPP会话，它发送一个PPPoEW效发现会话确认 PADS 分组。其中COD序段彳1为0X65 (PADSCode) , SESSION-ID字段值为接入集中器所产生的 一个惟一的PPPoE会话标识号码。PADS组也必须包含一个接入集中器名称类型的标签以 确认向主机提供的服务。当主机收到PADS分组确认后，双方就进入 PPP会话阶段。PAD

5、S和 PADR勺 Host-Uniq Tag 值相同。UserME601,PADI2PADO3.PADR4PADSJM.图1 P叩。E的协商流程2 .会话阶段(PPPoES PPPoE SessionPPP会话的建立，需要两端的设备都发送LCP数据包来配置和测试数据通信链路。用户主机与接入集中器根据在发现阶段所协商的PPP会话连接参数进行 PPP会话。-旦PPPoE会话开始，PPP数据就可以以任何其他的 PPP封装形式发送。所有的以太网帧都是 单播的。PPPoE会话的SESSIOND 一定不能改变，并且必须是发现阶段分配的值。2.1 LCP协商阶段(LCP Link Control Proto

6、col )LCP的Request主机和AC都要给对方发送，LCP协商阶段完成最大传输单元( MTU), 是否进行认证和采用何种认证方式( Authentication Type)的协商。(1) LCM议数据报文分类链路配置报文：用来建立和配置一条链路，主要包括Configure-Request、Configure-Ack、 Configure-Nak 和 Configure-Reject 报文链路维 护报文：用来管理和调试链路，主要包 括 Code-Reject Protocol -Reject Echo-Request、 Echo-Reply 和 Discard-Request 报文链路终止

7、报文：用来终止一条链路，主要包括Terminate-Request和Terminate-Reply报(2) LCM商过程LCP协商的过程如下：协商双方互相发送一个LCP Config-Request报文，确认收到的Config-Request报文中的协商选项，根据这些选项的支持与接受情况，做出适当的回应。若 两端都回应了 Config-ACK则标志LCP链路建立成功，否则会继续发送Request报文，直到对端回应了 ACK报文为止。ClientServerI.CP办商阶段Config-reqConfig* a。kConfig-reqConfig-tick图2 LCP协商的基本过程说明：(1)

8、Config-ACK若完全支持对端的 LCP选项，则回应 Config-ACK报文，报文中必须完 全携带对端Request报文中的选项。(2) Con巾g-NAK：若支持对端的协商选项，但不认可该项协商的内容，则回应Config-NAK报文，在Config-NAK的选项中填上自己期望的内容，如：对端MRU值为1500,而自己期望MRU值为1492,则在Con巾g-NAK报文中埴上自己的期望值1492。(3) Config-Reject：若不能支持对端的协商选项，则回应Con巾g-Reject报文，报文中带上不能支持的选项，如Windows拨号器会协商 CBCP(被叫回呼)，而ME60不支持CB

9、CP功能，则回将此选项拒绝掉。2.2 认证阶段(PPP Authentication : PAP/CHAP)会话双方通过LCP协商好的认证方法进行认证，如果认证通过了，才可以进行下面的网 络层的协商。认证过程在链路协商结束后就进行。I PAP ( Password Authentication Protocol , 口 令认证协议)认证PAP为两次握手协议，它通过用户名及口令来对用户进行验证。PAP验证过程如下：当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表(或Radius服务器)查看是否有此用户，口令是否正确。如正确则会给对端发送Authentic

10、ate-ACK报文，通告对端已被允许进入下一阶段协商；否则发送 NAK报文， 通告对端验证失败。此时，并不会直接将链路关闭。只有当验证不过次数达到一定值(缺省为10)时，才会关闭链路。PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有 可能对网络安全造成极大的威胁。因此，它适用于对网络安全要求相对较低的环境。ClientServerRadiusAuth-reqAuth-reqPPP:工厂卜AuhackAutti-ack图3 PAP认证流程n CHAP (Challenge Handshake Authentication Protocol ,质询握手认证协议)认证C

11、HAP为三次握手协议。只在网络上传输用户名，并不传输用户口令，因此它的安全性 要比PAP高。CHAP的验证过程为：首先由验证方(Server)向被验证方(Client)发送一些随机产生的报文，并同时将本端 的主机名附带上一起发送给被验证方。被验证方接到对端对本端的验证请求(Challenge)时，便根据此报文中验证方的主机名和本端的用户表查找用户口令字，如找到用户表中与验证方主机名相同的用户，便利用报文ID、此用户白密钥用 Md5算法生成应答(Response),随后将应答和自己的主机名送回。验证方接到此应答后， 用报文ID、本方保留的口令字 (密钥)和随机报文用 Md5算法得出结果，与被验证

12、方应答比较，根据比较结果返回相应的结果(ACKor NAK)(1)接受认证端发送 Challenge(2)申请认证端发验证请求报文(3)接受认证端回应认证接受报文经过以上三次报文交互后，CHAP认证完成。ClientServerRadiusChallenge(CHAP)Auth-reqPPP1证阶|Auth-reqAutti-ackAuth ack图4 CHAPU证胸里2.3 NCP 协商阶段(NCR Network Control Protocol )NCP有很多种，如 IPCR BCR IPv6CP,最为常用的是 IPCR Internet Protocol Control Protoco

13、l )协议。NCP的主要功能是协商 PPP报文的网络层参数，如IP地址，DNS Server IP地址，WINS Serve门P地址等。PPPoE用户主要通过IPCP来获取访问网络的IP地址或IP地址段。NCP流程与LCP流程类似，用户与 ME设备之间互相发送 NCP Config-Request报文并且 互相回应NCP Config-Ack报文后，标志NCP己协商完，用户上线成功，可以正常访问网络了。IPCP的协商过程是基于 PPP状态机进行协商的。经过双方协商，通过配置请求、配置 确认、配置否认等包文交换配置信息，最终由initial (或closed)状态变为Opened状态。IPCP状

14、态变为Opened的条件必须是发送方和接收方都发送和接收过确认包文。IPCP协商过程中，协商包文可包含多个选项，即参数。各个选项的拒绝或否认都不能 影响IPCP的UP, IPCP可以无选项协商，无选项协商也同样能够UP。选项有IP Address、网关、掩码等，其中IP Address是最重要的一个选项，有些厂家的实现必须这个选项得到确认， 大多数厂家的实现允许这个选项为空。ClientNCP的基本协商流程见下图：ServerParmeter reqParmeter-ackNCT协商阶段Parmeter-reqParmeterack图5 NCP的基本协商流程用户和接入设备对ip服务阶段的一些要

15、求进行多次协商，以决定双方都能够接收的约 ao如：IP业务阶段使用的IP压缩协议等。双方的协议是通过报文中包含的Option项进行协商的，每一个Option都是一个需要协商的问题。最后双方都需要对方答复Configure_Ack的同意报文。2.4 会话维持(Session Keep-alive)设备主动发送Echo Request进彳T PPPoE心跳保活，若3次未得到服务器的响应， 则设备 主动释放地址。发LCP Echo Request的时候，魔术字字段要和之前通信的 Configure_Request 使用的魔术字字段保持一致。有些设备或终端不支持主动发送Echc-Request报文，只

16、能支持回应 Echc-Reply报文。2.5 会话结束(Session Termination )PPPoE还有一个 PADT(PPPOE Active Discovery Terminate)分组，它可以在会话建立后 的任何时候发送，来终止PPPoE会话，也就是会话释放。它可以由主机或者接入集中器发送，目的地址填充为对端的以太网的MAC地址。当对方接收到一个 PADT (PPPOE Active Discovery Terminate)分组，就不再允许使用这 个会话来发送 PPP业务。PADT分组不需要任何标签， 其CODE字段值为0xa7 (PADT Cod。， SESSIOND字段值为需

17、要终止的 PPP会话的会话标识号码。在发送或接收PADT后，即使正常的PPP终止分组也不必发送。PPP对端应t使用 PPP协议自身来终止 PPPoE会话，但是当 PPP不能使用时，可以使用 PADT。1.PADI2PAD0 3 PADR 4 PADS日.LCP枷商f使用HAP认证 一 一 6,Challenge7.ResponseM Ace巳 5 5 Agee 口廿 RejectWSuccess/Failure图7 PFP。日CHAP拷入认讦流未导4.Linux 中的 PPPoE拨号守护进程(pppd : Point-to-Point Protocol Daemon )Linux 内 核inc

18、lude/uapi/linux/if_pppox.h 中 定 义 了PADI_CODE,PADO_CODE,PADR_CODE,PADS_CODE,PADT_CODE和structpppoe_tag/pppoe_hdr ; PPP/PPPoE实现代码在 /drivers/net/ppp/ 目录下，pppoe.c 中实现 了 pppoe_connect、pppoe_xmit、pppoe_recvmsg 等接口。pppd是一个后台服务进程(daemon),是一个用户空间的进程，所以把策略性的内容从 内核的PPP协议处理模块移到 pppd中是很自然的事了。pppd实现了所有鉴权、压缩/解压和加密/解

19、密等扩展功能的控制协议。pppd只是一个普通的用户进程， 它如何扩展PPP协议呢？这就是pppd与内核中的PPP 协议处理模块之间约定了， 它们之间采用了最传统的内核空间与用户空间之间通信方式：设备文件。设备文件名是/dev/ppp。通过read系统调用，pppd可以读取PPP协议处理模块的数 据包，当然，PPP协议处理模块只会把应该由pppd处理的数据包发给 pppd。通过write系统调用，pppd可以把要发送的数据包传递给PPP协议处理模块。通过ioctrl系统调用，pppd可以设置PPP协议的参数，可以建立/关闭连接PPP帧格式：帧格式与HDLC相似.不同的是PPP是面I句字符r HD

20、LC是面向位的L PPP帧格式如下：F A C 协设 信息FCS F字节 1 1 IZ不毡过150 0字节 2 1看到总共多了8个字节.其中首尾字节都是幢的起始和结束标志位,示地址,C表示控制.协议的两个字段，表示后面信息部分的数据协议是什么r包括：0x0021-一信息字段是1 口数据报0XC021-信息字段是链路控制数据LCP0x8021思字聘网雌缶UMNCPOXCO23信息字段是安全性认证PAP0XC025(言息字段是LQR0XC223-(B息认证 C HAPPPPoE的报文就是在 PPP的报文前面再加上 PPPOE头和以太网的报头，使得 PPPoE可 以通过简单桥接设备连入远端接入设备P

21、PPOE段如下：也可参考整个叩PoE的报文（包括Ethernet Frame ）:详细的说,就是下面的内容:TAG_TYPES (用于 Discovery Stage 中的协商参数)0x0000 End-Of-List0x0101 Service-Name0x0102 AGName0x0103 Host-Uniq其中:hc.nlcrhv.i drrIzthcmH情t Tlt.LBKTW TX.TaLUIUt.TTTtT&： Lnr.TR 1.,Ibblllnn3TlMJ 1444I 00 til2 4cliiIBtypecisdrIDkngthI)ECTIli-1i01i_A3A MrtH知必

22、&rnmrmCTOCISU)!1 Ml 41加8s的Dimareiy 4啊6勰MPPP沁J前Si必FTHFR TYPE :GnOOPPP $e$5ion S 他於0m09PF POf Aft1-” C hfnwry InitiaTifln -PAD1| parkrt0x07PPPOE Active Discovery Crffer (PADO packet0x19PFPOE Active Discovery Rsquet (PADR) packetPPPOL ActjVf Di口帐ly Sessiun-cuiilirnidtiui iPADSj pd现PPPOE Acthrc DiESvecy

23、 Iftminatv (PADB packetCODE :0x0104 AC-Cookie0x0105 Vendor-Specific0x0110 Relay-Session-Id0x0201 Service-Name-Error0x0202 AC-System-Error0x0203 Generic -ErrorPPP协议的LCP数据报文下面我们来对PPP协议的LCP数据报文内容进行一下分析和讲解。首先我们需要从数据 帧内容过度一下今天的内容。对于PPP协议的基础内容，PPP数据帧以及PPP模式我们都做了介绍。那么这里我们再 来讲解一下PPP协议的LCP数据报文的内容。通过前面的文章，我们知

24、道，LCP数据报文是在链路建立阶段被交换的，它作为PPP的净载荷被封装在 PPP数据帧的信息域中。在链路建立阶段的整个过程中信息域的内容是在变化的， 它包括很多种类型的报文， 所以这些报文 也要通过相应的字段来区分。PPP数据帧的协议域固定填充0xC021。代码域 1 + 标识域 1 + 长度域+ 数据域代码域的长度为一个字节，主要是用来标识LCP数据报文的类型的。在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（ Code-Reject 报文） 。标识域也是一个字节， 其目的是用来匹配请求和响应报文。 一般而言在进入链路建立阶段时， 通信双

25、方无论哪一端都会连续发送几个配置请求报文（ Config-Request 报文） ， 而这几个请求报文的数据域可能是完全一样的， 而仅仅是它们的标识域不同罢了。 通常一个配置请求报文的ID是从0x01开始逐步加1的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可能是Config-Ack、 Config-Nak 和 Config-Reject 三种报文中的一种）来回应对方，但必须要求回应报文中的ID （标识域）要与接收报文中的ID一致，当通信设备收到回应后就可以将该回应与发送时的进行比较来决定下一步的操作。长度域的内容 = 总字节数据（代码域+标志域+长度域+数据域）。长度域所指示字

26、节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU 的值。数据域的内容卞据不同的LCP数据报文的内容也是不一样的。下面说一下LCP包括的几种报文类型，不同的报文在标识域中所填充的内容也不同。LCP报文主要分为1、链路配置报文；2、链路终止报文；3、链路维护报文。链路配置报文主要包括Config-Request、 Config-Ack、 Config-Nak 和 Config-Reject 四种报当通信双方需要建立链路时， 无论哪一方都需要发送Config-Request 报文并携带每一端自已所希望协商的配置参数选项。当接收方收到 Config-Request 报文时， 会在剩

27、下的三种类型的报文中选择一种来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件：不能完全识别配置参数选项的类型域， 我们知道一个Config-Request 报文中会同时携带多个配置参数选项，而对于一个支持 PPP协议的通信设备也不一定会支持上表中所有列出的 配置选项，即使支持，也可能在实际应用中关闭掉某些选项功能。（例如：当使用PPP协议通信的一端可能将一些无用的配置选项都关闭了， 而仅支持 0x01 和 0x03 两个配置参数选项， 因此当对方发送的 Config-Request 报文中含有0x04 配置选项时，对于本端而言这个配置参数选项就无法识别，也即是不支持这个配置参

28、数选项的协商） 。如果能支持完全识别配置参数选项， 但接收端也可能不认可Config-Request 报文中配置参数选项数据域中的内容（例如：当一端发送魔术字配置参数选项中的魔术字为全0，而对端认为应该为其它值，这种情况就属于不支持配置参数选项中的内容） 。所以依据上面的两个条件， 我们就可以明确在回应对方配置请求报文时， 采用何种报文 回应。当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时， 接收端将会给对端回一个Config-Ack 报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack 报文的数据域内 （根

29、据协议的规定是不可改变配置参数选项的顺序） 。当配置请求报文的发送端收到 Config-Ack 报后，则会从当前阶段进入 到下一个阶段。当接收 Config-Request 报文的一端能识别发送端所发送过来的所有配置参数选项， 但对 部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-Nak 报文，（注意，是能够识别，只是对部分参数内容不认可，所以不是Config-Reject 报文）该报文中只携带不认可的配置参数选项， 而这些配置参数选项的数据内容为本端希望的值。 然而当接 收端收到Config-Nak报文后，会重新发送 Config-Request报文，而这个 C

30、onfig-Request报文 与上一次所发送的 Config-Request 报文区别在于那些被对端不认可的配置参数选项的内容被 填写到刚刚协商完后再次发送的Config-Request报文中（Con巾g-Nak报文发送回来的那些配置参数选项） 。当接收 Config-Request 报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject 报文， 该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别时） 。当对端接收到 Config-Reject 报文后，同样会再次发送一个Config-Request 报文， 这

31、个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。链路终止报文分为 Terminate-Request和Terminate-Reply两种报文。LCP报文中提供了一 种机制来关闭一个点对点的连接，想要关断链路的一端会持续发送Terminate-Request报文，直到收到一个 Terminate-Reply为止。接收端一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply 报文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项

32、。对于链路终止报文也同样需要ID一致，当接收到 Terminate-Reply报文才会做链路终止操作。最后说一下魔术字的含义， 这是在链路建立过程中比较重要的一个参数， 这个参数是在Config-Request 里面被协商的， 主要的作用是防止环路， 如果在双方不协商魔术字的情况下，某些LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全0;反之，则填充为配置参数选项协商后的结果。魔术字在目前所有的设备当中都是需要进行协商的， 它被放在 Config-Request 的配置选项参数中进行发送， 而且需要由自身的通信设备独立产生， 协议为了避免双方可能产生同样的魔术字， 从而导致通

33、信出现不必要的麻烦， 因此要求由设备采用一些随机方法产生一个独一无二的魔术字。 一般来说魔术字的选择会采用设备的系列号、 网络硬件地址或时钟。 双方产生相同魔术字的可能性不能说是没有的， 但应尽量避免， 通常这种情况是发产在相同厂商 的设备进行互连时，因为一个厂商所生产的设备产生魔术字的方法是一样的。我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端收到一个Config-Request 报文时，会将此报文与上一次所接收到的 Config-Request 进行比较，如果两 个报文中所含的魔术字不一致的话， 表明链路不存在环路。 但如果一致的话， 接收端认为链 路可能存在环路，但不一

34、定存在环路，还需进一步确认。此时接收端将发送一个Config-Nak报文，并在该报文中携带一个重新产生的魔术字，而且此时在未接收到任何Config-Request或 Config-Nak 报文之前，接收端也不会发送任何的 Config-Request 报文。这时我们假设可能 会有以下两种情况发生：1 .链路实际不存在环路，而是由于对方在产生魔术字时与接收端产生的一致，但实际这种情况出现的概率是很小的。当 Config-Nak 被对端接收到后，应该发送一个Config-Request报文（此报文中的魔术字为Nak报文中的），当对端接收到后，与上次比较，由于接收端已经在Nak报文中产生了一个不同的

35、魔术字，此时接收端收到的 Config-Request报文中的魔术字与上次配置请求报文中不一样，所以接收端可断定链路不存在环路。2 .链路实际上确实存在环路，一段时间后Con的-Nak报文会返回到发送该报文的同一端。这时接收端比较这个Config-Nak 报文与上一次发出去的一样， 因此链路存在环路的可能性又增大了。我们知道当一端收到了一个Con巾g-Nak报文时，又会发送一个Con巾g-Request报文（该报文中的魔术字与Config-Nak 中的一致） ，这样又回到了最初的状态，在这条链路上就会不断的出现Config-Request、 Config-Nak 报文，因此这样周而复始下去，接

36、收端就会认为PPP 链路存在环路的可能性在不断增加，当达到一定数量级时，就可认为此链路存在环路。（注意，不是第一次受到相同的魔术字就判断有环路的）但在实际应用中根据不同设备实现PPP协议的方法，我们在链路环路检测时可采用两种方法。第一种机制就是如上面所述的，这个过程不断地重复，最终可能会给LCP状态机发一个Down事件，这时可能会使 LCP的状态机又回到初始化阶段，又开始新一轮的协商。当然 对于某些设备还会采用第二种机制，就是不产生任何事件去影响当前LCP的状态机，而是停留在请求发送状态。但这时认为链路有环路的一端设备需要不断的向链路上发送 Echo-Request报文来检测链路环路是否被解除，当接收端收到Echo-Reply报文时，就认为链路环路被解除，从而就可能进行后续的PPP的过程。ppp协商过程图;幻灯探报一些物理其电的微.摩 .会学恐城人 rluBl iah失败首先，ppp从DEAD阶段开始，PPPOEM开始到结束都是从这个阶段开始了，他表示已 经准备好开始了，然后