PPP协议和PPP0E协议ISSUE1.0.docx

《PPP协议和PPP0E协议ISSUE1.0.docx》由会员分享，可在线阅读，更多相关《PPP协议和PPP0E协议ISSUE1.0.docx（73页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、课程 BA000003 PPP协议和PPP0E协议ISSUE1.0Huawei Technologies目 录课程说明1课程介绍1课程目标1第1章 概述2第2章 PPP协议8第3章 PPPOE协议48附录 缩略词表74课程说明课程介绍本教材为宽带产品工程师培训公共课程。本课程介绍PPP协议和PPPOE协议。课程目标完成本课程学习，学员能够：l 了解SLIP协议的基本原理。l 掌握PPP协议的基本原理。l 掌握LCP协议和NCP协议数据报文的交换过程。l 掌握PPPOE协议的基本原理。第1章 概述SLIP的全称是Serial Line IP，出现在80年代中期，并被使用在BSD UNIX主机和S

2、UN的工作站上。因为SLIP简单好用，所以后来被大量使用在线路速率从1200bps到19.2Kbps的专用线路和拨号线路上互连主机和路由器，到目前为止仍有大部分UNIX主机保留对该协议的支持。在80年代末90年代初期，被广泛用于家庭中每台有RS232串口的计算机和调制解调器连接到Internet。SLIP的帧格式由IP包加上END字符组成。通过在被发送IP数据报的尾部增加特殊的END字符（0xC0 ）从而形成一个简单的SLIP的数据帧，而后该帧会被传送到物理层进行发送。为了防止线路噪声被当成数据报的内容在线路上传输，通常发送端在被传送数据报的开始处也传一个END字符。如果线路上的确存在噪声，则

3、该数据报起始位置的END字符将结束这份错误的报文，这样当前正确的数据报文就能正确的传送了，而前一个含有无意义报文的数据帧会在对端的高层被丢弃。END是判断一个SLIP帧是否结束的标志。如果要传送的IP包中正好有一个字符0xc0要传送，为了避免它被当作END字符，要用连续的两个字节0xdb和0xdc来代替它。如果要传送的是0xdb，那么就用连续传输两个字节0xdb和0xdd来代替它。 SLIP只支持IP协议，对IPX等缺乏支持。并且，由于帧格式中没有类型字段，致使如果一条串行线路如果用于SLIP，就不能同时使用其它协议。 SLIP不提供纠错机制，错误只能依靠上层协议实现。 SLIP帧的封装格式非

4、常简单，通信双方无需在数据报发送前协商任何配置参数选项（在PPP协议中需协商配置参数选项），所以双方IP层通信前必需先获知对方的IP地址，才能进行网络层的通信，否则链路层发送的数据帧在被送到对方网络层时将无法进行转发。正是由于上面的诸多缺点，导致了SLIP很快的被后面要讲的PPP协议所替代。第2章 PPP协议PPP协议主要包括三部分：LCP（Link Control Protocol）链路控制协议、NCP（Network Control Protocol）和PPP的扩展协议（如Multilink Protocol）。随着网络技术的不断发展，网络带宽已不再是瓶颈，所以PPP扩展协议的应用也就越来

5、越少，因此往往人们在叙述PPP协议时经常会忘记它的存在。我们在提及PPP协议的报文封装格式时，不可不先提一下HDLC协议。HDLC也是最常用的数据链路层协议，它是从SDLC协议衍进过来的，许多常用的数据链路层协议的封装方式都是基于HDLC的封装格式的，同样PPP协议也不例外，它也采用了HDLC的定界帧格式。以下为对PPP数据帧封装格式的一点说明：每一个PPP数据帧均是以一个标志字节起始和结束的，该字节为0x7E。紧接在起始标志字节后的一个字节是地址域，该字节为0xFF。我们熟知网络是分层的，且对等层之间进行相互通信，而下层为上层提供服务。当对等层进行通信时首先需获知对方的地址，而对不同的网络，

