- PPP表示点到点协议。这是一种在串行链路上传输IP数据报的流行方洼,从低速的拨号调制解调器到高速的光链路。它被一些DSL服务供应商广泛部署,也可分配Intemet系统的参数(例如,最初的IP地址和域名服务器;见第6章)
- PPP实际上是一个协议集合,而不是一个单一的协议
- 它支持建立链接的基本方法——称为链路控制协议(Link Control Protocol, LCP),以及一系列NCP协议,在LCP建立了基 本链路之后,用于为各种协议(包括IPv4、 IPv6和非IP协议)建立网络层链路
- 一些相关 标准涉及对PPP的压缩和加密控制,以及在链接建立后的一些认证方法
- PPP的LCP用于在点到点链路上建立和维护低层的双方通信路径。因此,PPP操作只需关注一条链路的两端,它不需要像以太网和Wi-Fi的MAC层协议那样处理共享资源访问的问题
- PPP通常对底层的点到点链路有最低要求,LCP更是这样。链路必须支持双向操作(LCP使用的确认),以及异步或同步操作
PPP帧格式
- 通常, LCP使用简单的位级别帧格式,基于高级数据链路控制(HDLC)建立链路协议
- 在PPP设计时, HDLC就已建立了一种良好的帧格式
- IBM将它修改为同步数据链路控制(SDLC),在其专用的系统网络体 系结构(SNA)协议族中用作链路层协议
- HDLC协议还用作802.2中LLC标准的基础,并最终被用于PPP
- 在通常情况下, PPP帧格式类似于图3-22所示的HDLC帧,由2个1字节的包含固定 值Ox7E的标志字段“包围” 。点到点链路的两个端点使用这些字段来发现一个帧的开始和结束。如果Ox7E值出现在帧内部,这时会带来一个小问题。它可通过两种方式来处理,这取决于PPP工作在异步还是同步链路上:
对于异步链路:PPP使用字符填充(也称为字节填充)。如果标志字符出现在帧中其他地方,则用2字节序列Ox7D5E (Ox7D称为“ppp转义 字符”)替换。如果转义字符本身出现在帧中,则用2字节序列Ox7D5D替换。因此,接收方用Ox7E替换接收的Ox7D5E,并用Ox7D替换接收的Ox7D5D
在同步链路(例如Tl线路、 T3线路)上:PPP使用位填充
- 注意,标志字符的位模式为01111110 (连续6个1的位 序列),在除了标志字符之外的任何地方,位填充在5个连续1之后填充一个00这样做意味 着,发送的字节可能超过8位,但这通常是正常的,因为低层串行处理硬件能去掉填充的比 特流,并将它恢复成未填充时的样子
- 在第一个标志字段之后,PPP采用HDLC的地址(Addr)和控制字段。在HDLC中,地 址字段用于指定哪个站正在处理,但是由于PPP只关心一个目的地,这个字段总是被设置为 OxFF (所有站)。 HDLC控制字段用于指示帧序列和重传行为。由于这些链路层的可靠性功 能通常不是由PPP实现,所以控制字段设置为固定值OxO30 由于地址和控制字段在PPP中 都是固定的常数,所以在传输过程中经常通过一个称为地址和控制字段压缩(ACFC)的选项来省略它们,该选项实质上是消除了这两个字段
- PPP帧的协议字段表明携带的数据类型。在一个PPP帧中,可携带多种不同类型的协 议。正式列表和用于协议字段的分配号显示在“点到点协议字段分配”文档中[PPPn]。根据 HDLC规范,协议号的分配方式为:高位字节的最低有效位为0,低位字节的最低有效位为1。0xOOOO - Ox3FFF (十六进制)范围内的值表示网络层协议, Ox8000 - OxBFFF范围内的 值表示NCP的相关数据。0x4000 - Ox7FFF范围内的值用于NCP不相关的“很少使用的”协议。0xCOOO - OxEFFF范围内的值表示控制协议,例如LCPo在某些情况下,如果协议字 段压缩(PFC)选项在链路建立时协商成功,协议字段可被压缩为1字节。0xOOOO - OxOOFF 范围内的协议号适用于包括大多数流行的网络层协议在内的协议。注意, LCP分组总是使用 2字节的未压缩格式
- PPP帧的最后部分包含一个16位的FCS(一个CRC16,生成多项式为10001000000100001 ), 涵盖除FCS字段本身和标志字节之外的整个帧。注意, FCS的值涵盖任何字节或位被填充之前的帧。LCP选项(见3.6.1.2节)可将CRC从16位扩展到32位。在这种情况下,可采用 与前面提到的以太网相同的CRC32多项式
LCP帧
- LCP在基本PPP分组之上进行了简单的封装。如图3-23所示
- LCP的PPP协议字段值始终是OxCO21,它不能用PFC删除,以免产生歧义。标识字 段是由LCP请求帧的发送方提供的序列号,并随着每个后续消息进行递增。在生成一个回 复(ACK、 NACK或RE肥CT响应)时,这个字段通过复制响应分组请求中包含的值来构造。 采用这种方式,请求方可通过匹配标识符来识别相应请求的应答。代码字段给出了请求或响 应的操作类型:配置请求(OxOl )、配置ACK (OxO2)、配置NACK (OxO3)、配置REJECT (OxO4)、终止请求(OxO5 )、终止ACK(OxO6)、代码REJECT(OxO7)、协议REJECT(OxO8 )、 回送请求(OxO9)、回送应答(OxOA)、放弃请求(OxOB)、标识(OxOC)和剩余时间(OxOD)。ACK消息通常表明接受一组选项, NACK消息用建议选项表明部分拒绝。 REJECT消息完 全拒绝一个或多个选项。拒绝代码表明前一个分组包含的某些字段值未知。长度字段给出了LCP分组的字节长度,它不能超过链路的最大接收单元(MRU),我们稍后讨论一种建议的最 大帧限制。注意,长度字段是LCP协议的一部分; PPP协议通常不提供这种字段
- LCP的主要工作是使一条点到点链路达到最低要求。配置消息使链路两端开始基本配置 过程,并建立商定的选项。终止消息用于在完成后清除一条链路。LCP也提供了前面提到的 一些附加功能。回送请求/应答消息可由LCP在一条活跃链路上随时交换,以验证对方的操 作。放弃请求消息可用于性能测试,指示对方丢弃没有响应的分组。标识和剩余时间消息用 于管理目的:了解对方的系统类型,指出链路保持建立的时间(例如出于管理或安全原因)
- 从历史上来看,如果一个远程工作站处于环回模式(或者说“回路” ),这时点到点链路 会出现一个常见问题。电话公司的广域数据线路有时会为了测试而设置成环回模式,由一 方发送的数据直接由另一方返回。虽然这可能对线路测试有用,但它对数据通信完全没有帮 助,所以LCP包括一种发送魔术数字(由发送方选择的任意数字)的方式,并查看是否立即 返回相同类型的消息。如果是的话,该线路被检测为处于回路,并可能需要进行维护
为了对PPP链路建立和选项协商有一个更好的认识,图3-24显示了一个简化的分组交 换时间表和一个简化的状态机(在链路两端实现)。
- 一旦底层协议表明一个关联变为活跃(例如调制解调器检测到载波),则认为这个链路已 被建立。链路质量测试包含链路质量报告和确认交换(见3.6.1.2节),它也可以在此期间完成。 如果链接需要认证(这是常见的),例如当拨号到一个ISP时,可能需要一些额外的信息交换, 以认证链路上的一方或双方的身份。当底层协议或硬件表明一个关联已停止(例如载波消失), 或发送一个链路终止请求,并从对方接收到一个终止响应,则认为这个链路已被终止
三、多链路PPPLCP选项
- 当LCP建立一条由一个或多个NCP使用的链路时,可以对一些选项进行协商。我们 将讨论两种或更多的常见情况。异步控制字符映射(ACCM)或简称“ asyncmap”选项定义 哪些控制字符(即OxOO - OxIF范围内的ASCⅡ字符)需要被“转义”为PPP操作。转义一 个字符表示不发送这个字符的真实值,而将PPP转义字符(Ox7D)放在控制字符原始值和 Ox20异或形成的值之前。例如, XOFF字符(Ox13)将转换为(Ox7D33)发送o ACCM用于 控制字符可能影响底层硬件操作的情况。例如,如果软件流控制能够使用XON/XOFF字符, 而XOFF字符未经转义就通过链路传输,则硬件直到看到一个XON字符才停止数据传输o asyncmap选项通常是一个32位的十六进制数,其中第77个最低有效位被设置为1 ,表示值为#的控制字符应被转义。因此, aSynCmaP为Oxffffffff表示转义所有控制字符,为OxOOOOOOOO 表示不转义任何控制字符,为OxOOOAOOOO表示转义XON (Ox11 )和XOFF (Ox13)。虽然 Oxffffffff是默认值,但当前很多链路可在asyncmap被设置为OxOOOOOOOO时安全运行。
- 由于PPP缺少一个长度字段,并且串行线路通常不提供帧封装,所以在理论上对一个 PPP帧的长度没有硬性限制。实际上,最大帧大小通常由MRU指定。当一台主机指定一个 MRU选项(类型OxOl )时,它要求对方不发送比MRU选项提供的值更长的帧。MRU值是 数据字段的字节长度,它不计算其他PPP开销字段(即协议、 FCS、标志字段)。它的典型 值是1500或1492,但也可能多达65 5350 1Pv6操作需要的长度最小为12800 PPP标准要求 具体实现能接收最大1500字节的帧, MRU更多的是建议对方选择帧大小,而不是硬性限制 帧大小。当小分组和大分组在同一条PPP链路上交错传输时,较大分组可能占用一条低带宽链路的大部分带宽,并影响小分组的正常传输。这可能导致抖动(延迟变化),对交互式应用 (例如远程登录和VbIP)产生负面影响。配置较小的MRU (或MTU)有助于缓解这个问题, 但会产生更大的开销
- PPP支持一种交换链路质量报告信息的机制。在选项协商期间,可能包括一个包含所请 求的特定质量协议的配置信息。选项中的第16位被保留给特定协议,但最常见的是一个包 括链路质量报告(LQR)的PPP标准[RFC1989],它在PPP协议字段中使用值OxCO250如 果启用该选项,则要求对方按某个周期间隔提供LQR。LQR请求之间的最大周期间隔被编 码为一个32位数字,它被保存在配置选项中,并以1/100秒为单位表示。对方可能比这个 要求更频繁地生成LQRoLQR包括以下信息‥一个魔术数字、发送和接收的分组数和字节数、 出错的输人分组数和丢弃的分组数,以及交换的LQR总数。在一个典型的实现中,允许用 户设置对方发送LQR的频繁程度。如果链路质量无法满足某些配置阑值,有些实现也提供 了终止链路的方法。LQR可在PPP链路进人建立状态后请求。每个LQR被赋予一个序列号, 因此它能确定一段时间内的趋势,甚至在LQR重新排序时也能确定
- 很多PPP实现支持一种回叫功能。在一次典型的回叫建立过程中, PPP拨号回叫客户端 呼叫PPP回叫服务器,并提供认证信息,而服务器断开连接并回叫客户端。在呼叫费用不对 称或对于某些安全级别的情况下,这种做法可能是有用的。LCP选项针对用于协商回叫的协 议,该选项值为OxOD [RFC1570]。如果许可,回叫控制协议(CBCP)完成协商
- PPP使用的一些压缩和加密算法在处理时需要一定的最小字节数,称为块大小。在数据 不够长的情况下,通过填充增加数据长度,达到一个甚至多个块的大小。如果存在填充,它通[函 常位于数据区后面,并位于PPP FCS字段之前。一种填充方法称为自描述填充[RFC1570], 它将填充值变为非零值。这时,每个字节获得填充区域的偏移量值。因此,填充的第一个字 节值为Ox0l,最后一个字节包含填充字节数。最多支持255字节的填充。自描述填充选项 (类型10)用于让对方了解填充类型和最大填充值(MPv),它是这个关联允许的最大填充 值。由于基本PPP帧缺少一个明确的长度字段,因此一个接收方可使用自描述填充,以确定 应从接收的数据区删除多少填充字节
- 为了减小每个帧包含一个头部的固定开销,提出了一种将多个不同协议的有效载荷聚合 成PPP帧的方法,称为PPPMux [RFC3153]方法。主要PPP头部的协议字段被设置为聚合 帧(OxoO59),然后每个有效载荷块被插人帧中。通过在每个有效载荷块之前插人1 - 4字 节的子帧头部来实现。在子帧头部中, 1位(称为PFF)说明子帧头部中是否包含协议字段, 1位(称为LxT)说明后面的长度字段是1字节还是2字节。除此之外, 1或2字节的协议 ID使用与外部的PPP头部相同的值和压缩方法。在子帧与默认PID (该PID在配置阶段通 过PPPMux控制协议(PPPMuxCP)建立)匹配时, PFF可以为0 (意味着不存在PID字段)
- PPP帧格式如图3-19所示,普通PPP/HDLC的FCS可以是16或32位。默认的FCS为 16位,但32位的FCS值可通过32位的FCS选项来启用。其他的LCP选项包括使用PFC 和ACFC,以及认证算法的选择
- 国际化[RFC2484]提供了一种使用语言和字符集的表示方式。字符集是一个来自“字符集注册表” [IANA-CHARSET]的标准值,并从[RFC5646] [RFC4647]的列表中选择语言
- PPP的一个特殊版本称为多链路PPP (MP) [RFC1990],可用于将多条点到点链路聚合为一条链路。这种想法与前面讨论过的链路聚合相似,并被用于多个电路交换信道(例如 ISDNB信道)的聚合。MP包含一个特殊的LCP选项,表示支持多链路,以及一个用于多 链路上PPP帧分片与重组的协商协议。一条聚合链路(称为一个捆绑)可作为一条完整的虚 拟链路来操作,并包含自已的配置信息。链路捆绑由大量成员链路组成。每个成员链路可能有自已的选项集
- 实现MP的典型方法是使分组轮流经过备个成员链路传输。这种方法称为银行柜员算 法,它可能导致分组重新排序,可能为其他协议带来不良的性能影响。 (例如,虽然TCP/ IP可以正确处理重新排序后的分组,但也可能不如没有重新排序处理得好。) MP在每个 分组中添加一个2 - 4字节的序列头部,而远程MP接收方的任务是重建正确的顺序。 图3-25显示了这种数据帧
- 在图3-25中,我们看到一个MP分片的开始分片(B)、结柬分片(E)位字段和序列号 字段。这里,需要注意的是长格式(4字节用于分片信息)和短格式(2字节用于分片信息)。 在选项协商阶段, LCP的短序列号选项(类型18)用于选择使用的格式。如果一个帧没有被 分片,但使用这种格式传输,则B和E位都被置位,表明该分片是第一个和最后一个(即它 是整个帧)。否则,第一个分片的B、 E位组合被设置为10,最后一个分片的B、 E位组合被 设置为01 ,它们之间的所有分片被设置为000序列号给出相对第一个分片的分组号偏移量
- MP使用一个称为多链路最大接收重构单元(MRRU,类型18)的LCP选项,它可将一 系列更大的MRU应用于捆绑中。大于成员链路MRU的帧仍被允许通过这个MP链路,直 到达到这个值的上限为止
- 由于一个MP捆绑可能跨越多条成员链路,因此需要一种方法来确定成员链路属于同一 捆绑。同一捆绑中的成员链路由LcP端点鉴别(类型19)选项识别。端点鉴别可使用电话 号码、从IP或MAC地址中提取的数字,以及其他可管理的字符串。除了每个成员链路的常 见内容,对这个选项的格式没有多少限制
- 建立MP的基本方法定义在[RFC1990]中,希望各个成员链路可对称使用,相近数量 的分片被分配到号码围定的每条链路上。为了实现更复杂的分配, [RFC2125]中规定了带 宽分配协议(BAP)和带宽分配控制协议(BACP)。BAP用于为一个捆绑动态添加或删除链 路,而BACP用于交换如何使用BAP添加或删除链路的信息。这种功能有助于实现按需带 宽(BOD。在一些需要分配固定资源以满足应用(例如一定数量的电话连接)对带宽需求的网络中, BOD通常需要监测流量,在应用需求高时创建新的连接,以及在应用需求低时删 除连接。在某些开销和连接数量相关的情况下,这种功能是有用的
- BAP/BACP使用一种新的链路鉴别LCP选项(LCP选项类型为23 )。这个选项包含一 个16位的数字值,一个捆绑中的每条成员链路有不同的值。它被BAP用于确定需要添加或 删除哪些链路。在一条PPP链路的网络阶段,每个捆绑都需要使用BACP协商。它的主要目 的是找出首选对端。也就是说,如果在多个对端之间同时建立多个捆绑时,将会优先为首选 对端分配成员链路
- BAP包括3种分组类型:请求、响应和标识。请求用于向一个捆绑添加一条链路,或从 一个捆绑中删除一条链路。标识用于为原始或被确认的请求返回结果。响应是对这些请求的 ACK或NACK.。更多细节见[RFC2125]
- 从历史上来看,PPP是相对较慢的拨号调制解调器使用的协议。因此,针对PPP链路上 压缩后发送数据已提出一些方法。压缩类型是不同的,无论是调制解调器硬件支持的压缩类 型(例如V42bis、 V44),还是我们以后讨论的协议头部压缩。目前,有几个压缩选项可选。 可在一条PPP链路的两个方向做出选择, LCP可协商一个使压缩控制协议(CCP) [RFC1962] 生效的选项。ccp的作用就像NCP (见3.6.5节),只不过在LCP链路建立交换阶段指明压 缩选项时才开始处理配置压缩细节
- CCP在行为上很像NCP,仅在链路进人网络状态时协商。它使用与LCP相同的分组交换过程和格式(除协议字段被设置为Ox80FD之外),另外还有一些特殊选项,并对常见的代 码字段值(1~7)定义了2个新的操作:复位请求(Oxoe)和复位确认(Oxof)。如果在一 个压缩帧中检测到一个错误,复位请求可用于要求对方复位压缩状态(例如字典、状态变量、 状态机等)。在复位后,对方响应一个复位确认
- 一个或多个压缩帧可作为一个PPP帧的一部分(即包括LCP数据和可能的填充部分)。 压缩帧携带的协议字段值为OxooFD,但是如何指明存在多个压缩帧,这依赖于使用的特定 压缩算法(见3.6.6节)。当CCP与MP结合使用时,既可用于一个捆绑,也可用于多条成员 链路的某些组合。如果只用于成员链路,协议字段设置为Ox00FB (单个的链路压缩数据报)
- CCP可使用十几个压缩算法之一[PPPn]。大多数算洼不是官方标准的IETF文档,虽然 它们可能已在RFC中加以描述(例如, [RFC1977]描述了BSD压缩方案, [RFC2118]描述 了Microsoft点对点压缩协议(MPPC))。如果使用压缩, PPP帧在进一步处理之前需要重构, 因此高层的PPP操作通常不关心压缩帧的细节
- 在一条PPP链路处于网络状态之前,通常有必要使用某种认证(身份验证)机制,以识 别建立链路的对方身份
- 基本的PPP规范默认不提供认证,因此图3-24中的认证交换在这 种情况下不会出现。但是,某种形式的认证在多数时候是需要的,一些经过多年演变的协 议被用于应对这种情况。在本章中,我们仅从高层的角度展开讨论,并将细节留给关于安 全的章节(第18章)
- 与不提供认证相比,最简单、安全性最低的认证方案是密码认证协议 (PAP)。这种协议非常简单,一方请求另一方发送一个密码。由于该密码在PPP链路上未加 密传输,窃听者在线路上可轻易捕获密码并使用它。由于这个重大的漏洞,不建议使用PAP进行认证o pAP分组像LCP分组那样编码,协议字段值设置为OxCO230
- 查询一握手认证协议( CHAP) [RFC1994]提供了一种更安全的认证方法。在使用CHAP 时,一个随机值从一方(称为认证方)发送到另一方。响应通过一种特殊的单向(即不可逆)功能,将一个随机值和一个共享密钥(通常由密码生成)结合形成响应中的一个数字。在接 收到这个响应之后,认证方能更可靠地验证对方密钥是否正确。这个协议在链路上不会以明 文(未加密)形式发送密钥或密码,因此窃听者难以了解相关信息。由于每次使用不同的随 机值,每个查询/响应的结果会改变,即使一个窃听者有可能捕捉到这个值,也无法通过重 新使用(回放)来欺骗对方
- EAP [RFC3748]是一个可用于备种网络的认证框架。它支持很多(约40个)不同的认 证方法,从简单密码(例如PAP和CHAP)到更可靠的认证类型(例如智能卡、生物识别)。EAP定义了一种携带各种认证的消息格式,但需要额外的规范定义EAP消息如何在特定的 链路上传输
- 当EAP被用于PPP时,前面讨论过的基本认证方法不变o EAP不是在链路建立(LCP 建立)阶段协商一种认证方法,认证操作将被推迟到认证状态(网络状态的前一个状态)。这 允许更多信息类型用于影响远程访问服务器(RAS)的访问控制决策。当某种标准的协议用 于执行各种认证机制,网络访问服务器可能无须处理EAP消息内容,但可依靠其他基础设 施的认证服务器(例如RADIUS服务器[RFC2865])确定访问控制决策。这是当前的企业网 和ISP设计中的首选方案
- 虽然多种NCP可用于一条PPP链路(甚至同时),但我们将关注支持IPv4和IPv6的 NCPo 对于IPv4, NCP被称为IP控制协议(IPCP) [RFC1332]。对于IPv6, NCP被称为IPV6CP [RFC5072]。在LCP完成链路建立和认证之后,该链路每端都进人网络状态,并使 用一个或多个NCP (例如典型的是一个IPCP)进行网络层的相关协商
- IPCP (针对IPv4的标准NCP)可用于在一条链路上建立IPv4连接,以及配置Vin Jacobson头部压缩(VJ压缩) [RFCl144]。IPCP分组在PPP状态机进人网络状态之后交换o IPCP分组使用与LCP相同的分组交换机制和分组格式,除非协议字段被设置为Ox8021,并 且代码字段被限制在范围0 - 70代码字段的值对应于消息类型:特定供应商(见[RFc2153])、 配置请求、配置ACK、配置REJECT、终止请求、终止ACK和代码REJECT。IPCP可协商一系列选项,包括IP压缩协议(2)、 IPv4地址(3)和移动IPv4 (4) [RFC2290]。其他选 项可用于获得主要和次要的域名服务器(见第11章)
- IPV6CP使用与LCP相同的分组交换机制和分组格式,但它有两种不同的选择:接口标 识符和IPv6压缩协议。接日标识符选项用于传输一个64位的ⅡD值(见第2章),它作为形 成一个链路本地IPv6地址的基础。由于它仅在本地链路上使用,因此不需要具有全球唯一 性。这通过在IPv6地址的高位使用标准链路本地前缀,在低位设置某种功能的接口标识符 来实现。这里模拟了IPv6自动配置过程(见第6章)
- PPP拨号线路的速率一直较慢( 54000b/s或更少),很多小的分组通常使用TCP/IP (例 如TCP确认,见第15章)。这些分组大部分包含TCP和IP头部,同一TCP连接上的分组之间变化不大。其他高层协议的行为相似。因此,压缩(或消除)高层协议头部是一种有用 的方法,这样以来就可在相对较慢的点到点链路上传输更少字节。现代的压缩或消除头部方法一直在随着时间演变。我们将从前面提到的vJ压缩开始,按时间顺序讨论它们
- 在VJ压缩中,部分高层(TCP和IP)头部被1字节的连接标识符代替。 [RFCl144]讨 论了这种方法的起源,它最初来源于一种旧的、称为CSLIP (压缩串行线路IP)的点到点协 议。一个典型IPv4头部的长度是20字节,一个没有选项的TCP头部的长度也是20字节。 因此,一个常见的TCP/IPv4头部组合是40字节,并且很多字段在分组间没有变化。另外, 很多字段在分组间只有很小或有限的变化。如果不变的值通过一条链路(或一段时间内)传 输并被保存在一张表中,则在后续分组中可用一个小的索引代替该值。变化有限的值可以仅 编码差异部分(即仅发送变化的部分)。因此,整个40字节头部通常可有效压缩到3或4字 节。这样可显著提高在低速链路上的TCP/IP性能
- 头部压缩的下一步演化简称为IP头部压缩[RFC2507] [RFC3544]。它提供了一种压缩 多个分组头部的方式,使用TCP或UDP传输层协议,以及IPv4或IPv6网络层协议。这种 技术是VJ压缩技术的一种逻辑上的扩展,可用于多种协议以及PPP链路之外的其他链路。 [RFc2507]指出了底层链路层的一些强大的差错检测机制的必要性,因为,如果压缩头部在 运输过程中损坏,出错的分组可在离开链路层时被构造。我们需要认识到,当头部压缩用于 链路上时,可能不会像PPP的FCS计算那样强大
- 头部压缩的最新改进方案称为鲁棒性头部压缩(ROHC) [RFC5225]。它进一步改进了 IP头部压缩以涵盖更多的传输协议,并允许同时处理多种头部压缩方式。前面提到的IP头 部压缩可适用于不同类型的链路,包括PPP
- 我们查看一台PPP服务器的调试输出,它通过拨号的调制解调器与客户机交互。客户机 是一台有IPv6功能的运行Microsoft Windows Vista的计算机,服务器是一台运行Linux的计 算机。客户机配置为可在单一链路上协商多链路功能(属性1选项I PPP设置),出于演示目 的,服务器配置为使用CCP协商加密协议(见以下代码清单中的MPPE):
- 这里,我们可看到一些涉及PPP的交换,它是从服务器的角度来看的o ppp服务器进 程创建的(虚拟)网络接日为pppo,它在连接串行端日ttySO的拨号调制解调器上等待连 接请求(称为“输人连接”)。当有连接请求到达时,服务器依次发送OxO的异步控制字符 映射(asyncmap)、 EAP认证、 PFC和ACFC请求。客户拒绝EAP认证,并建议使用MSCHAP-V2 ( ConENak) [RFC2759]。服务器再次尝试发送请求,并使用MS-CHAP-V2,这次请求被接受和确认(ConfAck)。接下来, “输人”请求包括CBCP,一个与MP支持相关的 1614字节的MRRU,以及一个端点IDo服务器拒绝CBCP和多链路操作(ConfRqj)请求。 客户机发送不带MRRU的端点鉴别请求,并被接收和确认。下一步,服务器发送一个名为 dialer的CHAP查询。在该查询的响应到达之前,两个标识消息到达,表明对方以字符串 MSRASV5.20和MSRAS-0-VISTA来标识。最后, CHAP响应到达并验证通过,表明许可访 问。这时, PPP转换为网络状态
- 当进人网络状态时, CCP、 IPCP和IPV6CP NCP被交换o ccp尝试协商微软点对点加 密(MPPE)[RFC3078]oMPPE有些不同之处,因为它是一种加密协议,而不是一种压缩协议, 它实际将分组扩大了4字节。但是,它提供了一个相对简单的方法,早在协商过程中就完成 了加密。选项+H-M+S+L-D-C表明MPPE是否采用无状态操作(H)、使用哪种加密 密钥强度(安全, S;中等, M;低, L)、是否存在过时的D位,以及是否需要单独、专用 的MPPC的压缩协议(C) [RFC2118]。最终,双方同意在有状态模式下使用强大的128位密 钥(一H, +S)。注意,在这次协商过程中,客户机尝试发送一个IPCP请求,但服务器响应 的是一个主动的TermAck (一个LCP定义、 ICPC采纳的消息)。它用于向对方指出服务器 “需要重新谈判” [RFC1661]
- 在MPPE协商成功之后,服务器请求使用VJ头部压缩,并提供它的IPv4地址和IPv6 地址,分别为192.168.0.1和fe80::0206‥5b播fedd:C5c30这个IPv6地址是从服务器的以太网 MAC地址00‥06:5B‥DD:C5:C3而来。客户机最初使用IPCP建议的IPv4地址和域名服务器 0.0.0.0,但被拒绝。客户机请求使用fe80::0000:0000:dead:beef作为IPv6地址,这个请求被 接受和确认。最后,客户机确认服务器的IPv4和IPv6地址,并且表明自已已建立IPv6地 址。接着,客户机再次请求IPv4和服务器地址0.0.0.0,再次被拒绝0 192.168.0.1被接受和 确认
- 我们从这次交换中可看到, PPP协商是既灵活又烦琐的。很多选项可以尝试、拒绝和重 新协商。虽然在低延时链路上这可能不是一个大间题,但这种交换中的每个消息都需要花费 几秒(或更长)到达目的地。如果在一条卫星链路上,则可能出现很大的超时。对用户来说, 链路建立明显是一个太长的过程