PPPoE使用原理及PPPoE服务器的制作.doc

PPPoE使用原理及PPPoE服务器的制作 PPPoE使用原理及PPPoE服务器的制作 40目 录摘 要11、PPPoE技术简介11.1 PPPOE的发展过程11.2 PPPOE的特点11.3 PPPOE的帧格式22、PPPOE的实现42.1概述42.2实现过程分析52.2.1发现阶段52.2.2链路建立阶段92.2.3认证阶段122.2.4网络协议信息配置阶段183、PPPoE服务器的制作203.1前期准备203.2安装步骤203.2.1安装PPPoE协议203.2.2配置并起用路由和远程访问服务233.2.3设置具有远程登录权限的用户信息313.2.4配置身份验证方法353.2.5设置PPPoE协议的相关配置信息383.3验证Router/ DSL Router的 PPPoE相关功能的方法：39摘 要本文首先对PPPoE的发展过程、特点及帧格式进行了简要分析，接着在实验室条件下结合对实际运行时所捕获的数据包的分析，详细介绍了使用PPPoE拨号模式建立连接的过程，并对在连接建立过程中各种具体的数据帧及其所包含字段的含义做了详细的阐述。文章的第二部分详细介绍了在实验室现有条件下使用RASPPPoE协议驱动及Windows2003 Server构建PPPoE接入服务器的方法。在最后还简单介绍了使用PPPoE服务器验证PPPoE拨号功能是否正常的方法。关键字帧格式PAP认证CHAP认证RASPPPoE路由及远程访问服务器1、PPPoE技术简介1.1 PPPOE的发展过程同ADSL技术的发展过程一样，modem接入技术的发展也面临一些相互矛盾的目标：既要通过同一个用户前置接入设备连接远程的多个用户主机，又要提供类似拨号一样的接入控制，计费等功能，而且要尽可能地减少用户的配置操作。为了解决上述问题，PPPoE拨号技术应运而生，1998年后期问世的基于以太网的点对点协议（PPPoverEthernet）技术是由Red back网络公司、客户端软件开发商Router Ware公司以及Worldcom子公司UUNET Technologies公司在IETFRFC的基础上联合开发的。通过把最经济的局域网技术以太网和点对点协议的可扩展性及管理控制功能结合在一起，网络服务提供商和电信运营商便可利用可靠和熟悉的技术来加速部署高速互联网业务。它使服务提供商在通过数字用户线、电缆调制解调器或无线连接等方式，提供支持多用户的宽带接入服务时更加简便易行。同时该技术亦简化了最终用户在选择这些服务时的配置操作。1.2 PPPOE的特点PPPoE在标准PPP报文的前面加上以太网的报头，使得PPPoE提供通过简单桥接接入设备连接远端接入设备，并可以利用以太网的共享性连接多个用户主机，在这个模型下，每个用户主机利用自身的PPP堆栈，用户使用熟悉的界面。接入控制，计费等都可以针对每个用户来进行。概括来讲，PPPoE具有以下的几处优点：1、 安裝与操作方式类似于以往的拨号网络模式，方便用户使用。2、 用户处的XDSL调制解调器可以不进行任何特殊配置。3、 允许多个用户共享一个高速数据接入链路。4、 终端用户可同时接入多个ISP，这种动态服务选择的功能可以使ISP更容易创建并可提供新的业务。5、 兼容现有所有的XDSL Modem和DSLAM。6、 可与ISP有接入结构相融合。1.3 PPPOE的帧格式参数取值：ETHER_TYPE:0x8863 Discovery Stage0x8864 PPP Session StageCODE 1:0x00 PPP Session Stage0x09 PPPoE Active Discovery Initiation (PADI) packet0x07 PPPoE Active Discovery Offer (PADO) packet0x19 PPPoE Active Discovery Request (PADR) packet0x65 PPPoE Active Discovery Session-confirmation (PADS) packet0xa7 PPPOE Active Discovery Terminate (PADT) packetTAG_TYPES：0x0000 End-Of-List0x0101 Service-Name0x0102 AC-Name0x0103 Host-Uniq0x0104 AC-Cookie0x0105 Vendor-Specific0x0110 Relay-Session-Id0x0201 Service-Name-Error0x0202 AC-System-Erro0x0203 Generic-ErrorPROTOCOL:0x 0001Padding Protocol填料协议0x0003 to 0x 001f reserved (transparency inefficient)保留（透明度效率低的）0x 007d reserved (Control Escape)保留（控制逃逸）0x 00cf reserved (PPP NLPID)保留(PPP NLPID)0x 00ff reserved (compression inefficient)保留(压缩效率低的)0x 8001 to0x 801f unused（未使用）0x 807d unused（未使用）0x 80cf unused（未使用）0x 80ff unused（未使用）0x c021 Link Control Protocol链路控制协议0x c023 Password Authentication Protocol密码认证协议0x c025 Link Quality Report链路品质报告0x c223 Challenge Handshake AuthenticationCODE2：0x01: Configure-Request0x02: Configure-Ack0x03: Configure-Nak0x04: Configure-Reject0x05: Terminate-Request0x06: Terminate-Ack0x07: Code-Reject0x08: Protocol-Reject0x09: Echo-Request0x10: Echo-Reply0x11: Discard-Request2、PPPOE的实现2.1概述总的说来，建立一个基于以太网的点对点会话过程包括发现和会话两个阶段，而会话阶段又可具体分为认证阶段和网络协议信息的配置阶段。在不同的阶段使用的具体的协议类型均有所不同：在发现阶段，PPPoE帧格式中的“ETHER_TYPE”字段填充值为0x8863，相应的payload1内封装的是PAD协议（PPPoE Active Discovery）。在整个会话阶段，PPPoE帧格式中的“ETHER_TYPE”字段填充值均为0x8864，其中在链路建立阶段payload1内封装的是PPP协议中的LCP（Link control protocol）协议；在认证阶段使用之前协商达成的认证协议（该类认证协议主要包括点对点认证协议PAP，询问式信号交换鉴别协议CHAP）进行认证；在网络协议信息的配置阶段使用PPP协议中NCP（Network control protocol）进行网络信息的配置，其中IPCP（IP control protocol）是NCP中最主要的一种。为了更详细的对该实现过程进行说明，现使用Ethereal软件对一个完整的PAP认证过程进行抓包分析，以下过程中“Giga-Byt_46:f5:fc”代表PPPoE服务器，“MS-NLB-PhysServer-16_18:01:00:06”代表需要进行PPPoE接入服务的客户端No. Time Source Destination Protocol Info/*发现阶段开始*/ 10 35.863660 MS-NLB-PhysServer-16_18:01:00:06 Broadcast PPPoED Active Discovery Initiation (PADI) 11 35.863697 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPPoED Active Discovery Offer (PADO) 12 35.923730 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPPoED Active Discovery Request (PADR) 13 35.924311 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPPoED Active Discovery Session-confirmation (PADS)/*发现阶段结束*/*/*开始使用PPP LCP进行链路建立*/ 14 36.038766 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP LCP Configuration Request 15 36.039087 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP LCP Configuration Request 16 36.039143 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP LCP Configuration Ack 17 36.058773 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP LCP Configuration Reject 18 36.058833 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP LCP Configuration Request 19 36.078199 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP LCP Configuration Nak 20 36.078254 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP LCP Configuration Request 21 36.098637 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP LCP Configuration Ack /*链路建立结束，经协商采用PAP这种认证方式*/*/* PAP认证开始*/ 22 36.099129 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP PAP Authenticate-Request 23 36.100736 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP PAP Authenticate-Ack /*PAP认证结束，客户端通过服务器认证*/ * /*开始使用PPP IPCP协议进行网络协议信息的配置，通过该过程客户端获得一个由服务器分配的公网IP*/ 24 36.103020 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP CCP Configuration Request 25 36.103070 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP IPCP Configuration Request 26 36.124277 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP IPCP Configuration Request 27 36.124346 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP IPCP Configuration Reject 28 36.124741 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP LCP Protocol Reject 29 36.125236 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP IPCP Configuration Reject 30 36.125287 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP IPCP Configuration Request 31 36.143984 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP IPCP Configuration Request 32 36.144036 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP IPCP Configuration Nak 33 36.148414 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP IPCP Configuration Ack 34 36.163695 MS-NLB-PhysServer-16_18:01:00:06 Giga-Byt_46:f5:fc PPP IPCP Configuration Request 35 36.163745 Giga-Byt_46:f5:fc MS-NLB-PhysServer-16_18:01:00:06 PPP IPCP Configuration Ack/*网络协议信息的配置过程结束，通过该过程客户端获得一个由服务器分配的公网IP*/2.2实现过程分析以下将结合该实例按顺序对各个认证阶段做具体的介绍：2.2.1发现阶段 在发现过程中用户主机以广播方式寻找可以连接的所有接入设备，获得其以太网MAC地址。然后选择需要连接的用户主机并最后获得所要建立的PPP会话的SESSION_ID。在发现过程中节点间是客户端服务器关系， 一个用户主机（客户端）最终要发现一个接入设备（服务器）。在网络拓朴中，一般有不止一个的接入设备可以通信，发现阶段允许用户主机发现所有的接入设备，并从中选择一个。当发现阶段结束时， 用户主机和接入设备之间都获得了可供以太网上建立PPP连接的全部信息。发现阶段保持无连接状态直到一个PPP会话的建立。一旦PPP连接建立，则用户主机和接入设备都必须为PPP虚拟端口分配资源。典型的发现（Discovery）阶段共包括4个步骤：步骤一：用户主机发出PPPOE有效发现初始（PADI）包。以太网目的地址为广播地址0xffffffff， CODE1 字段为0x09， SESSION_ID为0x0000。PADI包必须至少包含一个服务名称类型（Service-Name）的标签（标签类型字段为0x0101）， 向接入设备提出所要求提供的服务。一个完整的PADI（包括PPPOE头）不能超过1484字节，以留下充足的预留给agent设备增加Relay-Session-Id标识。在上例中编号10的数据包即为PADI包，该数据包由客户端发向服务器端发送，将该数据包展开可以得到如下的结构：Frame 10 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: MS-NLB-PhysServer-16_18:01:00:06 (02:10:18:01:00:06), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Type: PPPoE Discovery (0x8863)PPP-over-Ethernet Discovery 0001 . = Version: 1 . 0001 = Type: 1 Code: Active Discovery Initiation (PADI) (0x09) Session ID: 0x0000 Payload Length: 12PPPoE Tags Host-Uniq: 10046100Service-Name:步骤二：接入设备收到在服务范围内的PADI包后，发送PPPOE有效发现提供包（PADO）以响应请求。其CODE1字段为0x07 ，SESSION_ID仍为0x0000。PADO包必须包含一个接入设备名称类型（AC-Name）的标签（标签类型字段为0x0102）以及一个或多个服务名称类型标签，表明可向用户主机提供的服务种类。在上例中编号11的数据包即为PADO包，该数据包由服务器端向客户端发送，将该数据包展开可以得到如下的结构：Frame 11 (68 bytes on wire, 68 bytes captured)Ethernet II, Src: Giga-Byt_46:f5:fc (00:16:e6:46:f5:fc), Dst: Type: PPPoE Discovery (0x8863)PPP-over-Ethernet Discovery 0001 . = Version: 1 . 0001 = Type: 1 Code: Active Discovery Offer (PADO) (0x07) Session ID: 0x0000 Payload Length: 48PPPoE Tags Service-Name: AC-Name: 8I915ME-GV Host-Uniq: 10046100AC-Cookie: 52535045021018010006989C5930A4A6C701注意：为防止DOS（Denial of Service）攻击，接入设备应该可以使用AC-Cookie属性，接入设备应可以根据PADI中的源地址唯一再生成一个值，这样就可以保证PADR的源地址是真正可达，同时限制与这个地址同时连接数量。这个算法细节并没有在RFC2516中具体描述。虽然AC-Cookie在反DOS攻击方面很有效，但它并不能防止所有DOS攻击，在接入设备上也可以采用其他方法来对抗DOS。步骤三：用户主机在可能收到的多个PADO包中选择一个合适的接入设备，选择的原则是根据PADO中接入设备名称类型标签和服务名称类型标签的内容。然后向所选择的接入设备发送PPPOE 有效发现请求（PADR）包。其CODE1 字段为0x19，SESSION_ID仍为0x0000。PADR包必须包一个服务名称类型标签，确定向接入设备请求的服务种类。当一个用户主机在确定时间没有收到PADO，他会重发一个PADI，同时等待两倍的时间。这种过程可以根据需要重复多次。在上例中编号13的数据包即为PADR包，该数据包由客户端向服务器端发送，将该数据包展开可以得到如下的结构：Frame 12 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: MS-NLB-PhysServer-16_18:01:00:06 (02:10:18:01:00:06), Dst: Type: PPPoE Discovery (0x8863)PPP-over-Ethernet Discovery 0001 . = Version: 1 . 0001 = Type: 1 Code: Active Discovery Request (PADR) (0x19) Session ID: 0x0000 Payload Length: 34PPPoE Tags Service-Name: Host-Uniq: 10046100AC-Cookie: 52535045021018010006989C5930A4A6C701步骤四：接入设备收到PADR包后准备开始PPP会话，它发送一个PPPOE 有效发现会话确认（ PADS）包。其CODE1 字段为0x65 ， SESSION_ID为接入设备所产生的一个唯一的PPPOE会话标识号码。0xffff作为预留资源，目前不能被使用作SESSION_ID。PADS包也必须包含一个服务名称类型的标签确认向用户主机提供的服务。当用户主机收到PADS包确认后，双方就进入PPP会话阶段。如果接入设备不能识别PADR中的服务名称类型的标签，则会回一个包含服务名称错误（ Service-Name-Error ） 标签的PADS ，其SESSION_ID仍然是0x0000。如果用户主机在确定时间没收到PADS包，与没收到PADO作同样处理。在上例中编号13的数据包即为PADS包，该数据包由服务器端向客户端发送，将该数据包展开可以得到如下的结构：Frame 13 (32 bytes on wire, 32 bytes captured)Ethernet II, Src: Giga-Byt_46:f5:fc (00:16:e6:46:f5:fc), Dst: MS-NLB-PhysServer-16_18:01:00:06 (02:10:18:01:00:06) Type: PPPoE Discovery (0x8863)PPP-over-Ethernet Discovery 0001 . = Version: 1 . 0001 = Type: 1 Code: Active Discovery Session-confirmation (PADS) (0x65) Session ID: 0x0010 Payload Length: 12PPPoE Tags Service-Name: Host-Uniq: 10046100除了以上的发现过程所提及的数据包外，还有一种PPPOE有效发现终止（PADT）包，在一个PPP会话建立后它随时可由用户主机或接入设备中任何一方发送，指示PPP会话已终止。PADT包不需要任何标签，其CODE字段为0xa7 ， SESSION_ID 为需要终止的PPP会话的会话标识号码。现作为范例提供一个PADT包的展开结构：Frame 9 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: MS-NLB-PhysServer-16_18:01:00:06 (02:10:18:01:00:06), Dst: Giga-Byt_46:f5:fc (00:16:e6:46:f5:fc) Type: PPPoE Discovery (0x8863)PPP-over-Ethernet Discovery 0001 . = Version: 1 . 0001 = Type: 1 Code: Active Discovery Terminate (PADT) (0xa7) Session ID: 0x000e Payload Length: 12PPPoE Tags Host-Uniq: 10046100Service-Name:2.2.2链路建立阶段为了在点到点链路上建立通信，PPP链路的每一端在链路建立阶段必须首先发送LCP包进行数据链路配置。链路建立之后，PPP提供可选的认证阶段，可以在进入NCP阶段之前实行认证。缺省情况下，认证并非是强制执行的，如果需要链路认证，PPP实现必须在链路建立阶段指定“认证协议配置”选项。这些认证协议主要用于主机和路由器，这些主机和路由器一般通过交换电路线或者拨号线连在PPP网络服务器上，但是也可以通过专线实现。服务器可以用主机或路由器的连接身份来作为网络层协商的选项。LCP包主要有三类：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包里没有版本域。一个正确的LCP协商过程总是对带有可以识别的LCP包的未知协议和代码进行响应。这样倘若一个确定性的可靠的机制用于其他版本的执行，不管哪个配置选项被允许，所有的LCP链路配置，链路终止和代码-拒绝包（代码1到7）总被发送，就像没有配置选项被协商一样。特别是，每个配置选项都指定缺省值。这就保证了即便是当错误的相信1个已经结束的链路的仍是是开启时，这样的LCP包总是可以识别的。当1个LCP包被封装在PPP信息域中，该PPP协议域（即下图中的PROTOCOL位）表示类型为十六进制c021。链路控制协议包格式的摘要如下，域被从左往右传送。其中CODE2字段的填充字符含义如下：w Configure-Request：若要执行建立一个连接或对链路默认配置进行修改的必须传送一个Configure-Request。任何想要的对链路默认配置的改变被填充在选项域。默认配置中应该不包括所要进行修改的配置选项。接收Configure-Request的一端，必须传送适当的答复。在Configure-Request 数据包中，DATA字段具体化为选项域，选项域是长度的变量，并包含零个或多个发送方需要协商的配置选项的列表。全部配置选项总是被同时协商。w Configure-Ack：如果对端收到Configure-Request配置选项，并且其中所包含的全部的配置项都是能接受的，那么该执行必须传送一个Configure-Ack。该配置确认选项不能被重命令或更改。所传输的Configure-Ack中，标识符域必须与最后传送的Configure-Request完全匹配。另外，Configure-Ack中的配置选项必须与最后收到的Configure-Request完全匹配。错误包将会被被静静的丢弃。在Configure-Ack 数据包中，DATA字段具体化为选项域，选项域是长度的变量，并包含零个或多个发送方确认的配置选项的列表。全部配置选项总是被同时确认。全部配置选项总是同时没有应答的。w Configure-Nak：如果每一个收到的配置选项要求是可认知的，但是一些值不能被接受，那么该执行必须传送一个Configure-Nak。选项域仅由来自Configure -Request的不可接受的配置选项所填充。且来自Configure-Request的可接受配置选项不能被重命令。没有值域的选项（布尔选项）一定使用Configure-Reject答复来代替。当使用Configure-Nak对Configure-Request进行答复时，需将Configure-Request中包含的不可配置且仅有一个单一要求的配置选项修正到可接受的值然后再发出。此时若Configure-Request中的不可接受配置项与默认值不一致，可以将其恢复为默认值。在这个过程中若一个详细的不可接受的配置选项类型能以多个值被列出时，Configure-Nak必须包括Configure-Nak发送方所接受的全部选项值的列表。包括Configure-Request中当前可接受的值。 最后，一个执行可以被配置到要求明确的配置选项。若该选项未被列出，则该选项可以被添加到没有应答的配置选项的列表中，以便提示对端添加该选项到Configure-Request包中。任何用于该选项的值域必须指出Configure-Nak发送方的可接受值。 在一个Configure-Nak接收中，标识符域必须匹配最后一个传输的Configure-Request。否则错误包被静静的丢弃。 若在发送一个新的Configure-Request前接受到Configure-Nak，Configure-Request将会按照Configure-Nak中指定的配置选项进行配置。若Configure-Nak中的配置选项提供多种可能的情况，Configure-Request发送端应该选择一个单一的值包含到下一个Configure-Request包中。一些配置选项有可变长度。既然没有应答的选项被Configure-Nak发送端修正了，该执行必须能够处理与原Configure-Request不同的选项长度。在Configure-Nak 数据包中，DATA字段具体化为选项域，选项域是长度的变量，包含零到多个没有应答的发送方的配置选项。全部配置选项总是同时没有应答的。w Configure-Reject：如果从Configure-Request中收到的一些配置选项是不可辨认的或者不被商议所接受（由网络管理员配置的），则该执行必须传送一个 Configure-Reject。选项域仅由来自Configure-Request不可接受的配置选项所填充。所有可识别的和可通过商议解决的配置选项被过滤出Configure-Reject，且这些配置选项必须不被任何方式重定义或修改。 在发送Configure-Reject时，标识符域必须匹配最后传输的Configure-Request。另外，Configure-Reject的配置选项必须是最后传输的Configure-Request的正确的子集。错误包被静静的丢弃。当一个新的Configure-Request发送的时候，必须不包含任何所收到的Configure-Reject中列出的配置选项。在Configure-Reject 数据包中，DATA字段具体化为选项域，选项域是长度的变量，包含零或者多个发送者拒绝的配置选项列表。全部的配置选项总是被同时拒绝的。w Terminate-Request and Terminate-Ack：LCP包含Terminate-Request 和 Terminate-Ack代码是为了提供关闭一个连接的机制。一个执行想要关闭一个连接应该传送一个Terminate-Request。Terminate-Request包应该持续发送，直到收到Terminate-Ack、底层显示已经关闭了，或者已经发送充分大的数量，以致对端有确切地理由关闭。接收到一个Terminate-Request后，必须传送一个Terminate-Ack。接收一个未被引出的Terminate-Ack表示对端处在Closed（关闭）或Stopped（停止）状态，或者需要另外再商议。数据域为零个或多个八位字节，包含发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束可以由长度指出。w Code-Reject：一个带有未知代码的LCP包的接收显示该数据包事由对端一个不同的版本的协议生成的。此时必须传送一个Code-Reject报告回给未知代码的发送方。当对端接受到一个基本的Code-Reject后，既然该情形不像能被自动矫正，执行应该报告问题并结束连接。被拒绝的包域包含被拒绝的LCP包的拷贝。它由信息域开始，并且不包括任何数据链路层的头或者FCS。被拒绝的包必须被缩短来符合peer指定的MRU。w Protocol-Reject：一个带有未知协议域的PPP包的接收显示对端试图使用一个不支持的协议。这通常发生在对端试图配置一个新的协议时。如果LCP自动处理处于Opened（打开）状态，那么必须通过传送一个Protocol-Reject报告回对端。在Protocol-Reject接收中，该类包的接收端必须及早停止发送被指出的协议的包。Protocol-Reject包只能在LCP的Opened（打开）状态被发送。在其他不是Opened（打开）状态下接收到的Protocol-Reject包应该被静静的丢弃。被拒绝的信息域包含被拒绝的包的拷贝。由信息域开始，不包含任何数据链路层头或FCS。被拒绝的信息必须削减来适应peer制定的MRU。w Echo-Request and Echo-Reply：LCP包含Echo-Request 和 Echo-Reply代码来供给一个数据链路层回送机制来演习链路双方的使用。这对调试、链路质量检测、执行测试和众多的其他功能有帮助。一个在LCP的Opened（打开）状态接收Echo-Request时，必须传送一个Echo-Reply。Echo-Request 和 Echo-Reply包必须仅在LCP的Opened（打开）状态下发送，在其他不是Opened（打开）状态下接收到的Echo-Request 和 Echo-Reply包应该被静静的丢弃。数据域是零或者多个八位字节，包含被发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束由长度指出。w Discard-Request：LCP包含一个Discard-Request代码为了供给一个用于演习本地到遥 远的链路方向的数据链路层接收器机制。有助于调试、执行测试、和众多的其他功能。Discard-Request包必须仅在LCP的Opened（打开）状态被发送。接收中，接收器必须静静的丢弃任何收到的Discard-Request。数据域是零或者多个八位字节，包含被发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束由长度指出。2.2.3认证阶段LCP协商主要完成某些链路路特性和认证方式的协商，LCP协商成功后，用户根据协商的认证方式向接入服务器发起认证请求，用户认证的方式采用PAP、CHAP或MS-CHAP方式：1、PAP认证PAP为两次握手认证，口令为明文。PAP认证过程中拨号用户首先发送用户名和口令到接入服务器，接入服务器通过RADIUS协议到RADIUS服务器上去查看是否有此用户，口令是否正确，然后发送相应的响应：在上例中编号为22的数据包显示了第一次的握手过程，该数据包由客户端向服务器发送： Frame 22 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: MS-NLB-PhysServer-16_18:01:00:06 (02:10:18:01:00:06), Dst: Giga-Byt_46:f5:fc (00:16:e6:46:f5:fc) Type: PPPoE Session (0x8864)PPP-over-Ethernet Session 0001 . = Version: 1 . 0001 = Type: 1 Code: Session Data (0x00) Session ID: 0x0010 Payload Length: 20Point-to-Point Protocol Protocol: Password Authentication Protocol (0xc023)PPP Password Authentication Protocol Code: Authenticate-Request (0x01) Identifier: 0x01 Length: 18 Data (14 bytes) Peer ID length: 6 bytes Peer-ID (6 bytes) Password length: 6 bytes Password (6 bytes)在上例中编号为23的数据包显示了第二次的握手过程，该数据包由客户端向服务器发送，其展开结构如下：Frame 23 (27 bytes on wire, 27 bytes captured)Ethernet II, Src: Giga-Byt_46:f5:fc (00:16:e6:46:f5:fc), Dst: MS-NLB-PhysServer-16_18:01:00:06 (02:10:18:01:00:06) Type: PPPoE Session (0x8864)PPP-over-Ethernet Session 0001 . = Version: 1 . 0001 = Type: 1 Code: Session Data (0x00) Session ID: 0x0010 Payload Length: 7Point-to-Point Protocol Protocol: Password Authentication Protocol (0xc023)PPP Password Authentication Protocol Code: Authenticate-Ack (0x02) Identifier: 0x01 Length: 5 Data (1 byte) Message length: 0 bytes2、CHAP认证 CHAP为三次握手认证，口令为密文。CHAP的认证步骤如下：1） 认证方式协商阶段结束之后，认证者（服务器端）向对端发送“挑战”消息。2） 对端用经过单向哈希函数（16位，MD5）计算出来的值做应答。3） 认证者根据它自己的预期哈希值的计算来检查应答，如果值匹配，认证得到承认；否则，连接应该终止。4） 经过一定的随机间隔，认证者发送一个新的挑战给对端，重复1到3。在上述的认证过程中挑战包是CHAP的开始，认证者必须传送代码字段为1的CHAP包，其他挑战数据包必须在有效应答数据包成功接收之后或者可选重试计数器计满后发送。为了确保连接没有被更改，挑战包也可以在NCP阶段的任何时候发送。对端应该随时为认证阶段和NCP阶段的挑战做好准备，任何时候收到挑战包，对端都必须传送代码字段为2（应答）的CHAP数据包。无论何时，如果收到应答包，认证者都必须把应答值和自己计算的预期值比较，基于这种比较，认证者必须发送成功（Success）或者失败（Failure）CHAP包。这里需要注意的是，由于成功包可能丢失，认证者在NCP阶段中必须允许重复的应答包，为了发现更改的名字和密钥，收到具有当前挑战标识符的应答包必须返回与先前挑战同样的响应代码（消息部分可能不相同），在任何其他阶段收到的任何应答包必须静静丢弃。如果“失败包”丢失，认证者终止了链路，那么可以由LCP的“终止请求”和“终止应答”来指示认证失败。采用CHAP认证方法具有以下几种优点：1） 通过递增改变的标识符和可变的挑战值，CHAP防止了重放攻击，重复挑战限制了对单个攻击的暴露时间，认证者控制挑战的频度。2） 该认证方法依赖于认证者和对端共享的密钥，密钥不是通过该链路发送的。虽然该认证是单向的，但是在两个方向都进行CHAP协商，同一密钥可以很容易的实现交互认证。3） 由于CHAP可以用在许多不同的系统认证中，因此可以用NAME字段作为索引，以便在一张大型密钥表中查找正确的密钥，这样也可以在一个系统中支持多个NAME/密钥对，在会话中随时改变密钥。不可避免的，CHAP认证方法在拥有上述种种优点的同时，也暴露出了一些缺点，最主要的就是CHAP要求密钥以明