6、在数据链路层则表现为需要知道对方的MAC地址、X.121地址、ATM地址等；在网络层则表现为需要知道对方的IP地址、IPX地址等；而在传输层则需要知道对方的协议端口号。例如如果两个以太网上的主机希望能够通信的话，首先发送端需获知对端的MAC地址。但由于PPP协议是被运用在点对点的链路上的特殊性，它不像广播或多点访问的网络一样，因为点对点的链路就可以唯一标示对方，因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址，所以该字节已无任何意义，按照协议的规定将该字节填充为全1的广播地址。同地址域一样，PPP数据帧的控制域也没有实际意义，按照协议的规定通信双方将该字节的内容填充为0x03

7、。就PPP协议本身而言，我们最关心的内容应该是它的协议域和信息域。协议域可用来区分PPP数据帧中信息域所承载的数据报文的内容。协议域的内容必须依据ISO 3309的地址扩展机制所给出的规定。该机制规定协议域所填充的内容必须为奇数，也即是要求低字节的最低位为“1”，高字节的最低位为“0”。如果当发送端发送的PPP数据帧的协议域字段不符合上述规定，则接收端会认为此数据帧是不可识别的，那么接收端会向发送端发送一个Protocol-Reject报文，在该报文尾部将完整地填充被拒绝的报文。信息域缺省时最大长度不能超过1500字节，其中包括填充域的内容，1500字节大小等于PPP协议中配置参数选项MRU（

8、Maximum Receive Unit）的缺省值，在实际应用当中可根据实际需要进行信息域最大封装长度选项的协商。信息域如果不足1500字节时可被填充，但不是必须的，如果填充则需通信双方的两端能辨认出有用与无用的信息方可正常通信。 说明：MRU表示本端接收到的PPP数据帧的数据域的最大值。通常情况下这个参数选项使用默认值（1500字节），因此在Config-Request报文中双方都不会携带这个配置参数选项。 当在某些特殊应用中，可能会使用到小于1500字节或大于1500字节的情况，这时在Config-Request报文就会携带要协商的MRU配置参数选项值。CRC校验域主要是对PPP数据帧传输

9、的正确性进行检测的，当然在数据帧中引入了一些传输的保证机制是好的，但可以反过来说，同样我们会引入更多的开销，这样可能会增加应用层交互的延迟。 为了能适应复杂多变的网络环境，PPP协议提供了一种链路控制协议来配置和测试数据通信链路，它能用来协商PPP协议的一些配置参数选项；处理不同大小的数据帧；检测链路环路、一些链路的错误；终止一条链路。PPP的网络控制协议根据不同的网络层协议可提供一族网络控制协议(NCP)，常用的有提供给TCP/IP网络使用的IPCP网络控制协议；提供给SPX/IPX网络使用的IPXCP网络控制协议等。最为常用的是IPCP协议，当点对点的两端进行NCP参数配置协商时，主要是用

10、来通信双方的网络层地址。 数据通信设备（在本文中指路由器）的两端如果希望通过PPP协议建立点对点的通信，无论哪一端的设备都需发送LCP数据报文来配置链路（测试链路）。一旦LCP的配置参数选项协商完后，通信的双方就会根据LCP配置请求报文中所协商的认证配置参数选项来决定链路两端设备所采用的认证方式。协议缺省情况下双方是不进行认证的，而直接进入到NCP配置参数选项的协商，直至所经历的几个配置过程全部完成后，点对点的双方就可以开始通过已建立好的链路进行网络层数据报文的传送了，整个链路就处于可用状态。只有当任何一端收到LCP或NCP的链路关闭报文时（一般而言协议是不要求NCP有关闭链路的能力的，因此通

