pppoe报文深入了解.docx
《pppoe报文深入了解.docx》由会员分享，可在线阅读，更多相关《pppoe报文深入了解.docx（27页珍藏版）》请在冰点文库上搜索。
pppoe报文深入了解
第一天：
pppoe的数据包深入了解，点对点协议（ppp）
Pppoe分为发现阶段和会话阶段，发现阶段分为PADI,PADO,PADR,PADS.
pppoe的数据报文依次为目的MAC（6字节=48bit），源MAC（6字节），协议类型（2字节为ox8863），版本（VER4bit为0001），字段和类型（TYPE4bit0001）,代码（CODE8bit）,版本标识号码（SESSION-ID16bit为ox0000），长度（LENGTH16bit）,静载荷（数据域）。
发现报文的数据域格式为TAG（类型-长度），主机名称（15个字节），TAG（类型-长度），主机标识符（4个字节），TAG（类型-长度），AC-Cookie（18个字节）。
采用的是TLV（类型-长度-值）
阶段
源MAC
目的MAC
CODE
48bit
48bit
8bit
PADI
主机A
广播（FF:
FF:
FF:
FF:
FF:
FF）
Ox09
PADO
服务器B
主机A
Ox07
PADR
主机A
服务器B
Ox19
PADS
服务器B
主机A
Ox65
PPPOE数据报文中Tag（标记）的格式
对于发现阶段的PPPOE数据报文而言，它的净载荷可能包含零个或多个Tag（标记），实际上这些标记的意义非常类似于PPP配置参数选项，它同样也是要经过协商的。
对于PPPOE协议而言，没有像PPP的配置参数选项那样定义了很多细节，而只是一个初略的定义，因此在实际当中实现这个过程会依据不同厂商的设备有不同。
首先还是让我们看一下承载在PPPOE报文数据域中的标记封装格式，如图2。
类型
长度
数据
（图2标记的封装格式）
从图2中可以看出，标记的封装格式采用的是大家所熟知的TLV结构，也即是（类型+长度+数据）。
标记的类型域为2个字节，下表列出了各种标记类型的含义：
标记类型
标记说明
0x0000
表示PPPOE报文数据域中一串标记的结束，为了保证版本的兼容性而保留，在有些报文中有应用。
0x0101
服务名，主要用来表明网络侧所能提供给用户的一些服务。
0x0102
访问集中器名，当用户侧接收到了AC的回应的PADO报文时，就可获从所携带的标记中获知访问集中器的名子，而且还可以据此来选择相应的访问集中器。
0x0103
主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和接收端的，因为对于广播式的网络中会同时存在很多个PPPOE的数据报文。
0x0104
AC-Cookies，主要被用来防止恶意性DOS功击。
0x0105
销售商的标识符。
0x0110
中继会话ID，对于PPPOE的数据报文也同样可以像DHCP报文一样被中断到另外的AC上终结，这个字段则是用来维护另一个连接的。
0x0201
服务名错误，当请求的服务名不被对端所接受时，会在响应的报文中携带这个标记。
0x0202
访问集中器名出错。
0x0203
一般性错误。
1.PADI
PPPOE发现阶段的第一步，也即是由用户首先发送这样一个报文。
用户主机是以广播的方式发送这个报文，所以该报文所对应的以太网帧的目的地址域应填充为全1，而源地址域填充用户主机的MAC地址。
广播包可能会被多个访问集中器接收到。
2.PADO
PPPOE发现阶段的第二步，也即是由访问集中器回应各用户主机发送的PADI报文，此时该报文所对应的以太网帧的源地址填充访问集中器的MAC地址，而目的地址则填充从PADI中所获取的用户主机的MAC地址。
3.PADR
PPPOE发现阶段的第三步，也即是由用户主机向访问服务器发送单播的请求报文。
当用户主机收到PADO报文后，会从这些报文中挑选一个访问集中器作为后续会话的对象。
由于用户主机在收到PADO报文后，就获知了访问集中器的MAC地址，因此PADR报文所以应的以太网帧的源地址填充用户主机的MAC地址，而以太网的目的地址填充为访问集中器的MAC地址。
4.PADS
PPPOE发现阶段的第四步，也即是最后一步，此时访问集中器当收到PADR报文时，就准备进入开始一个PPP的会话了，而此时访问集中器会为在这个会话分配一个唯一的会话进程ID，并在发送给主机的PADS报文中携带上这个会话ID。
当然如果访问集中器不满足用户所申请的服务的话，则会向用户发送一个PADS报文，而其中携带一个服务名错误的标记，而且此时该PADS报文中的会话ID填充0x0000。
5.PADT
PADT报文可能在会话进行开始之后的任意时间内被发送，主要是用来终止一个PPPOE会话的止。
它可以由主机或访问集中器发送，目的地址填充为对端的以太网的MAC地址。
会话阶段：
（ppp全过程）
数据帧在数据域中，不变的有如下信息：
协议的组成：
–链路控制协议（LCP）：
建立、拆除和监控PPP数据链路
–网络控制协议（NCP）：
协商网络层协议
–PPP扩展协议：
如压缩、链路捆绑
–PPP验证协议：
如PAP、CHAP
Ppp帧格式：
标志字段F为0x7E（0x表示7E），但地址字段A和控制字段C都是固定不变的，分别为0xFF、0x03。
PPP协议不是面向比特的，因而所有的PPP帧长度都是整数个字节。
与HDLC不同的是多了2个字节的协议字段。
协议字段不同，后面的信息字段类型就不同。
如：
0x0021——信息字段是IP数据报
0xC021——信息字段是链路控制数据LCP
0x8021——信息字段是网络控制数据NCP
0xC023——信息字段是安全性认证PAP
0xC025——信息字段是LQR
0xC223——信息字段是安全性认证CHAP
当信息字段中出现和标志字段一样的比特0x7E时，就必须采取一些措施。
因PPP协议是面向字符型的，所以它不能采用HDLC所使用的零比特插入法，而是使用一种特殊的字符填充。
具体的做法是将信息字段中出现的每一个0x7E字节转变成2字节序列（0x7D，0x5E）。
若信息字段中出现一个0x7D的字节，则将其转变成2字节序列（0x7D，0x5D）。
若信息字段中出现ASCII码的控制字符，则在该字符前面要加入一个0x7D字节。
这样做的目的是防止这些表面上的ASCII码控制字符被错误地解释为控制字符。
•Flag标志域：
每一个PPP数据帧均是以一个标志字节起始和结束的，该字节为0x7E。
•Address地址域：
该字节为0xFF。
由于PPP协议是被运用在点对点的链路上，点对点的链路可以唯一标示对方，因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址，所以该字节已无任何意义，按照协议的规定将该字节填充为全1的广播地址。
•Control控制域：
也没有实际意义，按照协议的规定通信双方将该字节的内容填充为0x03。
•Protocol协议域：
用来区分PPP数据帧中信息域所承载的数据报文的内容。
•Information：
信息域：
缺省时最大长度不能超过1500字节，其中包括填充域的内容。
•FCS校验域：
主要是对PPP数据帧传输的正确性进行检测的。
•Code域表明了此报文为哪种PPP协商报文；Identifier域用于进行协商报文的匹配；Length域为此协商报文长度（包含Code及Identifier域）；Data域所包含的为协商报文内容；Type为协商选项类型；其后的Length为此协商选项长度（包含Type域）；紧接着的Data域为协商选项具体内容。
PPP主要由三类协议组成：
链路控制协议族（LCP）、网络控制协议族（NCP）和PPP扩展协议族。
其中，链路控制协议主要用于建立、拆除和监控PPP数据链路；网络控制协议族主要用于协商在该数据链路上所传输的网络层数据包的类型以及网络层协议自身需要的一些内容（如IPCP要协商IP地址等）；PPP扩展协议族主要用于提供对PPP功能的进一步支持，实际上就是为提供一些特性服务，基于PPP协议框架设计的一些扩展协议。
同时，PPP还提供了用于网络安全方面的验证协议族（PAP和CHAP）。
LCP包有3类：
1.链路配置包，用于建立和配置链路（Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject）。
2.链路结束包被用于结束一个链路（Terminate-Request和Terminate-Ack）
3.链路维修包被用于管理和调试一个链路（Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request）。
确切的说一个LCP包被封装在PPP信息域中，该PPP 协议域表示类型为十六进制c021（链路控制协议）。
8
16
32bit
Variable
Code
Identifier（匹配请求和响应报文）
Length
Data
Code―十进制值，表示LCP数据包类型。
o1－Configure-Request配置请求报文
o2－Configure-Ack配置确定报文
o3－Configure-Nak支持对端的协商选项但不认可该项协商的内容，回复自己认可的配置方式并放入其中
o4－Configure-Reject配置拒接
o5－Terminate-Request终止请求
o6－Terminate-Ack终止确认
o7－Code-Reject代码拒绝
o8－Protocol-Reject
o9－Echo-Request
o10－Echo-Reply
o11－Discard-Request
o12－Link-QualityRepor
Identifier―十进制值，表示匹配Request和Reply。
Length―LCP数据包长度，包括Code、Identifier、Length和Data字段。
Data―可变长字段，可能包括一或多个配置选项。
•Address-and-Control-Field-Compress地址控制字段压缩
•Authentication-Protocol身份验证协议
•Protocol-Field-Compress协议域压缩
•Maximum-Recieve-Unit最大接受单元（4个字节）
•Multilink-Protocol多重协议（5个字节）
•Magic-Number避免在PPP帧的循环使用（6个字节）
•Callback回调（3个字节）
•MultilinkMRRU多链路协议（4个字节）
•Multilinkendpointdiscriminator:
多链路端点鉴别（23个字节）
•Linkdiscriminator：
l链路鉴别。
（4个字节）
Request：
Ack：
Terminationrequest报文：
Terminationack报文：
:
PPP扩展认证协议（EAP）是一个用于PPP认证的通用协议，可以支持多种认证方法。
EAP并不在链路控制阶段指定认证方法，而是把这个过程推迟到认证阶段。
这样认证方就可以在得到更多的信息以后再决定使用什么认证方法。
这种机制还允许PPP认证方简单地把收到的认证报文透传给后方的认证服务器，由后方的认证服务器来真正实现各种认证方法。
1.在链路阶段完成以后，认证方向对端发送一个或多个请求报文。
在请求报文中有一个类型字用来指明认证方所请求的信息类型，例如是对端的ID、MD5的挑战字、一次密码（OTP）以及通用令牌卡等。
MD5的挑战字对应于CHAP认证协议的挑战字。
典型情况下，认证方首先发送一个ID请求报文随后再发送其他的请求报文。
当然，并不是必须要首先发送这个ID请求报文，在对端身份是已知的情况下（如租用线、拨号专线等）可以跳过这个步骤。
2.对端对每一个请求报文回应一个应答报文。
和请求报文一样，应答报文中也包含一个类型字段，对应于所回应的请求报文中的类型字段。
3.认证方通过发送一个成功或者失败的报文来结束认证过程。
EAP可以支持多种认证机制，而无需在LCP阶段预协商过程中指定。
某些设备（如：
网络接入服务器）不需要关心每一个请求报文的真正含义，而是作为一个代理把认证报文直接透传给后端的认证服务器。
设备只需关心认证结果是成功还是失败，然后结束认证阶段。
EAP需要在LCP中增加一个新的认证协议，这样现有的PPP实现要想使用EAP就必须进行修改。
同时，使用EAP也和现有的在LCP协商阶段指定认证方法的模型不一致。
8
16
32bit
Variable
Type
Length
Authentication-Protocol
Data
Type―3
Length―4
Authentication-Protocol―对于PPP中的EAP，该字段为C227（十六进制）。
一个PPPEAP数据包封装在PPP数据链路层帧的Information字段，其中的Protocol字段表示类型为十六进制C227（PPPEAP）。
EAP数据包格式如下所示：
8
16
32bit
Variable
Code
Identifier
Length
Data
Code―Code字段识别EAP数据包类型。
EAP代码分配如下：
1、请求（Request）；2、响应（Response）；3、成功（Success）；4、失败（Failure）
Identifier―Identifier字段用于匹配响应和请求信息。
Length―Length字段表示EAP数据包的长度，包括Code、Identifier、Length和Data字段
Data―Data字段的格式取决于Code字段。
Ipcprequest报文：
Ipcpack报文：
Ccprequest报文：
Ccpack报文：
CHAP：
PPP挑战握手认证协议
（CHAP：
ChallengeHandshakeAuthenticationProtocol）
挑战握手认证协议（CHAP）通过三次握手周期性的认证对端的身份，在初始链路建立时完成，可以在链路建立之后的任何时候重复进行。
1.链路建立阶段结束之后，认证者向对端发送“挑战”消息。
2.对端用经过单向哈希函数计算出来的值做应答。
3.认证者根据它自己的预期哈希值的计算来检查应答，如果值匹配，认证得到承认；否则，连接应该终止。
4.经过一定的随机间隔，认证者发送一个新的挑战给对端，重复1到3。
通过递增改变的标识符和可变的挑战值，CHAP防止了重放攻击，重复挑战限制了对单个攻击的暴露时间，认证者控制挑战的频度。
该认证方法依赖于认证者和对端共享的密钥，密钥不是通过该链路发送的。
虽然该认证是单向的，但是在两个方向都进行CHAP协商，同一密钥可以很容的实现交互认证。
由于CHAP可以用在许多不同的系统认证中，因此可以用NAME字段作为索引，以便在一张大型密钥表中查找正确的密钥，这样也可以在一个系统中支持多个NAME密钥对，在会话中随时改变密钥。
CHAP要求密钥以明文形式存在，无法使用通常的不可回复加密口令数据库。
在大型设备中不适用，因为每个可能的密钥由链路的两端共同维护。
8
16
32
40bit
Type
Length
Authentication-Protocol
Algorithm
Type―3
Length―5
Authentication-Protocol―对于CHAP，为C223（Hex）。
Algorithm―Algorithm字段为八位字节，表示使用的认证方法。
CHAP数据包结构如下所示：
8
16
32bit
Variable
Code>
Identifier
Length
Data...
Code―识别CHAP数据包类型。
CHAP代码具有以下几种：
1、Challenge；2、Response；3、Success；4、Failure。
Identifier―用于匹配Challenges、Responses和Replies信息。
Length―CHAP数据包的长度，包括Code、Identifier、Length和Data字段。
Data―0或更多八位字节。
该字段格式取决于Code字段。
对于Success和Failure，Data字段包括一个独立执行的可变信息字段。
服务器先发给主机的chapchanllage报文：
主机回复服务器chapresponse报文
服务器发给主机的chapsuccess报文：
PPP的协商过程
PPP协议在进行LCP协商的时候，双方是互相发送configure-request，然后向对方回应configure-ack，也可以只有一方发送，另一方回应。
PPP在建立链路之前要进行一系列的协商过程，过程如下：
PPP首先进行LCP协商，协商内容包括：
MTU（最大传输单元）、魔术字（magicnumber）、验证方式、异步字符映射等选项（详见RFC1661）LCP协商成功后，进入Establish（链路建立）阶段，如配置了CHAP或PAP验证，便进入CHAP或PAP验证阶段，验证通过后才会进入网络阶段协商（NCP），如IPCPIPXCP、BCP的协商，任何阶段的协商失败都将导致链路的拆除，魔术字，主要用于检测链路自环，PPP靠发送EchoRequest、EchoReply报文来检测自环和维护链路状态，如连续发现有超过最大自环允许数目EchoRequest报文中魔术字与上次发送魔术字相同，则判定网络发生自环现象，如链路发生自环，则就需采取相应措施对链路复位另外，LCP发送configrequest时也可以检测自环，LCP发现自环后，在发送一定数目的报文后也会复位链路，如果PPP发送的EchoRequest报文产生丢失，则在连续丢失最大允许丢失的个数之后，将链路复位，以免过多的无效数据传输，异步字符映射用于同异步转换。
PAP的验证过程
PAP为两次握手协议，它通过用户名及口令来对用户进行验证。
PAP验证过程如下：
当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表或radius服务器，查看是否有此用户，口令是否正确，如正确则会给对端发送ACK报文，通告对端已被允许进入下一阶段协商，否则发送NAK报文，通告对端验证失败，此时并不会直接将链路关闭，只有当验证不过次数达到一定值时，才会关闭链路，来防止因误传、网络干扰等造成不必要的LCP重新协商过程。
PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获便有可能对网络安全造成极大的威胁。
因此，它适用于对网络安全要求相对较低的环境。
CHAP的验证过程
CHAP为三次握手协议，它的特点是：
只在网络上传输用户名，而并不传输用户口令，因此，它的安全性要比PAP高。
CHAP的验证过程为：
首先由验证方向被验证方发送一些随机产生的报文，并同时将本端的主机名附带上一起发送给被验证方，被验证方接到对端对本端的验证请
PAP是首先由被验证方将自己的用户名及密码送给验证方，而CHAP验证是首先由验证方发起验证过程的，主要区别为PAP为明文传送密码，而在CHAP验证过程中，密码是不在线传送的。
Ppp运行过程：
•PPP的运行过程分为3个阶段
–链路建立阶段（LCP）
–验证阶段（Authenticate）
–网络控制协商阶段（NCP）
•1、PPP由不活动（dead）状态到链路UP状态，大体上可分为3个阶段，分别是链路建立阶段、验证阶段、网络控制协商阶段；
•2、链路建立阶段主要进行链路控制协商（LCP），协商内容包括：
MRU（最大接收单元）、魔术字（magicnumber）、验证方式、异步字符映射等选项（详见RFC1661）；
•3、LCP协商成功后，如配置了CHAP或PAP验证，便进入CHAP或PAP验证阶段；
•4、验证通过后才会进入网络控制协商阶段（NCP），如IPCP、IPXCP的协商；IPCP的协商内容目前主要包括IP地址、TCP等包文头的头压缩等。
•5、网络控制协商成功后，链路就会UP，就可以开始接收与发送协商指定的网络层包文了。
•任何阶段的协商失败都将导致链路的拆除。
LCP
LCP数据报文是在链路建立阶段被交换的，它作为PPP的净载荷被封装在PPP数据帧的信息域中，此时PPP数据帧的协议域固定填充0xC021，但在链路建立阶段的整个过程中信息域的内容是在变化的，一共包括12种LCP数据报文，依据各报文的的功能又将其具体细化为以下三类：
•链路配置报文，主要用来建立和配置一条链路的。
•链路终止报文，主要用来终止一条链路的。
•链路维护报文，主要用来维护和调试链路的。
Code代码域：
长度为一个字节，主要是用来标识LCP数据报文的类型的。
在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。
Identifier标识域：
长度为一个字节，其目的是用来匹配请求和响应报文。
一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文（Config-Request报文），而这几个请求报文的数据域可能是完全一样的，而仅仅是它们的标志域不同罢了。
通常一个配置请求报文的ID是从0x01开始逐步加1的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可能是Config-Ack、Config-Nak和Config-Reject三种报文中的一种）来回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致，当通信设备收到回应后就可以将该回应与发送时的进行比较来决定下一步的操作。
Length长度域的内容=总字节数据（代码域+标志域+长度域+数据域）。
Data数据域的内容依据不同LCP数据报文的内容而有所不同。
链路配置报文主要是用来协商链路的配置参数选项的，因此这种报文的数据域要携带许多配置参数选项。
链路配置报文主要包括Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。
当通信双方需要建立链路时，无论哪一方都需要发送Config-Request报文并携带自已所希望协商的配置参数选项，常见的配置参数选项包括：
•Multilink-Protocol多重协议
•Address-and-Control-Field-Compress地址控制字段压缩
•Authentication-Protocol身份验证协议
•Protocol-Field-Compress协议
升级会员 