《pppoe报文深入了解(14页).doc》由会员分享，可在线阅读，更多相关《pppoe报文深入了解(14页).doc（14页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、-pppoe报文深入了解-第 14 页第一天：pppoe的数据包深入了解，点对点协议（ppp）Pppoe分为发现阶段和会话阶段，发现阶段分为PADI,PADO,PADR,PADS.pppoe的数据报文依次为目的MAC（6字节=48bit），源MAC（6字节），协议类型（2字节 为ox8863），版本（VER 4bit 为0001），字段和类型（TYPE 4bit 0001）,代码（CODE 8bit）,版本标识号码（SESSION-ID 16bit 为ox0000），长度（LENGTH 16bit）,静载荷（数据域）。发现报文的数据域格式为TAG（类型-长度），主机名称（15个字节），TAG（
2、类型-长度），主机标识符（4个字节），TAG（类型-长度），AC-Cookie（18个字节）。采用的是TLV（类型-长度-值）阶段源MAC目的MACCODE48bit48bit8bitPADI主机A广播(FF:FF:FF:FF:FF:FF)Ox09PADO服务器B主机AOx07PADR主机A服务器BOx19PADS服务器B主机AOx65PPPOE数据报文中Tag（标记）的格式对于发现阶段的PPPOE数据报文而言，它的净载荷可能包含零个或多个Tag（标记），实际上这些标记的意义非常类似于PPP配置参数选项，它同样也是要经过协商的。对于PPPOE协议而言，没有像PPP的配置参数选项那样定义了很多细
3、节，而只是一个初略的定义，因此在实际当中实现这个过程会依据不同厂商的设备有不同。首先还是让我们看一下承载在PPPOE报文数据域中的标记封装格式，如图2。类型长度数据（图2 标记的封装格式）从图2中可以看出，标记的封装格式采用的是大家所熟知的TLV结构，也即是（类型+长度+数据）。标记的类型域为2个字节，下表列出了各种标记类型的含义：标记类型标记说明0x0000表示PPPOE报文数据域中一串标记的结束，为了保证版本的兼容性而保留，在有些报文中有应用。0x0101服务名，主要用来表明网络侧所能提供给用户的一些服务。0x0102访问集中器名，当用户侧接收到了AC的回应的PADO报文时，就可获从所携带
4、的标记中获知访问集中器的名子，而且还可以据此来选择相应的访问集中器。0x0103主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和接收端的，因为对于广播式的网络中会同时存在很多个PPPOE的数据报文。0x0104AC-Cookies，主要被用来防止恶意性DOS功击。0x0105销售商的标识符。0x0110中继会话ID，对于PPPOE的数据报文也同样可以像DHCP报文一样被中断到另外的AC上终结，这个字段则是用来维护另一个连接的。0x0201服务名错误，当请求的服务名不被对端所接受时，会在响应的报文中携带这个标记。0x0202访问集中器名出错。0x0203一般性错误。1. PAD
5、IPPPOE发现阶段的第一步，也即是由用户首先发送这样一个报文。用户主机是以广播的方式发送这个报文，所以该报文所对应的以太网帧的目的地址域应填充为全1，而源地址域填充用户主机的MAC地址。广播包可能会被多个访问集中器接收到。2. PADO PPPOE发现阶段的第二步，也即是由访问集中器回应各用户主机发送的PADI报文，此时该报文所对应的以太网帧的源地址填充访问集中器的MAC地址，而目的地址则填充从PADI中所获取的用户主机的MAC地址。3. PADRPPPOE发现阶段的第三步，也即是由用户主机向访问服务器发送单播的请求报文。当用户主机收到PADO报文后，会从这些报文中挑选一个访问集中器作为后续
6、会话的对象。由于用户主机在收到PADO报文后，就获知了访问集中器的MAC地址，因此PADR报文所以应的以太网帧的源地址填充用户主机的MAC地址，而以太网的目的地址填充为访问集中器的MAC地址。 4. PADSPPPOE发现阶段的第四步，也即是最后一步，此时访问集中器当收到PADR报文时，就准备进入开始一个PPP的会话了，而此时访问集中器会为在这个会话分配一个唯一的会话进程ID，并在发送给主机的PADS报文中携带上这个会话ID。当然如果访问集中器不满足用户所申请的服务的话，则会向用户发送一个PADS报文，而其中携带一个服务名错误的标记，而且此时该PADS报文中的会话ID填充0x0000。5. P
7、ADTPADT报文可能在会话进行开始之后的任意时间内被发送，主要是用来终止一个PPPOE会话的止。它可以由主机或访问集中器发送，目的地址填充为对端的以太网的MAC地址。会话阶段：（ppp全过程）数据帧在数据域中，不变的有如下信息：协议的组成： 链路控制协议(LCP)：建立、拆除和监控PPP数据链路 网络控制协议(NCP)：协商网络层协议 PPP扩展协议：如压缩、链路捆绑 PPP验证协议：如PAP、CHAPPpp帧格式：标志字段F为0x7E（0x表示7E），但地址字段A和控制字段C都是固定不变的，分别为0xFF、0x03。PPP协议不是面向比特的，因而所有的PPP帧长度都是整数个字节。与HDLC
8、不同的是多了2个字节的协议字段。协议字段不同，后面的信息字段类型就不同。如：0x0021信息字段是IP数据报0xC021信息字段是链路控制数据LCP0x8021信息字段是网络控制数据NCP0xC023信息字段是安全性认证PAP0xC025信息字段是LQR0xC223信息字段是安全性认证CHAP当信息字段中出现和标志字段一样的比特0x7E时，就必须采取一些措施。因PPP协议是面向字符型的，所以它不能采用HDLC所使用的零比特插入法，而是使用一种特殊的字符填充。具体的做法是将信息字段中出现的每一个0x7E字节转变成2字节序列（0x7D，0x5E）。若信息字段中出现一个0x7D的字节，则将其转变成2
9、字节序列（0x7D，0x5D）。若信息字段中出现ASCII码的控制字符，则在该字符前面要加入一个0x7D字节。这样做的目的是防止这些表面上的ASCII码控制字符被错误地解释为控制字符。 Flag标志域：每一个PPP数据帧均是以一个标志字节起始和结束的，该字节为0x7E。 Address地址域：该字节为0xFF。由于PPP协议是被运用在点对点的链路上，点对点的链路可以唯一标示对方，因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址，所以该字节已无任何意义，按照协议的规定将该字节填充为全1的广播地址。 Control控制域：也没有实际意义，按照协议的规定通信双方将该字节的内容填充为
10、0x03。 Protocol协议域：用来区分PPP数据帧中信息域所承载的数据报文的内容。 Information：信息域：缺省时最大长度不能超过1500字节，其中包括填充域的内容。 FCS校验域：主要是对PPP数据帧传输的正确性进行检测的。 Code域表明了此报文为哪种PPP协商报文；Identifier域用于进行协商报文的匹配；Length域为此协商报文长度（包含Code及Identifier域）；Data域所包含的为协商报文内容；Type为协商选项类型；其后的Length为此协商选项长度（包含Type域）；紧接着的Data域为协商选项具体内容。 PPP主要由三类协议组成：链路控制协议族(L
11、CP)、网络控制协议族(NCP)和PPP扩展协议族。其中，链路控制协议主要用于建立、拆除和监控PPP数据链路；网络控制协议族主要用于协商在该数据链路上所传输的网络层数据包的类型以及网络层协议自身需要的一些内容（如IPCP要协商IP地址等）；PPP扩展协议族主要用于提供对PPP功能的进一步支持，实际上就是为提供一些特性服务，基于PPP协议框架设计的一些扩展协议。 同时，PPP还提供了用于网络安全方面的验证协议族(PAP和CHAP)。1.LCPLCP 包有3类：1. 链路配置包，用于建立和配置链路（Configure-Request、Configure-Ack、Configure-Nak 和Con
12、figure-Reject）。2. 链路结束包被用于结束一个链路（Terminate-Request 和 Terminate-Ack）3. 链路维修包被用于管理和调试一个链路（Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply 和 Discard-Request）。确切的说一个 LCP 包被封装在 PPP 信息域中，该 PPP域表示类型为十六进制 c021（链路控制协议）。81632 bitVariableCodeIdentifier（匹配请求和响应报文）LengthData Code 十进制值，表示 LCP 数据包类型。o 1 Config
13、ure-Request配置请求报文o 2 Configure-Ack配置确定报文o 3 Configure-Nak支持对端的协商选项但不认可该项协商的内容，回复自己认可的配置方式并放入其中o 4 Configure-Reject配置拒接o 5 Terminate-Request终止请求o 6 Terminate-Ack终止确认o 7 Code-Reject代码拒绝o 8 Protocol-Rejecto 9 Echo-Requesto 10 Echo-Replyo 11 Discard-Requesto 12 Link-Quality Repor Identifier 十进制值，表示匹配 Re
14、quest 和 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 回
15、调（3个字节） Multilink MRRU 多链路协议（4个字节） Multilink endpoint discriminator:多链路端点鉴别（23个字节） Link discriminator：l链路鉴别。（4个字节）Request： Ack：Termination request报文：Termination ack报文：2.NCP:PPP 扩展认证（EAP）是一个用于 PPP 认证的通用，可以支持多种认证方法。EAP 并不在链路控制阶段指定认证方法，而是把这个过程推迟到认证阶段。这样认证方就可以在得到更多的信息以后再决定使用什么认证方法。这种机制还允许 PPP 认证方简单地把收到的
16、认证报文透传给后方的认证服务器，由后方的认证服务器来真正实现各种认证方法。1. 在链路阶段完成以后，认证方向对端发送一个或多个请求报文。在请求报文中有一个类型字用来指明认证方所请求的信息类型，例如是对端的 ID、MD5 的挑战字、一次密码（OTP）以及通用令牌卡等。MD5 的挑战字对应于 CHAP 认证协议的挑战字。典型情况下，认证方首先发送一个 ID 请求报文随后再发送其他的请求报文。当然，并不是必须要首先发送这个 ID 请求报文，在对端身份是已知的情况下（如租用线、拨号专线等）可以跳过这个步骤。2. 对端对每一个请求报文回应一个应答报文。和请求报文一样，应答报文中也包含一个类型字段，对应于
17、所回应的请求报文中的类型字段。3. 认证方通过发送一个成功或者失败的报文来结束认证过程。EAP 可以支持多种认证机制，而无需在 LCP 阶段预协商过程中指定。某些设备（如：接入服务器）不需要关心每一个请求报文的真正含义，而是作为一个代理把认证报文直接透传给后端的认证服务器。设备只需关心认证结果是成功还是失败，然后结束认证阶段。EAP 需要在 LCP 中增加一个新的认证协议，这样现有的 PPP 实现要想使用 EAP 就必须进行修改。同时，使用 EAP 也和现有的在 LCP 协商阶段指定认证方法的模型不一致。81632 bitVariableTypeLengthAuthentication-Pro
18、tocolData Type 3 Length 4 Authentication-Protocol 对于 PPP 中的 EAP，该字段为C227（十六进制）。一个 PPP EAP 数据包封装在 PPP 数据链路层帧的 Information 字段，其中的 Protocol 字段表示类型为十六进制 C227（PPP EAP）。EAP 数据包格式如下所示：81632 bitVariableCodeIdentifierLengthData Code Code 字段识别 EAP 数据包类型。 EAP 代码分配如下：1、请求（Request）；2、响应（Response）；3、成功（Success）；4
19、、失败（Failure） Identifier Identifier 字段用于匹配响应和请求信息。 Length Length 字段表示 EAP 数据包的长度，包括 Code、Identifier、Length 和 Data 字段 Data Data 字段的格式取决于 Code 字段。Ipcp request报文：Ipcp ack报文：Ccp request 报文：Cc pack报文：CHAP：PPP 挑战握手认证（CHAP：Challenge Handshake Authentication Protocol）挑战握手认证（CHAP）通过三次握手周期性的认证对端的身份，在初始链路建立时完成，
20、可以在链路建立之后的任何时候重复进行。1. 链路建立阶段结束之后，认证者向对端发送“挑战”消息。2. 对端用经过单向哈希函数计算出来的值做应答。3. 认证者根据它自己的预期哈希值的计算来检查应答，如果值匹配，认证得到承认；否则，连接应该终止。4. 经过一定的随机间隔，认证者发送一个新的挑战给对端，重复1到3。通过递增改变的标识符和可变的挑战值，CHAP 防止了重放攻击，重复挑战限制了对单个攻击的暴露时间，认证者控制挑战的频度。该认证方法依赖于认证者和对端共享的密钥，密钥不是通过该链路发送的。虽然该认证是单向的，但是在两个方向都进行CHAP协商，同一密钥可以很容的实现交互认证。由于 CHAP 可
21、以用在许多不同的认证中，因此可以用 NAME 字段作为索引，以便在一张大型密钥表中查找正确的密钥，这样也可以在一个中支持多个 NAME 密钥对，在会话中随时改变密钥。CHAP 要求密钥以明文形式存在，无法使用通常的不可回复加密口令数据库。在大型设备中不适用，因为每个可能的密钥由链路的两端共同维护。8163240 bitTypeLengthAuthentication-ProtocolAlgorithm Type 3 Length 5 Authentication-Protocol 对于 CHAP，为 C223（Hex）。 Algorithm Algorithm 字段为八位字节，表示使用的认证方
22、法。CHAP 数据包结构如下所示：81632 bitVariableCodeIdentifierLengthData . . . 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
23、，Data 字段包括一个独立执行的可变信息字段。服务器先发给主机的chap chanllage报文：主机回复服务器chap response报文服务器发给主机的chap success报文：PPP的协商过程PPP协议在进行LCP协商的时候，双方是互相发送configure-request，然后向对方回应configure-ack，也可以只有一方发送，另一方回应。PPP在建立链路之前要进行一系列的协商过程，过程如下：PPP首先进行LCP协商，协商内容包括：MTU(最大传输单元)、魔术字(magic number)、验证方式、异步字符映射等选项(详见RFC1661) LCP协商成功后，进入Esta
24、blish(链路建立)阶段，如配置了CHAP或PAP验证，便进入CHAP或PAP验证阶段，验证通过后才会进入网络阶段协商(NCP)，如IPCPIPXCP、BCP的协商，任何阶段的协商失败都将导致链路的拆除，魔术字，主要用于检测链路自环，PPP靠发送Echo Request、Echo Reply报文来检测自环和维护链路状态，如连续发现有超过最大自环允许数目Echo Request报文中魔术字与上次发送魔术字相同，则判定网络发生自环现象，如链路发生自环，则就需采取相应措施对链路复位 另外，LCP发送config request时也可以检测自环，LCP发现自环后，在发送一定数目的报文后也会复位链路，
25、如果PPP发送的Echo Request 报文产生丢失，则在连续丢失最大允许丢失的个数之后，将链路复位，以免过多的无效数据传输，异步字符映射用于同异步转换。PAP的验证过程PAP为两次握手协议，它通过用户名及口令来对用户进行验证。PAP验证过程如下：当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表或radius服务器，查看是否有此用户，口令是否正确，如正确则会给对端发送ACK报文，通告对端已被允许进入下一阶段协商，否则发送NAK报文，通告对端验证失败，此时并不会直接将链路关闭，只有当验证不过次数达到一定值时，才会关闭链路，来防止因误传、网络干扰等造成不
26、必要的LCP重新协商过程。PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获便有可能对网络安全造成极大的威胁。因此，它适用于对网络安全要求相对较低的环境。CHAP的验证过程CHAP为三次握手协议，它的特点是：只在网络上传输用户名，而并不传输用户口令，因此，它的安全性要比PAP高。CHAP的验证过程为：首先由验证方向被验证方发送一些随机产生的报文，并同时将本端的主机名附带上一起发送给被验证方，被验证方接到对端对本端的验证请PAP是首先由被验证方将自己的用户名及密码送给验证方，而CHAP验证是首先由验证方发起验证过程的，主要区别为PAP为明文传送密码，而在CHAP验证过程中，
27、密码是不在线传送的。Ppp运行过程： PPP的运行过程分为3个阶段 链路建立阶段（LCP） 验证阶段（Authenticate） 网络控制协商阶段（NCP） 1、PPP由不活动（dead）状态到链路UP状态，大体上可分为3个阶段，分别是链路建立阶段、验证阶段、网络控制协商阶段； 2、链路建立阶段主要进行链路控制协商（LCP），协商内容包括：MRU(最大接收单元)、魔术字(magic number)、验证方式、异步字符映射等选项(详见RFC1661)； 3、LCP协商成功后，如配置了CHAP或PAP验证，便进入CHAP或PAP验证阶段； 4、验证通过后才会进入网络控制协商阶段(NCP)，如IPC
28、P、IPXCP的协商；IPCP的协商内容目前主要包括IP地址、TCP等包文头的头压缩等。 5、网络控制协商成功后，链路就会UP，就可以开始接收与发送协商 指定的网络层包文了。 任何阶段的协商失败都将导致链路的拆除。LCPLCP数据报文是在链路建立阶段被交换的，它作为PPP的净载荷被封装在PPP数据帧的信息域中，此时PPP数据帧的协议域固定填充0xC021，但在链路建立阶段的整个过程中信息域的内容是在变化的，一共包括12种LCP数据报文，依据各报文的的功能又将其具体细化为以下三类： 链路配置报文，主要用来建立和配置一条链路的。 链路终止报文，主要用来终止一条链路的。 链路维护报文，主要用来维护和
29、调试链路的。Code代码域：长度为一个字节，主要是用来标识LCP数据报文的类型的。在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。Identifier标识域：长度为一个字节，其目的是用来匹配请求和响应报文。一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文（Config-Request报文），而这几个请求报文的数据域可能是完全一样的，而仅仅是它们的标志域不同罢了。通常一个配置请求报文的ID是从0x01开始逐步加1的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可能是Conf
30、ig-Ack、Config-Nak和Config-Reject三种报文中的一种）来回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致，当通信设备收到回应后就可以将该回应与发送时的进行比较来决定下一步的操作。Length长度域的内容= 总字节数据(代码域+标志域+长度域+数据域)。Data数据域的内容依据不同LCP数据报文的内容而有所不同。 链路配置报文主要是用来协商链路的配置参数选项的，因此这种报文的数据域要携带许多配置参数选项。 链路配置报文主要包括Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。 当通信双方需要建立链路
31、时，无论哪一方都需要发送Config-Request报文并携带自已所希望协商的配置参数选项，常见的配置参数选项包括： Multilink-Protocol多重协议 Address-and-Control-Field-Compress 地址控制字段压缩 Authentication-Protocol身份验证协议 Protocol-Field-Compress协议域压缩 Maximum-Recieve-Unit最大接受单元 Magic-Number避免在PPP帧的循环使用1. 当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将
32、会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。2. 当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-Nak报文，该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。当接收端收到Config-Nak报文后，会重新发送Config-Request 报文，而这个Config-Request报文与上
33、一次所发送的Config-Request报文区别在于那些被对端不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中（Config-Nak报文发送回来的那些配置参数选项）3. 当接收Config-Request报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别时）。当对端接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置
34、参数选项给删除了。链路终止报文分为Terminate-Request和Terminate-Ack两种。 LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端会持续发送Terminate-Request报文，直到收到一个Terminate- Ack为止。接收端一旦收到了一个Terminate-Request报文后，必须回应一个Terminate- Ack报文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。 LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项。对于链路终止报文也同样需要ID一致，当接收到Terminate- Ac
35、k报文才会做链路终止操作。 PAP为两次握手协议，它通过用户名及口令来对用户进行验证； PAP验证过程：当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表（或radius服务器）查看是否有此用户，口令是否正确。如正确则会给对端发送ACK报文，通告对端已被允许进入下一阶段协商；否则发送NAK报文，通告对端验证失败。此时，并不会直接将链路关闭。只有当验证不过次数达到一定值时，才会关闭链路，来防止因误传、网络干扰等造成不必要的LCP重新协商过程。 PAP的特点：在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有可能对网络安全造成极大的威胁。因此，
36、它适用于对网络安全要求相对较低的环境。 PAP为两次握手协议，它通过用户名及口令来对用户进行验证； PAP验证过程：当两端链路可相互传输数据时，被验证方发送本端的用户名及口令到验证方，验证方根据本端的用户表（或radius服务器）查看是否有此用户，口令是否正确。如正确则会给对端发送ACK报文，通告对端已被允许进入下一阶段协商；否则发送NAK报文，通告对端验证失败。此时，并不会直接将链路关闭。只有当验证不过次数达到一定值时，才会关闭链路，来防止因误传、网络干扰等造成不必要的LCP重新协商过程。 PAP的特点：在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有可能对网络安全造成极大的
37、威胁。因此，它适用于对网络安全要求相对较低的环境。 NCP协议的数据报文是在网络控制协商阶段被交换的 NCP协议主要包括IPCP、IPXCP等，实际当中最常见的是IPCP协议 IPCP控制协议负责完成点对点通信设备的两端协商IP地址 静态协商 动态协商 IPCP的数据报文是LCP数据报文的一个子集 Config-Request Config-Ack Config-Nak Config-Reject NCP协议的数据报文是在网络控制协商阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。NCP协议主要包括IPCP、
38、IPXCP等，实际当中最常遇见的是IPCP协议。 IPCP控制协议主要是负责完成点对点通信设备的两端动态的协商IP地址。依据两端设备的配置选项可将IPCP的协商过程分为”静态”和”动态”。 IPCP的数据报文同LCP的数据报文非常类似，LCP共包括十几种报文，IPCP报文类型只是LCP数据报文的一个子集（只有LCP代码域从1到7这七种报文），而且实际的数据报文交换过程中常见的是以下四种：Config-Request、Config-Ack、Config-Nak和Config-Reject（代码域从1到4，而链路终止报文一般而言是不在网络协议阶段使用的，而且也是不需要的）。 静态协商，也即是不协商
39、 双方需要告诉对方自身的IP地址，即发送Config-Request报文，其中配置选项中含有各自的IP地址 当对端收到该报文后，会发送一个Config-Ack报文，对路由器而言会增加一条到对端接口的主机路由 NCP协议的数据报文是在网络控制协商阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。NCP协议主要包括IPCP、IPXCP等，实际当中最常遇见的是IPCP协议。 IPCP控制协议主要是负责完成点对点通信设备的两端动态的协商IP地址。依据两端设备的配置选项可将IPCP的协商过程分为”静态”和”动态”。 IP
40、CP的数据报文同LCP的数据报文非常类似，LCP共包括十几种报文，IPCP报文类型只是LCP数据报文的一个子集（只有LCP代码域从1到7这七种报文），而且实际的数据报文交换过程中常见的是以下四种：Config-Request、Config-Ack、Config-Nak和Config-Reject（代码域从1到4，而链路终止报文一般而言是不在网络协议阶段使用的，而且也是不需要的）。 动态协商，也即是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址 发送方连续发送了两次Config-Request报文，才能完成发送方的协商过程 接收方只需要发送一次Config-
41、Request即可完成本端的协商过程 动态协商，也即是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址。 发送方连续发送了两次Config-Request报文，才能完成发送方的协商过程。而接收方仍然只需要发送一次Config-Request即可完成本端的协商过程。 由于发送方没有配置IP地址（而是动态获取IP地址），所以在IPCP的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-Request报文即可，当收到发送方的Config-Ack报文，就表示接收方的IP地址配置完成。