11、常情况下关闭链路的数据报文是在LCP协商阶段或应用程序会话阶段发出的）；物理层无法检测到载波或管理人员对该链路进行关闭操作，都会将该条链路断开，从而终止PPP会话。以下是PPP协议整个链路过程需经历阶段的状态转移图说明：在点对点链路的配置、维护和终止过程中，PPP需经历以下几个阶段：链路不可用阶段。有时也称为物理层不可用阶段，PPP链路都需从这个阶段开始和结束。当通信双方的两端检测到物理线路激活（通常是检测到链路上有载波信号）时，就会从当前这个阶段跃迁至下一个阶段（即链路建立阶段）。先简单提一下链路建立阶段，在这个阶段主要是通过LCP协议进行链路参数的配置，LCP在此阶段的状态机也会根据不同的

12、事件发生变化。当处于在链路不可用阶段时，LCP的状态机是处于initial（初始化状态）或starting（准备启动状态），一旦检测到物理线路可用，则LCP的状态机就要发生改变。当然链路被断开后也同样会返回到这个阶段，往往在实际过程中这个阶段所停留的时间是很短的，仅仅是检测到对方设备的存在。链路建立阶段。是PPP协议最关键和最复杂的阶段。该阶段主要是发送一些配置报文来配置数据链路，这些配置的参数不包括网络层协议所需的参数。当完成数据报文的交换后，则会继续向下一个阶段跃迁，该下一个阶段既可是验证阶段，也可是网络层协议阶段，下一阶段的选择是依据链路两端的设备配置的（通常是由用户来配置，但对NAS或

13、BAS设备的PPP模块缺省就需要支持PAP或CHAP中的一种认证方式）。在此阶段LCP的状态机会发生两次改变，前面我们说了当链路处于不可用阶段时，此时LCP的状态机处于initial或starting，当检测到链路可用时，则物理层会向链路层发送一个UP事件，链路层收到该事件后，会将LCP的状态机从当前状态改变为Request-Sent（请求发送状态），根据此时的状态机LCP会进行相应的动作，也即是开始发送Config-Request报文来配置数据链路，无论哪一端接收到了Config-Ack报文时，LCP的状态机又要发生改变，从当前状态改变为opened状态，进入Opened状态后收到Confi

14、g-Ack报文的一方则完成了当前阶段，应该向下一个阶段跃迁。同理可知，另一端也是一样的，但须注意的一点是在链路配置阶段双方是链路配置操作过程是相互独立的。如果在该阶段收到了非LCP数据报文，则会将这些报文丢弃。验证阶段。多数情况下的链路两端设备是需要经过认证后才进入到网络层协议阶段，缺省情况下链路两端的设备是不进行认证的。在该阶段支持PAP和CHAP两种认证方式，验证方式的选择是依据在链路建立阶段双方进行协商的结果。然而，链路质量的检测也会在这个阶段同时发生，但协议规定不会让链路质量的检测无限制的延迟验证过程。在这个阶段仅支持链路控制协议、验证协议和质量检测数据报文，其它的数据报文都会被丢弃。

15、如果在这个阶段再次收到了Config-Request报文，则又会返回到链路建立阶段。网络层协议阶段。一旦PPP完成了前面几个阶段，每种网络层协议（IP、IPX和AppleTalk）会通过各自相应的网络控制协议进行配置，每个NCP协议可在任何时间打开和关闭。当一个NCP的状态机变成Opened状态时，则PPP就可以开始在链路上承载网络层的数据包报文了。如果在个阶段收到了Config-Request报文，则又会返回到链路建立阶段。网络终止阶段，PPP能在任何时候终止链路。当载波丢失、授权失败、链路质量检测失败和管理员人为关闭链路等情况均会导致链路终止。链路建立阶段可能通过交换LCP的链路终止报文来

16、关闭链路，当链路关闭时，链路层会通知网络层做相应的操作，而且也会通过物理层强制关断链路。对于NCP协议，它是没有也没有必要去关闭PPP链路的。 LCP数据报文是在链路建立阶段被交换的，它作为PPP的净载荷被封装在PPP数据帧的信息域中。在链路建立阶段的整个过程中信息域的内容是在变化的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分，PPP数据帧的协议域固定填充0xC021。 代码域的长度为一个字节，主要是用来标识LCP数据报文的类型的。在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。 标识域也是一

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

18、节数据（代码域+标志域+长度域+数据域）。长度域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值。数据域的内容依据不同LCP数据报文的内容也是不一样的。链路配置报文与其它两类报文有着明显的区别，它主要是用来协商链路的配置参数选项的，因此这种报文的数据域还要携带许多配置参数选项的。链路配置报文主要包括Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。当通信双方需要建立链路时，无论哪一方都需要发送Config-Request报文并携带每一端自已所希望协商的配置参数选项。当接收方收到Config-Reques

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

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

21、项的顺序）。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。 当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-Nak报文，该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。然而当接收端收到Config-Nak报文后，会重新发送Config-Request报文，而这个Config-Request报文与上一次所发送的Config-Request报文区别在于那些被对端不认可的配置参数选项的内容被填写到刚刚协商完后再次

22、发送的Config-Request报文中（Config-Nak报文发送回来的那些配置参数选项）。 当接收Config-Request报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别时）。当对端接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。 链路配置阶段也可能要经过几次协商后才能完成，但这与点对点两端的设备有着密切的联系。对于PPP的

23、两个端点而言，两者是独立完成各自的配置参数选项的协商过程的。链路终止报文分为Terminate-Request和Terminate-Reply两种报文。LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端会持续发送Terminate-Request报文，直到收到一个Terminate-Reply为止。接收端一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply报文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项。对于链路终止报文也同

24、样需要ID一致，当接收到Terminate-Reply报文才会做链路终止操作。 魔术字是在LCP的Config-Request报文中被协商的，并且可被一些其它类型的LCP数据报文所使用，如Echo-Request、Echo-Reply报文和Quality-Protocol报文等。对于PPP协议本身它是不要求协商魔术字的，如果在双方不协商魔术字的情况下，某些LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全0；反之，则填充为配置参数选项协商后的结果。魔术字在目前所有的设备当中都是需要进行协商的，它被放在Config-Request的配置选项参数中进行发送，而且需要由自身的通信设备

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

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

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

28、下去，接收端就会认为PPP链路存在环路的可能性在不断增加，当达到一定数量级时，就可认为此链路存在环路。但在实际应用中根据不同设备实现PPP协议的方法，我们在链路环路检测时可采用两种方法。第一种机制就是如上面所述的，这个过程不断地重复，最终可能会给LCP状态机发一个Down事件，这时可能会使LCP的状态机又回到初始化阶段，又开始新一轮的协商。当然对于某些设备还会采用第二种机制，就是不产生任何事件去影响当前LCP的状态机，而是停留在请求发送状态。但这时认为链路有环路的一端设备需要不断的向链路上发送Echo-Request报文来检测链路环路是否被解除，当接收端收到Echo-Reply报文时，就认为链

29、路环路被解除，从而就可能进行后续的PPP的过程。 PPP协议也提供了可选的认证配置参数选项，缺省情况下点对点通信的两端是不进行认证的。在LCP的Config-Request报文中不可一次携带多种认证配置选项，必须二者择其一（PAP/CHAP）。一般是在PPP设备互连的设备上进行配置的，或设备默认支持一个缺省的认证方式（PAP是大部分设备所默认的认证方式）。当对端收到该配置请求报文后，如果支持配置参数选项中的认证方式，则回应一个Config-Ack报文；否则回应一个Config-Nak报文，并附带上自希望双方采用的认证方式。当对方接收到Config-Ack报文后就可以开始进行认证了，而如果收到得

30、是Config-Nak报文，则根据自身是否支持Config-Nak报文中的认证方式来回应对方，如果支持则回应一个新的Config-Request（并携带上Config-Nak报文中所希望使用的认证协议），否则将回应一个Config-Reject报文，那么双方就无法通过认证，从而不可能建立起PPP链路。PPP支持两种授权协议：PAP（Password Authentication Protocol）和CHAP（Challenge Hand Authentication Protocol）。 我们所知两个设备在使用PAP进行认证之前，应该确认那一方是验证方，那一方是被验证方。实际上对于使用PPP协

31、议互连的两端来说，既可作为认证方，也可作为被认证方。但通常情况下，PAP只使用一个方向上的认证。一般在两端设备使用PAP协议之前，均会设备上进行一些相应的配置，对于MA5200IP接入设备，它默认就作为验证方，但可通过使用命令PAP Authentication PAP/CHAP来更改认证方式，而对于被验证方而言只需设置用户名和密码即可。PAP认证是两次握手，在链路建立阶段，依据设备上的配置情况，如果是使用PAP认证，则验证方在发送Config-Request报文时会携带认证配置参数选项，而对于被验证方而言则是不需要，它只需要收到该配置请求报文后根据自身的情况给对端返回相应的报文。如果点对点的

32、两端设备采用的是PAP双向认证时，也即是它同时也作为验证方，则此时需要在配置请求报文中携带认证配置参数选项。因此，我们可以总结一下，如果对于点对点的两个设备在PPP链路建立的过程中使用的认证方式为PAP的话，那么验证方在其Config-Request报文中必须含有认证配置参数选项，且该认证配置参数选项的数据域为0xC023 。当通信设备的两端在收到对方返回的Config-Ack报文时，就从各自的链路建立阶段进入到认证阶段，那么作为被验证方此时需要向验证方发送PAP认证的请求报文，该请求报文携带了用户名和密码，当验证方收到该认证请求报文后，则会根据报文中的实际内容查找本地的数据库，如果该数据库中

33、有与用户名和密码一致的选项时，则回向对方返回一个认证请求响应，告诉对方认证已通过。反之，如果用户名与密码不符，则向对方返回验证不通过的响应报文。如果双方都配置为验证方，则需要双方的两个单向验证过程都完成后，方可进入到网络层协议阶段，否则在一定次的认证失败后，则会从当前状态返回链路不可用状态。例如：当路由器A（被验证方）收到了路由器B 的Config-Ack报文后，因为是使用PAP认证，所以作为被验证方的路由器A应主动向验证方（路由器B）发送认证请求报文（PAP Authenticate），用户名和密码均为163，报文的内容如下：7E FF 03 C0 23 01 01 00 0C 03 31

34、36 33 03 31 36 33 7E下划线的前四个字节是用户名，后四个字节是密码。当路由器B收到了该报文后，会向路由器A回应一个PAP Authenticate Ack报文，报文内容如下：7E FF 03 80 21 02 01 00 05 00 7E此时所回应的报文中，并未携带任何数据，如果是认证不通过，则会在返回的报文中指是因何原因无法认证通过，可能是无此用户名或密码不匹配。 与PAP认证比起来，CHAP认证更具有安全性，从前面认证过程的数据包交换过程中不难发现，采用PAP认证时，被验证是采用明文的方式直接将用户名和密码发送给验证方的，而对于PAP认证则不一样。CHAP为三次握手协议，

35、它只在网络上传送用户名而不传送口令，因此安全性比PAP高。在验证一开始，不像PAP一样是由被验证方发送认证请求报文了，而是由验证方向被验证方发送一段随机的报文，并加上自己的主机名，我们通称这个过程叫做挑战。当被验证方收到验证方的验证请求，从中提取出验证方所发送过来的主机名，然后根据该主机名在被验证方设备的后台数据库中去查找相同的用户名的记录，当查找到后就使用该用户名所对应的密钥，然后根据这个密钥、报文ID和验证方发送的随机报文用Md5加密算法生成应答，随后将应答和自己的主机名送回，同样验证方收到被验证方发送回应后，提取被验证方的用户名，然后去查找本地的数据库，当找到与被验证方一致用户名后，根据

36、该用户名所对应的密钥、保留报文ID和随机报文用Md5加密算法生成结果，和刚刚被验证方所返回的应答进行比较，相同则返回Ack，否则返回Nak。例11： 如图4-2所示，当路由器A（被验证方）收到了路由器B 的Challenge报文后，报文内容如下：7E FF 03 C2 23 01 01 00 1C 10 FF 41 CF 22 AA 8E F1 B9 99 9A 79 A7 56 78 C4 A7 4d 41 35 32 30 30 417E下划线的前16个字节是验证方随机产生的一段报文，后7个字节是验证方的主机名（MA5200A），而且单个字节10表示随机报文的长度。而此时路由器A会根据用户

37、名所对应的密钥使用报文的ID和该报文的内容生成一个回应报文，报文内容如下：7E FF 03 C2 23 02 01 00 1F 10 18 86 22 FF CE 81 D0 68 FF 80 85 00 A7 E3 85 35 70 70 6B 69 73 73 40 68 75 61 7E我们将这个回应报文与验证方发送的挑战报文进行比较，报文的代码域已由原01改为02，总报文的长度有变化，主要后而一个下划线的内容是被验证方的主机名（ppkisshua），而且此时回应的16个字节的报文已经是经过MD5算法加密过的。当验证方收到了这个回应报文后，会根据报文中被验证方的主机名（ppkisshua

38、）在本地的数据库中去查找密钥，然后再对原发先发送的那段挑战报文进行MD5的算法加密，如果所得的结果与对方刚发过来的16个字节的加密值一样的话，则就会发送一个报文通知被验证方，你的认证已经通过，我们可以进入到下一个阶段了。在实际应用当中，我们很多都是使用PC机来进行拨号这个过程，实际中当验证方发送挑战后，PC机只接收而并不去查本地数据库，而直接使用在拨号对话框中所输入的密码和报文的ID及报报文的内容进行MD5算法加密（这个在PC机采用PPPOE软件拨入到MA5200时就是这样的）。下面来看一下验证通过时，验证方给被验证方所发送的一段报文内容：7E FF 03 C2 23 03 01 00 17

39、57 65 6C 63 6F 6D 65 20 74 6F20 4D 41 35 32 30 30 41 2E 7E此时所回应的报文的代码域为03，且报文的实际内容是，Welcom to MA5200A。 NCP协议的数据报文是在网络层协议阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。NCP协议主要包括IPCP、IPXCP等，但我们在实际当中最常遇见的也只有IPCP协议了，如果对IPXCP或其它的一些网络控制协议有兴趣，则可参见RFC1552。 IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的

40、选项协商的。IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。我们依据两端设备的配置选项可将IPCP的协商过程分为静态和动态。何为静态，何为动态，这是一个相对的概念，可能不太准确，只作为参考使用。我们在下面会具体描述这两个过程。IPCP的数据的文同LCP的数据报文非常类似，只不过NCP是在网络层协议阶段协商配置参数选项，而LCP协议则是在链路建立阶段协商配置参数选项的。除此之外是两者在所使用报文上的相似之处，我们知道LCP共包括十几种报文，而IPCP也包括多种报文，但它的报文类型只是LCP数据报文的一个子集（只有LCP代码域从1到7这七种报文），而且实际的数据报文交换

41、过程中也仅涉及以下几种：Config-Request、Config-Ack、Config-Nak和Config-Reject（代码域从1到4，而链路终止报文一般而言是不在网络协议阶段使用的，而且也是不需要的）。以下就具体介绍一下IPCP控制协议的静态和动态的两个过程，实际上两者的区分是在于互连设备IP地址的获取过程。静态协商，也即是不协商。点对点的通信设备两端在PPP协商之前已配置好了IP地址，所以就无须在网络层协议阶段协商IP地址，而双方唯一要做的就是告诉对方自身的IP地址。在IPCP控制协议完成整个配置的过程时，最理想的情况将会看到如图所示的四种报文，而无其它报文再被发送。如果当配置请求中

42、所携带的网络层配置参数选项类似于LCP配置参数选项协商过程一样，可能会有对方不识别的配置参数选项或不被对方所认可的配置参数选项的内容。这样在这个阶段的协商过程中可能还会看到其它的一些报文。在静态协商时，如果IPCP的Config-Request报文中只含有地址配置参数选项时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与LCP阶段的一样，而我这里只提到了IP地址配置参数选项），无论是发送方还是接收方都同时发送Config-Request报文，其中配置选项中只含有各自的IP地址。当对端收到该报文后，会发送一个Config-Ack报文，这个目的是告诉对端我已经知道了你的IP地址，对路

43、由器而言会增加一条到对端接口的主机路由。 刚进入网络层协议阶段时，IPCP的状态机是initial的，但当完成了上述的整个过程后，IPCP的状态机改变为Opened，双方也就可以开始网络层数据网的传送了。当一端接收到Config-Request报文后，它从报文的配置参数选项中可获知对端的IP地址，但并不与本端的IP地址进行比较。我们也知道，一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段，IPCP协议中并未规定，此时不给对方回应Config-Ack报文，而是无条件的回送。因此说点对点通信的两端如果是手动设置每一端的IP地址时，无须双方地址在同一网段。例8：假设IPCP在网络层

44、协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方设置IP地址为192.168.0.1，接收方设置IP地址为192.168.0.2，发送方发送给Config-Request报文内容如下：7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E在这个例子中我们能看见明显的改变之处再于PPP协议域字段由原先的0xC021改变为0x8021，下划线的部分表示本端的IP地址。当对端正确接收到了该报文后，应该回应一个Config-Ack报文，报文内容如下：7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 0

45、0 01 7E同样的接收方给发送方也发送一个Config-Request报文内容如下，但此时报文中IP地址配置参数选项的值为本端的IP地址（192.168.0.2）：7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E发送方回应一个Config-Ack报文给接收方，报文内容如下：7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E动态协商，也即是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址，这个过程实际上可与窄带拨号上网的过程相一致，如果我们想用计算机上网，均会安装一个拨

46、号适配器，而且计算机中的拨号网络适配器是采用动态获取IP地址的方式，也就是在IPCP的Config-Request报文中只携带IP地址的配置参数选项。这个例子与一个例子相似如果是配置参数选项中含有其它配置参数选项，则可能会遇到其它的一些情况（如不识别配置参数选项的代码域或不认可配置参数选项的内容，但对于这些情况的处理方法和LCP配置参数选项的处理方法一致）。图我们可以看出发送方连续发送了两次Config-Request报文，才能完成发送方的协商过程。而接收方仍然只需要发送一次Config-Request即可完成本端的协商过程。由于发送方没有配置IP地址（而是动态获取IP地址），所以在IPCP的

47、Config-Request报文的IP地址配置参数配置选项中的IP地址填充全0（也即是0.0.0.0），这样当对端收到这个Config-Request报文时，当接收方收到该配置请求报文后会迅检测IP地址的内容，如果发送为全0，则认为对端的这个IP地址不是我所希望的值，这样就回应一个Config-Nak报文，并将希望分配给对方的IP地址填充到Config-Nak报文内。这时当接收方收到Config-Nak报文后，就会重新发送一个Config-Request报文，这个报文中的IP地址配置选项为对方在Nak报文中所提供的。接收方IP地址的配置过程与静态时的一样，只需发送一个Config-Reques

48、t报文即可，当收到发送方的Config-Ack报文，就表示接收方的IP地址配置完成。例9： 假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方没有配置IP地址，而接收方配置了IP地址为192.168.0.2，接收方可给发送方分配IP地址（192.168.0.1），发送方发送给接收方的Config-Request报文内容如下：7E FF 03 80 21 01 01 00 0A 03 06 00 00 00 00 7E有下划线的部分表示本端的IP地址。当对端正确接收到了该报文后，应该回应一个Config-Nak报文，报文内容如下：7E FF 03 80 21 03 01 00 0A 03 06 C0 A8 00 01 7E当接收方收到该报文后，重新发送一个Config-Request报文，报文内容如下：7E FF 03 80 21 01 02 00 0A 0